Skip to main content

Immaculate Collection

(Preface: I wrote this around January of 2007 and simply forgot about it. I wrote it around the time that Marty was writing these posts: here. Also when Richard was writing these posts here.)

I started playing with Sguil again recently, and for the benefit of those that don’t know, Sguil is a Snort based “NSM” system. It uses Snort and some other tools brought together in one interface to provide better analysis and results. The main factor of Sguil is that it runs something like Tcpdump, Snort, or Daemonlogger in order to dump ALL traffic to disk.

I bought my good friend Richard Bejtlich’s “The Tao of Network Security Monitoring” book earlier this year.

Richard has the theory of: “collect all packets, because without all packets the total picture isn’t seen”. In principle, I agree. I used to use this methodology heavily in my last job, and it worked quite well at the time.

While he also goes on to say that IDS “alerting” has its place, without “context” (the surrounding traffic on the network) the alert will make no sense. I don’t know if I rightly agree with that statement as a whole. Let me explain my difference in “context”.

At my company, Sourcefire, we make a product called “RNA” which stands for “Real-Time Network Awareness”. This product coupled with our IPS’s and Defense Center make an extremely powerful tool for analyzing “alert traffic”. Let me give you an example.

Simple Example:

Hacker attacks your network with an exploit against IIS servers. If any of you have ever seen something like this before in your analyst lives, you probably know that they will either 1) Prescan your network for open http ports, or 2) just automate the attack so no prescan takes place, just the attack, very quickly.

If you have plain vanilla Snort, you will get an alert for every one of these attempts. Using the “Collection” theory, we would also collect all traffic for these connections and we are able to see which attacks got through the firewall, not which ones didn’t. You can even take it this a step further and rebuild the session to see what took place (if anything). This is a lot of data. We’re talking a pcap file that is containing not only all these hundreds of potential connections, but every other connection that is taking place on the network at the same time.

Now, there is nothing wrong with that if:

A) You have the hard drive space.

B) You have the time.

  1. Your machines doing the sniffing can keep up.
  2. You have the personnel to manage all the time, data, and storage.

The problem with it is, at modern network speeds, and the speed at which a program would have to write this stuff to disk, something would give. Now I am not talking at your 500 Mbit/s speeds. I’m talking about the majority of the networks that I deal with that are >1 Gig/s. Whether it be the hard drive, memory, or whatever, but something would buffer somewhere, and more than likely you are going to drop packets. Again, I’m not saying that this is totally a bad idea, I’m just bringing up cons to the pros.

But lets look at it a different way. RNA profiles the hosts on your network, both pre-attack and during, in real-time. RNA knows which machines are running IIS (if any) and which ones aren’t. So it already knows if you will be affected by the IIS exploit attempt.

When these alerts come back to the DC (Defense Center), the DC correlates the RNA event with the Intrusion Sensor alert and the “fat rises to the top” as it were. The DC knows to say “Hey, this attack affects IIS version 5, and only version 5, on Windows...etc..” This is technology that Sourcefire has invented and patented.

So instead of you now having to analyze 100’s of alerts and 1000’s of packets, hey, I only have “these two machines” over here running IIS, and the DC told me that I need to look at these alerts first. Are the other alerts still recorded? Yes, but now I know through the correlation which machines will receive a greater IMPACT from the attack. The two IIS machines. My other Apache boxes aren’t affected at all, so who really cares.

Lets take it a step further. Say the exploit was against IIS 5.0. Well, our two machines are running IIS 6.0. (I’m inferring patch level with this example)

So do we really care? Well, we might like to know, hey, there was an attempt, that’s great, but it doesn’t affect us, we’re not vulnerable to it, lower the IMPACT, and lets move on to the next alert.

If you were collecting packets using the “Immaculate Collection” theory, you’d have to analyze all these streams to make sure that each IIS/Apache/etc.. box returned 404 and whatever else error codes.

Could we do that with Snort? Yes, of course we could. But if RNA knows our network already, then is it important to us? Or is it just informational at this point?

Take it a step further. Think about the exploits that affect browsers, Mail Clients, versions of SSH, telnet, snmp, etc.. RNA already knows these services and applications on your network. Before the attack even takes place.

Single glances allow us to look at these 1000’s of alerts, and say hey, these 2 machines are running IIS, but we’re not vulnerable to the attack. In a matter of seconds.

If you’ve ever heard Marty Roesch speak, you’ll know that it is his belief that “Humans” basically can’t make the decisions for the IDS. Why don’t we let RNA tune it directly? But that’s for a totally different post, one that Marty has covered on his blog as well.

Of course there are strong points to both sides of the discussion. Share your thoughts in the comments.

® Snort, Daemonlogger, RNA, Defense Center, and Sourcefire are all registered trademarks of Sourcefire, Inc.


Popular posts from this blog

Offset, Depth, Distance, and Within

Without going off the deep-end here and discussing every single Snort rule keyword, I just wanted to touch on a few modifiers that people sometimes misunderstand.  They aren't difficult, and hopefully after this explanation and a few examples, I can clear some of the air around these five modifiers.

The five modifiers that I am talking about are
OffsetDepthDistanceWithinnocaseThese five modifiers are not keywords of themselves, but rather they apply as modifiers to another keyword.  That keyword is "content". The content keyword is one of the easiest pieces of the Snort rules language as all it does is look for a particular string.  So for instance if I wanted to look for the word "joel" within a packet.  A simple:
content:"joel";Would allow me to do that.  The interesting part comes into play when you want to specify where inside of a particular packet you want the string "joel" to be looked for.  If you are running just a plain content ma…

Writing Snort Rules Correctly

Let me start off by saying I'm not bashing the writer of this article, and I'm trying not to be super critical.  I don't want to discourage this person from writing articles about Snort rules.  It's great when people in the Snort community step up and explain some simple things out there.  There are mistakes, it comes with the territory.  If you choose to be one of the people that tries to write Snort rules, you also choose to be someone who wants to learn how to do it better.  That's why I write this blog post, not to bash the writer, but to teach.

I noticed this post today over at the "Tao of Signature Writing" blog, and to be honest I glanced over most of it figuring it was a rehash of things I've already read or things that have already been written from countless people about "Here's how you write Snort rules!".  I scrolled down quickly skimming, not reading at all really, and noticed this part:
Now, let us look at the second questio…

Safari 5.1.4 now available

Safari 5.1.4 now available, fixes issues and improves performance | TUAW - The Unofficial Apple Weblog:

Improve JavaScript performanceImprove responsiveness when typing into the search field after changing network configurations or with an intermittent network connectionAddress an issue that could cause webpages to flash white when switching between Safari windowsAddress issues that prevented printing U.S. Postal Service shipping labels and embedded PDFsPreserve links in PDFs saved from webpagesFix an issue that could make Flash content appear incomplete after using gesture zoomingFix an issue that could cause the screen to dim while watching HTML5 videoImprove stability, compatibility and startup time when using extensionsAllow cookies set during regular browsing to be available after using Private BrowsingFix an issue that could cause some data to be left behind after pressing the "Remove All Website Data" button