Wireshark网络分析就这么简单

tcpdump抓包命令：

root#tcpdump -I eth0 -s 80 -w /tmp/tcpdump.cap

注：其中80表示，只抓每一个包的前80个字节。

 

抓包时就筛选本身须要的包：

Wireshark抓包前Capture→Options，在Capture Filter中输入“host 10.10.100.10”，而后再抓。

tcpdump抓包对应的命令：

root#tcpdump -I eth0 host 10.10.100.10 -w /tmp/tcpdump.cap

 

小技巧：

ping<IP> -n 1 -l 1

这样抓包看到的，Data位为1，当请求方出口IP为PAT地址时，便于定位测试ping包是否可达。

 

 

过滤表达式：

1. 根据IP和端口：过滤“IP为10.10.100.10且TCP端口为445”，则输入“ip.addr eq 10.10.100.10 && tcp.port eq 445”
2. 根据协议过滤：NFS共享挂在失败，查看portmap和mount两个协议，则输入“portmap || mount”
3. 数据包跟踪：选中感兴趣的包，选择Follow TCP/UDP Stream。
4. 鼠标帮助过滤：选中感兴趣的包，右键Prepare a Filter→Selected能够自动生成过滤表达式。若是选择Apply as Filter→Selected则此表达式还会自动执行。

 

Wireshark自动分析：

1. 单击Analyze→Expert Information能够看到不一样级别的提示，如重传统计，链接创建和重置统计
   

    

2. 单击Statistics→Service Response Time选定协议名称，能够获得响应时间统计。
   

    

3. 单击Statistics→TCP Stream Graph
   
   

    

4. 单击Statistics→TCP Stream Graph能够生成统计图
   

    

5. 单击Statistics→I/O Graphs能够看到统计信息，如平均流量等等：
   

    

