网络分析的艺术(一)

作者: 云中布衣   分类:  读书笔记    热度: (272℃)   时间: 2018-8-27 16:19   标签: #wireshark  #读书笔记    

读书笔记之《Wireshark网络分析的艺术》篇,作者林沛满,豆瓣评分8.6。

这是林沛满老师第二本关于Wireshark网络分析的书了,延续上一本《Wireshark网络分析就这么简单》的幽默文风,本书可读性很强。林老师的书写的太通俗易懂,根本不想做笔记,只想一口气读完。其实昨天已经把后半部分都粗略的看过了,今天重头开始看,一边看一遍做一些笔记。

Capture_wireshark3.PNG
Linux为什么卡住?
按照惯例使用Wireshark抓包,发现是DNS惹的祸。
林老师说:技能比知识更重要。通过Wireshark抓包这个技能,林老师很好的Get到了SSH登录配置,消除登录卡顿十秒的这个知识。、
当然如何能够利用好信息检索这个技能,也能很好的解决这个问题。
或许这就是,上学时候老师常说的:“授人以鱼,不如授人以渔。”

想福尔摩斯一样思考
通过TCP三次握手中,1、2号数据包中,源地址和目的地址的不同,来推测实际的网络拓扑图,此外,2号包的TTL(time to live)值为64,说明中间没有经过路由,理论上经过一次路由的包,TTL应该减1;再利用2号和3号数据包Identification的不同,找到防火墙的存在,进而推测出出防火墙的配置有误。
用Wireshark去分析网络,并解决问题,真的有一种当侦探的感觉,23333

一篇关于VMware的文章
通过Wireshark去抓包分析,以验证作者理论分析的结果正确性。

来点有深度的
从本质上看,延时确认之所以会在大量重传时影响性能,是因为它在该场景下会多次出现(甚至因为延迟太久而导致超时重传)
除了以上场景,当TCP窗口极小的情况,此时启用延迟确认简直就是雪上加霜。

三次握手的小知识
比较经典额一个TCP通过三次握手建立连接的过程如下:
Image.png
成功的握手都是一样的,失败的握手却各不相同,因此解决起来还是需要一些技巧的。
Wireshark提供了一个功能把Seq和Ack的初始值都置成0,即用“相对值”来代替“真实值”,Edit->Preferences->Protocols->TCP菜单中勾上Relative Sequence Numbers
表达式1:(tcp.flags.reset == 1) && (tcp.seq == 1)
表达式2:(tcp.flags.syn == 1) && (tcp.analysis.retransmission)
这两个表达式很好用,不过要最快排查出根本原因还需要另一个技巧,即在两端同时抓包。
同样是握手失败,客户端发出的包丢了,服务器回复的包丢了,不同的丢包意味着不同的问题根源,解决的方式也不一样。如果只在客户端抓包,那这两种丢包的症状看起来就像是一样的。

大规模DDoS(Distributed Denial of Service, 分布式拒绝服务攻击)的形式有很多种,其中最流行的就是基于三次握手的SYN flood,其原理是从大量主机发送SYN请求给服务器,假装要建立TCP连接。这些SYN请求可能含有假的源地址,所以服务器响应后永远收不到Ack,就会留下half=open状态的TCP连接。由于每个TCP都会消耗一定的系统资源,如果攻击足够猛烈,此类连接越建越多,服务器的资源就会被耗光,当真正的用户访问时也会被拒绝。
我们可以把SYN flood看作TCP协议的设计缺陷,有办法可以防御,却无法根除。比如可以使用流量清洗,TCP握手代理之列的方法,这一点在网络安全方面的专著应该会有相应的分析。

被误解的TCP
误解1:每个发送的数据包都应该得到确认。事实不是每个数据包都会有对应的Ack,数据接收方可以累积一些包才对发送方Ack一次。
误解2:TCP效率低,是因为其传输过程需要往返时间来确认(Ack),而UDP无需确认,因此不停地发包,效率就高了。事实上只要窗口足够大,TCP也可以不受往返时间的约束而源源不断的传输数据。
当然啦,误解2中,TCP也确实因为往返时间而降低效率的情况。比如在传输小块数据的场景,本来能在1个往返时间内完成的小事,却要额外耗费3次握手和4次握手开销,DNS查询就符合这种场景。
Google发布的QUIC(Quick UDP Internet Connection)协议,就是为了消除TCP的延迟而设计的替代品,在某些领域可以视为TCP的竞争对手,目前在Google网站上已经可以试用了。

最经典的网络问题
Nagle算法和延迟确认一起用,影响了实际的性能。解决方法很简单,要么在Windows上关闭Nagle算法,要么在AIX上关闭延迟确认,客户选择了前者,性能立即提升了20倍。
按道理说,世界上到处都有启用了Nagle和算法和延迟确认的设备在通信。

为什么丢了单子?
通过wireshark找到了RPC协议 RFC5531中关于gids<16>的定义,解决了远程NFS服务器创建用户,并设置分组时,出现某些文件允许某个用户组访问的,但是属于该组的用户却访问不了的现象。

