I started out to build a little diagram of a TCP/IP packet in hex with each header a different color so that my ADD brain could decipher quickly and easily what fields are what protocols. Then at this site I found what I was looking for:
4510 0068 7e87 4000 4006 3862 c0a8 011e
c0a8 0128 0016 0479 b6c8 a8de 621e 87db
5018 4470 1813 0000 e492 152f 23c3 8a2b
4ee7 dbf8 0d48 88e8 0110 2b01 4295 39f4
52c9 a05b 31d7 e3ae 1c62 2dbd d955 d604
b5d2 63d1 8fbc 4ab7 1615 b382 571c 70e0
a368 a03f 425b 6211
I changed the colors to work with a white background, but here in red you see the IP header (20 bytes), and in cyan you see the TCP header (another 20 bytes).
Each 4 hex numbers is 2 bytes. Then just remember that they start counting at zero for the "offset," or rather how far from the first bit/byte each field is found.
The first option we take is the "-i" which instructs tcpdump which interface to listen on. This is useful if you have multiple NICs or perhaps if you are using VMWare to run your lab. I did notice that traffic coming out of the VM will be captured by the host on lo, but not on eth0. Packets from host to VM can be captured on eth0, however. I'm assuming that is because the network card is actually bridged through the physical interface, so traffic coming from the VM never touches the wire. That's good to know, actually, as I prepare to take this into the real world.
Next I use "-x" which dumps the packet in hex. Hex is a bugger for me, personally, to work with, but it really gives you a good feel for what fields are where in the frame. I find that, as I do this more I pick up a field here and there, starting with the first byte of an IP header, which indicates protocol type. A "4" indicates that this is IPv4 (so, if it were IPv6 it would ovbviously be a 6) and the second byte (at bit offset 4) is a 5, indicating that the IP header is in 32-bit words (4 bytes == one 32-bit "word", 5*4=20 bytes)
Other important options are "-X" which gives you the ASCII output as well and "-s" which allows you to determine how much of the packet you want to capture. (-s is for "snaplen, or snapshot length). Using -s0 means "capture the whole packet." Remember that one when you are ready to mount your attack on the local FTP server...
I have been using tcpdump for many years now, and for some reason I have never noted the "host" or "and()" parameters. Using these you can specify a hostname or IP address to filter your capture on (handy if you are trying to watch an attack). Syntax would be:
tcpdump -i eth0 'host 192.168.1.1 and (192.168.1.5 or 4.2.2.2)'
This allows you to capture any traffic between host 1 (192.168.1.1) and either host 2 (192.168.1.5) or host 3(4.2.2.2). Using these parameters you can really fine-tune your capture, and I now use this quite a lot. It shuts down much of the noise a normal LAN has these days. Oh, you can also use "and not" to keep traffic from any given host from being captured. Nice when you work remotely like I do often and don't want to capture all the VNC traffic between your workstation and the remote host.
There you have it, folks. Tcpdump. There are a boatload of great tutorials out there, and quite honestly I'd rather use Wireshark. But sometimes for a quick 'n' dirty capture it's nice to run a quick tcpdumpa nd see who's communicating with whom. Not to mention you get to feel like you're in the Matrix as you watch all that hex fly by...
No comments:
Post a Comment