pavement

Tcpdump

From FreeBSDwiki
(Difference between revisions)
Jump to: navigation, search
(common options)
 
(6 intermediate revisions by 3 users not shown)
Line 3: Line 3:
 
==Common arguments==
 
==Common arguments==
  
  -c ''number'' "sniff this many packets". By default, tcpdump will sniff until you tell it not to.  
+
  -c ''number'' "sniff this many packets". By default, tcpdump will sniff until  
    Using this flag will cause it to stop at a certain number of packets instead of waiting for an
+
    you tell it not to. Using this flag will cause it to stop at a certain number
    interruption (like cntrl-C...or running out of diskspace, if you're writing to a file).
+
    of packets instead of waiting for an interruption (like cntrl-C...or running  
  -i ''interface''"listen on this interface". If you want traffic from just one network interface, you want to use this option.
+
    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"
 
  -a "convert IPs to names if you can"
 
  -w ''filename'' "write this to a file". you must give a filename to write to.
 
  -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
 
  -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.
+
  -p "do not put interface in promiscuous mode". By default, tcpdump will make your
Note that if not src (source) or dst (destination) port/ip/net is specified, tcpdump assumes ''either'' source or destination:
+
    interface promiscuous.
 +
-A ASCII capture - display the contents of packets as ASCII.
 +
-s0 "snap length 0" - you need this to capture full lines of text, if you are using the -A flag.
 +
 
 +
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"
 
  src port ''number'' "from this port"
 
  dst port ''number'' "to this port"
 
  dst port ''number'' "to this port"
  src ip ''number'' "from this IP"
+
    port ''number'' "to or from this port"
  dst ip ''number'' "to this IP"
+
 +
  src host ''address'' "from this IP"
 +
  dst host ''address'' "to this IP"
 +
    host ''address'' "to or from this IP"
 +
 
  src net ''number'' "from this network"
 
  src net ''number'' "from this network"
 
  dst net ''number'' "to this network"
 
  dst net ''number'' "to 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.
+
    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?==
 
==ok, but is it useful?==
Line 24: Line 35:
 
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:
 
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'''
+
  ph34r# '''tcpdump -pA -s0 -w /home/jimbo/ftpsniff.tcpdump.bin -i xl0 dst port 21'''
 
  tcpdump: listening on xl0
 
  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:
 
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'''
+
  ph34r# '''tcpdump -pA -s0 -w /home/jimbo/ftpsniff.tcpdump.bin -i xl0 dst port 21'''
 
  tcpdump: listening on xl0
 
  tcpdump: listening on xl0
 
  ^C
 
  ^C
Line 35: Line 46:
 
  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 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? see the discussion page...) and searching for PASS led me to this snippet:
  
 
  PASS V9xo3Pr1
 
  PASS V9xo3Pr1

Latest revision as of 21:45, 6 January 2009

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).

[edit] Common arguments

-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.
-A ASCII capture - display the contents of packets as ASCII.
-s0 "snap length 0" - you need this to capture full lines of text, if you are using the -A flag.

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 host address "from this IP"
dst host address "to this IP"
    host 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.

[edit] 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 -pA -s0 -w /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 -pA -s0 -w /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:

PASS V9xo3Pr1

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?)

Personal tools