我已阅读了大量有关此问题的帖子，但没有一个提供真正的答案。
我们有 3 台机器，其中一台（不在我们的管理范围内）为另外两台机器分配负载。第一台机器使用 FreeBSD 正常运行，另一台机器最近进行了格式化，现在正在使用 Ubuntu Server。
第二台机器目前毫无理由地将所有连接保留在 SYN_RECV 上。两台机器都没有防火墙。
dmesg但我们知道事实Possible SYN Flood attack并非如此。
可能出了什么问题？我必须进行一些内核配置吗？Ubuntu 是否存在一些已知问题？
谢谢
编辑：我在 BSD 机器的 PF 上发现了一条规则，我不确定，但它应该与这个问题有关。
pass in log on bce1 proto tcp from <nois> to any port = http flags S/SA keep state (max 2000, source-track rule, max-src-states 120, max-src-conn 80, adaptive.start 1200, adaptive.end 2400)
它基本上保持了 SYN SYNACK 标志包的状态...有人知道如何将其转换为 IPTABLES 吗？
答案1
基本上，Linux 机器正在接收 SYN（尝试打开 TCP 连接），然后它没有收到 ACK（整个过程）。半开连接不断累积，直到服务器决定受到攻击。
可能存在以下几种原因：
首先，负载均衡器可能配置为执行此操作。它可能会将 SYN 传递到两个框，并且只允许一个连接到客户端，因为它只需要一个。平衡器可能认为忽略回复是无害的，因为数据包总是丢失。但是，在这种情况下，您实际上没有理由遇到实际问题。请确保您已启用 syncookies，以确保在这种情况下不会导致问题。
其次，Linux 机器对 SYN 的 ACK 响应可能无法通过 Linux 机器的防火墙。这需要防火墙配置非常糟糕，所以不太可能。
可能性较小的是：
第三，负载均衡器可能由于某种原因拒绝Linux机器的ACK。
第四，负载均衡器可能无法将 ACK 传回 Linux 机器。
第五，Linux 系统的防火墙可能会丢弃传入的 ACK。
答案2
从您所说的情况来看，负载均衡器很可能会检查后端服务器返回的 SYN/ACK 以查看它是否启动，然后将所述 SYN/ACK 传回给客户端；这意味着除了负载均衡之外，它还执行故障转移任务。
显然，FreeBSD 处理此问题的方式与 Ubuntu 不同，Ubuntu 将此视为 SYN 洪水攻击。
嗅探来自客户端以及负载均衡器和后端之间的流量将告诉你到底发生了什么。