TCP/IP协议安全复习材料

一、网络设备与TCP连接建立

1.1 核心网络设备：

在TCP/IP网络中，“网关”是连接不同网络的关键设备，核心功能

• 局域网内设备（如电脑、手机）的IP地址属于“私有IP”（如192.168.1.0/24网段），无法直接在互联网中路由；
• 当局域网设备需要访问互联网（公网）时，数据包会先发送到网关，网关将“私有IP封装的数据包”转换为“公网IP封装的数据包”，再转发到互联网；
• 反之，互联网返回的数据包会先到达网关，网关再转换为私有IP，转发到局域网内的目标设备；
• 网关与路由器的关系：通常“网关”是路由器的一个功能（路由器可作为网关），但网关不一定是路由器（如服务器也可配置为网关），核心记住“网关是跨网络通信的必经节点”。

1.2 TCP三次握手

TCP协议通过“三次握手”建立可靠连接，需明确每一步的“标志位”“序列号”“确认号”变化，这是理解TCP连接的基础：

1. 第一步（客户端→服务器）：
   • 报文类型：SYN报文（标志位仅SYN=1）；
   • 序列号（Seq）：客户端生成的随机初始值（如Seq=0，实际为随机数，示例用0简化）；
   • 目的：向服务器发起连接请求，告知服务器“客户端的初始序列号”；
2. 第二步（服务器→客户端）：
   • 报文类型：SYN+ACK报文（标志位SYN=1、ACK=1）；
   • 序列号（Seq）：服务器生成的随机初始值（如Seq=0）；
   • 确认号（Ack）：客户端初始序列号+1（如Ack=0+1=1），表示“服务器已收到客户端Seq=0及之前的所有数据，期待下一个数据的序列号为1”；
   • 目的：同意客户端的连接请求，告知服务器的初始序列号，并确认收到客户端的请求；
3. 第三步（客户端→服务器）：
   • 报文类型：ACK报文（标志位仅ACK=1）；
   • 序列号（Seq）：客户端初始序列号+1（如Seq=0+1=1）；
   • 确认号（Ack）：服务器初始序列号+1（如Ack=0+1=1），表示“客户端已收到服务器Seq=0及之前的所有数据，期待下一个数据的序列号为1”；
   • 目的：确认收到服务器的同意请求，TCP连接正式建立；

关键注意点：三次握手的核心是“交换初始序列号”和“确认接收能力”，缺少任何一步都会导致连接无法建立（如服务器未回复SYN+ACK，客户端会超时重传SYN报文）。

二、HTTP协议深化与Cookie安全

2.1 HTTP状态码详解

HTTP状态码是服务器对请求的“处理结果反馈”，需掌握常见状态码的含义及客户端处理逻辑：

• 2xx（成功类）：
  • 200 OK：请求完全成功，服务器返回请求的资源（如HTML页面、图片）；
• 3xx（重定向类）：
  • 301 Moved Permanently：“资源永久重定向”，表示该资源已永久迁移到新URL，客户端后续应直接访问新URL（浏览器会缓存该重定向关系）；
  • 302 Found：“资源临时重定向”，表示该资源暂时迁移到新URL，客户端需向新URL重新发送请求，但后续请求仍可访问原URL（浏览器不缓存重定向关系）；
  • 重定向的核心：服务器通过“Location”响应头字段告知新URL，客户端自动跳转；
• 4xx（客户端错误类）：
  • 400 Bad Request：“客户端请求格式错误”（如请求参数缺失、格式非法）；
  • 401 Unauthorized：“未授权访问”（如访问需要登录的资源，但客户端未携带登录凭证）；
  • 403 Forbidden：“服务器拒绝请求”（如客户端有登录凭证，但无访问该资源的权限）；
  • 404 Not Found：“请求的资源不存在”（如URL输入错误、资源已删除）；
• 5xx（服务器错误类）：
  • 500 Internal Server Error：“服务器内部错误”（如服务器代码bug、数据库连接失败）；
  • 503 Service Unavailable：“服务器暂时不可用”（如服务器过载、维护中）；

记忆技巧：2xx“成”、3xx“转”、4xx“客错”、5xx“服错”。

2.2 Cookie属性与安全防御

Cookie是Web应用中存储客户端状态的核心机制，不同属性对应不同的安全防御场景，需明确各属性的作用：

