Monitoring for Intrusion Attempts

Unfortunately, even systems that are very well maintained , with good account and password policies and no unnecessary servers running, are sometimes compromised. Knowing how to spot an intrusion can be critically important to minimizing the damage from such an event. There are several intrusion-detection tools available for Linux, and there are also symptoms for which you can look to help you identify a compromised computer.

Intrusion-Detection Tools

Crackers who break into computers frequently alter the system's configuration in some way. Examples of changes include defaced Web pages, modified password files with new accounts to simplify future break-ins, modified program files that do things other than what you expect, and hidden surprises in just about any configuration or data file. Unfortunately, it's impossible to predict precisely what files a cracker will modify. This is part of what makes a successful intrusion so serious: Because you don't know precisely what was done to your system, you can't trust any of it any longer. The safest course of action is to completely delete all data on the computer and re-install it or restore it from a backup made before the compromise. (The upcoming section, "What to Do if You Discover an Intruder," covers this topic in more detail.)

The fact that intruders modify files, however, can be used as a way to detect them. The idea is to record information on critical system files, like /etc/passwd and various files in /bin , in such a way that this information can't be modified. The information might be encrypted or stored on a removable medium, for instance. You can then compare your stored information against the critical files on a regular basis. If a file that should not have changed has changed, you should suspect an intrusion. (Of course, there are also innocent explanations for some changes, such as the legitimate addition of users causing changes to /etc/passwd .)

Using Package Databases

One tool that can be used in this endeavor already exists on most Linux distributions: Your package database. The Debian package system and RPM system both store a wide variety of information about all installed packages in package database files. You can use the --verify (or -V ) option to rpm to check an installed package against its original file contents, thus:

 #  rpm -V postfix  S.5....T c /etc/postfix/aliases S.5....T c /etc/postfix/ 

This output shows the names of files that have changed in some way from their original state. The string at the start of each line of output indicates the information that no longer matches. For both of the files reported in this example, the S indicates that the file size has changed, the 5 means that the MD5 sum is different, and the T refers to an altered file modification time. In this particular case, these changes are not a problem, because both the files in question are configuration files that should be different than what was delivered with the original package. If the Postfix executable had changed, though, there would be cause for concern.

On Debian systems, dlocate provides similar functionality, but as of Debian 2.2, this tool isn't part of the standard system. Once you've installed it, you can issue a command like the following:

  #   dlocate -md5check postfix  

This checks the postfix package's MD5 sums, and reports whether this sum is correct for each file in the package.

In addition to checking just one package, you can check all your installed packages on an RPM-based system by typing rpm -Va . The resulting output is likely to contain hundreds of lines, mostly referring to changed configuration files and other innocent alterations. You may want to redirect the output to a file or pipe it through more or less so that you can more readily examine the output.

One drawback to using rpm or dlocate in this way is that it doesn't allow you to track changes to configuration files made after the package was installed. Because you're likely to make such changes, package tools aren't sensitive to intruders who might modify your system's unique configuration files. Another problem is that an intruder need only add software via your package manager to hide that fact from you. For instance, if an intruder wanted to change /bin/bash on an RPM-based system, the cracker could do so by installing a new bash RPM package, and rpm -Va wouldn't detect the change. For these reasons, it's best not to rely upon a package manager as your sole intrusion-detection tool. It's worth mentioning as something you might use if you believe you have been compromised. Although you can't be certain that a system hasn't been compromised if rpm -Va doesn't turn up any problems, you can be suspicious if it turns up changes to critical binary files.

Using Tripwire

A tool that's designed to detect intruders is called Tripwire ( This program ships with many Linux distributions, or you can download it from its Web site. A version that ships with your distribution is far easier to set up, because it will be preconfigured for your distribution's particular mix of files and file locations. Tripwire works by storing information on various files in its database. In this respect, Tripwire is similar to RPM or Debian package management tools. Tripwire was designed as a security tool, though, so it has certain advantages over package management tools for this purpose. Most importantly, Tripwire can be configured to store information on an arbitrary set of files at some point after they're installed, so you can change configuration files and then record their information. Tripwire can also use encryption to reduce the odds of a miscreant modifying the Tripwire database. For better security, you can store the Tripwire database on a read-only or removable medium, and mount it only when you want to perform a database check or update.

Tripwire runs in one of four different modes:

  • Database generation ” The first run of Tripwire initializes its database. You do this by typing tripwire -initialize after editing its configuration file. This process can take some time to execute, because it must compute hashes of all the files it's to monitor. The resulting database file may be placed in the databases subdirectory under the current directory, but it should normally be moved to /usr/lib/tripwire/databases , which ideally should be a read-only filesystem after you've created the database file.

  • Database update ” If you make changes to your system, you can use the database update mode by typing tripwire -update / path /to/file , where /path/to/file is the file whose entry you want to update.

  • Interactive update ” If you make substantial changes to your system, such as adding a large package, you can type tripwire -interactive . This enters an interactive mode in which the program reports files that have changed and asks if you want to update the entry.

  • Integrity checking ” This is the default mode for Tripwire; you run it by typing tripwire with no options. This mode checks your files for changes and reports them. You might run this check on a daily basis in a cron job.

