Snort

		Chapter 9 - Network Traffic Analysis Honeypots for Windows by Roger A. Grimes Apress 2005

Snort is a free network packet analysis tool written by Martin Roesch in 1998 for his personal use. It now enjoys a reputation as one of the most widely used security tools in the open-source world. Community support is available from http://www.snort.org. Snort was originally a Unix-only program, but it has been successfully ported to Windows by Michael Davis, who was also the porter of Honeyd.

Understanding How Snort Works

Snort is often described as a virus scanner for network packets, but it has three modes: packet dump, packet logger, and network IDS. Packet dump mode captures packets and displays them to the screen (the console). Packet logger mode writes packets to a physical file. Snort can be used in both modes at the same time, mimicking a command-line network protocol analyzer. In network IDS mode, Snort will analyze grabbed packets for malicious content. All three modes can be used together in different combinations.

Snort is perfect for detecting DoS, fragmentation, known buffer overflows, scanning worms and scripts, cross-site, and injection attacks. You can connect Snort to external databases to ease packet and event logging and analysis, link it to reporting tools, manage it through centralized consoles, and enable it to participate in many types of alert systems.

Snort’s packet-capturing routine allows you to capture all packets headed to and from your honeypot. In order for Snort to detect malicious packets reliably, it needs to inspect all packets. Captured packets are passed to the packet-decode engine component. The packet-decode engine separates packets into their higher- and lower-layer components, much like Ethereal might display. This is because different attacks occur at different levels, and Snort doesn’t need to apply all its rules to all layers for all attacks. For example, if a buffer overflow will never occur at the frame layer, there is no need to examine that layer for buffer overflow attacks.

Snort works by using the libcap capture API (as does WinPcap, tcpdump, and Ethereal) to capture packets for examination and logging. A packet-decode engine examines the packets, hands them to preprocessor plug-ins, and then on to the signature-detection engine, which produces actions (allow, deny, and log) and outputs (alert, log, and so on). See Figure 9-14 for an illustration of the Snort packet pathway.

Figure 9-14: Snort packet pathway

Although Snort can decode many other protocols, TCP/IP support is its primary concern. For example, IPX and Cisco frames are recognized as such, but they aren’t decoded beyond layer 2. This is why you still need a protocol analyzer and cannot use Snort as your only forensic tool.

Installing Snort

Before you install Snort on a Windows machine, you must download the latest binary and support files and make sure WinPcap is installed, as described in Chapter 5.

When you install Snort with default parameters, it installs to C:\Snort, which is empty except for six subdirectories and the uninstall executable. The six directories and their functions are as follows:

• \bin: Contains the Snort.exe main executable and the DLL files it depends on.

• \contrib: Contains the script files coded by community contributors that extend Snort’s functionality. There is a Readme file with a brief description of each script. Many are written in Perl and the shell scripting language, which you can execute because you installed Cygwin (in Chapter 5).

• \doc: Includes an extensive collection of Readme files regarding most Snort functionality.

• \etc: Contains Snort configuration files, including the critical Snort.conf.

• \log: Serves as the log folder for holding Snort’s default log files. Usually, it’s empty until you have Snort running.

• \rules: Contains an extensive collection of Snort rule sets, the predefined byte patterns that Snort’s signature-detection engine uses to detect malicious packets.

I highly recommend that first-time users print all of the Snort documentation and read it. It will answer most of your questions, so you can get Snort up and running quickly.

Configuring Snort

Snort is not an install-and-execute program. It takes a fairly good understanding of what it does and how it operates to configure and use properly. Besides making sure that the Snort host computer is hardened against detection and attack, honeypot administrators should use the following steps when configuring it for the first time:

1. Decide what you want Snort to do.

2. Configure the Snort configuration file.

3. Configure rule sets.

4. Test the Snort configuration.

5. Create and use a Snort.bat file.

