模拟 DDoS TCP SYN 泛洪攻击的最佳方法是什么
what is the best way to simulate DDoS TCP SYN Flooding attack
我想模拟一个受到 DDoS TCP SYN 泛洪攻击的网络，评估新解决方案的性能，并将其与其他解决方案进行比较。
我打算使用 NS3 来做，但我在互联网上的某个地方读到，我不能使用 descret 事件网络模拟器（NS3 是一个 descret 事件网络模拟器），我想知道为什么？最好的选择是什么？
遗憾的是，无法在 ns-3 中模拟 DoS 攻击。推而广之，DDoS 攻击也无法模拟。
DoS 攻击如何运作？
要理解为什么ns-3不能模拟DoS攻击，我们需要先了解DoS攻击是如何进行的。正如您提到的，TCP SYN 泛洪是模拟 DoS 攻击的一种方法。为什么这行得通？好吧，任何计算机的资源都是有限的，例如内存和磁盘 space。当计算机收到 SYN 时，它会创建一个套接字以促进通信。鉴于资源数量有限，只能创建有限数量的套接字。因此，DoS 攻击通过使用 SYN 淹没网络上的计算机来发挥作用，从而迫使计算机分配许多不会使用的套接字。在某些时候，计算机必须简单地拒绝任何连接，即使是合法连接。这是 DoS 攻击成功的时候。
为什么ns-3模拟不了？
在 ns-3 中，没有 Node 拥有有限资源的概念。 Nodes 中的 Queues 可以有有限的大小，但无法限制 Node 上的活动连接数。因此，无法模拟 DoS 攻击。
一个（潜在的）解决方案
为 ns-3 做贡献！ 访问 gitlab repo，并尝试添加您想要的功能。
回复评论
TCP 在 ns-3
我使用 "number of active connections" 等同于 "number of sockets"。这些术语并不完全等同，但就此答案而言，没关系。
在 SYN 泛洪中，接收到的数据包数量不是问题。相反，问题是每个接收到的 SYN 都会产生一个半开套接字，并且计算机上只能存在有限数量的套接字。
您建议使接收数据包的 Queue 饱和。你可以发送一堆数据包来饱和这个 Queue，然后 将 破坏 Node 到 一些 程度，但这不会模拟 SYN 泛洪。 SYN 洪水起作用是因为产生了太多的半开套接字，而不是因为数据包队列已满。
同样，SYN flood 之所以有效，是因为一台真实的计算机只能有有限数量的套接字。在 ns-3, 中，Node.
上的套接字数量没有限制
ns-3模型
看来你可能对ns-3的模型不熟悉。我不怪你；有一个陡峭的学习曲线。在 ns-3 中，Node 相当于网络上的 computer/server/router。附加到 Nodes 的是 Applications。反过来，Applications 创建 Sockets 以促进网络通信。
现在让我们看看 TcpSocket，Socket 的子class。 TcpSocket 在 TcpTxBuffer、TcpRxBuffer 和其他 class 变量的帮助下维持其状态。 Buffers 是 TCP 使用的 classic 缓冲区，以确保数据的可靠、有序和错误检查 delivery/reception。这些 Buffers 的大小是有限的，但是 附加到 Application 的 TcpSockets 的数量没有限制， Application 的数量也没有限制 Applications 附加到 Node. 如果存在这样的限制，那将有助于模拟内存使用情况，但在 ns-3[=87= 中不存在这样的模型].
This post on the ns-3 Google Groups 也描述了为什么你不能在不改变源的情况下模拟 SYN 洪水代码。搜索 Google 组以获取更多关于 DoS 攻击的 post。链接 post 描述了如何模拟其他类型的 DoS 攻击，但未明确支持 SYN 泛洪。
我认为目前无法模拟 TCP-SYN 泛洪攻击。
我目前也在 ns-3 中进行模拟，我希望在其中模拟 TCP-SYN 泛洪攻击。我实际上找到了[一篇论文]（https://ieeexplore.ieee.org/abstract/document/8448683) claiming to have implemented a SYN Flood in ns-3 successfully by just implementing a socket that sends SYN packets. Sadly the source code is not provided which makes me even more skeptical if their implementation actually worked as described. While the ns-3 documentation 声称正确实现了 TCP 状态机，我相信他们，我也倾向于相信@Sagar，因为我在文档中找不到任何关于限制以任何方式打开的套接字数。
我想模拟一个受到 DDoS TCP SYN 泛洪攻击的网络，评估新解决方案的性能，并将其与其他解决方案进行比较。 我打算使用 NS3 来做，但我在互联网上的某个地方读到，我不能使用 descret 事件网络模拟器（NS3 是一个 descret 事件网络模拟器），我想知道为什么？最好的选择是什么？
遗憾的是，无法在 ns-3 中模拟 DoS 攻击。推而广之，DDoS 攻击也无法模拟。
DoS 攻击如何运作？
要理解为什么ns-3不能模拟DoS攻击，我们需要先了解DoS攻击是如何进行的。正如您提到的，TCP SYN 泛洪是模拟 DoS 攻击的一种方法。为什么这行得通？好吧，任何计算机的资源都是有限的，例如内存和磁盘 space。当计算机收到 SYN 时，它会创建一个套接字以促进通信。鉴于资源数量有限，只能创建有限数量的套接字。因此，DoS 攻击通过使用 SYN 淹没网络上的计算机来发挥作用，从而迫使计算机分配许多不会使用的套接字。在某些时候，计算机必须简单地拒绝任何连接，即使是合法连接。这是 DoS 攻击成功的时候。
为什么ns-3模拟不了？
在 ns-3 中，没有 Node 拥有有限资源的概念。 Nodes 中的 Queues 可以有有限的大小，但无法限制 Node 上的活动连接数。因此，无法模拟 DoS 攻击。
一个（潜在的）解决方案
为 ns-3 做贡献！ 访问 gitlab repo，并尝试添加您想要的功能。
回复评论
TCP 在 ns-3
我使用 "number of active connections" 等同于 "number of sockets"。这些术语并不完全等同，但就此答案而言，没关系。
在 SYN 泛洪中，接收到的数据包数量不是问题。相反，问题是每个接收到的 SYN 都会产生一个半开套接字，并且计算机上只能存在有限数量的套接字。
您建议使接收数据包的 Queue 饱和。你可以发送一堆数据包来饱和这个 Queue，然后 将 破坏 Node 到 一些 程度，但这不会模拟 SYN 泛洪。 SYN 洪水起作用是因为产生了太多的半开套接字，而不是因为数据包队列已满。
同样，SYN flood 之所以有效，是因为一台真实的计算机只能有有限数量的套接字。在 ns-3, 中，Node.
ns-3模型
看来你可能对ns-3的模型不熟悉。我不怪你；有一个陡峭的学习曲线。在 ns-3 中，Node 相当于网络上的 computer/server/router。附加到 Nodes 的是 Applications。反过来，Applications 创建 Sockets 以促进网络通信。
现在让我们看看 TcpSocket，Socket 的子class。 TcpSocket 在 TcpTxBuffer、TcpRxBuffer 和其他 class 变量的帮助下维持其状态。 Buffers 是 TCP 使用的 classic 缓冲区，以确保数据的可靠、有序和错误检查 delivery/reception。这些 Buffers 的大小是有限的，但是 附加到 Application 的 TcpSockets 的数量没有限制， Application 的数量也没有限制 Applications 附加到 Node. 如果存在这样的限制，那将有助于模拟内存使用情况，但在 ns-3[=87= 中不存在这样的模型].
This post on the ns-3 Google Groups 也描述了为什么你不能在不改变源的情况下模拟 SYN 洪水代码。搜索 Google 组以获取更多关于 DoS 攻击的 post。链接 post 描述了如何模拟其他类型的 DoS 攻击，但未明确支持 SYN 泛洪。
我认为目前无法模拟 TCP-SYN 泛洪攻击。
我目前也在 ns-3 中进行模拟，我希望在其中模拟 TCP-SYN 泛洪攻击。我实际上找到了[一篇论文]（https://ieeexplore.ieee.org/abstract/document/8448683) claiming to have implemented a SYN Flood in ns-3 successfully by just implementing a socket that sends SYN packets. Sadly the source code is not provided which makes me even more skeptical if their implementation actually worked as described. While the ns-3 documentation 声称正确实现了 TCP 状态机，我相信他们，我也倾向于相信@Sagar，因为我在文档中找不到任何关于限制以任何方式打开的套接字数。