The Tripwire configuration file is /etc/tripwire/tw.config . Like many configuration files, pound signs ( # ) indicate comments in this file, and text after these characters is ignored. Other lines indicate directories that Tripwire is to check. The format of these lines is as follows :

 [!=]  entry  [  select-flags   template  ] 

The meaning of each component is as follows:

  • Inclusive prune ( ! ) ” An entry that's preceded by an exclamation mark indicates that the specified directory or file is not to be examined. In the case of directories, all its subdirectories are ignored, as well.

  • Exclusive prune ( = ) ” This code is used on directories that should be checked, but whose children should not be checked. It's often used on directories like /home . When an exclusive prune is indicated, Tripwire tells you that the directory has changed if files or directories in it have been added or deleted, but Tripwire won't identify which files have been added or deleted.

  • entry ” The entry is the name of a file or directory that's to be checked, such as /etc or /usr . If you list a directory, all its subdirectories are scanned as well, unless they reside on separate filesystems. Thus, if /usr/local is on a different partition than /usr , you'd need to create entries for both /usr and /usr/local to scan the entire tree.

  • select-flags ” You can tell Tripwire what types of changes to report by specifying select-flags . These take the form [+-] [pinugsamc123456789]... . The + or - indicates that Tripwire should or should not report changes, respectively. Each subsequent character indicates an attribute to check: p for permission changes, i for inode number changes, n for number of links, u for user ID of the file's owner, g for the group ID of the file's owner, s for file size, a for access timestamp, m for modification timestamp, c for the inode creation timestamp, and through 9 for various hashes and checksums.

  • template ” Instead of specifying a select-flags entry, you can use a shorthand template . The default is R , which stands for +pinugsm12-ac3456789 . Other template entries include L ( +pinug-sacm123456789 ), which is useful for log files; N ( +pinugsamc123456789 ), which is very time-consuming but thorough; and E ( -pinugsamc123456789 ), which ignores everything.

Once you've set up a Tripwire configuration file, you should run the program in database generation mode. This produces a file in the databases directory. Subsequent runs of Tripwire expect to find the file in /usr/lib/tripwire/databases . Because this file is so sensitive, you should take steps to protect it against modification. Some possibilities include the following:

  • You can store the database file on a write-protected removable medium, such as a write-protected floppy (if the file will fit; it may not) or CD-ROM, and permanently mount that medium at /usr/lib/tripwire/databases . This is the safest approach, but it may be the least convenient . A variant is to leave the medium unmounted and mount it only when you run a check. If you run checks in cron jobs, this may be inconvenient.

  • You can create a small partition that you mount in a read-only manner to house the Tripwire database file. There are several possible variants on this. For instance, you might use a write-protected CD-ROM disc image or a filesystem type for which Linux has read-only but no read-write support. (The latter would obviously require the intervention of another OS.) These variants can make it more difficult for an interloper to modify your Tripwire database file, but a truly competent and determined cracker could probably overcome these measures.

  • Back up your Tripwire database file to a removable medium and manually compare it to the stored version every now and then. If the stored copy has changed, that may indicate a break-in. If you use this approach, you should compare the two files before you make any modifications yourself, then replace the backup with the updated database file.

  • Some Tripwire packages support encryption, usually through a third-party utility. When so used, an interloper would have to know your encryption password to modify the database.

If you take reasonable precautions , you can be quite confident in your Tripwire database's veracity, and therefore in the trustworthiness of your computer. It's important to note, though, that Tripwire is best used when it's installed on a fresh Linux installation. If you install Linux, then wait a day or two, then install Tripwire, you'll learn of changes to your system made after Tripwire's installation, but if your system was invaded before that time, Tripwire won't detect that fact.

General Intrusion Detection Procedures

In addition to using intrusion detection tools like Tripwire, there are various actions you can take and procedures you can follow to help you detect an intrusion. These include:

  • Monitor log files ” Log files, most of which appear in the /var/log directory tree, contain a great deal of information about server activity. As described earlier, monitoring them manually can be tedious at best, but with the help of a tool like SWATCH, you may be able to spot at least some suspicious activity, such as local logins by users who you know to be on vacation thousands of miles away.

  • Monitor system health ” If a server suddenly begins behaving strangely, this could be a sign of an intrusion, because crackers frequently damage your configuration in making their changes. You shouldn't be too alarmed by a sudden malfunction, though; there are many other less sinister possible causes. The possibility of an intrusion is worth investigating, though.

  • User complaints ” Crackers sometimes break in via ordinary user accounts, and just as a cracker may damage your system's configuration, a cracker may damage a user's settings. As with general system health issues, there are other possible explanations for user complaints like "forgotten" passwords or mysteriously altered shell defaults, but you might want to check details like the change dates on configuration files and passwords to see if these might be suspicious.

  • Strange files ” You may notice peculiar files appear on your computer. These are frequently the detritus of intrusion scripts, or perhaps your original program files under new names, called by replacement scripts to help mask the replacements ' presence. Intruders also sometimes delete or alter log files, so suspicious gaps in your log files can be a clue to an intrusion.

  • Unusual network traffic ” If the amount of network traffic a server sees suddenly increases , one possible explanation is that your system is under attack or is being abused. Of course, it's also possible that your system has simply jumped in popularity. For instance, a link to a small Web site on the popular Slashdot ( frequently swamps a small Web site. (This effect is so well known that it's spawned a word ”a site so affected is said to be Slashdotted. ) You might also notice unusual connections coming from a computer. For instance, if a Web server is used only as a Web server, logs on other computers on your network showing Telnet attempts from the Web server could indicate that the Web server system has been compromised.

