again, i'm cross posting to the log analysis mailing list cos, well, it's my list ;-) On Mon, 3 Nov 2003, Eric Johanson wrote: > Sorry for the IDS rant. I'm sure ya'll have heard it before. My only > real exsposure to IDS is via snort. > oh, you know us shmoo, we have absolutely no tolerance for rants :-) > It works on 'blacklists' of known bad data, or stuff that 'looks bad'. > > This doesn't really help when dealing with new types of attacks. Most > can't deal with a new strean of outlook worm, or can tell the difference > between a (new, never seen) rpc exploit, or a simple SYN/SYNACK. > this is true...ish. f'r one thing, lots and lots o' exploits are based on known vulnerabilities, where there's enough information disclosed prior to release of exploit that reliable IDS signatures exist. nimda's my fave example of this. especially for its server attacks, nimda exploited vulnerabilities that were anywhere from 4 months to 2 years old. all the IDS vendors had signatures, which is why nimda was discovered so quickly and so rampantly. in the limited dataset i had -- counterpane customers with network-based intrusion detection systems watching their web farms -- the message counts increased by an order of 100000 within half an hour of the first "public" announcement of nimda (a posting at 9:18 east coast time on 18 sept 2001, on the incidents@private mailing list) (not that i was scarred or anything). so in that particular instance, signature based IDS was certainly highly effective in letting you know that something was up. several of the signature based IDS vendors claim that they base their signatures on the vulns rather than on a given exploit -- i don't really know what that means, but i do know that several of them detected this summer's RPC exploits, based on the info in the microsoft announcement, and the behavior of the vulnerable code when tickled, as opposed to waiting to write a signature after an attack had been discovered. we got attack data from ISS far faster than could have been explained if they were strictly writing in response to new attacks. > I suspect we'll start seeing products in a few years that are focused on > 'whitelisting' traffic. Anything that doesn't match this pattern, kill > it. > > While this is a pain with lots-o-crappy protocols, it is possible. Does > anyone know of a product that functions this way? > there are a couple of IDS vendors that claim to do this -- they tend to call themselves anomaly detection systems rather than intrusion detection systems -- and i've yet to be convinced about any of them. the only one i can think of is lancope, but rodney probably knows better than i do. the statistical issues are huge, because you've got to be able to characterize normal traffic in real time with huge numbers of packets. it's more approachable IMNSHO for log data -- marcus ranum's "artificial ignorance" approach -- because you get far less data from a system or application log per actual event than you get numbers of packets. of course i'm not convinced that getting >less< data is an entirely good thing -- see below.... > The other big problem I see with IDS systems is the SNR. Most are soo > noisy, that they have little real-world value. > > I think doing real time reviewing of log entries would have a much better > chance of returing useful information - - but again, should be based on > whitelists of know good log entries, not grepping for segfaulting apaches. > well, segfaulting apache is actually an important thing to watch for, cos it shouldn't ever happen in a production environment -- right, ben? the HUGE MASSIVE **bleeping** PROBLEM with using log data for this is that general purpose applications and operating systems completely suck at detecting malicious or unusual behavior. where by "completely suck," i mean: -- take default installs of solaris, winNT, win2000, cisco IOS, linux -- get your favorite copy of "armoring solaris," "armoring windows" blah -- do the exact >>opposite<< of what the docs say -- that is, make the target systems as wide open and vulnerable as possible -- take your favorite vulnerability auditing tool, or hacker toolbox, and set it to "nuclear apocalypse" level (that is, don't grab banners, run the damn exploits) -- turn the logging on the boxes to 11 ---> the best you'll see is 15% of the total number of attacks, AND what shows up in the logs is invariably >not< the attack that actually rooted your box. as ben clarified for me a lot when i saw him last month, a root compromise that succeeds generally succeeds before the poor exploited daemon has a chance to write anything in the logs. what you see in the logs are traces of what >didn't< work, on the way to getting a memory offset or a phase of the moon just right and getting a rootshell. [this number based on a summer's worth of lab work i did at counterpane; needs to be repeated with more aggressive hacker tools and rather more tweaking of system logging...] > Any comments? > > As for Rodney's comment: For Network based ISDs, I think we need to not > look at attacks, but look at abnormal traffic. EG: my web server should > not do dns lookups. My mail server should not be ftping out. Nobody > should be sshing/tsing into the DB server in the DMZ. My server should > only send SYNACKs on port X,Y and Z. > > I'm pretty sure that snort could be made to do this - - but it doesn't do > this today without some major rule foo. well, anywhere you can build your network to have a really limited set of rules, this approach is easy. hell, don't want my web server doing name resolution or web >browsing< -- so run ipchains or iptables or pf and block everything but the allowed traffic and get the logs and alerts as a fringe benefit. doing it for the content of web traffic is a little trickier but still completely plausible because web logs are relatively well structured. for some really vague definition of "relatively." doing it for a general purpose windows server or a seriously multi-user unix environment is a lot harder, cos the range of acceptible behavior is so much larger and harder to parametrize. but hey, that's >>exactly<< what the log analysis list (and web site) are working on... and is also why i am continually pestering my friends in the open source development community to give me logging that is more likely to catch things like client sessions that never terminate properly (to catch successful buffer overflows) (give me a log when a session opens and >then< when it closes)...and things like significant administrative events (like sig updates in snort, or config changes on my firewall). had a fascinating talk with microsoft today about getting them to modify their patch installer (the thing that windows update >runs<, not windows update itself) so that in addition to creating a registry key for a patch when it >begins< an install, it also generates a checksum for the new files it's installed when it >finishes<, and then put that into the event log where i can centralize it and monitor it and have a higher level of confidence that the damn patch succeeded... not that i've been thinking about this stuff a lot lately or anything. tbird _______________________________________________ LogAnalysis mailing list LogAnalysis@private http://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2b30 : Mon Nov 03 2003 - 23:49:54 PST