Intrusion Detection in Linux Systems

How Linux deals with Intrusion Detection

7. Intrusion Detection

Intruders are constantly attempting different mechanisms to attack your system. You must be able to detect these varying attempts, and know what to do when they happen. You should also be able to distinguish the normal operating conditions from an actual attack.

You must be able to determine things like whether or not there really was an intrusion, to what extent the attack occured.

7.1 What is Intrusion Detection?

Intrusion Detection is the method in which a security administrator uses to detect the presence of an unauthorized intruder. An Intrusion Detection System (IDS) are the combination of tools that a security administrator uses to detect the intrusion. Briefly, the available types of intrusion detection include:

• Network Based Intrusion Detection - These mechanisms typically consist of a black box that sits on the network in promiscious mode, listening for patterns indictive of an intrusion.

• Host Based Intrusion Detection - These mechanisms typically include auditing for specific events that occur on a specific host. These are not as common, due to the overhead they incur by having to monitor each system event.

• Log File Monitoring - These mechanisms are typically programs that parse log files after an event has already occured, such as failed login attempts, etc.

• File Integrity Checking - These mechanisms typically check for trojan horses, or files that have otherwise been modified, indicating an intruder has already been there. The Red Hat Package Manager, RPM, has this capability, as does the well-known Tripwire package.

7.2 General Indications of Intrusion

Being capable of detecting an intrusion is as important as being able to stop it once it happens. It is important that you are able to detect the subtle signs left by an intruder during his attack of your system.

Suspicious signs of intrusion include at least the following:

User Indications

• Failed log-in attempts
• Log-ins to accounts that have not been used for an extended period of time
• Log-ins during hours other than non-working hours
• The presence of new user accounts that were not created by the system administrator
• su entries or logins from strange places, as well as repeated failed attempts

System Indications

• Modifications to system software and configuration files
• Gaps in system accounting that indicate that no activity has occurred for a long period of time
• Unusually slow system performance
• System crashes or reboots
• Short or incomplete logs
• Logs containing strange timestamps
• Logs with incorrect permissions or ownership
• Missing logs
• Abnormal system performance
• Unfamiliar processes
• Unusual graphic displays or text messages.

File System Indications

• The presence of new, unfamiliar files or programs
• Changes in file permissions
• Unexplained changes in file size. Be sure to analyize all your system files, including those in your $HOME/ directory such as $HOME/.bashrc for modified $PATH entries, as well as changes in system configuration files in /etc
• Rogue suid and sgid files on the system that do not correspond to your master list of suid and sgid files
• Unfamiliar file names in directories
• Missing files

Network Indications

• Repeated probes of the available services on your machines
• Connections from unusual locations
• Repeated login attempts from remote hosts
• Arbitrary log data in log files, indicating attempt at creating either Denial of Service, or crash service

7.3 General Methods for Detecting Intrusions

In order to determine if an intruder has violated your system, you must be familiar with the normal system administration tools, and be able to use them to find the ``footprint'' a cracker may have left behind. This procedure can be relatively easy, or practically impossible, depending on how much preparation you have done, as well as the stage you've detected the intruder, and how skilled the intruder is.

There are pointers throughout this document that list the various tools available. Some of the tools and methods you should become familiar with include:

• Log file analysis. Be sure to see the User Security section for information on syslog(8) which is responsible for logging many system events that are helpful in tracking connections to your system, as well as local system events.

• Become familiar with the last(1), lastcomm(1), and netstat(8) commands. These are available to show valuable information about the users, commands, and connections on your system. More information on these commands are available in the User Security section.

• Look for signs of physical intrusion.

• Ensure that the software you are using to search for the intruder hasn't itself been compromised. Do not place all your trust in the tools you are using, and the output they produce. Consider placing a set of secure binaries on external media that can be used later, with confidence. See the http://www.txdirect.net/users/mdfranz/trinux.html package for a starting point.

• Follow the guidelines provided by CERT in this document ftp://info.cert.org/pub/tech_tips/UNIX_configuration_guidelines

• Check other local systems that may have been used to attack at yours

• Check for systems at remote sites that may be involved or affected

• Investigate unauthorized hardware attached to the network

• Observe your systems for anything unusual, and certainly investigate anything you find

• Notify your incident response team if you find something that could have been performed by an unauthorized user

• Use the network monitoring tools. There are also several nifty network monitoring tools there that are also very helpful. It is important to keep aware of the status of your network, so you know when to be alerted to a specific event. See the Network Monitoring section for more information.

7.4 Intrusion Detection Tools

There are many intrusion detection tools available for Linux, and many new tools are constantly becomming available. While the majority of the tools are host-based intrusion detection tools, there are a number of network-based tools as well.

Host Based Detection Tools

• Tripwire
• Make use of the available tools. There are several tools available to detect when someone is portscanning your network. Start with http://www.psionic.com/abacus/abacus_sentry.html which is the Sentry intrusion detection tool.

There are also several intrusion detection tools available at http://www.eng.auburn.edu/users/doug/second.html including a tool called klaxton which basically sets a trap for an intruder, then notifies you when some is ``doorknob rattling''.

