RE: IDS\IPS that can handle one Gig

• Previous message: Gary Halleen: "RE: IDS\IPS that can handle one Gig"
• Maybe in reply to: THolman_at_toplayer.com: "RE: IDS\IPS that can handle one Gig"
• Next in thread: THolman_at_toplayer.com: "RE: IDS\IPS that can handle one Gig"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Mon, 6 Jun 2005 13:58:20 -0500
To: "Ed Gibbs" <ed@digitalconclave.com>, "Chris Harrington" <charrington@nitrosecurity.com>, <THolman@toplayer.com>, <PPalmer@iss.net>, <prashant@juniper.net>, <focus-ids@securityfocus.com>

I believe Joel Snyder (Network World) has been working on something like
this so you may want to get in touch with him

-Chris

> -----Original Message-----
> From: Ed Gibbs [mailto:ed@digitalconclave.com]
> Sent: Monday, June 06, 2005 11:21 AM
> To: Chris Harrington; THolman@toplayer.com; PPalmer@iss.net;
> prashant@juniper.net; focus-ids@securityfocus.com
> Subject: Re: IDS\IPS that can handle one Gig
>
> You're absolutely right - there needs to be IPS test
> standards. I would like to propose putting together a forum,
> and defining what the IPS test standards should be - is
> anyone interested? I would like to see several members from
> each IPS vendor involved. The result is that we create a set
> of procedures that provide guidance, and help someone
> determine which IPS is best for their environment.
>
> Ed
>
>
>
>
> ----- Original Message -----
> From: "Chris Harrington" <charrington@nitrosecurity.com>
> To: <THolman@toplayer.com>; <PPalmer@iss.net>;
> <ed@digitalconclave.com>; <prashant@juniper.net>;
> <focus-ids@securityfocus.com>
> Sent: Saturday, June 04, 2005 11:43 PM
> Subject: RE: IDS\IPS that can handle one Gig
>
>
> > Let's have another vendor weigh in :) See my comments in line.
> >
> >
> >> -----Original Message-----
> >> From: THolman@toplayer.com [mailto:THolman@toplayer.com]
> >> Sent: Friday, June 03, 2005 8:25 AM
> >>
> >> 1) Gigabit performance is irrelevant; it's the packets per second
> >> that count. Vendors cheat and claim 1Gb performance based
> on large
> >> packet sizes (not real world), or just add up the sizes of
> all their
> >> interfaces.
> >
> > It would be nice if there was a standardized IPS
> performance test with
> > regards to packet size, traffic mix, etc. I don't see that
> happening
> > unless ICSA does it for the NIPS certification. This would
> cut down on
> > the shady performance numbers that Tim refers to.
> >
> >>
> >> 2) In PC architecture, the PCI bus is the bottleneck, not the
> >> processor.
> >
> > That depends on what you are doing with the processor. If you are
> > doing pattern matching in the CPU you could run out of CPU
> well before
> > you run out of bus capacity. A PCI bus has a theoretical
> limit of 1.05
> > Gbps. A 16 lane PCI-Express bus is 80 Gbps. Several vendors are
> > already shipping 10 Gig PCI-Express cards.
> >
> >>
> >> 3) An Intel processor has a large instruction set designed for
> >> workstation/server performance and GUI operations, and not
> for packet
> >> processing.
> >
> > I would say that the processor designers didn't have any specific
> > tasks in mind. It is a general purpose processor.
> >
> >>
> >> 4) An ASIC has a tiny instruction set in comparison,
> designed for a
> >> specific task. So, a 3.2Ghz Intel processor forwarding/processing
> >> network traffic is on a par with a 133Mhz ASIC designed to do the
> >> same thing.
> >
> > I'm not an ASIC guy so I will take your word for it on the
> comparison
> > :)
> >
> >>
> >> 5) Processors can only do one thing at once. Thus, a networking
> >> device with several processors installed in parallel
> (ASICs OR Intel)
> >> is far more effective than a box with a single/dual processor.
> >
> > More processors gives you more flexibility in what gets
> processed where.
> >
> >>
> >> 6) Hard disks do not slow down performance. They lower
> reliability
> >> as fail all the time (!). RAID would help, but I don't think any
> >> security vendor offers a RAID array as an integral part of their
> >> appliance, so cut to the chase, get the HDD off the inline
> unit and
> >> place on a separate management machine so we have a reliable
> >> distributed architecture that isn't put at risk by HDD
> failure. On
> >> the same note, dual fans and power supplies also need to be
> >> considered.
> >
> > Hard drives do fail, no question there. I definitely disagree with
> > your statement about vendors not having RAID. There are definitely
> > vendors (other than us) who have drives in RAID
> configuration, both 1
> > and 5. I am not sure taking the drive off the device makes
> for a more
> > reliable distributed architecture. What if the link from the IPS to
> > the Management machine goes down or the Syslog server dies? What if
> > the hard drive in the Management machine fails? :) With no
> drive on
> > the IPS your space to store events, system data, etc, is somewhat
> > limited. How long before you have to start overwriting
> event data on
> > the IPS?
> >
> > Same goes for dual fans and power supplies. There are
> vendors (again
> > other than us) who have dual fans and hot swappable power supplies.
> > Although these are generally found in the 500 mbps and up ranges.
> >
> > Don't forget fail open NIC's and bypass devices. Most vendors
> > (including ASIC IPS') have them, at least as an option. If
> not having
> > a hard drive is the path to reliability then why do vendors without
> > hard drives have fail open NIC's? Because other components
> can and do fail as well.
> >
> >>
> >> 7) Single-processor machines can easily FORWARD 64-byte
> packets at
> >> 'multi-Gig' speeds. They can do this as the processor
> doesn't have
> >> to do anything with them. As soon as you add intensive
> operations to
> >> the packets in question, bearing in mind there is only a
> single CPU
> >> that can only do one thing at once, you introduce LATENCY
> plus reduce
> >> pps performance DRASTICALLY. This is where a parallel processing
> >> architecture comes into it's own and takes leaps forward
> over what a
> >> single-CPU box can do.
> >
> > You are assuming that the CPU is doing the packet processing. Many
> > vendors are using network content accelerators and other processing
> > cards to offload the CPU intensive operations.
> >
> >>
> >> In conclusion:
> >>
> >> A box with one or two ASICs in is easily outperformed by a PC with
> >> the latest Intel processor, fast network cards and a good chunk of
> >> memory.
> >> However, the PC is more prone to hard disk failure, which
> is why you
> >> should never put one inline if uptime is critical.
> >>
> >> A box with several ASICs in will outperform ANY PC-based solution,
> >> and ANY ASIC solution that relies only on one or two processors.
> >
> > But at what cost in terms of price per Gigabit and
> flexibility? Adding
> > new functionality to software is pretty easy....
> >
> >>
> >> ..and one comment to Ed with respect to McAfee/TippingPoint
> >>
> >> >both products really don't care if you have every
> signature and then
> >> >some on.
> >>
> >> Yes they do. If you turn on every signature check with
> these IPS's,
> >> pps performance slows to a mediocre dribble...
> >
> > They do care. Look at some of the product reviews and you will see
> > that vendor X has 2000 rules / filters / signatures but
> only 500 are
> > on by default. I've witnessed a couple of ASIC IPS' that
> were brought
> > to their knees when asked to store the offending packets.
> What about
> > storing the TCP stream involved with an event? Customers are asking
> > about this...
> >
> >>
> >> Inline devices should NOT rely on REGEX signatures - by nature,
> >> string searching is very resource intensive and best left
> to a nice
> >> fast offline IDS running on an up-to-date PC platform,
> where latency
> >> is not going to be an issue...
> >
> > There are PC platform IPS on the market that are under 100
> > microseconds that do pattern matching.
> >
> >>
> >> Hope this helps - this isn't an all out war ASIC-based vs
> PC-based,
> >> it's a question of architecture and suitability for the
> job in hand!
> >>
> >
> > Definitely an interesting thread. I agree that it is about
> suitability.
> >
> > --Chris
> >
> > Christopher Harrington, CISSP
> > Chief Technology Officer
> > nitrosecurity
> > o: 603.570.3931
> > c: 603.969.0592
> > e: charrington@nitrosecurity.com
> > w: www.nitrosecurity.com
> > Skype: chrisharrington
> >
> >
> >
> >
>
>
> --------------------------------------------------------------
> ------------
> 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.
> --------------------------------------------------------------
> ------------
>
>
>

