Re: Passive Network Taps - on the cheap

Richard Bejtlich wrote:
You mention "ZERO network degradation" for your last two tables, but
it seems you are only looking at TX and RX errors between the parties
exchanging traffic. How do you measure the number of packets captured
by the sensor?

For example, study 3 lists workstation having 174739 "Total Packets"
(TX + RX), but the sensor has 112686 "Rx packets". Does this mean
174739-112686=62053 packets (35%) were not seen by the sensor?

The traffic is measured on the target host, and on the
bond0 interface of the sensor; therefore, the numbers for
bond0 should be all of the traffic that the target host
saw. In the initial tests, I ran timed dumps of netstat -i
on the host and sensor, plus I was capturing on the sensor
with tcpdump. After the test, an "eyeball" check of the
packet count was made against the capture file.

The study for the Linux host, was very close in packet
count with no errors; with the sensor actually having a
surplus of around 140 packets. I am sure that this is
the result of the difference in start times for the test,
with a few seconds lag between the machines.

I suspect that the Windows tests have far more packets
on the Windows box than the sensor due to the difference
in the way Linux and Windows look at the network. But,
I am rerunning the Windows box with an ethereal capture
going to be able to run accurate stats on the test.

I doubt that the first test really showed a 35% loss
of packets, but we should know shortly.

Also, in your first doc you say:
"Granted, you could very well use switch ports to aggregate the signal
from the PNT's tap jacks, or maybe even a hub (haven't tried). "

Connecting tap outputs to a hub makes a great collision factory, not a
way to combine tap outputs. [0]. [1]




OK.. caught me. Brain not engaged, fingers flailing.

For those who aren't aware, pg. 72 in Richard's
awesome book "The Tao of Network Security Monitoring"
explains exactly why we don't use hubs. :) I had
read that, knew that, but screwed up anyway.

Needless to say, I dropped the offending text from
my paper and made sure to reference the info that
Richard has on his blog regarding taps.

Thanks a bunch Mr. Bejtlich. Much appreciated.

Excellence in InfoSec and Linux

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 to learn more.

Relevant Pages

  • Malformed DNS or something odd (or just me)
    ... at my network borders. ... the packets contain exactly the same payload as those on udp ports ... the sensor is located in the DMZ of a network that offers no ... the ip of the NAT router is dynamically assigned, ...
  • Re: self authentication for sensors in ids ?
    ... that sensor hasn't been compromised he ... I meant a passphrase to activate a private gpg key. ... all packets coming from sensor. ...
  • Re: Update: UDP 770 Potential Worm
    ... > were no packets indicating some form of replication. ... > my capture was limited due to the switched ... to see if the problem occurs on the test network, ... The proxy had already been isolated from the ...
  • Re: W2K Firewall That Can Route Outbound Packets on Same Interface They Arrived On
    ... but under Windows 2000 Checkpoint ... packets return back on the same interface they arrived. ... arrives. ...
  • Re: Continuous internet activity
    ... IP address out of the exercise (dest address for the packets). ... starts the capture. ... Wireshark is not running, and then it is "safe" to transmit ... There is a small probability of a networking problem, ...