Archive for April 2009
Update: – You can download tweetyard here.
There has been some of discussion of late on the snort-* lists of late regarding Unified alerting vs direct DB access.
I stopped storing events in a DB years back when I stopped using ACID (and yes that was back-in-the-day before BASE came into being). My personal Snort requirements are pretty simple and fast output has always worked well for me linked with a load of swatch-foo and custom perl scripts. After hanging my head in shame for not converting to unified yet (cobblers children clearly have no shoes over here) I thought it would be wise to put some effort in.
I used to receive all of my Snort IDS events via email, but email is *so* web 1.0. So I thought I would hook into Twitter for real-time alerting 🙂
So far, so good, and it only took about an hour to build. Kudos to Jason Brvenik for his snort-unified.pm and sample barnyard replacement, it was a good base for what I wanted to hack together. Because I put this together more than fun more than anything else, feel free to follow a censored Twitter feed of my IPS events (If you didn’t have enough to deal with already). I have blanked the IPs of my protected systems in an attempt to raise the smarts-to-abuse bar up 0.2 inches above short skiddie tall.
I will upload the code when I get a spare couple of minutes, but as I will be attached to the Sourcefire booth @ Infosecurity London for the next three days it may take a while. Hooking it into Sourcefire’s Estreamer is also on the cards the next time I get some down-time.
If anyone is at the show, feel free to drop by the Sourcefire booth and say hi (and to bring me a Coffee at the same time).
I am in the process of uploading a load of pcap files to openpacket.org from my “example.com” collection. Because openpacket doesn’t provide an interface to include supporting data, below is network map that should help anyone who needs to use these pcaps. They were sniffed from a test network I built and should contain a good mix of systems and protocols.
Expect to see:
While I fight with Openpcap’s upload limits, a complete archive of example.com can be found here.
I’m writing this post on the 14:00 BST 7/April, this timestamp is important because snort 2.8.4 has not yet been released to the public and when it is I get the feeling that there could be a lot of traffic on the Snort forums and mailing lists.
The morning after the 2.8.4 release I imagine a lot of people will have woken up to a Snort sensor that is no longer functioning, now let me take guess at what has most likely has happened.
- You are running Snort version 2.3.x or earlier
- You are using oinkmaster, or similar to provide an automated tool to download new snort rules and restart the detection engine
- You have set oinkmaster to download the “CURRENT” release
- Snort now fails to start because of these new rules
So what’s happened in plain English?
A new preprocessor has been released called DCERPC2. If stuff has just broken for you, the version of rules that your automated update process has downloaded requires this new preprocessor to provide detection for a load of new “stuff” in the NetBIOS category.
You now have two choices:
- Update Snort to 2.8.4 to stay current with the detection that Sourcefire’s VRT provide (Good)
- Don’t update Snort. Run with an older rule set that doesn’t provide detection for current threats (bad)
Unfortunately it doesn’t look like there is much choice in it, go get the latest tarball and install. While you have wget running in the background, lets examine whet DCERPC2 does, and why this change has been made.
Snort is a real-time protocol modeller, it inspects network traffic at the application layer (and below) and builds a state-machine. This isn’t just simple TCP state data like a firewall would track, it follows application protocol state. The Snort language allows a rule-writer to build his/her own application state tables as needed to support pretty much any protocol, so if a vulnerability is found in the brand new “foo” protocol, a state-machine to track “foo” connections can be built by the rule writer as needed.
Here is an example of how application protocol state is tracked. The magic word here is “flowbits”. I have copied a rule out of the smtp.rules as an example. Note that I have also simplified it for display here so don’t expect it to work in the real-world any more.
alert tcp $EXTERNAL_NET any -> $SMTP_SERVERS 465 (msg:"SMTP SSLv3 Client_Hello request"; \ flow:to_server,established; \ flowbits:isnotset,sslv2.client_hello.request; \ flowbits:isnotset,tlsv1.client_hello.request; \ content:"|16 03 00|"; depth:3; \ content:"|01|" ; depth:1; offset:5; \ flowbits:set,sslv3.client_hello.request; \ flowbits:noalert; \ service smtp; classtype:protocol-command-decode;)
When traffic that matches this rule is seen, it sets a “flowbit” on the stream that can be checked in other rules. Here we can see that for this rule to “fire” and have the SSLv3 flowbit set, the stream cannot be SSLv2 or TLSv1. Also note that when this rule does “fire” it won’t create an alert, it just sets the state for further processing.
This method has been traditionally used to track application protocol state in NetBIOS/DCERPC traffic in the same was as all other protocols. The method has has worked well for years but because of all the different ways you can access potentially access some vulnerable functions in DCERPC, the netbios rule-set has grown noticeably. DCERPCv2 deprecates most of these flowbit based protocol modellers for DCERPC traffic, this allows the VRT to shrink the netbios.rules category down to make it more manageable, this is great for those who hand-hack config files. Anyone using Sourcefire 3D won’t really notice much difference when DCERPC2 gets released in a SEU, but you would have missed out on a lot of pain already because of the built in flow-bit dependency tracking.
If you are running a commercial solution that won’t work with this rule-set, I would like to hear from you, please get in touch.
The below tool and information has been superceded by Snoge. More info about Snoge is available at here.
Original text included for historical completeness.
Rather than answer to each person separately I thought I would upload some instructions here.
- A Snort fast alert file OR a Sourcefire 3D Intrusion events CSV report (just the table view, with no hidden columns)
- A working perl environment. I run this script on OSX and Debian Linux, I have no idea if works on Windows (If you have this working please let me know)
- The perl module Geo::IP::PurePerl
- A text editor
1) Install Geo::IP::PurePerl. It’s available via CPAN, so I recommend you use it.
[13:03:55]lward@drax~$ cpan cpan shell -- CPAN exploration and modules installation (v1.7602) ReadLine support available (try 'install Bundle::CPAN') cpan> install Geo::IP::PurePerl <snip>
3) Ungzip the file, and save it to /usr/local/share/GeoIP/GeoLiteCity.dat
3) Download the mksfkml.pl script from here and untar (tar -zxvf ./filename.tgz)
4) You’re good to go.
mk_sfkml.pl <options> -m or --mode <plot | attack>. Draw attack lines, or plot sources - Default=plot -i or --input Input filename. -t or --tool <3D | snort> Source tool. (Default = 3D) -h or --help This message -o or --output KML output file. Defaults to /tmp/sfire.kml -s or --snort Place a snort instance at the location of this IP address -3 or --sensor <ip.add.re.ss> Place a 3D sensor at the location of this IP address -d or --dupes Do not show multiple events from a single source location
./mk_sfkml.pl -t snort -m attack -i alert.sql -w /tmp/foo -s rm-rf.co.uk
[*] Reading from alert.sql: Creating /tmp/sfire.kml for google earth [*] Adding a Sensor in York [*] Working on a snort alert file |- Start point 18.104.22.168 in Beijing + Destination point 22.214.171.124 in York |- Start point 126.96.36.199 in Chengdu + Destination point 188.8.131.52 in York |- Start point 184.108.40.206 in Changzhou + Destination point 220.127.116.11 in York |- Start point 18.104.22.168 in Hefei <snip>
And that’s it. Simple eh?