3. Operation
3.1. How do I sniff in a switched environment?
The easiest route is simply to impersonate the local gateway, stealing client traffic en route to some remote destination. Of course, the traffic must be forwarded by your attacking machine, either by enabling kernel IP forwarding (sysctl -w net.inet.ip.forwarding=1 on BSD) or with a userland program that acccomplishes the same (fragrouter -B1).
Several people have reportedly destroyed connectivity on their LAN to the outside world by arpspoof'ing the gateway, and forgetting to enable IP forwarding on the attacking machine. Don't do this. You have been warned.
3.2. arpspoof always fails with "couldn't arp for host"?
You can only arpspoof hosts on the same subnet as your attacking machine.
3.3. Why isn't dsniff / *snarf seeing anything?
3.3.1. ...when using arpspoof to intercept client traffic?
Make sure you are actually forwarding the intercepted packets, either via kernel IP forwarding or with fragrouter.
If you are indeed seeing the client's half of the TCP connection (e.g. as verified using tcpdump), make sure you've enable dsniff's half-duplex TCP stream reassembly (dsniff -c). The *snarf tools do not yet support this mode of operation.
3.3.2. ...when I can see ongoing connections with tcpdump?
libnids, dsniff's underlying TCP/IP reassembling library, needs to see the start of a connection in order to follow it. There are several good reasons for this, as outlined in Ptacek and Newsham's seminal paper on network IDS evasion.
The best you can do, in a live penetration testing scenario, is to
1. start sniffing
2. selectively reset existing connections with tcpkill, and then
3. wait for the users to reconnect
This is horribly intrusive and evil, but then again, so are pen tests.
3.3.3. ...when sniffing a busy network, or a switch's monitor port?
You may be losing some packets, either at the switch's monitor port (mirroring ten 100 Mbit Ethernet ports to a single port is never a good idea) or within libpcap - anathema to libnids, which needs to see all packets in a connection for strict reassembly. Try enabling dsniff's best-effort half-duplex TCP stream reassembly (dsniff -c) instead.
Other general performance enhancements for sniffing include:
1. SMP, which on most OSs results in only one processor handling the high interrupt load, leaving the other to do real work
2. good NICs and drivers with working DMA
3. large kernel buffers for efficient packet capture (OpenBSD's BPF already does this)
4. custom kernel support for single-copy packet capture (e.g. direct access to such buffers in kmem from userland)
3.3.4. ...when sniffing traffic on an unusual port?
Try enabling dsniff's magic (dsniff -m) automatic protocol detection, which should detect the appropriate protocol (if dsniff knows about it) running on any arbitrary port. If dsniff still fails to pick up the traffic, it may be an unusual protocol dsniff doesn't yet support. Create a dsniff services file like
hex 12345/tcp
where 12345 is the TCP port of the unknown service, run dsniff with -f services and send the resulting hexdump of the connection trace to me. Some proprietary protocols transmogrify almost daily, it's not easy keeping up!
3.3.5. ...when sniffing unknown traffic, or a new version of some protocol?
dsniff's decode routines are admittedly pretty sleazy, and cut many corners for the sake of performance (and simplicity - you try fully decomposing all 30+ open / proprietary protocols that dsniff handles!). Additionally, many of the protocols dsniff handles are completely proprietary, and required a bit of reverse engineering which may not have been all that complete or accurate in the face of new protocol versions or extensions.
The best way to get new protocols handled by dsniff is to send me traffic traces of a few complete connections / sessions, from start to finish (making sure to capture the packets in their entirety with tcpdump -s 4096, or with Ethereal), along with any pointers to relevant documentation (or client/server implementations).
If you'd like to give it a try yourself, add an entry to dsniff's dsniff.services file to map the traffic you wish to analyze to the "hex" decode routine, and dissect the hexdumps manually.
![[HaBo]](/styles/default/logoklein.png){kind=small}
