Complete Snort-based IDS Architecture, Part One
by Anton Chuvakin, Ph.D. and Vladislav V. Myasnyankin
last updated November 6, 2002


Intrusion detection systems (IDS) are one of the fastest growing technologies within the security space. Unfortunately, many companies find it hard to justify acquiring IDS systems due to their perceived high cost of ownership (for example see Justifying the Expense of IDS by Kevin Timm and David Kinn). However, not all IDS systems are prohibitively expensive. This two-part article will provide a set of detailed directions to build an affordable intrusion detection architecture from hardware and freely available software. This discussion will avoid the classic "build or buy" debate and instead focus on building the system at a minimum cost.

Building often provides a definite cost advantage, especially for companies that are unsure about the long-term necessity of the IDS. Building it cheaply allows one to evaluate the technology with very little investment and without necessarily possessing sophisticated network security skills. That said, it is reasonable to expect that maintaining and tuning the IDS will require relatively advanced security knowledge.

Also, while the goal of this discussion is to help readers to build a low-cost IDS, they should be aware of the expenses that are involved with operating, maintaining and adequately monitoring the system. In fact, it has been claimed that running a self-built IDS is more expensive than running a commercial system due to the lack of support provided by IDS vendors. This statement may be or not be true, but free support sources such as mailing lists and user forums can often be more thorough and timely than the official support channels.

Either way, it is clear that the initial acquisition cost is lower for the free solution. Furthermore, if the in-house staff is qualified to build the IDS, one can likely conclude that they will be able to run it without outside support, thus saving money on the day-to-day operation of the IDS. This does not mean that there are not significant expenses involved in the operation of the system. For instance, personnel requirements for round-the-clock monitoring of a single console range have been estimated from 3-7 analysts on full-time staff (8-hour shifts, weekends, backup staff, etc).

General Design

The intrusion detection platform discussed in this paper will be based on Debian GNU Linux OS, Snort network IDS, MySQL database, and ACID analysis console. Debian is entirely free software that may be used under GNU General Public License. Of course, one can use any Linux system, as they generally differ from each other only by package format and start-up scripts hierarchy. But Debian has been chosen for this example because among its general features are security and stability. It is also a highly configurable system: users can select and install only the things they need to perform the set of tasks, which is very important for security reasons. Debian also allows for easy deployment of the minimum system, a characteristic that is highly desirable for IDS sensors.

