The logto keyword tells Snort to log all packets that trigger this rule to a special output log file. This is especially handy for combining data from things like NMAP activity, HTTP CGI scans, etc. It should be noted that this option does not work when Snort is in binary logging mode.
The session keyword is built to extract user data from TCP Sessions. There are many cases where seeing what users are typing in telnet, rlogin, ftp, or even web sessions is very useful.
There are three available argument keywords for the session rule option: printable, binary, or all.
The printable keyword only prints out data that the user would normally see or be able to type. The binary keyword prints out data in a binary format. The all keyword substitutes non-printable characters with their hexadecimal equivalents.
The following example logs all printable strings in a telnet packet.
log tcp any any <> any 23 (session:printable;)
Given an FTP data session on port 12345, this example logs the payload bytes in binary form.
log tcp any any <> any 12345 (metadata:service ftp-data; session:binary;)
Using the session keyword can slow Snort down considerably, so it should not be used in heavy load situations. The session keyword is best suited for post-processing binary (pcap) log files.
The binary keyword does not log any protocol headers below the application layer, and Stream reassembly will cause duplicate data when the reassembled packets are logged.
The resp keyword enables an active response that kills the offending session. Resp can be used in both passive or inline modes. See for details.
The react keyword enables an active response that includes sending a web page or other content to the client and then closing the connection. React can be used in both passive and inline modes. See for details.
The tag keyword allow rules to log more than just the single packet that triggered the rule. Once a rule is triggered, additional traffic involving the source and/or destination host is tagged. Tagged traffic is logged to allow analysis of response codes and post-attack traffic. tagged alerts will be sent to the same output plugins as the original alert, but it is the responsibility of the output plugin to properly handle these special alerts.
tag:host, <count>, <metric>, <direction>; tag:session[, <count>, <metric>][, exclusive];
Note that neither subsequent alerts nor event filters will prevent a tagged packet from being logged. Subsequent tagged alerts will cause the limit to reset.
alert tcp any any <> 10.1.1.1 any \ (flowbits:isnotset,tagged; content:"foobar"; nocase; \ flowbits:set,tagged; tag:host,600,seconds,src;)
Also note that if you have a tag option in a rule that uses a metric other than packets, a tagged_packet_limit will be used to limit the number of tagged packets regardless of whether the seconds or bytes count has been reached. The default tagged_packet_limit value is 256 and can be modified by using a config option in your snort.conf file (see Section on how to use the tagged_packet_limit config option). You can disable this packet limit for a particular rule by adding a packets metric to your tag option and setting its count to 0 (This can be done on a global scale by setting the tagged_packet_limit option in snort.conf to 0). Doing this will ensure that packets are tagged for the full amount of seconds or bytes and will not be cut off by the tagged_packet_limit. (Note that the tagged_packet_limit was introduced to avoid DoS situations on high bandwidth sensors for tag rules with a high seconds or bytes counts.)
alert tcp 10.1.1.4 any -> 10.1.1.1 any \ (content:"TAGMYPACKETS"; tag:host,0,packets,600,seconds,src;)
This example logs the first 10 seconds or the tagged_packet_limit (whichever comes first) of any telnet session.
alert tcp any any -> any 23 (flags:S,CE; tag:session,10,seconds;)
While at least one count and metric is required for tag:host, tag:session with exclusive without any metrics can be used to get a full session like this:
pass tcp any any -> 192.168.1.1 80 (flags:S; tag:session,exclusive;)
The replace keyword is a feature available in inline mode which will cause Snort to replace the prior matching content with the given string. Both the new string and the content it is to replace must have the same length. You can have multiple replacements within a rule, one per content.
detection_filter defines a rate which must be exceeded by a source or destination host before a rule can generate an event. detection_filter has the following format:
detection_filter: \ track <by_src|by_dst>, \ count <c>, seconds <s>;
Rate is tracked either by source IP address or destination IP address. This means count is maintained for each unique source IP address or each unique destination IP address.
The maximum number of rule matches in s seconds allowed before the detection filter limit to be exceeded. C must be nonzero.
Time period over which count is accrued. The value must be nonzero.
Snort evaluates a detection_filter as the last step of the detection phase, after evaluating all other rule options (regardless of the position of the filter within the rule source). At most one detection_filter is permitted per rule.
Example - this rule will fire on every failed login attempt from 10.1.2.100 during one sampling period of 60 seconds, after the first 30 failed login attempts:
drop tcp 10.1.2.100 any > 10.1.1.100 22 ( \ msg:"SSH Brute Force Attempt"; flow:established,to_server; \ content:"SSH"; nocase; offset:0; depth:4; \ detection_filter:track by_src, count 30, seconds 60; \ sid:1000001; rev:1;)
Since potentially many events will be generated, a detection_filter would normally be used in conjunction with an event_filter to reduce the number of logged events.
|Note: As mentioned above, Snort evaluates detection_filter as the last step of the detection and not in post-detection.|
The logto keyword tells Snort to log all packets that trigger this rule to a special output log file.
The session keyword is built to extract user data from TCP Sessions.
The resp keyword is used attempt to close sessions when an alert is triggered.
This keyword implements an ability for users to react to traffic that matches a Snort rule by closing connection and sending a notice.
The tag keyword allow rules to log more than just the single packet that triggered the rule.
Replace the prior matching content with the given string of the same length. Available in inline mode only.
Track by source or destination IP address and if the rule otherwise matches more than the configured rate it will fire.