https://www.tcpdump.org/
https://www.tcpdump.org/manpages/tcpdump.1.html
https://jvns.ca/tcpdump-zine-print.pdf
tcpdump是一個功能強大的命令行數據包分析器; 和 libpcap,一個用於網絡流量捕獲的可移植C / C ++庫。tcpdump – 在網絡上轉儲流量。是一個抓包工具,一種嗅探器(sniffer)。
man描述
Tcpdump在網絡接口上打印出與布爾表達式匹配的數據包內容的描述; 描述以前是一個時間戳,默認狀況下打印爲小時,分鐘,秒和午夜以來的分數。
它也可使用-w 標誌運行 ,這會致使它將數據包數據保存到文件中以供之後分析,和/或使用 -r 標誌,這會使它從保存的數據包文件中讀取而不是讀取數據包來自網絡界面。
它也可使用-V 標誌運行 ,這會使它讀取已保存的數據包文件列表。在全部狀況下,只有匹配表達式的數據包 纔會被tcpdump處理 。
若是沒有使用-c 標誌運行,Tcpdump將 繼續捕獲數據包,直到被SIGINT信號(例如,經過鍵入中斷字符,一般是control-C)或SIGTERM信號(一般使用kill產生)生成 (1)命令); 若是使用-c 標誌運行 ,它將捕獲數據包,直到被SIGINT或SIGTERM信號中斷或已處理指定數量的數據包。
當 tcpdump 完成捕獲數據包時,它將報告如下計數:html
在支持SIGINFO信號的平臺上,例如大多數BSD(包括macOS)和Digital / Tru64 UNIX,它會在收到SIGINFO信號時報告這些計數(例如,經過鍵入「狀態」字符生成,一般control-T,雖然在某些平臺上,例如macOS,默認狀況下不設置``status''字符,因此你必須用stty(1)設置 才能使用它,並繼續捕獲數據包。在不支持SIGINFO信號的平臺上,使用SIGUSR1信號能夠實現相同的功能。
使用SIGUSR2信號和 -w 標誌會強制將數據包緩衝區刷新到輸出文件中。
從網絡接口讀取數據包可能要求您具備特殊權限; 有關詳細信息,請參見 pcap(3PCAP)手冊頁。經過將網卡適配器(NIC)置於混雜模式(promiscuous)來獲取傳輸在網絡中的信息包。須要root權限將網卡變動爲「混雜模式」,切換到root或者用sudo。讀取已保存的數據包文件不須要特殊權限。node
https://www.tcpdump.org/manpages/tcpdump.1.html
Index:
NAME名稱; SYNOPSIS概要; DESCRIPTION描述; OPTIONS選項; EXAMPLES 例子;
OUTPUT FORMAT輸出格式; SEE ALSO跟多信息; AUTHORS做者; BUGS異常反饋;
上面是英文原文的目錄連接,能夠直接轉到英文原文的對應章節。
tcpdump version 4.9.2
libpcap version 1.9.0-PRE-GIT (with TPACKET_V3)
OpenSSL 1.1.1c 28 May 2019
經常使用選項: 紅色:抓包選項;藍色:輸出選項;紫色:其餘經常使用功能選項
-a 》嘗試將網絡和廣播地址轉換成名稱。
-A 只會顯示ASCII形式的數據包內容,不會再以十六進制形式顯示
-b 以ASDOT表示法而不是ASPLAIN表示法打印BGP數據包中的AS編號。
-d 將編譯後的數據包匹配代碼以人類可讀的形式轉儲到標準輸出並中止。
-dd 將數據包匹配代碼轉儲爲 C 程序片斷。
-ddd 將數據包匹配代碼轉儲爲十進制數字(以計數開頭)。
-D --list-interfaces 列出系統上可用的網絡接口列表以及 tcpdump 能夠捕獲數據包的列表。
-e 打印連接級標題。例如,可打印諸如以太網和IEEE 802.11之類協議的MAC層地址。
-f 用數字顯示網際網絡地址。
-h --help 打印tcpdump和libpcap版本字符串,打印用法消息,而後退出。
--version 打印tcpdump和libpcap版本字符串並退出。
-H 嘗試檢測802.11s草圖網格標頭。ios
-I --monitor-mode將界面置於(監控模式); 這僅在IEEE 802.11 Wi-Fi接口上受支持,及某些OS上受支持。
git
請注意,在監視器模式下,適配器可能與與其關聯的網絡取消關聯,所以您將沒法使用具備該適配器的任何無線網絡。若是您在監視器模式下捕獲而且未使用其餘適配器鏈接到另外一個網絡,則可能會阻止訪問網絡服務器上的文件或解析主機名或網絡地址。該標誌將影響-L 標誌的輸出 。若是 未指定-I,則僅顯示未處於監控模式時可用的鏈路層類型; 若是 指定-I,則僅顯示處於監視模式時可用的連接層類型。
--immediate-mode
以「當即模式」捕獲。在此模式下,數據包一到達就會傳送到tcpdump,而不是爲了提升效率而進行緩衝。這是打印數據包時的默認設置,而不是在將數據包打印到終端而不是文件或管道時將數據包保存到「savefile」。算法
-J --list-time-stamp-types 列出接口支持的時間戳類型並退出。若是沒法爲接口設置時間戳類型,則不會列出時間戳類型。shell
--time-stamp-precision = tstamp_precision
捕獲時,將捕獲的時間戳精度設置爲 tstamp_precision。請注意,高精度時間戳(納秒)的可用性及其實際精度取決於平臺和硬件。還要注意,當以納秒級精度將捕獲寫入保存文件時,時間戳以納秒分辨率寫入,而且文件使用不一樣的幻數編寫,以指示時間戳以秒和納秒爲單位; 並不是全部讀取pcap savefiles的程序都能讀取這些捕獲。
讀取保存文件時,將時間戳轉換爲timestamp_precision指定的精度,並以該分辨率顯示它們。若是指定的精度小於文件中時間戳的精度,則轉換將失去精度。
爲支持的值timestamp_precision是微爲微秒分辨率和納米爲十億分之一秒分辨率。默認值爲微秒分辨率。
--micro
--nano
速記爲--time時間戳精度=微或 --time戳精度=納米,相應地調節時間戳精度。從保存文件讀取數據包時,若是使用納秒精度建立保存文件,則使用 --micro截斷時間戳。與此相反,具備微秒精度建立的SAVEFILE將具備當後添加的時間標記的零 --nano被使用。express
-K --dont-verify-checksums 請勿嘗試驗證IP,TCP或UDP校驗和。這對於在硬件中執行部分或所有校驗和計算的接口很是有用; 不然,全部傳出的TCP校驗和都將被標記爲錯誤。安全
-l 使用標準輸出列的緩衝區。在捕獲數據時查看數據,很是有用。例如,
服務器
tcpdump -l | tee dat
or
tcpdump -l > dat & tail -f dat
請注意,在Windows上,「line buffered」表示「無緩衝」,所以若是 指定了-l,WinDump將單獨寫入每一個字符 。
-U 在其行爲上 相似於 -l,但它會致使輸出爲「數據包緩衝」,所以輸出在每一個數據包的末尾而不是在每行的末尾寫入stdout; 這是在全部平臺上緩衝的,包括Windows。網絡
-L --list-數據鏈路類型
在指定模式下列出接口的已知數據連接類型,而後退出。已知數據連接類型列表可能取決於指定的模式; 例如,在某些平臺上,Wi-Fi接口可能在不處於監控模式時支持一組數據鏈路類型(例如,它可能僅支持僞以太網報頭,或者可能支持802.11報頭但不支持帶有無線電信息的802.11報頭)和處於監控模式時的另外一組數據鏈路類型(例如,它可能支持802.11標頭,或僅具備無線電信息的802.11標頭,僅在監控模式下)。
-n 數字顯示, -n顯示ip地址(不解析爲主機名);-nn地址+端口號碼(端口不解析爲服務名稱)。
-N 不打印host的域名部分
-O --no-optimize,不要運行數據包匹配代碼優化器。僅當您懷疑優化器中存在錯誤時,此選項纔有用。
-p --no-promiscuous-mode 不要將接口置於混雜模式。
請注意,因爲某些其餘緣由,界面可能處於混雜模式; 所以,`-p'不能用做`ether host {local-hw-addr}或ether broadcast'的縮寫。
--print, 即便將原始數據包保存到帶有-w 標誌的文件,也會打印已分析的數據包輸出 。
-q 快速簡短打印
-S --absolute-tcp-sequence-numbers打印絕對而非相對的TCP序列號。
-t 輸出時不打印時間戳
-tt 顯示未經格式化的時間戳記。即自1970年1月1日00:00:00,UTC以及自該時間以來的每秒分數
-ttt 在每一個轉儲行上的當前行和上一行之間 打印增量 (微秒或納秒分辨率,具體取決於 --time-stamp-precision選項)。默認值爲微秒分辨率。
-tttt 在每一個轉儲行上打印一個時間戳,以小時,分鐘,秒和從午夜開始的一小時一秒爲止。
-ttttt 在每一個轉儲線上的當前行和第一行之間 打印增量 (微秒或納秒分辨率,具體取決於 --time-stamp-precision選項)。默認值爲微秒分辨率。
-u 打印未解碼的NFS句柄。
-U --packet-buffered
若是 未指定-w選項,或者若是指定了 -w選項可是 也指定了 --print標誌,則使打印的數據包輸出``packet-buffered''; 即,當打印每一個數據包的內容的描述時,它將被寫入標準輸出,而不是在不寫入終端時,僅在輸出緩衝器填滿時寫入。
若是 指定了 -w選項,則使保存的原始數據包輸出``packet-buffered''; 即,在保存每一個數據包時,它將被寫入輸出文件,而不是僅在輸出緩衝區填滿時才寫入。
該 -U 若是標誌將不被支持 的tcpdump 與舊版本的內置 的libpcap 是缺少 pcap_dump_flush(3PCAP) 功能。
-v 輸出更詳細的信息,tos值、ttl值、ID值、總長度、校驗值等。-vv, -vvv.
-x 用十六進制字碼列出數據包資料。
解析和打印時,除了打印每一個數據包的標頭外,還要以十六進制格式打印每一個數據包的數據(減去其連接級別標題)。 將打印整個數據包或snaplen字節中較小的一個 。請注意,這是整個鏈路層數據包,所以對於填充(例如以太網)的鏈路層,當較高層數據包短於所需填充時,也將打印填充字節。
-xx 除了打印每一個數據包的標頭外,還要打印每一個數據包的數據, 包括 其連接級別標題,以十六進制表示。
-X 除了打印每一個數據包的標題外,還要以16進制和ASCII格式打印每一個數據包的數據(減去其連接級別標題)。這對於分析新協議很是方便。
-XX 除了打印每一個數據包的標頭外,還要以 16進制和ASCII格式打印每一個數據包的數據, 包括其連接級別標題。
-# --number, 在行的開頭打印一個可選的包號。
[ -B size ] --buffer-size = buffer_size 將OS捕獲緩衝區大小設置爲buffer_size,以KiB(1024字節)爲單位。
[ -c count ] 數量,收到計數包後退出
[ -C file_size ] 檢查文件大小
在將原始數據包寫入保存文件以前,請檢查該文件當前是否大於file_size,若是是,請關閉當前保存文件並打開一個新文件。第一個savefile以後的savefiles將使用-w 標誌指定名稱 ,後面帶一個數字,從1開始並繼續向上。file_size的單位是數百萬字節(1,000,000字節,而不是1,048,576字節)。
[ -E algo:secret ] 解密數據包。
使用spi@ipaddr algo:secret來解密發送到addr幷包含安全參數索引值 spi的 IPsec ESP數據包。能夠用逗號或換行符分隔重複該組合。
請注意,此時支持爲IPv4 ESP數據包設置機密。
算法能夠是 des-cbc, 3des-cbc, blowfish-cbc, rc3-cbc, cast128-cbc或 none。默認爲des-cbc。只有在啓用加密編譯tcpdump的狀況下才能解密數據包。
secret是ESP密鑰的ASCII文本。若是前面帶有0x,則將讀取十六進制值。
該選項假定爲RFC2406 ESP,而不是RFC1827 ESP。該選項僅用於調試目的,不鼓勵使用此選項和真正的「祕密」密鑰。經過在命令行上顯示IPsec密鑰,您能夠經過ps(1)和其餘場合將其顯示給其餘人 。
除了上面的語法以外,語法文件名能夠用來讓tcpdump讀取提供的文件。文件在收到第一個ESP數據包後打開,因此tcpdump可能已經放棄的任何特殊權限應該已經放棄了。
[ -F file ] 指定過濾表達式所在的文件
[ -G seconds ]
[ -i interface ] 指定網卡。若不指定,會使用[-D可用中]編號最小的已配置接口(不包括環回),如eth0。
[ -j tstamptype ] 將捕獲的時間戳類型設置爲tstamp_type。
用於時間戳類型的名稱在 pcap-tstamp(7)中給出; 並不是全部列出的類型都必須對任何給定的接口有效。
[ -M secret ] 使用secret做爲共享密鑰,使用TCP-MD5選項(RFC 2385)驗證TCP段中的摘要(若是存在)。
[ --number ]
[ -Q in|out|inout ] --direction=direction選擇發送/接收方向上的哪些數據包應該被捕獲。可能的值是「in」,「out」和「inout」。並不是適用於全部平臺。
[ -r file ] 從文件讀取數據包(使用-w 選項或其餘編寫pcap或pcapng文件的工具建立 )。若是文件是「 - 」,則使用標準輸入。
[ -s snaplen ] --snapshot-length = snaplen <數據包大小> 設置每一個數據包的大小。
Snarf snaplen來自每一個數據包的數據字節而不是默認值262144字節。因爲快照有限而被截斷的數據包在輸出中用`[|proto]',其中proto 是發生截斷的協議級別的名稱。
請注意,拍攝較大的快照會增長處理時間,並有效地減小數據包緩衝量。這可能會致使數據包丟失。
另請注意,拍攝較小的快照會丟棄傳輸層上方協議的數據,這會丟失可能很重要的信息。例如,NFS和AFS請求和回覆很是大,若是選擇了過短的快照長度,則不少細節將不可用。
若是您須要將快照大小減少到默認值如下,則應將snaplen限制爲捕獲您感興趣的協議信息的最小數量。
將snaplen設置 爲0會將其設置爲默認值262144,以便向後兼容最近的舊版本tcpdump的版本 。
[ --time-stamp-precision precision ]
[ --immediate-mode ]
[ -T type ] <數據包類型> 強制「 表達式 」 選擇的數據包將被解釋爲指定的類型。目前已知的類型是:
請注意,上面的pgm類型僅影響UDP解釋,不管如何,本機PGM始終被識別爲IP協議113。UDP封裝的PGM一般稱爲「EPGM」或「PGM / UDP」。
請注意,上面的pgm_zmtp1類型會同時影響本機PGM和UDP的解釋。在本機PGM解碼期間,ODATA / RDATA分組的應用數據將被解碼爲具備ZMTP / 1.0幀的ZeroMQ數據報。在UDP解碼期間,除了任何UDP分組以外,任何UDP分組都將被視爲封裝的PGM分組。
[ -V file ] 從文件中讀取文件名列表。若是文件是「 - 」,則使用標準輸入。
[ -w file ] 將原始數據包寫入文件而不是解析並打印出來。稍後可使用-r選項打印它們。若是文件是「 - 」,則使用標準輸出。
若是寫入文件或管道,則此輸出將被緩衝,所以從文件或管道讀取的程序在收到後可能沒法在任意時間內看到數據包。使用 -U 標誌能夠在收到數據包後當即寫入數據包。MIME類型application/vnd.tcpdump.pcap已在IANA註冊pcap文件。文件擴展名.pcap 彷佛是最經常使用的.cap和 .dmp。讀取捕獲文件時Tcpdump自己不檢查擴展名,而且在寫入時不添加擴展名(它在文件頭中使用幻數)。可是,許多操做系統和應用程序將使用擴展(若是存在)並建議添加一個(例如.pcap)。有關文件格式的說明,請參閱 pcap-savefile(5)。
[ -W filecount ] 限制循環轉儲文件的數量
[ -y datalinktype ] --linktype=datalinktype 設置要在將數據包捕獲到datalinktype時使用的數據連接類型。
[ -z postrotate-command ]
與-C 或 -G 選項一塊兒使用時 ,這將使 tcpdump 運行「 postrotate-command file 」,其中 file 是每次輪換後關閉的savefile。例如,指定 -z gzip 或 -z bzip2 將使用gzip或bzip2壓縮每一個savefile。
請注意,tcpdump將使用最低優先級並行執行命令,以便不會干擾捕獲過程。
若是您想使用一個自己帶有標誌或不一樣參數的命令,您老是能夠編寫一個shell腳本,它將保存文件名做爲惟一參數,製做標誌和參數排列並執行您想要的命令。
[ -Z user ] --relinquish-privileges=user
若是 tcpdump的 運行做爲根,打開所述捕獲裝置或輸入SAVEFILE以後,但在打開任何savefiles輸出以前,用戶ID來改變 用戶 和組ID的主組 用戶。默認狀況下,在編譯時也能夠啓用此行爲。
[ expression ]
選擇要轉儲的數據包。若是沒有 給出表達式,則網絡上的全部數據包都將被轉儲。不然,只會轉儲表達式爲「true」的數據包。有關表達式語法,請參閱 pcap-filter(7)。
該表達式參數可被傳遞給和tcpdump做爲單一殼牌參數,或做爲多個殼牌參數,取其更方便。一般,若是表達式包含Shell元字符,例如用於轉義協議名稱的反斜槓,則更容易將其做爲單個引用參數傳遞,而不是轉義Shell元字符。在解析以前,多個參數與空格鏈接在一塊兒。
列出全部能夠選擇的抓包對象
$ sudo tcpdump -D
1.wlp16s0 [Up, Running]
2.lo [Up, Running, Loopback]
3.any (Pseudo-device that captures on all interfaces) [Up, Running]
4.enp0s25 [Up]
5.bluetooth-monitor (Bluetooth Linux Monitor) [none]
6.nflog (Linux netfilter log (NFLOG) interface) [none]
7.nfqueue (Linux netfilter queue (NFQUEUE) interface) [none]
8.dbus-system (D-Bus system bus) [none]
9.dbus-session (D-Bus session bus) [none]
抓個包看看
$ sudo tcpdump -i wlp16s0 -nn -X ‘port 53’ -c 1
// ‘port 53’:看看53端口的包,DNS服務
$ sudo tcpdump -i wlp16s0 -nn -X -c 1
$ sudo tcpdump -i wlp16s0 -nn -c 1
$ sudo tcpdump -i wlp16s0 -nn -c 1 -e
[ -F file ] 指定過濾表達式所在的文件
$ sudo tcpdump -i eth0 -nn -X ‘port 53′ -c 1
這裏的’port 53’便叫作「過濾表達式」,當表達式比較複雜時,能夠將表達式保存到文件中,使用-F調用。Like this:
$ sudo cat filter.txt
port 53
$ sudo tcpdump -i eth0 -c 1 -t -F filter.txt
[ -w file ] 將原始數據包寫入文件而不是解析並打印出來。
$ sudo tcpdump -i wlp16s0 -w flowdata.txt
[ -r file ] 從文件讀取數據包(使用-w 選項或其餘編寫pcap或pcapng文件的工具建立 )。若是文件是「 - 」,則使用標準輸入。
$ sudo tcpdump -r flowdata.txt |less
因爲是按raw packets來存儲的,因此可使用-e、-l和過濾表達式來對輸出信息進行控制。
打印全部到達或離開sundown的數據包:
$ sudo tcpdump host sundown
打印helios和hot或ace之間的流量:
$ sudo tcpdump host helios and \( hot or ace \)
要在ace和除helios以外的任何主機之間打印全部IP數據包:
$ sudo tcpdump ip host ace and not helios
要在伯克利打印本地主機和主機之間的全部流量:
$ sudo tcpdump net ucb-ether
要經過互聯網網關snup打印全部ftp流量:(請注意,引用該表達式是爲了防止shell(錯誤地)解釋括號):
$ sudo tcpdump 'gateway snup and (port ftp or ftp-data)'
要打印既不是來自本地主機也不是發往本地主機的流量(若是你通往另外一個網絡,那麼這些東西永遠不該該進入你的本地網絡)。
$ sudo tcpdump ip and not net localnet
打印涉及非本地主機的每一個TCP對話的開始和結束數據包(SYN和FIN數據包)。
$ sudo tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net localnet'
要打印與端口80之間的全部IPv4 HTTP數據包,即僅打印包含數據的數據包,而不打印例如SYN和FIN數據包以及僅ACK數據包。(IPv6留給讀者練習。)
$ sudo tcpdump 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'
要打印經過網關snup發送的長度超過576字節的IP數據包:
$ sudo tcpdump 'gateway snup and ip[2:2] > 576'
要打印未 經過以太網廣播或多播發送的IP廣播或多播數據包 :
$ sudo tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'
要打印全部不是迴應請求/回覆的ICMP數據包(即不ping數據包):
$ sudo tcpdump 'icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply'
打印IP包長超過576字節的網絡包
$ sudo tcpdump 'ip[2:2] > 576'
打印涉及非本地主機的每一個TCP對話的開始SYN標記數據包,排除目標主機google。
$ sudo tcpdump 'tcp[tcpflags] & tcp-syn != 0 and not dst host google.com'
協議過濾: ether, ip, ip6, arp, tcp, udp, rarp
$ sudo tcpdump -i wlp16s0 -c 10 'udp'
指定源或者目的地址:默認是src or dst。
$ sudo tcpdump -i wlp16s0 -c 10 'dst 8.8.8.8'
限定端口port; portrange端口區域; host; net(網絡段);
$ sudo tcpdump -i wlp16s0 -c 10 'dst port 53 or dst port 80'
指定經過網卡與某個特定服務器的數據包
$ sudo tcpdump -i wlp16s0 -c 1 'host google.com'
只看ftp及ftp數據
$ tcpdump 'port ftp or ftp-data'
TCP協議的SYN、ACK、FIN標識
tcp[tcpflags] & tcp-syn
tcp[tcpflags] & tcp-ack
tcp[tcpflags] & tcp-fin
查看ICMP包中「目標不可達、主機不可達」的包:
icmp[0:2]==0x0301
proto就是protocol的縮寫,可用的協議包括:
tcp, udp,
ip, ip6, icmp,
ether, fddi, tr, wlan, ppp, slip, link – 鏈路層協議
arp, rarp, radio,
tcpdump的輸出取決於協議。如下給出了大多數格式的簡要說明和示例。
⚓ 時間戳 HH:MM:ss.frac
默認狀況下,全部輸出行都以時間戳開頭。時間戳是表單中的當前時鐘時間
而且與內核的時鐘同樣準確。時間戳反映了內核將時間戳應用於數據包的時間。沒有嘗試考慮網絡接口完成從網絡接收分組與內核什麼時候向分組應用時間戳之間的時間延遲;該時間延遲可能包括網絡接口完成從網絡接收數據包的時間與中斷傳遞到內核以使其讀取數據包的時間和內核服務於內核之間的延遲之間的延遲「新數據包」中斷以及向數據包應用時間戳的時間。
若是給出'-e'選項,則打印出連接級別標題。在以太網上,將打印源和目標地址,協議和數據包長度。
在FDDI網絡上,' - e'選項使tcpdump打印「幀控制」字段,源地址和目標地址以及數據包長度。(「幀控制」字段控制數據包其他部分的解釋。正常數據包(例如包含IP數據報的數據包)是「異步」數據包,優先級值介於0和7之間;例如,「async4」。假設數據包包含802.2邏輯鏈路控制(LLC)數據包;若是LLC報頭不是ISO數據報或所謂的SNAP數據包,則打印LLC報頭。
在令牌環網絡中,' - e'選項使tcpdump打印「訪問控制」和「幀控制」字段,源和目標地址以及數據包長度。與FDDI網絡同樣,假設數據包包含LLC數據包。不管是否指定了'-e'選項,都會爲源路由數據包打印源路由信息。
在802.11網絡上,' - e'選項使tcpdump打印「幀控制」字段,802.11標頭中的全部地址以及數據包長度。與FDDI網絡同樣,假設數據包包含LLC數據包。
(注意:如下描述假定您熟悉RFC-1144中描述的SLIP壓縮算法。)
在SLIP連接上,打印出方向指示符(入站爲「I」,出站爲「O」),數據包類型和壓縮信息。首先打印數據包類型。這三種類型是ip,utcp和ctcp。不會爲ip數據包打印更多連接信息。對於TCP數據包,將在類型後打印鏈接標識符。若是數據包被壓縮,則打印出其編碼的標頭。特殊狀況打印爲* S +n和* SA +n,其中n是序列號(或序列號和ack)已更改的量。若是不是特殊狀況,則打印零個或多個更改。更改由U(緊急指針),W(窗口),A(ack),S(序列號)和I(數據包ID)指示,後跟delta(+ n或-n)或新值(= N)。最後,打印數據包中的數據量和壓縮的報頭長度。
例如,如下行顯示了帶有隱式鏈接標識符的出站壓縮TCP數據包;ack改成6,序列號改成49,分組ID改成6;有3個字節的數據和6個字節的壓縮標頭:
O ctcp * A+6 S+49 I+6 3 (6)
Arp/rarp輸出顯示請求的類型及其參數。格式旨在自我解釋。如下是從主機rtsg到主機csam的`rlogin'開頭的簡短示例:
arp who-has csam tell rtsg
arp reply csam is-at CSAM
第一行說rtsg發送了一個arp數據包,詢問互聯網主機csam的以太網地址。Csam回覆其以太網地址(在此示例中,以太網地址採用大寫字母和小寫的互聯網地址)。
若是咱們作了tcpdump -n,這看起來就不那麼多了:
arp who-has 128.3.254.6 tell 128.3.254.68
arp reply 128.3.254.6 is-at 02:07:01:00:01:c4
若是咱們已經完成了tcpdump -e,那麼第一個數據包被廣播而第二個數據包是點對點這一事實將是可見的:
RTSG Broadcast 0806 64: arp who-has csam tell rtsg CSAM RTSG 0806 64: arp reply csam is-at CSAM
對於第一個數據包,這表示以太網源地址是RTSG,目標是以太網廣播地址,類型字段包含十六進制0806(類型ETHER_ARP),總長度爲64字節。
若是未打印鏈路層標頭,則對於IPv4數據包,將在時間戳以後打印IP。
若是指定了-v標誌,那麼來自IPv4標頭的信息將顯示在IP或鏈路層標頭以後的括號中。此信息的通常格式爲:
tos tos, ttl ttl, id id, offset offset, flags [flags], proto proto, length length, options (options)
tos是服務領域的類型;若是ECN位非零,則將其報告爲ECT(1),ECT(0)或CE。ttl是生存時間;若是它爲零,則不報告。id是IP標識字段。offset是片斷偏移字段;打印它是不是碎片數據報的一部分。標誌是MF和DF標誌;若是設置了MF,則報告+,若是設置了F,則報告DF。若是二者都沒有設置,。據報道。proto是協議ID字段。length是總長度字段。選項是IP選項,若是有的話。
接下來,對於TCP和UDP數據包,將打印源和目標IP地址以及TCP或UDP端口(每一個IP地址與其對應端口之間帶有一個點),並使用>分隔源和目標。對於其餘協議,將打印地址,並使用>分隔源和目標。以後將打印更高級別的協議信息(若是有)。
對於分段的IP數據報,第一個片斷包含更高級別的協議頭;第一個以後的片斷不包含更高級別的協議頭。如上所述,將在IP報頭信息中僅使用-v標誌打印分段信息。
(注意:如下描述假定您熟悉RFC-793中描述的TCP協議。若是您不熟悉該協議,則此描述對您沒有多大用處。)
TCP協議線的通常格式是:
src > dst: Flags [tcpflags], seq data-seqno, ack ackno, win window, urg urgent, options [opts], length len
Src和dst是源和目標IP地址和端口。Tcpflags是S(SYN),F(FIN),P(PUSH),R(RST),U(URG),W(ECN CWR),E(ECN-Echo)或「。」的某種組合。(ACK),若是沒有設置標誌,則爲「none」。Data-seqno描述了該數據包中數據所覆蓋的序列空間部分(參見下面的示例)。Ackno是預期此鏈接上另外一個方向的下一個數據的序列號。Window是此鏈接上另外一個方向可用的接收緩衝區空間的字節數。Urg表示數據包中存在「緊急」數據。OPTS是TCP選項(例如,MSS 1024)。萊恩是有效載荷數據的長度。
Iptype,Src,dst和flags老是存在。其餘字段取決於數據包的TCP協議頭的內容,僅在適當時輸出。
這是從主機rtsg到主機csam的rlogin的開頭部分。
IP rtsg.1023 > csam.login: Flags [S], seq 768512:768512, win 4096, opts [mss 1024] IP csam.login > rtsg.1023: Flags [S.], seq, 947648:947648, ack 768513, win 4096, opts [mss 1024] IP rtsg.1023 > csam.login: Flags [.], ack 1, win 4096 IP rtsg.1023 > csam.login: Flags [P.], seq 1:2, ack 1, win 4096, length 1 IP csam.login > rtsg.1023: Flags [.], ack 2, win 4096 IP rtsg.1023 > csam.login: Flags [P.], seq 2:21, ack 1, win 4096, length 19 IP csam.login > rtsg.1023: Flags [P.], seq 1:2, ack 21, win 4077, length 1 IP csam.login > rtsg.1023: Flags [P.], seq 2:3, ack 21, win 4077, urg 1, length 1 IP csam.login > rtsg.1023: Flags [P.], seq 3:4, ack 21, win 4077, urg 1, length 1
第一行說rtsg上的TCP端口1023將數據包發送到csam上的端口登陸。在小號代表SYN標誌設置。數據包序列號爲768512,不包含任何數據。(符號是'first:last',表示`序列號首先到但不包括last'。)沒有揹負的ack,可用的接收窗口是4096字節,而且有一個max-segment-size選項請求一個1024字節的mss。
Csam回覆了一個相似的數據包,除了它包含rtsg的SYN的背馱式ack。Rtsg而後acks csam的SYN。'。'表示已設置ACK標誌。數據包不包含數據,所以沒有數據序列號或長度。注意,ack序列號是一個小整數(1)。第一次tcpdump看到TCP「會話」時,它會打印數據包中的序列號。在隨後的會話分組中,打印當前分組的序列號與該初始序列號之間的差別。這意味着第一個以後的序列號能夠被解釋爲對話數據流中的相對字節位置(每一個方向的第一個數據字節爲「1」)。`-S'將覆蓋此功能,致使輸出原始序列號。
在第6行,rtsg發送csam 19字節的數據(在會話的rtsg→csam一側的字節2到20)。PUSH標誌在數據包中設置。在第7行,csam表示接收到的數據由rtsg發送但不包括字節21.大多數數據顯然都位於套接字緩衝區中,由於csam的接收窗口縮小了19個字節。Csam還將一個字節的數據發送到此數據包中的rtsg。在第8行和第9行,csam將兩個字節的緊急推送數據發送到rtsg。
若是快照足夠小以致於tcpdump沒有捕獲完整的TCP標頭,它會盡量多地解釋標頭,而後報告``tcp]''表示沒法解釋餘數。若是標題包含一個僞造的選項(一個長度過小或超出標題末尾的選項),tcpdump會將其報告爲「[bad opt]」而且不會解釋任何其餘選項(由於它沒法分辨)他們開始的地方)。若是標題長度表示存在選項,但IP數據報長度不足以使選項實際存在,則tcpdump將其報告爲「[bad hdr length]」。
使用特定標誌組合捕獲TCP數據包(SYN-ACK,URG-ACK等)
TCP報頭的控制位部分有8位:
假設咱們想要觀察用於創建TCP鏈接的數據包。回想一下TCP在初始化新鏈接時使用3次握手協議;關於TCP控制位的鏈接順序是
如今咱們對捕獲僅設置了SYN位的數據包感興趣(步驟1)。請注意,咱們不但願來自步驟2(SYN-ACK)的數據包,只是簡單的初始SYN。咱們須要的是tcpdump的正確過濾器表達式。
回想一下沒有選項的TCP頭的結構:
0 15 31 ----------------------------------------------------------------- | source port | destination port | ----------------------------------------------------------------- | sequence number | ----------------------------------------------------------------- | acknowledgment number | ----------------------------------------------------------------- | HL | rsvd |C|E|U|A|P|R|S|F| window size | ----------------------------------------------------------------- | TCP checksum | urgent pointer | ----------------------------------------------------------------- 除非存在選項,不然TCP標頭一般包含20個八位字節的數據。圖的第一行包含八位字節0-3,第二行顯示八位字節4-7等。
從0開始計數,相關的TCP控制位包含在八位字節13中:
0 7| 15| 23| 31 ----------------|---------------|---------------|---------------- | HL | rsvd |C|E|U|A|P|R|S|F| window size | ----------------|---------------|---------------|---------------- | | 13th octet | | |
讓咱們仔細看看octet no。13:
| | |---------------| |C|E|U|A|P|R|S|F| |---------------| |7 5 3 0|
這些是咱們感興趣的TCP控制位。咱們將此八位位組中的位從0到7,從右到左編號,所以PSH位爲3位,而URG位爲5。
回想一下,咱們想要捕獲只有SYN集的數據包。讓咱們看看若是TCP數據報到達其標頭中的SYN位,那麼八位字節13會發生什麼:
|C|E|U|A|P|R|S|F| |---------------| |0 0 0 0 0 0 1 0| |---------------| |7 6 5 4 3 2 1 0|
查看控制位部分,咱們看到只設置了位號1(SYN)。
假設八位字節數13是網絡字節順序的8位無符號整數,則該八位字節的二進制值爲
它的十進制表示是
7 6 5 4 3 2 1 0 0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 1*2 + 0*2 = 2
咱們差很少完成了,由於如今咱們知道若是隻設置了SYN,TCP頭中第13個八位字節的值,當被解釋爲網絡字節順序的8位無符號整數時,必須正好爲2。
這種關係能夠表示爲
咱們可使用這個表達式做爲tcpdump的過濾器,以便觀察只有SYN集的數據包:
表達式說「讓TCP數據報的第13個八位字節具備小數值2」,這正是咱們想要的。
如今,讓咱們假設咱們須要捕獲SYN數據包,但咱們不關心是否同時設置ACK或任何其餘TCP控制位。讓咱們看看當設置了SYN-ACK的TCP數據報到達時,八位字節13會發生什麼:
|C|E|U|A|P|R|S|F| |---------------| |0 0 0 1 0 0 1 0| |---------------| |7 6 5 4 3 2 1 0|
如今位1和4設置在第13個八位字節中。八位組13的二進制值是
轉換爲十進制
7 6 5 4 3 2 1 0 0*2 + 0*2 + 0*2 + 1*2 + 0*2 + 0*2 + 1*2 + 0*2 = 18
如今咱們不能在tcpdump過濾器表達式中使用'tcp [13] == 18',由於這樣只會選擇那些設置了SYN-ACK的數據包,而不能只選擇那些只有SYN設置的數據包。請記住,只要設置了SYN,咱們就不關心是否設置ACK或任何其餘控制位。
爲了實現咱們的目標,咱們須要邏輯上將八位組13的二進制值與其餘值保持一致以保留SYN位。咱們知道咱們但願在任何狀況下都要設置SYN,所以咱們將使用SYN的二進制值邏輯AND第13個八位字節中的值:
00010010 SYN-ACK 00000010 SYN AND 00000010(咱們想要SYN)和00000010(咱們想要SYN) -------- -------- = 00000010 = 00000010
咱們看到,不管是否設置了ACK或其餘TCP控制位,此AND操做都會產生相同的結果。AND值的十進制表示以及此操做的結果爲2(二進制00000010),所以咱們知道對於具備SYN集的數據包,如下關係必須爲true:
這指向了tcpdump過濾器表達式
一些偏移和字段值能夠表示爲名稱而不是數值。例如,tcp [13]能夠用tcp [tcpflags]替換。如下TCP標誌字段值也可用:tcp-fin,tcp-syn,tcp-rst,tcp-push,tcp-ack,tcp-urg。
這能夠證實以下:
請注意,您應該在表達式中使用單引號或反斜槓來隱藏shell中的AND('&')特殊字符。
這種rwho數據包說明了UDP格式:
actinide.who> broadcast.who:udp 84
這就是說端口誰主機錒發送一個UDP數據報給端口誰主機廣播,互聯網廣播地址。該數據包包含84個字節的用戶數據。
識別某些UDP服務(來自源或目標端口號)並打印更高級別的協議信息。特別是,域名服務請求(RFC-1034/1035)和Sun RPC調用(RFC-1050)到NFS。
(注意:如下描述假定您熟悉RFC-1035中描述的域服務協議。若是您不熟悉該協議,則如下描述彷佛是用希臘語編寫的。)
名稱服務器請求的格式爲
src > dst: id op? flags qtype qclass name (len) h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)
主機h2opolo向helios上的域服務器詢問與名稱ucbvax.berkeley.edu相關聯的地址記錄(qtype = A)。查詢ID爲「3」。「+」表示設置了遞歸所需的標誌。查詢長度爲37個字節,不包括UDP和IP協議頭。查詢操做是正常的,查詢,因此省略了運算字段。若是op是其餘任何東西,它將被打印在'3'和'+'之間。相似地,qclass是正常的,C_IN,而且被省略。在'A'以後當即打印任何其餘qclass。
檢查一些異常並可能致使用方括號括起來的額外字段:若是查詢包含答案,權限記錄或附加記錄部分,則ancount,nscount或arcount打印爲「[na]」,「[nn ]'或`[nau]'其中n是適當的計數。若是任何響應位被設置(AA,RA或rcode)或任何「必須爲零」位被設置爲字節2和3,則打印「[b2&3 =x]」,其中x是十六進制值頭字節二和三。
名稱服務器響應的格式爲
src > dst: id op rcode flags a/n/au type class data (len) helios.domain > h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273) helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97)
在第一個示例中,helios響應來自h2opolo的查詢ID 3,其中包含3個答案記錄,3個名稱服務器記錄和7個附加記錄。第一個答案記錄是A型(地址),其數據是因特網地址128.32.137.3。響應的總大小爲273個字節,不包括UDP和IP頭。省略了op(查詢)和響應代碼(NoError),以及A記錄的類(C_IN)。
在第二個示例中,helios使用不存在的域(NXDomain)的響應代碼響應查詢2,沒有答案,一個名稱服務器而且沒有權限記錄。「*」表示權威答案位已設置。因爲沒有答案,所以沒有打印任何類型,類別或數據。
可能出現的其餘標誌字符是「 - 」(遞歸可用,RA,未設置)和「|」(截斷消息,TC,設置)。若是`question'部分不包含一個條目,則打印`[nq]'。
tcpdump如今包括對UDP / 137,UDP / 138和TCP / 139上的數據進行至關普遍的SMB / CIFS / NBT解碼。還完成了對IPX和NetBEUI SMB數據的一些原始解碼。
默認狀況下,完成至關小的解碼,若是使用-v,則執行更詳細的解碼。請注意,使用-va單個SMB數據包可能佔用一頁或更多頁面,所以若是您真的須要全部血腥細節,請僅使用-v。
有關SMB數據包格式的信息以及全部字段的含義,請參閱您最喜好的samba.org鏡像站點上的www.cifs.org或pub / samba / specs /目錄。SMB補丁由Andrew Tridgell(tridge@samba.org)編寫。
Sun NFS(網絡文件系統)請求和回覆打印爲:
src.sport > dst.nfs: NFS request xid xid len op args src.nfs > dst.dport: NFS reply xid xid reply stat len op results sushi.1023 > wrl.nfs: NFS request xid 26377 112 readlink fh 21,24/10.73165 wrl.nfs > sushi.1023: NFS reply xid 26377 reply ok 40 readlink "../var" sushi.1022 > wrl.nfs: NFS request xid 8219 144 lookup fh 9,74/4096.6878 "xcolors" wrl.nfs > sushi.1022: NFS reply xid 8219 reply ok 128 lookup fh 9,74/4134.3150
在第一行,主機壽司發送帶有ID的交易26377至WRL。請求是112個字節,不包括UDP和IP頭。該操做是文件句柄(fh)21,24 / 10.731657119上的readlink(讀取符號連接)。(若是幸運的話,就像在這種狀況下,文件句柄能夠被解釋爲主要的次要設備號對,而後是inode號和世代號。)在第二行中,wrl用相同的事務回覆「ok」 id和連接的內容。
在第三行中,sushi請求(使用新的事務id)wrl在目錄文件9,74 / 4096.6878中查找名稱`xcolors'。在第四行中,wrl發送帶有相應事務id的回覆。
請注意,打印的數據取決於操做類型。若是與NFS協議規範一塊兒閱讀,則該格式旨在自我解釋。另請注意,舊版本的tcpdump以稍微不一樣的格式打印NFS數據包:將打印事務ID(xid)而不是數據包的非NFS端口號。
若是給出-v(詳細)標誌,則打印附加信息。例如:
sushi.1023 > wrl.nfs: NFS request xid 79658 148 read fh 21,11/12.195 8192 bytes @ 24576 wrl.nfs > sushi.1023: NFS reply xid 79658 reply ok 1472 read REG 100664 ids 417/0 sz 29388
(-v還打印IP頭TTL,ID,長度和碎片字段,這些字段已在本例中省略。)在第一行中,sushi要求wrl從文件21,11 / 12.195讀取8192個字節,字節偏移量24576.Wrl回覆'ok';第二行顯示的數據包是應答的第一個片斷,所以只有1472個字節長(其餘字節將跟隨後續片斷,但這些片斷沒有NFS甚至UDP頭,因此可能不會打印,取決於使用的過濾器表達式)。由於給出了-v標誌,因此打印了一些文件屬性(除文件數據外還返回):文件類型(常規文件的「REG」),文件模式(八進制), uid和gid以及文件大小。
若是屢次給出-v標誌,則會打印更多詳細信息。
NFS回覆數據包未明確標識RPC操做。相反,tcpdump會跟蹤「最近」的請求,並使用事務ID將它們與回覆相匹配。若是答覆沒有嚴格遵循相應的請求,則可能沒法解析。
Transarc AFS(安德魯文件系統)請求和回覆打印爲:
src.sport > dst.dport: rx packet-type src.sport > dst.dport: rx packet-type service call call-name args src.sport > dst.dport: rx packet-type service reply call-name args elvis.7001 > pike.afsfs: rx data fs call rename old fid 536876964/1/1 ".newsrc.new" new fid 536876964/1/1 ".newsrc" pike.afsfs > elvis.7001: rx data fs reply rename
在第一行中,主機elvis發送一個RX數據包到pike。這是到fs(文件服務器)服務的RX數據包,而且是RPC調用的開始。RPC調用是重命名,舊目錄文件ID爲536876964/1/1,舊文件名爲`.newsrc.new',新目錄文件ID爲536876964/1/1,新文件名爲`。 newsrc」。主機派克響應重命名調用的RPC回覆(這是成功的,由於它是一個數據包而不是停止數據包)。
一般,全部AFS RPC至少由RPC調用名稱解碼。大多數AFS RPC至少有一些參數被解碼(一般只有「有趣的」參數,對於某些有趣的定義)。
該格式旨在自我描述,但對於不熟悉AFS和RX工做的人可能沒有用。
若是給出兩次-v(詳細)標誌,則打印確認包和附加標題信息,例如RX呼叫ID,呼叫號,序列號,序列號和RX分組標誌。
若是給出-v標誌兩次,則打印附加信息,例如RX呼叫ID,序列號和RX包標誌。還從RX ack分組打印MTU協商信息。
若是給出-v標誌三次,則打印安全性索引和服務標識。
爲停止數據包打印錯誤代碼,但Ubik信標數據包除外(由於停止數據包用於表示Ubik協議的是投票)。
AFS回覆數據包未明確標識RPC操做。相反,tcpdump會跟蹤「最近」的請求,並使用電話號碼和服務ID將它們與回覆相匹配。若是答覆沒有嚴格遵循相應的請求,則可能沒法解析。
封裝在UDP數據報中的AppleTalk DDP數據包被解封裝並做爲DDP數據包轉儲(即,丟棄全部UDP報頭信息)。文件/etc/atalk.names用於將AppleTalk網絡和節點編號轉換爲名稱。此文件中的行具備該表單
number name 1.254 ether 16.1 icsd-net 1.254.110 ace
前兩行給出了AppleTalk網絡的名稱。第三行給出了特定主機的名稱(主機與數字中的第3個八位字節區分開來 - 網絡號必須有兩個八位字節,主機號必須有三個八位字節。)數字和名稱應該分開經過空格(空格或製表符)。該/etc/atalk.names文件可能包含空行或註釋行(開始用'#')。
AppleTalk地址以表格形式打印
net.host.port 144.1.209.2 > icsd-net.112.220 office.2 > icsd-net.112.220 jssmag.149.235 > icsd-net.2
(若是/etc/atalk.names不存在或者不包含某些AppleTalk主機/網絡號的條目,則地址以數字形式打印。)在第一個示例中,網絡144.1上的NBP(DDP端口2)節點209發送到正在監聽網絡節點112的端口220的任何內容。除了源節點的全名已知(「辦公室」)以外,第二行是相同的。第三行是從net jssmag節點149上的端口235發送到在icsd-net NBP端口上廣播(注意,廣播地址(255)由沒有主機號的網絡名稱指示 - 所以這是個好主意在/etc/atalk.names中保持節點名稱和網絡名稱不一樣。
NBP(名稱綁定協議)和ATP(AppleTalk事務協議)數據包的內容被解釋。其餘協議只是轉儲協議名稱(若是沒有爲協議註冊名稱,則爲數字)和數據包大小。
icsd-net.112.220> jssmag.2:nbp-lkup 190:「=:LaserWriter @ *」 jssmag.209.2> icsd-net.112.220:nbp-reply 190:「RM1140:LaserWriter @ *」250 techpit.2> icsd-net.112.220:nbp-reply 190:「techpit:LaserWriter @ *」186
第一行是由net icsd主機112發送並在網絡jssmag上廣播的激光寫入器的名稱查找請求。查找的nbp id是190.第二行顯示來自主機jssmag.209的此請求的回覆(請注意它具備相同的id),表示它在端口250上註冊了名爲「RM1140」的激光編寫器資源。 line是對同一請求的另外一個回覆,稱主機techpit在端口186上註冊了laserwriter「techpit」。
jssmag.209.165 > helios.132: atp-req 12266<0-7> 0xae030001 helios.132 > jssmag.209.165: atp-resp 12266:0 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:1 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:2 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:4 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:6 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp*12266:7 (512) 0xae040000 jssmag.209.165 > helios.132: atp-req 12266<3,5> 0xae030001 helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000 jssmag.209.165 > helios.132: atp-rel 12266<0-7> 0xae030001 jssmag.209.133 > helios.132: atp-req* 12267<0-7> 0xae030002
Jssmag.209經過請求最多8個數據包(「<0-7>」)啓動與主機helios的事務ID 12266。該行末尾的十六進制數是請求中「userdata」字段的值。
Helios響應8個512字節的數據包。事務id後面的`:digit'給出事務中的數據包序列號,而parens中的數字是數據包中的數據量,不包括atp頭。包7上的「*」表示EOM位已設置。
而後Jssmag.209請求重傳數據包3和5。Helios從新發送它們而後jssmag.209發佈交易。最後,jssmag.209啓動下一個請求。請求中的「*」表示未設置XO(「剛好一次」)。