The first thing to consider in the general design of the IDS is to determine the best place to position the IDS. Unfortunately, a detailed discussion of this subject is beyond the scope of this paper, and can be found elsewhere on the Internet or in various books, which look at various deployment schemes (external connection, IDS behind firewall, both inside and outside, DMZ, internal network, etc). (Two such resources are Network Intrusion Detection: An Analyst's Handbook by Judy Novak and Stephen Northcutt, and the SecurityFocus article Managing Intrusion Detection Systems in Large Organizations by Paul Innella, Oba McMillan, and David Trout.)

In all cases, one needs to keep one common problem in mind: traffic availability. To run an IDS, one needs to have all network traffic available for an IDS inspection. If the network is hub-based, this is no problem: one has only to connect an IDS sensor to any unused hub port and sniff all the information. But in the switched environment the sensor will become blind because packets are send only to ports, where the appropriate destination MAC address is located. Only broadcast packets are available to all hosts in such environment.

Many switches have a special port, called "SPAN-port", "mirror-port", etc. This may be a dedicated port or any port, configured to be a monitor port by the switch software. Usually, this port works at higher speed than others for a simple reason: to monitor 10 channels at 10 Mbps, one needs a 100 Mbps line as a minimum.

Another related problem is VLAN-divided networks. If the hardware does not allow the user to monitor different VLANs on a SPAN-port at the same time, one option is to try to monitor a trunk-link. Usually, this is a link between switches or routers, where packets from all VLANs are transmitted marked with a particular label, called "VLAN ID tag", according to IEEE 802.1q standard (also known as "dot 1q"). However, an IDS or a sniffer cannot directly deal with this traffic to due to VLAN ID change to packet structure. Fortunately, newer Linux kernels support 802.1q, so one can tune VLAN parsing on primary interface (for example, eth0) and direct appropriate traffic to the virtual interfaces (eth0.1, eth0.2, eth0.3, etc) according to VLAN ID. Note that Linux VLAN interfaces are designated as "eth0.X" and should not be confused with IP aliases which are marked "eth0:X".

All one needs to do is to turn on 802.1q VLAN support in the kernel configuration and install vlanconfig. Traffic on each virtual interface will be analyzed by its own IDS sensor.


This series will discuss two deployment scenarios: a single IDS box (possibly with many Snort instances for VLANs) and a true distributed system with numerous sensors. The set-ups have one important similarity: for security reasons, sensor and administrative network interfaces must be separate. So one needs to have at least two NICs on the computer.

The first option (single host) is more appropriate for a small network with 3-4 hosts or for a network with single low-speed Internet connection. In this case the Snort software, Alert SQL database, Web server and additional software are deployed on a single computer. The second (distributed) option is similar but will involve several sensors, each deployed on a separate computer and one central console with SQL database, Web server and additional software on a dedicated computer. In cases of higher traffic load one might want to install the database and a Web server on different computers.

Because components of the distributed IDS are connected via network, several security measures must be implemented. First, to protect traffic between analyst workstation and a database, SSL connection will be used. To restrict access to the console, the standard feature of Apache Web server, basic http authentication via .htpasswd, will be utilized for ACID-based console.

As was noted above, separate interfaces are used for sniffing and administration. The main reason for this is that the sniffing interface will have no IP address assigned to it. In Linux, it is easy to activate a network interface with no IP by using a command similar to ifconfig eth1 up. While not providing total security, this solution is much better than having a regular interface for detection. On switched networks, if one connects the sensor to the special switch port in "port monitor" mode (mirror port, SPAN, etc), then this port is considered to be read-only by the switch itself, so the sensor cannot send any data through this port and is extremely hard to attack through it (notwithstanding the bugs in packet capture libraries and rumoured vulnerabilities of the TCP/IP stack).

Base System Set-up

The guidelines below can be used to implement a secure minimal Linux system.

It is recommended that readers use a Debian CD or network install via floppies (4 are needed). In fact, an intermediate variant (minimum CD and network install) might be an option for some environments. This option was used for the test configuration by one of the authors.

First, you should download Debian floppies or download and burn a minimal CD image (or acquire a full distribution CD set. Four floppy images are needed (rescue.bin, root.bin, driver-1.bin and driver-2.bin). You can create the floppy images using rawrite.exe (Windows) or dd> (under Linux) .

You then need to insert rescue floppy and boot from rescue. When prompted, insert root diskette and continue loading. For CD ROM case, boot from the CD ROM but keep the computer connected to the network for downloading additional software packages.

Here is guide for secure base system building:

  1. Partition a hard disk. While you may create only one Linux native partition and one swap partition, it is recommended that you separate at least /tmp and /var from the rest (/, /usr, /home). The size of swap partition depends on the available hardware and should be equal to at least twice the RAM size. For partitioning in the installation process, you can use cfdisk - a friendly program with built-in help.
  2. Install kernel and configure driver modules - the configure networking
  3. Install the base system packages as suggested by the install program. For network install, select "Network" (http or ftp connection) for further installation and enter (or confirm) the download URL. The default URL is, but other locations can be selected as well (for example, If a direct Internet connection is unavailable, one will need to enter proxy server parameters such as address and port.
  4. Reboot the system. At this point, core Debian installation is complete but some preliminary configuration should be done. One needs to choose the appropriate timezone, setup password security options, define root password and create other accounts.
  5. Run tasksel. Do not select any additional software. The precise set of required software will be installed manually later. Choose "no" if asked about installing further software. Do not run dselect. When the set-up script asks about the mail system configuration, answer "local delivery only."

The base system install is now complete. Now the resulting system should be hardened. The minimum required hardening is to remove all network services by editing the /etc/inetd.conf or by disabling the inetd daemon completely.

Add to crontab synchronization with time reference machine:

# crontab -e
0 2 * * * /usr/sbin/rdate -s

OpenSSH will be used for secure remote administration. Debian install might install the SSH package by default. If the SSH is not running after the system reboot, install the package using:

# apt-get install ssh

During the post-install configuration, one should answer "yes" to the question "Do you want to run the sshd server?" Additional access control should be configured to only let specified IP addresses access the system. TCP wrappers are the simplest to configure, as they are installed by default. Add a line "ALL:ALL" to /etc/hosts.deny and the IP address of the administration system to the /etc/hosts.allow. The format is:

sshd: 111.222.333.444

To add yet another layer to the remote access security, one can enable passwordless SSH authentication via public keys and totally disable password authentication. It is also highly recommended that you deploy a host firewall with a restrictive rule set (similar to the one described in Netfilter How-To).

The base system configuration is complete. The system can now be deployed in the server room and the next steps can be performed remotely via secure shell.

Snort Installation

At this point two versions of the Snort set-up are possible. The first is a single box set-up (sensor, database and console on one machine), which is more appropriate for a small environment. First, the database for storing alert information is added to the Linux system. This set-up uses MySQL database.

# apt-get install MySQL-server

The access to a database is controlled by a MySQL admin password ("BigSecretPassword" in the example below):

# mysqladmin -u root password BigSecretPassword

Next, the Snort IDS with SQL logging support is deployed:

# apt-get install snort-mysql

It is more consistent to accept the default values and then run through a configuration checklist below. First, create snort_log database and set up user passwords:

# cd /usr/share/doc/snort-mysql/contrib.
# gunzip -d create_mysql.gz
# mysql -u root -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
mysql> create database snort_log;
mysql> connect snort_log;
mysql> source create_mysql
mysql> grant CREATE, INSERT, SELECT, DELETE, UPDATE on snort_log.* to snort;
mysql> grant CREATE, INSERT, SELECT, DELETE, UPDATE on snort_log.* to snort@localhost;
mysql> grant CREATE, INSERT, SELECT, DELETE, UPDATE on snort_log.* to acid;
mysql> grant CREATE, INSERT, SELECT, DELETE, UPDATE on snort_log.* to acid@localhost;
mysql> create database snort_archive;
mysql> connect snort_archive;
mysql> source create_mysql
mysql> grant CREATE, INSERT, SELECT, DELETE, UPDATE on snort_archive.* to acid;
mysql> grant CREATE, INSERT, SELECT, DELETE, UPDATE on snort_archive.* to acid@localhost;
mysql> set password for 'snort'@'localhost'=password('');
mysql> set password for 'snort'@'%'=password('');
mysql> set password for 'acid'@'localhost'=password('');
mysql> set password for 'acid'@'%'=password('');
mysql> exit

Since the IDS platform can be used to sniff many interfaces or many virtual (VLAN) connections, the default set-up needs to be modified. For each VLAN circuit a separate instance of Snort will be used. Provided below is the set of Snort configuration files that seamlessly support any number of VLAN links and are easy to maintain and upgrade.

First, an additional directory needs to be created to store the common config files:

# mkdir  /etc/snort/common

If you need to switch interfaces into promiscuous mode, then simply create a file named "promisc" in the "common" directory, which will be referenced by the start-up script:

# touch promisc

Now one needs to create a file named "interfaces", containing the list of interfaces that Snort must be run on. For example, one can add either real (eth1, eth2 - in the case of multiple network cards) or virtual (eth1.0, eth1.1 - in case of a VLAN set-up) interfaces, one for each monitored line. Virtual interfaces are monitored via the 802.1Q support in Linux, and in this case one must ensure that the master interface is already up, because the ifconfig eth1.1 up command does not bring up the master interface (eth1).

Next, edit the common configuration file. In this example it will contain:

##### begin file ####

# common variables

pass ICMP $HOME_NET any -> $HOME_NET any
pass TCP $HOME_NET any -> $HOME_NET any
pass UDP $HOME_NET any -> $HOME_NET any

# preprocessors
preprocessor frag2
preprocessor stream4: detect_scans
preprocessor stream4_reassemble
preprocessor http_decode: 80 -unicode -cginull
preprocessor rpc_decode: 111
preprocessor bo: -nobrute
preprocessor telnet_decode

# output plugins
output database: log, mysql, user=snort password= dbname=snort_log host=localhost

#### end file ####

The "pass" rules might not be appropriate for all networks since internal-to-internal attacks will not be recorded. For a busy network where the perceived threat is outside the "pass" rules might be a good idea since they will decrease the hardware requirements and thus save some money.

Next, one must create the configuration file for each sensor in /etc/snort directory. The naming convention is simple: "snort.conf.<interface>", where "interface" is eth1, or eth1.0 etc.

Typical config may contain:

#### begin snort.conf.eth1 example file ####

var HOME_NET  #for example:

include /etc/snort/common/

# Include classification & priority settings

include classification.config

# Customize the rule set

include bad-traffic.rules
include exploit.rules
include scan.rules
include finger.rules
include ftp.rules
include telnet.rules
include smtp.rules
include rpc.rules
include rservices.rules
include dos.rules
include ddos.rules
include dns.rules
include tftp.rules
include web-cgi.rules
#include web-coldfusion.rules
#include web-frontpage.rules
#include web-iis.rules
include web-misc.rules
include web-attacks.rules
include sql.rules
include x11.rules
#include icmp.rules
#include netbios.rules
include misc.rules
include attack-responses.rules
#include backdoor.rules
#include shellcode.rules
#include policy.rules
#include porn.rules
#include info.rules
#include icmp-info.rules
#include virus.rules
include local.rules

#### end of snort.conf.eth1 example file ####

Of course, one needs to review the set of rules based on the specific conditions. For example, if you do not use any Windows machines or UNIX samba servers, you probably do not need to include the "netbios.rules" file. In some cases, you will need to write your own rules or modify existing rules. See Snort documentation for additional details on rule writing.

What are the factors that might influence the choice of rules? While a detailed discussion of IDS tuning is beyond the scope of this article, readers can refer to Kevin Timm's SecurityFocus article Strategies to Reduce False Positives and False Negatives. That said, one approach is to enable all rules and spend several days flooded with alerts, analyzing them and reducing the rule set accordingly. This route is more appropriate for internal network IDS deployment. Another solution is to narrow the ruleset to only watch the "risky" services. This works better in a highly secure DMZ set-up in which all machines are carefully audited and hardened.

Everything should run properly once the configurations are completed, but sometimes bugs and crashes happen. To automatically restart the Snort instances, the following root-owned cron job will be used:

*/5 * * * * /usr/local/bin/snortcheck >/dev/null 2>&1

It uses the script provided below:

#### begin /usr/local/bin/snortcheck ####


#snort restarting
num=`ps aux|grep "\/etc\/snort"|wc -l|awk '{print $1}'`

if [ $num -lt 3 ]
/etc/init.d/snort restart
date >> /var/log/snortrestart
echo "Snort was restarted at `date`" | /usr/bin/mail root

####end of  /usr/local/bin/snortcheck ####

One should ensure the appropriate permissions on the file /usr/local/bin/snortcheck (read and execute by the owner i.e. root).

The final step in the set-up process is to edit the Snort startup script:

#### begin /etc/init.d/snort ####
# Script to control SNORT execution under Debian
# Written by Vladislav V. Myasnyankin .

PIDFILES=`ls /var/run | grep snort`
INTERFACES=`cat /etc/snort/common/interfaces`

# Arguments passed to SNORT
# To watch only our system
ARGS="-o -p -X -u snort -g snort -D"

# Check if we need to watch all packets in the segment
if [ -e /etc/snort/common/promisc ]
ARGS="-o -X -u snort -g snort -D"

test -x $DAEMON || exit 0

case "$1" in
    echo -n "Starting Network Intrusion Detection System: snort"
        echo $IFACE
        echo $CONFIG
        echo $PIDFILE
         /sbin/ifconfig | grep $IFACE > /dev/null 
         if [ $? -ne 0 ] 
          /sbin/ifconfig $IFACE up            

 /sbin/start-stop-daemon --start --pidfile $PIDFILE --exec $DAEMON -- -i $IFACE $ARGS -c $CONFIG

	case "$?" in
	  0) echo "." ;;
	  1) echo "...already running." ;;
	  2) echo "...failed." ;;
    echo -n "Stopping Network Intrusion Detection System: snort"
        echo $PIDFILE
        /sbin/start-stop-daemon --stop --quiet --oknodo --pidfile /var/run/$PIDFILE --exec $DAEMON
        echo "."
        rm -f /var/run/$PIDFILE
    ps cax | grep '/usr/sbin/snort' 	   | awk '{ print $1 }' 	   | xargs --no-run-if-empty kill -9 >/dev/null
	/etc/init.d/snort stop 
	# stop will take care that the thing is really dead
	/etc/init.d/snort start
    echo "Usage: /etc/init.d/snort {start|stop|restart|force-reload|reload}"
    exit 1

