The alert action causes the activity to be logged as well. There is a separate action, log, which only logs the triggered activity. When activity is logged, it is recorded in a human readable format that can provide more verbose information about the packet, such as the payload. The logged packets are written to files and directories based on the IP addresses in the packet being logged. These are further segregated by the transport layer protocol and source and destination ports involved in the connection. Look at the contents of FTP activity that was logged:

[**] Attempted anonymous ftp access [**] 04/24-12:11:08.724441 192.168.143.15:3484 -> 192.168.143.16:21

The logged output contains the same information that the alert does, but it also has the payload if the decode (-d) command-line option was supplied. This message indicates that we have a rule to inspect ftp command-line traffic to destination port 21 for a user of anonymous. We will examine how this is accomplished in Chapter 14, "Snort Rules—Part II," but the payload from the previous output indicates that there was an anonymous user attempt. The hexadecimal representations of the ASCII values in the payload are also included in the logged packet.

The log and alert files can be a cumbersome way of analyzing output from Snort, so it allows you other options via configuration file changes. Activating available output options can enable writing output or alerts to spool files via a backend known as Barnyard, or directly to a database, to name a few of the possible options.

Snort Rules

Snort supports both header and payload inspection methods, allowing you to fully specify in a single rule what is considered a suspect packet. This flexibility allows you to build rules customized to your site that greatly aid in minimizing false positives, but in a format that is very readable. Remember all the heartache and toil involved in writing TCPdump filters, especially one to inspect a packet for a particular TCP flag setting? Well, writing an identical rule in Snort is almost trivial, as you will soon see.

As a short but important digression, what qualities does one look for in a good NIDS? There are many, but one of the most important is the capability to inspect and alter signatures. Believe it or not, there are NIDS available that do not allow the user to see the active signatures or alter them in any way. This blindsides the analyst and does not allow her to distinguish between false positives and real alerts. When an alert appears, it is presented as an irrefutable statement that a problem has appeared, and there is no way to validate it using the NIDS alone. If the analyst can examine the signatures and the packet that caused the alert, there is a better chance that a more accurate assessment can be made.

Additionally, signatures that allow an analyst to look at any field, either header or payload, from different perspectives potentially improve the quality of the NIDS. In other words, if a NIDS only allows the analyst to create rules that inspect packets for a given IP or port or protocol, it lacks the range to examine payloads or header fields on a more granular level such as TCP flag settings. Perhaps the analyst is interested in inspecting the payload for specific contents when the acknowledgement flag is set. Because other flags may be set along with the acknowledgement flag, it would be handy for the signature to allow for this specification as well.

The capability to inspect just about any field in a packet is an area in which Snort excels. There are many options available to configure a rule to specify just about any field in the packet and examine the value of that field in a variety of ways. And, the few fields that cannot be inspected via current Snort rule options can always be examined by supplying a filter at the end of the command line or by resorting to a command-line switch (-F) that allows Berkeley Packet Filters (BPF) to be specified in a file. Berkeley Packet Filters are what we have been calling TCPdump filters, which can be used to select the desired field. For instance, Snort doesn't have an option to examine the IP version field found in the highorder nibble of the zero byte offset of the IP header. Snort might be run to examine packets off the wire or from a binary file of captured TCPdump data using a BPF filter to find any packets with an IP version that does not equal 4. Here is the command that would

perform this inspection reading packets from the network: snort –v 'ip[0] & 0xf0 != 0x40'

As explained in more detail in Chapter 12, "Writing TCPdump Filters," this will mask out the low-order nibble of the zero byte offset of the IP header and look for a value of 4 in the high-order nibble of that field and write the output to the screen (-v).

Another benefit of using Snort is that it comes with a very large set of rules. It is not recommended that all of the rules be used on installation because the more active rules used, the slower the traffic inspection becomes. The analyst must decide which rules are appropriate for the site. And, amazingly, new Snort rules are released sometimes as soon as hours after a new exploit is discovered. This is by virtue of having so many savvy users and developers of Snort who respond almost instantly to develop and test new rules for these exploits.

However, a word of caution must be added about some Snort rules. Just because a rule becomes available shortly after an exploit is released, doesn't mean that it is a good rule—that is to say, just because a rule matches a given compiled version of an exploit's output doesn't mean that it is necessarily a rule that may find variations of the exploit from making minor changes in the source code. It is imperative that the rule writer understands not only the exploit code and output, but also the protocol against which it runs.

A good rule anchors on fields and values that must remain static for the exploit to succeed. For instance, if there is some kind of DNS exploit that generates a DNS identification number of 0xBEEF, this is not a good field or value to use in the rule. It is trivial to change this in the source code, and the exploit will most likely succeed regardless of the value of the DNS identification number.

Hidden Signatures

As a contractor for a client, I once had the opportunity to visit a commercial NIDS vendor about integrating output from its NIDS to some kind of correlation tool. Frankly, I believed the output from the NIDS wasn't worth trying to correlate since there was no way to validate if the generated alerts were real because there was no access to either the signatures or the packets that caused the alert. Why synthesize garbage? But, the client had requested my presence at the meeting, so I dutifully attended.

While there, I asked if there was any way that we could get access to the signatures. The vendor rep balked and asked why I would ever need to see the signatures. "Well, I want to know if we have a real detect or false positive," I politely responded. The rep replied that if I believed we had seen a rare false positive, I could call the support line and ask for help. With the number of false positives generated by the vendor's NIDS, I could only imagine that it had stock in the Baby Bells to answer so foolishly. Indignantly, I pressed on and asked the rep what the problem was with releasing his signatures. The response was that if I could see the signatures, so could the hackers! Honest to goodness, that was the best dog-ate-my-homework excuse he could come up with. More than anything, I suspect it was that he feared that the competition might pirate his product's signatures, but he didn't have the spine to say that. How are you supposed to take these guys and their proprietary signatures seriously? Okay, so we're not all blessed with the power to either make or influence the decision of which NIDS to buy. What if you happen to work at a site where you have a NIDS that has either a limited or no view of the signatures and traffic—do you throw in the towel? Well, if lobbying for a better NIDS fails, you can become resourceful! You can always run TCPdump in the background mode either alone or as part of Shadow. Or, you can try to do correlation with other sources of information such as firewalls, routers, or host logs. This is not ideal, but it prevents you from being totally blind.

We were running Shadow along with the deficient NIDS mentioned previously. An analyst called me to report that the NIDS was alerting on a Loki attack and asked if I could examine the TCPdump output to discover whether this was a real alert or not. I knew that Loki had a telltale signature years ago of a value of 0xf001 or 0x01f0 in the ICMP sequence number. The analyst was able to give me the source and destination IP numbers for the suspected Loki traffic. I searched the TCPdump records and discovered ICMP packets that matched the signature; however, this was just a case of coincidental use of those values in the ICMP sequence number in an innocuous ICMP echo request/response pair. This was an awkward and time-consuming way of dealing with this false positive, but it was better than putting full trust in the NIDS.

Snort Rule Anatomy

An individual rule is broken into two general parts. The first part, the rule header, defines who must be involved in order for the traffic to be considered by the rule options. The second part, the rule options, defines what must be involved. This includes packet header information (such as TCP flag settings) or the contents of the payload.

Generally speaking, both sections are used for most rules. It is possible to specify rules with only a rule header so that the given action can be taken for the provided hosts and ports. This is typically the case where pass rules are used to ignore traffic between specific hosts and ports, such as port 53 traffic coming from a site's DNS servers.

All conditions specified in both the rule header and the rule options must be true in order

for an alert or some other kind of action to be triggered. It is also important to understand the Snort rules are stateless. In other words, each rule inspects one and only one packet. The rules themselves have no way of knowing what activity occurred in a packet preceding or following the current one. Snort attempts to build in functionality for state using a preprocessor such as IP defragmentation or TCP stream reassembly, but there are limits to what can be discovered when not examining traffic statefully.

Also, Snort triggers on the first rule that a packet matches and does not examine the remaining rules. The order that rules are listed in the rules files is important, but Snort does some ordering of its own. By default, Snort orders all rules by their action value in the following order: alert, pass, and log. This can be overridden by a command-line option that will be discussed later in the section, "The Action Field." However, Snort does some further ordering by grouping identical headers that is beyond the scope of this chapter. For more

information, see www.snort.org/docs/faq.html#3.13.

Look at Figure 13.1 to see a sample Snort rule.

Figure 13.1. The anatomy of a Snort rule.

You see a rule header that gives the details of the action to be taken if the rule triggers and the information pertaining to the who values in the packet. In this rule, we alert when TCP traffic is observed that originates from a network that is not 10.1.1.x from any source port destined for network 10.1.1.x to any destination port. We assume that our internal network is the 10.1.1.x network, so this rule triggers when an outsider attempts to make an internal TCP connection.

If you turn your attention to the rule options, we further specify the what of the packet attributes. In this instance, the anomalous TCP flag pair of SYN and FIN is sought, and if found, a message of "SYN-FIN scan" is associated with the alert. The rules keywords will be described more thoroughly in the following sections.

Rumor has it that the rules syntax will change radically when Snort version 2.0 makes its debut. So, if you are reading this chapter after the release of Snort 2.0, it is best to refer to Snort documentation because the information presented here might be obsolete.

Rule Header Fields

As briefly mentioned, the rule header is responsible for specifying the action used to respond to a triggered rule, as well as specifying the protocol and source and destination addresses and ports. These who conditions must be met if the rule options are to be examined. Rule options will be explored in Chapter 14.

The Action Field

The first field in the rule header is the action field. This field instructs Snort on what to do if the rule is triggered. The valid values for the action field are the following:

●Alert. This value instructs Snort to create an entry in the alert file and to log the packet as well. The alert file is a single file that contains all detects that were made. The information written to this file in the default alert mode consists only of the packet header information. For the log entry, the same information (optionally including the payload if the -d command-line option is specified) that is written to the alert file is written to individual files found in a directory that usually has the name of the hostile IP number.

●Log. This value instructs Snort to only make a log entry. No record of the traffic is made in the alert file when the log action is used. The log files might have data from