Morgan Keegan & Co., Inc. DOES NOT ACCEPT ORDERS AND/OR INSTRUCTIONS REGARDING YOUR ACCOUNT BY
 E-MAIL. Transactional details do not supersede normal trade confirmations or statements. The information contained
 in this transmission is privileged and confidential. It is intended for the use of the individual or entity named above. The
 information contained herein is based on sources we believe reliable but is not considered all-inclusive. Opinions are
 our current opinions only and are subject to change without notice. Offerings are subject to prior sale and/or change
 in price. Prices, quotes, rates and yields are subject to change without notice. Morgan Keegan & Co., Inc., member
 NYSE, NASD and SIPC, is a registered broker-dealer subsidiary of Regions Financial Corporation. Investments are
 NOT FDIC INSURED, NOT BANK GUARANTEED and MAY LOSE VALUE. Morgan Keegan & Co., Inc. reserves the right to
 monitor all electronic correspondence.

http://www.morgankeegan.com

--------------------------------------------------------------------------
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 message: Gary Halleen: "RE: IDS\IPS that can handle one Gig"
• Maybe in reply to: THolman_at_toplayer.com: "RE: IDS\IPS that can handle one Gig"
• Next in thread: THolman_at_toplayer.com: "RE: IDS\IPS that can handle one Gig"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]