Snort contains a myriad of features, but if all of them were turned on, it would be a very slow IDS. Snort administrators will need to examine Snort’s documentation and functionality, learn the good and the bad about each feature, and then configure what makes the most sense for their honeypot environment. I suggest that new Snort users start with a small and basic configuration, and then expand it as they get more practice.

Deciding What You Want Snort to Do

The first decision is which mode to put Snort in. Snort can be configured to be a packet sniffer or network IDS.

Snort Packet Dump Mode

To enable Snort to sniff packets to the console, you can execute Snort.exe with one or more of three command-line switches:

• -v: This puts Snort in packet dump (sniffer) mode. With just the -v option enabled, only the network and transport layer header information will be captured and displayed, as shown in Figure 9-15.

  
  Figure 9-15: Executing Snort with the -v option captures header information only.

• -e: If you enable the -e parameter, you will get layer 2 frame headers added to the information collected. To most people, this means you’ll get ARP information. This information can be useful to ensure Honeyd is correctly emulating the MAC addresses in response to queries to its virtual IP addresses.

• -d: The -d parameter will display all payload data information from the transport layer.

The -v parameter must be used to put Snort in packet sniffer mode, but the other two options will instruct it to capture more information (you cannot use -e or -d without -v).

Most honeypot administrators use all three parameters when putting Snort in full packet sniffer mode, so the command looks something like this:

 snort.exe -vde 

(Snort accepts almost any combination of parameters, including -v -d -e or -dve, for example.)

As shown in Figure 9-16, in packet dump mode with all three parameters set, you capture the following fields (in order) on TCP packets:

• Date

• Time

• Source MAC address

• Destination MAC address

• IP protocol ID number (transport protocol type)

• Total packet length (in hex)

• Source IP address

• Source port number

• Destination IP address

• Destination port number

• Transport protocol name

• TTL setting

• Type-of-service setting

• IP packet ID

• IP header length

• Packet length

• TCP flags (represented by their the first letter of their name: S for SYN, P for PSH, A for ACK, and so on)

• Sequence number

• Acknowledgment number

• Window size

• Transport protocol header size

• Payload data

Figure 9-16: Snort in full packet capture mode

When you exit Snort by pressing Ctrl-C, it will finish with a packet statistics screen.

You can choose whether or not to log packets to a file instead of the screen, or log them to both. The -vde options capture and save packets to the screen only. If you also use the log parameter (-l <logfiledirectory>), all packet traffic will be logged to ASCII text files named after the protocol and protocol number, stored in subdirectories named after the source IP addresses involved. If you just use the -l <logfile directory> parameter (without the -vde parameters), all packets, layer 2 and up, are logged and decoded to the log folder, but packets are not displayed on the console.

Under heavy-processing loads with normal logging enabled, Snort might not be able to keep up with capturing, decoding, and writing the various log files normally distributed over the \log directory. This could lead to missed or dropped packets. Binary logging mode was added to Snort so it could capture and log packets as quickly as possible. The -b, for binary, switch will write captured traffic to a single, undecoded and unformatted file (in tcpdump file format). Its contents are, as the name implies, binary representations, as shown in Figure 9-17. Even in binary mode, the packet logging on the screen is decoded, unless the -vde switches are left off. For fastest performance, just type in the following Snort command:

 snort.exe -b -lc:\Snort\log 

Figure 9-17: A Snort binary log file

According to Snort’s documentation, with binary logging enabled, Snort is capable of handling 100 Mbps traffic. Just as with the -l switch, the -b switch captures layer 2 and above traffic automatically. You need to use the -vde parameters only to see packets on the screen.

You can import the binary log files into tcpdump-compatible programs, including Ethereal. In Ethereal, just use the File Open menu command and point to the Snort binary file. It will decode the binary file into the normal logical breakouts. This is the way I like to use Snort: capture data in Snort using binary logging, and then use Ethereal to analyze the packets. That way, I get the best of both worlds, with each tool working at its specialty.

Snort Network IDS Mode

