TL;DR Атакующий подменяет source ip на адрес вашего сервера и триггерит автоматические абузы. В результате клиента банят на хостинге за вредоносную активность, которой не было.

Комментарий от vdsina.ru:
Эта статья написана нашим клиентом, который перешёл к нам от крупного хостера после DDoS-атаки и любезно согласился поделиться этой историей.

Расскажу про удивительно коварный способ DDoS-атак, с которым я раньше не сталкивался. Коварство заключается в том, что на сам сервер жертвы не выполняется никакой атаки. Вместо этого, злоумышленник провоцирует срабатывание сторонних систем обнаружения атак, заставляя генерировать совершенно настоящие жалобы (в простонародье «абузы») на ваш сервер.

Со стороны хостера это выглядит так, будто вы занимаетесь вредоносной активностью, хотя на самом деле это неправда. Оказалось, что многие крупные хостинг-провайдеры не готовы глубоко разбираться в причинах проблемы и предпочтут вас просто забанить за нарушение правил.

В статье подробно разбирается этот вид атаки в реальном кейсе.

Хронология событий

Я держал несколько личных проектов на VPS-серверах у одного известного хостера. Однажды мне пришло от него такое письмо:

#9042382: ToS Violation — Malicious Activity
Hello,

We have received a report of malicious activity originating from your server XXXX. We ask that you investigate this matter as soon as you are able. Once you have completed your investigation, kindly reply to this ticket with the answers to the following questions:
…

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/STORUNGEN | 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-адрес сервера.

В нем хостер пересылает мне жалобу, поступившую на его ящик abuse@, и настойчиво просит прекратить вредоносную активность, иначе я буду заблокирован. В приложенном логе виден список TCP-подключений к 80 (HTTP) порту в состоянии SYN RECEIVED. То есть с моего сервера идёт SYN-флуд на чей-то веб-сервер.

Первая мысль — меня взломали и с моего сервера идёт SYN-флуд. В Linux есть ограничения на управление сокетами с правами обычного пользователя и посылать только SYN-пакеты (без установки полноценного TCP-соединения) можно только имея привилегии root. А это значит, что взломали полностью.

В панике бегу на сервер искать вредоносный процесс. Проверяю top, ss, lsof и ничего подозрительного не вижу. Первичный вывод: "ужас, наверное залили настолько крутой руткит, который прячет вирус на уровне ядра от всех системных утилит!". В процессе исследований выясняется, что нагрузка на сервер никак не изменилась, по графикам в панели хостера трафик на интерфейсе остается прежним.

До этого я запускал tcpdump c фильтрами, показывающими исходящий трафик и ничего подозрительного не видел. Отчаявшись, решаю посмотреть весь трафик на сервер. В потоке легитимного трафика нахожу редкие 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-амплификации, когда атакующий посылает маленький запрос от имени жертвы, а жертве приходит большой ответ, которого он не запрашивал. Это классический механизм атак на исчерпание канала.

В моем случае атакующий не ставил целью исчерпать канал сервера-жертвы. Его активность была совершенно незаметна на графиках потребления канала. Главной его целью было спровоцировать системы автоматического уведомления о сетевых атаках, которые пошлют письмо с жалобой на abuse-адрес, указанный в whois подсети моего провайдера. Это умеют делать системы обнаружения и предотвращения вторжений (Intrusive Prevent/Detect System), такие как Snort и Suricata.

В результате хостер получает абсолютно настоящее письмо от легитимных компаний, в котором содержится жалоба на мою вредоносную активность и даже логи в них настоящие. При этом атакующему не нужен большой канал, так как он заранее знает адреса серверов, на которых установлены IDS/IPS-системы и минимально необходимое число пакетов, чтобы сработала автоматическая жалоба.

Единственной трудностью для атакующего является поиск сервера, разрешающего подмену исходящих IP-адресов в пакетах. Все нормальные хостеры блокируют такие пакеты. Существует только два типа хостинга, позволяющего клиентам подменять исходящий IP: либо очень безграмотно настроенный, либо специально созданный для кибер-криминала.

Проверяем возможность подмены IP-адреса

Советую вам проверить своего хостера на возможность подмены исходящего IP. Для этого потребуется два сервера, один для приёма трафика, другой для отправки.

На стороне принимающего сервера запустим логирование входящего трафика. В качестве фильтра укажем редкий порт, на котором в обычное время не должно быть трафика:

tcpdump -i any port 9912

На проверяемом сервере сгенерируем пакет с подменой исходящего IP-адреса на 1.1.1.1, направленный на порт 9912. Для этого используем крутую утилиту nping от разработчиков nmap. Она позволяет генерировать любые нестандартные пакеты на уровне L2 и L3.

nping --tcp -p 9912 -S 1.1.1.1 receiver-server.com

receiver-server.com — адрес слушающего сервера, на котором запущен tcpdump
1.1.1.1 — подменяемый исходящий адрес
9912 — удалённый порт

Если на стороне receiver-server.com вы увидите пакет, пришедший от имени 1.1.1.1, значит ваш провайдер позволяет подменять исходящий IP-адрес. Это повод сообщить ему о проблемах в настройке сетевого оборудования. Зачастую такой проблемой страдают домашние интернет-провайдеры.

Глупая техподдержка

Разобравшись в причинах жалоб, я подробно все изложил хостеру:

Hello,
I finally understand what happened.

They spoof my IP address and DDoS random hosts using my address as source address. So victims generate automatic abuse reports to my hosting providers.

You can see on abuse log that connections are only in SYN_RECV state (no full TCP-connection established) because they can send only one packet using spoofed IP and can't finish TCP-handshake.
I can prove this. There are many TCP RST incoming packets coming right now to my server from hosts whom I never sent any packets.

You can check it right now by running:

tcpdump -i eth0 «tcp[tcpflags] & (tcp-rst) != 0»

You will see that many RST packets came from hosts to which I've never sent any data.
This proves that attacker is spoofing my IP-address to compromise me and generate abuses.

Тогда мне казалось, что любой квалифицированный инженер техподдержки разберётся в ситуации и вопрос будет закрыт. Но вместо этого они требовали от меня проверить сервер антивирусом или полностью переустановить ОС. Пока мы переписывались с техподдержкой, абузы продолжали поступать и через сутки меня забанили.

Было дико обидно, что меня фактически подставили. Эта ситуация показывает, насколько уязвимы люди, которые вместо того, чтобы разбираться, бездумно следуют скриптам. С тех пор я часто привожу этот случай в пример, когда заходит спор о выборе хостинга для важных проектов. К сожалению, многие хостеры просто не могут позволить себе уделять много времени нестандартным случаям мелких клиентов и вас проще забанить, чем разбираться в ваших проблемах.

Подписывайтесь на нашего разработчика в Instagram