In recent days, node operators have begun to receive a large number of abuse notifications. These notifications refer to failed login attempts due to their hosts being subject to what are termed attacks, indicating the presence of brute force attacks.

Typically, nodes only forward traffic between the source and destination nodes on the network and should not initiate connections to open hosts on the network, especially brute force attacks.

However, the analysis by the researcher under the pseudonym " " indicates that most nodes do not generate traffic.

The attacker was found to deceive the address of the node, conducting large-scale brute force attacks on honeypots and networks equipped with intrusion detection systems capable of automatically reporting suspicious activities, resulting in false abuse notifications being sent to the node.

Therefore, hosts that repeatedly receive failed login attempts will eventually be blacklisted due to their "bad reputation." This leads many providers to disable such hosts, sometimes making it impossible to reactivate them.

These attacks aim to weaken the infrastructure of nodes, triggering a wave of abuse reports. Currently, the level of malicious activity is low, and the attackers remain unknown.

Although node operators are encouraged to appeal and deploy additional nodes to replace lost ones, providers themselves are also required to carefully review complaints to avoid false bans.

Analyze the full text of the original:

The author has published the article:

https://delroth.net/posts/#content-start

A strange trick to get the world to send abuse complaints to your best friend

https://delroth.net/posts/spoofed-mass-scan-abuse/

It all started with a terrifying email I received just before going to bed late at night:

From: [email protected]``Date: 2024-10-29 01:03:00 CET``Subject: AbuseInfo: Potential Security issue: AS24940: 195.201.9.37`` ``We have received an abuse report from [email protected] for your``IP address 195.201.9.37.`` ``We are automatically forwarding this report on to you, for your information.``You do not need to respond, but we do expect you to check it and to resolve any``potential issues.`` ``> To assist you in understanding the situation, we have provided the relevant``> log data below, with timestamps adjusted to our GMT +8 timezone:``>``> DateTime Action AttackClass SourceIP Srcport Protocol DestinationIP DestPort``> 0 28-Oct-2024 19:39:11 DENIED 195.201.9.37 36163 TCP 202.91.162.233 22``> ``> 20 28-Oct-2024 20:36:33 DENIED 195.201.9.37 22044 TCP 202.91.161.97 22``> 21 28-Oct-2024 20:41:37 DENIED 195.201.9.37 9305 TCP 202.91.163.36 22``> 22 28-Oct-2024 20:50:33 DENIED 195.201.9.37 39588 TCP 202.91.163.199 22``> 23 28-Oct-2024 20:50:58 DENIED 195.201.9.37 62973 TCP 202.91.161.41 22``> 24  28-Oct-2024 20:51:50   DENIED                   195.201.9.37    3085      TCP   202.91.161.97       22

初看，这听起来很糟糕。我的一台服务器突然决定开始向更广泛的互联网发送 SSH 连接。这通常是恶意软件入侵的强烈迹象，如果真是这样，我必须迅速采取行动。幸运的是，我从事信息安全工作已有一段时间，几年前我甚至做过一些自由职业，负责取证和清理受感染的服务器。 因此，虽然我并不完全不适应，但一两个小时后，我发现没有发现任何异常情况，这让我很惊讶。要证明错误总是很难，但实际上，机器很好。没有奇怪的进程，没有文件系统修改，没有奇怪的网络流量（这是虚拟机管理程序观察到的，而不是服务器本身观察到的，服务器本身恰好是虚拟机 - 只是为了更加确定！）。如果这是一起恶意软件入侵事件，那么恶意软件会非常隐蔽，这与它被命令扫描互联网的想法相悖 - 一般来说，这是一种非常响亮和明显的行动。我转向机器上定期运行的服务。这是我的主要数据中心托管服务器，我在那里运行了一堆分布式或联合服务：● 同步中继。● Mastodon 实例。● Tor 中继（非出口，仅内部节点）。● Matrix 家庭服务器。经过仔细检查，Tor 中继确实连接到了托管在端口 22 上的几个其他中继，但这是一组非常有限的 IP，并且它不包含网络中向我的 ISP 发送滥用投诉的任何内容。不太可能。我认为 Matrix 或 Mastodon 可能被滥用来向任意 IP:port 目的地发送命令请求，但两者的日志记录都表明没有发生任何此类事情（明显）。我的 Mastodon 实例的 Sidekiq 队列也没有任何此类痕迹，而我原本预计如果涉及此事，会看到例如重试排队。那里发生了什么事？虐待投诉是无稽之谈吗？conclusive evidence然后，我注意到我的某个tcpdump程序仍在运行，以监控涉及该服务器上端口 22 的流量。我最初 tcpdump在 上运行了过滤dst port 22，因为这将显示从我的服务器发往远程目的地的流量。然而，出于某种原因，我在某个时候放弃了该过滤器，而是过滤not src host 195.201.9.37（我的服务器的 IP）。这时出现了以下内容：