1. HttpOnly：
   • 作用：禁止JavaScript脚本读取Cookie；
   • 防御场景：XSS（跨站脚本攻击）——XSS攻击者通常通过注入恶意JavaScript代码（如<script>alert(document.cookie)</script>）窃取Cookie，HttpOnly属性可阻止脚本读取Cookie，从源头防御这种窃取；
   • 注意：HttpOnly不影响Cookie随HTTP请求自动发送给服务器，仅限制脚本读取；
2. Secure：
   • 作用：仅允许Cookie在“HTTPS加密连接”中传输，HTTP明文连接中不传输Cookie；
   • 防御场景：网络嗅探——HTTP明文传输时，Cookie（如登录凭证）会以明文形式在网络中传输，攻击者可通过抓包工具（如Wireshark）窃取；HTTPS通过SSL/TLS加密数据，即使抓包也无法解密，Secure属性确保Cookie仅在加密连接中传输；
3. Max-Age/Expires：
   • 作用：设置Cookie的有效期，过期后客户端会自动删除Cookie；
   • 防御场景：Cookie重放攻击——攻击者窃取Cookie后，若Cookie长期有效，可长期伪造客户端请求；设置有效期（如1小时），即使Cookie被窃取，过期后也无法使用，缩短攻击窗口；
   • 区别：Max-Age以“秒”为单位（如Max-Age=3600表示1小时），Expires指定具体过期时间（如Expires=Wed, 10 Jul 2024 12:00:00 GMT）；
4. SameSite：
   • 作用：限制Cookie仅在“同站点请求”中发送，禁止在“跨站点请求”中发送；
   • 防御场景：CSRF（跨站请求伪造）——CSRF攻击者通过第三方网站（如钓鱼网站）伪造客户端请求（如转账请求），若Cookie可随跨站请求发送，服务器会误认为是客户端本人操作；SameSite属性阻止Cookie随跨站请求发送，从而防御CSRF；
   • 常见值：SameSite=Strict（仅同站点请求发送）、SameSite=Lax（部分跨站请求允许发送，如链接跳转）。

三、ARP协议与局域网安全

3.1 ARP协议工作原理

ARP协议的核心是“IP地址→MAC地址”的解析，需结合局域网通信流程理解：

1. 局域网通信的本质：局域网内设备（如两台电脑）通过“数据链路层”通信，数据链路层的寻址依赖“MAC地址”（每个网卡的唯一标识，如00:11:22:33:44:55），因此必须知道目标设备的MAC地址才能发送数据；
2. ARP的必要性：应用层程序（如浏览器、QQ）通常仅知道目标设备的“IP地址”（如通过DNS解析获取），不知道MAC地址，因此需要ARP协议完成“IP→MAC”的映射；
3. 完整ARP交互流程（以主机A→主机B为例）：
   • 前提：主机A知道主机B的IP（如192.168.1.3），不知道MAC；
   • 步骤1：主机A检查自身“ARP缓存表”，若有192.168.1.3对应的MAC，直接使用；若无，执行下一步；
   • 步骤2：主机A发送“ARP请求报文”（广播发送，目的MAC=ff:ff:ff:ff:ff:ff），报文中包含“目标IP=192.168.1.3”和“主机A的IP-MAC（192.168.1.2 + 00:11:22:33:44:55）”；
   • 步骤3：局域网内所有设备（包括主机B）都会接收ARP请求报文，检查“目标IP”是否与自身IP一致：
     • 不一致的设备：忽略该报文；
     • 一致的设备（主机B）：生成“ARP响应报文”，报文中包含“主机B的IP-MAC（192.168.1.3 + aa:bb:cc:dd:ee:ff）”，通过“单播”发送给主机A（目的MAC=主机A的MAC）；
   • 步骤4：主机A收到ARP响应报文后，将“192.168.1.3 + aa:bb:cc:dd:ee:ff”存储到ARP缓存表中，后续与主机B通信时，直接从缓存中获取MAC地址。

3.2 ARP攻击类型与防御措施

3.2.1 ARP欺骗攻击的两种核心类型

ARP协议无身份验证机制，攻击者可发送伪造的ARP响应报文，篡改目标设备的ARP缓存，常见攻击类型有两种：