受损的帧
每个帧在发送前都会被发送方校验一次,然后生成一个4个字节的FCS(Frame Check Sequence)存在帧尾,接收方拿到帧后,又会用相同的算法再做一次校验并生成FCS,假如这次生成的FCS和帧尾携带的不一致,就说明该帧已经损坏,应该被丢弃。由于校验是由网卡完成的,所以在主机上抓包,一般是看不到FCS区域的。
这时如果通过wireshark抓包,一般是发现不了问题的,如果在linux上,则可以通过netstat -i命令综合输出多种错误,其中也包括FCS的相关信息。

虚惊一场
延迟确认把四次挥手,从4个包,减少成了3个包。

NTLM协议分析
NTLM全称是NT LAN Manager,是Windows NT时代就出现的身份验证协议。林工通过wireshark抓包,分析了NTLM的工作原理。

Wireshark的提示
1)Packet size limited during capture
该提示表明被标记的那个包没有抓全,有些操作系统,tcpdump默认只抓每个帧的前96个字节,我们可以用-s参数来设定想要抓的字节数,比如:
# tcpdump -i eth0 -s 1000 -w /tmp/tcpdump.cap
2)TCP Previous segment not captured

在TCP传输的过程中,同一台主机发出的数据段应该是连续的。即后一个包的seq号应该等于前一个包的Seq+Len(三次握手和四次挥手除外),如果wireshark发现后一个包的Seq号大于前一个包的Seq+Len,就知道中间缺失了一段数据,假如那段缺失的数据在整个网络包中都找不到(即排除了乱序),就会提示以上错误。网络包没有抓到可以分为两种情况,一种是真的丢了,另一种是实际上没有丢,但被抓包工具漏掉了,在Wireshark中可以通过对方回复的Ack来区分,如果确认的包含了没有抓到的包,那就是抓包工具漏掉了,否则就是真的丢了这个包。
3)TCP ACKed unseen segment
当Wireshark发现被Ack的那个包没被抓到,就会提上以上错误,一般经常出现在一个网络包的开头,因为只抓到了后面的Ack没有抓到前面的数据包。
4)TCP Out-of_Order

当Wireshark发现后一个包的Seq号小于前一个包的Seq+Len时,就会认为是乱序了。
小跨度的乱序影响不大,比如原本顺序为1、2、3、4、5号包,被打乱为2、1、3、4、5就没事,但是跨度大的乱序去可能触发快速重传机制,比如打乱成2、3、4、5、1,就会触发足够多的Dup ACK,从而导致1号包重传。
5)TCP Dup ACK
当乱序或者丢包发生时,接收方会收到一些Seq号比期望值大的包。它每收到一个这种包就会Ack一次期望的Seq值,以此方式来提醒发送方,于是就产生了一些重复的Ack,Wireshark会在这种重复的Ack上标记[TCP Dup ACK]。
6)TCP Fast Retransmission
当发送方收到3个或以上TCP Dup ACK,就意识到之前发的包可能丢了,于是快速重传它(这是RFC的规定)。
7)TCP Retransmission
如果一个包真的丢了,又没有后续包可以在接收方触发Dup Ack,就不会快速重传,这种情况下发送方只好等到超时了再重传。
8)TCP zerowindow
TCP包中的"win="代表接收窗口的大小,即表示这个包的发送方当前还有多少缓冲区可以接收数据。当Wireshark在一个包中发现"win=0"时,就会给它打上"TCP zerowindow"的标记,表示缓冲区已满不能再接收数据了。
9)TCP window Full
当Wireshark在一个包中打上[TCP window Full]标志时,就表示这个包的发送方已经把对方所声明的接收窗口耗尽了。
10)TCP segment of a reassembled PDU
当你接收这个提示,肯定已经在Edit->Preferences->Protocols->TCP 菜单里启用了Allow sub dissector to reassemble TCP streams。它表示Wireshark可以把属于同一个应用层PDU的TCP虚拟的集中起来。
11)Continuation to #
当你看到这个提示,说明已经在Edit->Preferences->Protocols->TCP菜单里关闭了Allow sub dissector to reassemble TCP streams。
12)Time-to-live exceeded(Fragment reassembly time exceeded)

ICMP 的报错有好多种,此处的提示,表示这个包的发送方之前收到了一些分片,但是由于某些原因迟迟无法组装起来。
<20180827 未完待续>
56.8K

评论:

云中布衣 Say:
@云顶天的博客 这个取代的过程必将非常的漫长,但网络层传输速率的不断优化肯定是一大趋势。

2018-08-30 11:26


云顶天的博客 Say:
不错不错,虽然TCP传输效率是个问题,不过UDP在实际应用中也总是遇到某一方防火墙开启了udp flood防御的丢弃动作,然后直接被干掉。期待成熟通用的替代品出现~

2018-08-29 23:39


云中布衣 Say:
@贵安交易 欢迎常来坐坐。

2018-08-29 22:39


贵安交易 Say:
非常优秀的读书笔记,看完收获很多!

2018-08-28 11:38


发表评论:

© 云中布衣 2015 | Driven by EMLOG  | SiteMap | RunTime: 7.60ms RSS  | MORE  |   | TOP

文章数量【258】 评论数量【238】 稳定运行【1208天】

Visitor IP Address【54.196.190.32】

Email:ieeflsyu#outlook.com