I read Tina's first message and decided not to wade in, but now, I'm gonna :-) One thing that continually surprises me in reading the mailing lists, particularly the IDS and snort-* lists, is how much people _who really should understand their environment_ rely on signatures that either don't apply at all or have very little chance of triggering. For example, with Blaster etc., the discussions I've seen revolved around how to write a signature for the attack or a signature for the vuln, but no one seems to have noticed that none of these rules will trigger on a TCP-based worm if the worm scans null addresses (i.e. unused addresses within the network or unreachable non-network addresses). We've got the blaster sig in, and it never fires. On the other hand, we've got a sensor that watches the default route and alerts on any TCP 135/139/445 connection attempt that's following it. We've got thresholds set up that generate a bunch of emails/pages if a single source tries connecting to X number of unique destinations in Y period of time. This has caught not only blaster-like attempts but also people with Randex, which wasn't even out when we set the system up. Furthermore, in 99% of the cases we've seen, both with Blaster-type and Nimda, SQL Server, etc., when the randomization feature kicks in, the infected hosts tend to scan unreachable addresses. If we only looked for the signature of the attack/vuln, we wouldn't have known about the attack until a) a valid address was scanned, and b) the connection crossed a link our sensors were watching. And that still only deals with active, malicious attacks. User stupidity has no signature, and a properly-tuned IDS can go a long way towards resolving misconfiguration problems, (wrong netmask, unapproved software, DHCP not updating DNS entries properly, etc.) too. Yes, patching is important. I don't deny it, but so is taking the time to actually understand your network (what addresses are supposed to be in use, what protocols should occur, what kinds of traffic should _never_ occur, etc.) and tune your rules to match your network. Simply buying/installing IDS/Firewalls/Log monitoring/whatever won't deal with the issue. I don't remember who said it now, but somewhere in this thread there was a comment about IDS not being able to detect something without going through a bunch of work customizing the rules. I hate to point this out, but properly managing and maintaining the IDS is the only way intrusion detection will be of any use and, quite frankly, is what we're supposedly being paid to do as IDS analysts. Jon -----Original Message----- From: Bruce Potter [mailto:gdead@private] Sent: Tuesday, November 04, 2003 7:39 AM To: The Shmoo Group Cc: loganalysis@private Subject: [logs] Re: [TSG] intrusion detection and log analysis [was: book advice] <snip> In short, if you spend your IDS budget on figuring out how to do patching right and mabye even for some external auditing of your network, you'll probably not see many valid hits on your IDS. _______________________________________________ LogAnalysis mailing list LogAnalysis@private http://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2b30 : Tue Nov 04 2003 - 14:08:35 PST