1. 欺骗网关：
   • 攻击目标：局域网网关；
   • 攻击过程：攻击者向网关发送伪造的ARP响应报文，报文中将“客户端IP（如192.168.1.2）”对应的MAC地址改为“攻击者的MAC地址（如cc:dd:ee:ff:00:11）”；
   • 后果：网关后续向该客户端发送的所有数据（如互联网返回的网页数据），都会转发到攻击者的设备，攻击者可窃取数据或篡改数据后再转发给客户端（“中间人攻击”）；
2. 欺骗客户端：
   • 攻击目标：局域网内的客户端（如某台电脑）；
   • 攻击过程：攻击者向客户端发送伪造的ARP响应报文，报文中将“网关IP（如192.168.1.1）”对应的MAC地址改为“攻击者的MAC地址”；
   • 后果：客户端后续向网关发送的所有数据（如访问网页的请求），都会转发到攻击者的设备，攻击者同样可窃取或篡改数据；

两种攻击的共性：都是通过篡改“IP-MAC映射关系”，使目标设备的流量经过攻击者，实现“流量劫持”。

3.2.2 ARP攻击的通用防御措施

1. 配置静态ARP缓存表：
   • 原理：手动在目标设备（如网关、客户端、服务器）上绑定“关键IP-MAC”映射关系，静态ARP条目不会被动态ARP响应报文篡改；
   • 操作示例（Windows系统）：
     • 查看ARP缓存：arp -a；
     • 添加静态ARP：arp -s 192.168.1.1 00-11-22-33-44-55（绑定网关IP与网关MAC）；
   • 适用场景：局域网设备较少、MAC地址固定的环境（如服务器机房）；
2. 启用动态ARP检测（DAI）：
   • 原理：DAI是交换机的安全功能，交换机通过“IP-MAC绑定表”（可手动配置或从DHCP Snooping获取）验证ARP报文的合法性：
     • 若ARP报文的“IP-MAC”与绑定表一致，允许通过；
     • 若不一致（伪造ARP报文），丢弃该报文；
   • 优势：无需在每个客户端配置，由交换机统一防护，适合设备较多的局域网（如校园网、企业网）；
3. 交换机端口绑定IP-MAC：
   • 原理：在交换机上为每个端口配置“允许访问的IP-MAC组合”，仅允许已绑定的IP-MAC通过该端口，防止攻击者伪造IP或MAC地址接入网络；
   • 补充：该措施不仅防御ARP攻击，还能防御IP地址盗用（如他人使用他人的IP地址）。

四、TCP攻击与防御

4.1 TCP协议的可靠传输机制

TCP协议通过多种机制实现“可靠传输”，这些机制也是理解TCP攻击的基础：

1. 序列号与确认号：
   • 序列号（Seq）：标识每个TCP报文段的数据在整个数据流中的位置（如Seq=100表示该报文段的数据是数据流中第100字节开始的部分）；
   • 确认号（Ack）：告知发送端“已收到的最大序列号+1”（如Ack=200表示已收到Seq=199及之前的所有数据，期待下一个数据的Seq=200）；
   • 作用：确保数据不丢失（未收到确认则重传）、不重复（通过序列号去重）、不乱序（按序列号重组）；
2. 校验和：
   • 作用：验证TCP报文段的完整性。发送端计算TCP报文段（包括TCP报头和数据）的校验和，接收端收到后重新计算，若校验和不匹配，说明数据被篡改或损坏，接收端会丢弃该报文段；
3. 滑动窗口：
   • 作用：实现流量控制，避免接收端缓存溢出。接收端通过TCP报头的“窗口大小”字段，告知发送端“当前接收端缓存可容纳的最大数据量”，发送端仅能发送不超过窗口大小的数据；
4. 重传机制：
   • 超时重传：发送端发送数据后启动计时器，超时未收到确认则重传；
   • 快速重传：收到连续3次重复确认则重传（无需等待超时）；
   • 作用：解决数据丢失问题。

4.2 TCP SYN Flood攻击（拒绝服务攻击）

4.2.1 攻击原理

SYN Flood攻击是典型的“拒绝服务攻击（DoS）”，利用TCP三次握手的“半连接状态”耗尽服务器资源：

