TL; DR攻击者将源IP替换为服务器的地址并触发自动滥用。 结果，客户端被禁止进行不存在的恶意活动。由vdsina.ru评论：
这篇文章是由我们的客户撰写的，在DDoS攻击后，他从一个大型托管商那里传递给我们，并同意分享这个故事。
我将告诉您有关DDoS攻击的一种令人难以置信的阴险方式，这是我以前从未遇到过的。 阴险的是，不会对受害者的服务器本身进行攻击。 取而代之的是，攻击者激发了第三方攻击检测系统的运行，从而迫使对服务器产生完全真实的投诉（在普通人中为“滥用”）。
从托管者的角度来看，您似乎正在从事恶意活动，尽管实际上并非如此。 事实证明，许多大型托管服务提供商尚未准备好深入了解问题的原因，而宁愿只是禁止您违反规则。
本文详细介绍了这种攻击。
时间表
我在一台知名主机上的VPS服务器上保留了几个个人项目。 我收到他的来信后：
＃9042382：违反ToS-恶意活动
你好
我们收到了来自您的服务器XXXX的恶意活动的报告。 我们要求您尽快对此事进行调查。 完成调查后，请对此票提供以下问题的答案：
...
Reported-From: abuse-out@checkdomain.de Category: info Report-Type: info Service: different services Version: 0.1 User-Agent: Checkdomain Express 0.19 Date: Fri, 26 May 2018 19:25:19 +0200 Source-Type: ipv4 Source: my-server-ip-xx-xxx Port: dif. Report-ID: dih3cefnp@checkdomain.de Schema-URL: http://www.blocklist.de/downloads/schema/info_0.1.1.json Attachment: text/plain DETAILS ZU DEN ATTACKEN/STÖRUNGEN | DETAILS OF THE ATTACKS (letzten 60 Tage / max. 100 St.) | (last 60 days / max. 100 hits) portflood: syn | | standby.checkdomain.de | VORHERIGE SPERREN DER IP-NUMMER | BANNED HISTORY OF THIS IP-NUMBER my-server-ip-xxx-xxx-xxx: this ip-number was never banned before AUZUG AUS SERVERLOGDATEI | EXCERPT FROM SERVER LOGFILE tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:41667 SYNRECV - tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:46208 SYNRECV - tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:13000 SYNRECV - tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:39104 SYNRECV - tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:55348 SYNRECV - tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:37266 SYNRECV - tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:60684 SYNRECV - tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:63878 SYNRECV - tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:50445 SYNRECV - tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:56215 SYNRECV -
其中
my-server-ip-xx-xxx是服务器IP地址。
在其中，托管人向我发送了关于其滥用@邮箱的投诉，并紧急要求停止恶意活动，否则我将被阻止。 随附的日志显示了处于SYN RECEIVED状态的到80（HTTP）端口的TCP连接的列表。 也就是说，从我的服务器到某人的Web服务器有SYN泛洪。
我的第一个想法是，他们入侵了我，SYN Flood来自我的服务器。 在Linux上，使用普通用户权限管理套接字有限制，并且只能使用root特权仅发送SYN数据包（不建立完整的TCP连接）。 这意味着它们已经完全破裂。
慌乱中，我跑到服务器寻找恶意进程。 我检查top，ss，lsof，但没有发现可疑之处。 主要结论是：“
可怕的是，他们可能充斥了如此酷的rootkit，它在所有系统实用程序的内核级别都隐藏了该病毒！ ”。 在研究过程中，事实证明服务器上的负载没有改变，根据主机面板中的图表，接口上的流量保持不变。
在此之前，我使用显示出站流量的过滤器启动了
tcpdump ，并且没有发现任何可疑的内容。 绝望的是，我决定查看到服务器的所有流量。 我在合法流量中发现了来自奇怪服务器的稀有RST数据包。
看起来像这样，其中
my-server-ip-xx-xxx是我的服务器
的地址：
IP 85.10.207.190.http > my-server-ip-xx-xxx.8389: Flags [R] IP 85.10.207.190.http > my-server-ip-xx-xxx.8389: Flags [R] IP 85.10.207.190.http > my-server-ip-xx-xxx.8389: Flags [R] IP adsl-070-154.sip.pns.bellsouth.net.http > my-server-ip-xx-xxx.8389: Flags [R] IP adsl-070-154.sip.pns.bellsouth.net.http > my-server-ip-xx-xxx.8389: Flags [R] IP adsl-070-154.sip.pns.bellsouth.net.http > my-server-ip-xx-xxx.8389: Flags [R]
很明显，这是一个异常，因为与这些服务器之间不再进行任何交换，并且为什么它们发送了数据包以关闭连接，所以我不清楚。
此时，经验丰富的管理员会立即了解所有内容，但我们会尽一切努力
如何运作
传入的RST数据包是对尝试建立到专用端口的TCP连接的响应。 同时，没有从我的服务器到发送RST的服务器的传出流量。 这意味着攻击者用我的替换出站地址，并产生类似于DDoS攻击的流量。 但是，由于攻击者唯一能做的就是发送传出数据包，因此来自服务器的所有响应都将到达我的服务器。
只有假请求的答案才能到达受害者的服务器通常，当攻击者代表受害者发送小的请求，而受害者收到他未请求的大响应时，此类攻击将用于DNS放大 。 这是经典的信道耗尽攻击机制。
就我而言，攻击者并未着手耗尽受害者服务器的通道。 其活动在渠道的消费图表上是完全看不见的。 它的主要目的是激发网络攻击的自动通知系统，该系统会发送一封信，抱怨在我的提供商的whois子网中指定的滥用地址。 诸如
Snort和
Suricata之类的
侵入式预防/检测系统 可以做到这一点 。
结果，托管人收到了来自合法公司的绝对真实的信件，其中包含有关我的恶意活动甚至真实日志的投诉。 同时，攻击者不需要大的通道，因为他可以预先知道安装IDS / IPS系统的服务器的地址以及自动投诉工作所需的最小数据包数量。
攻击者的唯一困难是找到一个服务器，该服务器允许替换数据包中的传出IP地址。 所有普通主机都阻止此类数据包。 托管只有两种类型，允许客户端替换传出的IP：配置非常不熟练，或者是专门为网络犯罪创建的。
检查IP地址欺骗的可能性
我建议您检查主机是否有替换外发IP的可能性。 这将需要两台服务器，一台用于接收流量，另一台用于发送。
在接收服务器端，我们将开始记录传入流量。 我们将指定一个稀有端口作为过滤器，正常情况下该端口上不应有流量：
tcpdump -i any port 9912
在我们正在测试的服务器上，我们将生成一个包，其中将传出IP地址替换为指向端口9912的
1.1.1.1 。为此，我们使用了来自nmap开发人员的酷实用程序
nping 。 它允许您在L2和L3级别生成任何非标准软件包。
nping --tcp -p 9912 -S 1.1.1.1 receiver-server.com
receiver -server.com-运行tcpdump的侦听服务器的地址
1.1.1.1-替代外发地址
9912-远程端口
如果在receive-server.com的一侧看到代表1.1.1.1的数据包，则您的提供程序允许您替换传出IP地址。 这是一个向他通报设置网络设备问题的机会。 通常，此问题会受到家庭Internet服务提供商的影响。
愚蠢的技术支持
在找出投诉的原因之后，我向主持人详细介绍了所有内容：
你好
我终于明白发生了什么事。
他们使用我的地址作为源地址来欺骗我的IP地址和DDoS随机主机。 因此，受害者会向我的托管服务提供商生成自动的滥用报告。
您可以在滥用日志上看到连接仅处于SYN_RECV状态（未建立完整的TCP连接），因为它们只能使用欺骗性IP发送一个数据包，并且无法完成TCP握手。
我可以证明这一点。 现在有许多TCP RST传入数据包从从未发送过任何数据包的主机发送到我的服务器。
您可以通过运行以下命令立即检查它：
tcpdump -i eth0“ tcp [tcpflags]＆（tcp-rst）！= 0”
您将看到许多RST数据包来自从未向其发送任何数据的主机。
这证明攻击者欺骗了我的IP地址，以危害我并造成滥用。
然后在我看来，任何合格的技术支持工程师都将了解情况，并且问题将被解决。 但是，相反，他们要求我使用防病毒软件检查服务器或完全重新安装操作系统。 在我们获得技术支持的情况下，滥用行为继续蔓延，并在一天之内被禁止。
竟然被我陷害了，这真是侮辱。 这种情况说明了脆弱的人是多么脆弱，他们不加理understanding地遵循脚本。 从那时起，当有关为重要项目选择托管的辩论出现时，我经常以这个案例为例。 不幸的是，许多托管公司根本无法将大量时间花在处理非标准的小型客户上，而且禁止您比解决问题还容易。
订阅我们的Instagram开发人员
