Host-Based Intrusion Detection 229 Tripwire policies operate on the concept of ignore flags. You can configure Tripwire to keep track of or ignore different file properties. You use a + (plus sign) to track proper- ties and a – (minus sign) to ignore them. The format for the policy file statement is as follows: file/directory name -> property mask; For example, this line in the policy file: /etc/secretfile.txt -> +amcpstu; would cause Tripwire to notify you any time the last access time, creation or modification time, permissions, ownership, or file size and type changed on the file secretfile.txt in /etc. There are also several predefined property masks. Table 7.5 lists these template prop- erty masks and their effects. These predefined variables fit the behavior of different sets of files. For instance, you may want to use $Readonly for your key configuration files since their access dates will be changing when programs use them, but you don’t want the size or content to change. You could use $Growing for your log files, since they will be constantly growing (or should be anyways). The policy configuration file also defines some variables that are combinations of the above presets with a few additions or subtractions. These give you a way to quickly set policies for various different classes of files. You can change them slightly if you want to ignore or examine more things. Listing 7.3 shows these variables from the policy file. Table 7.5 Template Property Masks Property Masks Effects $Readonly +pinugtsdbmCM-rlasSH $Dynamic +pinugtd-srlbamcCMSH $Growing +pinugtdl-srbamcCMSH $Device +pugsdr-intlbamcCMSH $IgnoreAll -pinugtsdrlbamcCMSH $IgnoreNone +pinugtsdrlbamcCMSH Howlett_CH07.fm Page 229 Thursday, June 24, 2004 12:17 PM 230 Chapter 7 • Intrusion Detection Systems Listing 7.3 Property Mask Variables SEC_CRIT = $(IgnoreNone)-SHa ; # Critical files that cannot change SEC_SUID = $(IgnoreNone)-SHa ; # Binaries with the SUID or SGID flags set SEC_BIN = $(ReadOnly) ; # Binaries that should not change SEC_CONFIG = $(Dynamic) ; # Config files that are changed infrequently but accessed often SEC_LOG = $(Growing) ; # Files that grow, but that should never change ownership SEC_INVARIANT = +tpug ; # Directories that should never change permission or ownership SIG_LOW = 33 ; # Non-critical files that are of minimal security impact SIG_MED = 66 ; # Non-critical files that are of significant security impact SIG_HI = 100 ; # Critical files that are significant points of vulnerability Below the property masks, policies are set for the various files and directories on the system. You can start with the default policy file and see how it works for you. Take time to peruse the file to see which files are being tracked. Once you are satisfied, save the file and exit. You are ready to run Tripwire. Initializing Your Baseline Database The first step in running Tripwire is to set up your baseline database. This creates the ini- tial list of signatures against which the policies will be used. Remember, running this after you have suspect files on your system does you no good; you need to create your baseline database before you have any security problems, ideally just after your system is installed and configured. To establish your initial file database, use the following command: tripwire –m i –v The –m switch specifies which mode to run in, in this case i for initialize. The –v switch gives verbose output so you can see what’s happening. Tripwire audits all the files specified in your policy file, creates the database in the ./database directory, and encrypts it using your site pass-phrase. In order for Tripwire to be truly secure, you should make a copy of your baseline database to some secure offline media—floppy disk (if it will fit), CD, or tape. If you store it locally online, there is always a possibility that it could be altered, although Tripwire has some protections against this. Howlett_CH07.fm Page 230 Thursday, June 24, 2004 12:17 PM Host-Based Intrusion Detection 231 Checking File Integrity This is the main mode you will run Tripwire in once you have set it up. It compares the current attributes of the files specified with the ones in the Tripwire database. The format is: tripwire –m c file.txt where you replace file.txt with the path to the file or directories you want checked. It will verify the attributes of that file according to the specifications of the policy file and return with a report of any changes. Updating the Database As you fine-tune your policy and make major system changes, you will want to update your database so it accurately reflects the valid state of those files. This is important so that not only will new files and directories be added to your database, but false positives will be eliminated. Do not update your database if there is any chance that your system has been compromised. This will invalidate those signatures and make your Tripwire database useless. You can update select directories; after all, some things like system binaries should rarely change. You update the Tripwire database using this command: tripwire –m u –r path-to-report You need to replace path-to-report with the name and path of the most recent report file. Running this command will show you all the changes that have occurred and which rules detected them. There will be an X in boxes by files in which Tripwire has detected changes. If you leave the X there, Tripwire will update the signature for that file when you exit the file. If you remove the X , Tripwire will assume that the original signa- ture is correct and not update it. When you exit, Tripwire will perform these changes. You can specify –c in the command to skip doing the preview and to have Tripwire simply make the changes for the files it has detected. Updating the Policy File Over time, you will learn what rules are not generating valid alerts and will want to delete them or change the property masks on them. You may want to tighten property masks for some files as well. Make your changes to the Tripwire policy file, save it, and then issue the following command to have Tripwire update the policy file: tripwire –m p policy-file.txt where you replace policy-file.txt with the new policy file. Tripwire will ask for your local and site pass-phrases before updating the policy. Once you have your Tripwire poli- cies sufficiently fine-tuned, you can create a cron job and have it run daily (or however often you want) to check your file systems looking for intruders. Howlett_CH07.fm Page 231 Thursday, June 24, 2004 12:17 PM Howlett_CH07.fm Page 232 Thursday, June 24, 2004 12:17 PM 233 C HAPTER 8 Analysis and Management Tools The tools discussed so far give you a lot of useful information to help you fix your network security problems. But the problem with these wonderful programs is that they can some- times generate too much information. A single Nessus scan of a sizable network can gen- erate a report that is hundreds of pages long. An active Snort sensor can output thousands of alerts a day. Even the lowly firewall might send out log notices on an hourly basis. Keeping track of all of this security information can be a full-time job. In fact, at larger companies, it often requires a small staff just to track and analyze the security data. With all the data these tools generate, you can go from being uninformed to informa- tion overload very easily. This can be worse than being in the dark regarding your security situation. System administrators can suffer from “analysis paralysis”—feeling like they don’t know where to start. For many overwhelmed technical managers, the solution is to do nothing at all, or to put the security issues on the back burner until they have time to deal with them. Of course, that time never seems to come. Chapter Overview Concepts you will learn: • Managing server log files • Using databases and Web servers for security data • Analyzing IDS data • Managing vulnerability scan data • Running a vulnerability scan management system Tools you will use: Swatch, ACID, NPI, and NCC Howlett_CH08.fm Page 233 Thursday, June 24, 2004 9:54 PM 234 Chapter 8 • Analysis and Management Tools To avoid this situation, you need tools to help organize your security data and priori- tize the action items. Many commercial packages assist in this task, including HP Open- View, BMC NetPatrol, and NetIQ. Fortunately for the budget-impaired, there are also some great open source packages available. While these open source applications are not strictly security tools in that they are not actively polling or protecting machines on your network, they are every bit as important as your network scanners and intrusion detection systems. Because if you can’t see the forest for the trees, you are no better off than you were before. One example of the challenges in analyzing security data is the server message logs. Most servers, UNIX and Windows alike, maintain logs on various activities going on in the system. Most of this activity is innocuous, like services starting up, user access, and so on. Linux, for example, keeps the system logs in the /var/log directory. Usually, there are two general logs—syslog and messages— along with several other more specific logs. These text files show you all the things going on in the background of the system. Listing 8.1 shows the typical contents of a Linux messages file. Listing 8.1 Linux Messages File Aug 17 04:02:06 earth syslogd 1.4.1: restart. Aug 18 21:07:57 earth sshd(pam_unix)[17904]: session opened for user john by (uid=502) Aug 18 21:12:39 earth su(pam_unix)[17960]: session opened for user root by john(uid=502) Aug 18 21:12:52 earth su(pam_unix)[17960]: session closed for user root Aug 18 21:13:44 earth sshd(pam_unix)[18008]: session opened for user john by (uid=502) Aug 18 21:14:02 earth sshd(pam_unix)[18008]: session closed for user john Aug 18 21:23:21 earth su(pam_unix)[18482]: session opened for user root by john(uid=502) Aug 18 21:24:12 earth su(pam_unix)[18482]: session closed for user root Aug 18 21:39:00 earth su(pam_unix)[10627]: session opened for user root by john(uid=502) Howlett_CH08.fm Page 234 Thursday, June 24, 2004 9:54 PM Analysis and Management Tools 235 Aug 18 21:44:57 earth httpd: httpd shutdown succeeded Aug 18 21:44:58 earth httpd: httpd: Could not determine the server's fully qualified domain name, using 127.0.0.1 for ServerName Aug 18 21:45:00 earth httpd: httpd startup succeeded Aug 19 23:39:02 earth sshd(pam_unix)[13219]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=tayhou-tnt-9-216-40-228-250.isp.net user=john Aug 22 10:31:14 earth sshd(pam_unix)[16205]: session opened for user tony by (uid=500) Aug 22 10:31:20 earth su(pam_unix)[16240]: session opened for user root by tony(uid=500) These messages are useful for debugging your system or troubleshooting a new program installation. You can see the details for each program or process that starts on your system. You can also see if there are any problems. In this example, you can see that the httpd process, the Web server, shut down. The next line says the problem is with the domain name set for the server. In this case, an IP address has been set incorrectly as the host name. Log files also contain information that is of interest from a security standpoint. Cer- tain activities are often the precursor of an attack in progress. Failed login attempts can be one of these signs. In Listing 8.1 you can see the user “john” had a failed login. It even tells where John was trying to log in from—an address owned by Isp.net. If it was just a single failed attempt and you knew John used Isp.net, then you would probably not worry about this entry. It was probably just John mistyping his password. However, if you saw multiple failed logins or this one was coming from an unfamiliar address, you would want to check into it further. Another sign of something going wrong is servers rebooting them- selves at strange times. These are some of the things that can show up in logs files that would warrant your attention. In an ideal world, you would review all your log files on a daily basis. Unfortunately, most of us don’t have time to do this even weekly, if at all. There is just too much informa- tion in these files to easily be able to find the data that’s important to us. Wouldn’t it be great if there was a helper program that looked for these kinds of things and let us know when they came up, so we could react in a timely manner, rather than a few days or a week later? Well, as it happens, there is an open source program that does just that. Howlett_CH08.fm Page 235 Thursday, June 24, 2004 9:54 PM 236 Chapter 8 • Analysis and Management Tools Swatch stands for Simple watcher or Syslog watcher, depending on whom you ask. Either way, Swatch is a helpful program that does your log watching and alerts you only when things that you are specifically looking for get logged. Swatch is a Perl program that regularly sweeps the main log files and looks for certain key words that you can define. It can be run in the background as a daemon or as a cron job. You can configure Swatch to notify you of any events in the messages or syslog log files that might indicate a security problem. However, Swatch can also be used to flag just about any kind of activity: a cer- tain program being used, a certain user logging in, or anything that might appear in a log file. Swatch can also be configured to watch application-specific log files instead of the general log files that it does by default. Returning to the security uses of Swatch, certain events that are logged have signifi- cance from a security standpoint. The default items that Swatch looks for are a good start. • Bad logins. Criteria: The words Invalid, Repeated, or Incomplete appear in the messages file. • System crashes. Criteria: The words panic or halt appear in the log files. • System reboots. Criteria: The banner of your OS should only appear in the log files when you reboot. Here are some other security-specific things that you might want to have Swatch look for. • Snort or Nessus messages. If you are logging your Snort data to a syslog file, you can have Swatch search for occurrences of snort. This will appear every time a Snort alert is generated. Swatch: A Log Monitoring Program Swatch Author/primary contact: Todd Atkins Web site: swatch.sourceforge.net/ Platforms: Linux, most UNIX License: GPL Version reviewed: 3.0.8 Mailing lists: Swatch-announce Primarily for version updates and new releases. Does not take posts. Subscribe at list.sourceforge.net/list/listinfo/swatch-announce. Swatch-users For general help, questions, and development information. Subscribe at list.sourceforge.net/list/listinfo/swatch-users. Howlett_CH08.fm Page 236 Thursday, June 24, 2004 9:54 PM Analysis and Management Tools 237 • Use of a text editor. This might indicate that someone is on your system trying to make changes to configuration files. Of course, if you are on the system a lot using a text editor, this alert might generate too many false positives. • Uses of FTP, SSH, or Telnet. If someone is downloading or uploading files to your system, it could mean trouble. Also, if someone is logging in remotely, you will want to track this. However, if you are doing these activities frequently, it might create more noise that it is worth. Note: By default, Swatch is configured to look for terms specific to the Sun operating system. While some of these may be common to Linux and other UNIX- based operating systems, others are not. For example, when looking for a reboot on a Mandrake Linux system, you will want to replace the search terms Sun OS Release with Linux Mandrake Release . If you are using a different OS, use the term from your OS reboot message. To find this, do a reboot and then look in the messages file for a unique statement to search for. Installing Swatch 1. Swatch requires Perl 5 or higher. If you have a fairly new installation of Linux or BSD (less than a year old), then you should have a sufficiently current version. 2. Swatch also requires several Perl modules, which are add-on subprograms for the Perl language. These modules are Date::Calc, Date::HiRes, and Date::Format. The configuration process will tell you if you are missing these modules. To get them, you can check the Web site www.rpmfind.net to see if there is an RPM available for your distribution. If you used a Linux distribution, there is a good chance there are RPMs to load these modules on your distributions disks. If you don’t have an RPM for the Perl modules, you can use the Comprehensive Perl Archive Network (CPAN) system for downloading the required modules. (The CPAN system is a way to auto down- load required Perl libraries without a lot of hassle.) To do this, type the following command: cpan –i module-name where you replace module-name with Date::Calc or whatever module you are trying to load. Make sure you get the spelling and capitalization right and use both colons. You will have to do this three times—once for each required module above. The CPAN system will take care of contacting the central CPAN servers, downloading the module, and installing it for you. 3. Download the tar file from the book’s CD-ROM or the Sourceforge Web site and unzip it. Howlett_CH08.fm Page 237 Thursday, June 24, 2004 9:54 PM 238 Chapter 8 • Analysis and Management Tools 4. Since Swatch is a Perl program, the installation process is slightly different than the previous C-based programs. The sequence of commands to type is: perl Makefile.PL make make test make install make realclean Once those processes are done, Swatch is installed and ready to go. Configuring and Running Swatch Swatch is a command line utility and you start it by issuing a swatch command with var- ious settings after it. Table 8.1 lists and describes the swatch options. For example, running this command: ./swatch config-file /home/john/my-swatch-config daemon will run Swatch using the configuration file found at /home/john/my-swatch-config instead of the default config file. It will also run it as a background process or daemon. The above options may be issued alone or together. Table 8.1 Swatch Command Options Options Descriptions config-file filename Runs Swatch using the configuration filename indicated. The default is ./swatchrc if no option is given. restart-time time Restarts Swatch at the indicated time. Also can be used with a + to have it restart at a given elapsed time after the current time. This can be used to have it refresh the view of the log file it has. input-record-separator This statement followed by a regular expression tells Swatch to use the expression to delineate the boundaries between each input record and line in the log file. The default is a carriage return, but if your operating system uses something different, you can change it here. daemon Runs Swatch as a system daemon. Accomplishes the same thing as running Swatch with the & (ampersand) switch. Howlett_CH08.fm Page 238 Thursday, June 24, 2004 9:54 PM . File Aug 17 0 4:0 2:0 6 earth syslogd 1.4. 1: restart. Aug 18 2 1:0 7:5 7 earth sshd(pam_unix)[17904 ]: session opened for user john by (uid=502) Aug 18 2 1:1 2:3 9 earth su(pam_unix)[17960 ]: session opened. user=john Aug 22 1 0:3 1:1 4 earth sshd(pam_unix)[16205 ]: session opened for user tony by (uid=500) Aug 22 1 0:3 1:2 0 earth su(pam_unix)[16240 ]: session opened for user root by tony(uid=500) These. Swatch: A Log Monitoring Program Swatch Author/primary contact: Todd Atkins Web site: swatch.sourceforge.net/ Platforms: Linux, most UNIX License: GPL Version reviewed: 3.0.8 Mailing lists: Swatch-announce Primarily