Detecting a Host Intrusion


In the preceding section, we looked at protecting systems through controlling the network. If attackers cannot reach a system, in theory they cannot compromise it. All servers on a network, however, are there to offer a service. If a vulnerability exists in the code on which the service relies, it may be exploited by an attacker to gain access to the server.

Tools such as Snort and ACID can be used to look for exploit attempts within network packets. If the attacker is using a technique not yet known to these tools, the compromise may go undetected at the network level. In cases such as these, other techniques will have to be employed in an attempt to find possible exploits.

Log Files

One method for looking for traces of an intrusion is to look for clues in log files. Depending on the activity level of the server, this can be a Herculean task. If the attacker was a novice and left traces of his presence, possibly only one log entry in thousands may reflect that fact. If the attack is successful, deliberate modification of the log file could hide any sign of an intrusion.

Placing the log files on a remote syslog server can mitigate against this type of cleanup attempt. Tools such as logsurfer can help sift through the many entries looking for known patterns. The problem is, not all patterns are known, and in many cases the log files are tweaked to erase tracks.

The value of log files should not be dismissed as a valuable tool for detecting intrusions. What they can provide, in some cases, is early warning that an attack is being set up. A careful review of the logs can reveal abnormal login failures from unexpected sources or port scans from other systems. Such information should not be ignored. Repeated failures of a particular service may indicate knowledge of vulnerabilities with the code. A quick check for newer, patched versions should be done.

chkrootkit

As soon as a system is compromised, it is not uncommon for an attacker to install what is commonly known as a rootkit. A rootkit is essentially a backdoor environment that allows the attacker to continue to access the compromised system. Often this is done through replacement of known executables with modified versions. This permits the attacker to connect to the system through a more comfortable interface.

Detecting a rootkit can be very difficult. Knowing which executable has been replaced with a hacked version can be almost impossible.

The chkrootkit program has been made available for just such a task and is available for download from www.chkrootkit.org. As new rootkits are discovered, this utility is modified to allow it to detect the subtle nuances in hacked versions of known executables.

Once compiled for your system, the chkrootkit program can be run with the -h flag to receive a list of available options. When run with no flags, it will scan all the executables it knows of and generate a lengthy report of its findings. Portions of such a report are shown here:

 Athena:~ # ./chkrootkit ROOTDIR is `/' Checking `amd'... not found Checking `basename'... not infected Checking `biff'... not found Checking `chfn'... not infected Checking `chsh'... not infected Checking `cron'... not infected Checking `date'... not infected Checking `du'... not infected Checking `dirname'... not infected Checking `echo'... not infected . . . Searching for HiDrootkit's default dir... nothing found Searching for t0rn's default files and dirs... nothing found Searching for t0rn's v8 defaults... nothing found Searching for Lion Worm default files and dirs... nothing found Searching for RSHA's default files and dir... nothing found Searching for RH-Sharpe's default files... nothing found . . . Searching for LPD Worm files and dirs... nothing found Searching for Ramen Worm files and dirs... nothing found Searching for Maniac files and dirs... nothing found Searching for RK17 files and dirs... nothing found Searching for Ducoci rootkit... nothing found Searching for Adore Worm... nothing found . . . Checking `lkm'... chkproc: nothing detected Checking `rexedcs'... not found Checking `sniffer'... eth0: PF_PACKET(/usr/bin/snort) Checking `w55808'... not infected Checking `wted'... chkwtmp: nothing deleted Checking `scalper'... not infected Checking `slapper'... not infected Checking `z2'... chklastlog: nothing deleted Checking `chkutmp'... chkutmp: nothing deleted 

In the report produced on Athena, more than 100 lines of output were generated. As you can see from this listing, the machine is clean. As expected, however, the sniffer check found that eth0 was in promiscuous mode and that the responsible binary was /usr/bin/snort. Because we knew Snort was running, this was not a problem. If we found something unexpected, it may be an indication of an intrusion.

The chkrootkit utility can be very useful in detecting a number of known backdoors. It can also look for known behaviors of backdoors such as the sniffer example shown in this section. What it cannot guarantee, however, is protection from other modifications beyond its designed scope.

Advanced Intrusion Detection Environment (AIDE)

Tools such as chkrootkit are very good at detecting changes in applications they have been designed to check. Because new backdoor techniques are constantly being developed, however, countermeasures such as these are forever playing catchup.

One approach for detecting unauthorized changes to a system is to take a snapshot of its content on a regular basis. Comparing these snapshots over time can provide a time-lapse reconstruction of changes. Such is the approach taken by applications such as the Advanced Intrusion Detection Environment (AIDE).

TRIPWIRE

One of the first HIDS products available on Linux is called Tripwire. Both free and commercial versions are available. The free version of this tool is included in the SLES distribution.

This product delivers essentially the same functionality as AIDE. It is, however, multiplatform. Based on the architecture of your site, you may decide that you want a common tool for all platforms. In such cases, Tripwire would be an ideal candidate. More information on the Tripwire tool is available from the website at http://www.tripwire.org.


The AIDE utility is a file integrity checker. It does not know about different attack algorithms or how backdoors get implanted on a system. It does, however, know how to keep track of files and notice whether changes have been made.

The main strength of tools such as AIDE is their ability to detect changes in patterns. When a system is built from known, trusted media, it can be considered safe and unexploited. The moment the machine is placed on a network, it is potentially vulnerable to exploits. Before exposing the system, you must record selected characteristics of your files. You will therefore know what they looked like when they were in pristine condition. On a regular basis, you can then compare the same characteristics from the live system with your time-zero snapshot. Changes in the attributes might reflect a machine compromise.

