Subject: Re: Gigabit IDS solutions
From: Igor Gashinsky (igor
HOTJOBS.COM)
Date: Wed Nov 15 2000 - 00:27:46 CST
From what I have seen/been recommended, Intel EEPro 100's seem to be the
best NIC when it comes to running IDS's on. I has been repatedly
recommended for use with Snort, Dragon, and NFR (and we all know how picky
those guys are.. 3 supported cards!!).
---
Igor Gashinsky, CISSP
Sr. Network Engineer
HotJobs.com, Ltd.
On Tue, 14 Nov 2000, Jacob Martinson wrote:
:: Anyone have a rec on which nic manufacturers/models/drivers(bsd and linux)
:: drop the least under heavy load?
::
:: -----Original Message-----
:: From: Dragos Ruiu [mailto:drKYX.NET]
:: Sent: Tuesday, November 14, 2000 3:22 PM
:: To: FOCUS-IDSSECURITYFOCUS.COM
:: Subject: Re: Gigabit IDS solutions
::
::
:: On Tue, 14 Nov 2000, Patrick Mueller wrote:
:: > On Tue, 14 Nov 2000, Elliot Turner wrote:
:: >
:: > > We measure capture rate by running our product in a debug mode, which
:: allows
:: > > packets/per/sec and bytes/per/sec
:: > > statistics to be printed. We cross-reference these statistics to output
:: > > from commercial sniffers/packet analyzers,
:: > > also taking into consideration the TurboPacket drop statistics and the
:: > > actual Ethernet device drop statistics.
:: >
:: > Elliot, can you tell me what sniffers/packet analyzers you use to confirm
:: > your numbers. I'm dealing with a problem where we can't get the various
:: > components in our test to agree on how many packets they are seeing over a
:: > fixed time. Any experience w/ iptraf? Thanks.
::
:: IMHO.... the best numbers to use on Linux (as implied by the above) are the
:: numbers you get from ifconfig (via ioctls to the driver).... these are
:: derived
:: from counters on the NIC registers itself on most drivers or at least low
:: level
:: DMA counts (on 100Mbps hw, haven't looked at much GigE) and will obviate
:: any software related packet loss issues.
::
:: I remember looking at iptraf about two years and two versions ago and being
:: puzzled by both discrepancies in packet size statistics and packet counts
:: between it and other tools. Though I never really tracked down the full
:: cause
:: as I was chasing a number of other problems and esoteric attacks at the
:: time,
:: my conclusion was that the place for stats such as this is in the NIC
:: drivers or
:: very early in the OS stack and wound up rigging up a few kludges to help me
:: get past any ambiguity conclusively...
::
:: One situation to be aware of is that some stacks don't count ARP packets in
:: their packet stats. And I would guess that collisions, runts and other L2
:: effects could give room for discrepancies in statistics implementations
:: even at the chipset level... I consider the NIC packet counter registers to
:: be
:: the most authoritative in this area, but I haven't researched differences
:: between various NIC vendors and chipsets as to counting methodology. Same
:: goes for sniffers - but they are usually only as accurate as the NIC chipset
:: being used anyway. (at best, and even then some commercial ones are
:: considerably worse than this... :-)
::
:: cheers,
:: --dr
::
