|< Day Day Up >|
Host-Based Intrusion Detection
We have spent a lot of time on network-based intrusion detection. However, there are other ways of finding intrusion attempts. One alternative method is to load software to look for signs of intrusion on the system itself. If a machine has been exploited, often certain system files will be altered. For example, the password file may be changed, users may be added, system configuration files may be modified, or file permissions might be altered. Normally these system files shouldn't change much. By looking for modifications in these files, you can detect an intrusion or other unusual activity.
This method of intrusion detection can be much more accurate, producing fewer false positives since it doesn't go off unless a system is actually affected. It is a little more trouble to maintain since you have to load software on each system to be protected, but it might be well worth the time and effort to use both host-based and network-based intrusion detection to protect mission-critical systems.
Advantages of Host-Based Intrusion Detection Methods
Disadvantages of Host-Based Intrusion Detection Methods
Tripwire is another great example of open source software that has made the transition to a commercial platform. Tripwire was originally purely open source. Eventually, the founders formed a company to sell and support it commercially. However, they took the original code base and released it under the GPL license so that development could continue in the open source community. The open source version has been updated from version 2.2.1 released in October of 2000 to the current version of 2.3.
There are significant differences between the commercial and the open source versions. The biggest is that the commercial version isn't open source and supports more platforms. The open source version currently is available only on Linux, while the commercial version is available on several platforms including Windows. Another difference is that the commercial version comes with a program called twagent, which is a utility for managing multiple installations of Tripwire. The commercial version also has a nice GUI for managing your databases and configurations.
Both versions of Tripwire operate by creating a database of baseline attributes of important files you want to track, so you can check the actual attributes at any given time against the baseline to see if anything has changed. This is good for keeping track of your system's binary files. One of the favorite tricks of hackers once they've gotten into a system is to replace key binary files with trojanized versions of their own. That way, when you use commands like ls or ps, you don't see their illicit files or processes running. You can also use Tripwire during a forensic investigation to find out where an intruder has been; it's like following digital footprints.
This completes the Tripware installation process.
The final step before running Tripwire is to set your policy. The policy file is a very important file for Tripwire operation: it tells Tripwire what files to keep an eye on and what level of detail to go into. You can find the main policy file, twpol.txt, in the main Tripwire directory. This is not the policy file itself but a copy of the encrypted version that the program actually uses. For better security, you should make a copy and delete the unencrypted copy, twpol.txt, once you have set and tested your policy.
The policy file contains some system variables at the top, and then it has a listing of various files and directories and the policy directives for them. These directives are represented by either code letters or variable names. They are called property masks and represent the properties that Tripwire is tracking. Table 7.4 lists the items that can be tracked for each file and their code letters.
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 properties 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 property 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.
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 initial 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.
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 signature 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 policies 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.
|< Day Day Up >|