3.7 Post-Detection Rule Options

3.7.1 logto

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.

3.7.1.1 Format

    logto:"filename";

3.7.2 session

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.

3.7.2.1 Format

    session:[printable|binary|all];

3.7.2.2 Example

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;)

3.7.2.3 Warnings

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.

3.7.3 resp

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.

3.7.4 react

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.

3.7.5 tag

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.

3.7.5.1 Format

    tag:host, <count>, <metric>, <direction>;
    tag:session[, <count>, <metric>][, exclusive];

type

 

• session - Log packets in the session that set off the rule

• host - Log packets from the host that caused the tag to activate (uses [direction] modifier)

count

 

• <integer> - Count is specified as a number of units. Units are specified in the $<$metric$>$ field.

metric

 

• packets - Tag the host/session for $<$count$>$ packets
• seconds - Tag the host/session for $<$count$>$ seconds
• bytes - Tag the host/session for $<$count$>$ bytes

other

• src - Tag packets containing the source IP address of the packet that generated the initial event. Only relevant if host type is used.

• dst - Tag packets containing the destination IP address of the packet that generated the initial event. Only relevant if host type is used.

• exclusive - Tag packets only in the first matching session. Only relevant if session type is used.

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;)

3.7.5.2 Example

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;)

3.7.6 replace

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.

    replace:"<string>";

3.7.7 detection_filter

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.

Note:   As mentioned above, Snort evaluates detection_filter as the last step of the detection and not in post-detection.

3.7.8 Post-Detection Quick Reference

Table: Post-detection rule option keywords

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.
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.