与服务器的连接被重置_TCP 重置攻击的工作原理

原文链接：https://fuckcloudnative.io/posts/deploy-k3s-cross-public-cloud/

TCP 重置攻击 是使用一个单一的数据包来执行的，只有几个字节大小。攻击者制作并发送一个伪造的 TCP 重置包来干扰用户和网站的连接，欺骗通信双方终止 TCP 连接。我们伟大的 xx 长城便运用了这个技术来进行 TCP 关键字阻断。

理解 TCP 重置攻击并不需要具备深厚的网络知识功底，只需要一台笔记本就可以对自己进行模拟攻击。本文将会带你了解 TCP 重置攻击的原理，同时会帮助你理解很多关于 TCP 协议的特性。本文主要内容：

• 回顾 TCP 协议的基础知识
• 了解 TCP 重置攻击的原理
• 使用一个简单的 Python 脚本来模拟攻击

下面开始分析 TCP 重置攻击原理。

1. 伟大的 xx 长城是如何利用 TCP 重置攻击的？

这一段略过，原因你懂得，感兴趣的请直接看原文。

2. TCP 重置攻击的工作原理

在 TCP 重置攻击中，攻击者通过向通信的一方或双方发送伪造的消息，告诉它们立即断开连接，从而使通信双方连接中断。正常情况下，如果客户端收发现到达的报文段对于相关连接而言是不正确的，TCP 就会发送一个重置报文段，从而导致 TCP 连接的快速拆卸。

TCP 重置攻击利用这一机制，通过向通信方发送伪造的重置报文段，欺骗通信双方提前关闭 TCP 连接。如果伪造的重置报文段完全逼真，接收者就会认为它有效，并关闭 TCP 连接，防止连接被用来进一步交换信息。服务端可以创建一个新的 TCP 连接来恢复通信，但仍然可能会被攻击者重置连接。万幸的是，攻击者需要一定的时间来组装和发送伪造的报文，所以一般情况下这种攻击只对长连接有杀伤力，对于短连接而言，你还没攻击呢，人家已经完成了信息交换。

从某种意义上来说，伪造 TCP 报文段是很容易的，因为 TCP/IP 都没有任何内置的方法来验证服务端的身份。有些特殊的 IP 扩展协议（例如 IPSec）确实可以验证身份，但并没有被广泛使用。客户端只能接收报文段，并在可能的情况下使用更高级别的协议（如 TLS）来验证服务端的身份。但这个方法对 TCP 重置包并不适用，因为 TCP 重置包是 TCP 协议本身的一部分，无法使用更高级别的协议进行验证。

尽管伪造 TCP 报文段很容易，但伪造正确的 TCP 重置报文段并完成攻击却并不容易。为了理解这项工作的难度，我们需要先了解一下 TCP 协议的工作原理。

3. TCP 协议工作原理

TCP 协议的目标是向客户端发送一份完整的数据副本。例如，如果我的服务器通过 TCP 连接向你的计算机发送我的网站的 HTML，你的计算机的 TCP 协议栈应该能够以我发送的形式和顺序输出 HTML。

然而现实生活中我的 HTML 内容并不是按顺序发送的，它被分解成许多小块(称为 TCP 分组)，每个小块在网络上被单独发送，并被重新组合成原来发送的顺序。这种重新组合后的输出被称为 TCP 字节流。

将分组重建成字节流并不简单，因为网络是不可靠的。TCP分组可能会被丢弃，可能不按发送的顺序到达客户端，也可能会被重复发送、报文损坏等等。因此，TCP 协议的职责是在不可靠的网络上提供可靠的通信。TCP 通过要求连接双方保持密切联系，持续报告它们接收到了哪些数据来实现可靠通信，这样服务端就能够推断出客户端尚未接收到的数据，并重新发送丢失的数据。

为了进一步理解这个过程，我们需要了解服务端和客户端是如何使用序列号（sequence numbers）来标记和跟踪数据的。

TCP 序列号

TCP 协议的通信双方， 都必须维护一个序列号（sequence numbers），对于客户端来说，它会使用服务端的序列号来将接收到的数据按照发送的顺序排列。