Monitoring Security | Beginning Fedora 2

There are several ways to monitor the security of your Fedora Core system that enable you to spot security breaches and other potential problems.

System Logs

The Fedora Core system maintains several log files that record system activity. Most of the interesting ones reside in /var/log .

/var/log

The table that follows describes the most important log files that you will find in /var/log .

File in /var/log	Contents	View with
Btmp	Record of all bad login attempts. Updated by login program if it exists.	lastb command
Cron	Messages sent to syslogd from the cron daemon (which schedules jobs on UNIX systems).	Normal text-viewing tools
Dmesg	Kernel messages (from boot ).	Normal text-viewing tools
Lastlog	Last login times for all users.	lastlog command
Messages	Messages sent to syslogd with level of info or higher, except those from mail , cron , or authentication- related messages.	Normal text-viewing tools
Secure	Messages sent to syslogd from authpriv (that is, authentication and security messages that should be visible only to privileged users).	Normal text-viewing tools
Wtmp	Record of all logins and logouts.	last command

Note

Note that several of these files are maintained by the kernel logging daemon syslogd . The behavior of this daemon is controlled by the configuration file /etc/syslog.conf , and you can customize it if you don t like the defaults (which are pretty good). For more information on configuring syslog , check its man page.

The files /var/log/btmp and /var/log/wtmp are updated only if they exist (that is, the programs that update these files won t create them for you). The default Fedora Core 2 installation has /var/log/wtmp , so all logins and logouts are logged, but not /var/log/btmp .

A diligent system administrator will regularly review the contents of these log files, either using tools such as gedit , if the file is a plain text file, or the appropriate command, such as last or lastlog if the file contains formatted data. However, regularly trawling through log files for the occasional message of significance is very tedious . Fortunately, an automated tool called logwatch takes away much of the tedium. Even better, Red Hat includes a sensible default setup so it s up and running out of the box.

logwatch

Fedora Core 2 has a tool called logwatch that can search through log files for interesting messages and summarize them elsewhere. We will look at the default configuration provided with Fedora Core 2 here.

The configuration files for logwatch are in /etc/log.d . The main configuration file is called logwatch.conf , and here are the default contents:

######################################################## # This was written and is maintained by: # Kirk Bauer <kirk@kaybee.org> # # Please send all comments, suggestions, bug reports, # etc, to kirk@kaybee.org. # ######################################################## # NOTE: # All these options are the defaults if you run logwatch with no# command-line arguments. You can override all of these on the # command-line. # You can put comments anywhere you want to. They are effective for the # rest of the line. # this is in the format of <name> = <value>. Whitespace at the beginning # and end of the lines is removed. Whitespace before and after the = sign # is removed. Everything is case *insensitive*. # Yes = True = On = 1 # No = False = Off = 0 # Default Log Directory # All log-files are assumed to be given relative to this directory. # This should be /var/log on just about all systems... LogDir = /var/log # Default person to mail reports to. Can be a local account or a # complete email address. MailTo = root # If set to 'Yes', the report will be sent to stdout instead of being # mailed to above person. Print = No # if set, the results will be saved in <filename> instead of mailed # or displayed. #Save = /tmp/logwatch # Use archives? If set to 'Yes', the archives of logfiles # (i.e. /var/log/messages.1 or /var/log/messages.1.gz) will # be searched in addition to the /var/log/messages file. # This usually will not do much if your range is set to just # 'Yesterday' or 'Today'... it is probably best used with # Archives = Yes # Range = All # The default time range for the report... # The current choices are All, Today, Yesterday Range = yesterday # The default detail level for the report. # This can either be Low, Med, High or a number. # Low = 0 # Med = 5 # High = 10 Detail = Low # The 'Service' option expects either the name of a filter # (in /etc/log.d/scripts/services/*) or 'All'. # The default service(s) to report on. This should be left as All for # most people. Service = All # If you only cared about FTP messages, you could use these 2 lines # instead of the above: #Service = ftpd-messages # Processes ftpd messages in /var/log/messages #Service = ftpd-xferlog # Processes ftpd messages in /var/log/xferlog # Maybe you only wanted reports on PAM messages, then you would use: #Service = pam_pwdb # PAM_pwdb messages - usually quite a bit #Service = pam # General PAM messages... usually not many # You can also choose to use the 'LogFile' option. This will cause # logwatch to only analyze that one logfile.. for example: #LogFile = messages # will process /var/log/messages. This will run all the filters that # process that logfile. This option is probably not too useful to # most people. Setting 'Service' to 'All' above analyizes all LogFiles # anyways...

