tcpdump wireshark
转载：https://www.cnblogs.com/shishanyu/p/7966477.htmlhtml
TCPDUMP
实用命令实例
tcpdump根据使用者的定义对网络上的数据包进行截获的包进行分析。linux
默认启动
tcpdump
普通状况下，直接启动tcpdump将监视第一个网络接口上全部流过的数据包。ios
监视指定网络接口的数据包
tcpdump -i eth1
若是不指定网卡，默认tcpdump只会监视第一个网络接口，通常是eth0，下面的例子都没有指定网络接口。 git
监视指定主机的数据包
打印全部进入或离开sundown的数据包.web
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的通讯shell
tcpdump host 210.27.48.1 and \ (210.27.48.2 or 210.27.48.3 \)
打印ace与任何其余主机之间通讯的IP 数据包, 但不包括与helios之间的数据包.express
tcpdump ip host ace and not helios
若是想要获取主机210.27.48.1除了和主机210.27.48.2以外全部主机通讯的ip包，使用命令：windows
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采用命令行方式，它的命令格式为：
tcpdump [ -AdDeflLnNOpqRStuUvxX ] [ -c count ]
[ -C file_size ] [ -F file ]
[ -i interface ] [ -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 以ASCII码方式显示每个数据包(不会显示数据包中链路层头部信息). 在抓取包含网页数据的数据包时, 可方便查看数据(nt: 即Handy for capturing web pages).
-c count
tcpdump将在接受到count个数据包后退出.
-C file-size (nt: 此选项用于配合-w file 选项使用)
该选项使得tcpdump 在把原始数据包直接保存到文件中以前, 检查此文件大小是否超过file-size. 若是超过了, 将关闭此文件,另创一个文件继续用于原始数据包的记录. 新建立的文件名与-w 选项指定的文件名一致, 但文件名后多了一个数字.该数字会从1开始随着新建立文件的增多而增长. file-size的单位是百万字节(nt: 这里指1,000,000个字节,并不是1,048,576个字节, 后者是以1024字节为1k, 1024k字节为1M计算所得, 即1M=1024 ＊ 1024 ＝ 1,048,576)
-d 以容易阅读的形式,在标准输出上打印出编排过的包匹配码, 随后tcpdump中止.(nt | rt: human readable, 容易阅读的,一般是指以ascii码来打印一些信息. compiled, 编排过的. packet-matching code, 包匹配码,含义未知, 需补充)
-dd 以C语言的形式打印出包匹配码.
-ddd 以十进制数的形式打印出包匹配码(会在包匹配码以前有一个附加的'count'前缀).
-D 打印系统中全部tcpdump能够在其上进行抓包的网络接口. 每个接口会打印出数字编号, 相应的接口名字, 以及可能的一个网络接口描述. 其中网络接口名字和数字编号能够用在tcpdump 的-i flag 选项(nt: 把名字或数字代替flag), 来指定要在其上抓包的网络接口.
此选项在不支持接口列表命令的系统上颇有用(nt: 好比, Windows 系统, 或缺少 ifconfig -a 的UNIX系统); 接口的数字编号在windows 2000 或其后的系统中颇有用, 由于这些系统上的接口名字比较复杂, 而不易使用.
若是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 下的 'any' 网络接口就不须要设置地址和掩码, 不过此'any'接口能够收到系统中全部接口的数据包), 该选项不能正常工做.
-F file
使用file 文件做为过滤条件表达式的输入, 此时命令行上的输入将被忽略.
-i interface
指定tcpdump 须要监听的接口. 若是没有指定, tcpdump 会从系统接口列表中搜寻编号最小的已配置好的接口(不包括 loopback 接口).一但找到第一个符合条件的接口, 搜寻立刻结束.
在采用2.2版本或以后版本内核的Linux 操做系统上, 'any' 这个虚拟网络接口可被用来接收全部网络接口上的数据包(nt: 这会包括目的是该网络接口的, 也包括目的不是该网络接口的). 须要注意的是若是真实网络接口不能工做在'混杂'模式(promiscuous)下,则没法在'any'这个虚拟的网络接口上抓取其数据包.
若是 -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 将会打印'nic' 而不是 'nic.ddn.mil'.
-O 不启用进行包匹配时所用的优化代码. 当怀疑某些bug是由优化代码引发的, 此选项将颇有用.
-p 通常状况下, 把网络接口设置为非'混杂'模式. 但必须注意 , 在特殊状况下此网络接口仍是会以'混杂'模式来工做； 从而, '-p' 的设与不设, 不能当作如下选现的代名词:'ether host {local-hw-add}' 或 'ether broadcast'(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 和 2. 而若是此时-S 选项被设置, 对于后来接收到的第2个, 第3个数据包会打印出其绝对顺序号:232324, 232325).
-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 for 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 的取值未知, 需补充)
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中的'('等字符)， 最好仍是使用单独字符串的方式传入. 这时,整个表达式须要被单引号括起来. 多参数的传入方式中, 全部参数最终仍是被空格串联在一块儿, 做为一个字符串被解析.
wireshark
首先说几个最经常使用的关键字，“eq” 和 “==”等同，可使用 “and” 表示而且，“or”表示或者。“!" 和 "not” 都表示取反。
tcp dst port 3128
显示目的TCP端口为3128的封包。ip src host 10.1.1.1显示来源IP地址为10.1.1.1的封包。host 10.1.2.3显示目的或来源IP地址为10.1.2.3的封包。src portrange 2000-2500显示来源为UDP或TCP，而且端口号在2000至2500范围内的封包。not imcp显示除了icmp之外的全部封包。（icmp一般被ping工具使用）src host 10.7.2.12 and not dst net 10.200.0.0/16显示来源IP地址为10.7.2.12，但目的地不是10.200.0.0/16的封包。(src host 10.4.1.12 or src net 10.6.0.0/16) and tcp dst portrange 200-10000 and dst net 10.0.0.0/8显示来源IP为10.4.1.12或者来源网络为10.6.0.0/16，目的地TCP端口号在200至10000之间，而且目的位于网络10.0.0.0/8内的全部封包。
- 1. Wireshark 与 Tcpdump
- 2. kali linux之wireshark/tcpdump
- 3. Wireshark & tcpdump & ELecard StreamEye Tools
- 4. LINUX调优---tcpdump,wireshark
- 5. tcpdump抓包wireshark分析
- 6. tcpdump / wireshark 抓包及分析
- 7. tcpdump抓包+wireshark解包
- 8. tcpdump抓包与Wireshark分析
- 9. 178_Android抓包-Tcpdump命令+Wireshark
- 10. 抓包及分析（wireshark&tcpdump）
- 更多相关文章...
- • Wireshark下载安装和使用教程 - TCP/IP教程
- • 伪造ICMP请求包进行路由跟踪 - TCP/IP教程
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. Wireshark 与 Tcpdump
- 2. kali linux之wireshark/tcpdump
- 3. Wireshark & tcpdump & ELecard StreamEye Tools
- 4. LINUX调优---tcpdump,wireshark
- 5. tcpdump抓包wireshark分析
- 6. tcpdump / wireshark 抓包及分析
- 7. tcpdump抓包+wireshark解包
- 8. tcpdump抓包与Wireshark分析
- 9. 178_Android抓包-Tcpdump命令+Wireshark
- 10. 抓包及分析（wireshark&tcpdump）