7.5 Integrity Checking

A very good way to determine if you have an unwanted visitor is to check your local files for possible trojan horses, missing files, files that are larger or smaller than they are supposed to be, etc.

Fortunately, there are several tools that can verify the file integrity. Many Linux distributions use RPM for their package management, which inherently has integrity checking. Also available is the well-known program called tripwire.

7.6 Using tripwire

Tripwire runs a number of checksums on all your important binaries and config files and compares them against a database of former, known-good values as a reference. Thus, any changes in the files will be flagged.

It's a good idea to install tripwire onto a floppy, and then physically set the write protect on the floppy. This way intruders can't tamper with tripwire itself or change the database. Once you have tripwire setup, it's a good idea to run it as part of your normal security administration duties to see if anything has changed.

You can even add a crontab entry to run tripwire from your floppy every night and mail you the results in the morning. Something like:

                # set mailto
             MAILTO=kevin
             # run tripwire
             15 05 * * * root /usr/local/adm/tcheck/tripwire

will mail you a report each morning at 5:15am.

Tripwire can be a godsend to detecting intruders before you would otherwise notice them. Since a lot of files change on the average system, you have to be careful what is cracker activity and what is your own doing, which is a solid reason to keep track of the status of the binaries on your system.

A company called Visual Computing Corporation now apparently has been given exclusive rights to continue development of tripwire, originally developed at Purdue University. It looks to be so-far-so-good, as there is still a working version for Linux. You can find more information from them at http://www.visualcomputing.com

7.7 Using The Red Hat Package Mangaer

The Red Hat Package Manager (RPM) program includes the ability to verify all packages that it has installed on the system.

RPM has facilities for verifying that a package is not corrupt or has components missing. A program added or removed by a cracker will not match the original and RPM will generally report a verification failure.

Now, when your system is compromised, you can use the command:

                        root# rpm -Va

to verify each file on the system. See the RPM man page, as there are a few other options that can be included to make it less verbose. Keep in mind you must also be sure your RPM binary has not been compromised. RPM can also be combined with PGP to check a package's signature. Typical output might look like the following:

                          ..5....T /bin/login

should sound alarm bells. RPM produces the following useful output fields:

• S - file size changed
• M - file mode changed
• 5 - MD5 checksum failed
• U - file owner changed
• G - group changed

This means that every time a new RPM is added to the system, the RPM database will need to be re-archived. You will have to decide the advantages versus drawbacks. Also, keep in mind that it won't verify programs that RPM did not install.

Specifically, the files /var/lib/rpm/fileindex.rpm and /var/lib/rpm/packages.rpm most likely won't fit on a single floppy. Compressed, each should fit on a separate floppy. Consider storing this (as well as the actual /bin/rpm executable!!) on a Zip cartrige.

7.8 File System Guidelines

Intruders often either modify, delete, or replace existing files in order to either cover their tracks, assist them in gaining access, or to gather further information.

Ensuring the integrity of the files and programs on your system is vital in intrusion detection. Several means can be used to determine if files have been tampered with on your system:

• Look for suspicious files on your system, or even system files that may have been tampered with, or missing. You can find the list of the most recently modified files with the following command:

                      user@host# /usr/bin/find / -ctime -1 -print
  

  Read the File System Security section for tips on scanning your filesystem for changed files, as well as setuid and sgid files.

• Verify the integrity of the files. If you are prepared, you can use your Red Hat RPM database, or Tripwire database stored on external media at this time to verify the integrity of the most important files on your system.

7.9 Physical Intrusion Detection

Intruders may attempt to breach your network's by physical infitration as well as via the network. Keep in mind that one system can be used to penetrate many others, so securing one machine is as important as securing another.

The first thing to always note is when your machine was rebooted. Since Linux is a robust and stable OS, the only times your machine should reboot is when YOU take it down for OS upgrades, hardware swapping, or the like. You should always investigate machine reboots.

Check for signs of tampering on the case and computer area. Although many intruders clean traces of their presence out of logs, it's a good idea to check through them all and note any discrepancy.

7.10 Packet Sniffers

One of the more common ways intruders gain access to multiple systems on your network is by employing a packet sniffer on a already compromised host. This software-based ``sniffer'' just listens on the Ethernet port for things like ``password'' and ``login'' and ``su'' in the packet stream and then logs the traffic after that. This way, attackers gain passwords for systems they are not even attempting to break into. Clear text passwords are very vulnerable to this attack.

An attacker doesn't even need to compromise a system to do this, they could also bring a laptop or PC into your building and tap into your net.

Using SSH, or other encrypted password methods, thwarts this attack. Things like APOP for POP email accounts also prevents this attack. (Normal POP logins are very vulnerable to this, as is anything that sends clear text passwords over the wire.)

If you are using syslog to send your data to a central log server, consider that the data is sent in clear text, and much information can be gathered from this data. Consider using a secure implementation of syslog, which encrypts and compresses the data before it is sent. See the Using Syslog section for more information on configuring syslogd(8) securely.