exit 0
#### end of /etc/init.d/snort ####

Now the IDS can be safely restarted using the new multisensor configuration.


This concludes the first part of our two-part discussion of how to build a Snort-based IDS from scratch. In the next installment, we shall discuss Web interface configuration, summaries and daily reporting, automated attack response, sensor installation, installation of the central station, and big distributed IDS systems.

Complete Snort-based IDS Architecture, Part Two
by Anton Chuvakin, Ph.D. and Vladislav V. Myasnyankin
last updated November 19, 2002

Many companies find it hard to justify acquiring the IDS systems due to their perceived high cost of ownership. However, not all IDS systems are prohibitively expensive. This is second part of a two-part article that will provide a set of detailed directions to build an affordable intrusion detection architecture from hardware and freely available software. In this installment we shall discuss Web interface configuration, summaries and daily reporting, automated attack response, sensor installation, installation of the central station, and big distributed IDS systems.

Web Interface Configuration

First, you should deploy an Apache Web server with an SSL support, if it is not already installed by the Debian config. The command to run is "apt-get install apache-ssl". When configuring, you will be asked for some information that is required to generate the SSL key pair. One need to enter the same server name as was used for the base Linux set-up.

Next, ACID IDS console is deployed via "apt-get install acidlab". This is yet another point when the choice of Debian becomes clear, as there are no packages to compile and no dependences to troubleshoot. Answering the set-up questions is easy. The only one that needs special attention is the question about the database user: it is not root as suggested by the set-up script, but the “acid” user, which we already created during the database set-up. You should also agree to inserting string with PHP module into config file and running the apache config script.

