The msg rule option 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 that utilizes the \ as an escape character to indicate a discrete character that might otherwise confuse Snort's rules parser (such as the semi-colon ; character).
The reference keyword allows rules to include references to external attack identification systems. The plugin currently supports several specific systems as well as unique URLs. This plugin is to be used by output plugins to provide a link to additional information about the alert produced.
Make sure to also take a look at http://www.snort.org/pub-bin/sigs-search.cgi/ for a system that is indexing descriptions of alerts based on of the sid (See Section ).
|arachnids||(currently down) http://www.whitehats.com/info/IDS|
reference:<id system>, <id>; [reference:<id system>, <id>;]
alert tcp any any -> any 7070 (msg:"IDS411/dos-realaudio"; \ flags:AP; content:"|fff4 fffd 06|"; reference:arachnids,IDS411;) alert tcp any any -> any 21 (msg:"IDS287/ftp-wuftp260-venglin-linux"; \ flags:AP; content:"|31c031db 31c9b046 cd80 31c031db|"; \ reference:arachnids,IDS287; reference:bugtraq,1387; \ reference:cve,CAN-2000-1574;)
The gid keyword (generator id) is used to identify what part of Snort generates the event when a particular rule fires. For example gid 1 is associated with the rules subsystem and various gids over 100 are designated for specific preprocessors and the decoder. See etc/generators in the source tree for the current generator ids in use. Note that the gid keyword is optional and if it is not specified in a rule, it will default to 1 and the rule will be part of the general rule subsystem. To avoid potential conflict with gids defined in Snort (that for some reason aren't noted it etc/generators), it is recommended that values starting at 1,000,000 be used. For general rule writing, it is not recommended that the gid keyword be used. This option should be used with the sid keyword. (See section )
The file etc/gen-msg.map contains contains more information on preprocessor and decoder gids.
This example is a rule with a generator id of 1000001.
alert tcp any any -> any 80 (content:"BOB"; gid:1000001; sid:1; rev:1;)
The sid keyword is used to uniquely identify Snort rules. This information allows output plugins to identify rules easily. This option should be used with the rev keyword. (See section )
The file sid-msg.map contains a mapping of alert messages to Snort rule IDs. This information is useful when post-processing alert to map an ID to an alert message.
sid:<snort rules id>;
This example is a rule with the Snort Rule ID of 1000983.
alert tcp any any -> any 80 (content:"BOB"; sid:1000983; rev:1;)
The rev keyword is used to uniquely identify revisions of Snort rules. Revisions, along with Snort rule id's, allow signatures and descriptions to be refined and replaced with updated information. This option should be used with the sid keyword. (See section )
This example is a rule with the Snort Rule Revision of 1.
alert tcp any any -> any 80 (content:"BOB"; sid:1000983; rev:1;)
The classtype keyword is used to categorize a rule as detecting an attack that is part of a more general type of attack class. Snort provides a default set of attack classes that are used by the default set of rules it provides. Defining classifications for rules provides a way to better organize the event data Snort produces.
alert tcp any any -> any 25 (msg:"SMTP expn root"; flags:A+; \ content:"expn root"; nocase; classtype:attempted-recon;)
Attack classifications defined by Snort reside in the classification.config file. The file uses the following syntax:
config classification: <class name>,<class description>,<default priority>
These attack classifications are listed in Table . They are currently ordered with 4 default priorities. A priority of 1 (high) is the most severe and 4 (very low) is the least severe.
|attempted-admin||Attempted Administrator Privilege Gain||high|
|attempted-user||Attempted User Privilege Gain||high|
|inappropriate-content||Inappropriate Content was Detected||high|
|policy-violation||Potential Corporate Privacy Violation||high|
|shellcode-detect||Executable code was detected||high|
|successful-admin||Successful Administrator Privilege Gain||high|
|successful-user||Successful User Privilege Gain||high|
|trojan-activity||A Network Trojan was detected||high|
|unsuccessful-user||Unsuccessful User Privilege Gain||high|
|web-application-attack||Web Application Attack||high|
|attempted-dos||Attempted Denial of Service||medium|
|attempted-recon||Attempted Information Leak||medium|
|bad-unknown||Potentially Bad Traffic||medium|
|default-login-attempt||Attempt to login by a default username and password||medium|
|denial-of-service||Detection of a Denial of Service Attack||medium|
|non-standard-protocol||Detection of a non-standard protocol or event||medium|
|rpc-portmap-decode||Decode of an RPC Query||medium|
|successful-dos||Denial of Service||medium|
|successful-recon-largescale||Large Scale Information Leak||medium|
|suspicious-filename-detect||A suspicious filename was detected||medium|
|suspicious-login||An attempted login using a suspicious username was detected||medium|
|system-call-detect||A system call was detected||medium|
|unusual-client-port-connection||A client was using an unusual port||medium|
|web-application-activity||Access to a potentially vulnerable web application||medium|
|icmp-event||Generic ICMP event||low|
|network-scan||Detection of a Network Scan||low|
|not-suspicious||Not Suspicious Traffic||low|
|protocol-command-decode||Generic Protocol Command Decode||low|
|string-detect||A suspicious string was detected||low|
|tcp-connection||A TCP connection was detected||very low|
The classtype option can only use classifications that have been defined in snort.conf by using the config classification option. Snort provides a default set of classifications in classification.config that are used by the rules it provides.
The priority tag assigns a severity level to rules. A classtype rule assigns a default priority (defined by the config classification option) that may be overridden with a priority rule. Examples of each case are given below.
alert tcp any any -> any 80 (msg:"WEB-MISC phf attempt"; flags:A+; \ content:"/cgi-bin/phf"; priority:10;) alert tcp any any -> any 80 (msg:"EXPLOIT ntpdx overflow"; \ dsize:>128; classtype:attempted-admin; priority:10 );
The metadata tag allows a rule writer to embed additional information about the rule, typically in a key-value format. Certain metadata keys and values have meaning to Snort and are listed in Table . Keys other than those listed in the table are effectively ignored by Snort and can be free-form, with a key and a value. Multiple keys are separated by a comma, while keys and values are separated by a space.
|engine||Indicate a Shared Library Rule||"shared"|
|soid||Shared Library Rule Generator and SID||gid4#4sid|
|service||Target-Based Service Identifier||"http"|
The examples below show an stub rule from a shared library rule. The first uses multiple metadata keywords, the second a single metadata keyword, with keys separated by commas.
metadata:key1 value1; metadata:key1 value1, key2 value2;
alert tcp any any -> any 80 (msg:"Shared Library Rule Example"; \ metadata:engine shared; metadata:soid 3|12345;) alert tcp any any -> any 80 (msg:"Shared Library Rule Example"; \ metadata:engine shared, soid 3|12345;) alert tcp any any -> any 80 (msg:"HTTP Service Rule Example"; \ metadata:service http;)
The msg keyword tells the logging and alerting engine the message to print with the packet dump or alert.
The reference keyword allows rules to include references to external attack identification systems.
The gid keyword (generator id) is used to identify what part of Snort generates the event when a particular rule fires.
The sid keyword is used to uniquely identify Snort rules.
The rev keyword is used to uniquely identify revisions of Snort rules.
The classtype keyword is used to categorize a rule as detecting an attack that is part of a more general type of attack class.
The priority keyword assigns a severity level to rules.
The metadata keyword allows a rule writer to embed additional information about the rule, typically in a key-value format.