Future Of IDS 125
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?
Hard to install and setup? (Score:1, Troll)
Re:Hard to install and setup? (Score:1)
'apt-get' is not recognized as an internal or external command,
operable program or batch file.
I think I see his problem!
Re:Hard to install and setup? (Score:1)
You need to install this [slashdot.org].
Re:Hard to install and setup? (Score:5, Funny)
Phase 1: apt-get install snort
Phase 2:
Phase 3: Security!
Re:Hard to install and setup? (Score:1)
The company [trellisinc.com] I work for is set up to do centralized monitoring of lots of different IDS's (including a spiffy one we developed in-house) for our customers who don't want to deal with/can't afford to hire their own people. There are only so many admins in the world who know how to deal with an attack, and they usually want a lot of money for that. =)
Re:Hard to install and setup? (Score:1)
And if you see a false positive caused by legitimate traffic and respond to it as though it were an attack, then you have failed.
Re:Hard to install and setup? (Score:3, Insightful)
Nothing's hard about that, but that isn't setting up snort.
Let me know when "apt-get setup snort" is working.
Re:Hard to install and setup? (Score:1)
$ apt-get setup snort
E: Invalid operation setup
It's "apt-get install snort". And if you had actually tried it before (which we all know you haven't due to your syntax slip) you would realize that it is in fact that easy. It asks you a few questions as far as when eth card/ip to listen in on and then you are up and running. The default rules are quite reasonable and of course you are free to tweak the thing till the cows come home.
Re:Hard to install and setup? (Score:2)
It wasn't a syntax slip, cretin. It was a sarcastic comment on the fact that an installation is very different from a setup, and the fact that as any security professional can tell you (and pay attention, boy, because one is) Snort requires some setup if one wants it to actually help protect one's network, not just produce a nice warm fuzzy feeling that bears little relationship to reality.
And for the record, if I actually try "apt-get" anything I'll get a "command not found" error because I don't do Debian. Not due to any deficiency in Debian, just because the Fortune 500 company for which I administrate a couple hundred UNIX servers uses RedHat.
Re:Hard to install and setup? (Score:1)
Re:A question (Score:2)
The decision came from the adminisphere. Way over my pay grade.
Re:Hard to install and setup? (Score:2)
Disclaimer: I'm the author and v1.1 needs to be released soon :)
Excellent IDS-related site (Score:4, Informative)
Network Intrusion [networkintrusion.co.uk] ran by some guy who is extremely helpfull on the Security Focus IDS mailing list.
Large scale correlation (Score:4, Interesting)
Would somebody please mod this guy up? (Score:2)
This is the flipside to things like predictive agents and automated vulnerability testers. It improves security by social mechanisms. I'm going to look into using ARIS today, and if I can figure out how myNetWatchman works, I'll consider it too.
I hope other readers are forming solid opinions about where IDSes ought to be headed by reading posts to this article. It has been informative for me, at least. (and I've been around this stuff for a while... sometimes I see packet headers in my sleep
Re:Would somebody please mod this guy up? (Score:1)
Re:Would somebody please mod this guy up? (Score:1)
I'll second that - I've been looking for the same sort of thing and had no idea really where to start. This article and this thread have really provided me with some great options to monitor and control all the knobs that keep trying to Code Red my little apache webserver :(
Um, details? (Score:4, Informative)
Re:Um, details? (Score:4, Informative)
Some methodology flaws (Score:2)
Page 165: The Tests
all available signatures enabled
This is not a level playing field. The product that I helped build (ISS RealSecure [iss.net]) contains a number of signatures that are not intended to be turned on in normal usage. For instance, RealSecure can generate an even for every single HTTP GET request on your network, no matter how inane.
This feature is intended to be used as a special purpose tool, for instance to analyze web usage over the short term. It is not intended to be turned on during normal IDS usage. If you do turn it on, it often overwhelms your console with tons of incidental data and rapidly fills your logs.
Page 166-167: Performance Under Load
Another RealSecure specific problem here is that RealSecure deliberately drops redundant reports and does not count them, so that you do not get inundated with a million messages that tell you the exact same thing. Therefore I would expect it to fare very poorly in the boping count test.
Others in this thread have pointed out [slashdot.org] the danger of using tools like SMARTBITS to generate background traffic. The problem is that unless you really know what you are doing, SMARTBITS is likely to generate traffic that is entirely unrealistic. (For instance, TCP data packets that don't correspond to an actual open session that the IDS would have been tracking). This can cause both unrealistically good and unrealistically bad performance, depending on what the background traffic actually is and how the IDS is built.
The assertion early in this section that "if a sensor detects 100 per cent of attacks at 100 per cent load in this test" (of minimum length packets) that it "can handle anything that islikely to be thrown at it" is patent BS. Yes this is the worst case scenario of "packets per second", but packets per second is not the most important metric here.
I also note on page 177 and 178 in a footnote that neither RealSecure nor BlackICE were "re-tested for Edition 2", yet they are not reluctant to conclude that SNORT is better than the commercial products. I think we've got an apples and oranges problem here.
I also question whether their assertion that all products were tested with their latest signature updates can possibly true, if they didn't retest all the products. Most of the commercial vendors release new signatures on a regular basis.
(This is also true for the Cisco, CA, Symantec, Enterasys and other products in the comparison, if you read the footnotes carefully).
Managers Like Names... (Score:4, Interesting)
In places where the budget is a bigger concern I still implement Snort. I can't possibly afford to stick a commercial product on every subnet that I'd like to.
Re:Managers Like Names... (Score:2, Informative)
Re:Managers Like Names... (Score:4, Insightful)
CEO's like $$$ (Score:4, Interesting)
Only choads that are getting kickbacks from manufacturers are going to push for overpriced commercial solutions in shops that don't have an existing IDS installation or a compelling reason to use the packaged solutions (NetRanger, OpenView, their ilk).
A packet is a packet... NFR and Snort are both designed by well-respected engineers who are more interested in accuracy and correctness than in unit shifting. I trust them for that.
When you get right down to it, unless you're rolling in dough, why blow $20,000 per management station plus consulting costs to implement something your network administrator can probably set up in a week for free? (I know I can) It's stupid. Save the cash for your coke dealer or a rock for the missus.
You pay for performance (Score:5, Informative)
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 [spirentcom.com] 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 [iss.net] that Snort supposedly beat, and I analyzed the source code for another one [networkice.com] 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.
Re:You pay for performance (Score:1)
Re:You pay for performance (Score:2)
And I don't think you were flaming, its a very legit suggestion.
Re:You pay for performance (Score:2)
Does your contract prevent you from pointing out where snort was slower and under what kinds of loads.
Re:You pay for performance (Score:1)
Why? Because a smartbits doesn't generate "real" application traffic. They don't do ftp, http, smtp, h.323, etc. So what point is there in using it to test/benchmark the throughput of a NIDS which needs to look into these protocols? None- which is why a smartbits is used to test routers, switches and things of that nature- not NIDS or firewalls.
Fact is I've used both ISS and Snort, and frankly they both suck. Both false positive up the wazoo. Only now that ISS is integrating the technology from NetIce are they able to have decent accuracy- and even then they've got a long way to go.
Not to mention trying to compare NetIce to Snort is like apples and oranges. NetIce does protocol analysis and snort is mostly signature based. Anyone in the industry who is honest will tell you that sigs will detect more attacks but require more processing time than PA. The [networkcomputing.com]
recent test by Network Computing is a good indication of this. (NetICE found 5/9, snort 8/9, Dragon, another sig based system found 9/9 attacks)
Re:You pay for performance (Score:2)
> NIDS should be flogged and then shot in the kneecap
I am aware of the fact that SMARTBITS alone is not sufficient to properly test a network IDS. I was merely giving an example of the expense someone has to incur to set up proper simulation environments to exercise their products so they will have good behavior in real-world networks.
SMARTBITS, while not sufficient by itself to properly test an IDS, is a tool that lets you push Ethernets to (and beyond) their theoretical limits. This is VERY DIFFICULT to do with other solutions.
> > Not to mention trying to compare NetIce to Snort is like apples
> > and oranges. NetIce does protocol analysis...
I see that, like many, you have fallen prey to Network ICE's excellent marketing machine. Yes, it does do protocol analysis, but it is not unique in this respect. RealSecure (ISS'es product prior to buying Network ICE) did protocol analysis before BlackICE even existed. NETICE was just better at getting that marketing message out. (Reminder: I've seen the source code to both products, and wrote large hunks of one of them).
Re:You pay for performance (Score:1)
If you can find me one NIDS review by a reputable 3rd party where they hooked up a NIDS to a SMARTBITS and reported the results I'll take it back.
As for ISS/NetICE/Snort... my point was this:
- ISS false positives so much that it is completely worthless. Now that they've got the NetICE tech, they should be able to fix this- time will tell.
- Snort false positives way too much too (see an earlier post by me on this topic)
- NetICE missed 45% of the attacks that NWC threw at it. Pathetic. I blame this for lack of signatures (which ISS/Snort/Dragon have and did significantly better in the test).
Re:You pay for performance (Score:1)
> they hooked up a NIDS to a SMARTBITS and reported the results I'll take it back.
Well for one, the review we are talking about, which you can download here [nss.co.uk], used a SmartBits (among other things) to generate background traffic during the performance tests. See pages 167 and 228 in the report.
Re:You pay for performance (Score:1)
Say you have a NIDS and you know about various protocols: ftp, telnet, ssh, http, smtp, snmp, h.323, etc.
Now you have an ethernet frame which reaches the NIC, it has an ip header in it. You pass it up to the NIDS.
The NIDS says, cool, something to look at. And runs it's various signatures/protocol analysis (PA) against the packet. But NIDS vendors aren't totally incompetent- they realize it doesn't make sense to apply ftp sigs/PA against anything other than ftp. Same goes true for every other protocol. This not only reduces false positives, but significantly improves performance as well (since you do fewer tests/packet).
So what happens when a SMARTBITS generates traffic? Well it can't create a vaild TCP stream, let alone a vaild HTTP connection, so the NIDS isn't going to do all those expensive checks for any SMARTBITS generated traffic. The result is that all the SMARTBITS traffic is never processed like "real traffic" which artificially inflates the performance of the NIDS.
NSS even realizes this is a problem (if you read between the lines) on pg 167 when they say "future tests will continue to enhance the 'real world' packet mix
This is why a SMARTBITS works great for testing routers/switches/etc- they don't bother looking into the data portion or even the header info for protocols above layer 3.
I monitor 2 DS-3's, that's all I need to... (Score:4, Informative)
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!
Enterprise Grade IDS (Score:1)
Simply aggregating the data from that many networks is a hassle, even if I only do it from the Internet and Store facing networks. Correlating data produced by Snort when you have over 20 gigs of aggregate backbone traffic is completely unreasonable.
I heartily recommend ISS Real Secure Network Sensor. I am in the process of deploying 230 Network Sensor and Host Sensor agents. With the addition of the "Black Ice" technology, acquired when they purchased Network Ice, it is the best solution on the market.
With their new Site Protector console, Data from all agents is correlated with scans performed by ISS Internet Scanner (works like CyberCop Scanner, or Nessus) and I don't get alerted if a system is not vulnerable!
I can add new systems, run an Internet Scanner scan once a week, and rest easy that if I get paged at 1am, a hacker really has breached the gates...
If Site Protector does not provide enough data correlation for you, you can get netForensics self titled product, or Open Systems Private Eye, and correlate the ISS data with your Cisco IDS's, Checkpoint and PIX firewalls, VPN boxes and routers.
While Snort is great to see what is coming into my house, I would never deploy it in an enterprise where your security administrators want to do more than sift IDS logs...
Re:Managers Like Names... (Score:1)
ya know.... (Score:3, Insightful)
For example, Yesterday I get hit with about 90 attempts to get cmd.exe on my webserver from one specific IP addy. So, a quick nslookup / whois later and I get the server name and contact info for the suspected malicious box.
Since it's from a major site, I decide to contact them to let them know they may have a potentially compromised box on thier network.
Three v-mails and two emails later, no word back from them.
I'm all for IDS's, but aside from possibly dishing out some Louisville Slugger style 'cease and desist' requests, what good is the info?
argent out
Re:ya know.... (Score:1)
You could firewall their entire netblock into oblivion.
If you run an internet router, drop all their port 80 packets.
If more service providers would do this then perhaps lazy companies would smarten up pretty quick if the internet they've paid for becomes useless.
Re:ya know.... (Score:1)
At the very least: trend analysis. It's always good to keep an open eye to what the Script o' the Day is.
You misunderstand. (Score:2)
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?
I think the general idea is to be aware of what's going on. If you are aware, you can be prepared.
If you look at a system like SNORT... it's not *really* and IDS. It's just something that checks for many, many common attack signatures. It tells you *nothing* about whether someone has intruded into your system. It's not really an IDS.
Now. the Linux IDS stuff... that locks certain files at the kernel level and notifies admin if anything tries to change.. THAT is an intrusion detection system. Someone has intruted, tried to modify something they shouldn't.. now you KNOW you have an intruder.
Triggers and such set up in some systems to detect when someone is where they shouldn't be is the real goal of an IDS.. not to tell you some new worm is trying to exploit your webserver.
Re:You misunderstand. (Score:5, Informative)
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.
Re:You misunderstand. (Score:1)
Regards,
ToeDruid
Re:ya know.... (Score:2, Insightful)
And of course, and IDS logs can be valuable when it comes to forensic investigations.
Zeshan
Re:ya know.... (Score:2, Insightful)
I get a very good response rate, possibly as high as 80%...100% if you consider that the offending activity generally stops shortly after I have reported it...
Maybe it's the tone you're using...
Re:ya know.... (Score:1)
For example, Yesterday I get hit with about 90 attempts to get cmd.exe on my webserver from one specific IP addy. So, a quick nslookup / whois later and I get the server name and contact info for the suspected malicious box.
What is the big deal here? You have an Intrusion Detection System, you detected an intrusion. Now, let them know you dectected them. I wrote a simple script that pings the host back on the port they scanned, kind of says "hey, im here, im watching you, DON'T mess with me, im not a moron".
New IDS model (Score:1)
ACID and Barnyard for Snort users -- great stuff! (Score:5, Informative)
Anyways, I want to throw in a shill for ACID [sourceforge.net] 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 [packetninja.net] 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 ;-).
Re:ACID and Barnyard for Snort users -- great stuf (Score:3, Informative)
ACID looks great...but it requires PHP. :^/
Does anyone have good information on how to compile Apache with mod_perl and PHP and SSL?
Re:ACID and Barnyard for Snort users -- great stuf (Score:3, Informative)
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.
Re:ACID and Barnyard for Snort users -- great stuf (Score:1)
Re:ACID and Barnyard for Snort users -- great stuf (Score:2)
moby_apache setup (php + perl + ssl) (Score:2)
At least, that worked for Apache 1.3.12 on FreeBSD 2.2. Like I said, it's been a while since I needed to prototype an Apache module (sooner or later it's best to move them all to C, IMHO).
Re:ACID and Barnyard for Snort users -- great stuf (Score:1)
It's in the process, stoopid (Score:4, Insightful)
Snort may be cheap and easy to install, but many corporations buy IDS on the strength of the management and reporting capability.
One of my clients went with Cisco Netranger IDS because it offers excellent Monitoring screens that are then staffed by a 24/7 response unit waiting for alerts on the border/dmz/back office networks. It then made it straightforward to sit semi-skilled staff in front of the consoles to monitor activity and alert a skilled technician (i.e. me in this case) if an amber or red warning occurred.
While Snort may be free, you would have to roll your own management stations (though I guess someone has done this), and thus management costs creep in.
PleasePleasePlease remember software costs are rarely in the price
DANGER: I'm not flaming snort, I just haven't had to chance to try and scale it up into an enterprise-type situation.
a great management console for Snort... (Score:1, Redundant)
<p>
Try it. <a href="http://acidlab.sourceforge.net/">ACID homepage</a> 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 <a href="http://firedrake.org/thothproject/">Thoth</
<p>
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.
<p>
Management console for Snort, take 2.... (Score:3, Informative)
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 [sourceforge.net] 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 [firedrake.org] 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. :-)
FIrewall Firewall Firewall (Score:4, Insightful)
The Future of IDS (Score:2, Funny)
Future of IDS (Score:3, Funny)
What?
Intrusion Detection Systems? You mean this isn't about Iain Duncan Smith?
Re:Future of IDS (Score:2)
Basically, they are saying that Iain Duncan Smith has been hacking into computers and taking Snort, right?
Demarc Console frontend for Snort (Score:1)
Re:Demarc Console frontend for Snort (Score:1)
Where's the proof? (Score:1)
The thing is that it's just a summary - no methodology is discussed - no results from the tests with any of the vendors - no reasons at all are given for crowning Snort the king.
Hell, for 10 minutes of work, I'll put up a web page that says Apache running off my wristwatch is the ultimate in web serving. Doesn't make it true...
Re:Where's the proof? (Score:3, Informative)
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.
mirrored (Score:1)
a world of 100% encryption? (Score:2)
The fundamental fact is that we will never get to the point where all traffic sent out over the great big I is encrypted. Its a matter of simple economics. Things like publicly available web sites, DNS, and even email don't need to be encrypted, nothing is gained by protecting that data. That's why it's a public service. Therefore, content providers (those deploying IDS) will never fork out the $$$ to buy equipment which can handle the load produced by millions of daily transactions that come down to just to encrypting index.html and decrypting GET index.html requests.
As an IDS analyst for the last two years in a Fortune 10 company, I can tell you from first-hand experience that 90%+ of the attacks we see on a daily basis are HTTP-based. DNS comes in second, because guess what? It's one of the needed public services offered by content providers on the Internet. Why encrypt data you're offering out to the whole world?
Nice article for CIOs, but I'm getting tired of hearing that encryption is going to get rid of NIDS. It's an omega point that we'll just never get to.
Why you encrypt data being offered to the world (Score:2)
Just because it goes over the internet doesn't mean it's no private. Financial, insurance, and login information, among many others. All of these things go through "public" web sites. I work for a bank. Most of our web traffic travels under the covers of SSL.
Right now, we're implementing an SSL terminator near the front door. SSL doesn't have to terminate on the web server. If it doesn't, you have the ability to let your SSL move across the web farm, not being server-bound anymore, never mind the overhead SSL imposes on a web server. Does moving SSL traffic unencrypted across the network between firewall and server squick me? You betcha. Does it squick me as much as not seeing IDS on the majority of our traffic? No way.
Even with IPv6 and IPsec, IDS isn't going away anytime soon, for exactly the reason outlined above.
IDS Performance, False Positives, and The Future (Score:4, Insightful)
The problem with that is that the number of alerts does not determine the efficiency and efficacy of an IDS does. As Stefan Axelsson points out in his paper "The Base Rate Fallacy and its Implications for the Difficulty of Intrusion Detection [raid-symposium.org], the real limiting factor in IDS performance will ALWAYS be the number of false positives generated.
Unfortunately, not many people seem to be working in the direction to deal with that problem. Most of the major IDS vendors are talking only in terms of getting faster, and having more rules.
The only company I've actually seen that is looking at any new paradigm to deal with this problem is nCircle [ncircle.com]. Their system has an IDS and a vulnerability scanner working together to accomplish the reduction in false positives.
It's not a perfect system, but it performs significantly better than any of the IDS products that I've seen. And it definitely shows some sort of vision into the future, and into dealing with the real problems with the way IDS is currently done.
Just my $0.02...
How to get round the slashdot filter (Score:2)
Writing Linux viruses is easy (slightly OT) (Score:3, Interesting)
I could try submitting this to
Here's the link (sorry) (Score:2)
Re:Writing Linux viruses is easy (slightly OT) (Score:2)
First, the guy who gave that quote is from McAfee. They are complacent. They sell loads of software for one platform, and have no interest in writing software for Linux. Scaring people away from it will keep down the market. Either that, or they don't know how to improve upon the existing security.
Second, advocating security through obscurity again backs up their market share. It's also been proven time and again to not work.
This is not to say that the article wasn't without it's good points. Social engineering can work just as well with Linux users as Winxx users. As the Linux base grows, they will become a more welcome target (especially if they are a firewall protecting all of those juicy WinXY boxes behind them). And yes, Li0N and Ramen 'prove' that Linux is not 100% secure. But only a few psychos claim that anyway.
The reason that I think the general premise of the article (Linux will see big cracks soons) is that doing cracks on M$ stuff is so trivially easy at this point, and it hits a lot of machines. Spreading stuff via
As long as Linux (and BSD and others) remain non-trivial to crack, M$ will remain the platform of choice.
The State of IDS (Score:3, Interesting)
The basic problem with all IDS is in the confidence level of determining if something is an attack or just random garbage. Also, IDS have to be fast. If there's too much traffic (if you've been
Right now, nearly all IDSes are extremely primitive and consist of nothing more than snort [snort.org] rules [snort.org] and Perl [perl.com] scripts that call ipchains [samba.org] or something.
Btw, I went to RAID 2001 [raid-symposium.org] this year (hosted at UCD), it was fairly interesting.
prognosticate? (Score:1, Offtopic)
Re:prognosticate? (Score:1)
It's also has more than just a web interface. See the DICT RFC [isi.edu]. There are clients available etc.
But when is Snort going to get good sigs? (Score:5, Insightful)
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.
Re:But when is Snort going to get good sigs? (Score:1)
In other words, every packet that enters the system (detection area, based on whether the detection is network based or host based).
The cause and effect is two fold. A packet with a string contained therein may be detected falsely as an attack can be masked by using unicode or shell code, etc.
the second effect is that since each packet or stream is matched against every pattern in the database, is that the engine is easily bogged down and with some simple techniques, can be made to drop packets in order to not kill itself off.
There is no perfect solution for this that I know of..
however, there are more efficient ways to handle both these problems.
Packet and Stream disassembly can be used to reduce the amount of overhead and greatly reduce the anmount of mis-detections (both false positive and false negative).
First, breaking down the stream to determine protocol, source, destination, payload, etc..
once a stream is broken up, analyzing it for content is much simpler and quicker becuase you dont have to check all the unklreated traffic against all the signatures in the database.. only those which pertain to the specific protocol in use, if any matching is necessary at all.
Now.. this technique can be done right and be done very wrong. do it wrong and youll spend much more time disassembling things and using more resources than the pattern matching engines.
Doing it right means quickly limiting the amount of matching that needs to be done and reducing overhead even in high traffic situations.
Of course, as with any method, there are weaknesses. This method can reduce cpu and memory requirements, increase accuracy and reduce false negatives and false positives.
As another colleague pointed out, IDS is an early warning system. In any of its incarnations, its nearly innefective without escalation and constant monitoring.
LW-
Links (Score:3, Interesting)
Automated Discovery of Concise Predictive Rules for Intrusion Detection [iastate.edu]
Snort & BigBrother (Score:2, Informative)
/Haeger
Re:Snort & BigBrother (Score:1)
The false positive myth, & escalation vs detec (Score:2, Informative)
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
Get the real report from NSS. (Score:2, Informative)
Save yourself a few hours (Score:2)
in snort.conf:
change
var EXTERNAL_NET any
to
var EXTERNAL_NET !$HOME_NET
Otherwise, you'll see all your local hosts matching rules meant for external traffic. That's a little confusing.
Yet another clueless magazine... (Score:1)
Why oh why do they always call it freeware wrongly [gnu.org]?
The past of IDS (Score:2)
As I said, this was the Network ICE business plan from three years ago. We built a product to address these issues, we shipped it, we were successful, and this product is being mixed with the rest of ISS's technologies to become RealSecure 7.
I hate to come out with a "vendor" message, it is just that the author is most familiar with Snort, where these things are issues. He makes the assumption that other products are just commercialized versions of Snort. This isn't true -- at least in the case of our commercial product, it isn't related to Snort at all. He is maybe describing "The Future of Snort", but this is three years old for BlackICE.
Several comments (Score:2, Informative)
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 [mailto], 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 [networkcomputing.com] roundups [nss.co.uk] 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 [sourcefire.com], 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 [cert.org] 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
Re:Several comments (Score:1)