Ultimately, it's up to you to spot unusual events. Most network intrusions are the work of script kiddies ”crackers with little skill who work from intrusion scripts created by others. (Some people prefer not to call script kiddies crackers, reserving the latter term for more skilled computer miscreants.) The scripts that script kiddies deploy frequently leave identifiable traces behind. Unfortunately, each intrusion script leaves behind its own unique fingerprint of changes, so it's impossible to give a short list of files to watch. Security Web sites frequently include discussions of the symptoms of particular intrusion methods , so using such a site's search function can help you identify the nature of an intrusion.

It's also important not to overreact or jump to the conclusion that your system has been cracked. Hardware failures, software misconfiguration, and bugs can all produce symptoms that resemble those of intrusions.

What to Do if You Discover an Intruder

What should you do if you detect an intruder? The general recovery steps are as follows:

  1. Disconnect the computer from the network ” A compromised computer might be used to cause problems for others or to infect other systems on your own network. If your cracked system contains sensitive data, the longer it's networked, the more likely it is your sensitive data will be stolen.

  2. Verify the nature of the compromise ” You should verify that your problem is due to a security breach. As noted earlier, many less sinister problems can be mistaken for a break-in. You should also try to identify the route that the attacker used to gain entry to your system. Even if you clean the infection, if you don't lock the door the intruder used to get in, the intruder will be able to gain entry in the same way again. Unfortunately, identifying the specific security problem may be easier said than done, so you may have to settle for upgrading your software and increasing your security level generally .

  3. Back up vital data ” If your system isn't backed up routinely or hasn't been backed up recently, you should back up regular user data. You may also want to create a backup of the entire compromised system. You can peruse this backup later, and it might become important evidence if the break-in becomes a criminal matter.

  4. Restore a clean system ” Unfortunately, cleaning out only infected files is not safe. You might get most altered files but miss something important, thus leaving the intruder a way back in. You should wipe your hard disk clean, or at least the partitions on which Linux itself resides; you might be able to leave /home untouched. You can then re-install Linux from scratch or restore it from a backup that you're sure was made prior to the intrusion. Do not configure your system's network functions at this point, though; leave it disconnected from the network.

  5. Restore data files ” If you wiped out the entire hard disk in Step 4, you should restore the user data you backed up in Step 3. You should also alter your configuration to suit your needs, if you re-installed everything from scratch in Step 4.

  6. Correct the security problem ” You should correct whatever problem existed that allowed the intruder entry to your system, as identified in Step 2. You may also want to take steps to improve security generally, such as installing Tripwire if it wasn't installed already, setting up a local firewall as described in Chapter 25, and so on.

  7. Return the system to the network ” After you've recovered the system and fixed its problems, you can restore it to its normal duties .

There are other steps you can take along the way, if you like. For instance, if you can trace the intrusion back to a specific remote site, you might try contacting that site's administrator. Crackers like to use several systems as stepping-stones to their true targets, so there's a good chance that the site that launched an attack on you was itself a compromised system. If your losses due to the intrusion were substantial, you can contact the FBI or other law enforcement agencies; however, the amount of cracking activity and difficulty of obtaining convictions means that you're unlikely to see much action unless your case is very clear-cut or involves substantial losses. (In the United States in 2002, losses must exceed $5,000 before the FBI will take notice.)

Advanced Linux Networking
Advanced Linux Networking
ISBN: 0201774232
EAN: 2147483647
Year: 2002
Pages: 203

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: