does not use ports like TCP and UDP. The rule syntax requires ports, so you must specify some kind of placeholder value. Although no port value makes sense, the value "any" is often used. Let's look at some possible port values.

Direction Indicator

The traffic direction field allows you to indicate the direction the packet must be traveling. Two options are available, allowing you to indicate a specific direction of flow, or that direction doesn't matter. Using the notation that looks like an arrow (->), the packet must be traveling from a source to a destination. The source information is specified to the left of the arrow, and the destination is to the right. The packet must be traveling in the listed direction; if it is traveling in the opposite direction, the packet will not pass the rule header test and will not be inspected any further against the rule.

If you use the notation that looks similar to a double-headed arrow (<>), the packet can be traveling to or from either address/port pair. For this notation, either side can represent the source or destination depending on the packet flow in the connection.

Summary

Snort provides a very good NIDS at no cost for the software. Understand that although it is free to use, there are costs associated with the hardware, as well as costs associated with customizing rules and making sense of the output. Snort is most useful when run in packetsniffing mode where it compares the network traffic against a set of rules. This can be done either in real-time mode, or traffic can be captured in binary format and retrospectively analyzed later by feeding it back into Snort as an input file.

Snort rules provide a flexible and easily configurable means of specifying most header fields to inspect, as well as analyzing any data in the payload. The rules allow the user many different ways to indicate values for particular fields in addition to permitting the use of variables to represent values. Snort rules also provide the granularity necessary to be very explicit about the attributes of the packet that are to be inspected or ignored. The result is that there should be far fewer false positives and false negatives if the rules are properly configured for the site.

Chapter 14. Snort Rules - Part II

The previous chapter provided an introduction to Snort, in general, and Snort rules. As you will recall, a Snort rule is composed of a rule header, which was examined in detail in the previous chapter, and a rule option, which will be covered thoroughly in this chapter.

The rule header supplies the action that will be applied if the rule is triggered. It details the source and destination IP addresses and ports, the protocol, and the direction of the traffic flow. The rule header can be used alone to form a rule, but it is usually followed by a rule option to provide more detail about the packet attributes. Ironically, there are some commercial NIDS that only allow the same level of detail as a Snort rule header when specifying a signature. In other words, they don't allow the user to configure much more than the IP addresses, protocol, and TCP or UDP ports to define a signature. Obviously,