lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <200606181309.k5ID9g7C032666@turing-police.cc.vt.edu>
Date: Sun Jun 18 14:09:55 2006
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks@...edu)
Subject: Sniffing on 1GBps

On Sun, 18 Jun 2006 17:58:32 +0530, crazy frog crazy frog said:
> I m just wondering if it is possible to capture the data from a
> highspeed NIC card?if it is possible then wht kind of precaution we
> have to take so that we does not miss the data?

What you need:

1) A NIC that can *sustain* 1GBps (did you mean 1Gbps?  GB is giga-BYTES,
Gb is giga-BITS.  1Gbps is getting to be pretty standard).  The two end
cases you want to test are (a) back-to-back jumbograms, and (b) back-to-
back *minimum* sized packets.  Often, the second will make the card fall over
even though the actual data transfer is far lower, due to the increased
interrupt rate. Non-buggy device drivers help a lot here, as does the
ability to buffer multiple packets per interrupt.

2) Is full packet capture required, or just the IP/TCP/UDP headers?  It
makes a big difference for data storage requirements.  Similarly, if
you can limit the traffic captured (a given hostname, a port, anything
else that makes sense as a tcpdump or iptables filter, tec), it makes the
job easier.

3) A disk subsystem that can *sustain* 125 MB/sec write rates (you'll
probably need to stripe across several disks.  Also, you'll need to
think *really* hard if you need continuous full storage - even an hour
of 125 MB/sec gets pretty honking huge....

4) If you're trying to catch off the wire at 125MB/sec, and throw it *all*
to a disk, you'll be wanting to look at high-end PCI.  Quite possibly a
dual-backplane system, and watch out for memory contention issues...

5) You'll need something to *process* the data as well - which gets *really*
interesting if you're trying to do it real-time.

Having said that, 1Gbps capture isn't particularly technically challenging.
There's people out there that are looking at the 10Gbps and 40Gbps markets
(these usually involve some custom silicon to do filtering so you don't
try to capture the *entire* data capacity - think "Snort rules in hardware").
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20060618/02320468/attachment.bin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