This is essentially what AIDE permits you to do. The behavior of AIDE is controlled through its configuration file aide.conf, which contains three different types of directives.

The first line type can be used to set a number of configuration options. With these options, you can set path values for database, database_new, and report_url. Defining these values within the configuration file means they do not have to be defined on the command line.

Macro lines allow you to specify short forms to define which characteristics will be recorded for each file. Attributes such as permission, inode, ownership, time stamps, and hash values for files can be registered in the AIDE database.

The last line type contains directives regarding which portions of the directory structure will be present in the AIDE database. Directories are included in the list using regular expressions. These expressions can allow for portions of directories or even specific files to be ignored.

The following is a portion of the default aide.conf file, supplied with SLES, located in the /etc directory:

 # #    AIDE _Example_ Configuration # # # Configuration parameters # database=file:/var/lib/aide/aide.db database_out=file:/var/lib/aide/aide.db.new verbose=1 report_url=stdout warn_dead_symlinks=yes # # Custom rules # Binlib         = p+i+n+u+g+s+b+m+c+md5+sha1 ConfFiles      = p+i+n+u+g+s+b+m+c+md5+sha1 # # Directories and files # # Kernel, system map, etc. /boot                                 Binlib # watch config files, but exclude, what changes at boot time, ... !/etc/mtab !/etc/lvm* /etc                                  ConfFiles # Binaries /bin                                  Binlib /sbin                                 Binlib # Libraries /lib                                  Binlib # Complete /usr and /opt /usr                                  Binlib /opt                                  Binlib 

In this example, you can clearly see where a number of command-line parameters have been predefined. Also, the BinLib macro has been created to identify the file attributes we would like AIDE to track. A list of the attributes AIDE is capable of tracking is shown in Table 12.3.

Table 12.3. Tracking AIDE Attributes

ATTRIBUTE

DESCRIPTION

P

Permissions

I

Inode

N

Number of links

U

User

G

Group

S

Size

B

Block count

M

Modify time (mtime)

A

Access timestamp

C

Creation time (Ctime)

md5

Creates an MD5 sum for the file

sha1

Creates an sha1 checksum for the file

rmd160

Creates an rmd160 checksum for the file

tiger

Creates a tiger checksum for the file

R

Short form for the combination of p+i+n+u+g+s+m+c+md5

L

Short form for the combination of p+i+n+g+u

E

Checks for empty groups

>

Short form for the combination of p+u+g+i+n+s

crc32

Creates a crc32 checksum (if mhash is enabled)

haval

Creates an haval checksum (if mhash is enabled)

gost

Creates a gost checksum (if mhash is enabled)


AIDE can be invoked in four different modes, as listed in Table 12.4.

Table 12.4. AIDE Run-Time Modes

MODE

DESCRIPTION

--check

Performs an integrity check on the AIDE database

--init

Creates an initial database based on the aide.conf configuration

--update

Allows for updates to be accepted into the database for approved changes to the system content

--compare

Checks for differences between the databases pointed to by the database_new and database parameters in the configuration file


The --init version of AIDE needs to be run only once. It creates the initial database. Subsequent calls to AIDE should use the --check option. As an example, after configuring AIDE and initializing the database, we manually changed a file in our system. When we ran the check phase, AIDE generated the following:

 Athena:/var/lib/aide # aide -C AIDE found differences between database and filesystem!! Summary:s Total number of files=3679,added files=1,removed files=0, changed files=4 Athena:/var/lib/aide # 

Checking the resulting logs revealed this change:

 File: /etc/php.ini Size : 38307                      , 38330 Mtime:2005-04-14 03:24:41         , 2005-03-11 18:42:10 Ctime:2005-04-14 03:24:41         , 2005-03-11 18:42:10 Inode:181287                      , 181494 MD5  :EgKatoUTIIWvIAoBiXtOkg==    , 1tmORxHz6pAD1y5Nl8fPpw== SHA1:HY09wB3q6MXMepohZ+JkP46TKBk=,LF/6gYohtIPCJj3fZqhBh0puXfc= 

Though this is a simple example, it provides a fair amount of comfort that AIDE is capable of finding changes.

The AIDE tool was created to allow for a flexible system to provide a consistent and robust method for tracking changes to a server. It is important to remember that, as configured, the AIDE tool stores all its results within the filesystem. Given sufficient time, attackers may realize that AIDE is installed. This would give them ample opportunity to maintain the AIDE database, covering their tracks as they go.

It is imperative that copies of both the configuration file and the databases be kept on offline storage devices. If the databases are kept on read-only mount points, an attacker with root privileges could simply remount the volume, make changes, and switch it back again. Placing the information on CD is a good idea unless the CD is left in the burner. Multiple session CDs could be used to overwrite previous versions of the database. Additionally, leaving the CD in the drive might also allow an attacker to view the configuration file. Once the attacker has that information, he will know exactly where to place the exploit code to make it invisible to your scans.

Though much of this may sound paranoid, any information stored on, or accessible to, a compromised system must be considered tainted. By placing the AIDE files out of reach of the running system, you have a more reliable comparison snapshot.

It is also important to remember that the AIDE database will have to be maintained every time new applications are applied to the system. This includes patches to the operating system and its underlying services.



    SUSE LINUX Enterprise Server 9 Administrator's Handbook
    SUSE LINUX Enterprise Server 9 Administrators Handbook
    ISBN: 067232735X
    EAN: 2147483647
    Year: 2003
    Pages: 134

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net