Active Response with Snort 2.9.0

Snort 2.9.0 can take a more active role in securing your network by sending TCP resets and ICMP unreachables to shutdown offending sessions to minimize the chance that Snort is bypassed due to traffic volume, restarts, etc. Changes include:

• block (drop) rules can be configured to send rejects
• responses are encoded based on the headers in the triggering packets
• flexresp3 was added which replaces flexresp and flexresp2 and supports all those keywords
• react rules have a configurable response page

The block rule action was added in 2.9.0 as a synonym to drop to avoid confusion with packets that are not inspected.

To enable these features, use the following when configuring Snort:

./configure --enable-active-response --enable-react --enable-flexresp3

Demo Setup

To run these tests you will need the this tarball: http://labs.snort.org/files/active_blog.tgz.

Follow the setup outlined in the prior post for inline normalization.

You can run these tests in readback mode using the dump DAQ or in playback mode using tcpreplay and an inline sensor. Using a sensor is the ultimate but you may find the dump DAQ to be indispensable for pcap testing.

Configuration

This test demonstrates how Snort can take an active role in shutting down offending sessions. The easiest way to do this is to configure the stream5 preprocessor to take action when when a block (drop) rule fires.

preprocessor stream5_global: max_active_responses 1, min_response_seconds 1

block tcp any any -> 10.9.8.7 80 ( sid:2; msg:"Cheeze Prohibited"; content:"Cheeze"; )

Here we have a simple block rule that will cause TCP resets because max_active_responses has been set. When this rule fires in inline mode, the packet will be blocked and a reset will be sent.

Execution

We will run the test twice, once in inline mode and again in passive mode.

For readback testing:

• From Sensor run: ./readback.sh act_i?s.conf ../Source/act.pcap

For playback testing:

1. On the sensor, run ./inline.sh act_i?s.conf
2. On the sink, run ../recv.sh
3. On the source, run ./send.sh act.pcap
4. Type Ctrl-C on the sensor and sink to terminate.

Passive Mode Results

The results for act_ids.conf are (just showing the reset packet and the ones before and after):

17:14:37.760753 10.1.2.3.48620 -> 10.9.8.7.80: . [tcp sum ok] ack 1 win 256 (ttl 64, id 3, len 40)0x0000   

4500 0028 0003 0000 4006 5cba 0a01 0203        E..(....@.\.....0x0010

0a09 0807 bdec 0050 0000 0002 0000 0002        .......P........0x0020   

5010 0100 d280 0000 0000 0000 0000             P.............

17:14:37.760876 10.1.2.3.48620 -> 10.9.8.7.80: R [tcp sum ok] 2:2(0) win 0 (ttl 5, id 25097, len 40)0x0000   

4500 0028 6209 0000 0506 35b4 0a01 0203        E..(b.....5.....0x0010   

0a09 0807 bdec 0050 0000 0002 0000 0002        .......P........0x0020   

5004 0000 d38c 0000 0000 0000 0000             P.............

17:14:37.760878 10.1.2.3.48620 -> 10.9.8.7.80: . [tcp sum ok] 1:41(40) ack 1 win 256 (ttl 64, id 4, len 80)0x0000   

4500 0050 0004 0000 4006 5c91 0a01 0203        E..P....@.\.....0x0010   

0a09 0807 bdec 0050 0000 0002 0000 0002        .......P........0x0020   

5010 0100 1c7f 0000 4745 5420 2f63 7261        P.......GET./cra0x0030   

7a79 2e63 6769 3f77 6974 6854 6865 4368        zy.cgi?withTheCh0x0040   

6565 7a65 5769 7a20 4854 5450 2f31 2e31        eezeWiz.HTTP/1.1

Inline Mode Results

The results for act_ips.conf are:

17:18:15.377938 10.1.2.3.48620 -> 10.9.8.7.80: . [tcp sum ok] ack 1 win 256 (ttl 64, id 3, len 40)0x0000   

4500 0028 0003 0000 4006 5cba 0a01 0203        E..(....@.\.....0x0010   

0a09 0807 bdec 0050 0000 0002 0000 0002        .......P........0x0020   

5010 0100 d280 0000 0000 0000 0000             P.............

17:18:15.378186 10.1.2.3.48620 -> 10.9.8.7.80: R [tcp sum ok] 2:2(0) win 0 (ttl 5, id 48182, len 40)0x0000   

4500 0028 bc36 0000 0506 db86 0a01 0203        E..(.6..........0x0010   

0a09 0807 bdec 0050 0000 0002 0000 0002        .......P........0x0020   

5004 0000 d38c 0000 0000 0000 0000             P.............

(The above results were captured from a playback test and show only one direction. For a readback test, you would see the reset packet in each direction.)

Packet Counts

For the ids run, we see the whole session plus a TCP reset, but the inline run shows the threeway handshake and a TCP reset. In the latter case, not only was the “Cheeze” attack blocked, but the offending session was shutdown as well. Snort's shutdown counts reflect this. Of the 8 packets analyzed in the ips case, there are 3 allowed, 1 blacklisted, 4 blocked. The 2 injections are 1 TCP reset in each direction.

Packet I/O Totals:

Received:            8

Analyzed:            8 ( 53.333%)

Injected:            2

Here are the ids counts:

Verdicts:

Allow:            8 ( 53.333%)

And here are the ips counts:

Verdicts:

Allow:            3 ( 14.286%)

Block:            4 ( 19.048%)

Blacklist:            1 (  4.762%)

Closing

Note that the passive mode reset may or may not be effective at shutting down the session depending on timing. For a more determined effort at passive IDS sniping, you can set config response: attempts A to specify that multiple resets be sent with varying sequence numbers ("sequence strafing"). But inline IPS will ensure the best results.

For both passive and inline scenarios, you can adjust max_active_responses N and min_response_seconds T to make up to N responses if traffic is still present after T seconds. Beware: when strafing, you will get A packets in each direction configured for each response.

If you only want some block rules to generate active responses, you can change those to reject, react, or resp rules instead of setting max_active_responses.

Please read Russ's other blog post about Inline Normalization with Snort 2.9 here, on the VRT blog.