At the time of writing, there was a small bug in the ACID package install script: by default, the script does not install MySQL support for PHP needed for ACID. So, this should be done by hand:

# apt-get install php4-mysql 

and Apache should be restarted as follows for the changes to take effect:

/etc/init.d/apache-ssl restart

Now, the system can be tested. For this one should go to the appropriate page using HTTPS protocol: https://<the server address or name>/acidlab/ . On the first load, one will be asked to click on the “Setup Page” link to complete the installation. On this page the “create_AG” button should be pushed. With this, set-up is almost complete; the only remaining part is to limit the access to the server via Apache basic authentication.

The following lines should be added to the /etc/acidlab/apache.conf file after the “AllowOverride None” line:

AuthType Basic
AuthName "Restricted"
AuthUserFile .htpasswd
Require valid-user

In addition, one can restrict access only from specified IP addresses. For example, if one wants to allow access to ACID console only from, and entire C-class network, the appropriate changes are:

order deny,allow
deny from all
allow from,,

To complete the access control set-up, one should go to the /etc/apache-ssl directory and create the password file:

# htpasswd -c .htpasswd <username>

You will be prompted for password. Several users can be added by the “htpasswd .htpasswd <username1>”, etc commands.

The IDS system is now fully operational with Web access to alerts and packet data.

