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" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] > 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:[EMAIL PROTECTED] > Sent: Thursday, February 16, 2006 3:40 PM > To: 'David Williams'; 'Andrew Plato' > Cc: [EMAIL PROTECTED]; [email protected] > 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:[EMAIL PROTECTED] > Sent: Monday, February 13, 2006 10:24 AM > To: Andrew Plato > Cc: [EMAIL PROTECTED]; [email protected] > 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >> Sent: Thursday, February 02, 2006 8:27 AM >> To: [email protected] >> 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. ------------------------------------------------------------------------