04:14:25.286063 IP 45.187.212.68.22 > 195.201.9.37.59639: Flags [R.], seq 0, ack 41396686, win 0, length 0``04:14:25.291455 IP 107.152.7.33.22 > 195.201.9.37.39793: Flags [R.], seq 0, ack 1391844539, win 0, length 0``04:14:25.322255 IP 107.91.78.158.22 > 195.201.9.37.48900: Flags [R.], seq 0, ack 1434896088, win 65535, length 0

确实发生了一些事情。但完全不是我所期望的。结果：没有任何连接从我的服务器发出并进入随机机器的端口 22。但实际上一些随机互联网机器向我发送了 TCP 重置数据包。如果您在网络/信息安全社区待过一段时间，您现在可能会尖叫：反向散射！源 IP 欺骗！是的，这也是我的第一个想法。让我们快速地了解一下这些事情的含义。Deception on the Internet事实证明，使用虚假的源 IP 地址将数据包发送到 Internet 上的各个目的地非常简单（当然，目标 IP 必须正确，因为它决定了……目的地）。许多 ISP 遵守最佳 当前实践 (BCP) 38，可总结如下：“如果您与网络对等，则应只允许他们使用您期望的 IP 地址发送 IP 数据包”。不幸的是，这种过滤通常只能在数据包到目的地的路由早期完成。一旦数据包到达大型中转提供商，他们的对等方就会期望该提供商将整个互联网的流量传送给他们，因此无法进行任何有意义的过滤。这意味着，只要你找到一个不进行 BCP38 过滤的中转提供商……你就可以发送带有任何源 IP 标记的 IP 数据包！不幸的是，尽管 BCP38 的起源可以追溯到 1998 年……但 25 年后仍有网络提供商没有实施它。APNIC去年发表了一篇关于这个主题的精彩文章。实践中，后果应该不会太糟。TCP、QUIC 以及通常使用 (d)TLS 的任何东西都需要往返，而当源 IP 被欺骗时，往返是不会发生的。欺骗源 IP 意味着您可以发送“错误”的数据包，但对该数据包的回复仍会发送到您欺骗的源 IP，欺骗者无法看到并处理它们。有一些众所周知的滥用媒介依赖于欺骗，例如反射 DDoS，但这通常不是一个问题。除非…Guess motive让我们回到我的RST数据包。主要假设是有人正在使用我的源 IP 向各种互联网机器的端口 22 发送出站连接。但乍一看，这在逻辑上说不通。通常，人们会这样做来扫描开放端口或具有正常工作的 SSH 服务器的服务器。但是，当您欺骗源 IP 时，这些都不起作用，因为您看不到探测的结果！在互联网发展的早期，曾有一种名为“空闲扫描”的技术，它依赖于以下条件：1. 服务器的繁忙程度远低于今天；2. 网络堆栈缺乏某些字段的随机化，并使用自动递增的可预测计数器。这可用于在伪造源 IP 时探测端口是否打开（为了匿名，或绕过防火墙）。但这种技术已经失效，几十年来一直无法使用。那么，也许有人设置了扫描仪，并在配置文件中输入了他们的源 IP，导致随机互联网机器认为我正在向它们发起连接？但是……流量似乎太低，异常持续时间太长，而且无论如何这真的会很牵强。无论欺骗者的动机是什么，这都有点令人讨厌。他们的扫描会击中蜜罐、带有入侵检测系统的网络，这些网络会发送（有时是自动的）滥用投诉，等等。我希望他们能注意到他们所做的一切都没有奏效，因为我特别不喜欢收到滥用投诉，而且他们让我面临被踢出托管提供商的风险。… 等一下？！Connection我之前顺便提到过，我在服务器上运行的服务之一是 Tor 中继。中继是 Tor 网络的内部节点。它们只承载匿名加密流量（事实上，通常采用多层加密），并且只在 Tor 网络的同意加入节点之间传输。中继不是出口节点，它们不与开放互联网通信。一些选定的中继也是“守卫节点”，可以作为 Tor 网络的入口点。从技术上讲，它们与开放互联网通信，但仍然只有同意的用户才能连接到 Tor 网络。出于这个原因，我最初排除了 Tor 与这个滥用问题有任何联系（双关语）。我敢肯定你们中的一些人对此大喊大叫，但是嘿，你可能有以下好处：1. 事后诸葛亮；2. 不会在凌晨 4 点起床跑步tcpdump。但 Tor 有一个特点：互联网上有些人不喜欢它。这有很多好的理由和坏的理由——我个人认为 Tor 是一个“有用的中立污水池”，但这不是一篇关于道德的文章，而且很容易说有些人不同意。这些人包括“个人黑客活动分子”、 “警察部队” 和“政府机构”，他们的复杂程度和技巧各不相同。是否有人故意试图诱导 Tor 网络参与者提出滥用投诉，从而关闭部分网络（或阻止正在运行的内部节点，而这对于网络的健康至关重要）？检查起来很简单。我运行了更多中继节点，所以我们也来tcpdump这里看看。一个在我的住宅 IP 连接上，另一个在日本的 Linode VPS 上：

