An Alternative IDS software.

[instronics]

A different IDS Software.

Dear AO. This tutorial will be my 400th post making me a senior (w00t w00t) here on AO. So i thought what better way to do this than with a tutorial. This tutorial will be based on the IDS AIDE and ARGUS. The reason why i chose these 2 IDS is because there are so many posts on SNORT and on Tripwire. By no means do i intend to say that AIDE and ARGUS are better or worse than SNORT or Tripwire, its just that AIDE and ARGUS are not that bad either. As usual, please forgive any typos or bad English. This tutorial was written and tested on SuSE 8.1 Professional Linux, but it should work on most *nix systems.


1 - AIDE - (Advanced Intrusion Detection Environment)

AIDE is a program from the category Host Based Intrusion Detection, where you can guard the integrity of your data and system. AIDE is a modern free alternative to tripwire (since tripwire has gone commercial).

AIDE creates a database with data which guards your data on a *nix computer. This is done and maintained from the administrator inside /etc/aide.conf . Inside this configuration file, several attributes can be set such as user permissions, inode numbers, users, user groups, file size, mtime, ctime, atime, growing size and the amount of links which are linked to any chosen file. In addition, AIDE creates an encrypted checksum for every file using one or more algorithms such as sha1, md5, rmd160,and even tiger (crc32, hava1 and gost which can be compiled if mhash is supported).

Normally the AIDE database is configured after a new installation of a system before that system even goes online, or is connected to any form of network. This first AIDE database will create an instant “image” (i hope this word is correctly translated) of the systems default setup and is the backbone for any changes made from there onwards. This database should register the state of all executables, libraries, and header-files which will not be changed when the system is running. Files which will change constantly such as logfiles, mailboxes, files from the proc-file system, files inside /home or any temp files/folders should be ignored from this database. Normally it is quite easy to manipulate files in front of the system administrators eyes without them noticing, whereas system programs such as “ls”, “ps”, “netstat”, and “who” can be replaced by manipulated applications such as trojans. An encrypted checksum which is encrypted with the md5 algorithm is therefor much much harder to manipulate. The amount of work is too vast to go through that kind of trouble.

If you run AIDE on a compromised system, the administrator on that system can then very quickly and easily find the data which has been manipulated. If the created AIDE database is kept on a read only medium, then you can say that once AIDE reports any kind of manipulation it is 100% correct. A good way to keep the database would be to burn in onto a cd.


Configuring AIDE.

The configuration file is /etc/aide.conf (also do a man 5 aide.conf). The configuration file is line based. There are 4 types of lines (lines as in sentences) which are as follows.

1 - Configuration lines are used, to record configuration parameters, variables-definitions/variables solutions.

2 - Defined selected lines which are recorded in the AIDE database and which are not to be recorded.

3 - Macro-lines which are to be defined or deleted variables.

4 - Lines which begin with the #-character which will be ignored, normally used for comments.


#
# /etc/aide.conf
#

#This is where you define where the reference database is located.
database=file:/var/lib/aide/aide.db

#This is where you define where the actual database is to be created.
database_out=file:/var/lib/aide/aide.db.new

#This is where you define how informative AIDE will be.
verbose=20

#Reports should be written to 'stdout'.
report_url=stdout

#This is a list of all possible checksums.
#
#These are the pre-defined standard rules.
#
#
#p: permissions
#i: inode
#n: number of links
#u: user
#g: group
#s: size
#b: block count
#m: mtime
#a: atime
#c: ctime
#S: check for growing size
#md5: md5 checksum
#sha1: sha1 checksum
#rmd160: rmd160 checksum
#tiger: tiger checksum
#R: p+i+n+u+g+S+m+c+md5
#L: p+i+n+u+g
#E: empty group
#>: Growing log file p+u+g+i+n+S

#You can also define your own rules.
#
All=R+a+sha1+rmd160+tiger
Norm=s+n+b+md5+sha1+rmd160+tiger

#
# Now let us have a look at which files/folders are to be ignored.
#

!/tmp
!/proc
!/usr/src
!/var/log
!/var/adm/utmp$
!/home

#
#All the rest will be monitored.
#


/ R


##EOF##


In this example, we have done the following.

We have defined where the reference database is located.

We have defined where the actual database is to be created.

We have defined how much information AIDE gives us (verbose)

