tcpdump命令详解
简介
⽤简单的话来定义tcpdump，就是：dump the traffic on a network，根据使⽤者的定义对⽹络上的数据包进⾏截获的包分析⼯具。 tcpdump可以将⽹络中传送的数据包的“头”完全
截获下来提供分析。它⽀持针对⽹络层、协议、主机、⽹络或端⼝的过滤，并提供and、or、not等逻辑语句来帮助你去掉⽆⽤的信息。
实⽤命令实例
默认启动
tcpdump
普通情况下，直接启动tcpdump将监视第⼀个⽹络接⼝上所有流过的数据包。
1、tcpdump: no suitable device found
问题分析及解决：
2种原因：
1.权限不够，⼀般不经过处理，只⽤root⽤户能使⽤tcpdump , sudo ./tcpdump
2.缺省只能同时使⽤4个tcpdump，如⽤完，则报此类错。需要停掉多余的tcpdump
2、
fedora 14 中运⾏make install 命令也要加上 sudo
3、出现种提⽰ linux UID or EUID of 0 required
也是权限问题，fedora 下加上sudo
监视指定⽹络接⼝的数据包
tcpdump -i eth1
如果不指定⽹卡，默认tcpdump只会监视第⼀个⽹络接⼝，⼀般是eth0，下⾯的例⼦都没有指定⽹络接⼝。
监视指定主机的数据包
打印所有进⼊或离开sundown的数据包.
tcpdump host sundown
也可以指定ip，例如截获所有210.27.48.1 的主机收到的和发出的所有的数据包
tcpdump host 210.27.48.1
打印helios 与 hot 或者与 ace 之间通信的数据包
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包，同时本地端⼝是23，使⽤如下命令
tcpdump tcp port 23 and host 210.27.48.1
18:16:52.987746 IP 10.1.210.111.55634 > izwz969829wo6i9nlscjukz.9124: Flags [S], q 833996115, win 29200, options [mss 1460,sackOK,TS val 1492682208 ecr 0,nop,wscale 7], length 0
18:16:52.987794 IP izwz969829wo6i9nlscjukz.9124 > 10.1.210.111.55634: Flags [S.], q 540069507, ack 833996116, win 28960, options [mss 1460,sackOK,TS val 1492698220 ecr 149268
2208,nop,wscale 7], length 0 18:16:52.987980 IP 10.1.210.111.55634 > izwz969829wo6i9nlscjukz.9124: Flags [R.], q 1, ack 1, win 229, options [nop,nop,TS val 0 ecr 1492698220], length 0
18:16:52.989616 IP 10.1.210.111.55636 > izwz969829wo6i9nlscjukz.9124: Flags [S], q 236673865, win 29200, options [mss 1460,sackOK,TS val 1492682210 ecr 0,nop,wscale 7], length 0
18:16:52.989642 IP izwz969829wo6i9nlscjukz.9124 > 10.1.210.111.55636: Flags [S.], q 2397900505, ack 236673866, win 28960, options [mss 1460,sackOK,TS val 1492698222 ecr 1492682210,nop,wscale 7], length 0 18:16:52.989782 IP 10.1.210.111.55636 > izwz969829wo6i9nlscjukz.9124: Flags [R.], q 1, ack 1, win 229, options [nop,nop,TS val 0 ecr 1492698222], length 0
18:16:54.189162 IP izwz969829wo6i9nlscjukz.9124 > 10.1.210.111.55634: Flags [S.], q 540069507, ack 833996116, win 28960, options [mss 1460,sackOK,TS val 1492699422 ecr 1492682208,nop,wscale 7], length 0 18:16:54.189319 IP 10.1.210.111.55634 > izwz969829wo6i9nlscjukz.9124: Flags [R], q 833996116, win 0, length 0
18:16:54.389178 IP izwz969829wo6i9nlscjukz.9124 > 10.1.210.111.55636: Flags [S.], q 23979005
05, ack 236673866, win 28960, options [mss 1460,sackOK,TS val 1492699622 ecr 1492682210,nop,wscale 7], length 0 18:16:54.389374 IP 10.1.210.111.55636 > izwz969829wo6i9nlscjukz.9124: Flags [R], q 236673866, win 0, length 0
18:16:56.989896 IP 10.1.210.111.55656 > izwz969829wo6i9nlscjukz.9124: Flags [S], q 2567997945, win 29200, options [mss 1460,sackOK,TS val 1492686210 ecr 0,nop,wscale 7], length 0
18:16:56.989959 IP izwz969829wo6i9nlscjukz.9124
我的haproxy配置的是4秒，这⾥怎么是2秒呢？
看上⾯的标志位
对本机的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 ⾥抓包，然后在Wind
ows ⾥分析包。
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-qno 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-qno)描述了此包中数据所对应序列号空间中的⼀个位置(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的the是什么词
⽤户数据'.) 没有捎带应答(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 |
-----------------------------------------------------------------
| quence 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 rvice 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: 表⽰地址), 其数据为int
ernet地址128.32.137.3.
此回应UDP数据包, 包含273字节的数据(不包含UPD和IP的头部数据). op字段和rcode字段被忽略(nt: op的实际值为Query, rcode, 即
respon 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 或者samba 镜像站点的pub/samba/specs/ ⽬录. linux 上的SMB 补丁
(nt | rt: patch)由 Andrew Tridgell (tridge@samba)提供.
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 (⽂件⼤⼩).