Some other free consoles exist for Snort. One of the better known free ones is SnortCenter. This is a Web-based client-server management system written in PHP and Perl. It includes SSL-encryption, built-in user authentication, rules management and multi-language support.

The latest and greatest Snort front end is made by Sourcefire, home of Marty Roesch and Snort. The slick web GUI seamlessly integrates alarm viewing with rule management, a big advantage over other Web front ends. It also provides a simple, but flexible interface for rule editing and many useful alarm viewing modes (including graphing) as well as full control over other aspects of Snort behavior, such as preprocessor configuration. Sourcefire GUI also has an option of issuing live signature updates directly from the Sourcefire site.

Additional Features

There are some additional features, which you can use to make IDS administration and event analysis process even easier. One good idea is to add daily reporting and some attack response capabilities.

Summaries and Daily Reporting

The most essential part of IDS deployment is monitoring of routine network activity. An effective way to accomplish this is to get daily reports on the activity. To provide daily statistics, one can query the alert MySQL database or configure Snort to also output data to syslog for summarization. The former approach can be implemented using SnortReport, which is available at It can be used for real-time or historical reporting from the MySQL or PostgreSQL database of alarms generated by Snort.

Many tools are written to utilize the latter approach of summarizing Snort alarms from syslog. SnortSnarf by Silicon Defense is perhaps the most well known of these. It can produce HTML reports from snort alert files, include port scan summary, alert summary by alarm, alert summary by source and destination and others. Other scripts include snort_stat and LogHog.