Although Snort can be used purely as a packet sniffer, it isn’t the primary reason you should have it as part of your honeypot deployment. You should use Snort’s packet-capturing abilities, but only as a backup and secondary check of your other packet protocol analyzer (such as Ethereal). Snort’s specialty is detecting malicious content in sniffed packets.

To put Snort into its network IDS mode, you need to instruct Snort.exe to use a configuration file. Use the -c command-line parameter to point to the Snort configuration file, similar to the following example:

 snort.exe -c c:\Snort\etc\snort.conf -vde -l c:\Snort\Log 

Configuring Snort’s Configuration File

The configuration file contains commands to define the following items during Snort’s runtime:

• System variables

• Which preprocessor plug-ins to load

• Which rule sets to load

• Which output plug-ins to use

Snort comes with a default configuration file called Snort.conf, in the C:\Snort\etc directory. I recommend backing up the default Snort.conf and keeping it as an original, unmodified copy before modifying it.

The different sections are well differentiated in the configuration file. When Snort is executed with the -c parameter and pointed to an appropriate configuration file, Snort will run with those options during its execution. You can configure multiple configuration files for different tasks.

Snort Variables

The first configuration file section defines system variables, which can then be used as replacement variables throughout the rest of the configuration file (and in related rule sets). Variables are defined by using the var keyword. Variables that are set using other variables are usually prefixed by a $. You don’t need to use Snort variables, but it makes configuration and rule writing easier, and you can make your own customized variables. Table 9-1 shows the default Snort variables.

Table 9-1: Default Snort Variables

Variable	Description
HOME_NET	Local area network subnet
EXTERNAL_NET	External network address range
RULE_PATH	Path where Snort rule sets are stored
HTTP_SERVERS	IP Addresses of home web server(s)
HTTP_PORTS	Port(s) that should be scanned for web traffic
DNS_SERVERS	IP address of home DNS server(s)
SMTP_SERVERS	IP address of home SMTP server(s)
TELNET_SERVERS	IP address of home telnet server(s)
SNMP_SERVERS	IP address of home SNMP server(s)
SQL_SERVERS	IP address of home SQL server(s)
SHELLCODE_PORTS	Port(s) to scan with shellcode rule sets
AIM_SERVERS	IP address of AIM server(s) (great for detecting unauthorized IM traffic)
ORACLE_PORTS	IP address of home Oracle database server(s)

For the HOME_NET variable, you can type in one or more IP addresses, enter one or more subnet ranges, or set it to match your host machine’s IP address (using <networkinterfacename> on startup). The latter option is useful when you’re copying Snort configuration files from machine to machine, on portable machines picking up new IP addresses all the time, or on machines frequently switching networks (as might be the case with a laptop-based Snort sensor). For single IP-based honeypots, you can specify one IP address. The following HOME_NET variables use valid syntaxes:

• var HOME_NET 10.4.4.254

• var HOME_NET 10.4.4.0/24

• var HOME_NET 10.4.4.1-10.4.4.254

• var HOME_NET [10.4.4.0/24,192.168.5.0/24]

• var HOME_NET \Device\NPF_{7BB9F674-13C5-43D4-9273-05E352F77719}

• var HOME_NET any

The any variable tells Snort to treat all IP addresses—both source and destination—as belonging on the same security boundary. The any variable can be used in place of specific port numbers as well.

The EXTERNAL_NET variable uses the same syntax at the HOME_NET variable, but most Snort installations use var EXTERNAL_NET any.

The SERVER variables allow you to indicate which servers offer particular services. For example, you may want to have Snort look for only malicious HTTP traffic headed to and from your web servers.

The PORTS variables let you look for particular attack types over well-known ports. For example, I run a few of my web sites on high ports that are generally not checked by most hackers. I almost never get HTTP scans on them, but I have Snort set to detect HTTP scans on the normal ports 80 and 443, and also on those high ports. I want to know if someone has identified them as web servers and is now trying to exploit them. In fact, because I know that it took special attention to find them, and the attack is probably being done manually, I make those alerts high priority. Multiple ports are entered in sequentially and with spaces between the ports, as in this example:

 var HTTP_PORTS 80 443 8080 23000 

