IDS mailing list archives
RE: Intrusion Prevention requirements document
From: "Tony Haywood" <thaywood () karalon com>
Date: Wed, 9 Nov 2005 22:52:43 -0000
IDS Informer like Traffic IQ Pro is an advanced packet replay tool and can be used to validate inline and passive intrusion detection/prevention systems. In both instances the applications have no concept of the device being tested and therefore has no understanding on the outcome of the attack, it is just generating the traffic, the only information it has is if any of the packets are failed to be delivered. A successful attack within both applications is based on whether or not all of the packets in the traffic files were received by the opposing network card. The difference between the successful and unsuccessful traffic files themselves is, as you correctly pointed out, based on whether the particular attack/exploit was successful. In many cases it is important for an IDS/IDP to know the difference. Taking a simple example such as the DNS Zone Transfers - escalation procedures may require remediation work if an IP other than a secondary DNS was able to transfer zone details. In this case the successful file would be used. If on the other hand you wanted to ensure that all unsuccessful attempts were logged but not acted upon then you would use the unsuccessful event. In both cases an IDS/IDP should be able to differentiate between the two and alert accordingly. Your second point in relation to attack detection and false positives is interesting. It is well known that network based intrusion detection/prevention systems can be produce a high degree of false positives and unfortunately IDS Informer can add to that as it will attempt to replay the remainder of an attack even though it has already been detected and blocked. Traffic IQ Pro does not have this problem and will not cause additional false positives. The second part of your question is more of a theological debate however.
From a standpoint of "all attacks should be detected and blocked prior to
execution" I would expect an IDS to detect the attack prior to it reaching a point that could cause a compromise to my internal/protected systems although this is not always possible. In some cases though it is best to let the attack take its natural course for evidential purposes. For me, if an attack succeeds then its too late, the damage has been done. It is worth pointing out that in many cases it is not possible to detect an attack at the point of inception as there is not enough information available to make an accurate determination. There is a bug in IDS Informer that prevents it from displaying the correct information in certain scenarios. This can lead to different information being displayed for an audit and packet level report of the same event. Traffic IQ Pro does not exhibit this flaw. Using Traffic IQ Pro it is possible to run an audit level report for multiple files to determine which succeed and which fail. Then typically a packet level report would be run on the ones that failed to determine at which point they failed to see if the detection point is acceptable. For instance, blocking an attack at packet 47 when the attack can be run in 46 is not very useful. Regards Tony -----Original Message----- From: Sanjay Rawat [mailto:sanjayr () intoto com] Sent: 08 November 2005 04:42 To: thaywood () karalon com; focus-ids () securityfocus com Cc: pen-test () securityfocus com Subject: RE: Intrusion Prevention requirements document Hi: to tell the truth, I was thinking to post a query regarding IDS informer. I worked with IDS informer and observed some points. 1. I m still not clear on "how IDS informer decides that attack was not detected?" 2. On false positives, we observe that so called U traffic, corresponding to an attack, mainly differs in the response part. in this case, if an IDS/IPS detects the attack, it flags it as false positive. but it should be noted that attack is launched against a target. Now, i m confused on one thing- for an IDS/IPS, what should be the modus of operandi? should it detect an attack on the very moment it is launched, or it should wait for the response from the target to see if it is really successful? In the second case, though FP may be reduced, but for an IPS, it can be dangerous thing. 3. sometime, packet level auditing and connection level auditing differs, as far as the final results are concerned. please impart your expert views regards Sanjay At 02:23 AM 11/5/2005, Tony Haywood wrote:
One of the ways that you could test safely is by using something like Traffic IQ Pro or a similar product. It is a stateful traffic replay tool and can be used to test any inline or packet monitoring device. The product uses two network cards and so the library of over 700 normal
and
threat traffic files can be replayed statefully without the need to connect to a live target system. This allows for live production systems to be testing for the correct configuration really quickly and easily. I have been involved in working in this area for a number of years now and my previous company was Blade Software where I developed IDS Informer and Firewall Informer to provide similar testing capabilities. Information on Traffic IQ Pro is available below should you want to take a look. http://www.karalon.com/Karalon/TrafficIQ/TrafficIQ.htm Working with testing labs and a number of security and networking vendors has enabled Traffic IQ Pro to be a really useful tool for anyone who wants to check the configuration of their firewalls, IPS, IDS, routers, switches etc and see how those devices perform under different scenarios. Tony Tony Haywood www.karalon.com -----Original Message----- From: vendortrebuchet () comcast net [mailto:vendortrebuchet () comcast net] Sent: 29 October 2005 20:40 To: focus-ids () securityfocus com Subject: Re: Intrusion Prevention requirements document Another question for everyone, When you brought in each vendor for evaluation, did you configure a test network for them or did you use your production network? My 1st concern is keeping my job :o) If I test in production, I could impact production traffic. If I don't test in production, how can I best ensure that I won't have problems with custom applictions, older IP stacks which could be an issue if RFC compliance checks are done, etc. The vendor answer is always, "don't turn on blocking and just monitor." Is that a reality? I'd like some testimonials to this and some real life instances of what has been done from unbiased sources. Thanks, VTAll, I work on a team that manages signature and behavioral based intrusion detection systems today. We have been tasked with reviewing IPS (or whatever vendor name acronym you prefer) in '06. Our normal process is to put together a base requirements document to weed out vendors in the first round through a paper excercise and then bring in the best we can identify. My question is, has anyone developed a matrix that identifies key qualifiers in an IPS solution (e.g. in-line, fails open/closed, reporting features, etc.). If so, could you provide links
or
the documents?If not, what categories are most significant to consider in your expert opinions? What reasons did you choose the solution you have? What would you consider if you had to choose over again, etc? Thanks in advance for your responses. VT
---------------------------------------------------------------------------- -- Audit your website security with Acunetix Web Vulnerability Scanner: Hackers are concentrating their efforts on attacking applications on your website. Up to 75% of cyber attacks are launched on shopping carts, forms, login pages, dynamic content etc. Firewalls, SSL and locked-down servers are futile against web application hacking. Check your website for vulnerabilities to SQL injection, Cross site scripting and other web attacks before hackers do! Download Trial at: http://www.securityfocus.com/sponsor/pen-test_050831 ---------------------------------------------------------------------------- --- ------------------------------------------------------------------------ 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. ------------------------------------------------------------------------
Current thread:
- Re: Intrusion Prevention requirements document vendortrebuchet (Nov 03)
- RE: Intrusion Prevention requirements document Tony Haywood (Nov 07)
- RE: Intrusion Prevention requirements document Andy Cuff (Nov 08)
- RE: Intrusion Prevention requirements document -Apology Talisker (Nov 09)
- <Possible follow-ups>
- RE: Intrusion Prevention requirements document Arun Vishwanathan (Nov 07)
- RE: Intrusion Prevention requirements document FinAckSyn (Nov 09)
- RE: Intrusion Prevention requirements document Tony Haywood (Nov 10)
- Re: Intrusion Prevention requirements document Mike Frantzen (Nov 14)
- Re: Intrusion Prevention requirements document Bob Walder (Nov 10)
- RE: Intrusion Prevention requirements document FinAckSyn (Nov 09)
- RE: Intrusion Prevention requirements document vendortrebuchet (Nov 07)
- RE: Intrusion Prevention requirements document Tony Haywood (Nov 10)
- RE: Intrusion Prevention requirements document Chris Ralph (Nov 14)
- Re: Intrusion Prevention requirements document ADT (Nov 16)