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. |

| Subject: | Re: IPS Reliability/Availability |
|---|---|
| Date: | Wed, 22 Feb 2006 11:40:16 +0100 |
I think there were some known issues with those boxes when they first switched focus from supplying firewall vendors to supplying in-line IPS vendors. I think most of them have been addressed in recent releases, and you might find another look to be beneficial Bob Walder The NSS Group On 20/2/06 01:43, "Alan Shimel" <ashimel@stillsecure.com> wrote:
Guys Without data on what rules are turned on and what type of traffic you are putting through the box, all of this data is at best very suspect. We put the same box you guys are talking about through every conceivable test and I know for a fact the numbers don't add up. In fact in speaking to the mfr. They confirmed that they have not seen the throughput they advertise in what we would consider real world conditions. Lets see 3rd party data! alan StillSecure Alan Shimel Chief Strategy Officer O 303.381.3815 C 516.857.7409 F 303.381.3881 email ashimel@stillsecure.com blog http://ashimmy.typepad.com www.stillsecure.com The information transmitted is intended only for the person to whom it is addressed and may contain confidential material. Review or other use of this information by persons other than the intended recipient is prohibited. If you've received this in error, please contact the sender and delete from any computer. -----Original Message----- From: Mike Barkett [mailto:mbarkett@nfr.com] Sent: Thursday, February 16, 2006 3:40 PM To: 'David Williams'; 'Andrew Plato' Cc: geek_brigades@yahoo.com; focus-ids@securityfocus.com Subject: RE: IPS Reliability/Availability David - This reads like a plug post, but you asked, so here goes anyway. I will point out that we should have some real-world *3rd party* test data to share with you by this Summer. And surely that will be of much more value to you than anything we vendors can spout. The NFR Sentivist Enterprise Series sensors utilize the RISC-based architecture you describe. Of course, we believe it to be the evolution of high-speed prevention, and a step beyond ASIC-based IPS. (Let the controversy begin.) To answer your questions specifically: 1. You're correct on the processors; using real-world customer data and Web Avalanche tests of all different packet sizes, our ES1000 appliance does inline prevention across four networks at an aggregate 1Gbps, or IDS across eight networks at 2 Gbps. We also have a 2/4Gbps and a 5/10Gbps appliance. We have not sat the ES sensors directly next to an ASIC solution, but if we take the ASIC vendors' marketing material at its word, then by comparison our RISC-based ES sensors deliver equivalent or superior throughput and latency, and better resilience to policy complexity. The latter was an important consideration for us, since NFR's prevention engine is well-known for being more thorough than that of the typical IPS. 2. I do not know the full list, but I do know that Sourcefire uses hardware technology similar to ours. Actually, I'm very curious, what other RISC-based vendors have you worked with besides Sourcefire, and have you researched NFR? 3. As you can imagine, I could go on forever on the pros and cons of this architecture, mostly pros of course. :) But I'll boil the pros down to flexibility, redundancy, and scalability, all in addition to the aforementioned performance. To give you an example of flexibility, you'll recall the recent thread on IPv6. NFR supports IPv6 natively. But if we didn't, then updating our RISC-based ES sensors to handle such a major engine change would be significantly easier than updating an ASIC-based device. On redundancy, the multiple processor board architecture allows you to hot-swap processor boards if necessary, plus it makes it impossible for an attacker to DoS the box by dominating a single CPU. This architecture also gives ES users the ability to scale from a 2Gbps to 4Gbp to 10Gbps appliance simply by adding processor boards. A final note on redundancy is that most ES sensors have fail passthrough cards built-in (not optional) that can pass traffic even in the event of total device failure. The primary "con" is that it's a fairly new approach, and therefore it's difficult to get people on the bandwagon. Lastly, make sure you actually need an enterprise grade sensor. Nowadays, most lower-end sensors, NFR's lower end x86-based "Smart Sensors" included, have gigabit ports, even if they do not offer gigabit speed. Do not shell out the cash to go to the ES simply because you've got a fiber or 1000baseT network. Get some data on your actual bandwidth requirements and then talk to an SE about which product is actually necessary. -MAB -- (nfr)(security) Michael A Barkett, CISSP Vice President, Systems Engineering (www.nfr.com) +1.240.632.9000 Fax: +1.240.747.3512 -----Original Message----- From: David Williams [mailto:dwilliamsd@gmail.com] Sent: Monday, February 13, 2006 10:24 AM To: Andrew Plato Cc: geek_brigades@yahoo.com; focus-ids@securityfocus.com Subject: Re: IPS Reliability/Availability Actually, I'm seeing other vendors, SourceFire being one of the ones in the eval list below, who have not gone the ASIC route, but have gone with a kind of RISC architecture to get speed. Their pitch is that they get the performance of the ASIC vendors by using multiple RISC chips (I think the base model that does a gig inline has 6 RISC processors) to handle the load (plus an extra processor to handle the management end of things... so 7 all together). They are claiming performance of an ASIC but the flexibility of software. Not sure how valid that claim is. Question 1 : I'm wondering if anybody has tested these or stacked them up next to the ASIC brands to test perfomance, and if so, can they provide some feedback. Question 2: Does anybody have a list of which vendors are using ASICs for performance and which are using this RISC type architecture for performance? Question 3: Not so much a question, but a general request; I'd be interested in a "pro vs con" for each if anybody gets their hands on them. -d On 2/6/06, Andrew Plato <andrew.plato@anitian.com> wrote:Most of these devices are pretty good for reliability. The only exception I would make is SourceFire, which back when we sold it had abysmal reliability (3 out of 4 boxes we sold to a customer show up dead or died soon after installation). TippingPoint sells a zero-power bypass add-on for their IPS. If the IPS fails in anyway, traffic is passed through the zero-power device. Its very easy to add. Juniper does something similar. ----------------------------------------------- Andrew Plato, CISSP, CISM President/Principal Consultant Anitian Enterprise Security ----------------------------------------------- -----Original Message----- From: geek_brigades@yahoo.com [mailto:geek_brigades@yahoo.com] Sent: Thursday, February 02, 2006 8:27 AM To: focus-ids@securityfocus.com Subject: IPS Reliability/Availability I am working on a big IPS project and I am very concerned about installing an inline device in a core enterprise network, where these devices have the potential to create big time network outages. Can you, please, share your possible bad experiences about the reliability of the following inline IPS products: ISS TippingPoint Juniper IPS Sourcefire McAfee IntruShield Have you had any issues with the availability of these devices, such as fail close crashes or do you have any experience with bypass switches that would mitigate the availability issue? Thanks, Mike------------------------------------------------------------------------ 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. ------------------------------------------------------------------------ ------------------------------------------------------------------------ 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. ------------------------------------------------------------------------
------------------------------------------------------------------------ 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. ------------------------------------------------------------------------
| Previous by Date: | Re: Tracking back internal incidents to users, not IPs, Kevin |
|---|---|
| Next by Date: | Re: IPS Reliability/Availability, Bob Walder |
| Previous by Thread: | RE: IPS Reliability/Availability, Alan Shimel |
| Next by Thread: | Re: IPS Reliability/Availability, Martin Roesch |
| Indexes: | [Date] [Thread] [Top] [All Lists] |