So, is it better to scan traffic headed to all ports and servers for all exploits, or to just scan for particular traffic bound for particular ports and servers? After all, if you can do the latter, Snort will be faster because it has less to do. There are two common schools of thought regarding this concept. One is that you want to scan for all attacks headed to or from all machines, regardless of whether that attack would ever be successful. The other side of the coin is that you might want to be aware of only attacks that might even come close to being a threat, and disregard everything as background noise. For example, if a malicious hacker sends telnet attacks against your web server (which is not running a Telnet Server service), do you care? There is no right or wrong answer; it’s your personal choice and whatever suits your security management style.

For an internal honeypot serving as an early warning system, any traffic touching it should create an alert. If you are monitoring a DMZ that is under constant assault all day long, and 99.999% of the attacks would never be successful, then filtering out the noise would probably be the answer. No one wants to sift through thousands of event warnings when they would never be a legitimate threat.

Note 

The RULE_PATH variable located in the default Snort.conf file might include a forward slash (/) at the end of each rule include statement, when it should be a backslash (\). This is due to a Unix translation problem. You’ll want to do a search and replace on any instance of the incorrect slash.

Preprocessors

After the basic decoding, packets can optionally be sent through preprocessor plug-ins. Snort plug-ins are modular pieces of code that extend the program’s preprocessing functionality, detection functionality, and output options. Preprocessor plug-ins examine and/or manipulate the packet before sending it to the signature-detection engine. Preprocessors can sort, order, and normalize the packets, although each packet is examined only once per preprocessor. Table 9-2 describes some of Snort’s preprocessors.

Table 9-2: Some Snort Preprocessors

