![SYN_RECV 中有很多连接,不是 SYN 洪水,是某种反射攻击吗?](https://linux22.com/image/741734/SYN_RECV%20%E4%B8%AD%E6%9C%89%E5%BE%88%E5%A4%9A%E8%BF%9E%E6%8E%A5%EF%BC%8C%E4%B8%8D%E6%98%AF%20SYN%20%E6%B4%AA%E6%B0%B4%EF%BC%8C%E6%98%AF%E6%9F%90%E7%A7%8D%E5%8F%8D%E5%B0%84%E6%94%BB%E5%87%BB%E5%90%97%EF%BC%9F.png)
至少几个月以来,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 还是虚拟机网络等)。
然后,如果是上游,你可以将你的担忧转发给他们国家奥委会(当然更有可能是从支持开始。)如果是你的立场,那么 — 澄清一下。