Configuring Snort
The snort.conf file provided in the distribution normally needs to be modified to work properly. There are several variables that must be defined in order for Snort to identify the traffic. Additionally, the snort.conf file is where you define what plugins to use, what rulesets to use, and how to output log and alert information.
Variable Definition
Individual IP and Network addresses are given in CIDR notation. Most variables and configuration directives accept a list of addresses. The list format is a comma-separated list with no spaces between each IP or Network address. The list itself is enclosed in square brackets, like so:
[10.1.1.0/24,192.168.71.20/32]
The first variables to define are the internal and external networks. The terms internal and external are relative, and can be adjusted to mean many hosts or networks. Internal networks are generally defined as those within your organization. However, for servers on your DMZ, you might configure the internal network as the IP address of the server itself, and external network as everything else. This view allows you to monitor all access, including access from internal hosts.
var HOME_NET 192.168.71.119/32 var INTERNAL $HOME_NET
External networks can then be defined in terms of what is internal.
var EXTERNAL_NET !$HOME_NET var EXTERNAL $EXTERNAL_NET
It is important to define both HOME_NET/EXTERNAL_NET and INTERNAL/EXTERNAL variable pairs because some rulesets use the former, and others use the latter. Defining both allows you to mix and match rulesets without a significant amount of editing on your part.
Mail servers, Web servers, DNS servers, and database servers are defined in a similar fashion to the internal and external networks. You can provide lists of hosts and networks, or use the $HOME_NET variable.
var SMTP $HOME_NET var HTTP_SERVERS [192.168.71.2/32,192.168.71.3/32] var SQL_SERVERS 192.168.71.101/32 var DNS_SERVERS [192.168.71.100/32,192.168.71.1/32]
Again, it is important to define them all, even if you define them as the local server IP address because they are used throughout the available rulesets.
Stealth Sensors
One tip for deploying Snort sensors on either side of the firewall is to not bind an IP address to the listening network interface. This effectively puts the sensor in "stealth mode" because it will not respond to any IP-based traffic.
The sensors are usually configured to have a secondary network interface card installed that is attached to a LAN dedicated to alert logging and administration.
Enabling a network interface without an IP address is not a common practice on network-attached servers. That means there will be precious little (read none) documentation in your administration manuals on how to configure your sensor in this way. Following are some hints about how to configure some of the more common operating systems.
On Solaris systems, you must first initialize the driver and then enable the interface.
ifconfig hme0 plumb ifconfig hme0 up
On Linux systems, ensure that the driver is loaded and just enable the interface.
modprobe –a tulip ifconfig eth0 up
On Windows NT and 2000 systems, configure the interface, but do not bind TCP/IP to the interface. If TCP/IP is already bound, just remove TCP/IP from the interface in the Networking Control panel dialog box.
On sensors configured with no IP address, you cannot monitor traffic destined for that particular sensor, but that should not be a problem because that is not the intent of a "stealth sensor."
Enabling Preprocessor Plugins
The next section of the snort.conf configuration file defines which preprocessor plugins are to be used. The definition and configuration options for each plugin are described as comments in the snort.conf file. Some of the more common preprocessors to enable are as follows:
IP defragmentation detection, uncomment preprocessor defrag
TCP Stream Reassembly, uncomment preprocessor stream
HTTP decode normalizes HTTP requests so that all the Snort rules apply in the same fashion, uncomment preprocessor http_decode
Portscanning plugin detects UDP packets or TCP packets with the SYN flag set, uncomment preprocessor portscan
A complementary plugin to the portscan plugin that identifies your DNS servers so you can reduce the amount of false positives because DNS traffic is so prevalent, uncomment preprocessor portscan-ignorehosts
Defining Output Options
The output options allow you to define how and where alerts and logs get written. You can log to local files in formatted or binary format, syslog, Eventlog on Win32, XML, or any of the supported databases.
You can log to multiple output devices, but the more output you produce, the more overhead is involved with processing those logged packets and incidents. On a highly loaded server, it may be wise to just log to the local filesystem in the tcpdump binary format, which can later be retrieved and reviewed on a central console.
For the purposes of this article, I've chosen to log to a central MySQL database. The snort.conf file has documentation that explains many of the options of each type of output plugin.
The output line looks similar to the following:
output database: log, mysql user=snort_sensor dbname=snort_log host=192.168.71.20 password='pass' output database: alert, mysql user=snort_sensor dbname=snort_log host=192.168.71.20 password='pass'
The reason for two output lines, nearly the same, is that I want to store both logged packets and alerts to the same database. You can easily separate the two into two databases if you wish.
Selecting Rules and Rulesets
The Snort rule language is fairly easy to learn. A detailed account on specifically writing rules can be found in the Snort rule-writing document: (http://www.snort.org/writing_snort_rules.htm)
Additionally, there are many sources of new rules that can be added to your ruleset. There is a mailing list dedicated to the creation of rules. The Snort Web site has a periodically updated set of rules, split out by functionality. This makes it far easier to enable or disable various classes of rules. The most popular source of Snort rules is the arachNIDS database, maintained by Max Vision. The arachNIDS database is auto-generated whenever new rules are added or changed.
The rules that are provided in the source and binary packages are slightly stale and not really maintained. They are intended primarily for helping you get Snort up and running, and not meant for production deployment. I recommend downloading the updated rules from the Snort Web site, the vision.rules file from the arachNIDS database, or a combination of the two.
The rules can easily be incorporated into your snort.conf file by using the "include" directive. Toward the bottom of the snort.conf file are examples that you can delete or comment out. When including the new rules, use fully qualified pathnames. For example:
include c:\snort\rules\Webserver-iis.rules include /etc/snort/vision.rules