Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Focus-IDS
[Top] [All Lists]

RE: Foolin an IDS ?

Subject: RE: Foolin an IDS ?
Date: Sun, 5 Dec 2004 10:13:45 -0500
Most IDS/IPS Vendors today account for the papers mentioned.  

Yup. I feel really sorry for any vendor that is currently evaded by ip
fragmentation. But the papers have a historical value of putting the
reader in the mindset required to nitpick how IPS's are built. 

Test methodologies for IDS/IPS technologies has mutated a bit.  

I am sure glad. The "pay no attention to the man behind the curtain" bit
has gotten old.

Some IDS/IPS vendors utilize various commercial and non-commercial
tools 
to test their products, The issue at hand is how does one separate out

true IPS evasion techniques to validate IPS based attacks only.

You would have to start with the question what is a true IPS evasion
technique? I tend to think of it as any technique used to take an
exploit that is normally stoppable by the IPS and get it by with no
detection. 

Going on this definition I would build an attack tree based on what
works and what doesn't. Two stage testing seems to be in order. Find a
public that the IPS should stop without question. A great example would
be MS03-026. I really feel if you can't stop MS03-026 you should not
call yourself an IPS. Run the vanilla public proof-of-concept and record
on a clipboard if it is detected or not. A labcoat may also be in order.


Now you have a baseline for the IPS performance. At this point IPS
evasions techniques can be applied. Based on the results of these you
can tell where the vendor has problems. For instance if RPC
fragmentation bypasses it's a pretty safe bet that and protocol that has
the ability to fragment or chunk you can most likely sneak attacks by.
This can build a pretty nice tree for testing true IPS evasions. 

The baseline exploit should be constantly changed or vendors we will the
same type of enhancements in this space as tester found in the video
card space. Results can be cooked to do one thing very well but are not
indicative of real world results.

These are false-negatives though, or getting an attack by that the
device should trigger on. False positives are useful for testing how
well things are actually detected. Things like embedding the offending
GUID from MS03-026 in a word doc and seeing if the corresponding alert
is raised gives enormous insight into the detection ability of the
device. 





--------------------------------------------------------------------------
Test Your IDS

Is your IDS deployed correctly?
Find out quickly and easily by testing it with real-world attacks from 
CORE IMPACT.
Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708 
to learn more.
--------------------------------------------------------------------------


<Prev in Thread] Current Thread [Next in Thread>