04:19:14.705034 IP 198.30.233.69.22 > 172.105.199.155.39998: Flags [R.], seq 0, ack 171173954, win 0, length 0``04:20:15.135733 IP 124.198.33.196.22 > 172.105.199.155.23506: Flags [R.], seq 0, ack 1985822135, win 0, length 0``04:21:30.222739 IP 223.29.149.158.22 > 172.105.199.155.27507: Flags [R.], seq 0, ack 3614869158, win 0, length 0`` ``04:12:39.470366 IP 121.150.242.252.22 > 77.109.152.87.57627: Flags [R.], seq 0, ack 2452733863, win 0, length 0``04:13:05.549920 IP 46.188.201.102.22 > 77.109.152.87.9999: Flags [R.], seq 0, ack 3253922544, win 0, length 0``04:14:33.027326 IP 1.1.195.62.22 > 77.109.152.87.52448: Flags [R.], seq 0, ack 351972505, win 0, length 0

是的，我的另外两个中继运行在完全不同的国家，使用完全不同的 ISP，看到了相同的欺骗 TCP SYN 模式。这是我向邮件列表发送邮件tor-relays的时候，结果发现几天前有人注意到并诊断出了同样的事情 。这种欺骗“攻击”实际上是在迁移到中继之前在其他类型的节点上开始的，而这些其他节点受到了大量欺骗连接的攻击，导致它们在某些情况下实际上被暂时关闭！证明攻击确实有效……您也可能是目标！回顾一下可能发生的事情：恶意攻击者可以访问未经 BCP38 过滤的网络。它们向许多随机互联网机器上的端口 22 发送 TCP 连接请求 - 可能故意选择已知的蜜罐或已知发送自动滥用投诉的网络。这些 TCP 连接请求使用伪造的源 IP 地址，使目标机器认为伪造的源发送了该连接。它们成为自动滥用投诉的目标。当数量足够大时，欺骗性的 IP 很快就会被许多遵循黑名单的互联网实体列入黑名单，并且托管服务提供商可能会因为许多滥用报告而采取行动，并因受到攻击/恶意而关闭服务器。这次攻击与 Tor 无关！我其实很惊讶这是我第一次听说这种攻击，因为虽然这种攻击很巧妙，但对于一个有动机的攻击者来说，似乎没有什么特别困难的。你也可以让你朋友的托管服务提供商（当然，在他们同意的情况下）关闭他们的服务器并取消他们的托管合同，方法是让他们收到大量善意但混乱的滥用投诉。conclusion互联网在 25 年前就已崩溃，25 年后仍然崩溃。伪造的源 IP 地址在 2024 年应该不会再成为问题，但更大的互联网社区似乎完全不愿意执行任何可以让互联网对每个人都更安全的规则或基本安全。这不仅仅是 BCP38 - RPKI 在部署方面也是一场类似的灾难，而且它之所以开始加速发展，只是因为它影响了那些开始对其直接同行实施要求的大型互联网公司。我不清楚这次攻击的下一步是什么。很明显，它已经肆虐了。我不知道它是否已经被人知晓和记录下来。但它似乎仍在起作用，很难追踪（我不知道有什么方法可以找出伪造 IP 数据包的真正来源 - 没有“事后”跟踪路由，即使有，也必须由某个上游提供商来完成才能获得有用的信息）。但是，如果您现在收到这样的滥用投诉，您现在可能更清楚要查找什么以及如何回复托管服务提供商，以尝试说服他们您实际上是受害者而不是肇事者！谁知道呢，他们甚至可能愿意听。这篇文章是在登机前几个小时匆忙写下的。缺少校对和可能出现的错别字，敬请谅解！