To simplify the analysis of events from many sensors running on the same machine (such as for the VLAN case), one can use the simple syslog filtering trick. Add a line to the corresponding snort.conf.ethX file:

output alert_syslog: LOG_LOCALX LOG_ALERT

In this example one uses LOG_LOCAL1 facility for the first sensor running on the interface eth1. It is convenient to use different syslog facilities (LOG_LOCAL1, LOG_LOCAL2 etc) to distinguish the information flows and direct they into different log files for summary reporting. For example, for a 3-sensor machine one need to add to /etc/syslog.conf the following lines:

LOG_LOCAL1.* /var/log/snorty/snorty-eth1.log
LOG_LOCAL2.* /var/log/snorty/snorty-eth2.log
LOG_LOCAL3.* /var/log/snorty/snorty-eth3.log

Now, before the log rotation procedure (enabled by default on Debian) starts, you need to simply run whichever Snort script against Snort log files and mail output to the appropriate address. For example, there is /etc/logrotate.d/syslog entry for using "" for daily summaries:

        /bin/cat /var/log/snort/snorty-eth1.log 
| /usr/local/bin/ -i ETH1 -f | /usr/bin/mail\ -s "Snort Daily Report for sensor eth1"
        rotate 7
        create 644 root root
            /etc/init.d/syslog restart >/dev/null 2&>1

The Snort log for a sensor running on eth1 is processed via, e-mailed to “", compressed and stored. Snort is then restarted.

Automated Attack Response

Network intrusion detection systems are also capable of mitigating attacks by applying the network access controls, such as firewall rules, or by directly terminating offending connections. For a review of Snort attack response methods see's featureIntrusion Detection Response.

The most flexible way to use Snort for automatic attack response is with Guardian Active Response for Snort. This tool automatically updates firewall rules based on alerts generated by Snort. The new firewall rules block all incoming data from the IP address of the machine that caused Snort to generate an alert. There is a whitelist support to prevent the blocking of important machines, such as DNS servers, gateways and other predefined hosts. The whitelist of addresses that should never be blocked by the IDS is crucial for the automated response system. Even if the IDS will invoke the response command upon seeing the attack in the full TCP stream only (thus preventing the denial of service through blocking the access to crucial hosts caused by spoofed "attack" packets), many IDS signatures have false positives that will result in disrupting of non-malicious connections. It is highly desirable to enable response only on reliable signature with no known false positives and additionally have the well-designed whitelist.

