Search Site

Search Rules

Account

email
password

not registered?

can't login?

user preferences

3.7 Post-Detection Rule Options

3.7.1 logto

The logto option 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 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.

3.7.2.1 Format

session: [printable|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;)

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.

3.7.3 resp

The resp keyword is used 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.

3.7.3.1 Format

resp: <resp_mechanism>[,<resp_mechanism>[,<resp_mechanism>]];

3.7.3.2 Warnings

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.

3.7.3.3 Example

The following example attempts to reset any TCP connection to port 1524.

alert tcp any any -> any 1524 (flags:S; resp:rst_all;)

3.7.4 react

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 porn sites. The React code allows Snort to actively close offending connections and/or send a visible notice to the browser. The notice may include your own comment. The following arguments (basic modifiers) are valid for this option:

• block - close connection and send the visible notice
• warn - send the visible, warning notice (will be available soon)

The basic argument may be combined with the following arguments (additional modifiers):

• msg - include the msg option text into the blocking visible notice
• proxy: $<$port_nr$>$ - use the proxy port to send the visible notice (will be available soon)

Multiple additional arguments are separated by a comma. The react keyword should be placed as the last one in the option list.

3.7.4.1 Format

react: <react_basic_modifier[, react_additional_modifier]>;

Figure: React Usage Example

3.7.4.2 Warnings

React functionality is not built in by default. This code is currently bundled under Flexible Response, so enabling Flexible Response (-enable-flexresp) will also enable React.

Be very careful when using react. Causing a network traffic generation loop is very easy to do with this functionality.

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. Currently, the database output plugin, described in Section , does not properly handle tagged alerts.

3.7.5.1 Format

tag: <type>, <count>, <metric>, [direction]

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

- 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

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 <> any 10.1.1.1 (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 <> any 10.1.1.1 (flowbits:isnotset,tagged; 
    flowbits:set,tagged; tag:host,600,seconds,src;)

3.7.5.2 Example

This example logs the first 10 seconds of any telnet session.

alert tcp any any -> any 23 (flags:s,12; tag:session,10,seconds;)

site feedback | Terms of Use | Privacy Policy | forum archives ©2008 Snort and Sourcefire are registered trademarks of Sourcefire, Inc. All rights reserved.