We have defined where the reports are to be written to.

We have defined each rule. Also custom rules.

We have defined that AIDE will ignore /tmp, /proc, /usr/src/, var/log, /var/adm/utmp$. /home and all the rest should be ignored since they tend to change as the system is running.


Unfortunately there is no default guide for this, decisions of what to guard and what not will vary from case to case depending on how your system is setup (caldera is a good example, since many known default paths are different on there). When configuring AIDE, great caution is required.

Also very important is that some rules which should guard certain files end with a $ character. (such as our example /var/adm/utmp$), so that the rules matches the exact file we specify.
If we left out the $ sign here, that would mean that all files beginning with utmp are affected. Our example would then have the following weakness:

/var/adm/utmp_root_kit would be ignored, since the utmp is on our ignore list. So in our case, only the actual utmp file we have is ignored thanks to the $ sign.

One also very important file to guard is where your firewall rules are setup (such as the iptables rules, since intruders who like to plant back doors might alter the firewall rules to allow access).


Using AIDE.

Once you have freshly installed your system to your likings, and before you connect to any form of network you can run AIDE by typing in:

aide –init

Once this is done, it is wise to burn them on a cd or on any non-writable medium, especially if the system is a firewall system or a system within the DMZ (De Militarized Zone). Once it is on a secured medium, it can be used to compare your set database with the actual system you intend to guard.

Also secure on a medium /var/lib/aide/aide.db.new.

To compare your system to your IDS just run the following command:

aide –check

Also the results which you get should be stored on a secure medium.

You can automate this procedure with the help of cronjobs. Where by AIDE is launched from a cd (your secure medium). The reports could then notify you by mail to the administrator. If you have a DMZ, then its good to mail from that box into your LAN.


2 - ARGUS

Argus is a generic tool used to guard IP networks.

With broadcast mediums, such as Ethernet, token rings, or apple talk you can program the network interfaces to guard all packets in transit (promiscuous mode). Argus runs as a daemon in the background, listens to all interfaces which are defined to be in promiscuous mode and creates then a log file. It is (thanks to the possibility that Argus belongs to the categories of network activities) which makes this tool so powerful. (Please also have a look at /usr/share/doc/packages/argus/README for more detail.)

Argus is available for SunOS, Solaris, Ultrix, IRIX, AIX and Linux.

Argus belongs to the category Net based Intrusion Detection. If you have a DMZ which is protected by an Application Level Gateway and the hosts within the DMZ run through proxies which are set to guard up to the IP-Level, then there is no need for a switch with port-security and flood protection within the DMZ. This is where argus can be placed to guard the network traffic within the DMZ. Especially if within the DMZ you have hosts which cannot be secured with detail such as windows nt-servers. It is then a good idea to use a tool like Argus to guard that traffic.

Configuring Argus.

In Linux, the file to start argus is located inside /etc/rc.config.

START_ARGUS=yes

That will make sure argus is started at every system boot.

ARGUS_INTERFACE=eth0

That will define on which interface argus runs on.

ARGUS_LOGFILE="/var/log/argus.log"

This will define where the log file for argus is.


Because this log file can become very large, it is wise to restart argus once a day (you can automate this) so that on every restart, the old log file is compressed and kept elsewhere so that a new log file can be started. Let me show you a little script that can do that for you every day.

#!/bin/bash
# /root/bin/argus_restart
#
/etc/rc.d/argus stop
mv /var/log/argus.log /var/log/argus.'date + "%y%m%d"'.log
/etc/rc.d/argus start

Name this file argus_restart, and place it inside /root/bin. Then make sure that only root can use this.

Linux:~ #chown root.root /root/bin/argus_restart
Linux:~ #chmod 500 /root/bin/argus_restart

After this, you can add to your cronjobs the following, let us say we want to run our little script every day at 12.30 PM.

#/etc/crontab
#
0 30 * * * root test -x /root/bin/argus_restart && /root/bin/argus_restart


For the analysis which argus produces for us, we can use the 2 tools "ra" (man ra) and "services" (man services).


I hope that these 2 tools might actually be helpful for anyone who wishes to use an alternative solution to snort or tripwire.


Cheers everyone.

[King of CaveMen]

Good job on the tutorial, very in depth.

[berg]

Awesome tutorial, keep up the great work.

[thehorse13]

Wow. This is great stuff.