跳转至

Protocols

OSI model

OSI(Open System Interconnection，开放式通信互联) 是由 ISO(International Organization for Standardization，国际标准化组织) 制定的标准模型。

这张图就更加形象具体了，每一层都有对应的网络设备：

从上到下分别是：

  • 应用层，就是指特定的应用层协议，比如 HTTP、远程文件协议 FTP、邮件协议POP3、远程登录协议 SSH 等
  • 表示层，负责数据处理转换：包含数据格式、编码解码、加密解密等
  • 会话层，负责建立和维护不同主机之间的通信连接
  • 传输层，主机进程之间的数据传输服务，注意，这里的进程间实际就是指传输层需要端口号来识别进程
  • 网络层， 主机端到端的路由和寻址（这一层寻址是依靠 IP 地址）
  • 数据链路层，负责管理相邻节点之间的数据通信：包括 数据封装成帧、MAC 寻址、流量控制、差错控制
  • 物理层，数据通信的光电物理特性、时钟同步、传输比特流等

可以看到，常见的网络攻击就发生在前五层中

Protocols

ARP

Bash
# 清除缓存
arp -d
# 发送ARP报文
arp -a

image-20260630162009694

这里我的IP为192.168.31.113，首先我发起了一个广播，寻找IP为192.168.31.1的设备

image-20260630162120802

如果该设备存在，那么会回复我的设备它的MAC地址为多少

所以ARP欺骗的原理也很简单，当目标发送广播寻找某个设备时，攻击者发送大量的伪造回复消息，更新ARP缓存表，伪造成目标要寻找的设备

ARP欺骗的典型案例就是伪造网关的地址，将目标的数据包导向攻击机，从而实现中间人攻击或断网攻击

ARP欺骗防御手段

  1. 动态ARP检测（DAI, Dynamic ARP Inspection）： 这是最有效的方案。交换机拦截所有的ARP包，并与DHCP Snooping表（记录了合法终端通过DHCP获取的IP-MAC绑定关系）进行比对。如果ARP包中的IP-MAC不匹配，交换机直接丢弃该包。
  2. IP Source Guard： 在交换机端口上绑定合法的IP和MAC地址，只有源IP和源MAC都匹配的包才允许从该端口发出。
  3. 划分VLAN与端口隔离： 缩小广播域。将不同部门或不同业务划分到不同的VLAN，并在交换机端口开启“端口隔离”或“私有VLAN”，禁止同VLAN内的主机直接二层通信，所有流量必须经过网关（三层设备），从而消除主机间直接ARP欺骗的基础。
  4. 静态ARP绑定(路由器设置)：在本地手动绑定网关的IP和真实MAC。

DHCP

Bash
# 释放并重新获取IP
sudo ipconfig set en0 DHCP

image-20260630173513856

DHCP的实现分为以下四步：

**1、IP地址租用询问：**DHCP客户端在本地子网内，以广播的方式，发送一个DHCP Discover报文，目的是发现能够提供IP地址的DHCP服务器。即客户端询问，有没有可用的DHCP服务器。

image-20260630173820300

**2、IP地址租用回应：**可用的DHCP服务器接收到Discover报文后，以单播形式回应DHCP Offer报文，告诉相应的客户端可以提供IP地址，并在Offer报文字段添加可提供的IP地址。即DHCP服务器回复，我这里有可用的IP地址，你看要不要用。如果本地子网中存在多个DHCP服务器，则以客户端收到的第一个Offer报文为准。

image-20260630173853199

**3、IP地址租用请求：**客户端接收到DHCP服务器的DHCP Offer报文后，以广播方式发送DHCP Request报文，并在报文字段中添加选中的DHCP 服务器的IP地址和请求的IP地址。即客户端再次回应，我想要你提供地址分配服务，并使用这个IP地址。

image-20260630173952041

**4、IP地址租用确认：**DHCP服务器收到 Request报文后，判断报文字段中的IP地址是否和自己一致。如果一致，则以单播形式向相应的客户端发送DHCP ACK报文，并在报文字段中添加IP地址租期等信息。即DHCP服务器回复确认信息，好的，一切就绪，你可以租用该IP地址。如果发现客户端提供的IP地址信息不正确，DHCP服务器则发送DHCP NACK报文给客户端，让客户端重新发起地址请求过程。客户端接收到DHCP ACK报文后，检查DHCP 服务器分配的IP地址是否可用。如果可用，则客户端成功获得IP地址并根据IP地址使用租期自动启动续延过程。如果发现IP地址已经被其他主机占用，客户端则发送DHCP Decline报文，通知DHCP 服务器禁用这个IP地址，然后开始新的地址申请过程。

image-20260630174025549

DHCP欺骗攻击

DHCP 协议在设计时，默认局域网内**只有一个合法的 DHCP 服务器**，且客户端**盲目信任第一个响应它的服务器**。

