Skip to main content

Random IDS musings

I've seen alot of traffic lately on the snort-users list about how to clean out a database periodically and it got me thinking..

Basically the basis of the story is that people want to clean out the events from their DB on a periodic basis, 1 month, 2 months, whatever. Basically I look at it like this then, why are there events in your database that are that old?

If you have events in your IDS DB, you should look at them. That's the reason you have an IDS/IPS. To review the events (and in the case of IPS, prevent the attacks) and make sure the evil hax0rs are not getting you. If you have events in your current DB that are a month old, that tells me either one of two things:
A) You don't care about your alerts
B) You have too many alerts, and you don't have a system.

So let me help you get a system.

Make an archive DB (for the people using BASE, then this is pretty simple), now, you have two db's. One current, and one archive.

1) Events come in from Snort via barnyard into your current DB.
2) You review these events. Any events that you skip over, take note of them. Do you need this alert? Is applicable to your network? Do you KNOW if it's applicable to your network?
3) Any events that you take a look at, did it actually affect your network or was it someone banging on the door (script kiddie)? If it was a skript kiddie, what are you going to do about it? Block them at your firewall? Send their ISP a cease and desist letter? If you are going to do nothing then DELETE THE ALERT. Why keep it? You aren't going to do anything about it, so who cares?
4) Now, say when you are reviewing alerts, you come across something you need to investigate. Good. Take note of it and come back later. Leave it in your current db, get through the rest of your alerts.
5) Through your alerts? Good. Come back to the ones you still have in your current db. Do you need to take further action on these guys? Yes? Investigation time? Okay, well then you need to save the alert, so move it to your archive db. When you are done with your investigation in your archive db, then delete the alert.

Basically my point here is, don't keep alerts for no reason. Now, let's go back to #2.
For instance, if you are running web-php rules, but aren't running any webservers that run PHP on them, do you need the rules? Don't subscribe to the philosophy of "if the IDS isn't alerting, then how do I know it's working?". If you want to make sure your IDS is working, then write some kind of script to email you the statistics or something from the Snort process to make sure it's analyzing traffic. If you ALWAYS skip over a particular event, then WHY are you making your IDS run the rule? Shut it off!

Let's take a look at a network. Small one. One bsd box, 2 osx boxes, 2 windows boxes, and 1 linux box. Now, in your network these may be thousands of machines on tons of subnets. The network size doesn't matter, you can take the same philosophy.

Your frag3 and your stream5 preprocessors need to be tuned to the OSes. Done? k.

Now, take your network and look at it. What services are you running, what versions of those services? What OSes? What vulnerabilities are present on your network? Now, figure those things out and turn off the rules in Snort you don't need.

Now, this is where you say to me that this is a pain in the butt, and Snort has tens of thousands of rules, with more coming out each month, blah blah, etc. etc.

Well, that's where Sourcefire comes in. We have things like RNA, we have things like Adaptive IPS/IDS that will do all that FOR YOU, leaving you with the relevant alerts, things you HAVE to look at! But rather than this turning into a sales pitch, I am simply trying to get you to think about how to work with your data. Do you need to keep all that data? or can you fine tune it?

Comments

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