(sorry Dave, should have been more specific - text-mode hex editor for *nix =))
(→ok, but is it useful?)
|Line 43:||Line 43:|
0 packets dropped by kernel
0 packets dropped by kernel
And hex editing the raw tcp dump (I cheated and used UltraEdit on my windows box; I don't have a good text-mode hex editor for *nix yet. Anyone got any recommendations?) and searching for PASS led me to this snippet:
And hex editing the raw tcp dump (I cheated and used UltraEdit on my windows box; I don't have a good text-mode hex editor for *nix yet. Anyone got any recommendations? ) and searching for PASS led me to this snippet:
Revision as of 00:05, 6 April 2005
tcpdump is an extremely handy little utility that will "sniff" traffic on a particular network interface, match it against a set of criteria, and then output a summary of it to screen (or a dump of it to a file).
-c number "sniff this many packets". By default, tcpdump will sniff until you tell it not to. Using this flag will cause it to stop at a certain number of packets instead of waiting for an interruption (like cntrl-C...or running out of diskspace, if you're writing to a file). -i interface"listen on this interface". If you want traffic from just one network interface, you want to use this option. -a "convert IPs to names if you can" -w filename "write this to a file". you must give a filename to write to. -q "don't be so verbose" -- strips more protocol information -p "do not put interface in promiscuous mode". By default, tcpdump will make your interface promiscuous.
Note that if the src (source) or dst (destination) flags are not used to qualify the ip/port/net numbers specified, tcpdump assumes either source or destination:
src port number "from this port" dst port number "to this port" port number "to or from this port" src ip address "from this IP" dst ip address "to this IP" ip address "to or from this IP" src net number "from this network" dst net number "to this network" net number "to or from this network"
tcpdump understands boolean operators (and not or, etc) and can take hostnames, IPs, networks and protocols as arguments. The output is terse and hard to understand if you don't know what you're looking at or for; for this reason many folks prefer friendlier front-ends to tcp, such as ethereal.
ok, but is it useful?
Just tonight, I discovered that while I had login information for an FTP site I hadn't touched in years saved in my Windows FTP client, I didn't remember what that password WAS, and I needed it to give to somebody else. I looked in the data store for the FTP client, but unfortunately the passwords were stored as hashes. Rather than try to figure out the encryption algorithm used and then find a brute force cracker somewhere, I just shelled into my firewall and set up a tcpdump session to capture the packets:
ph34r# tcpdump -pw /home/jimbo/ftpsniff.tcpdump.bin -i xl0 dst port 21 tcpdump: listening on xl0
Now my firewall is monitoring all traffic through its inside interface, and dumping any packets headed out to an FTP server to the file /home/jimbo/ftpsniff.tcpdump.bin. So I fire up my Windows FTP client, connect to the FTP site and let it authenticate, and then immediately hit CTRL-C in ph34r to interrupt the tcpdump session:
ph34r# tcpdump -pw /home/jimbo/ftpsniff.tcpdump.bin -i xl0 dst port 21 tcpdump: listening on xl0 ^C 38 packets received by filter 0 packets dropped by kernel
And hex editing the raw tcp dump (I cheated and used UltraEdit on my windows box; I don't have a good text-mode hex editor for *nix yet. Anyone got any recommendations? see the discussion page...) and searching for PASS led me to this snippet:
Ta-da! Now I know the password for that FTP site. (Obviously you could use the same technique to find out OTHER people's passwords, if you ran the firewall they used to get out to the 'net... starting to see why the crypto geeks keep yelling about using secure authentication instead of plaintext?)