攻击过程：

  1. 攻击者在局域网内（比如插了一个小路由器，或者在笔记本上运行恶意软件）启动一个**恶意的 DHCP 服务器**。
  2. 当受害者发送 DHCP Discover 时，合法服务器和恶意服务器都会收到。
  3. 恶意服务器通常会配置得响应更快，或者故意提供更具“吸引力”的租约时间，抢先向受害者发送 DHCP Offer。
  4. 受害者接受了恶意服务器的 Offer，并发送 Request。
  5. 恶意服务器回复 Ack，但在分配 IP 的同时，将“默认网关（Router）”和“DNS 服务器”的选项，指向了攻击者自己的网卡 IP。

这样攻击者只需开启流量转发，将流量再转发到正常的DHCP服务器，就能实现中间人攻击了

DHCP欺骗攻击防御手段

防御 DHCP 欺骗，核心思想是 “控制谁能发送 DHCP 响应报文”。

  1. 网络架构层面（企业级终极方案：DHCP Snooping）

这是在**交换机（数据链路层）** 上配置的功能，是防御此攻击的绝对主力。

  • 原理：交换机将端口划分为 “信任端口”（Trusted，连接合法 DHCP 服务器或上级核心交换机）和 “非信任端口”（Untrusted，连接普通员工电脑）。
  • 动作：交换机默认允许所有端口发出 DHCP Discover/Request（客户端报文）。但是，只有信任端口才允许发出 DHCP Offer/Ack/NAK（服务端响应报文）。如果非信任端口收到了服务端响应报文，交换机会直接将其丢弃。

  • 效果：恶意 DHCP 服务器发出的 Offer 根本出不了它所在的那个交换机端口，受害者永远收不到恶意的 Offer。

  • 结合 IP Source Guard 与 DAI

通常 DHCP Snooping 会联动其他安全特性：

  • 交换机通过 DHCP Snooping 会记录一张表：MAC地址 - IP地址 - VLAN - 端口。
  • IP Source Guard：利用这张表，在非信任端口上，只允许源 IP 和源 MAC 匹配该表的流量通过，防止攻击者手动篡改 IP。
  • DAI（动态 ARP 检测）：利用这张表验证 ARP 报文的合法性，直接联动防御 ARP 欺骗。

FTP

SSH

发起一个ssh连接

image-20260630220038909

SSH数据传输可以分为下面几个阶段：

  1. SSH版本协商

image-20260630220536991

客户端和服务端会协商使用的SSH版本，目前绝大多数使用的都是SSHv2版本，假如一个仅支持SSHv1的客户端连接仅支持SSHv2的服务端，服务端会拒绝该连接

  1. 密钥协商

image-20260630220854991

image-20260630220930814

首先客户端和服务端会各自发送支持的加密算法

image-20260630221449218

随后使用DH算法进行密钥协商，首先客户端会发送公钥给服务端

image-20260630221653929

服务端接收到客户端公钥后，会通过DH算法协商出一个会话密钥，后续的数据加密都是通过该密钥进行，同时回复客户端服务端的公钥、签名等信息，在这一步，如果是初次连接，客户端会保存服务端公钥到本地，同时弹出是否信任该服务器提示

image-20260630222124140

客户端接收到New Keys包，回复New Keys，密钥协商完成

  1. 加密数据传输

image-20260630222352690

可以看到都是加密数据传输

如果使用用户名密码方式进行SSH连接，存在SSH中间人攻击的风险，具体原理如下：

根本原因就在于SSH客户端在首次连接时无法证明公钥属于目标服务器，假如攻击者能劫持该连接，那么就可以发送一个假的公钥给客户端，并充当中间人与客户端和服务端建立连接和传输数据，并且DH算法本身也存在中间人攻击的风险

由于SSH中间人攻击的前提条件为劫持到目标流量，所以经常配合以下攻击手法：

  • ARP欺骗（ARP Spoofing）：在局域网内，攻击者伪造MAC地址，让交换机把发往网关（或服务器）的流量先发给攻击者。
  • DNS劫持/污染：攻击者篡改DNS解析结果，让用户输入的域名（如 gitlab.company.com）解析到攻击者控制的IP地址。
  • 恶意Wi-Fi/路由器：在公共网络中，网关本身就是攻击者控制的。

中间人攻击防御措施

  1. 使用公私钥登录

当客户端信任了中间人的公钥后，双方建立了加密通道。此时客户端发起公私钥登录，中间人能否成功冒充客户端登录真实服务器呢？

