By James Turnbull
The final step of setting up the open source IDS sensor Snort within a Red Hat Enterprise Linux 5 environment is editing the snort.conf file. In previous steps we've laid the groundwork by showing you how to confirm that Snort can run on your customer's hardware, ensure that the proper software for Snort has been installed, configure Snort with MySQL, and configure Snort's configuration directory and logging directory.
# vi /etc/snort/snort.conf
We want to define four items: our home network, external networks, the path to the Snort rules and to tell Snort to output to the MySQL database we created.
Your home network is set using the var HOME_NET variable. The home network variable defines the network you wish to protect, like the local LAN segment for instance It is set by specifying one or more networks in the form of a CIDR. For example:
var HOME_NET 192.168.0.0/24
The external network is set using the var EXTERNAL_NET variable. The external network is one or more networks where you believe threats or attacks will originate. It can also be set by specifying a CIDR, or you can make use of the home network variable we've just specified like so:
var EXTERNAL_NET !$HOME_NET
Setting the external network, as we did in the latter example, tells Snort that external networks are any networks except those specified in the home network variable.
The next variable we need to change is the path to the Snort rules that we've downloaded. It is set using the var RULE_PATH variable, in our case like:
var RULE_PATH /etc/snort/rules
Later in the configuration file, you'll find a section where you can enable and disable specific rule files contained in that directory.
Lastly, for our configuration, we need to direct Snort to output events and logs into a MySQL database. Find the example output database entry in the configuration file like this and un-comment it:
output database: log, mysql, user=snort password=password
Change the password portion of the password you selected for your MySQL database and make sure the dbname variable matches the name of the database you created for Snort.
Once you've configured Snort, you can start the Snort daemon. Snort does not directly come with an init script. In the rpm directory of the Snort package you can find two files, snortd and snort.sysconfig, which are a Red Hat-style init script and a sysconfig file, respectively. You can modify the init script and sysconfig file to suit your environment. For instance, you may need to change the path for the snort binary in the script.
You can also start Snort via the command line like so:
# /usr/bin/snort -c /etc/snort/snort.conf -D -g snort -u snort -i eth0
The -c option specifies the location of the snort.conf configuration file, -D indicates you'd like to run in daemon mode, the -g and -u options specify the group and user to run Snort as, respectively, the -i option specifies the interface that Snort should listen on and finally, the -l option specifies the location of the Snort logging directory (which we created earlier).
Once Snort is running it will send alerts and log entries to MySQL and the /var/log/snort directory.
Adding BASE to Snort
You can now see how easy it is to install and configure a basic Snort sensor. Of course, your simple sensor is currently not tuned and will require that you tune pre-processors, rules and similar features to get the best out of its detection capabilities. You will probably also want to install a Web-based console, such as BASE, to view the alerts and logs.
Intrusion detection with Snort on Red Hat Enterprise Linux 5
Introduction to network intrusion detection and prevention using Snort
Snort hardware and network setup requirements
Snort's installation prerequisites
Compiling Snort and configuration with MySQL
Configuring Snort and setting up rules
<class="text3"> Editing the snort.conf file
About the author
James Turnbull works for the National Australia Bank as a Security Architect. He is also the author of Hardening Linux, which focuses on hardening Linux hosts including the base operating system, file systems, firewalling, connections, logging, testing your security and securing a number of common applications including e-mail, FTP and DNS. He is an experienced infrastructure architect with a background in Linux/Unix, AS/400, Windows, and storage systems. He has been involved in security consulting, infrastructure security design, SLA and service definition and has an abiding interest in security metrics and measurement.