As you read through the file, you see that most of the lines are comments (because they start with the # sign, and that s a widely used way of introducing comments in most script and configuration files). So, out of all those lines, the only entries that are in effect are the following:

   LogDir = /var/log     MailTo = root     Print = No     Range = yesterday     Detail = Low

These are highlighted in bold in the example. If you consult the man page for logwatch (run the command man logwatch ), you can see that logwatch will check the log files in /var/log , looking for entries from the previous day, and e-mail a report containing a low level of detail to root.

If you ve run your system for a few days and checked root mail, you ll have seen messages from logwatch ”so how is this happening? Scheduling of unattended jobs on Fedora Core 2, and most other UNIX versions, is handled by the cron daemon . This daemon looks for files containing information about when and what to run in the directories /var/spool/cron and /etc/cron.d , and in the file /etc/crontab . On Fedora Core 2, the /etc/crontab file is the one that is configured by default.

If you examine the contents of this file, you see a few lines of environment information, and some other lines starting with numbers :

   SHELL=/bin/bash     PATH=/sbin:/bin:/usr/sbin:/usr/bin     MAILTO=root     HOME=/     # run-parts     01 * * * * root run-parts /etc/cron.hourly     02 4 * * * root run-parts /etc/cron.daily     22 4 * * 0 root run-parts /etc/cron.weekly     42 4 1 * * root run-parts /etc/cron.monthly

The numbers specify when cron should run the command described by the rest of the line. There are five fields, which are, from left to right, minute, hour , day of month, month, and day of week. Where an asterisk is used, this means I don t care. So the four scheduled jobs in the default Fedora Core 2 crontab are run at times shown in the table that follows.

Scheduled Time	Interpretation
01 * * * *	01 minutes past each hour
02 4 * * *	04:02 every day
22 4 * * 0	04:22 every Sunday (1=Monday, 2=Tuesday, and so on; Sunday=0 or 7)
42 4 1 * *	04:42 on the 1st day of every month

The jobs are essentially similar; run the run-parts script as root and pass the name of a directory (for example, /etc/cron.hourly for the job run at 1 minute past each hour). The run-parts script simply runs every executable file it finds in the directory that it is given (except files ending in the characters ~ or , , and a few other exceptions). If you look in the /etc/cron.daily directory, you ll see a file called 00-logwatch , which is a symbolic link to the logwatch command.

All this means that, at 04:02 every day, the root user will be mailed a message containing summaries of important information entered into various log files in /var/log the previous day. This is all set up for you when Fedora Core is installed, but now that you know how it works, you can adjust the configuration to suit your own requirements. If, for example, you d like more information in the messages, you can simply edit /etc/log.d/logwatch.conf and change the Detail = Low line to Detail = High . Maybe you d like the message to be sent at 00:15 instead. Just delete the file 00-logwatch from /etc/cron.daily (so the 04:02 daily cron job no longer runs) and add the following line to /etc/crontab :

   15 00 * * * root /usr/sbin/logwatch

It s as simple as that.

System Integrity

Once a hacker has gained access to a system, she will often want to install modified versions of system files to ensure their continued access and to gather more information that will help her achieve her objectives. If your security analysis has identified this threat as one you need to consider, you need to have some means of identifying when your system may have been compromised in this way, so you can take remedial action (restore the compromised file from a trusted backup).

But if you re checking the system for modified files, you ll not only identify files modified by intruders, you ll also identify files that may have been inadvertently modified by authorized individuals, or that have become corrupt due to hardware problems (such as bad blocks appearing on disk drives ).

Tripwire

Tripwire is an open source system integrity checker that is available for Fedora Core. It is a useful weapon in the system administrator s armory, so this section will take you through obtaining it and setting it up. Note that when Tripwire scans the system to detect changes, it s doing a lot of work and will hit the processor(s) and file I/O hard.

Try It Out Downloading, Configuring, and Running Tripwire

Tripwire is available in RPM format for Fedora Core, which makes installation very straightforward. It s available on the Fedora Core 2 CD-ROMs, but as an interesting exercise, you ll try using the rpm command s built-in FTP and HTTP client. You ll use the rpm command to download and install the Tripwire RPM with a single command. Open a terminal window, switch to the root user, and type in the following command (all on one line):

Note

You ll need to change the httpproxy IP address and httpport port number to suit your Internet connection (omit them if you don t need to go through a proxy server to access the Internet).

   # rpm iv --httpproxy 10.4.65.2 --httpport 3128 http://download.fedora.us/fedora/fedora/1/i386/RPMS.testing/tripwire-2.3.1-18.fdr.3.1.i386.rpm

The command also assumes that you re running on an Intel architecture machine. If not, you will need to download the source RPM and build the package yourself.

After a few minutes (depending on the speed of your Internet connection), you should see the message Preparing packages for installation . . . followed by tripwire-2.3.1-18, and be returned to the command prompt.

You can confirm that the Tripwire package was installed by running the following command:
```
   # rpm q tripwire   
```
If all is well, you ll get the package version information back; if not, you ll get a message saying package tripwire is not installed (in which case, just download the RPM in the conventional way, and try again).
Now that Tripwire is installed, you can configure its policies and complete the setup. Before diving in to the configuration, take time to read the README file in /usr/share/doc/tripwire-2.3.1 , and the twintro and twpolicy man pages to familiarize yourself with therequired configuration tasks . These can be divided into three distinct steps:
- Setting up the policy file
- Initializing the Tripwire database
- Configuring Tripwire to run periodically and report system integrity violations
Let s begin with the policy file. Tripwire s policy file defines which files and directories Tripwire should monitor for changes, and what changes are significant. For some files, such as those in /bin/login , any change in file contents, modification date, or ownership is suspicious, but you d expect them to be accessed frequently. Other files, such as log files, are expected to grow in size , but not change ownership.

The policy file that is installed with the RPM in /etc/tripwire/twpol.txt tells Tripwire to monitor many files that probably don t exist on your system, so you ll get lots of spurious error messages when you run an integrity check. What you really need to do is edit the policy file so that files and directories that don t exist aren t monitored , and conversely, if files and directories that do exist are commented out in the policy file, they are reinstated. It would be tedious to do this by hand, so let s use our newfound knowledge of Perl to write a script to do it for us.
The algorithm you need to employ is straightforward. If you find a line that looks like an instruction to Tripwire to check a file or directory (optional white space, string beginning with / ), you should check that the file or directory exists. If not, comment out the line to prevent Tripwire from generating an error.

Similarly, if you find a line in the policy file that looks like a commented-out file (optional white space, # , optional white space, string beginning with / ), check if the file or directory exists. If it does, you ll remove the comment to reinstate the file.

We ll write the script as a filter, so it reads configuration lines from STDIN and writes to STDOUT . Any lines that don t look like either of the types of line you re interested in are passed through unmodified.

Here s the script (we hope your new knowledge of Perl will give you an idea of the structure being employed, even if the details are still a bit beyond you ”they ll come with practice):

   #! /usr/bin/perl -w     # Filter for Tripwire policy file. Looks for lines that     # start with optional whitespace and a filename, and     # comments them out if the file does not exist. Also     # looks for commented out lines containing filename and     # removes comment if they do exist.     $Additions = 0;     $Removals = 0;     # Read each line from stdin into the $line variable     while ($line = <STDIN>) {     # Look for lines that match a pattern (the Perl     # pattern matching characters are enclosed in [])     # start with optional white space [ ^\s* ]     # then a '#' [ # ]     # then more optional white space [ \s* ]     # then a string starting with '/' that doesn't     # contain white space [ \/\S+ ]     #     # The last part of the pattern is enclosed in ()     # so that if the pattern matches, we can access     # this part through the  variable.     #     # This pattern matches a commented out entry/     if ($line =~ /^\s*#\s*(\/\S+)/) {     # Found commented out entry. If the file exists,     # strip off the comment character.     if (-e) {     $line =~ s/^\s*#//;     $Additions++;     }     # Now look for a line that's like the above but     # without the '#' comment character.     } elsif ($line =~ /^\s*(\/\S+)/) {     # Found entry that starts with "  /". If file     # does not exist, then comment out entry.     if (! e) {     $line = "# " . $line;     $Removals++;     }     }     # Output the line (whether modified or not)     print $line;     }     # Print the statistics on STDERR, so they won't get redirected by >     print STDERR "Number of additions: $Additions\n";     print STDERR "Number of removals: $Removals\n";

Create a text file containing this script and call it /usr/local/bin/cleanpol.pl , and make it executable by running the following command:
Note
Depending on the examples you ve followed earlier in the book, you may need to acquire root privileges at this point.

# chmod +x /usr/local/bin/cleanpol.pl
Now you can use this Perl script to produce a customized Tripwire policy file:
```
   # cd /etc/tripwire     # mv twpol.txt twpol.txt.orig     # /usr/local/bin/cleanpol.pl <twpol.txt.orig \ >twpol.txt   ... Number of additions: 38 Number of removals: 125 
```
This little script saves you from making 163 manual changes to the Tripwire policy file! (The number of changes made on your system will vary depending on which packages you have installed.) You can review the changes that were made with the diff command:
```
 diff twpol.txt.orig twpol.txt 
```
Now, use gedit , or your favorite text editor, to review the contents of the updated /etc/tripwire/twpol.txt file. In particular, there may be a problem with the line defining the policy for /sbin/e2fsadm . If the cleanpol.pl script uncommented this line, the note tune2fs? at the end of the line is treated by Tripwire as a relative path to a file, and the policy file is rejected. Simply delete this note, as in the following:
```
   /sbin/e2fsadm    -> $(SEC_CRIT) ; tune2fs?   
```
becomes
```
   /sbin/e2fsadm    -> $(SEC_CRIT) ;   
```

The next step is to initialize the Tripwire database. This is done by running the twinstall.sh script in /etc/tripwire :

   # ./twinstall.sh

This script asks you to enter site and local passphrases (a term used to describe a long password), generates encryption keys, and cryptographically secures the configuration and policy files to prevent unauthorized changes:

[root@rh9 tripwire]# ./twinstall.sh ---------------------------------------------- The Tripwire site and local passphrases are used to sign a variety of files, such as the configuration, policy, and database files. Passphrases should be at least 8 characters in length and contain both letters and numbers. See the Tripwire manual for more information. ---------------------------------------------- Creating key files... (When selecting a passphrase, keep in mind that good passphrases typically have upper and lower case letters, digits and punctuation marks, and are at least 8 characters in length.) Enter the site keyfile passphrase: Verify the site keyfile passphrase: Generating key (this may take several minutes)...Key generation complete. (When selecting a passphrase, keep in mind that good passphrases typically have upper and lower case letters, digits and punctuation marks, and are at least 8 characters in length.) Enter the local keyfile passphrase: Verify the local keyfile passphrase: Generating key (this may take several minutes)...Key generation complete. ---------------------------------------------- Signing configuration file... Please enter your site passphrase: Wrote configuration file: /etc/tripwire/tw.cfg A clear-text version of the Tripwire configuration file /etc/tripwire/twcfg.txt has been preserved for your inspection. It is recommended that you delete this file manually after you have examined it. ---------------------------------------------- Signing policy file... Please enter your site passphrase: Wrote policy file: /etc/tripwire/tw.pol A clear-text version of the Tripwire policy file /etc/tripwire/twpol.txt has been preserved for your inspection. This implements a minimal policy, intended only to test essential Tripwire functionality. You should edit the policy file to describe your system, and then use twadmin to generate a new signed copy of the Tripwire policy.

The final step in initialization is to run the command tripwire -- init . You are prompted for the local passphrase; then Tripwire scans all the files listed in the configuration file and gathers baseline data against which all future scans are run. This may take several minutes, so be patient:

Note

It is vital that you are confident the system is in a sound state before initializing the database, otherwise there s little point in using Tripwire. After the database is initialized , it s a good idea to put a copy on write-once media (for example, CD-ROM) so that it cannot be altered :

   # tripwire --init   Please enter your local passphrase:  Parsing policy file: /etc/tripwire/tw.pol Generating the database... *** Processing Unix File System *** Wrote database file: /var/lib/tripwire/rh9.twd The database was successfully generated.

Setting Up Tripwire to Run Automatically

You ve already seen how logwatch is set up to run automatically every day at 04:02. You can easily set up Tripwire to run at the same time.

Create a two-line script called /etc/cron.daily/run-tripwire containing the following lines:

   #!/bin/sh     /usr/sbin/tripwire --check

Make sure the script is owned by root and has permissions of 500 (r-x------) so it is executable only by root. This script invokes Tripwire and gets it to check the system s integrity according to the rules in the policy file, and using the database you just created as its baseline. When cron runs this script at 04:02 every day, its output is sent to root (or whomever is configured in the MAILTO variable in /etc/crontab ).

Updating the Tripwire Database

We ll test the script by running it now. Type /etc/cron.daily/run-tripwire on the command line as root, and check that Tripwire runs successfully. Carefully examine the output produced; you should see that Tripwire has spotted the addition of the run-tripwire script to /etc/cron.daily and flagged it as a critical change.

To stop Tripwire from reporting this change (which you made and know is okay) as a policy violation every time it runs, you need to update Tripwire s database. You do this by running tripwire --update , specifying a Tripwire report file that you wish to use for the update. To see what files are available, run ls -ltr /var/lib/tripwire/report; choose the last report listed, as this will be the most recent one.

The command to run (all on one line) is then as follows:

   # tripwire --update --twrfile /var/lib/tripwire/report/rh9-20030209-040304.twr

Replace the report filename with the most recent .twr file on your system. This will produce a text file and start vi for you so you can edit the file. Each proposed database update is tagged with [x] , and if you don t want the update to be made, simply delete the x . If we don t want to use vi , add --visual gedit to the command, and Tripwire starts the graphical editor instead.

When you exit the editor, you re asked for the local passphrase, and then updates are applied to the database. Subsequent Tripwire integrity checks should no longer warn you about the change to /etc/cron.daily .