这是经典的SYN洪水攻击，预防措施包括

• 散列同步数据包，实现同步cookie
• 检查客户端在将无效数据包发回给他后是否正确发送 RST
• ddos 缓解软件通常会根据高级过滤提供特定的 syn 数据包超时
• 不存储整个 syn 数据包以供进一步参考，仅存储 IP 和序列号（还需要您安装额外的防火墙/软件）

限制NEW流量

sudo iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m limit --limit 50/minute --limit-burst 200 -j ACCEPT

限制established流量

sudo iptables -A INPUT -m state --state RELATED,ESTABLISHED -m limit --limit 50/second --limit-burst 50 -j ACCEPT

在您的内核上启用syncookies（@Rápli András推荐）

echo 1 > /proc/sys/net/ipv4/tcp_syncookies

安装和配置 ddos-deflate

显着特点：

• 可以通过 将 IP 地址列入白名单/etc/ddos/ignore.ip.list。
• 可以通过 将主机名列入白名单 /etc/ddos/ignore.host.list。
• 简单的配置文件： /etc/ddos/ddos.conf
• IP 地址在预先配置的时间限制后自动解锁（默认值：600 秒）
• 该脚本可以通过配置文件以选定的频率作为 cron 作业运行（默认值：1 分钟）
• 该脚本可以通过配置文件以选定的频率作为守护进程运行（默认值：5 秒）
• 当 IP 地址被阻止时，您可以收到电子邮件警报。
• 通过连接状态控制阻塞（参见 man netstat）。
• 自动检测防火墙。
• 支持 APF、CSF 和 iptables。
• 将事件记录到 /var/log/ddos.log
• 使用 tcpkill 减少攻击者打开的进程数量。

解决了

在这种情况下，这是一次针对受损 Wordpress 网站的 synflood 攻击，以 Gbytes/小时的速度向我们的网站产生了大量流量（pingback）。

这是攻击的完整描述。在推荐人/标题中，您可以将“Wordpress”作为用户代理阅读： https ://www.hyperborea.org/journal/2014/03/pingback-ddos/

使用防火墙规则（请参阅链接中的列表）阻止这些 IP 解决了这个问题。我分享名单，没有任何诅咒的责任。

被防火墙阻止的5000 个 IP 列表。

您显示的输出表明您正在接收大量 SYN 数据包并且没有响应其中任何一个。从显示的数字推断，它约为 7.5kpps。即使假设最大数据包大小为 60 字节的 IPv4 标头和 60 字节的 TCP 标头，总和仍小于 8Mbit/s。

因此，如果您的网络连接速度为 10Mbit/s 或更快，假设您有足够的处理能力来处理每秒数据包的数量，您应该能够接收该流量。

根据您问题中的有限信息，无法判断导致当前负载的原因。您的防火墙规则的结构可能会导致每个数据包在防火墙中消耗大量 CPU 时间。如果是这种情况，您需要重新构建防火墙规则以提高效率。

您似乎已配置防火墙以静默丢弃所有数据包。这实际上会使问题变得更糟，因为合法客户端将重新传输它们的 SYN 数据包，直到您响应（或客户端超时）。

我建议您在上游带宽允许的范围内响应尽可能多的数据包，而不是默默地丢弃数据包。响应需要是 SYN-ACK 数据包或 RST 数据包。

如果您遇到无法区分攻击数据包和合法数据包的 SYN 洪水，并且如果您需要继续为来自合法客户端的请求提供服务，我建议您按照Rápli的回答中的建议启用 SYN cookie。

在这种情况下，SYN cookie 可能是您的服务器在负载下响应缓慢或根本没有响应之间的区别。

不要仅基于 SYN 数据包阻止 IP 地址。如果您只看到一个 SYN 数据包，则源 IP 可能被欺骗。并且基于此的阻止对你没有好处，并且会让你面临不同类型的 DoS 攻击。

如果客户端完成握手然后发送不良流量，您可以考虑阻止 IP 地址。但是，使用 IPv4 这样做可能会导致附带损害，因此只能作为最后的措施。如果您确实以这种方式阻止流量，请确保您使用 RST 数据包进行响应，并确保您的防火墙规则的结构允许以最小的 CPU 消耗对其进行评估。