The tool supports Linux iptables, ipchains, ipfwadm, ipfw, and also commercial CheckPoint Firewall-1 and Cisco PIX firewalls.

Distributed IDS Setup

Networks with higher traffic load might justify deploying several dedicated sensor machines reporting to a single alarm database and console. To build a distributed IDS, one needs to install the components described above into different machines. The set-up is similar to the single host set-up described above. The difference is that now you need two (or more) base machines with Debian as described above.

Sensor Installation

Install base system, as described above. Set up Snort IDS with MySQL support:

# apt-get install snort-mysql

While configuring, accept all default values. The difference in Snort configuration is in the output plugin configuration. Now Snort is set to log to a database on another host. The appropriate lines in snort.conf on every sensor machine are:

# output plugins output
database: log, mysql, user=snort password=<the secret snort password
here> dbname=snort_log host=<central-log-host-running-sql-name>

It is apparent that every machine can have more than one Snort instance for the case of a distributed VLAN or a combination of LANs and VLANs.

Installation of Central Station

Install base system, as described above. Set up MySQL server via “apt-get install mysql-server”. During the installation, you should allow network connections to the SQL server. The following set-up matches that of a single host solution.

The differences start when granting permissions to access the database tables. One needs to repeat commands "grant" and "set password" for each host one want to connect to central database. For example:

mysql> grant CREATE, INSERT, SELECT, DELETE, UPDATE on snort_log.* to snort@<>;
mysql> grant CREATE, INSERT, SELECT, DELETE, UPDATE on snort_log.* to snort@<>;
mysql> grant CREATE, INSERT, SELECT, DELETE, UPDATE on snort_log.* to snort@<>;

Installing the Web interface (including Apache and ACID set up) is similar to the previous procedure for a single host set-up. It is highly recommended to synchronize the time between all sensors and the database system. It will save you some frustration during the incident response. While running additional services (such as NTP, which has a security history) might not be desire, the sensor boxes can be set to poll a specified time server via the "rdate" command set in crontab. For example:

* 1 * * * /bin/rdate -s

The multi-machine setup also brings up the problem of maintaining signature sets. It is likely that various machines will be deployed in different environments with different security requirements that will lead to corresponding differences in rulesets. It is apparent that an internal sensor will need a different rule set from the one running outside the border router or even in the DMZ.

Manual rule updates become troublesome if more than one sensor is deployed. The simple solution will be to deploy the signatures on a central server and then retrieve them via ftp ("wget" is great for this). If a signature sets are known in advance, i.e. the same signatures need to be disabled on each update, one can use "oinkmaster" from Snort to distribute updates from a central server and handle the local ruleset customization on each sensor via the oinkmaster interface.

Each sensor may also have its own unique configuration, which is tuned using "include" directive in configuration file.

The last issue to addresse is the security of the sensor-console communication. If deemed necessary, the SQL communication between the sensor and the database can be tunneled over the secure shell(SSH). This article provides a great reference for doing this.

Big Distributed IDS

In this case the central system is further separated, and the Web server and SQL server are installed on separate machines. This is just a version of the previous set-up. One needs to install sensors, then install the database on one machine, and deploy a Web server and ACID onto another machine. When setting up the IDS console, one should configure the source database as located at another machine. This will leave more CPU cycles for the database process.


The guide offered in this two-part series should allow readers to set-up an IDS for a small network (single host set-up) or even for a large environment (distributed configuration) at zero acquisition cost. Admittedly, there might be some set-up and maintenance costs involved, but it is apparent that for many environments configurations similar to above is the only way to deploy industry-accepted intrusion detection solution.

Vladislav V. Myasnyankin, security expert, author and translator of several IT security related papers. At present time he works as Chief Information Security Officer at the bank. The author would like to thank Paul Pokrovsky and Michael Plotnikov for help with article development.

Anton Chuvakin, Ph.D., GCIA is a Senior Security Analyst with a major information security company. His areas of infosec expertise include intrusion detection, UNIX security, honeypots, etc. In his spare time he maintains his security portal.