1. TCP半连接状态：服务器收到客户端的SYN报文后，会回复SYN+ACK报文，并进入“SYN_RCVD”状态（半连接状态），等待客户端回复ACK报文以完成连接建立；
2. 攻击过程：
   • 攻击者伪造大量“虚假源IP地址”（如随机生成不存在的IP），向服务器发送TCP SYN报文（请求建立连接）；
   • 服务器收到SYN报文后，向这些虚假IP发送SYN+ACK报文，但虚假IP无法收到（或不回复）ACK报文，服务器会一直维持“SYN_RCVD”半连接状态；
   • 服务器的“半连接队列”（存储SYN_RCVD状态连接的队列）有容量限制（如默认1024），当大量虚假SYN报文耗尽半连接队列后，服务器无法接收正常客户端的SYN报文，导致正常用户无法建立连接，服务不可用；

核心特点：攻击者无需建立完整连接，仅发送SYN报文即可消耗服务器资源，攻击成本低、效果明显。

4.2.2 防御措施：SYN Cookie

SYN Cookie是防御SYN Flood攻击的经典技术，核心思路是“服务器不存储半连接状态，通过Cookie验证连接合法性”：

1. 原理细节：
   • 步骤1：服务器收到客户端的SYN报文后，不分配半连接队列资源，而是根据“客户端IP、客户端端口、服务器IP、服务器端口、当前时间戳”等信息，生成一个“SYN Cookie”（通过哈希算法计算的随机值）；
   • 步骤2：服务器将SYN Cookie作为“服务器的初始序列号（Seq）”，向客户端发送SYN+ACK报文（此时服务器不存储任何连接信息）；
   • 步骤3：若客户端是正常客户端，会回复ACK报文，ACK报文的“确认号（Ack）”=SYN Cookie + 1；
   • 步骤4：服务器收到ACK报文后，重新计算SYN Cookie（使用与步骤1相同的算法），验证“ACK报文的确认号-1”是否等于计算出的SYN Cookie：
     • 若相等：说明是合法连接，服务器直接建立连接（进入ESTABLISHED状态），无需之前的半连接状态；
     • 若不相等：说明是伪造的ACK报文，服务器丢弃该报文；
2. 优势：服务器无需存储半连接状态，半连接队列耗尽的问题不复存在，即使攻击者发送大量虚假SYN报文，服务器也能正常处理正常客户端的连接请求；
3. 补充措施：
   • 缩短半连接超时时间：默认SYN_RCVD状态超时时间约为30秒，可缩短至5秒，加快释放无效半连接；
   • 限制单IP的SYN报文频率：通过防火墙配置，限制单位时间内单个IP发送的SYN报文数量（如每秒不超过10个），过滤异常流量。

五、DHCP协议深化（租约与冲突处理）

5.1 DHCP地址分配完整流程

DHCP的核心是“自动分配IP”，除了基础的“Discover→Offer→Request→ACK”四步，还需掌握“租约续租”“IP冲突处理”等异常场景：

5.1.1 基础分配流程（正常场景）

1. Discover（发现）：客户端无IP，广播发送Discover，寻找DHCP服务器；
2. Offer（提供）：DHCP服务器广播/单播发送Offer，提供IP、子网掩码、网关、DNS等参数；
3. Request（请求）：客户端选择第一个Offer，广播发送Request，确认使用该IP；
4. ACK（确认）：DHCP服务器广播/单播发送ACK，确认IP分配，客户端开始使用IP（租约计时开始）。

5.1.2 租约续租流程

客户端需在租约到期前续租，避免IP被收回：

1. 第一次续租：租约到期前1/2时间（如24小时租约的12小时），客户端向原DHCP服务器单播发送Request报文，请求续租；
   • 若服务器回复ACK：租约从当前时间重新计时；
   • 若未收到ACK：进入第二次续租；
2. 第二次续租：租约到期前1/4时间（如6小时），客户端向原DHCP服务器广播发送Request报文，请求续租；
   • 若服务器回复ACK：租约延期；
   • 若未收到ACK：租约到期后，客户端释放IP，重新发送Discover请求新IP。

5.1.3 IP冲突处理（DHCP Decline报文）

客户端获取IP后，需检测该IP是否已被其他设备使用（避免IP冲突），核心依赖“Gratuitous ARP”和“DHCP Decline”：