6. 经过“Ctrl+F”搜索关键字：选string按钮，而后输入error搜索：
   

    

   
   
   
    

   NFS协议的抓包分析：

    

   客户端访问NFS服务器的portmap端口（tcp111），询问NFS进程的端口号，默认NFS的端口号时2049，客户端再访问TCP2049，mount挂载动做时file handle动做。

    

   另外NFS建立文件时，是认UID的，同一个UID号再另外一台机器上看到的用户就会不同了。

    

    

    

   NFS协议的细节动做：

    

   NFS时多个READ-CALL连续发出，和window的CIFS不一样，CIFS时一个一个来的。

    

   NFS进入文件夹的动做时ACCESS-CALL，查找是LOOKUP-CALL，建立是CREATE-CALL，写入是WRITE-CALL，写完了提交时COMMIT-CALL（COMMIT确认了才算数据真正写好），看看文件属性是GETATTR-CALL

    

   async和sync的写方式，async时多个WRITE-Call同时发出，sync时一个一个WRITE-Call执行（commit对sync无心义），分辨方法时看WRITE-CALL上的UNSTABLE和FILE_SYNC标志，前者是async，后者表示sync。

    

   有人mount时跟上noac参数，读写性能不好，是由于noac会强制写操做为sync参数，读操做时频繁GETATTR，致使性能受影响。

    

    

    

   MTU的交互：

    

   TCP在三次握手过程当中就会告知对方本身的MSS（Maximum Segment Size），MSS加上TCP头（20）和IP头（20）的长度就是MTU。

   
    

   强制nslookup使用tcp协议：

   root#nslookup

   >set vc

    

   TCP三次握手：

   第一个数据段的Seq为1，长度1448，因此数据段2的Seq号就是1449，数据段2长度为1448，数据段3的Seq号为2897。接收方发送的ACK号其实就等于发送方的Seq加上长度，接收方以此来判断少了哪些包，要求重传。

   咱们之因此在Wireshark上看到Seq=0，是由于Wireshark启用了Relative Sequence Number，能够在“Edit→Preferences→protocals→TCP”里设置。

    

   Windows滑动窗口：

   ACK的数据包中有win=1460或者win=2920之类的，表示接收方一次能够接收一个或两个MSS，两个就是发送方能够一次发两个包来等对方确认。

   若是接收方处理速度跟不上接收数据的速度，缓存就会满了，从而致使接收窗口为0，发送方就会将本身的发送窗口限制为0，以下图。

    

   发送窗口决定一次能发多少字节，而MSS决定这些字节分几个包发完。

   发送方一次发N个包，接收方有时候收到不少包时，只要回复最后一个就能确认它收到了全部N个包。

   历史插曲：

   TCP刚发明，接收窗口被定义为65535字节，TCP包头只给接收窗口值留了16bit，没法突破65535的，RFC1323中三次握手时，把本身的Window Scale信息告知对方，因为Window Scale放在TCP头以外的Option中，不用改TCP头设计，Window Scale做用向对方声明一个Shift count，咱们把它作成2的指数，乘以TCP包头中定义的接收窗口，获得真正的TCP接收窗口。

   以下图，5856就是183乘以32。
   

    

   TCP慢速启动：

   刚开始是连续翻倍增长每一次发送MSS的数量，到必定数量后开始逐渐+1递增。

    

   RTO是收不到确认，等待一段时间后再发，从发原始包到重发的时间。

    

   遇到拥塞重传后，从1开始从新慢启动，临界值设定为上次拥塞时的一半。
   

    

   快速重传：

   接收方收到的Seq比指望的大时，因此它没收到一个包就Ack一次指望的Seq号，发送方收到3个或以上重复ACK时，就意识到相应的包已经丢了，从而重传。为何要规定3个Dup Ack呢，为了在很大程度上避免因乱序而触发重传。

    

   拥塞避免阶段收到快速重传，临界窗口应该设为发生拥塞时还没被确认的数据量的一半，而后将拥塞窗口设置为临界窗口值加3个MSS，继续保留在拥塞避免阶段，这个过程被称为快速恢复。以下：

    

   TCP延迟确认：

   若是收到一个包以后暂时没有什么数据须要发送对方，那就延迟一段时间（在windows默认为200ms），假如这段时间刚好有数据要发送，那确认信息就随数据一同发出。

   微软KB328890提供关闭延迟确认的步骤。

   Nagle算法：

   在发出的数据没有被确认以前，假如又有小数据生成，那就把小数据收集起来，凑满一个MSS或者等收到确认后再发送。

   UDP协议的优点：

   1. UDP净荷高。
   2. 没有Seq和Ack，不创建链接，效率高

   UDP协议的劣势：

   1. 没有MTU的概念，网络层分片致使性能占用。
   2. 没有重传机制，应用层决定丢包处理。
   3. 分片机制容易遭受攻击。
   
   
   

   CIFS:

   CIFS使用TCP的445端口。支持SMB，SMB2，SMB3（其中SMB2广泛）

   客户端把本身全部支持版本告知服务器端，服务器端挑出回复本身支持的最高版本。

   CIFS的session身份验证方式有Kerberos和NTLM。

   Session Setup后客户端打开共享路径，操做称为Tree Connect，服务器返回的Tree ID，客户端利用这个ID去访问目录和文件。Tree Connect不检查权限，即便无权限客户也能获得，检查权限的工做由Create操做完成。Create操做是涉及新建，打开，读取等动做。

   常见问题：

   1. 若是对文件夹禁止用户访问，可是下面一个文件容许访问，则用户没法打开对应目录，可是能直接打开那个文件。
   2. Windows的备份是Create请求中“Backup Intent”设1，读取为0，服务器能够根据这个字段来根据备份和读取权限来决定是否准许访问。
   3. Access Mask是“读写”，Share Access Mask是“读”，若是有人读写，另外一我的请求读写就会收到“Sharing Violation”错误。
   4. CIFS来解决缓存数据一致性，采用Oplock（机会锁），有Exclusive（容许读写缓存），Batch（容许全部操做缓存）和Level2（容许读缓存）三种形式。

   （1）windows xp的SMB是一去一回，windows 7是多发多收，因此在网络质量很差的地方，差距挺大。

   （2）Windows Explorer从CIFS上复制文件比Robcopy和EMCopy慢，是由于它是单线程的。

   （3）CIFS共享中，复制一个文件粘贴到同一个目录是把内容复制到客户端内存，再从客户端内存写到服务器上，，而粘贴到客户端本地硬盘固然会比它快。SMB3才改进了这点，实现服务器端本地复制。

   （4）剪切粘贴很是快是由于只是一个“rename”操做。

   （5）SMB2没有SMB协议这么啰嗦，因此读性能提升不少。

    

   SMB3（Win8和10和2012）改进了复制粘贴在网络上跑两次的问题，是运用给客户端一个Token，客户端利用Token给服务器发写请求实现的。

   SMB3还实现了双网卡在CIFS层的负载均衡，一个SMB3 Session的诸多TCP分摊在两块网卡上，即便网卡瘫了一块，SMB3链接还能存在。

   SMB3还把文件锁之类的信息存在硬盘上，当双机头的架构中，主机头挂了，备机头起来便能得到此信息，从而提供无缝服务。

    

   DNS相关：

   A记录：域名解析到IP

   PTR记录：IP地址解析到域名（nslookup 跟上IP）

   SRV记录：查找域控

    

   CNAME记录：别名

    

   DNS的放大攻击：伪造DNS请求包的源IP，大量发送请求包，那个IP就会收到彻底不对称般大量的DNS响应包。

    

   FTP主动模式：客户端经过21端口链接服务器，可是数据传输是由服务器从20端口主动链接客户端协商好的随机高端口。

   FTP被动模式：数据传输时，也是由客户端发起链接的。

    

   根据密钥解密https流量：

   Edit→Preferences→Protocols→SSL→RSA keys list，而后按照IP，Port，Protocol，Private Key格式填写RSA keys list一行

    

   Kerberos认证原理：

   原始版本：

   A用hash把密码转成一把密钥Kclt，用kclt把当前时间戳加密生成一个字符串“时间戳Kclt”，把“时间戳kclt”和账号A的信息，以及一段随机字符串发给KDC组成身份认证请求AS_REQ。KDC收到AS_REQ后，读到账号A的信息，调出密码，在用hash转换成Kclt解开“时间戳Kclt”，能解开就代表请求是账号A生成的。

   选用时间戳是为了防范黑客的重放攻击，用时间戳，只要NTP是同步的，时间间隔相差太大就认为是重放攻击。

   KDC在用Kclt加密随机字符串，账号A拿到回复后可否解出就能判断KDC的真假。

   以上过程当中双方都没有向对方发送密码，即使一方是假的也不会泄密。

   可是有问题就是每次认证都要调出密码执行hash解密，对KDC的性能要求太大。

    

   改进版本：

   KDC生成两把同样的密钥Kclt-Kdc，把密码hash成Kkdc，而后用它加密那把委托给A的密钥，委托密钥称为TGT，KDC只需记住本身的Kkdc，就能解开委托给账号的TGT，从而得到与该账号之间的密钥，KDC的负担大大下降。KDC回复给A的AS_REP须要包含TGT，“（Kclt-kdc，时间戳，随机字符串）Kclt”

   A收到AS-REP后利用Kclt机密“（Kclt-kdc，时间戳，随机字符串）Kclt”，判断KDC真实性，把Kclt-kdc和TGT保存备用。

    

   帐号A请KDC帮忙认证资源B：

   A将TGT，账号A信息，时间戳，要访问的B的资源发给KDC，这个请求叫TGS-REQ。

   TGS_REQ=TGT,{账号A信息，时间戳}Kclt-kdc，资源B相关信息

   KDC收到TGS-REQ后，用Kkdc解密TGT获得Kclt-kdc，再用Kclt-kdc解密A的信息和时间戳验证身份，确认A为真。

   KDC生成两把相同的密钥给A和B使用，称为Kclt-srv，其中一把密钥给A，另外一把委托A给B，Kerberos把B的密码hash成Ksrv，而后用它加密委托给A转交B的Kclt-srv，只能B能解开这条Ticket。

   Ticket={账号A的信息，Kclt-srv}Ksrv

   TGS_REP={Kclt-srv}Kclt-kdc，Ticket

   帐号A收到TGS_REP后，用Kclt-kdc解开{Kclt-srv}Kclt-kdc，获得Kclt-srv，Ticket发给B，之后屡次访问B均可用这个Ticket，不用每次向KDC申请，下降KDC负担。

    

   账号A和账号B互相认证：

   账号A给B发送“{账号A的信息，时间戳}”Kclt-srv，以及上一步收到的Ticket，请求称为AP_REQ。

   AP_REQ=“{账号A的信息，时间戳}Kclt-srv”，Ticket

   B能用Ksrv解开Ticket获得Kclt-srv，用Kclt-srv解开“{账号A的信息，时间戳}Kclt-srv”，B就能确认A为真，回复AP_REP来证实本身也是真的。

   AP_REP={时间戳}Kclt-srv

   账号A利用Kclt-srv解密AP-REP，经过获得时间戳来判断对方是否为真。

    

   Wireshark解密查看必须Edit→Preferences→Protocols→KRB5，keytab file输入key的路径才能解密。

    

   客户能够用\\IP地址 访问，可是用域名就不行：

   用IP是NTLM身份认证的，用域名则是Kerberos认证的，机制不同，注意时钟，NTLM不会由于怀疑重放攻击拒绝访问。

    

   SACK机制（Selective Ack）：

   若是一个包丢了，接收方发现了，那这个包后续的包也要重传，由于没法肯定是否也丢失，可是接收方虽然知道丢了哪些包无法告知发送发，RFC2018中给出了方案，SACK启用的状况下，接收方能告诉发送方，它只须要重发的那个包，能够减小大量没必要要的重传。