Slashdot Mirror
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?
Check this out for full info on a whole range of IDS systems ... hardware & software.
Network Intrusion ran by some guy who is extremely helpfull on the Security Focus IDS mailing list.
That was one of the most content-free articles I've ever seen this side of USA Today. Any chance of tracking down a detailed side by side analysis of the products tested with pros and cons and maybe WHY they thought snort was so much better (not that I disagree, but vagaries don't tend to be terribly convincing when presenting to management).
this is getting old and so are you
blog
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.
Check out http://www.sourcefire.com if you are in that kind of situation
See my earlier comment about ACID. Multisensor correlation and alert grouping, emailing of packet traces to offenders or CIO's, pretty much all you could ask for.
Try it. ACID homepage You may be pleasantly surprised at how easy Snort is to scale up. I have numerous sensors, all in production, all logging on all interfaces, all the time, and haven't had any major incidents on my subnet. I credit this partly to having early warning of when some idiot tries to attack my boxen, as well as to using Thoth for host monitoring, which makes it trivial to check that all my daemons are up-to-date, and all kernel patches are installed.
Someone pisses me off consistently, they get blackholed. This is something I'd recommend doing by hand, of course, but for people whose business I don't need or want, it's a great way to end the problem right then and there. :-)
Remember that what's inside of you doesn't matter because nobody can see it.
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
ACID looks great...but it requires PHP. :^/
Does anyone have good information on how to compile Apache with mod_perl and PHP and SSL?
Wooden armaments to battle your imaginary foes!
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.
Don't know about the SSL side (haven't done it yet), but grab the sources for:
.php
Apache, Mod-Perl, PHP, (for PHP, make sure you have the proper graphics librarys installed also so that Acid can display graphs. What you need is in the Install file in the Acid Source.
Here's what I used.. (Subsitute what ever version is current below)
#Mod-Perl Install
perl Makefile.PL \
APACHE_SRC=../apache_1.3.20/src \
DO_HTTPD=1 \
USE_APACI=1 \
PREP_HTTPD=1 \
EVERYTHING=1 \
[...]
make
make test
make install
#PHP 4 Install
./configure \
--with-mysql \
--with-apache=../apache_1.3.20 \
--enable-track-vars \
--enable-inline-optimization \
--enable-ftp \
--enable-sockets \
--with-gd \
--with-jpeg-dir=/usr/lib \
--with-zlib-dir=/usr/include \
--with-png-dir=/usr/lib \
--with-freetype-dir=/usr/lib
make
make install
#Apache Install
./configure \
--enable-module=most \
--enable-shared=max \
--activate-module=src/modules/php4/libphp4.a \
--activate-module=src/modules/perl/libperl.a
make
make install
#add to Httpd.conf
#AddType application/x-httpd-php
Note, please decend into the top level of each source tree before executing command to configure, make and install.
I know this is off-Topic, but there are several folks out there that can't figure out how to compile these together to get Acid to work correctly.
From a brief initial read, it seems to be a fair review. It requires more work than the commercial offerings but is more flexible. And for their tests, they got comparable performance to the commercial products. To give a brief quote:
You are right however, the current links are mostly fluff.
I don't want knowledge. I want certainty. - Law, David Bowie
Snort combined with the equally free BigBrother gives every admin exactly what he wants. Secure net with an easy to monitor interface. If I'm not mistaken there was an article in SysAdmin not long ago about hooking Tripwire into BigBrother. The same should be able to do with Snort, shouldn't it?
/Haeger
You are not entitled to your opinion. You are entitled to your informed opinion. -- Harlan Ellison
First, most IDS users focus on eliminating "false positives." This mindset, and especially ISS' goal of "zero false positives," is misguided.
I treat every IDS event as an "indicator," in the military intel idea of "indications and warnings." If I tell my IDS to find "X", and it reports "X", is that a false positive if "X" doesn't mean compromise? No, it's my responsibility to evaluate that indication by performing correlation and looking at the bigger picture.
Second, most IDS developers seem to focus on the detection aspect, i.e., can we detect at gigabit speeds? Can we detect Unicode-encoded attacks? This is necessary but not sufficient to perform network security monitoring.
IDS vendors need to understand that ESCALATION is the goal, not just detection. If the IDS doesn't provide enough supporting data to help me make a judgement without physically inspecting the target, why bother alerting at all? Why flash the red alert light if I must call the customer or do computer forensics to find out if the box is hacked?
Expect more rants in the form of a book (hopefully) late next year or sometime in '03.
Helevius
You can get the real IDS report from the NSS group at http://www.nss.co.uk. at no charge.
- David A. Wheeler (see my Secure Programming HOWTO)
I can't speak to higher-end solutions, because as I mentioned in my response, I suspect they'll already have an architecture in place (eg. when I was at IBM Burlington, before Snort was even born, the setup they had created for monitoring ingress and egress traffic was far beyond what I've seen before or since).
But for my live production hosts, dual-homed on UUNet and Qwest, and all monitored, Snort + Barnyard + ACID have kept up without clipping traffic or interfering with operations. And yes, we DO saturate both of those links on occasion (though not always).
That's all I can speak to. When I worked at XOOM we saw traffic up to about 0.75Gbps steady and never bothered running an IDS, just were real fucking careful about what went live and keeping everything audited. An HP OpenView installation with some sort of IDS support was looking like $300K in bills. We said "fuck that" and to this day I wouldn't do any differently.
But, my situation may be very different from yours. If you need a $20K solution and its presence saves you $40K, you sure as hell don't need my blessing to buy it!
Remember that what's inside of you doesn't matter because nobody can see it.
I just got in from a busy day and what do I find but a little Snort action on ole Slashdot...
So, I've got a few comments about the comments:
Snort signatures and the quality thereof. Anyone who complains about the quality of Snort signatures is a lazy bastard, they're open source and easy to modify, if you find that much wrong with them make the appropriate changes and mail them back to me or Brian Caswell, our own official Snort Rules Nazi. Just because we write Snort sigs doesn't mean you have to use them, the original concept behind Snort and the rules files that came with the distro was that the users could look at examples of how to write them and develop their own set for the site they were protecting. This has gotten way out of hand over the past three years and has blossomed into the approximately 1300 rules we have now. The quality isn't always the best, but we're working on it (and if you've been tracking them over the past 6 months they've gotten much better.
Performance. People from ISS talking about the superior performance of their solution is laughable, it's been shown repeatedly in third party IDS roundups that Snort performs on par with or better than almost all of the other commercially available NIDS solutions out there. In fact, I know of one large entertainment company that sank a decent chunk of money into hardware that's running Snort at OC-12 speeds on their network successfully with no packet loss at all. Moral of the story? IDS performance is tied directly to the configuration and horsepower of the sensor hardware. No big revelations there. The fact of the matter is that's Snort's capabilities and performance keep increasing as we continue to develop it. We're also about to revisit some major architectural components of the system as we begin development on Snort 2.0 this month, but that's a different topic...
Love Snort but need a commercial company to back it? Check out Sourcefire, a company that I founded this year precisely to do that. We are selling network IDS appliances complete with a web-based GUI, data analysis console, and full blown configuration management system built in. We're also working on a Management Console appliance that will allow you to deploy and manage a distributed Snort NIDS infrastructure and manage all the data that comes out of the system and perform multi-sensor correlation.
Rapid response. When the shit hits the fan on the Internet, Snort is usually the leader in getting out new sigs to the user community. Case in point, the W32/Voyager MS SQL worm that recently came out, we were the first with sigs to pick it up.
So in the end, Snort gives you speed and accuracy (in that I mean you can identify specific exploits very precisely), has an active development and user community and is flexible to meet users needs. I think that this is a really good combo for most people's needs. Now that Sourcefire is out there, I think that the needs of "pro" users can be satisfied as well as those of the open source world.
On the other hand I might be biased, as I did write the thing... ;)
-Marty