Snort is an open source IPS that is capable of real-time traffic analysis and packet logging. At the core of Snort is the detection engine, which includes the preprocessors and the IPS rule base (IPS signatures). The preprocessors are used to normalize traffic, and identify network layer and transport layer protocol anomalies.
A rule is a specified set of keywords and arguments that are used as matching criteria to identify security policy violations, known network attacks, and IPS evasions. Custom rules can also be created, and added to the rule sets that ship with Snort.
Security analysts need to have a fundamental understanding of how Snort rules work. With this understanding, the analysts will have the ability to customize the rules based on the specific network environment, and be better prepared to analyze the IPS events.
A rule consists of a set of keywords and arguments that you can use as criteria to match against packets that are traversing the system. Packets that meet rule-matching criteria can signal security policy violations, attempted attacks, or network activity that you deem interesting enough to alert you when it is detected. The IPS engine compares packets against the conditions that are specified in each rule, and if the packet data matches all the conditions that are specified in a rule, an event is generated. The action field in the rule specifies what should be done next. For example, you may choose to simply raise an alert or, drop the offending packet.
Rules contain two logical sections: the rule header and the rule body.
The rule header contains the rule action, protocol, source and destination IP addresses, and source and destination port information. The following is an example rule header:
alert tcp $EXTERNAL_NET ANY -> $HTTP_SERVERS $HTTP_PORTS
The rule body consists of option keywords and parameters to define the criteria on which to trigger an event. The rule body can contain event messages, patterns that a packet payload must match to trigger the rule, and options to identify which part of the packet that the detection engine should inspect. The following is an example rule body:
(msg:"SERVER-IIS bdir.htr access"; flow:to_server,established; content:"/bdir.htr"; nocase; http_uri; metadata:ruleset community, service http; reference:bugtraq,2280; reference:nessus,10577; classtype:web-application-activity; sid:1000; rev:23;)
The rule header is the portion of the rule that identifies how to match the traffic which is based on the following criteria:
- Action (alert, drop, pass, and so on)
- Protocol (TCP, UDP, ICMP, IP)
- Source IP
- Source port
- Direction operator (the IP address and port numbers on the left side of the direction operator
->) is considered to be the source. There is also a bidirectional operator, which is indicated with a
<>symbol which tells Snort to consider the address/port pairs in either the source or destination orientation. Also, note that there is no
- Destination IP
- Destination port
Every rule header must specify these parameters.
The rule body is where the real power of the Cisco Snort rule language comes into play. In the rule body, you can drill into a packet and get to the content that actually signals malicious or suspicious activity.
Understanding the format of the body is significant because you must adhere to a very specific syntax. General syntax to be aware of includes the following:
- The entire body is enclosed in parentheses.
- Rule options end in a semicolon, including the last option.
- An option is structured as a keyword, followed by a colon, followed by an argument. If multiple arguments apply to an option, the arguments are separated by commas.The
contentoption is one of the more important features of Snort. It allows you to set rules that search for specific content (a sequence of characters or hexadecimal values) in the packet payload and trigger responses that are based on that data. To search for a string of characters, put the string in quotes. To search for a sequence of hexadecimal digits, enclose the digits in pipe ( | ) characters. Note that multiple content rules can be specified in one rule, which allows rules to be tailored for less false positives. The
contentkeyword has several modifier keywords, for example,
nocasemeans check for the content regardless of the case. In the example that is shown below, the
contentoption with match for the string “root” regardless of the case.
A rule can contain multiple content statements. Rules with multiple content statements are treated as an AND operation. For example:
content:"root"; nocase; content:"password"; nocase;
In this example, both content conditions must be met for the rule to trigger.
msgoption tells the logging and alerting engine the message to print along with a packet dump or to an alert. It is a simple text string up to 255 characters that uses the
\as an escape character to indicate a discrete character that might otherwise confuse Snort’s rules parser (such as the semi-colon ; character).
sidoption is used to uniquely identify each rule, sid 1000000 or greater is used for the locally user-defined rules.
- There are also many other rule options available to the rule developers such as the
flowoption, and so on.
In the rule example below, a connection from any source on any port going to any host defined by the variable $HOME_NET on port 23 will be checked to see if the string “root” occurs, regardless of case, the alert message will be “Suspicious Telnet!”, and the sid for this rule is 1000000.
alert tcp any any -> $HOME_NET 23 (content:"root"; nocase; msg:"Suspicious Telnet!";sid:1000000;)
This content is taken from cisco.com