The following is an example of the format of the mesg directive in use:Īlert tcp $EXTERNAL_NET any -> $SMTP_SERVERS 25 (msg:"SMTP sendmail 5.5.5 exploit" flow:to_server,established content:"mail from|3a20227c|" nocase reference:arachnids,119 classtype:attempted-admin sid:662 rev:4 ) By looking through the rules directory, you can see that the fabricators of the rules file have added messages to almost all the entries that they include. The mesg option creates a customized output message that can be included with any logs, alerts, and data dumps processed by the detection engine. After some analysis and a firmer understanding of the events takes shape, Snort's rules are then revised (often only subtly) to reflect what's known about the event. Sometimes, rules are quickly added during the heat of a malicious event so that immediate visibility is provided to the security managers who must monitor the attack. Busy enterprise networks are sometimes hostile and fast-paced environments.
Very few rules that come with Snort (less than 10 percent) have a revision number of only 1.
#Snort rules software#
The software industry uses many version management schemes because the field is so fluid and so dynamic that tight change control is almost a necessity. The Snort people thought ahead and even included a way to keep a version tracking on each individual rule. Table 8-4 Priority 3 Classifications (Low Severity) Limited information collection (reconnaissance)Ī client was abnormally using a network portĪccess was made to a potentially vulnerable Table 8-3 Priority 2 Classifications (Intermediate Severity)Īttempted information collection (reconnaissance)ĭenial-of-service attack possibly underwayĭetection or use of a nonstandard protocol Unsuccessful-user Failed privilege escalation to a User levelĪttack Identified an attack upon a Web server's application software
#Snort rules code#
Priority 1 Classifications (Critical Severity)Īttempted privilege escalation to an Administrator levelĪttempted privilege escalation to a User levelĪchieved successful privilege escalation to an Administrator levelĪchieved successful privilege escalation to a User levelĭiscovered software code of a Trojan Network Attack A few dozen different classification types are spread over three priority levels, which are described in Tables 8-2, 8-3 and 8-4. The classtype option can organize rules into major groups. For example, the following command assigns the rule associated with it the highest priority: 1. By using the priority option, you can override Snort's default level and rate how important or impacting a particular rule is to your unique environment. Snort has a built-in numerical rating for many of the rules that it ships with: The lower the priority number, the higher the risk posed by the attack that tripped the rule. Table 8-1 Snort ID (sid) Valuesġ,000,000 + For use in customizing your own Snort rulesġ,000,000 + For use in customizing your own Snort rules Priority Table 8-1 gives you a breakdown of the uses for sid ranges.
That way, updates to the Snort rule base won't accidentally collide with your custom rule. When you get the hang of building your own sets of rules, assign each custom rule a unique sid number somewhere above the 1,000,000 mark. For example, a proper usage is as follows: The format of the Snort ID value is the same as it as other classification options. The Snort ID (sid) option is unique to the Snort system and a good way to get a handle on classifications. Quite a few options help organize and classify detected alerts. These options include the Snort ID, the alert message to appear in the alert log, the rule revision number, the alert priority, the alert classification, and external references for the exploit or vulnerability that triggered the alert. The classification options provide an overall description of a rule, along with other helpful information about the rule, that can be used by the Snort program itself and a system administrator.