Preprocessor	Description
Frag2	Recombines fragmented packets into their larger original packet before sending them for inspection, so malicious commands cannot be split to avoid detection. This can defeat fragmentation attacks.
Http_decode	Converts HTTP transactions into normal text. Hackers will often encode malicious commands made up of standard ASCII characters into a variety of different formats that will be converted back into ASCII by the receiving web server. Snort’s preprocessor plug-in will convert HTTP traffic into standard ASCII before passing the packet on to the detection engine for inspection. This is called normalization.
stream4	Checks TCP packets for correct statefulness and reassembles multiple segmented packets. This allows Snort to recognize or ignore malformed TCP flag combinations, if desired. Originally coded to defeat a Snort-specific DoS attack called stick (http://www.eurocompton.net/stick/projects8.html), it is useful in all sorts of stateful decisions.
Telnet_negotiation	Pulls telnet channel administration commands so that only telnet payload data is left to inspect.
Portscan	Allows you to configure what type of sequential conditions must be met before a port-scan event is noted. For example, you might specify a condition like four packets hitting sequential ports in less than one second from the same originating host.

There are plenty more preprocessor plug-ins than shown in Table 9-2. Other preprocessors include scanners for RPC, Back Orifice Trojan, ARP spoofing, shellcode detectors, and ANS1 code detection. Each has its own instructions, configuration, and syntax.

My advice to first-time Snort users is to start with no preprocessors, just to make sure Snort is running without errors before adding more functionality.

Note 

Many of the preprocessors, like Portscan, have their own logs that capture more detailed information than Snort normally reports.

Preprocessors are configured in Snort’s configuration file using this syntax:

 preprocessor <preprocessorname>: <startup options> 

Here are common examples:

 preprocessor frag2  preprocessor stream4: disable_evasion_alerts 

Once the packets have been preprocessed, they are handed off to the signature-detection engine, where most of the real work begins. The detection engine sends each packet through the various detection plug-ins and rule sets, where it is inspected byte by byte. Detection plug-ins look for specific data within a decoded packet (for example, they might look for the word victim in the payload data), and they can run multiple times per packet. If a bit sequence matches a predefined pattern, Snort execute the rule’s action. Actions can be to alert or log, or if placed inline, possibly to deny the action by dropping the packet or initiating another counter-measure.

Snort Rules

Rules are the heart of Snort. They define which packets and content Snort will look at and what occurrences will cause a noted event. Writing them is as much of a science as it is an art. Hundred-page documents detail all the different rule options that Snort has to offer. I’ll cover just the basics here, but I highly recommend that you learn more about them before you begin to write them for yourself. The Snort documentation is the best place to start.

Rules tell Snort to look at the status of different TCP flags and inspect the data payload for specific text. You can add rules one at a time to Snort.conf, or you can collect many predefined rules into an external rule set file so that Snort.conf can load rules as needed, as described in the next section.

Each rule can be added, deleted, modified, and disabled. Rules are always text on one line. The typical rule has the following syntax:

 <action> <protocol> <source network> <source port> <director> <dest network>  <des tport> (<msg: "message"> <flags:x> <content: "content to look for">;  <attack reference>; <sid:x>; <class type>;  <rev>;) 

Table 9-3 briefly describes the fields in this syntax.

Table 9-3: Snort Rule Syntax Fields

Field	Description
Action	Indicates what the rule will do when it matches a packet. The action can be Alert, Log, Pass, Activate, or Dynamic. An Alert action logs the packet to a file and creates an alert condition that is logged to a special alert log file, called alert.ids (see Figure 9-18) or follows a predefined Alert action. Alerts can be directed to real communication devices such as e-mail messages, pagers, and cell phones. The Log action writes the packet to a file, and doesn’t send an alert. The Pass action ignores the packet. The Activate action creates an alert log message, and then turns on another rule. A rule preceded by the Dynamic action awaits activation by a related Activate rule instead of acting on each packet, and when activated acts as a Log rule.
Protocol	Indicates the protocol to affect. This can be IP, ICMP, TCP, or UDP.
Source network	Indicates the IP address (or subnet range) that must be present in a packet’s source IP address field for a match to be made.
Source port	Indicates the source port number that must be present in the packet’s protocol type field. Both this and the source network field can be replaced by the any keyword or a Snort variable.
Director	An operator that determines which way the rule applies. The -> tells the rule to act on source traffic headed to destination traffic, the <- director tells the rule to act on traffic headed from destination to source, and the <> director tells the rule to search the packet no matter what its direction.
Destination network	Indicates the IP address of the destination network.
Destination port	Indicates the destination port number.
Message	Allows you to customize the text message displayed to the screen or written to a log file. Messages are preceded by the msg: syntax, and the text is included inside quotation marks. An example is msg: "Netsky virus detected". Plug-in options and their syntax can be indicated here.
Content	Indicates which byte patterns are being looked for inside the network packet. Content bytes are preceded by the content: keyword, and ASCII content is enclosed in quotation marks. For example, content: "| PASS|" might be used to search for FTP, POP, or telnet passwords, which are all preceded by the PASS keyword.
Attack reference	A note field for indicating where more information might be found for the attack type. This is helpful during an exploit event, since no one can know all the details of every attack.
Class type	A text field where you can indicate a class of attack. You can put anything here and even define your own class types. It is used purely as an informational field that can be sorted or aggregated when summarizing the event.
SID	A Snort unique rule identifier. This is the number that Snort.org uses to keep track of the rule.
Rev	The version number of the rule. The Rev field is used by the Snort development community to keep track of the version of the rule, as each revision goes through a revision-and-approval process. Snort rule update engines will use the SID and Rev fields when trying to determine which rules need updating.

Be sure to use one Alert and one Log rule that alerts when any action takes place on an early warning system honeypot. Figure 9-18 shows an example of a Snort alert file. We will cover alerting mechanisms in more detail in Chapter 10.

Figure 9-18: A Snort alert file

Rules can be quite complex, and the syntax is significantly more complicated than shown here. Consult the Snort documentation for full rule usage and syntax.

Here is an example of rules taken from Snort’s Web-IIS.rules rule set:

 alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS  (msg:"WEB-IIS unicode directory traversal attempt"; flow:to_server,established;  content:"/..%c0%af../"; nocase; classtype:web-application-attack;  reference:cve,CVE-2000-0884; sid:981; rev:6;)  alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS  (msg:"WEB-IIS +.htr code fragment attempt"; flow:to_server,established;  uricontent:"+.htr"; nocase; reference:cve,CVE-2000-0630; classtype:web- application-attack; sid:1725;  rev:3;)  alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS  (msg:"WEB-IIS MDAC Content-Type overflow attempt";  flow:to_server,established; uricontent:"/msadcs.dll"; content:"Content-Type\:";  content:!"|0A|"; within:50; reference:cve,CAN-2002-1142;  reference:url,www.foundstone.com/knowledge/randd-advisories- display.html?id=337; classtype:web-application-attack; sid:1970; rev:1;) 

Keep in mind that an excessive number of rules can slow down Snort. Be sure to comment out (precede with #) any unnecessary rules. For example, if your environment does not contain X11 network hosts, why scan packets looking for it? You can, just to see if a hacker will even try to use that exploit, but it’s probably a poor cost/benefit trade-off for most honeypot administrators.

Snort Rule Sets

Rule sets are collections of related rules and usually end with the .rules file extension. Rule sets are usually named after the category of exploit. The following are Snort’s default rule sets:

• attack-responses.rules	• policy.rules
• backdoor.rules	• pop2.rules
• bad-traffic.rules	• pop3.rules
• chat.rules	• porn.rules
• ddos.rules	• rpc.rules
• dns.rules	• rservices.rules
• dos.rules	• scan.rules
• experimental.rules	• shellcode.rules
• exploit.rules	• smtp.rules
• finger.rules	• snmp.rules
• ftp.rules	• sql.rules
• icmp-info.rules	• telnet.rules
• icmp.rules	• tftp.rules
• imap.rules	• virus.rules
• Misc.rules	• web-attacks.rules
• Multimedia.rules	• web-cgi.rules
• mysql.rules	• web-client.rules
• netbios.rules	• Web-coldfusion.rules
• nntp.rules	• Web-frontpage.rules
• oracle.rules	• web-iis.rules
• other-ids.rules	• web-misc.rules
• P2p.rules	• web-php.rules

Some rule sets are full of useful rules. Others, like virus.rules, are nearly useless in their default form. But even if the default rule set is useless, I often still use the default recognized name to put in my custom signatures that are related to a particular type of attack.

Rule sets are loaded at runtime using the following statement:

 include <ruleset name> 

For example, if you add the following statement to Snort.conf:

 include virus.rules 

the program will run all the rules within that file, which is usually tailored to catch viruses and worms.

Rule sets can be commented out (as can any other Snort configuration line) by using the # sign in front of the include command. Thus, the section of Snort that loads the different rule files might look something like this:

 include $RULE_PATH\exploit.rules  include $RULE_PATH\scan.rules  include $RULE_PATH\ftp.rules  include $RULE_PATH\telnet.rules  include $RULE_PATH\web-iis.rules  include $RULE_PATH\web-frontpage.rules  include $RULE_PATH\web-client.rules  include $RULE_PATH\icmp.rules  include $RULE_PATH\netbios.rules  # include $RULE_PATH\porn.rules  include $RULE_PATH\virus.rules  #include $RULE_PATH\experimental.rules 

Rule sets should not be loaded unless needed. Like rules themselves, excessive rule sets can significantly slow down Snort. How many are too many rules and rule sets? Again, there is no set answer. It depends on your needs and the speed of your hardware. The more CPU power you throw at Snort, the faster it can do its job. But if you notice that Snort is missing traffic that is in Ethereal, then you know it’s dropping packets and something must be modified.

Snort Output Plug-ins

The last thing we need to examine in the Snort configuration file is output plug-ins. Like preprocessor plug-ins, output plug-ins extend Snort’s default behavior.

By default, Snort can write output to the console, ASCII text files, or to binary files that can be read by tcpdump-compatible tools. Output plug-ins can be used to produce a desired output effect, including sending packet-logging messages and alert messages to different file formats, such as HTML and XML, and to different databases, such as MySQL and Syslog servers.

By default, most honeypot administrators write logs to both binary and ASCII representations. That way, you can export logs to Ethereal for examination and take a look at them with different Snort analysis tools that expect Snort logs to be in the default ASCII locations and formats.

Read Snort’s documentation to learn about all the plug-ins included and their usage and syntax.

WHY USE A VIRUS RULES SET?

The default virus.rules rule sets that accompany most Snort offerings aren’t up-to-date with the latest viruses. In fact, even the best Snort virus.rules rule sets that I’ve seen wouldn’t find 100 of the more than 60,000 different types of malicious mobile programs in existence. And the newer version of Snort is doing away with any accurate default rule sets for viruses altogether.

Why even consider using a virus.rules rule set then, you ask? Snort is great for detecting specific popular network-traveling viruses when you need a quick check. For example, when the Netsky worm (http://securityresponse.symantec.com/avcenter/venc/data/[e-mail]) came out (in February 2004), it was quickly infecting network after network. Desktop antivirus programs won’t detect a scanning worming trying to break in. They can catch a virus only after it has successfully infected the computer. The worm could infect an entire network in seconds. It takes much longer to distribute new antivirus definitions and to install patches. I had my clients configure Snort with a customized virus.rules rule set looking just for Netsky and its multiple variants. That way, if it did hit their network, Snort would act as an early warning system to let them know a successful intrusion occurred before their updating was completed.

Sample Snort Configuration File

Putting everything together in a working Snort configuration file that doesn’t cause execution errors can take practice. My advice is to start with most features turned off. Comment out the preprocessors, rule sets, and fancy variable settings. Make sure that Snort runs with a relatively clean configuration file, and then add features back in.

Here is a short Snort configuration file to start with (replace the HOME_NET variable with the appropriate IP address):

 ####################################################################  # Sample Snort Configuration file for Windows Honeypots  # Snort.conf  # Revision 1.1  var HOME_NET 10.4.4.0/24 (put your honeypot's subnet here)  var EXTERNAL_NET any  var RULE_PATH C:\Snort\rules  var AIM_SERVERS $HOME_NET  var HTTP_SERVERS $HOME_NET  var SMTP_SERVERS $HOME_NET  var TELNET_SERVERS $HOME_NET  var SQL_SERVERS $HOME_NET  var DNS_SERVERS $HOME_NET  var HTTP_PORTS 80 443 8080  #####################################################################  # load preprocessors  preprocessor frag2  preprocessor stream4: detect_scans  preprocessor stream4_reassemble  preprocessor telnet_decode  preprocessor bo: -nobrute  preprocessor portscan-ignorehosts: $DNS_SERVERS  ######################################################################  # Log all traffic-use as a secondary back up for network protocol sniffer  log ip any any <> any any (msg: "Snort Unmatched"; session: printable;)  ####################################################################  # Output plugins  output alert_full: snort_full  output alert_fast: snort_fast  output log_tcpdump: snort.log  ####################################################################  # Include the additional Rule sets you want to enable.  include C:\Snort\etc\classification.config  include C:\Snort\etc\reference.config  include $RULE_PATH\bad-traffic.rules  include $RULE_PATH\exploit.rules  include $RULE_PATH\scan.rules  include $RULE_PATH\ftp.rules  include $RULE_PATH\telnet.rules  include $RULE_PATH\rpc.rules  include $RULE_PATH\dos.rules  include $RULE_PATH\ddos.rules  include $RULE_PATH\dns.rules  include $RULE_PATH\tftp.rules  include $RULE_PATH\web-iis.rules  include $RULE_PATH\web-frontpage.rules  include $RULE_PATH\web-attacks.rules  include $RULE_PATH\web-misc.rules  include $RULE_PATH\web-client.rules  include $RULE_PATH\sql.rules  include $RULE_PATH\icmp.rules  include $RULE_PATH\netbios.rules  include $RULE_PATH\attack-responses.rules  include $RULE_PATH\snmp.rules  include $RULE_PATH\smtp.rules  include $RULE_PATH\imap.rules  include $RULE_PATH\pop3.rules  # include $RULE_PATH\virus.rules  # include $RULE_PATH\oracle.rules  # include $RULE_PATH\mysql.rules  # include $RULE_PATH\nntp.rules  # include $RULE_PATH\backdoor.rules  # include $RULE_PATH\shellcode.rules  # include $RULE_PATH\policy.rules  # include $RULE_PATH\porn.rules  # include $RULE_PATH\info.rules  # include $RULE_PATH\icmp-info.rules  # include $RULE_PATH\chat.rules  # include $RULE_PATH\multimedia.rules  # include $RULE_PATH\p2p.rules  #####################################################################  # end of Snort.conf sample configuration  ##################################################################### 

Testing the Snort Configuration File

When you get Snort installed and the configuration file configured, run the following command:

 Snort.exe -vde -T 

This command will test Snort without the configuration file being involved. If you get an error here, troubleshoot the initial installation steps.

Next, execute the following two commands and make sure that Snort reports a successful test execution:

 snort.exe -l c:\Snort\log -T  snort.exe -c c:\Snort\etc\snort.conf -T 

The first command tests Snort in packet-logging mode only; again, no configuration file is involved. The second command tells Snort to load the configuration file and check for errors.

Sometimes, Snort error messages are good, and tell you the exact file and line of code causing problems. Other times, it’s nearly impossible to tell what’s wrong. So, start small and grow larger.

Creating a Snort.bat File

As you’ve probably noticed, user-friendliness is not one of Snort’s strengths. It is a command-line program, and running Snort in its default configuration means you must learn about two dozen case-sensitive parameters and enter them on the command line or in a text-based configuration file. The following is a sample Snort command:

 snort -c snort.conf  -h 192.168.1.0/24 -dq -l c:\Honeyd\log -vyU 

This is obviously not a command that Windows GUI–loving administrators are going to embrace. The syntax can be a bit hard to remember if you haven’t executed it in awhile.

To make your life easier, you can use a batch file instead of entering the commands each time. Here’s an example of a Snort batch file:

 @@echo off  rem Snort.bat-batch file to execute Snort.exe and its normal command-line parameters  cls  C:  cd\snort\bin  c:\snort\bin\snort.exe -c C:\Snort\etc\snort.conf -l C:\Snort\log  rem ***end of Snort.bat*** 

Consider adding error-checking, and maybe other commands to simultaneously execute Ethereal and alerting mechanisms at the same time. Copy the Snort.bat file to the root directory of the drive.

Also, be aware that sometimes you want to type in Snort.bat, the whole name, instead of just, Snort, as most people do. If not, you may accidentally execute Snort.exe (without any parameters) and get startup errors. By getting in the habit of typing (or pointing to) Snort.bat, you’ll always execute the right command.

Using Snort Click-and-Point

Users who want to belong to the Snort point-and-click club can download GUI-based installers and management tools from http://www.winsnort.com or http://www.snort.org. These tools make Snort significantly easier to use.

Most of the tools are just GUI front-ends that execute the appropriate Snort commands. Because they are built on top of the Snort runtime executable, they tend to lag a bit behind the official Snort releases. Also, I would highly recommend that even GUI users understand all the commands and syntax running behind the scenes. It makes choosing the right option and troubleshooting errors easier.

No matter which Snort executable you run, every honeypot administrator should have an IDS such as Snort running as part of a honeypot setup.