答案是：不能。中间人无法实现“透明的代理转发”。

  • 底层机制（Session ID 绑定）：在SSH协议（RFC 4252）中，客户端使用私钥进行的签名，其签名数据中严格绑定了当前连接的 Session ID。Session ID 是在最初的密钥交换阶段生成的。
  • 攻击阻断：客户端是对“中间人会话”的 Session ID 进行签名的。当中间人截获这个签名，试图将其转发给真实服务器时，真实服务器会发现：签名中的 Session ID 与真实服务器自己生成的 Session ID 不匹配。
  • 结果：真实服务器会拒绝该签名，认证失败。因此，中间人无法直接重放签名来登录真实服务器。

因为攻击者没有客户端的登录私钥，所以无法实际登录到服务器，但是仍然可以进行中间人攻击，原理如下：

在SSH连接中，其实有两套独立的密钥体系，它们的作用完全不同：

  • 第一对：服务端的主机密钥（Host Key）
  • 作用：证明 “我是真正的服务器”（防范中间人）。
  • 流程：服务端把公钥（Host Key）发给客户端，客户端用这个公钥验证服务端发来的签名。
  • 第二对：用户的登录密钥（User Key）
  • 作用：证明 “我是合法的用户”（替代密码登录）。
  • 流程：客户端用自己的私钥（User Private Key）对数据进行签名，服务端用预先配置好的用户公钥（User Public Key）来验证这个签名。

SSH的连接建立分为两个大阶段：

  1. 阶段一：密钥交换与服务器认证（建立加密通道）。在这个阶段，客户端接收服务端的 Host Key。如果此时客户端被中间人欺骗（信任了假 Host Key），加密通道就已经和中间人建立成功了。
  2. 阶段二：用户认证（公钥登录）。这是在**加密通道建立之后**才发生的业务逻辑。

当进行到“客户端使用私钥签名”这一步时，连接早就已经建立了，只不过这个连接是和中间人建立的。客户端的私钥签名，只是在这个“错误的通道”里发送了一个业务数据包而已。

虽然无法登录真实服务器，但攻击者仍然可以这样利用：

To bypass this protocol protection, one option for attackers is to redirect the traffic to a honeypot, which is basically another machine owned by the attacker (or previously compromised), that looks like the legitimate server but is under his control. Users might notice something wrong (missing files, different configurations) and execute diagnostic commands that can leak sensitive information.

Another option is to authenticate to the server using different credentials, but that requires knowing the credentials of another user who has access to the target server.

The tool used in this lab also supports honeypot redirection:

Bash
ssh-mitm server --remote-host 172.18.3.102 --listen-port 22 --fallback-host ssh-lab-server --fallback-username myserver --fallback-password 1234

This command specifies a fallback host and credentials that the MITM can use to connect to the honeypot.

  1. 首次连接时的带外验证（OOB Verification）

首次连接时，不要盲目输入 yes。必须通过其他安全渠道（如直接登录云控制台、通过内部安全IM、或查看服务器本地生成的指纹文件）核对终端上显示的公钥指纹（如 SHA256:xxxx...）是否一致。

  1. 强制严格的主机密钥检查

在客户端配置 ~/.ssh/config 中设置：

Text Only
StrictHostKeyChecking yes
UpdateHostKeys yes

在此配置下，客户端会拒绝所有不在kown_hosts中的主机公钥

  1. 企业级终极方案：使用 SSH 证书（SSH Certificates）

搭建内部的 SSH CA（证书颁发机构）。让 CA 为每台服务器签发主机证书，客户端只需信任 CA 的公钥，即可自动验证所有服务器的身份。这彻底消灭了 TOFU（首次使用盲目信任）模型，是大规模集群防范 MITM 的最佳实践。

Telnet

Telnet都是明文传输数据，包括认证密码等，极不安全，替代方案是使用SSH协议

参考：在Wireshark中检查Telnet和SSH - 知乎

SMTP

简单邮件传输协议（英语：**S**imple **M**ail **T**ransfer **P**rotocol，缩写：SMTP）是一个在互联网上传输电子邮件的标准。

SMTP是一个相对简单的基于文本的协议。在其之上指定了一条消息的一个或多个接收者（在大多数情况下被确认是存在的），然后消息文本会被传输。可以很简单地通过telnet程序来测试一个SMTP服务器。SMTP使用TCP端口25。要为一个给定的域名决定一个SMTP服务器，需要使用DNS的MX记录。

无论使用POP3还是IMAP4来获取消息，客户端均使用SMTP协议来发送消息。邮件客户端可能是POP客户端或者IMAP客户端，但都会使用SMTP。

在传输中，认证时用户名和密码都是base64编码，其余内容明文传输

由于明文传输的不安全性，现在单纯的SMTP已经几乎没有使用了，使用的较多的都是它的加密版本SMTPS（465端口，SSL加密，不推荐使用）和STARTTLS（587端口，TLS加密，推荐使用）。

参考：

Wireshark对SMTP抓包分析 | TinyChen's Blog

RFC8314文档中对465端口和587端口的阐述 | TinyChen's Blog

Wireshark抓取SMTP协议报文 - 技术栈