1. Gratuitous ARP（免费ARP）：客户端收到DHCP ACK后，发送“目的IP=自身分配的IP、目的MAC=广播地址”的ARP请求报文，询问“局域网内是否有设备使用该IP”；
2. 冲突处理：
   • 若有设备使用该IP：该设备会回复ARP响应报文，客户端确认IP冲突；
   • 客户端发送“DHCP Decline报文”给DHCP服务器，告知“该IP已被占用，拒绝使用”；
   • DHCP服务器收到Decline后，将该IP标记为“冲突IP”，暂不分配给其他客户端，并重新向该客户端发送Offer报文，提供新的IP。

5.2 DHCP Snooping防御欺骗

DHCP Snooping是交换机防御“DHCP服务欺骗攻击”的核心功能，需明确其工作机制和配置逻辑：

1. DHCP服务欺骗攻击的本质：攻击者伪造DHCP服务器，向客户端发送虚假Offer/ACK报文，分配无效IP或恶意网关，导致客户端无法上网或流量被劫持；
2. DHCP Snooping的核心机制：
   • 端口分类：交换机将所有端口分为“信任端口”和“非信任端口”：
     • 信任端口：仅连接“合法DHCP服务器”的端口（需手动配置），允许通过所有DHCP报文（包括Discover、Request、Offer、ACK）；
     • 非信任端口：连接客户端的端口，仅允许通过“客户端发送的DHCP报文”（如Discover、Request），禁止通过服务器发送的DHCP报文（如Offer、ACK）；
     • 关键逻辑：攻击者通常连接在非信任端口（客户端端口），其发送的虚假Offer/ACK报文会被交换机丢弃，无法到达客户端；
   • IP-MAC绑定表（DHCP Snooping Binding Table）：
     • 交换机通过信任端口接收DHCP ACK报文后，会提取报文中的“客户端IP、客户端MAC、端口号、租约时间”等信息，生成“DHCP Snooping绑定表”；
     • 后续交换机通过非信任端口接收数据包时，会验证“数据包的IP-MAC”是否与绑定表一致，不一致则丢弃，防止IP地址盗用或ARP欺骗；
3. 配置要点：
   • 仅需在交换机上配置，无需修改客户端或DHCP服务器设置；
   • 必须正确指定“信任端口”（连接合法DHCP服务器的端口），否则合法DHCP服务器的Offer/ACK报文也会被丢弃；
   • 适用于所有局域网环境（如校园网、企业网、家庭网），是防御DHCP欺骗的标准方案。

六、DNS协议与欺骗防御

6.1 DNS递归查询的特点

DNS查询中，“递归查询”是客户端获取域名解析结果的主要方式，需明确其交互流程和特点：

1. 交互双方：仅“客户端”与“本地DNS服务器”（如运营商DNS、学校DNS）交互；
2. 完整流程（以解析www.baidu.com为例）：
   • 步骤1：客户端向本地DNS服务器发送DNS查询请求（“解析www.baidu.com的IP”），并要求“递归查询”；
   • 步骤2：本地DNS服务器检查自身缓存，若有www.baidu.com的解析结果，直接返回给客户端；若无，执行下一步；
   • 步骤3：本地DNS服务器向“根DNS服务器”发送查询请求（“www.baidu.com的解析服务器是谁？”）；
   • 步骤4：根DNS服务器不返回最终IP，而是返回“.com顶级域DNS服务器的地址”；
   • 步骤5：本地DNS服务器向“.com顶级域DNS服务器”发送查询请求；
   • 步骤6：.com顶级域DNS服务器返回“baidu.com权威DNS服务器的地址”；
   • 步骤7：本地DNS服务器向“baidu.com权威DNS服务器”发送查询请求；
   • 步骤8：权威DNS服务器存储www.baidu.com的最终解析结果（如IP=180.101.49.11），返回给本地DNS服务器；
   • 步骤9：本地DNS服务器将解析结果缓存，并返回给客户端；
3. 核心特点：
   • 客户端“一站式”请求：仅需向本地DNS服务器发送一次请求，无需与根、顶级域、权威DNS交互；
   • 本地DNS“全程代理”：本地DNS服务器代替客户端完成后续所有查询，客户端仅需等待结果；
   • 结果为“最终解析值”：客户端收到的是“域名对应的IP地址”，而非中间DNS服务器地址。

