IDS mailing list archives
RE: Network hardware IPS
From: "Augusto Quadros Paes de Barros" <augusto () paesdebarros com br>
Date: Fri, 10 Oct 2003 13:22:49 -0300
About the cmd.exe rule, Yes, evasion techniques can be used against it. Just like metal detectors can be used against mined fields, but no one believes that mined fields are not effective because of it. If a rule trying to catch cmd.exe is the only rule that you have on your IDS, it is bad. But if you use it as part of a strategy, it will only improve your system. OK, the rule can catch 9 in 10 cases? Will anybody discard this rule because it can't catch all cases? A multi-layer approach should be used on IDS rules too. Regards, Augusto Quadros Paes de Barros, CISSP http://www.paesdebarros.com.br -----Mensagem original----- De: Dave Killion [mailto:Dkillion () netscreen com] Enviada em: quinta-feira, 9 de outubro de 2003 13:18 Para: 'Kohlenberg, Toby' Cc: focus-ids () securityfocus com Assunto: RE: Network hardware IPS Responses inline, as usual... ;) -----Original Message----- From: Kohlenberg, Toby [mailto:toby.kohlenberg () intel com] Sent: Thursday, October 09, 2003 12:45 AM To: Dave Killion; david maynor Cc: Stefano Zanero; focus-ids () securityfocus com Subject: RE: Network hardware IPS
That's a great ideal. When was the last time you tried to implement a rule that would catch attacks against buffer overflows in HTTP servers when the NOP sled can change content and size, the content of the attack code can change content and size and the only likely constant is that it contains cmd.exe?
Rules for specific exploits are easy- that's why worm rules are a cakewalk. The hard ones are the ones for the actual vulnerability the exploit is hitting. It is absolutely possible, it is just much harder to do without generating the occasional false positive.
I agree completely - I never implied I could always catch everything. No, I don't have an easy job.
Anyway, anyone who's crazy enough to put "cmd.exe" in his path deserves all the False Positives he can stomach. And quoting a 5-year old paper on IDS evasion doesn't convince me.
See above. I'll take it out of the signature base if you explain to me how you are going to catch novel or semi-novel attacks using very specific rules that are looking for known patterns.
I don't know what you mean here - one of us is misunderstanding each other. Stephano implied that there was a case that cmd.exe could be a valid (non-hostile, i.e False Positive) URL match. This was my response - if that's valid in your environment, you should have your head examined. And as for the IDS-evasion paper comment, we've read it too, and done as much as possible to NOT be evaded. What I want to see is a new paper, less than 5 years old, that has something *new*. I'll be very interested in reading that.
If I can create signatures to detect the majority of important attacks with a minimum of false positives, to the point where customers will buy the product, then my job is successful.
Ah, but you see, that's the problem. Most of us aren't _selling_ IDS/IPS/deep_packet_inspection whatever. We actually have to _implement_ them and make them work. Which means that they not only have to _not_ produce more false positives than we can handle, they actually have to _catch_ bad things that aren't easily and clearly defined already. Which means fuzziness, which means false positives. We don't get to focus on the "majority" of "important" attacks. Which would be the important ones? Exactly what percentage is "the majority"? Perhaps you didn't mean what you said because it comes across as meaning that you aren't interested in delivering a complete product, just the bare minimum necessary to get you in the door.
I don't sell this thing - I make it. And I use it = "eating your own dog food" as they say. So I *do* _implement_ this device, and I want it to work as effectively as possible. I'm as demanding of a user as any of my customers. So no - I'm not going for the bare minimum. I'm going for the maximum possible - we're always pushing the limits of the product, and trying to surpass all competition - by providing the most complete product possible. And we're always looking to reduce false positives, while maximize detection rates. Which is why I was so frustrated at Stephano for implying that the two values are inseparable. As for detecting the "majority" of "important" attacks - do you really have time to track down every port scan? How important is it when you're being "attacked" on something you have no vulnerability against (i.e. you run only Apache, and someone tries to attack you with an IIS-specific vulnerability)? Do you want to be paged at 3am by your IDS/IDP, only to find out it wasn't a valid attack? "Majority" and "Important" are defined by our customers. And if we've missed something, they tell us. Any valid signature request that comes from the field is generally in next week's release. And they can make their own, as well. I hope this clears things up. This email contains material that is confidential. The content of this email is for the sole use of the intended recipient(s). Any review or distribution by persons other than the intended recipient(s) without the express permission of NetScreen Technologies, Inc. is strictly prohibited. If you are not the intended recipient, please contact the sender and delete/destroy all copies of this email and any related attachments. NetScreen does not guarantee the accuracy or completeness of third party materials or information. Augusto Quadros Paes de Barros, CISSP http://www.paesdebarros.com.br --------------------------------------------------------------------------- Captus Networks IPS 4000 Intrusion Prevention and Traffic Shaping Technology to: - Instantly Stop DoS/DDoS Attacks, Worms & Port Scans - Automatically Control P2P, IM and Spam Traffic - Precisely Define and Implement Network Security & Performance Policies FREE Vulnerability Assessment Toolkit - WhitePapers - Live Demo http://www.securityfocus.com/sponsor/CaptusNetworks_focus-ids_000101 ---------------------------------------------------------------------------
Current thread:
- Re: Network hardware IPS, (continued)
- Re: Network hardware IPS Stefano Zanero (Oct 07)
- RE: Network hardware IPS david maynor (Oct 08)
- RE: Network hardware IPS Dave Killion (Oct 07)
- Re: Network hardware IPS Stefano Zanero (Oct 07)
- Re: Network hardware IPS George W. Capehart (Oct 08)
- RE: Network hardware IPS Dave Killion (Oct 08)
- RE: Network hardware IPS Frank Knobbe (Oct 09)
- RE: Network hardware IPS Kohlenberg, Toby (Oct 09)
- RE: Network hardware IPS Dave Killion (Oct 09)
- Re: Network hardware IPS Stefano Zanero (Oct 14)
- RE: Network hardware IPS Augusto Quadros Paes de Barros (Oct 14)
- RE: Network hardware IPS Dave Killion (Oct 14)
- RE: Network hardware IPS Frank Knobbe (Oct 14)