Snoop, as powerful as it is, simply cannot replace a good network sniffer or intru- sion detection system. Snort, at version 1.8 of this writing, is an excellent (and free) tool for this purpose. Since snort is rule-based, an administrator can easily adapt it to a specific network or set of networks.You will find Snort, rules files, documentation, and discussion boards at www.snort.org. I strongly suggest that you spend the time to read all the documentation and understand the release- level features as well as the alpha and beta features.
We will be looking at the use of Snort with just a few of its many command switches. In the simplest sense, Snort can be started like so:
%snort
This works only if you execute Snort as root and if you have a rules file in your home directory. Since we want to make Snort more useful, we’ll be learning about the following command-line switches:
■ -c <dir> This tells Snort where to look for its configuration file. In
version 1.8p1, Snort’s configuration file (snort.conf by default) sources in rules files for use.
■ -b Generates log files in the format of the tcpdump utility.This makes
logging faster and helps Snort keep up with traffic-saturated networks (even 100Mbit/FDX).
■ -l <dir> The log directory where Snort will place all of its logs. ■ -d Dumps the application layer of the sniffed packet (if any).This can
■ -D Use this to run Snort as a daemon.
■ -A <word> This tells Snort to generate alerts, and what level to gen-
erate.The legal words are: fast, full, console, or none. Start off with full and pare down as needed.
You will need to obtain the source code for Snort. Download, decompress, and compile the software.There is a great deal of flexibility in the package ranging from where you install the binary and configuration files, to the extent and location of logs and alert notifications.The heart of Snort, though is the set of rule and configuration files. Snort, as of version 1.7. uses a main configuration file, snort.conf. In snort.conf, the administrator defines the local subnet(s), sets up preprocessors to handle things like HTTP requests and TCP fragments, and defines the common servers on a network, like Web, mail, and database servers. Each definition will play some part in the rules by telling Snort what traffic to consider malicious and what traffic, while appearing malicious, is truly benign and acceptable traffic for your network.The configuration file ends with a series of include statements telling Snort which rules files to use and which to ignore. The beauty of this feature is that we can write various rules types for various classes of exploits into individual files.This makes the management, updating, and debugging of rules incredibly simple and painless.The best way to understand the rules themselves and how they work is to start with a simple example:
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"SCAN NMAP XMAS";flags:FPU;)
The first keyword, alert, tells Snort that if this rule is matched, we want to gen- erate an alert.The $EXTERNAL_NET statement is set in the snort.conf file with a default value of any, meaning any network.The first any keyword refers to the source port of this traffic. In this case, we are curious about all ports.The “->” nomenclature is indicative of source and destination and is quite significant. In this example, we care about traffic from EXTERNAL_NET to our HOME_NET (also defined in snort.conf ).Traffic originating from our HOME_NET to an EXTERNAL_NET would not be a match for this rule, due to the directional identifier.The next any statement refers to the destination port on our local net- work. Again, we care about any port.The “msg...” string is the plain ASCII text that will be placed with the Snort-generated alert in the log file. In this case, the string tells us that we are looking out for the Nmap XMAS scan.The flags keyword tells Snort that we are curious about the TCP flags F(IN), P(USH), and U(RG). Other flags we could scan for are S(YN), R(ST), and A(CK).
Another key benefit of Snort is its flexibility in crafting rules.While extensive rule sets exist for out-of-the-box use with Snort, any administrator will easily pick up the syntax and structure of Snort rules in just a few minutes.With Snort’s ability to trace and track traffic based on IP,TCP, UDP, and ICMP parameters (to name just a few), almost anything is possible. If you have local SQL databases, Snort even offers plug-ins to allow you to log to an SQL database.
One legitimate concern regarding Snort (or any other intrusion detection system) is its ability to keep up with network traffic flows. On a 100Mbit/s, full- duplex link, many slower and older machines will start to miss or drop packets. Behavior of this type has always been, and remains, unacceptable.What if an attacker flooded your network with harmless traffic in order to hide an attack? The results could be disastrous. Luckily, Snort has what the author refers to as a
high performance mode.When starting Snort, you can issue the following command
to run Snort in this high performance mode: %snort -b -A fast -c snort.conf
In this mode, Snort writes all its captures and logs to a binary-formatted file. When you want to review the captured and logged information, you re-run Snort against the log file like so:
%snort -d -c snort.conf -l ./log -r snort.log
The previous command uses the -l to tell Snort which directory to log to, and -r indicates the source file from which to read our tcpdump-formatted data.
Spending a few minutes with the Snort documentation is enough to get the system up and running with a basic and effective configuration. It would be wise, though, for you to spend a few hours getting to learn Snort. As an intrusion detection system, Snort is one of the most powerful and flexible tools available to help protect and monitor your networks.
So now that you have Snort set up, what next? My first piece of advice is to run Snort with all the default rules enabled and let it log and generate all the alerts it wants for a period of time. Also, be certain to use the -d switch for Snort to run it as a daemon. On a new network, I like to let Snort run for two or three days with a generic configuration. I review the logs and alerts and see which rules are flagging normal traffic (i.e., preventive portscans, passive FTP), and then I disable or rewrite them to be more intelligent. In this way, I can easily get an idea of what traffic should normally appear on my network (and therefore which traffic should not be considered malicious or detrimental). On a typical produc- tion network consisting of just Solaris systems, you will most commonly see
telnet, ftp, dns, smtp, pop3, imap and X11 traffic. If you have disabled telnet in favor of SSH, then you will also see a good amount of SSH traffic on port 22 and most likely little or no X11 traffic. (Secure Shell has a nice feature of for- warding X11 connections, which are notoriously insecure, over the encrypted SSH tunnel. Using DISPLAY environment variables and some SSH magic, all X11 traffic is protected from prying eyes.)
What about other Solaris-specific traffic? Well, if you run one of Sun’s man- agement or support programs (Answerbook, Sun Management Console), you will see traffic on any number of ports, such as 8888, 695 and 898. If you absolutely must run these services, be certain your systems are firewalled, patched and that the software is configured as securely as possible. As Sun releases new products and utilities, the number of ports in use will increase. It will be your duty to make sure that the new software and services are installed with maximum security in mind.