6.2 DNS欺骗攻击的场景与防御

6.2.1 两种常见欺骗场景

DNS欺骗攻击的核心是“篡改DNS解析结果”，常见场景分为“客户端欺骗”和“服务器欺骗”：

1. 客户端DNS欺骗（本地缓存篡改）：
   • 攻击目标：局域网内的单个客户端（如某台电脑）；
   • 攻击过程：
     • 攻击者在局域网内发送“伪造的DNS响应报文”，该报文的“域名”与客户端正在查询的域名一致（如www.baidu.com），“IP地址”为虚假IP（如钓鱼网站IP）；
     • 由于伪造的DNS响应报文通常比合法DNS服务器的响应更快到达客户端，客户端会优先接收伪造响应，并将“域名-虚假IP”存储到本地DNS缓存中；
     • 后续客户端访问该域名时，直接使用本地缓存的虚假IP，访问钓鱼网站；
   • 特点：攻击范围小（仅单个客户端），依赖“响应速度优先”；
2. 服务器DNS欺骗（DNS缓存污染）：
   • 攻击目标：本地DNS服务器（如学校的DNS服务器）；
   • 攻击过程：
     • 攻击者向本地DNS服务器发送“伪造的DNS响应报文”，篡改本地DNS服务器的缓存（将www.baidu.com解析为虚假IP）；
     • 所有使用该本地DNS服务器的客户端（如全校师生的电脑），查询该域名时都会获取虚假IP，访问钓鱼网站；
   • 特点：攻击范围大（影响所有使用该DNS的客户端），危害更严重。

6.2.2 有效的防御措施

1. 启用DNSSEC（DNS安全扩展）：
   • 原理：DNSSEC通过“数字签名”确保DNS响应的完整性和真实性：
     • 权威DNS服务器对DNS响应数据添加“数字签名”（使用私钥加密）；
     • 本地DNS服务器或客户端收到响应后，使用权威DNS服务器的“公钥”验证签名；
     • 若签名验证通过：说明响应数据未被篡改，可信任；
     • 若签名验证失败：说明响应数据被篡改，丢弃该响应；
   • 优势：从根本上防御DNS欺骗，无论攻击者伪造何种响应，只要签名不匹配，都会被拒绝；
   • 现状：目前主流DNS服务器（如阿里云DNS、谷歌DNS）均支持DNSSEC，客户端需在网络设置中启用DNSSEC验证；
2. 配置静态DNS解析：
   • 原理：在客户端或核心设备上，手动绑定“可信域名-IP”映射关系，静态解析的优先级高于动态DNS缓存；
   • 操作示例（Windows系统）：
     • 编辑C:\Windows\System32\drivers\etc\hosts文件；
     • 添加条目：180.101.49.11 www.baidu.com（绑定www.baidu.com到正确IP）；
   • 优势：简单易操作，适合对关键域名（如网银、办公系统域名）的防护；
3. 使用可信DNS服务器：
   • 原理：避免使用未知或不可信的DNS服务器（如公共WiFi提供的陌生DNS），选择运营商DNS、阿里云DNS（223.5.5.5）、谷歌DNS（8.8.8.8）等可信DNS；
   • 优势：可信DNS服务器通常启用了DNSSEC，且有完善的安全防护机制，不易被缓存污染。

七、Wireshark进阶使用（协议分析实战）

7.1 捕获过滤器深度理解（BPF语法）

捕获过滤器使用“BPF（Berkeley Packet Filter）”语法，核心是“在捕获阶段筛选数据”，需掌握常见组合筛选规则：

1. 按协议筛选：
   • 抓取TCP协议：tcp；
   • 抓取UDP协议：udp；
   • 抓取ARP协议：arp；
   • 抓取HTTP协议（TCP端口80）：tcp port 80；
   • 抓取HTTPS协议（TCP端口443）：tcp port 443；
2. 按IP地址筛选：
   • 抓取源IP为192.168.1.2的流量：src host 192.168.1.2；
   • 抓取目的IP为192.168.1.100的流量：dst host 192.168.1.100；
   • 抓取源或目的IP为192.168.1.0/24网段的流量：net 192.168.1.0/24；
