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_at_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_at_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_at_nfr.com]
> Sent: Thursday, February 16, 2006 3:40 PM
> To: 'David Williams'; 'Andrew Plato'
> Cc: geek_brigades_at_yahoo.com; focus-ids_at_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_at_gmail.com]
> Sent: Monday, February 13, 2006 10:24 AM
> To: Andrew Plato
> Cc: geek_brigades_at_yahoo.com; focus-ids_at_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_at_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_at_yahoo.com [mailto:geek_brigades_at_yahoo.com]
>> Sent: Thursday, February 02, 2006 8:27 AM
>> To: focus-ids_at_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.
------------------------------------------------------------------------
Received on Feb 22 2006
Intro
