Sourcefire VRT Certified Snort Rules Update for 01/22/2013

Just released: Sourcefire VRT Certified Snort Rules Update for 01/22/2013

We welcome the introduction of the newest rule release for today from the VRT. In this release we introduced 7 new rules and made modifications to 8 additional rules.

There were no changes made to the snort.conf in this release.

The VRT would like to thank Avery Tarasov for his work on sid:
25511

In VRT's rule release:

The Sourcefire VRT has added and modified multiple rules in the exploit-kit and netbios rule sets to provide coverage for emerging threats from these technologies.

The Sourcefire VRT has also fixed an integer overflow vulnerability in GID 3, SID 20275. This was reported by Fermin J. Serna and Tavis Ormandy.

In order to subscribe now to the VRT's newest rule detection functionality, you can subscribe for as low as $29 US dollars a year for personal users, be sure and see our business pricing as well at http://www.snort.org/store. Make sure and stay up to date to catch the most emerging threats!

Sourcefire VRT Certified Snort Rules Update for 01/17/2013

Just released: Sourcefire VRT Certified Snort Rules Update for 01/17/2013

We welcome the introduction of the newest rule release for today from the VRT. In this release we introduced 91 new rules and made modifications to 38 additional rules.

There were no changes made to the snort.conf in this release.

The VRT would like to thank Avery Tarasov for his work on the following SIDS:
25503
25504
25471

The VRT would also like to thank Tavis Ormandy for his work in finding a potential security issue with rule 3:20275.

From our assessment this looks like the potential impact is a DoS, however, we've been unable to cause this in our testing. We've rolled the subscriber sets to registered so everyone can download the updates. Additionally, the rule is not enabled in default policies so the exposure is limited.

In VRT's rule release:

The Sourcefire VRT has added and modified multiple rules in the app-detect, blacklist, browser-ie, dns, dos, exploit-kit, file-flash, file-identify, file-multimedia, file-office, file-other, file-pdf, indicator-obfuscation, malware-cnc, misc, netbios, os-windows, policy-social and web-client rule sets to provide coverage for emerging threats from these technologies. 

In order to subscribe now to the VRT's newest rule detection functionality, you can subscribe for as low as $29 US dollars a year for personal users, be sure and see our business pricing as well at http://www.snort.org/store. Make sure and stay up to date to catch the most emerging threats!

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.