Future Of IDS
A reader wrote to us about a summary article regarding IDS ? . This is an interesting article in so far as it attempts to prognosticate what the future will be for detection, and that draws in some interesting work on security modelling. T: Readers may also want to see this vnunet article on IDS products -- guess what comes out on top?
Anyways, I want to throw in a shill for ACID for anyone who runs Snort. It makes my job SO INCREDIBLY MUCH EASIER that, well, I bother to do it every day, maybe two or three times a day, and haven't had any major incidents to speak of. If you run Snort, you ought to log to a centralized database that can handle the traffic from all your sensors, and then grind through it with ACID for starters. Yes, you should keep a packet vault; yes, you should run Nessus; yes, you still need to use TripWire or Integrit for filesystems. But having a friendly, capable frontend to Snort sensors is a HUGE help.
If you're running a lot of sensors and they get a ton of attacks in production, you should also look into the Barnyard plugin for Snort. It's nice for keeping things from slowing down.
If I were to take a stab at what would MOST help IDS and ISS research in the near future, I'd guess at the integration of tools like Nessus and Snort with a predictive intelligent agent like Intravenous or similar. I wish I could comment intelligently on the article, but mostly I wanted people using Snort to be aware of HOW helpful the ACID frontend is, so that more people use it, and I have less subnets to blackhole ;-).
Remember that what's inside of you doesn't matter because nobody can see it.
Phase 1: apt-get install snort
Phase 2:
Phase 3: Security!
The point is to be aware, not to come down on them. If they knocked on the door, trying some exploit.. it's not worth your time to chase them down if it has no effect. On the other hand.. what if it turns out to be a rival company?
The point is _detection_ as in the three prongs of security, Protection, Detection, and Response.
Having a firewall (protection) without IDS (detection) is betting that your firewall is blocking everything bad, and not wanting to know if it isn't. Putting sensors inside and outside of your firewall allows you to see what is being attempted and what is being blocked. The IDS will flag things as possible attacks that will pass through the firewall, what you do when you IDS alarms is as important as having it in the first place.
The Firewall is the lock on your front door, the NIDS is your motion detector, and response is the alarm company sending the police.
Si vis pacem, para bellum
The only thing more annoying than a Libertarian is an (un|mis)informed Libertarian
I am afraid if you do you are in for a RUDE awakening. The fact of the matter is that these $20,000 solutions cost that much for a reason, and the reason is they've spent years optimizing them for high speed links. This is something the hobbiest programmers who work on Snort cannot compete with. For instance, what open source coder has a SMARTBITS on their desk? Something like that is essential to test these things, but they cost upwards of $10,000.
So I would say yes, if all you want to do is monitor a T1 or two, and you're willing to tinker alot, something like Snort would work. But if you have a SERIOUS network with lots of bandwidth, you're gonna have to pony up the dough.
Disclosure: I helped build one of the systems that Snort supposedly beat, and I analyzed the source code for another one that was bought by that company. Snort CANNOT beat either one in a high bandwidth situation. I've seen the code, I've run the tests, trust me.
I no longer work for that company so have little to gain by saying this.
I'm sure i'm going to get mod'd down or marked flamebait for this, but here it goes...
Has anyone ever bothered to actually READ the Snort signatures? I actually spent quite a few hours going over them and found a number of things:
1) Massive false postives. Almost all of the HTTP signatures only look for a request to a vulnerable CGI/ASP/etc, not for the actual exploit. This means perfectly normal/valid requests generate alerts.
2) Many sigs are easy to avoid. For HTTP sigs that actually try to look for the exploit it's generally a matter of putting a fake &var=value between the ? and the exploited param since Snort can only do simple string matching.
3) Many sigs are just plain stupid. I love the one that looks for the string "I love you" everywhere in all SMTP traffic. Heaven forbid someone at your company email their wife/husband/etc.
4) There's a number of sigs that have hard-coded strings for specific BROKEN exploits. Basically, they'll detect the broken exploit, which will catch the scriptkiddies, but anyone with half a brain who fixed the exploit won't be detected.
Unforunately, tuning the IDS (turning off signatures) isn't a valid means of reducing false positives since it makes you completely blind to the attack. Which means you either get deluged with alerts or miss legitimate threats to your network.
Honestly, I got so fed up with Snort and wasting my time with it, that I finally decided to get rid of it and spend the saved time being more proactive in securing my systems.