(I'm doing this now mainly to bump the bosses post down a slot... :))
Hey folks, we have some updated Snort information for you. Here is some information ofon the latest production build of Snort, and our first beta build of Snort 2.8.6.
Snort 126.96.36.199 Update:
A quick note about the latest Snort release, Snort 188.8.131.52 (find it here: http://dl.snort.org/snort-current/snort-184.108.40.206.tar.gz). This release resolves an issue discovered during the NSS testing that allowed for an evasion method in RPC rules. Note these RPC rules are not Windows RPC/SMB/NETBIOS etc..., but the Sun RPC flavor. This is the only evasion case that occured during NSS testing, so we're excited to have it out. Make sure you keep your Snort up to date!
Snort 2.8.6 BETA!
OK, so the Snort 2.8.6 beta is up on snort.org. (Don't tell marketing, but you can just wget http://dl.snort.org/snort-beta/snort-2.8.6-beta.tar.gz) While there is still some features that the dev team is planning on adding, this beta build already serves up some features that folks have been clammoring for. Steve Sturges, supreme high commander of the Snort development team, has put together some information for me to pass on.
First up, is the ability to handle gzip compressed server response data over http connections. To activate this feature, make sure you add the --enable-zlib argument to your configure script, and modify your http_inspect_server configuration field. There are two new depth fields associated with this feature. The first is the compress_depth field, which specifies the maximum amount of packet payload to decompress. If you don't modify the configuration at all, Snort will use the default value of 1460 bytes. Also, there is a decompress_depth configuration that specifies the maximum amount of decompressed data to unpack. The range is quite large, from 0 to 20480 bytes, with the default setting being 2920. As part of your testing for your environment, play with different values in these depth fields, so you get an understanding of any performance impact this feature will have.
Another frequently requested features is the ability to detect the transfer of Personally Identifiable Information (PII) passing across the wire. Snort 2.8.6 will have a sensitive_data preprocessor that will sort of combine pattern recognition and thresholding. There are some preset patterns that you can call: credit_card, us_social, us_social_nodashes and email. But you can also perform a limited regex-style match to define your own critical patterns. The rule format then allows you to specify how many times you need to see the patterns before you alert. So, for example:
alert tcp $HOME_NET any -> $EXTERNAL_NET $SMTP_PORTS (msg:"Credit Card numbers sent over email"; gid:138; sid:1000; rev:1; sd_pattern:4,credit_card; metadata:service smtp;)
This would alert if four or more credit card numbers were seen going over the defeined SMTP_PORTS. As an aside, the nice thing about the credit card pattern match keyword is that it matches 15 or 16 digit numbers, seperated by spaces, dashes or nothing and covers valid numbers for Visa, Mastercard, Discover and American Express. Note that the GID for this must be 138, and you may not combine the sd_pattern keyword with any other rule options.
We'll put together some more sample rules and get them out to you here. We might also throw together some PCAPs and toss them up on labs so you can test off the wire to make sure your configuration is good. The VRT and the Snort dev team are also very interested in what sort of patterns you decide to use on your end, so if you come up with something you're willing to share, let us know.
Now, deep in the recesses of Snort, and after a number of those engineering meetings that leave ancient mythical symbols on the white boards, a new pattern matcher has been born (hatched?). The new ac-split pattern matcher is much more efficient than the current default matcher (ac-bnfa) but is closer to ac-full in its memory consumption.
To give it a shot, modify your snort config to include:
config detection: search-method ac-split
Now, I'm going to be honest, I don't completely understand what this means (yet...its been a busy December...) but the High Commander tells me that this is an alias for search method ac, split-any-any. The High Commander also says that, in order to keep memory usage in check, try the following modifications to the config detection line:
max-pattern-len 20, search-optimize.
Which would result in the following full config line:
config detection: search-method ac-split, max-pattern-len 20, search-optimize
For my money, I'd try the ac-split method with and without the memory optimizations and see how your throughput is. Make sure you are looking at a typical amount of traffic and keep some stats on memory usage, cpu usage and throughput.
More info on 2.8.6 as things develop, get to testing and remember that you can provide feedback to email@example.com. We'll also get you some more in-depth technical information on the various features as the final build firms up.
Happy New Years, folks. Be safe and give your loved ones a hug.