我管理的（在 VPS 上）一个低流量网站的（Linux）网络服务器刚刚在端口 80 上每秒受到大约 5 个 SYN 请求，而没有来自远程主机的其他流量。这更像是滴比洪水还严重，但自从我第一次注意到它之后，它持续了大约一个小时。我不知道这是否是一次放大攻击。
我不想成为那种事情的一部分，无论如何，所有那些半开的连接堵塞 netstat 都很烦人，即使没有造成真正的伤害。（启用了 SYN-cookies，链接远未饱和，apache 正在应对，但我认为内存使用率上升，响应速度比正常情况慢一点。）
因此，这一次，我通过手动阻止欺骗/实际的原始 IP 地址来“缓解”问题，然后使用 tcpdump 密切关注它，这就是我知道他们已经放弃的原因。我想要一个自动解决方案...
由于它是面向公众的网络服务器，因此应该有连接！而且有些页面上有很多图片/CSS 文件等。因此，我完全预计真正的用户每秒的“攻击”请求数将远远超过 5 个，因此
iptables -A INPUT -m 状态 --state NEW -m 限制 --limit 4/秒 --limit-burst 20 ....
只能捕获真正的用户，但几乎无法捕获攻击，甚至根本无法捕获攻击。
除了一些粗糙的方法，比如一个脚本不时地计算 netstat 输出中的 SYN_RCVD 条目，然后将结果输入到日志中以供 fail2ban 响应之外，如果来自给定 IP 的半开连接的累计总数超过某个数字，是否有有效的解决方案来丢弃数据包？我在 iptables 中看不到任何东西，但也许我遗漏了一些东西。
编辑：忘记说了，VPS 是基于 openVZ 的（基于 RHEL6 构建），所以我目前坚持使用的内核是 2.6.32。如果能找到适用于如此古老内核的答案就太好了！
编辑2：Conntrack 超时，根据要求：
net.netfilter.nf_conntrack_generic_timeout = 120
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 30
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 15
net.netfilter.nf_conntrack_tcp_timeout_established = 86400
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 30
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 15
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 10
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 30
net.netfilter.nf_conntrack_tcp_timeout_close = 5
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 60
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 60
net.netfilter.nf_conntrack_udp_timeout = 10
net.netfilter.nf_conntrack_udp_timeout_stream = 60
net.netfilter.nf_conntrack_icmpv6_timeout = 30
net.netfilter.nf_conntrack_icmp_timeout = 10
net.netfilter.nf_conntrack_events_retry_timeout = 15
net.ipv6.nf_conntrack_frag6_timeout = 4194
但是正如我上面所写的，我不太关心对服务器的影响（到目前为止影响很小），而是阻止脚本小子之类的，就像当他们试图查看我是否有 phpmyAdmin、dlink 路由器（等等）时，这是我收到的他们的最后一个数据包。
答案1
是的，您可以结合 iptables 限制和 SYNPROXY 来执行内核设置（例如通过 conntrack 模块设置超时）。
synproxy 的作用基本上是检查是否建立了完整的 TLS 连接，如果没有，则丢弃请求。它的性能比之前的其他解决方案（hashlimits 等）要好得多。
你说得对，每秒 4 个连接的限制会阻止大量合法连接，每秒 60-80 个连接左右更为现实。对于你的用例，synproxy 绝对是最佳选择。
今年早些时候，当我自己使用内置 Linux 工具尝试 DDoS 保护时，我发现了一个很棒的反 DoS 指南：https://javapipe.com/ddos/blog/iptables-ddos-protection/
本指南基本上是我上面提到的所有内容的操作指南。它解释了每条规则的作用、为什么应该或不应该实施它、它的工作原理、它如何影响性能，并告诉你它是否是可选的，这是一本非常棒的指南。