Linux tcpdump抓包命令詳解
實用命令實例
命令使用
tcpdump採用命令行方式，它的命令格式爲：linux
tcpdump [ -AdDeflLnNOpqRStuUvxX ] [ -c count ] [ -C file_size ] [ -F file ] [ -i ] [ -m module ] [ -M secret ] [ -r file ] [ -s snaplen ] [ -T type ] [ -w file ] [ -W filecount ] [ -E spi@ipaddr algo:secret,... ] [ -y datalinktype ] [ -Z user ] [ expression ]
tcpdump的簡單選項介紹
-a 將網絡地址和廣播地址轉變成名字； -d 將匹配信息包的代碼以人們可以理解的彙編格式給出； -dd 將匹配信息包的代碼以c語言程序段的格式給出； -ddd 將匹配信息包的代碼以十進制的形式給出； -e 在輸出行打印出數據鏈路層的頭部信息； -f 將外部的Internet地址以數字的形式打印出來； -l 使標準輸出變爲緩衝行形式； -n 不把網絡地址轉換成名字； -t 在輸出的每一行不打印時間戳； -v 輸出一個稍微詳細的信息，例如在ip包中能夠包括ttl和服務類型的信息； -vv 輸出詳細的報文信息； -c 在收到指定的包的數目後，tcpdump就會中止； -F 從指定的文件中讀取表達式,忽略其它的表達式； -i 指定監聽的網絡接口； -r 從指定的文件中讀取包(這些包通常經過-w選項產生)； -w 直接將包寫入文件中，並不分析和打印出來； -T 將監聽到的包直接解釋爲指定的類型的報文，常見的類型有rpc （遠程過程調用）和snmp（簡單網絡管理協議；） -A 以ASCII碼方式顯示每個數據包(不會顯示數據包中鏈路層頭部信息). 在抓取包含網頁數據的數據包時, 可方便查看數據(nt: 即Handy capturing web pages). -c count tcpdump將在接受到count個數據包後退出. -C file-size (nt: 此選項用於配合-w file 選項使用) 該選項使得tcpdump 在把原始數據包直接保存到文件中以前, 檢查此文件大小是否超過file-size. 若是超過了, 將關閉此文件,另創一個文件繼續用於原始數據包的記錄. 新建立的文件名與-w 選項指定的文件名一致, 但文件名後多了一個數字.該數字會從1開始隨着新建立文件的增多而增長. file-size的單位是百萬字節(nt: 這裏指1,,000個字節,並不是1,,576個字節, 後者是以1024字節爲1k, 1024k字節爲1M計算所得, 即1M= ＊ ＝ ,,) -d 以容易閱讀的形式,在標準輸出上打印出編排過的包匹配碼, 隨後tcpdump中止.(nt | rt: human readable, 容易閱讀的,一般是指以ascii碼來打印一些信息. compiled, 編排過的. packet-matching code, 包匹配碼,含義未知, 需補充) -dd 以C語言的形式打印出包匹配碼. -ddd 以十進制數的形式打印出包匹配碼(會在包匹配碼以前有一個附加的前綴). -D 打印系統中全部tcpdump能夠在其上進行抓包的網絡接口. 每個接口會打印出數字編號, 相應的接口名字, 以及可能的一個網絡接口描述. 其中網絡接口名字和數字編號能夠用在tcpdump 的-i flag 選項(nt: 把名字或數字代替flag), 來指定要在其上抓包的網絡接口. 此選項在不支持接口列表命令的系統上頗有用(nt: 好比, Windows 系統, 或缺少 ifconfig -a 的UNIX系統); 接口的數字編號在windows 或其後的系統中頗有用, 由於這些系統上的接口名字比較複雜, 而不易使用. 若是tcpdump編譯時所依賴的libpcap庫太老,-D 選項不會被支持, 由於其中缺少 pcap_findalldevs()函數. -e 每行的打印輸出中將包括數據包的數據鏈路層頭部信息 -E spi@ipaddr algo:secret,... 可經過spi@ipaddr algo:secret 來解密IPsec ESP包(nt | rt:IPsec Encapsulating Security Payload,IPsec 封裝安全負載, IPsec可理解爲, 一整套對ip數據包的加密協議, ESP 爲整個IP 數據包或其中上層協議部分被加密後的數據,前者的工做模式稱爲隧道模式; 後者的工做模式稱爲傳輸模式 . 工做原理, 另需補充). 須要注意的是, 在終端啓動tcpdump 時, 能夠爲IPv4 ESP packets 設置密鑰(secret）. 可用於加密的算法包括des-cbc, 3des-cbc, blowfish-cbc, rc3-cbc, cast128-cbc, 或者沒有(none).默認的是des-cbc(nt: des, Data Encryption Standard, 數據加密標準, 加密算法未知, 另需補充).secret 爲用於ESP 的密鑰, 使用ASCII 字符串方式表達. 若是以 0x 開頭, 該密鑰將以16進制方式讀入. 該選項中ESP 的定義遵循RFC2406, 而不是 RFC1827. 而且, 此選項只是用來調試的, 不推薦以真實密鑰(secret)來使用該選項, 由於這樣不安全: 在命令行中輸入的secret 能夠被其餘人經過ps 等命令查看到. 除了以上的語法格式(nt: 指spi@ipaddr algo:secret), 還能夠在後面添加一個語法輸入文件名字供tcpdump 使用(nt：即把spi@ipaddr algo:secret,... 中...換成一個語法文件名). 此文件在接受到第一個ESP 包時會打開此文件, 因此最好此時把賦予tcpdump 的一些特權取消(nt: 可理解爲, 這樣防範以後, 當該文件爲惡意編寫時,不至於形成過大損害). -f 顯示外部的IPv4 地址時(nt: foreign IPv4 addresses, 可理解爲, 非本機ip地址), 採用數字方式而不是名字.(此選項是用來對付Sun公司的NIS服務器的缺陷(nt: NIS, 網絡信息服務, tcpdump 顯示外部地址的名字時會用到她提供的名稱服務): 此NIS服務器在查詢非本地地址名字時,經常會陷入無盡的查詢循環). 因爲對外部(foreign)IPv4地址的測試須要用到本地網絡接口(nt: tcpdump 抓包時用到的接口)及其IPv4 地址和網絡掩碼. 若是此地址或網絡掩碼不可用, 或者此接口根本就沒有設置相應網絡地址和網絡掩碼(nt: linux 下的 網絡接口就不須要設置地址和掩碼, 不過此接口能夠收到系統中全部接口的數據包), 該選項不能正常工做. -F file 使用file 文件做爲過濾條件表達式的輸入, 此時命令行上的輸入將被忽略. -i 指定tcpdump 須要監聽的接口. 若是沒有指定, tcpdump 會從系統接口列表中搜尋編號最小的已配置好的接口(不包括 loopback 接口).一但找到第一個符合條件的接口, 搜尋立刻結束. 在採用2.2版本或以後版本內核的Linux 操做系統上, 這個虛擬網絡接口可被用來接收全部網絡接口上的數據包(nt: 這會包括目的是該網絡接口的, 也包括目的不是該網絡接口的). 須要注意的是若是真實網絡接口不能工做在模式(promiscuous)下,則沒法在這個虛擬的網絡接口上抓取其數據包. 若是 -D 標誌被指定, tcpdump會打印系統中的接口編號，而該編號就可用於此處的interface 參數. -l 對標準輸出進行行緩衝(nt: 使標準輸出設備遇到一個換行符就立刻把這行的內容打印出來).在須要同時觀察抓包打印以及保存抓包記錄的時候頗有用. 好比, 可經過如下命令組合來達到此目的: ``tcpdump -l | tee dat 或者 ``tcpdump -l > dat & tail -f dat.(nt: 前者使用tee來把tcpdump 的輸出同時放到文件dat和標準輸出中, 然後者經過重定向操做, 把tcpdump的輸出放到dat 文件中, 同時經過tail把dat文件中的內容放到標準輸出中) -L 列出指定網絡接口所支持的數據鏈路層的類型後退出.(nt: 指定接口經過-i 來指定) -m module 經過module 指定的file 裝載SMI MIB 模塊(nt: SMI，Structure of Management Information, 管理信息結構MIB, Management Information Base, 管理信息庫. 可理解爲, 這二者用於SNMP(Simple Network Management Protoco)協議數據包的抓取. 具體SNMP 的工做原理未知, 另需補充). 此選項可屢次使用, 從而爲tcpdump 裝載不一樣的MIB 模塊. -M secret 若是TCP 數據包(TCP segments)有TCP-MD5選項(在RFC 2385有相關描述), 則爲其摘要的驗證指定一個公共的密鑰secret. -n 不對地址(好比, 主機地址, 端口號)進行數字表示到名字表示的轉換. -N 不打印出host 的域名部分. 好比, 若是設置了此選現, tcpdump 將會打印 而不是 . -O 不啓用進行包匹配時所用的優化代碼. 當懷疑某些bug是由優化代碼引發的, 此選項將頗有用. -p 通常狀況下, 把網絡接口設置爲非模式. 但必須注意 , 在特殊狀況下此網絡接口仍是會以模式來工做； 從而, 的設與不設, 不能當作如下選現的代名詞: 或 (nt: 前者表示只匹配以太網地址爲host 的包, 後者表示匹配以太網地址爲廣播地址的數據包). -q 快速(也許用更好?)打印輸出. 即打印不多的協議相關信息, 從而輸出行都比較簡短. -R 設定tcpdump 對 ESP/AH 數據包的解析按照 RFC1825而不是RFC1829(nt: AH, 認證頭, ESP， 安全負載封裝, 這二者會用在IP包的安全傳輸機制中). 若是此選項被設置, tcpdump 將不會打印出域(nt: relay prevention field). 另外,因爲ESP/AH規範中沒有規定ESP/AH數據包必須擁有協議版本號域,因此tcpdump不能從收到的ESP/AH數據包中推導出協議版本號. -r file 從文件file 中讀取包數據. 若是file 字段爲 符號, 則tcpdump 會從標準輸入中讀取包數據. -S 打印TCP 數據包的順序號時, 使用絕對的順序號, 而不是相對的順序號.(nt: 相對順序號可理解爲, 相對第一個TCP 包順序號的差距,好比, 接受方收到第一個數據包的絕對順序號爲232323, 對於後來接收到的第2個,第3個數據包, tcpdump會打印其序列號爲1, 2分別表示與第一個數據包的差距爲1 和 . 而若是此時-S 選項被設置, 對於後來接收到的第2個, 第3個數據包會打印出其絕對順序號:, ). -s snaplen 設置tcpdump的數據包抓取長度爲snaplen, 若是不設置默認將會是68字節(而支持網絡接口分接頭(nt: NIT, 上文已有描述,可搜索關鍵字找到那裏)的SunOS系列操做系統中默認的也是最小值是96).68字節對於IP, ICMP(nt: Internet Control Message Protocol,因特網控制報文協議), TCP 以及 UDP 協議的報文已足夠, 但對於名稱服務(nt: 可理解爲dns, nis等服務), NFS服務相關的數據包會產生包截短. 若是產生包截短這種狀況, tcpdump的相應打印輸出行中會出現[|proto]的標誌（proto 實際會顯示爲被截短的數據包的相關協議層次). 須要注意的是, 採用長的抓取長度(nt: snaplen比較大), 會增長包的處理時間, 而且會減小tcpdump 可緩存的數據包的數量， 從而會致使數據包的丟失. 因此, 在能抓取咱們想要的包的前提下, 抓取長度越小越好.把snaplen 設置爲0 意味着讓tcpdump自動選擇合適的長度來抓取數據包. -T type 強制tcpdump按type指定的協議所描述的包結構來分析收到的數據包. 目前已知的type 可取的協議爲: aodv (Ad-hoc On-demand Distance Vector protocol, 按需距離向量路由協議, 在Ad hoc(點對點模式)網絡中使用), cnfp (Cisco NetFlow protocol), rpc(Remote Procedure Call), rtp (Real-Time Applications protocol), rtcp (Real-Time Applications con-trol protocol), snmp (Simple Network Management Protocol), tftp (Trivial File Transfer Protocol, 碎文件協議), vat (Visual Audio Tool, 可用於在internet 上進行電 視電話會議的應用層協議), 以及wb (distributed White Board, 可用於網絡會議的應用層協議). -t 在每行輸出中不打印時間戳 -tt 不對每行輸出的時間進行格式處理(nt: 這種格式一眼可能看不出其含義, 如時間戳打印成1261798315) -ttt tcpdump 輸出時, 每兩行打印之間會延遲一個段時間(以毫秒爲單位) -tttt 在每行打印的時間戳以前添加日期的打印 -u 打印出未加密的NFS 句柄(nt: handle可理解爲NFS 中使用的文件句柄, 這將包括文件夾和文件夾中的文件) -U 使得當tcpdump在使用-w 選項時, 其文件寫入與包的保存同步.(nt: 即, 當每一個數據包被保存時, 它將及時被寫入文件中,而不是等文件的輸出緩衝已滿時才真正寫入此文件) -U 標誌在老版本的libcap庫(nt: tcpdump 所依賴的報文捕獲庫)上不起做用, 由於其中缺少pcap_cump_flush()函數. -v 當分析和打印的時候, 產生詳細的輸出. 好比, 包的生存時間, 標識, 總長度以及IP包的一些選項. 這也會打開一些附加的包完整性檢測, 好比對IP或ICMP包頭部的校驗和. -vv 產生比-v更詳細的輸出. 好比, NFS迴應包中的附加域將會被打印, SMB數據包也會被徹底解碼. -vvv 產生比-vv更詳細的輸出. 好比, telent 時所使用的SB, SE 選項將會被打印, 若是telnet同時使用的是圖形界面, 其相應的圖形選項將會以16進制的方式打印出來(nt: telnet 的SB,SE選項含義未知, 另需補充). -w 把包數據直接寫入文件而不進行分析和打印輸出. 這些包數據可在隨後經過-r 選項來從新讀入並進行分析和打印. -W filecount 此選項與-C 選項配合使用, 這將限制可打開的文件數目, 而且當文件數據超過這裏設置的限制時, 依次循環替代以前的文件, 這至關於一個擁有filecount 個文件的文件緩衝池. 同時, 該選項會使得每一個文件名的開頭會出現足夠多並用來佔位的0, 這能夠方便這些文件被正確的排序. -x 當分析和打印時, tcpdump 會打印每一個包的頭部數據, 同時會以16進制打印出每一個包的數據(但不包括鏈接層的頭部).總共打印的數據大小不會超過整個數據包的大小與snaplen 中的最小值. 必需要注意的是, 若是高層協議數據沒有snaplen 這麼長,而且數據鏈路層(好比, Ethernet層)有填充數據, 則這些填充數據也會被打印.(nt: so link layers that pad, 未能銜接理解和翻譯, 需補充 ) -xx tcpdump 會打印每一個包的頭部數據, 同時會以16進制打印出每一個包的數據, 其中包括數據鏈路層的頭部. -X 當分析和打印時, tcpdump 會打印每一個包的頭部數據, 同時會以16進制和ASCII碼形式打印出每一個包的數據(但不包括鏈接層的頭部).這對於分析一些新協議的數據包很方便. -XX 當分析和打印時, tcpdump 會打印每一個包的頭部數據, 同時會以16進制和ASCII碼形式打印出每一個包的數據, 其中包括數據鏈路層的頭部.這對於分析一些新協議的數據包很方便. -y datalinktype 設置tcpdump 只捕獲數據鏈路層協議類型是datalinktype的數據包 -Z user 使tcpdump 放棄本身的超級權限(若是以root用戶啓動tcpdump, tcpdump將會有超級用戶權限), 並把當前tcpdump的用戶ID設置爲user, 組ID設置爲user首要所屬組的ID(nt: tcpdump 此處可理解爲tcpdump 運行以後對應的進程) 此選項也可在編譯的時候被設置爲默認打開.(nt: 此時user 的取值未知, 需補充)
默認啓動ios
tcpdump
普通狀況下，直接啓動tcpdump將監視第一個網絡接口上全部流過的數據包。git
監視指定網絡接口的數據包web
tcpdump -i eth1
若是不指定網卡，默認tcpdump只會監視第一個網絡接口，通常是eth0，下面的例子都沒有指定網絡接口。 正則表達式
監視指定主機的數據包算法
打印全部進入或離開sundown的數據包.shell
tcpdump host sundown
也能夠指定ip,例如截獲全部210.27.48.1 的主機收到的和發出的全部的數據包express
tcpdump host 210.27.48.1
打印helios 與 hot 或者與 ace 之間通訊的數據包windows
tcpdump host helios and \( hot or ace \)
截獲主機210.27.48.1 和主機210.27.48.2 或210.27.48.3的通訊緩存
tcpdump host 210.27.48.1 and \ (210.27.48.2 or 210.27.48.3 \)
打印ace與任何其餘主機之間通訊的IP 數據包, 但不包括與helios之間的數據包.
tcpdump ip host ace and not helios
若是想要獲取主機210.27.48.1除了和主機210.27.48.2以外全部主機通訊的ip包，使用命令：
tcpdump ip host 210.27.48.1 and ! 210.27.48.2
截獲主機hostname發送的全部數據
tcpdump -i eth0 src host hostname
監視全部送到主機hostname的數據包
tcpdump -i eth0 dst host hostname
監視指定主機和端口的數據包
若是想要獲取主機210.27.48.1接收或發出的telnet包，使用以下命令
tcpdump tcp port 23 and host 210.27.48.1
對本機的udp 123 端口進行監視 123 爲ntp的服務端口
tcpdump udp port 123
監視指定網絡的數據包
打印本地主機與Berkeley網絡上的主機之間的全部通訊數據包(nt: ucb-ether, 此處可理解爲'Berkeley網絡'的網絡地址,此表達式最原始的含義可表達爲: 打印網絡地址爲ucb-ether的全部數據包)
tcpdump net ucb-ether
打印全部經過網關snup的ftp數據包(注意, 表達式被單引號括起來了, 這能夠防止shell對其中的括號進行錯誤解析)
tcpdump 'gateway snup and (port ftp or ftp-data)'
打印全部源地址或目標地址是本地主機的IP數據包
(若是本地網絡經過網關連到了另外一網絡, 則另外一網絡並不能算做本地網絡.(nt: 此句翻譯曲折,需補充).localnet 實際使用時要真正替換成本地網絡的名字)
tcpdump ip and not net localnet
監視指定協議的數據包
打印TCP會話中的的開始和結束數據包, 而且數據包的源或目的不是本地網絡上的主機.(nt: localnet, 實際使用時要真正替換成本地網絡的名字))
tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net localnet'
打印全部源或目的端口是80, 網絡層協議爲IPv4, 而且含有數據,而不是SYN,FIN以及ACK-only等不含數據的數據包.(ipv6的版本的表達式可作練習)
tcpdump 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'
(nt: 可理解爲, ip[2:2]表示整個ip數據包的長度, (ip[0]&0xf)<<2)表示ip數據包包頭的長度(ip[0]&0xf表明包中的IHL域, 而此域的單位爲32bit, 要換算
成字節數須要乘以4, 即左移2. (tcp[12]&0xf0)>>4 表示tcp頭的長度, 此域的單位也是32bit, 換算成比特數爲 ((tcp[12]&0xf0) >> 4) << ２,
即 ((tcp[12]&0xf0)>>2). ((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0 表示: 整個ip數據包的長度減去ip頭的長度,再減去
tcp頭的長度不爲0, 這就意味着, ip數據包中確實是有數據.對於ipv6版本只需考慮ipv6頭中的'Payload Length' 與 'tcp頭的長度'的差值, 而且其中表達方式'ip[]'需換成'ip6[]'.)
打印長度超過576字節, 而且網關地址是snup的IP數據包
tcpdump 'gateway snup and ip[2:2] > 576'
打印全部IP層廣播或多播的數據包， 但不是物理以太網層的廣播或多播數據報
tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'
打印除'echo request'或者'echo reply'類型之外的ICMP數據包( 好比,須要打印全部非ping 程序產生的數據包時可用到此表達式 .
(nt: 'echo reuqest' 與 'echo reply' 這兩種類型的ICMP數據包一般由ping程序產生))
tcpdump 'icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply'
tcpdump 與wireshark
Wireshark(之前是ethereal)是Windows下很是簡單易用的抓包工具。但在Linux下很難找到一個好用的圖形化抓包工具。
還好有Tcpdump。咱們能夠用Tcpdump + Wireshark 的完美組合實現：在 Linux 裏抓包，而後在Windows 裏分析包。
tcpdump tcp -i eth1 -t -s 0 -c 100 and dst port ! 22 and src net 192.168.1.0/24 -w ./target.cap
(1)tcp: ip icmp arp rarp 和 tcp、udp、icmp這些選項等都要放到第一個參數的位置，用來過濾數據報的類型
(2)-i eth1 : 只抓通過接口eth1的包
(3)-t : 不顯示時間戳
(4)-s 0 : 抓取數據包時默認抓取長度爲68字節。加上-S 0 後能夠抓到完整的數據包
(5)-c 100 : 只抓取100個數據包
(6)dst port ! 22 : 不抓取目標端口是22的數據包
(7)src net 192.168.1.0/24 : 數據包的源網絡地址爲192.168.1.0/24
(8)-w ./target.cap : 保存成cap文件，方便用ethereal(即wireshark)分析
使用tcpdump抓取HTTP包
tcpdump -XvvennSs 0 -i eth0 tcp[20:2]=0x4745 or tcp[20:2]=0x4854
0x4745 爲"GET"前兩個字母"GE",0x4854 爲"HTTP"前兩個字母"HT"。
tcpdump 對截獲的數據並無進行完全解碼，數據包內的大部份內容是使用十六進制的形式直接打印輸出的。顯然這不利於分析網絡故障，一般的解決辦法是先使用帶-w參數的tcpdump 截獲數據並保存到文件中，而後再使用其餘程序(如Wireshark)進行解碼分析。固然也應該定義過濾規則，以免捕獲的數據包填滿整個硬盤。
輸出信息含義
首先咱們注意一下，基本上tcpdump總的的輸出格式爲：系統時間 來源主機.端口 > 目標主機.端口 數據包參數
tcpdump 的輸出格式與協議有關.如下簡要描述了大部分經常使用的格式及相關例子.
鏈路層頭
對於FDDI網絡, '-e' 使tcpdump打印出指定數據包的'frame control' 域, 源和目的地址, 以及包的長度.(frame control域
控制對包中其餘域的解析). 通常的包(好比那些IP datagrams)都是帶有'async'(異步標誌)的數據包，而且有取值0到7的優先級;
好比 'async4'就表明此包爲異步數據包，而且優先級別爲4. 一般認爲,這些包們會內含一個 LLC包(邏輯鏈路控制包); 這時,若是此包
不是一個ISO datagram或所謂的SNAP包，其LLC頭部將會被打印(nt:應該是指此包內含的 LLC包的包頭).
對於Token Ring網絡(令牌環網絡), '-e' 使tcpdump打印出指定數據包的'frame control'和'access control'域, 以及源和目的地址,
外加包的長度. 與FDDI網絡相似, 此數據包一般內含LLC數據包. 無論 是否有'-e'選項.對於此網絡上的'source-routed'類型數據包(nt:
意譯爲:源地址被追蹤的數據包,具體含義未知,需補充), 其包的源路由信息總會被打印.
對於802.11網絡(WLAN,即wireless local area network), '-e' 使tcpdump打印出指定數據包的'frame control域,
包頭中包含的全部地址, 以及包的長度.與FDDI網絡相似, 此數據包一般內含LLC數據包.
(注意: 如下的描述會假設你熟悉SLIP壓縮算法 (nt:SLIP爲Serial Line Internet Protocol.), 這個算法能夠在
RFC-1144中找到相關的蛛絲馬跡.)
對於SLIP網絡(nt:SLIP links, 可理解爲一個網絡, 即經過串行線路創建的鏈接, 而一個簡單的鏈接也可當作一個網絡),
數據包的'direction indicator'('方向指示標誌')("I"表示入, "O"表示出), 類型以及壓縮信息將會被打印. 包類型會被首先打印.
類型分爲ip, utcp以及ctcp(nt:未知, 需補充). 對於ip包,鏈接信息將不被打印(nt:SLIP鏈接上,ip包的鏈接信息可能無用或沒有定義.
reconfirm).對於TCP數據包, 鏈接標識緊接着類型表示被打印. 若是此包被壓縮, 其被編碼過的頭部將被打印.
此時對於特殊的壓縮包,會以下顯示:
*S+n 或者 *SA+n, 其中n表明包的(順序號或(順序號和應答號))增長或減小的數目(nt | rt:S,SA拗口, 需再譯).
對於非特殊的壓縮包,0個或更多的'改變'將會被打印.'改變'被打印時格式以下:
'標誌'+/-/=n 包數據的長度 壓縮的頭部長度.
其中'標誌'能夠取如下值:
U(表明緊急指針), W(指緩衝窗口), A(應答), S(序列號), I(包ID),而增量表達'=n'表示被賦予新的值, +/-表示增長或減小.
好比, 如下顯示了對一個外發壓縮TCP數據包的打印, 這個數據包隱含一個鏈接標識(connection identifier); 應答號增長了6,
順序號增長了49, 包ID號增長了6; 包數據長度爲3字節(octect), 壓縮頭部爲6字節.(nt:如此看來這應該不是一個特殊的壓縮數據包).
ARP/RARP 數據包
tcpdump對Arp/rarp包的輸出信息中會包含請求類型及該請求對應的參數. 顯示格式簡潔明瞭. 如下是從主機rtsg到主機csam的'rlogin'
(遠程登陸)過程開始階段的數據包樣例:
arp who-has csam tell rtsg
arp reply csam is-at CSAM
第一行表示:rtsg發送了一個arp數據包(nt:向全網段發送,arp數據包）以詢問csam的以太網地址
Csam（nt:可從下文看出來, 是Csam）以她本身的以太網地址作了迴應(在這個例子中, 以太網地址以大寫的名字標識, 而internet
地址(即ip地址)以所有的小寫名字標識).
若是使用tcpdump -n, 能夠清晰看到以太網以及ip地址而不是名字標識:
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
第一個數據包代表:以arp包的源以太地址是RTSG, 目標地址是全以太網段, type域的值爲16進制0806(表示ETHER_ARP(nt:arp包的類型標識)),
包的總長度爲64字節.
TCP 數據包
(注意:如下將會假定你對 RFC-793所描述的TCP熟悉. 若是不熟, 如下描述以及tcpdump程序可能對你幫助不大.(nt:警告可忽略,
只需繼續看, 不熟悉的地方可回頭再看.).
一般tcpdump對tcp數據包的顯示格式以下:
src > dst: flags data-seqno ack window urgent options
src 和 dst 是源和目的IP地址以及相應的端口. flags 標誌由S(SYN), F(FIN), P(PUSH, R(RST),
W(ECN CWT(nt | rep:未知, 需補充))或者 E(ECN-Echo(nt | rep:未知, 需補充))組成,
單獨一個'.'表示沒有flags標識. 數據段順序號(Data-seqno)描述了此包中數據所對應序列號空間中的一個位置(nt:整個數據被分段,
每段有一個順序號, 全部的順序號構成一個序列號空間)(可參考如下例子). Ack 描述的是同一個鏈接,同一個方向,下一個本端應該接收的
(對方應該發送的)數據片斷的順序號. Window是本端可用的數據接收緩衝區的大小(也是對方發送數據時需根據這個大小來組織數據).
Urg(urgent) 表示數據包中有緊急的數據. options 描述了tcp的一些選項, 這些選項都用尖括號來表示(如 <mss 1024>).
src, dst 和 flags 這三個域老是會被顯示. 其餘域的顯示與否依賴於tcp協議頭裏的信息.
這是一個從trsg到csam的一個rlogin應用登陸的開始階段.
rtsg.1023 > csam.login: S 768512:768512(0) win 4096 <mss 1024>
csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096 <mss 1024>
rtsg.1023 > csam.login: . ack 1 win 4096
rtsg.1023 > csam.login: P 1:2(1) ack 1 win 4096
csam.login > rtsg.1023: . ack 2 win 4096
rtsg.1023 > csam.login: P 2:21(19) ack 1 win 4096
csam.login > rtsg.1023: P 1:2(1) ack 21 win 4077
csam.login > rtsg.1023: P 2:3(1) ack 21 win 4077 urg 1
csam.login > rtsg.1023: P 3:4(1) ack 21 win 4077 urg 1
第一行表示有一個數據包從rtsg主機的tcp端口1023發送到了csam主機的tcp端口login上(nt:udp協議的端口和tcp協議的端
口是分別的兩個空間, 雖然取值範圍一致). S表示設置了SYN標誌. 包的順序號是768512, 而且沒有包含數據.(表示格式
爲:'first:last(nbytes)', 其含義是'此包中數據的順序號從first開始直到last結束，不包括last. 而且總共包含nbytes的
用戶數據'.) 沒有捎帶應答(nt:從下文來看，第二行纔是有捎帶應答的數據包), 可用的接受窗口的大小爲4096bytes, 而且請求端(rtsg)
的最大可接受的數據段大小是1024字節(nt:這個信息做爲請求發向應答端csam, 以便雙方進一步的協商).
Csam 向rtsg 回覆了基本相同的SYN數據包, 其區別只是多了一個' piggy-backed ack'(nt:捎帶回的ack應答, 針對rtsg的SYN數據包).
rtsg 一樣針對csam的SYN數據包回覆了一ACK數據包做爲應答. '.'的含義就是此包中沒有標誌被設置. 因爲此應答包中不含有數據, 因此
包中也沒有數據段序列號. 提醒! 此ACK數據包的順序號只是一個小整數1. 有以下解釋:tcpdump對於一個tcp鏈接上的會話, 只打印會話兩端的
初始數據包的序列號,其後相應數據包只打印出與初始包序列號的差別.即初始序列號以後的序列號, 可被看做此會話上當前所傳數據片斷在整個
要傳輸的數據中的'相對字節'位置(nt:雙方的第一個位置都是1, 即'相對字節'的開始編號). '-Ｓ'將覆蓋這個功能,
使數據包的原始順序號被打印出來.
第六行的含義爲:rtsg 向 csam發送了19字節的數據(字節的編號爲2到20，傳送方向爲rtsg到csam). 包中設置了PUSH標誌. 在第7行,
csam 喊到， 她已經從rtsg中收到了21如下的字節, 但不包括21編號的字節. 這些字節存放在csam的socket的接收緩衝中, 相應地,
csam的接收緩衝窗口大小會減小19字節(nt:能夠從第5行和第7行win屬性值的變化看出來). csam在第7行這個包中也向rtsg發送了一個
字節. 在第8行和第9行, csam 繼續向rtsg 分別發送了兩個只包含一個字節的數據包, 而且這個數據包帶PUSH標誌.
若是所抓到的tcp包(nt:即這裏的snapshot)過小了，以致tcpdump沒法完整獲得其頭部數據, 這時, tcpdump會盡可能解析這個不完整的頭,
並把剩下不能解析的部分顯示爲'[|tcp]'. 若是頭部含有虛假的屬性信息(好比其長度屬性其實比頭部實際長度長或短), tcpdump會爲該頭部
顯示'[bad opt]'. 若是頭部的長度告訴咱們某些選項(nt | rt:從下文來看， 指tcp包的頭部中針對ip包的一些選項, 回頭再翻)會在此包中,
而真正的IP(數據包的長度又不夠容納這些選項, tcpdump會顯示'[bad hdr length]'.
抓取帶有特殊標誌的的TCP包(如SYN-ACK標誌, URG-ACK標誌等).
在TCP的頭部中, 有8比特(bit)用做控制位區域, 其取值爲:
CWR | ECE | URG | ACK | PSH | RST | SYN | FIN
(nt | rt:從表達方式上可推斷:這8個位是用或的方式來組合的, 可回頭再翻)
現假設咱們想要監控創建一個TCP鏈接整個過程當中所產生的數據包. 可回憶以下:TCP使用3次握手協議來創建一個新的鏈接; 其與此三次握手
鏈接順序對應，並帶有相應TCP控制標誌的數據包以下:
1) 鏈接發起方(nt:Caller)發送SYN標誌的數據包
2) 接收方(nt:Recipient)用帶有SYN和ACK標誌的數據包進行迴應
3) 發起方收到接收方迴應後再發送帶有ACK標誌的數據包進行迴應
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個字節(nt | rt:options 理解爲選項數據，需回譯). 第一行包含0到3編號的字節,
第二行包含編號4-7的字節.
若是編號從0開始算, TCP控制標誌位於13字節(nt:第四行左半部分).
0 7| 15| 23| 31
----------------|---------------|---------------|----------------
| HL | rsvd |C|E|U|A|P|R|S|F| window size |
----------------|---------------|---------------|----------------
| | 13th octet | | |
讓咱們仔細看看編號13的字節:
| |
|---------------|
|C|E|U|A|P|R|S|F|
|---------------|
|7 5 3 0|
這裏有咱們感興趣的控制標誌位. 從右往左這些位被依次編號爲0到7, 從而 PSH位在3號, 而URG位在5號.
提醒一下本身, 咱們只是要獲得包含SYN標誌的數據包. 讓咱們看看在一個包的包頭中, 若是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(bit number 1)被置位.
假設編號爲13的字節是一個8位的無符號字符型,而且按照網絡字節號排序(nt:對於一個字節來講，網絡字節序等同於主機字節序), 其二進制值
以下所示:
00000010
而且其10進制值爲:
0*2^7 + 0*2^6 + 0*2^5 + 0*2^4 + 0*2^3 + 0*2^2 + 1*2^1 + 0*2^0 = 2(nt: 1 * 2^6 表示1乘以2的6次方, 也許這樣更
清楚些, 即把原來表達中的指數7 6 ... 0挪到了下面來表達)
接近目標了, 由於咱們已經知道, 若是數據包頭部中的SYN被置位, 那麼頭部中的第13個字節的值爲2(nt: 按照網絡序, 即大頭方式, 最重要的字節
在前面(在前面,即該字節實際內存地址比較小, 最重要的字節,指數學表示中數的高位, 如356中的3) ).
表達爲tcpdump能理解的關係式就是:
tcp[13] 2
從而咱們能夠把此關係式看成tcpdump的過濾條件, 目標就是監控只含有SYN標誌的數據包:
tcpdump -i xl0 tcp[13] 2 (nt: xl0 指網絡接口, 如eth0)
這個表達式是說"讓TCP數據包的第13個字節擁有值2吧", 這也是咱們想要的結果.
如今, 假設咱們須要抓取帶SYN標誌的數據包, 而忽略它是否包含其餘標誌.(nt:只要帶SYN就是咱們想要的). 讓咱們來看看當一個含有
SYN-ACK的數據包(nt:SYN 和 ACK 標誌都有), 來到時發生了什麼:
|C|E|U|A|P|R|S|F|
|---------------|
|0 0 0 1 0 0 1 0|
|---------------|
|7 6 5 4 3 2 1 0|
13號字節的1號和4號位被置位, 其二進制的值爲:
00010010
轉換成十進制就是:
0*2^7 + 0*2^6 + 0*2^5 + 1*2^4 + 0*2^3 + 0*2^2 + 1*2^1 + 0*2 = 18(nt: 1 * 2^6 表示1乘以2的6次方, 也許這樣更
清楚些, 即把原來表達中的指數7 6 ... 0挪到了下面來表達)
如今, 卻不能只用'tcp[13] 18'做爲tcpdump的過濾表達式, 由於這將致使只選擇含有SYN-ACK標誌的數據包, 其餘的都被丟棄.
提醒一下本身, 咱們的目標是: 只要包的SYN標誌被設置就行, 其餘的標誌咱們不理會.
爲了達到咱們的目標, 咱們須要把13號字節的二進制值與其餘的一個數作AND操做(nt:邏輯與)來獲得SYN比特位的值. 目標是:只要SYN 被設置
就行, 因而咱們就把她與上13號字節的SYN值(nt: 00000010).
00010010 SYN-ACK 00000010 SYN
AND 00000010 (we want SYN) AND 00000010 (we want SYN)
-------- --------
= 00000010 = 00000010
咱們能夠發現, 無論包的ACK或其餘標誌是否被設置, 以上的AND操做都會給咱們相同的值, 其10進製表達就是2(2進製表達就是00000010).
從而咱們知道, 對於帶有SYN標誌的數據包, 如下的表達式的結果老是真(true):
( ( value of octet 13 ) AND ( 2 ) ) ( 2 ) (nt: value of octet 13, 即13號字節的值)
靈感隨之而來, 咱們因而獲得了以下的tcpdump 的過濾表達式
tcpdump -i xl0 'tcp[13] & 2 2'
注意, 單引號或反斜杆(nt: 這裏用的是單引號)不能省略, 這能夠防止shell對&的解釋或替換.
UDP 數據包
UDP 數據包的顯示格式，可經過rwho這個具體應用所產生的數據包來講明:
actinide.who > broadcast.who: udp 84
其含義爲:actinide主機上的端口who向broadcast主機上的端口who發送了一個udp數據包(nt: actinide和broadcast都是指Internet地址).
這個數據包承載的用戶數據爲84個字節.
一些UDP服務可從數據包的源或目的端口來識別，也可從所顯示的更高層協議信息來識別. 好比, Domain Name service requests(DNS 請求,
在RFC-1034/1035中), 和Sun RPC calls to NFS(對NFS服務器所發起的遠程調用(nt: 即Sun RPC)，在RFC-1050中有對遠程調用的描述).
UDP 名稱服務請求
(注意:如下的描述假設你對Domain Service protoco(nt:在RFC-103中有所描述), 不然你會發現如下描述就是天書(nt:希臘文天書,
沒必要理會, 嚇嚇你的, 接着看就行))
名稱服務請求有以下的格式:
src > dst: id op? flags qtype qclass name (len)
(nt: 從下文來看, 格式應該是src > dst: id op flags qtype qclass? name (len))
好比有一個實際顯示爲:
h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)
主機h2opolo 向helios 上運行的名稱服務器查詢ucbvax.berkeley.edu 的地址記錄(nt: qtype等於A). 此查詢自己的id號爲'3'. 符號
'+'意味着遞歸查詢標誌被設置(nt: dns服務器可向更高層dns服務器查詢本服務器不包含的地址記錄). 這個最終經過IP包發送的查詢請求
數據長度爲37字節, 其中不包括UDP和IP協議的頭數據. 由於此查詢操做爲默認值(nt | rt: normal one的理解), op字段被省略.
若是op字段沒被省略, 會被顯示在'3' 和'+'之間. 一樣, qclass也是默認值, C_IN, 從而也沒被顯示, 若是沒被忽略, 她會被顯示在'A'以後.
異常檢查會在方括中顯示出附加的域: 若是一個查詢同時包含一個迴應(nt: 可理解爲, 對以前其餘一個請求的迴應), 而且此迴應包含權威或附加記錄段,
ancount, nscout, arcount(nt: 具體字段含義需補充) 將被顯示爲'[na]', '[nn]', '[nau]', 其中n表明合適的計數. 若是包中如下
迴應位(好比AA位, RA位, rcode位), 或者字節2或3中任何一個'必須爲0'的位被置位(nt: 設置爲1), '[b2&3]=x' 將被顯示, 其中x表示
頭部字節2與字節3進行與操做後的值.
UDP 名稱服務應答
對名稱服務應答的數據包，tcpdump會有以下的顯示格式
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 所發送的3號查詢請求迴應了3條回答記錄(nt | rt: answer records), 3條名稱服務器記錄,
以及7條附加的記錄. 第一個回答記錄(nt: 3個回答記錄中的第一個)類型爲A(nt: 表示地址), 其數據爲internet地址128.32.137.3.
此迴應UDP數據包, 包含273字節的數據(不包含UPD和IP的頭部數據). op字段和rcode字段被忽略(nt: op的實際值爲Query, rcode, 即
response code的實際值爲NoError), 一樣被忽略的字段還有class 字段(nt | rt: 其值爲C_IN, 這也是A類型記錄默認取值)
第二行表示: helios 對h2opolo 所發送的2號查詢請求作了迴應. 迴應中, rcode編碼爲NXDomain(nt: 表示不存在的域)), 沒有回答記錄,
但包含一個名稱服務器記錄, 不包含權威服務器記錄(nt | ck: 從上文來看, 此處的authority records 就是上文中對應的additional
records). '*'表示權威服務器回答標誌被設置(nt: 從而additional records就表示的是authority records).
因爲沒有回答記錄, type, class, data字段都被忽略.
flag字段還有可能出現其餘一些字符, 好比'-'(nt: 表示可遞歸地查詢, 即RA 標誌沒有被設置), '|'(nt: 表示被截斷的消息, 即TC 標誌
被置位). 若是應答(nt | ct: 可理解爲, 包含名稱服務應答的UDP數據包, tcpdump知道這類數據包該怎樣解析其數據)的'question'段一個條
目(entry)都不包含(nt: 每一個條目的含義, 需補充),'[nq]' 會被打印出來.
要注意的是:名稱服務器的請求和應答數據量比較大, 而默認的68字節的抓取長度(nt: snaplen, 可理解爲tcpdump的一個設置選項)可能不足以抓取
數據包的所有內容. 若是你真的須要仔細查看名稱服務器的負載, 能夠經過tcpdump 的-s 選項來擴大snaplen值.
SMB/CIFS 解碼
tcpdump 已能夠對SMB/CIFS/NBT相關應用的數據包內容進行解碼(nt: 分別爲'Server Message Block Common', 'Internet File System'
'在TCP/IP上實現的網絡協議NETBIOS的簡稱'. 這幾個服務一般使用UDP的137/138以及TCP的139端口). 原來的對IPX和NetBEUI SMB數據包的
解碼能力依然能夠被使用(nt: NetBEUI爲NETBIOS的加強版本).
tcpdump默認只按照最簡約模式對相應數據包進行解碼, 若是咱們想要詳盡的解碼信息可使用其-v 啓動選現. 要注意的是, -v 會產生很是詳細的信息,
好比對單一的一個SMB數據包, 將產生一屏幕或更多的信息, 因此此選項, 確有須要才使用.
關於SMB數據包格式的信息, 以及每一個域的含義能夠參看www.cifs.org 或者samba.org 鏡像站點的pub/samba/specs/ 目錄. linux 上的SMB 補丁
(nt | rt: patch)由 Andrew Tridgell (tridge@samba.org)提供.
NFS 請求和迴應
tcpdump對Sun NFS(網絡文件系統)請求和迴應的UDP數據包有以下格式的打印輸出:
src.xid > dst.nfs: len op args
src.nfs > dst.xid: reply stat len op results
如下是一組具體的輸出數據
sushi.6709 > wrl.nfs: 112 readlink fh 21,24/10.73165
wrl.nfs > sushi.6709: reply ok 40 readlink "../var"
sushi.201b > wrl.nfs:
144 lookup fh 9,74/4096.6878 "xcolors"
wrl.nfs > sushi.201b:
reply ok 128 lookup fh 9,74/4134.3150
第一行輸出代表: 主機sushi向主機wrl發送了一個'交換請求'(nt: transaction), 此請求的id爲6709(注意, 主機名字後是交換
請求id號, 而不是源端口號). 此請求數據爲112字節, 其中不包括UDP和IP頭部的長度. 操做類型爲readlink(nt: 即此操做爲讀符號連接操做),
操做參數爲fh 21,24/10.73165(nt: 可按實際運行環境, 解析以下, fd 表示描述的爲文件句柄, 21,24 表示此句柄所對應設
備的主/從設備號對, 10表示此句柄所對應的i節點編號(nt:每一個文件都會在操做系統中對應一個i節點, 限於unix類系統中),
73165是一個編號(nt: 可理解爲標識此請求的一個隨機數, 具體含義需補充)).
第二行中, wrl 作了'ok'的迴應, 而且在results 字段中返回了sushi想要讀的符號鏈接的真實目錄(nt: 即sushi要求讀的符號鏈接實際上是一個目錄).
第三行代表: sushi 再次請求 wrl 在'fh 9,74/4096.6878'所描述的目錄中查找'xcolors'文件. 須要注意的是, 每行所顯示的數據含義依賴於其中op字段的
類型(nt: 不一樣op 所對應args 含義不相同), 其格式遵循NFS 協議, 追求簡潔明瞭.
若是tcpdump 的-v選項(詳細打印選項) 被設置, 附加的信息將被顯示. 好比:
sushi.1372a > wrl.nfs:
148 read fh 21,11/12.195 8192 bytes @ 24576
wrl.nfs > sushi.1372a:
reply ok 1472 read REG 100664 ids 417/0 sz 29388
(-v 選項通常還會打印出IP頭部的TTL, ID， length, 以及fragmentation 域, 但在此例中, 都略過了(nt: 可理解爲,簡潔起見, 作了刪減))
在第一行, sushi 請求wrl 從文件 21,11/12.195(nt: 格式在上面有描述)中, 自偏移24576字節處開始, 讀取8192字節數據.
Wrl 迴應讀取成功; 因爲第二行只是迴應請求的開頭片斷, 因此只包含1472字節(其餘的數據將在接着的reply片斷中到來, 但這些數據包不會再有NFS
頭, 甚至UDP頭信息也爲空(nt: 源和目的應該要有), 這將致使這些片斷不能知足過濾條件, 從而沒有被打印). -v 選項除了顯示文件數據信息, 還會顯示
附加顯示文件屬性信息: file type(文件類型, ''REG'' 表示普通文件), file mode(文件存取模式, 8進製表示的), uid 和gid(nt: 文件屬主和
組屬主), file size (文件大小).
若是-v 標誌被屢次重複給出(nt: 如-vv)， tcpdump會顯示更加詳細的信息.
必需要注意的是, NFS 請求包中數據比較多, 若是tcpdump 的snaplen(nt: 抓取長度) 取過短將不能顯示其詳細信息. 可以使用
'-s 192'來增長snaplen, 這可用以監測NFS應用的網絡負載(nt: traffic).
NFS 的迴應包並不嚴格的緊隨以前相應的請求包(nt: RPC operation). 從而, tcpdump 會跟蹤最近收到的一系列請求包, 再經過其
交換序號(nt: transaction ID)與相應請求包相匹配. 這可能產生一個問題， 若是迴應包來得太遲, 超出tcpdump 對相應請求包的跟蹤範圍,
該回應包將不能被分析.
AFS 請求和迴應
AFS(nt: Andrew 文件系統, Transarc , 未知, 需補充)請求和迴應有以下的答應
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 向pike 發送了一個RX數據包.
這是一個對於文件服務的請求數據包(nt: RX data packet, 發送數據包 , 可理解爲發送包過去, 從而請求對方的服務), 這也是一個RPC
調用的開始(nt: RPC, remote procedure call). 此RPC 請求pike 執行rename(nt: 重命名) 操做, 並指定了相關的參數:
原目錄描述符爲536876964/1/1, 原文件名爲 '.newsrc.new', 新目錄描述符爲536876964/1/1, 新文件名爲 '.newsrc'.
主機pike 對此rename操做的RPC請求做了迴應(迴應表示rename操做成功, 由於迴應的是包含數據內容的包而不是異常包).
通常來講, 全部的'AFS RPC'請求被顯示時, 會被冠以一個名字(nt: 即decode, 解碼), 這個名字每每就是RPC請求的操做名.
而且, 這些RPC請求的部分參數在顯示時, 也會被冠以一個名字(nt | rt: 即decode, 解碼, 通常來講也是取名也很直接, 好比,
一個interesting 參數, 顯示的時候就會直接是'interesting', 含義拗口, 需再翻).
這種顯示格式的設計初衷爲'一看就懂', 但對於不熟悉AFS 和 RX 工做原理的人可能不是很
有用(nt: 仍是不用管, 書面嚇嚇你的, 往下看就行).
若是 -v(詳細)標誌被重複給出(nt: 如-vv), tcpdump 會打印出確認包(nt: 可理解爲, 與應答包有區別的包)以及附加頭部信息
(nt: 可理解爲, 全部包, 而不只僅是確認包的附加頭部信息), 好比, RX call ID(請求包中'請求調用'的ID),
call number('請求調用'的編號), sequence number(nt: 包順序號),
serial number(nt | rt: 可理解爲與包中數據相關的另外一個順信號, 具體含義需補充), 請求包的標識. (nt: 接下來一段爲重複描述,
因此略去了), 此外確認包中的MTU協商信息也會被打印出來(nt: 確認包爲相對於請求包的確認包, Maximum Transmission Unit, 最大傳輸單元).
若是 -v 選項被重複了三次(nt: 如-vvv), 那麼AFS應用類型數據包的'安全索引'('security index')以及'服務索引'('service id')將會
被打印.
對於表示異常的數據包(nt: abort packet, 可理解爲, 此包就是用來通知接受者某種異常已發生), tcpdump 會打印出錯誤號(error codes).
但對於Ubik beacon packets(nt: Ubik 燈塔指示包, Ubik可理解爲特殊的通訊協議, beacon packets, 燈塔數據包, 可理解爲指明通訊中
關鍵信息的一些數據包), 錯誤號不會被打印, 由於對於Ubik 協議, 異常數據包不是表示錯誤, 相反倒是表示一種確定應答(nt: 即, yes vote).
AFS 請求數據量大, 參數也多, 因此要求tcpdump的 snaplen 比較大, 通常可經過啓動tcpdump時設置選項'-s 256' 來增大snaplen, 以
監測AFS 應用通訊負載.
AFS 迴應包並不顯示標識RPC 屬於何種遠程調用. 從而, tcpdump 會跟蹤最近一段時間內的請求包, 並經過call number(調用編號), service ID
(服務索引) 來匹配收到的迴應包. 若是迴應包不是針對最近一段時間內的請求包, tcpdump將沒法解析該包.
KIP AppleTalk協議
(nt | rt: DDP in UDP可理解爲, DDP, The AppleTalk Data Delivery Protocol,
至關於支持KIP AppleTalk協議棧的網絡層協議, 而DDP 自己又是經過UDP來傳輸的,
即在UDP 上實現的用於其餘網絡的網絡層，KIP AppleTalk是蘋果公司開發的整套網絡協議棧).
AppleTalk DDP 數據包被封裝在UDP數據包中, 其解封裝(nt: 至關於解碼)和相應信息的轉儲也遵循DDP 包規則.
(nt:encapsulate, 封裝, 至關於編碼, de-encapsulate, 解封裝, 至關於解碼, dump, 轉儲, 一般就是指對其信息進行打印).
/etc/atalk.names 文件中包含了AppleTalk 網絡和節點的數字標識到名稱的對應關係. 其文件格式一般以下所示:
number name
1.254 ether
16.1 icsd-net
1.254.110 ace
頭兩行表示有兩個AppleTalk 網絡. 第三行給出了特定網絡上的主機(一個主機會用3個字節來標識,
而一個網絡的標識一般只有兩個字節, 這也是二者標識的主要區別)(nt: 1.254.110 可理解爲ether網絡上的ace主機).
標識與其對應的名字之間必需要用空白分開. 除了以上內容, /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上的節點209經過2端口,向網絡icsd-net上監聽在220端口的112節點發送了一個NBP應用數據包
(nt | rt: NBP, name binding protocol, 名稱綁定協議, 從數據來看, NBP服務器會在端口2提供此服務.
'DDP port 2' 可理解爲'DDP 對應傳輸層的端口2', DDP自己沒有端口的概念, 這點未肯定, 需補充).
第二行與第一行相似, 只是源的所有地址可用'office'進行標識.
第三行表示: jssmag網絡上的149節點經過235向icsd-net網絡上的全部節點的2端口(NBP端口)發送了數據包.(須要注意的是,
在AppleTalk 網絡中若是地址中沒有節點, 則表示廣播地址, 從而節點標識和網絡標識最好在/etc/atalk.names有所區別.
nt: 不然一個標識x.port 沒法肯定x是指一個網絡上全部主機的port口仍是指定主機x的port口).
tcpdump 可解析NBP (名稱綁定協議) and ATP (AppleTalk傳輸協議)數據包, 對於其餘應用層的協議, 只會打印出相應協議名字(
若是此協議沒有註冊一個通用名字, 只會打印其協議號)以及數據包的大小.
NBP 數據包會按照以下格式顯示:
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
第一行表示: 網絡icsd-net 中的節點112 經過220端口向網絡jssmag 中全部節點的端口2發送了對'LaserWriter'的名稱查詢請求(nt:
此處名稱可理解爲一個資源的名稱, 好比打印機). 此查詢請求的序列號爲190.
第二行表示: 網絡jssmag 中的節點209 經過2端口向icsd-net.112節點的端口220進行了迴應: 我有'LaserWriter'資源, 其資源名稱
爲'RM1140', 而且在端口250上提供改資源的服務. 此迴應的序列號爲190, 對應以前查詢的序列號.
第三行也是對第一行請求的迴應: 節點techpit 經過2端口向icsd-net.112節點的端口220進行了迴應:我有'LaserWriter'資源, 其資源名稱
爲'techpit', 而且在端口186上提供改資源的服務. 此迴應的序列號爲190, 對應以前查詢的序列號.
ATP 數據包的顯示格式以下:
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: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 向節點helios 發送了一個會話編號爲12266的請求包, 請求helios
迴應8個數據包(這8個數據包的順序號爲0-7(nt: 順序號與會話編號不一樣, 後者爲一次完整傳輸的編號,
前者爲該傳輸中每一個數據包的編號. transaction, 會話, 一般也被叫作傳輸)). 行尾的16進制數字表示
該請求包中'userdata'域的值(nt: 從下文來看, 這並無把全部用戶數據都打印出來 ).
Helios 迴應了8個512字節的數據包. 跟在會話編號(nt: 12266)後的數字表示該數據包在該會話中的順序號.
括號中的數字表示該數據包中數據的大小, 這不包括atp 的頭部. 在順序號爲7數據包(第8行)外帶了一個'*'號,
表示該數據包的EOM 標誌被設置了.(nt: EOM, End Of Media, 可理解爲, 表示一次會話的數據迴應完畢).
接下來的第9行表示, Jssmag.209 又向helios 提出了請求: 順序號爲3以及5的數據包請從新傳送. Helios 收到這個
請求後從新發送了這個兩個數據包, jssmag.209 再次收到這兩個數據包以後, 主動結束(release)了此會話.
在最後一行, jssmag.209 向helios 發送了開始下一次會話的請求包. 請求包中的'*'表示該包的XO 標誌沒有被設置.
(nt: XO, exactly once, 可理解爲在該會話中, 數據包在接受方只被精確地處理一次, 就算對方重複傳送了該數據包,
接收方也只會處理一次, 這須要用到特別設計的數據包接收和處理機制).
IP 數據包破碎
(nt: 指把一個IP數據包分紅多個IP數據包)
碎片IP數據包(nt: 即一個大的IP數據包破碎後生成的小IP數據包)有以下兩種顯示格式.
(frag id:size@offset+)
(frag id:size@offset)
(第一種格式表示, 此碎片以後還有後續碎片. 第二種格式表示, 此碎片爲最後一個碎片.)
id 表示破碎編號(nt: 從下文來看, 會爲每一個要破碎的大IP包分配一個破碎編號, 以便區分每一個小碎片是否由同一數據包破碎而來).
size 表示此碎片的大小 , 不包含碎片頭部數據. offset表示此碎片所含數據在原始整個IP包中的偏移((nt: 從下文來看,
一個IP數據包是做爲一個總體被破碎的, 包括頭和數據, 而不僅是數據被分割).
每一個碎片都會使tcpdump產生相應的輸出打印. 第一個碎片包含了高層協議的頭數據(nt:從下文來看, 被破碎IP數據包中相應tcp頭以及
IP頭都放在了第一個碎片中 ), 從而tcpdump會針對第一個碎片顯示這些信息, 並接着顯示此碎片自己的信息. 其後的一些碎片並不包含
高層協議頭信息, 從而只會在顯示源和目的以後顯示碎片自己的信息. 如下有一個例子: 這是一個從arizona.edu 到lbl-rtsg.arpa
途經CSNET網絡(nt: CSNET connection 可理解爲創建在CSNET 網絡上的鏈接)的ftp應用通訊片斷:
arizona.ftp-data > rtsg.1170: . 1024:1332(308) ack 1 win 4096 (frag 595a:328@0+)
arizona > rtsg: (frag 595a:204@328)
rtsg.1170 > arizona.ftp-data: . ack 1536 win 2560
有幾點值得注意:
第一, 第二行的打印中, 地址後面沒有端口號.
這是由於TCP協議信息都放到了第一個碎片中, 當顯示第二個碎片時, 咱們沒法知道此碎片所對應TCP包的順序號.
第二, 從第一行的信息中, 能夠發現arizona須要向rtsg發送308字節的用戶數據, 而事實是, 相應IP包經破碎後會總共產生512字節
數據(第一個碎片包含308字節的數據, 第二個碎片包含204個字節的數據, 這超過了308字節). 若是你在查找數據包的順序號空間中的
一些空洞(nt: hole,空洞, 指數據包之間的順序號沒有上下銜接上), 512這個數據就足夠使你迷茫一陣(nt: 其實只要關注308就行,
沒必要關注破碎後的數據總量).
一個數據包(nt | rt: 指IP數據包)若是帶有非IP破碎標誌, 則顯示時會在最後顯示'(DF)'.(nt: 意味着此IP包沒有被破碎過).
時間戳
tcpdump的全部輸出打印行中都會默認包含時間戳信息.
時間戳信息的顯示格式以下
hh:mm:ss.frac (nt: 小時:分鐘:秒.(nt: frac未知, 需補充))
此時間戳的精度與內核時間精度一致, 反映的是內核第一次看到對應數據包的時間(nt: saw, 便可對該數據包進行操做).
而數據包從物理線路傳遞到內核的時間, 以及內核花費在此包上的中斷處理時間都沒有算進來.
tcpdump條件表達式
該表達式用於決定哪些數據包將被打印. 若是不給定條件表達式, 網絡上全部被捕獲的包都會被打印,不然, 只有知足條件表達式的數據包被打印.(nt: all packets, 可理解爲, 全部被指定接口捕獲的數據包).
表達式由一個或多個'表達元'組成(nt: primitive, 表達元, 可理解爲組成表達式的基本元素). 一個表達元一般由一個或多個修飾符(qualifiers)後跟一個名字或數字表示的id組成(nt: 即, 'qualifiers id').有三種不一樣類型的修飾符:type, dir以及 proto.
type 修飾符指定id 所表明的對象類型, id能夠是名字也能夠是數字. 可選的對象類型有: host, net, port 以及portrange(nt: host 代表id表示主機, net 代表id是網絡, port 代表id是端而portrange 代表id 是一個端口範圍). 如, 'host foo', 'net 128.3', 'port 20', 'portrange 6000-6008'(nt: 分別表示主機 foo,網絡 128.3, 端口 20, 端口範圍 6000-6008). 若是不指定type 修飾符, id默認的修飾符爲host. dir 修飾符描述id 所對應的傳輸方向, 即發往id 仍是從id 接收（nt: 而id 到底指什麼須要看其前面的type 修飾符）.可取的方向爲: src, dst, src 或 dst, src而且dst.(nt:分別表示, id是傳輸源, id是傳輸目的, id是傳輸源或者傳輸目的, id是傳輸源而且是傳輸目的). 例如, 'src foo','dst net 128.3', 'src or dst port ftp-data'.(nt: 分別表示符合條件的數據包中, 源主機是foo, 目的網絡是128.3, 源或目的端口爲 ftp-data).若是不指定dir修飾符, id 默認的修飾符爲src 或 dst.對於鏈路層的協議,好比SLIP(nt: Serial Line InternetProtocol, 串聯線路網際網絡協議), 以及linux下指定'any' 設備, 並指定'cooked'(nt | rt: cooked 含義未知, 需補充) 抓取類型, 或其餘設備類型,能夠用'inbound' 和 'outbount' 修飾符來指定想要的傳輸方向. proto 修飾符描述id 所屬的協議. 可選的協議有: ether, fddi, tr, wlan, ip, ip6, arp, rarp, decnet, tcp以及 upd.(nt | rt: ether, fddi, tr, 具體含義未知, 需補充. 可理解爲物理以太網傳輸協議, 光纖分佈數據網傳輸協議,以及用於路由跟蹤的協議. wlan, 無線局域網協議; ip,ip6 即一般的TCP/IP協議棧中所使用的ipv4以及ipv6網絡層協議;arp, rarp 即地址解析協議,反向地址解析協議; decnet, Digital Equipment Corporation開發的, 最先用於PDP-11 機器互聯的網絡協議; tcp and udp, 即一般TCP/IP協議棧中的兩個傳輸層協議). 例如, `ether src foo', `arp net 128.3', `tcp port 21', `udp portrange 7000-7009'分別表示 '從以太網地址foo 來的數據包','發往或來自128.3網絡的arp協議數據包', '發送或接收端口爲21的tcp協議數據包', '發送或接收端口範圍爲7000-7009的udp協議數據包'. 若是不指定proto 修飾符, 則默認爲與相應type匹配的修飾符. 例如, 'src foo' 含義是 '(ip or arp or rarp) src foo' (nt: 即, 來自主機foo的ip/arp/rarp協議數據包, 默認type爲host),`net bar' 含義是`(ip or arp or rarp) net bar'(nt: 即, 來自或發往bar網絡的ip/arp/rarp協議數據包),`port 53' 含義是 `(tcp or udp) port 53'(nt: 即, 發送或接收端口爲53的tcp/udp協議數據包).(nt: 因爲tcpdump 直接經過數據鏈路層的 BSD 數據包過濾器或 DLPI(datalink provider interface, 數據鏈層提供者接口)來直接得到網絡數據包, 其可抓取的數據包可涵蓋上層的各類協議, 包括arp, rarp, icmp(因特網控制報文協議),ip, ip6, tcp, udp, sctp(流控制傳輸協議). 對於修飾符後跟id 的格式,可理解爲, type id 是對包最基本的過濾條件: 即對包相關的主機, 網絡, 端口的限制;dir 表示對包的傳送方向的限制; proto表示對包相關的協議限制) 'fddi'(nt: Fiber Distributed Data Interface) 實際上與'ether' 含義同樣: tcpdump 會把他們看成一種''指定網絡接口上的數據鏈路層協議''. 如同ehter網(以太網), FDDI 的頭部一般也會有源, 目的, 以及包類型, 從而能夠像ether網數據包同樣對這些域進行過濾. 此外, FDDI 頭部還有其餘的域, 但不能被放到表達式中用來過濾 一樣, 'tr' 和 'wlan' 也和 'ether' 含義一致, 上一段對fddi 的描述一樣適用於tr(Token Ring) 和wlan(802.11 wireless LAN)的頭部. 對於802.11 協議數據包的頭部, 目的域稱爲DA, 源域稱爲 SA;而其中的 BSSID, RA, TA 域(nt | rt: 具體含義需補充)不會被檢測(nt: 不能被用於包過慮表達式中).
除以上所描述的表達元('primitive')， 還有其餘形式的表達元, 而且與上述表達元格式不一樣. 好比: gateway, broadcast, less, greater以及算術表達式(nt: 其中每個都算一種新的表達元). 下面將會對這些表達元進行說明.
表達元之間還能夠經過關鍵字and, or 以及 not 進行鏈接, 從而可組成比較複雜的條件表達式. 好比,`host foo and not port ftp and not port ftp-data'(nt: 其過濾條件可理解爲, 數據包的主機爲foo,而且端口不是ftp(端口21) 和ftp-data(端口20, 經常使用端口和名字的對應可在linux 系統中的/etc/service 文件中找到)).
爲了表示方便, 一樣的修飾符能夠被省略, 如'tcp dst port ftp or ftp-data or domain' 與如下的表達式含義相同'tcp dst port ftp or tcp dst port ftp-data or tcp dst port domain'.(nt: 其過濾條件可理解爲,包的協議爲tcp, 目的端口爲ftp 或 ftp-data 或 domain(端口53) ).
藉助括號以及相應操做符,可把表達元組合在一塊兒使用(因爲括號是shell的特殊字符, 因此在shell腳本或終端中使用時必須對括號進行轉義, 即'(' 與')'須要分別表達成'\(' 與 '\)').
有效的操做符有:
否認操做 (`!' 或 `not') 與操做(`&&' 或 `and') 或操做(`||' 或 `or')
否認操做符的優先級別最高. 與操做和或操做優先級別相同, 而且兩者的結合順序是從左到右. 要注意的是, 表達'與操做'時,
須要顯式寫出'and'操做符, 而不僅是把先後表達元並列放置(nt: 兩者中間的'and' 操做符不可省略).
若是一個標識符前沒有關鍵字, 則表達式的解析過程當中最近用過的關鍵字(每每也是從左往右距離標識符最近的關鍵字)將被使用.好比,
not host vs and ace
是如下表達的精簡:
not host vs and host ace
而不是not (host vs or ace).(nt: 前二者表示, 所需數據包不是來自或發往host vs, 而是來自或發往ace.然後者表示數據包只要不是來自或發往vs或ac都符合要求)
整個條件表達式能夠被看成一個單獨的字符串參數也能夠被看成空格分割的多個參數傳入tcpdump, 後者更方便些. 一般, 若是表達式中包含元字符(nt: 如正則表達式中的'*', '.'以及shell中的'('等字符)， 最好仍是使用單獨字符串的方式傳入. 這時,整個表達式須要被單引號括起來. 多參數的傳入方式中, 全部參數最終仍是被空格串聯在一塊兒, 做爲一個字符串被解析.
- 1. linux抓包命令-tcpdump命令詳解
- 2. tcpdump抓包命令詳解
- 3. TCPdump抓包命令詳解
- 4. Linux抓包工具tcpdump命令詳解
- 5. Linux tcpdump抓包命令詳解（一）
- 6. linux抓包命令之tcpdump
- 7. tcpdump抓包命令
- 8. Tcpdump命令抓包詳細分析
- 9. 抓包工具：tcpdump抓包命令詳解
- 10. 178_Android抓包-Tcpdump命令+Wireshark
- 更多相關文章...
- • 免費ARP詳解 - TCP/IP教程
- • Docker version 命令 - Docker命令大全
- • Docker 清理命令
- • Flink 數據傳輸及反壓詳解
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. vs2019運行opencv圖片顯示代碼時，窗口亂碼
- 2. app自動化 - 元素定位不到？別慌，看完你就能解決
- 3. 在Win8下用cisco ××× Client連接時報Reason 422錯誤的解決方法
- 4. eclipse快速補全代碼
- 5. Eclipse中Java/Html/Css/Jsp/JavaScript等代碼的格式化
- 6. idea+spring boot +mabitys(wanglezapin)+mysql (1)
- 7. 勒索病毒發生變種 新文件名將帶有「.UIWIX」後綴
- 8. 【原創】Python 源文件編碼解讀
- 9. iOS9企業部署分發問題深入瞭解與解決
- 10. 安裝pytorch報錯CondaHTTPError：******