Dynamic Rules

2017-11-03 09:05:02

Problem

I need to analyze a connection to verify whether it's an attack or normal traffic. How can Snort help?

Solution

Snort has a couple of answers to your question. First, there is a keyword activate and its complementary keyword dynamic. When a rule marked activate is triggered, it turns on a corresponding dynamic rule to capture the exploit, log the next couple of packets, etc.

activate tcp $EXTERNAL_NET any -> any 23 (msg:"Solaris TTYPROMPT expoit";content:"TTYPROMPT";depth:17;content:"|20|63|"; flow:to_server,established;sid:10555;reference:url: packetstormsecurity.org/0210-exploits/telnet.c; rev:1; activates:1;) dynamic tcp $EXTERNAL_NET any -> any 23 (activated_by: 1; count:50;)

For example, the previous rule will trigger on a single exploit packet such as most Snort rules. However, this rule then calls its dynamic partner to log the next 50 packets to port 23 tcp, which is useful in capturing the results of a successful exploit of a victim system.

However, as you might have realized that this could get unmanageable with only a few rules. It's also not very scalable. So Snort is slowly replacing those keywords with the tagging keyword. This provides a much simpler method to log attack responses. Here is the same rule changed to the new keywords.

alert tcp $EXTERNAL_NET any -> any 23 (msg:"Solaris TTYPROMPT expoit"; content:"TTYPROMPT"; depth:17; content:"|20|63|"; flow:to_server, established; sid:10555; reference:url:packetstormsecurity.org/0210-exploits/ telnet.c; rev:1; tag:session:50,packets;)

This example captures the same event as the activate rules with only one rule. This example uses the tag keyword to capture the next 50 packets over port 23 tcp with one addition, accuracy. The tag keyword tells Snort to log the next 50 packets in the same session between attacker and victim, ignoring other port 23 traffic on the network.

Discussion

There are several options to the tagging keyword that might be more helpful to some organizations. For example, the ability to log only the attacker side of the connection or to limit the log based on time or number of packets.

This modification of the same rule is going to log only the next 50 packets to our victim machine using some of the options for the tag keyword. The options to the tag keyword are used to create a more accurate and filtered logfile. For example, if you only want to see one side of an attack as in the following, record only one side of the connections.

Alert tcp $EXTERNAL_NET any -> any 23 (msg:"Solaris TTYPROMPT exploit"; content:"TTYPROMPT"; depth:17; content:"|20|63|"; flow:to_server, established; sid:105556; reference:url, packetstormsecurity.org/0210-exploits/telnet.c; rev:1; tag:host:50, packets,dst;logto:telnet_exploit.log;)

This modification of the same rule logs only the next 50 seconds to our victim machine, using some more options to the tag keyword. The following example uses the opposite sub keywords to the previous example to capture only the next 50 packets heading back to the attacker.

As you can see, this keyword provides a much easier method for event logging. It also provides a level of granularity and flexibility not found with the activate and dynamic keywords. When combined with the logto keyword, this can help when working with law enforcement and outside agencies/teams. The logto keyword specifies the name of the file to which to write the results of the alert. For this example, we want the traffic related to this specific event to be placed into a file called telnet_exploit.log. This will create and fill a file in the Snort logging directory when this event is seen, while also creating a session log for the tag keyword. These files can then be turned over to law enforcement as both the cause and effect of an attack, where the cause is seen in a full packet dump by the logto keyword file as well as the effect from the tag keywords' file.

Dynamic Rules

Detecting Binary Content

Категории