3. 按端口筛选：
   • 抓取源端口为64722的流量：src port 64722；
   • 抓取目的端口为9760的流量：dst port 9760；
   • 抓取端口为80或443的流量：port 80 or port 443；
4. 组合筛选（使用and/or/not）：
   • 抓取发往192.168.1.100的TCP流量：tcp and dst host 192.168.1.100；
   • 抓取除ARP外的所有流量：not arp；
   • 抓取源IP为192.168.1.2且目的端口为80的TCP流量：tcp and src host 192.168.1.2 and dst port 80；

注意：捕获过滤器语法严格，不支持空格随意添加（如dst host 192.168.1.100不能写成dst host 192.168.1.100）。

7.2 显示过滤器实战

显示过滤器用于“捕获后筛选”，支持更精细的协议字段筛选，需掌握常见场景的过滤器：

1. HTTP协议分析：
   • 显示所有HTTP请求：http；
   • 显示HTTP GET请求：http.request.method == "GET"；
   • 显示HTTP POST请求：http.request.method == "POST"；
   • 显示HTTP响应状态码为302的报文：http.response.status_code == 302；
   • 显示包含指定Cookie的HTTP报文：http.cookie contains "SESSIONID"；
2. TCP协议分析：
   • 显示TCP SYN报文：tcp.flags.syn == 1；
   • 显示TCP FIN报文：tcp.flags.fin == 1；
   • 显示TCP重传报文：tcp.analysis.retransmission；
   • 显示TCP重复ACK报文：tcp.analysis.duplicate_ack；
   • 显示指定TCP流的报文：tcp.stream == 3（tcp.stream表示TCP流编号，可在数据包详情面板查看）；
3. ARP协议分析：
   • 显示ARP请求报文：arp.opcode == 1；
   • 显示ARP响应报文：arp.opcode == 2；
   • 显示指定IP的ARP报文：arp.ip.dst == 192.168.1.1（arp.ip.dst表示ARP报文中的目的IP）；
4. IP协议分析：
   • 显示TTL值为64的IP报文：ip.ttl == 64；
   • 显示IP分片报文：ip.frag_offset > 0（frag_offset>0表示该数据包是分片）；
   • 显示指定协议号的IP报文：ip.proto == 6（ip.proto=6表示TCP协议）；

技巧：在Wireshark的“显示过滤器”输入框中输入协议名（如http），会自动弹出该协议的可筛选字段。

7.3 数据包长度与协议分层分析

在Wireshark中，“Length”字段表示数据包的总长度，需理解其构成（以以太网帧为例）：

1. 以太网帧的长度构成：
   • 总长度 = 链路层头部（Ethernet头部） + 网络层头部（IP头部） + 传输层头部（TCP/UDP头部） + 应用层数据（如HTTP数据）；
   • 各部分默认长度：
     • 以太网头部：14字节（包含源MAC、目的MAC、类型字段）；
     • IP头部（无选项）：20字节；
     • TCP头部（无选项）：20字节；
     • UDP头部：8字节；
   • 示例：Length=1514字节的TCP报文，通常构成如下：
     • 以太网头部（14） + IP头部（20） + TCP头部（20） + 应用层数据（1460） = 1514字节；
     • 其中1460字节是应用层数据的最大长度（以太网MTU=1500字节，1500-20-20=1460）；
2. 长度分析的意义：
   • 识别异常数据包：若某TCP报文的长度远大于MTU（如超过1500字节），可能是IP分片报文；
   • 判断数据量：应用层数据长度=总长度-链路层头部-网络层头部-传输层头部，可用于分析“是否有大量数据传输”（如文件上传下载）；
     ）：20字节；
     • UDP头部：8字节；
   • 示例：Length=1514字节的TCP报文，通常构成如下：
     • 以太网头部（14） + IP头部（20） + TCP头部（20） + 应用层数据（1460） = 1514字节；
     • 其中1460字节是应用层数据的最大长度（以太网MTU=1500字节，1500-20-20=1460）；
3. 长度分析的意义：
   • 识别异常数据包：若某TCP报文的长度远大于MTU（如超过1500字节），可能是IP分片报文；
   • 判断数据量：应用层数据长度=总长度-链路层头部-网络层头部-传输层头部，可用于分析“是否有大量数据传输”（如文件上传下载）；