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.
logto:"filename";
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 two available argument keywords for the session rule option, printable or all. The printable keyword only prints out data that the user would normally see or be able to type.
The all keyword substitutes non-printable characters with their hexadecimal equivalents.
session: [printable|all];
The following example logs all printable strings in a telnet packet.
log tcp any any <> any 23 (session:printable;)
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 resp keyword is used to attempt to close sessions when an alert is triggered. In Snort, this is called flexible response.
Flexible Response supports the following mechanisms for attempting to close sessions:
| Option | Description |
| rst_snd | Send TCP-RST packets to the sending socket |
| rst_rcv | Send TCP-RST packets to the receiving socket |
| rst_all | Send TCP_RST packets in both directions |
| icmp_net | Send a ICMP_NET_UNREACH to the sender |
| icmp_host | Send a ICMP_HOST_UNREACH to the sender |
| icmp_port | Send a ICMP_PORT_UNREACH to the sender |
| icmp_all | Send all above ICMP packets to the sender |
These options can be combined to send multiple responses to the target host.
resp: <resp_mechanism>[,<resp_mechanism>[,<resp_mechanism>]];
This functionality is not built in by default. Use the - -enable-flexresp flag to configure when building Snort to enable this functionality.
Be very careful when using Flexible Response. It is quite easy to get Snort into an infinite loop by defining a rule such as:
alert tcp any any -> any any (resp:rst_all;)
It is easy to be fooled into interfering with normal network traffic as well.
The following example attempts to reset any TCP connection to port 1524.
alert tcp any any -> any 1524 (flags:S; resp:rst_all;)
This keyword implements an ability for users to react to traffic that matches a Snort rule. The basic reaction is blocking interesting sites users want to access: New York Times, slashdot, or something really important - napster and any inappropriate sites. The React code allows Snort to actively close offending connections and send a visible notice to the browser. The notice may include your own comment. The following arguments (basic modifiers) are valid for this option:
The basic argument may be combined with the following arguments (additional modifiers):
port_nr
- use the proxy port to send the visible notice
Multiple additional arguments are separated by a comma. The react keyword should be placed as the last one in the option list.
react: block[, <react_additional_modifier>];
alert tcp any any <> 192.168.1.0/24 80 (content: "bad.htm"; \
msg: "Not for children!"; react: block, msg, proxy 8000;)
React functionality is not built in by default; you must configure with -enable-react to build it. (Note that react may now be enabled independently of flexresp and flexresp2.)
Be very careful when using react. Causing a network traffic generation loop is very easy to do with this functionality.
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.
Currently, the database output plugin, described in Section ![[*]](crossref.png)
, does not properly handle tagged alerts.
tag: <type>, <count>, <metric>, [direction];
metric field.
count packets
count seconds
count bytes
Note, any packets that generate an alert will not be tagged. For example, it may seem that the following rule will tag the first 600 seconds of any packet involving 10.1.1.1.
alert tcp any any <> 10.1.1.1 any (tag:host,600,seconds,src;)
However, since the rule will fire on every packet involving 10.1.1.1, no packets will get tagged. The flowbits option would be useful here.
alert tcp any any <> 10.1.1.1 any (flowbits:isnotset,tagged;
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,12; tag:session,10,seconds;)
The activates keyword allows the rule writer to specify a rule to add
when a specific network event occurs. See Section for more
information.
activates: 1;
The activated_by keyword allows the rule writer to dynamically enable
a rule when a specific activate rule is triggered. See Section for more information.
activated_by: 1;
The count keyword must be used in combination with the
activated_by keyword. It allows the rule writer to specify how many
packets to leave the rule enabled for after it is activated. See Section
for more information.
activated_by: 1; count: 50;
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.
See section for more on operating in inline mode.
replace: <string>;
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>;
| Option | Description |
| track by_src|by_dst | 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. |
| count c | The maximum number of rule matches in s seconds allowed before the detection filter limit to be exceeded. C must be nonzero. |
| seconds s | 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.
| Keyword | Description |
| logto | The logto keyword tells Snort to log all packets that trigger this rule to a special output log file. |
| session | The session keyword is built to extract user data from TCP Sessions. |
| resp | The resp keyword is used attempt to close sessions when an alert is triggered. |
| react | This keyword implements an ability for users to react to traffic that matches a Snort rule by closing connection and sending a notice. |
| tag | The tag keyword allow rules to log more than just the single packet that triggered the rule. |
| activates | This keyword allows the rule writer to specify a rule to add when a specific network event occurs. |
| activated_by | This keyword allows the rule writer to dynamically enable a rule when a specific activate rule is triggered. |
| count | This keyword must be used in combination with the activated_by keyword. It allows the rule writer to specify how many packets to leave the rule enabled for after it is activated. |
| replace | Replace the prior matching content with the given string of the same length. Available in inline mode only. |
| detection_filter | Track by source or destination IP address and if the rule otherwise matches more than the configured rate it will fire. |