img src https habrastorage org webt i6 x7 om i6x7omrejaehro4mws5i sygn

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
<img src="https://habrastorage.org/webt/i6/x7/om/i6x7omrejaehro4mws5isygnptk.jpeg" />
<b>TL;DR Атакующий подменяет source ip на адрес вашего сервера и тригерит автоматические абузы. В результате вас банят на хостинге за вредоносную активность которой не было.</b>
В статье описывается удивительно коварный способ DDoS-атак, с которым я раньше не сталкивался. Коварство заключается в том, что на сам сервер жертвы не выполняется никакой атаки, вместо этого, злоумышленник провоцирует сработку сторонних систем обнаружения атак, заставляя генерировать совершенно настоящие жалобы (в простонародье "абузы") на ваш сервер.
Со стороны хостера это выглядит так, будто вы занимаетесь вредоносной активностью, хотя на самом деле это не правда. Оказалось, что многие крупные хостинг-провайдеры не готовы глубоко разбираться в причинах проблемы и предпочтут вас просто забанить за нарушение правил.
В статье подробно разбирается данный вид атаки на реальном примере.
<cut />
<h2>Хронология событий</h2>
Я держал несколько личных проектов на VPS-серверах у одного известного хостера. Однажды мне пришло такое письмо хостера:
<blockquote>
<b>#9042382: ToS Violation - Malicious Activity</b>
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:
....
<source>
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 -
</source>
</blockquote>
Где <b>my-server-ip-xx-xxx</b> это IP-адрес сервера.
В нем хостер пересылает мне жалобу, поступившую на его ящик abuse@ и настойчиво просит прекратить вредоносную активность иначе я буду заблокирован. В приложенном логе виден список TCP подключений к 80 (HTTP) порту в состоянии SYN RECIVED. То есть с моего сервера идет SYN-флуд на чей-то веб-сервер.
Первая мысль — меня взломали и с моего сервера идет SYN-флуд. В Linux есть ограничения на управление сокетами с правами обычного пользователя, и посылать только SYN-пакеты (без установки полноценного TCP-соединения) можно только имея привелегии root. А это значит что взломали полностью.
В панике бегу на сервер искать вредоносный процесс. Проверяю top, ss, lsof и ничего подозрительного не вижу. Первичный вывод: "<i>ужас, наверное залили настолько крутой руткит, который прячет вирус на уровне ядра от всех системных утилит!</i>". В процессе исследований выясняется, что нагрузка на сервер никак не изменилась, по графикам в панели хостера, трафик на интерфейсе остается прежним.
До этого я запускал <b>tcpdump</b> c фильтрами показывающими исходящий трафик, и ничего подозрительного не видел. Отчаявшись, решаю посмотреть весь трафик на сервер. В потоке легетимного трафика нахожу редкие RST-пакеты от странных серверов.
Выглядит это примерно так, где <b>my-server-ip-xx-xxx</b> адрес моего сервера:
<source>
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]
</source>
Было очевидно, что это аномалия, так как никого больше обмена с этими серверами не было, и почему они шлют пакет закрытия соединения мне было неясно.
На этом моменте опытные админы сразу бы все поняли, но мы разберем все на пальцах
<h2>Как это работает</h2>
Входящие RST-пакеты это ответы на попытки установить TCP-соединение на закрытый порт. При этом от моего сервера никакого исходящего трафика в сторону серверов посылающих RST нет. Это значит, что атакующий подменяет исходящий адрес на мой и генерирует трафик, похожий на DDoS-атаку. Но так как единственное, что может атакующий это послать исходящий пакет, все ответы от серверов приходят на мой сервер.
<img src="https://habrastorage.org/webt/nd/g7/a-/ndg7a-fdzrxswv3sjvd8jwvykym.png" />
<font color="999999"><sup>До сервера жертвы доходят только ответы на поддельные запросы</sup></font>
<blockquote>Обычно, такие атаки используются для <a href="https://www.cloudflare.com/learning/ddos/dns-amplification-ddos-attack/">DNS-амплификации</a>, когда атакующий посылает маленький запрос от имени жертвы, а жертве приходит большой ответ которого он не запрашивал. Это классический механизм атак на исчерпание канала.</blockquote>
В моем случае атакующий не ставил целью исчерпать канал сервера-жертвы. Его активность была совершенно незаметна на графиках потребления канала. Главной его целью было спровоцировать системы автоматического уведомления о сетевых атаках, которые пошлют письмо с жалобой на abuse-адрес указаный в whois подсети моего провайдера. Это умеют делать системы обнаружения и предотвращения вторжений (<a href="https://ru.wikipedia.org/wiki/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0_%D0%BE%D0%B1%D0%BD%D0%B0%D1%80%D1%83%D0%B6%D0%B5%D0%BD%D0%B8%D1%8F_%D0%B2%D1%82%D0%BE%D1%80%D0%B6%D0%B5%D0%BD%D0%B8%D0%B9">Intrusive Prevent/Detect System</a>), такие как <a href="https://www.snort.org/">Snort</a> и <a href="https://suricata-ids.org/">Suricata</a>.
В результате хостер получает абсолютно настоящее письмо от легитимных компаний, в которых содержится жалоба на мою вредоносную активность, и даже логи в них настоящие. При этом атакующему не нужен большой канал, так как он заранее знает адреса серверов, на которых установлены IDS/IPS-системы и минимально необходимое число пакетов, для того чтобы сработала автоматическая жалоба.
Единственной трудностью для атакующего является поиск сервера, разрешающего подмену исходящих IP-адресов в пакетах. Все нормальные хостеры блокируют такие пакеты. Существует только два типа хостинга, позволяющего клиентам подменять исходящий IP: либо очень безграмотно настроенный, либо специальной созданный для кибер-криминала.
<h2>Проверяем возможность подмены IP-адреса</h2>
Советую вам проверить своего хостера на возможность подмены исходящего IP. Для этого потребуется два сервера, один для приема трафика, другой для отправки.
На стороне принимающего сервера запустим логирование входящего трафика. В качестве фильтра укажем редкий порт, на котором в обычное время не должно быть трафика:
<source>
tcpdump -i any port 9912
</source>
На проверяемом сервере сгенерируем пакет с подменой исходящего IP-адреса на <b>1.1.1.1</b>, направленный на порт 9912. Для этого используем крутую утилиту <a href="https://nmap.org/nping/">nping</a> от разработчиков nmap. Она позволяет генерировать любые нестандартные пакеты на уровне L2 и L3.
<source>
nping --tcp -p 9912 -S 1.1.1.1 receiver-server.com
</source>
<b>receiver-server.com</b> — адрес слушающего сервера на котором запущен tcpdump
<b>1.1.1.1</b> — подменяемый исходящий адрес
<b>9912</b> — удаленный порт
Если на стороне <b>receiver-server.com</b> вы увидите пакет пришедший от имени 1.1.1.1, значит ваш провайдер позволяет подменять исходящий IP-адрес. Это повод сообщить ему о проблемах в настройке сетевого оборудования.
<h2>Глупая техподдержка</h2>
Разобравшись в причинах жалоб я подробно все изложил хостеру:
<blockquote>
Hello,
I finally understand what happened.
They spoof my IP address and DDoS random hosts using my address as source address. So victims generates automatic abuse reports to my hosting providers.
You can see that on abuse log, that connections 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 is a lot of TCP RST incoming packets coming right now to my server from hosts that I never send's any packets.
You can check it right now by running:
tcpdump -i eth0 "tcp[tcpflags] & (tcp-rst) != 0"
You will see that a lot of RST packets came from hosts that I never send's any data.
This proves that attacker spoofing my IP address to compromise me and generate abuses.
</blockquote>
Тогда мне казалось что любой квалифицированный инженер техподдержки разберется в ситуации и вопрос будет закрыт. Но вместо этого они требовали от меня проверить сервер антивирусом или полностью переустановить ОС. Пока мы переписывались с техподдержкой абузы продолжали поступать и через сутки меня забанили.
Было дико обидно, что меня фактически подставили. Эта ситуация показывает, насколько уязвимы люди, которые вместо того чтобы разбираться, бездумно следуют скриптам. С тех пор я часто привожу этот случай в пример, когда заходит спор о выборе хостинга для важных проектов. К сожалению, многие крупные хостеры просто не могут позволить себе уделять много времени нестандартным случаям мелких клиентов, и вас проще забанить, чем разбираться в ваших проблемах.