2023年7月3日发(作者：)

《Wireshark⽹络分析就这么简单》读书笔记以下所有内容来⾃于《Wireshark⽹络分析就这么简单》(林沛满 著)Wireshark⽹络分析就这么简单⽹络分析>> 为什么ping的是服务器A的IP，B却去查询默认⽹关的MAC地址？因为B根据⾃⼰的⼦⽹掩码，计算出A属于不同⼦⽹，跨⼦⽹通信需要默认⽹关的转发。⽽要和默认⽹关通信，就需要获得其MAC地址。>> 不同⽹段的服务器B为何直接回复了服务器A⾃⼰的MAC地址？因为在执⾏ARP回复时并不考虑⼦⽹，即使ARP请求来⾃其他⼦⽹IP也照样回复。>> 为什么Wireshark上显⽰MAC地址开头是Vmware?因为 MAC 地址的前 3 个字节表⽰⼚商，这⾥表⽰Vmware公司。>> 当A ping B时，⽹络包应该怎么⾛？假如⾃⾝有⼀个IP和对⽅在同⼀⼦⽹，就从这个IP直接发包给对⽅；假如没有⼀个IP和对⽅同⼦⽹，就⾛默认⽹关。>> A正通过ARP⼴播查找B的MAC地址，试图绕过默认⽹关直接与B通信。这说明了什么问题呢？这说明A上存在⼀项符合与B同⽹段的路由，促使A通过eth1直接与B通信。由于不同⼦⽹所配的 VLAN 也不同，所以这些 ARP 请求根本到达不了 B。>> NAT的陷阱两个⽹络之间存在 NAT（Network Address Translation），当客户端发出的请求经过NAT设备时，Source IP被改掉了，所以原有的放⾏策略可能就会失效。抓包技巧>> 包的⼤⼩(1)⼀般能抓到的每个包（称为“帧”更准确）的最⼤长度为1514字节，启⽤了 Jumbo Frame（巨型帧）之后可达 9000 字节以上，⽽⼤多数时候我们只需要 IP 头或者 TCP 头就⾜够分析了。(2)⼀般设个偏⼤的数字：80字节，也就是说每个包只抓前80字节。这样TCP层、⽹络层和数据链路层的信息都可以包括在内(3)⽤tcpdump命令抓包时可以⽤“-s”参数达到相同效果。⽐如以下命令只抓eth0上每个包的前80字节，并把结果存到/tmp/⽂件中。[root@server_1 /]# tcpdump -i eth0 -s 80-w /tmp/>> 抓包标记抓的包除了要⼩，最好还能为每步操作打上标记。（1）ping-n1-l1（2）操作步骤1（3）ping-n1-l2（4）操作步骤2查看包最底下的“Data（1byte）”，byte的数⽬表⽰是第⼏步>> 服务器和客户端的时间问题(1) Wireshark 的时间调成跟服务器⼀样的格式：单击 Wireshark 的 View–>Time Display Format–>Date and Time of Day，就可以实现此设置；(2)如果在其他时区的服务器上抓包，然后下载到⾃⼰的电脑上分析，最好把⾃⼰电脑的时区设成跟抓包的服务器⼀样。这样，Wireshark显⽰的时间才能匹配服务器上⽇志的时间。>> 过滤(1) 如果已知某个协议发⽣问题，可以⽤协议名称过滤⼀下。⽤协议过滤时务必考虑到协议间的依赖性。(⽐如 NFS 共享挂载失败，问题可能发⽣在挂载时所⽤的mount协议，也可能发⽣在mount之前的portmap协议。这种情况下就需要⽤“portmap||mount”来过滤了。)(2) IP 地址加 port 号是最常⽤的过滤⽅式。除了⼿⼯输⼊ &&<端⼝号>之类的过滤表达式，Wireshark还提供了更快捷的⽅式：右键单击感兴趣的包，选择Follow TCP/UDP Stream（选择TCP还是UDP要视传输层协议⽽定）就可以⾃动过滤。(3)右键单击Wireshark上感兴趣的内容，然后选择Prepare a Filter–>Selected，就会在Filter框中⾃动⽣成过滤表达式。在有复杂需求的时候，还可以选择And、Or等选项来⽣成⼀个组合的过滤表达式。(假如右键单击之后选择的不是Prepare a Filter，⽽是Apply as Filter–>Selected，则该过滤表达式⽣成之后还会⾃动执⾏。)(4)在Filter中输⼊“error”进⾏搜索。很多应⽤层的错误都可以靠这个⽅法锁定问题包。>> 分析(1)单击Wireshark的Analyze–>Expert Info Composite，就可以在不同标签下看到不同级别的提⽰信息。⽐如重传的统计、连接的建⽴和重置统计，等等。在分析⽹络性能和连接问题时，我们经常需要借助这个功能。(从Error和Warning⾥都没有看到报错，这说明⽹络没有问题。假如有重传、乱序之类的现象，应该能在这个窗⼝⾥看到。)(2)单击Statistics–>Service Response Time，再选定协议名称，可以得到响应时间的统计表。我们在衡量服务器性能时经常需要此统计结果。(3)单击Statistics–>TCP Stream Graph，可以⽣成⼏类统计图。(4)单击Statistics–>Summary，可以看到⼀些统计信息，⽐如平均流量(/sec)等，这有助于我们推测负载状况。⽐如⽹络包才1.594Mbit/s，说明流量低得很。>> tsharkWireshark的命令⾏版，功能更强⼤。输出的分析⽂本⼤多可以直接写⼊分析报告中，⽽ Wireshark ⽣成不了这样的报告。TCP协议>> 协议说明TCP是基于连接的，⽽UDP不需要连接。它们各⾃⽀持⼀些应⽤层协议，但也有些协议是两者都⽀持的，⽐如DNS。>> MTU⽹络对包的⼤⼩是有限制的，其最⼤值称为MTU，即“最⼤传输单元”。⼤多数⽹络的MTU是1500字节，但也有些⽹络启⽤了巨帧（Jumbo Frame），能达到9000字节。⼀个8192字节的包进⼊巨帧⽹络不会有问题，但到了1500字节的⽹络中就会被丢弃或者切分。被丢弃意味着传输彻底失败，因为重传的包还会再⼀次被丢弃。⽽被切分则意味着传输效率降低。>> MSS在TCP连接建⽴（三次握⼿）时，双⽅都会把⾃⼰的MSS（Maximum Segment Size）告诉对⽅。MSS加上TCP头和IP头的长度，就得到MTU了。发包的⼤⼩是由MTU较⼩的⼀⽅决定的。>> Seq&&Ack点开TCP层前的“+”号，我们可以看到Seq号和Ack号等⼀系列信息，它们⽤于⽹络包的排序、重传、流量控制等。(1)Seq：表⽰该数据段的序。TCP提供有序的传输，所以每个数据段都要标上⼀个序号。当接收⽅收到乱序的包时，有了这个序号就可以重新排序了。⼀个Seq号的⼤⼩是根据上⼀个数据段的Seq号和长度相加⽽来的。(2)Len：该数据段的长度，注意这个长度不包括TCP头。(3)Ack：确认号，接收⽅向发送⽅确认已经收到了哪些字节。 ⽐如甲发送了“Seq:x Len:y”的数据段给⼄，那⼄回复的确认号就是x+y，这意味着它收到了x+y之前的所有字节。(TCP的确认是可以累积的。)>> 标志说明(1)SYN：携带这个标志的包表⽰正在发起连接请求。因为连接是双向的，所以建⽴连接时，双⽅都要发⼀个SYN。(2)FIN：携带这个标志的包表⽰正在请求终⽌连接。因为连接是双向的，所以彻底关闭⼀个连接时，双⽅都要发⼀个FIN。(3)RST：⽤于重置⼀个混乱的连接，或者拒绝⼀个⽆效的请求。>> Relative Sequence Number事实上，握⼿时Seq号并不是从0开始的。我们之所以在 Wireshark 上看到 Seq=0，是因为 Wireshark 启⽤了 Relative SequenceNumber。如果你想关闭这个功能，可以在Edit–>Preferences–>protocols–>TCP⾥设置。>> netstat⼯作中如果碰到断开连接的问题，可以使⽤ netstat 命令来排查。>> 延迟确认这其实就是TCP处理交互式场景的策略之⼀。该策略的原理是这样的：如果收到⼀个包之后暂时没什么数据要发给对⽅，那就延迟⼀段时间（在Windows上默认为200毫秒）再确认。假如在这段时间⾥恰好有数据要发送，那确认信息和数据就可以在⼀个包⾥发出去了。>> Nagle算法原理：在发出去的数据还没有被确认之前，假如⼜有⼩数据⽣成，那就把⼩数据收集起来，凑满⼀个MSS或者等收到确认后再发送。TCP窗⼝>> TCP发送窗⼝现实中也存在⼀些限制：接收⽅的缓存（接收窗⼝）可能⼀下⼦接受不了这么多数据；⽹络的带宽也不⼀定⾜够⼤，⼀⼝⽓发太多会导致丢包事故。所以，发送⽅要知道接收⽅的接收窗⼝和⽹络这两个限制因素中哪⼀个更严格，然后在其限制范围内尽可能多发包。这个⼀⼝⽓能发送的数据量就是传说中的TCP发送窗⼝。(1)TCP 超时重传的间隔时间太长，设置⼀个较⼩的时间可以减少重传对性能的影响。⽐如⽹络频繁拥塞，拥塞点⼤多在32KB以上。如果把发送窗⼝限制在32KB，就可以避免触碰拥塞点。(2)真实环境中，发送窗⼝常常可以达到数⼗个MSS。>> window size(1)每个包的TCP层都含有window size(也就是win=)的信息，这不是发送窗⼝，⽽是在向对⽅声明⾃⼰的接收窗⼝。(2)假如接收⽅处理数据的速度跟不上接收数据的速度，缓存就会被占满，从⽽导致接收窗⼝为0。(3)发送窗⼝决定了⼀⼝⽓能发多少字节，⽽MSS决定了这些字节要分多少个包发完。>> Window Scale(1)Window Scale的作⽤是向对⽅声明⼀个 Shift count，我们把它作为2的指数，再乘以TCP头中定义的接收窗⼝，就得到真正的TCP接收窗⼝了。(2)要注意Wireshark是根据Shift count计算出这个结果的，如果抓包时没有抓到三次握⼿，Wireshark就不知道该如何计算，所以我们有时候会很莫名地看到⼀些极⼩的接收窗⼝值。还有些时候是防⽕墙识别不了Window Scale，因此对⽅⽆法获得Shift count，最终导致严重的性能问题。>> 其他窗⼝算法(1)Westwood算法(Saverio先⽣提出)根据接收⽅回应的Ack来推算出有多少包已经被送达接收⽅，从⽽更精确地估算发⽣拥塞时的带宽，最后再依据带宽来确定新的拥塞窗⼝。(2)FlightSize引进FlightSize只是为了得到⼀个安全的临界窗⼝值，⽽不是像Westwood+⼀样追求⽐较理想的窗⼝。它的理论依据也并不复杂：当⽹络状况良好时，数据包的RTT（往返时间）⽐较稳定，这时候就可以增⼤拥塞窗⼝；当⽹络开始繁忙时，数据包开始排队，RTT就会变⼤，这时候就需要减⼩拥塞窗⼝了TCP重传>> 拥塞窗⼝这个策略就是在发送⽅维护⼀个虚拟的拥塞窗⼝，并利⽤各种算法使它尽可能接近真实的拥塞点。⽹络对发送窗⼝的限制，就是通过拥塞窗⼝实现的。>> RTO从发出原始包到重传该包的这段时间称为RTO。>>如何查看重传(1)单击 Analyze–>Expert Info Composite菜单，就能在Notes标签看到它们了。点开+号还能看到具体是哪些包发⽣了重传。(2)重传对性能的影响是极⼤的，即便是0.5%的⽐例也会使性能⼤幅度下降。>> 超时重传超时重传对传输性能有严重影响。原因之⼀是在RTO阶段不能传数据，相当于浪费了⼀段时间；原因之⼆是拥塞窗⼝的急剧减⼩，相当于接下来传得慢多了。>>快速重传后续的包到达接收⽅时，接收⽅会发现其Seq号⽐期望的⼤，所以它每收到⼀个包就Ack⼀次期望的Seq号，以此提醒发送⽅重传。当发送⽅收到3个或以上重复确认（Dup Ack）时，就意识到相应的包已经丢了，从⽽⽴即重传它。这个过程称为快速重传。之所以称为快速，是因为它不像超时重传⼀样需要等待⼀段时间。由于⼀般乱序的距离不会相差太⼤，⽐如2号包也许会跑到4号包后⾯，但不太可能跑到6号包后⾯，所以限定成3个或以上可以在很⼤程度上避免因乱序⽽触发快速重传。>> 快速恢复临界窗⼝值应该设为发⽣拥塞时还没被确认的数据量的1/2（但不能⼩于2个MSS）。然后将拥塞窗⼝设置为临界窗⼝值加3个MSS，继续保留在拥塞避免阶段。这个过程称为快速恢复。>> 总结(1)没有拥塞时，发送窗⼝越⼤，性能越好。所以在带宽没有限制的条件下，应该尽量增⼤接收窗⼝，⽐如启⽤Scale Option。(2)如果经常发⽣拥塞，那限制发送窗⼝反⽽能提⾼性能，因为即便万分之⼀的重传对性能的影响都很⼤。(3)超时重传对性能影响最⼤，因为它有⼀段时间（RTO）没有传输任何数据，⽽且拥塞窗⼝会被设成1个MSS，所以要尽量避免超时重传。(4)快速重传对性能影响⼩⼀些，因为它没有等待时间，⽽且拥塞窗⼝减⼩的幅度没那么⼤。(5)SACK和NewReno有利于提⾼重传效率，提⾼传输性能。(是否启⽤SACK是在TCP三次握⼿时协商决定的。只要双⽅中有⼀⽅没有发“SACK_PERM=1”，那该连接建⽴之后就不会⽤到 SACK。)(6)丢包对极⼩⽂件的影响⽐⼤⽂件严重。因为读写⼀个⼩⽂件需要的包数很少，所以丢包时往往凑不满3个Dup Ack，只能等待超时重传了。⽽⼤⽂件有较⼤可能触发快速重传。UDP协议>> 协议说明(1)UDP协议头中，只有端⼝号、包长度和校验码等少量信息，总共就8个字节。(2)UDP不像TCP⼀样在乎双⽅MTU的⼤⼩。它拿到应⽤层的数据之后，直接打上UDP头就交给下⼀层了。那么超过MTU的时候怎么办？在这种情况下，发送⽅的⽹络层负责分⽚，接收⽅收到分⽚后再组装起来，这个过程会消耗资源，降低性能。(3)UDP 没有重传机制，所以丢包由应⽤层来处理。>> 分⽚机制的弱点接收⽅之所以知道什么时候该把分⽚组装起来，是因为每个包⾥都有“More fragments”的flag。1表⽰后续还有分⽚，0 则表⽰这是最后⼀个分⽚，可以组装了。如果⿊客持续快速地发送flag为1的UDP包，接收⽅⼀直⽆法把这些包组装起来，就有可能耗尽内存。NFS协议>> 协议说明(1)NFS 服务器提供了/code 和/document两个共享⽬录，分别被挂载到多台客户端的本地⽬录上。当⽤户在这些本地⽬录读写⽂件时，实际是不知不觉地在NFS服务器上读写。(2)看到portmap请求没有得到回复，就可以考虑防⽕墙对111端⼝的拦截；如果发现mount请求被服务器拒绝了，就应该检查该共享⽬录的访问控制。(3)NFS对客户端的访问控制是通过IP地址实现的。创建共享⽬录时可以指定哪些IP允许读写，哪些IP只允许读，还有哪些IP连挂载都不允许(4)NFS协议是只认UID不认⽤户名的，建议⽤户名和UID的关系在每台客户端上都保持⼀致。(5)应⽤层：由于NFS是基于RPC的协议，所以Wireshark把它分成NFS和RPC两⾏来显⽰。>> async和sync⽅式(1)假如mount时使⽤了sync参数，客户端会先发送⼀个WRITE Call，等收到Reply后再发下⼀个Call，也就是说WRITE Call和WRITEReply是交替出现的。除此之外，还有什么办法在包⾥看出⼀个写操作是async还是sync呢？答案就是每个WRITE Call上的“UNSTABLE”和“FILE_SYNC”标志，前者表⽰async，后者表⽰sync。(2)每个 WRITE Call写多少数据也是影响写性能的重要因素，我们可以在mount时⽤wsize参数来指定每次应该写多少。不过在有些客户端上启⽤sync参数之后，⽆论wsize定义成多少都会被强制为 4KB，从⽽导致写性能⾮常差。那为什么还有⼈⽤ sync ⽅式呢？答案是有些特殊的应⽤要求服务器收到sync的写请求之后，⼀定要等到存盘才能回复 WRITE Reply，sync 操作正符合了这个需求。由此我们也可以推出COMMIT对于sync写操作是没有必要的。(3)从Write Call⾥的FILE_SYNC可以知道，虽然在mount时并没有指定sync参数，但是noac把写操作强制变成sync⽅式了，性能⾃然也会下降。CIFS协议>> 协议说明(1)Windows上⼀般使⽤什么共享协议呢？它就是微软维护的SMB协议，也叫Common Internet File System（CIFS）。(2)CIFS协议有三个版本：SMB、SMB2和SMB3，⽬前SMB和SMB2⽐较普遍。(3)CIFS 只能基于 TCP。(4)CIFS服务器上的端⼝号为445。>> CIFS连接过程(1)第⼀个CIFS操作是Negotiate（协商）。(2)协商好版本之后，就可以建⽴CIFS Session了。Session Setup的主要任务是⾝份验证，常⽤的⽅式有Kerberos和NTLM。(3)点开这两个Tree Connect包，最有价值的信息当属服务器返回的Tree ID。从此之后客户端就能利⽤这个ID去访问/dest共享的⼦⽬录和⼦⽂件。(4)Create是CIFS中⾮常重要的⼀个操作。⽆论是新建⽂件、打开⽬录，还是读写⽂件，都需要Create。(5)CIFS采⽤了Oplock（机会锁）来解决这个问题。Oplock有Exclusive、Batch 和 Level2三种形式。Exclusive允许读写缓存，Batch允许所有操作的缓存，⽽ Level 2 只允许读缓存。>> SMB3的突破(1)在 SMB3 的复制过程中，我们只是在⽹络上传输了⼀些指令，⽽⽂件内容并没有出现在⽹络上，因为复制数据完全由服务器⾃⼰完成了。(2)SMB3的另⼀个破天荒改进是在CIFS层实现了负载均衡。与其他CIFS版本不同，⼀个SMB3Session可以基于多个TCP连接。DNS协议>> 协议说明⽤ D N S 解析成 IP 地址，再通过 IP 地址找到服务器。⽐如打开公司电脑，⽤域账号登录操作系统，就是依靠DNS找到Domain Controller来验证⾝份。>> 递归查询和迭代查询(1)递归：客户端只发⼀次请求，要求对⽅给出最终结果。(2)迭代：客户端发出⼀次请求，对⽅如果没有授权回答，它就会返回⼀个能解答这个查询的其它名称服务器列表，客户端会再向返回的列表中发出请求，直到找到最终负责所查域名的名称服务器，从它得到最终结果。⽤dig命令加上“+trace”参数可以强迫客户端采⽤迭代查询。>> 记录说明PTR记录：与A记录的功能相反，它能从IP地址解析到域名。SRV记录：Windows的域管理员要特别关⼼SRV记录，因为它指向域⾥的资源。CNAME 记录：⼜称为 Alias 记录，就是别名的意思。>> 循环⼯作（round-robin）模式这个特性可以⼴泛应⽤于负载均衡。⽐如某个⽹站有10台Web服务器，管理员就可以在DNS⾥创建10个同名记录指向这些服务器的IP。由于不同客户端查到的结果顺序不同，⽽且⼀般会选⽤结果中的第⼀个IP，所以⼤量客户端就会被均衡地分配到10台Web服务器上。>> 安全性(1)DNS服务器被恶意修改指向钓鱼⽹站是很危险的事，即便是配了正规的DNS服务器，也是有可能中招的。⽐如正规的DNS服务器遭遇缓冲投毒之后，也会变得不可信；(2)DNS 除了能⽤来欺骗，还能当做攻击性武器。著名的 DNS 放⼤攻击就很让⼈头疼。⽐如执⾏“dig ANY "时，DNS会回复⼀个很⼤的包，在这个包⾥伪造⼀个想要攻击的源地址，那该地址就会莫名收到 DNS服务器3111字节的回复。利⽤这个放⼤效应，⿊客只要控制少量电脑就能把⼀个⼤⽹站拖垮了。FTP协议>> 协议说明(1)FTP常被⽤来传播⽂件，尤其是免费软件；另⼀个⼴泛应⽤是采集⽇志，我们可以让服务器发⽣故障之后，⾃动通过FTP把⽇志传回⼚商。(2)FTP服务器的控制端⼝21。(3)FTP 是⽤明⽂传输的>> 控制连接和数据连接客户端连接FTP服务器的21端⼝仅仅是为了传输控制信息，我们称之为“控制连接”。当需要传输数据时，就重新建⽴⼀个 TCP 连接，我们称之为“数据连接”。不但在下载⽂件时如此，就连执⾏ls命令来列举⽂件时，也需要新建⼀个数据连接。>>被动模式和主动模式(1)如果你为FTP配置过防⽕墙，还会发现这种⽅式带来了⼀个更加严重的问题—由于数据连接的三次握⼿是由服务器端主动发起的（我们称之为主动模式），如果客户端的防⽕墙阻挡了连接请求，传输就失败了，此时可以试⼀下FTP的被动模式。(2)Passive mode即表⽰被动模式。(3)Windows⾃带的ftp命令似乎只⽀持主动模式。HTTP协议>> 协议说明由于海量⽂件不适合传统的⽬录结构，所以云存储⼀般使⽤对象存储的⽅式—客户端访问⽂件时并不使⽤其路径和⽂件名，⽽是使⽤它的对象ID。>> HTTPS解析(1)使⽤HTTPS搜索时抓的包，注意服务器端⼝是443，关键词也被加密到了“Encrypted Application Data”⾥。(2)导出key并导⼊wireshark：单击Wireshark的Edit–>Preferences–>Protocols–>SSL–>RSA keys list。然后按照IPAddress,Port,Protocol,Private Key 的格式填好，此时https中的内容就可以看见了。(解码所⽤到的密钥只能在服务器端导出)Kerberos协议>> 协议说明(1)⾝份认证协议也叫 Kerberos，它有着⾮常⼴泛的应⽤，⽐如Windows域环境的⾝份认证就会⽤到它。(2)Kerberos 采⽤的⽅法是引⼊⼀个权威的第三⽅来负责⾝份认证。这个第三⽅称为KDC，它知道域⾥所有账号和资源的密码。(3)把⽣成的字符串“{时间戳}Kclt”、账号A 的信息，以及⼀段随机字符串发给KDC。这样就组成了Kerberos的⾝份认证请求AS_REQ。>> 重放攻击⿊客可能在⽹络上截获字符串“{时间戳} Kclt”，然后伪装成账户A来骗认证。这种⽅式称为重放攻击。重放攻击的伪装过程需要⼀段时间，所以 KDC 把解密得到的时间戳和当前时间作对⽐，如果相差过⼤就可以判断是重放攻击了。假如采⽤与时间⽆关的字符来加密，则⽆法避开重放攻击，这就是我们必须在域中同步所有机器时间的原因。