至少几个月以来，netstat -t在我们的 Web 服务器上发出命令时，通常会发现数十个连接状态，该服务器的 TCP 端口 22、80 和 443 都暴露在互联网上SYN_RECV：
$ netstat -nt
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 128.1XX.XX.X:22 142.93.230.186:50603 SYN_RECV
tcp 0 0 128.1XX.XX.X:80 104.248.89.196:36332 SYN_RECV
tcp 0 0 128.1XX.XX.X:80 167.71.79.217:40430 SYN_RECV
tcp 0 0 128.1XX.XX.X:22 142.93.235.90:36742 SYN_RECV
tcp 0 0 128.1XX.XX.X:80 178.128.243.146:35451 SYN_RECV
tcp 0 0 128.1XX.XX.X:443 178.62.253.100:43994 SYN_RECV
tcp 0 0 128.1XX.XX.X:80 188.166.91.16:42461 SYN_RECV
tcp 0 0 128.1XX.XX.X:22 178.62.242.138:33381 SYN_RECV
tcp 0 0 128.1XX.XX.X:80 142.93.235.90:57784 SYN_RECV
tcp 0 0 128.1XX.XX.X:443 165.22.198.207:36181 SYN_RECV
tcp 0 0 128.1XX.XX.X:22 68.183.11.83:63899 SYN_RECV
tcp 0 0 128.1XX.XX.X:22 104.248.93.253:41816 SYN_RECV
tcp 0 0 128.1XX.XX.X:80 104.248.85.129:48833 SYN_RECV
tcp 0 0 128.1XX.XX.X:80 178.62.207.43:59050 SYN_RECV
tcp 0 0 128.1XX.XX.X:80 128.199.55.152:55891 SYN_RECV
tcp 0 0 128.1XX.XX.X:443 178.62.205.23:52978 SYN_RECV
tcp 0 0 128.1XX.XX.X:80 165.22.198.135:36668 SYN_RECV
tcp 0 0 128.1XX.XX.X:80 165.22.203.65:65273 SYN_RECV
tcp 0 0 128.1XX.XX.X:80 68.183.15.91:46722 SYN_RECV
tcp 0 0 128.1XX.XX.X:443 167.71.4.136:55194 SYN_RECV
tcp 0 0 128.1XX.XX.X:80 142.93.228.103:60458 SYN_RECV
tcp 0 0 128.1XX.XX.X:443 178.62.253.100:52599 SYN_RECV
tcp 0 0 128.1XX.XX.X:22 104.248.89.56:46283 SYN_RECV
tcp 0 0 128.1XX.XX.X:443 178.62.250.235:43637 SYN_RECV
tcp 0 0 128.1XX.XX.X:443 167.71.7.181:37556 SYN_RECV
tcp 0 0 128.1XX.XX.X:80 104.248.89.200:64128 SYN_RECV
tcp 0 0 128.1XX.XX.X:22 142.93.139.213:38821 SYN_RECV
tcp 0 0 128.1XX.XX.X:443 104.248.92.161:63004 SYN_RECV
tcp 0 0 128.1XX.XX.X:22 68.183.15.91:46210 SYN_RECV
tcp 0 0 128.1XX.XX.X:443 104.248.92.138:39651 SYN_RECV
tcp 0 0 128.1XX.XX.X:22 178.62.241.74:43953 SYN_RECV
tcp 0 0 128.1XX.XX.X:22 142.93.224.74:42996 SYN_RECV
tcp 0 0 128.1XX.XX.X:443 165.22.196.167:38597 SYN_RECV
tcp 0 0 128.1XX.XX.X:80 178.128.254.3:36751 SYN_RECV
tcp 0 0 128.1XX.XX.X:22 104.248.93.27:32904 SYN_RECV
tcp 0 0 128.1XX.XX.X:443 167.71.78.255:60529 SYN_RECV
tcp 0 0 128.1XX.XX.X:22 165.22.201.209:45397 SYN_RECV
tcp 0 0 128.1XX.XX.X:80 178.62.207.205:39291 SYN_RECV
tcp 0 0 128.1XX.XX.X:22 165.22.198.207:61967 SYN_RECV
tcp 0 0 128.1XX.XX.X:443 178.62.234.81:39309 SYN_RECV
[---cut---]
我首先想到的是这是一次 SYN 洪水攻击，然而 (a) 服务器似乎根本没有受到“攻击”的影响，(b) SYN 速率相当低，仅略高于 2 个数据包/秒，并且 (c) 我通常观察到这些 SYN 数据包来自同一网络块，既来自该服务器（托管在我们大学网络中的大学实验室网络服务器），也来自完全不同网络块上的家庭服务器（通过与公共动态 IP 的常规住宅光纤连接），并且 (d) Linux 内核从未遵守有关可能的 SYN 洪水的规定（启用了 TCP SYN cookie）。
我想知道的是，这些 SYN 数据包的实际用途是什么。它们似乎不是来自网络问题（防火墙配置不当或类似问题）。它们几乎总是来自数据中心的 IP 空间，这些 IP 空间每天都在变化（可能是 Amazon EC2、Serverius、DigitalOcean 等）。有时只有一个到几个 IP，有时有几十个。有时如果我 ping 它，IP 会响应，有时不会。虽然我只是偶尔测试，但我几乎从未在端口 80 或 443 上找到可访问的 Web 服务器（从未尝试扫描比这更多的端口），但请参见下文，了解我今天发现的第一个。它们会突然出现，持续大约一个小时，然后消失；我还没有尝试自动检测它们，以便绘制每小时的图表，看看是否有某种“时间表”。
我也在想这可能是某种使用伪造 IP 源地址的放大攻击（每个接收到的 SYN 数据包最终会在服务器超时之前产生 5 个 SYN ACK 数据包），但这没有多大意义，因为（a）正常服务器会快速回复 RST 数据包从而停止进一步的 SYN ACK，并且（b）如上所述，这些服务器似乎没有托管可能值得进行 DDoS 放大攻击的公共网站。
这些（可能是伪造的？）源地址大多没有 PTR 记录，或者只有通用记录，但在某些情况下，它们会给出实际的主机名（例如，在上面提到的列表中，142.93.230.186 给出的是 parimatchklub.com，显然是一个俄罗斯体育博彩网站）。该网站的访问速度非常慢，因此也许它确实是针对明显源地址的某种形式的反射攻击？
还有其他人已经注意到这一点吗？对这些数据包的实际用途有什么解释吗？
答案1
它看起来像是 nmap 主机发现之类的工具留下的痕迹。Nmap 是一个主机发现工具和端口扫描器。
nmap 的主机发现阶段可以向 Web 服务器端口发送 syn 数据包，以检测阻止 icmp ping 的服务器。有人可能正在使用 nmap 发现您 IP 范围内（甚至 0.0.0.0/0）的实时主机，并且可能对您的主机毫无兴趣。
您可以通过嗅探 SYN 和 ICMP 数据包并将它们与以下描述的扫描进行比较来检测到这一点： https://nmap.org/book/man-host-discovery.html
您还可以查看他们是否正在跟进更广泛的端口扫描。他们可能正在寻找具有他们已知的漏洞的特定端口的主机。
答案2
这可能是 HTTP 规避，以绕过您的服务器安全。这些 IP 地址可能是恶意主机，因为它们是廉价托管提供商，已知它们托管恶意软件并参与僵尸网络活动。
答案3
对这些数据包的实际用途有什么解释吗？
输出netstat显示您的服务器无法ESTABLISH连接，这可能是由于临时连接问题或欺骗（伪造）IP 源端点 - 它发送的回复根本没有到达发起者。
如果我们选择“欺骗版本”，我建议尝试至少跟踪这些连接到服务器获取它们的通道。它可能不是上游，而是您的 LAN（无论是真正的 LAN 还是虚拟机网络等）。
然后，如果是上游，你可以将你的担忧转发给他们国家奥委会（当然更有可能是从支持开始。）如果是你的立场，那么 — 澄清一下。