Как бороться с DDOS атакой на сайт в виде частых POST запросов на главную страницу?

Question

[Андрей Еськов]

Подскажите методы борьбы с DDOS. На протяжении 2-х дней сайт кладёт на 2-3 часа большое количество POST на главную страницу.

access.log

78.41.102.131 - - [18/Aug/2020:11:12:22 +0300 - 12.047] 499 "POST / HTTP/1.1" 0 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.8a5) Gecko/20041122" "-"
78.41.102.131 - - [18/Aug/2020:11:12:22 +0300 - 7.671] 499 "POST / HTTP/1.1" 0 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.8a5) Gecko/20041122" "-"
45.12.19.35 - - [18/Aug/2020:11:12:22 +0300 - 9.931] 499 "POST / HTTP/1.1" 0 "-" "Mozilla/5.0 (Linux; Android 10; LM-V350) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.47 Mobile Safari/537.36" "-"
46.29.192.139 - - [18/Aug/2020:11:12:22 +0300 - 3.596] 499 "POST / HTTP/1.1" 0 "-" "Mozilla/5.0 (X11; Linux i686; rv:10.0) Gecko/20100101 Firefox/10.0" "-"
46.29.192.139 - - [18/Aug/2020:11:12:22 +0300 - 3.491] 499 "POST / HTTP/1.1" 0 "-" "Mozilla/5.0 (X11; Linux i686; rv:10.0) Gecko/20100101 Firefox/10.0" "-"
31.44.12.16 - - [18/Aug/2020:11:12:22 +0300 - 12.179] 499 "POST / HTTP/1.1" 0 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; APCPMS=^N20160719104810771416F4BAA3227ADDE13F_13562^; Trident/7.0; rv:11.0) like Gecko" "-"
78.41.102.131 - - [18/Aug/2020:11:12:22 +0300 - 8.892] 499 "POST / HTTP/1.1" 0 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20100101 Firefox/10.0" "-"
78.41.102.131 - - [18/Aug/2020:11:12:22 +0300 - 7.437] 403 "POST / HTTP/1.1" 243 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20100101 Firefox/10.0" "-"
185.70.105.127 - - [18/Aug/2020:11:12:22 +0300 - 1.278] 499 "POST / HTTP/1.1" 0 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; APCPMS=^N20160719104810771416F4BAA3227ADDE13F_13562^; Trident/7.0; rv:11.0) like Gecko" "-"
178.35.230.10 - - [18/Aug/2020:11:12:22 +0300 - 10.146] 499 "POST / HTTP/1.1" 0 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060126" "-"

Около 500 000 подобных запросов за 1 час. Как видно, некоторые удалось отсеять при помощи добавления в .htaccess блокировки POST.

<Limit POST>
    Order Allow,Deny
    deny from all
</Limit>

Но это не помогло не все обращения падают с 403. И сайту это несколько не помогает.
Как бороться? Я кстати пробовал ещё весь файл вставлял в эксель, брал все ip запросов с которых было более 100 и добавлял в iptables, но тоже не помогло.

PS ------
Интересные факты
- В логах видел постоянное присутствие бота который проверял доступность сайта. (https://uptimerobot.com/ )
- После любого действия по блокировке атака менялась. Переключали запросы с POST на GET, меняли атакуемый адрес, и пул ip постоянно пополнялся.

Comments

[Андрей Еськов]

Pardon Me! Where Do I Find 4giveness? подправил сообщение.

А почему POST запросы на главную ввобще кладут ваш сайт? Эти запросы как-то сложно обрабатываются?

Возможно потому, что их очень много ежесекундно. Просто забивают очередь.

Что за CMS или на чём вообще сайт написан?

Bitrix

Почему бы в роутере не сказать, что на главную страницу проходят только GET запросы, другие - отсеивать?

Пробовал вот так и не помогло, большая часть запросов всё равно проходит

<Limit POST>
    Order Allow,Deny
    deny from all
</Limit>

[Дмитрий]

Андрей Еськов, вот можно все остальные теги убрать, оставить только Bitrix

насколько помню, у них была какая-то облачная шняга для ддоса

Answer 1

[Кирилл Несмеянов]

Перекиньте DNS на халявную версию CloudFlare. Потом можно будет обратно, если будет желание.

Comments

[Андрей Еськов]

Да это 1 из вариантов.

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

Пару месяцев тишина. Вчера позвонили с этой компании, спросил почему перестали платить. И в этот же день ночью началось это веселье. Причём сайт ложат ненадолго, 1-2 часа, патом перерыв и снова.

Не говорю про заговор, но и совпадением не назвать.

[Антон Р.]

Андрей Еськов, А назовите эту компанию, думаю сообщество должно знать таких "героев".

[Андрей Еськов]

stormwall.pro
Утверждать не буду, что это они делают. Но слишком всё совпало.

[Кирилл Несмеянов]

Андрей Еськов, да тут даже без предположений очевидно, что это они. DDOS - это невероятно редкое событие.

[profesor08]

Кирилл Несмеянов, дудосят нонстоп по всему миру, в особенности конкурентов, а особенно свежих во время рекламной компании. Для игровых серверов это в порядке вещей и никого не удивляет.

Answer 2

[Андрей Еськов]

В общем помогло следующее.
Взял весь файл access.log засунул в эксель, фильтранул по POST на главную. Далее все хосты которые делали больше 30 запросов заблокировал через iptables и перезагрузил сервер.
iptables -I INPUT -s 0.0.0.0 -j DROP

Далее подключил CloudFlare систему, чтобы не делать это вручную. Помогло сайт заработал нагрузка упала.
Большое всем спасибо!

Comments

[PrAw]

Проблема в том, что злые люди могли запомнить старый ип адрес сервера и начнут бомбить напрямую, без запроса к DNS. Но если помогло - отлично.

[Андрей Еськов]

Да я вас понял. Я просто нашёл у битрикса блокировку обращений по различным хостам.

Он блокирует любые обращения с любых хостов отличающихся от указанных. Я там поставил чтобы только хосты по домену пропускал. Пака всё хорошо.

Но я Вас услышал буду учитывать и данный факт, если что сменю ip сервера.

Answer 3

[PrAw]

Блокировать апачем поздно - ресурсы на обработку запроса уже выделены.
Поищите общие закономерности (возможно только пара организаций и блокируйте в iptables целыми подсетями по /24 или вообще весь диапазон адресов из WHOIS.
Еще лучше на вышестоящем оборудовании.
Сотня уников как-то не сильно много.

Заодно к переводу на DDos защиту от CloudFlare надо бы и ип адрес сервера сменить и не светить его нигде.

Заодно можно позаниматься точечным фекало-метанием - смотрим abuse адреса и пишем проникновенное письмо с жалобой на нехороших клиентов. Учитывая, что все перечисленные в юрисдикции РФ, можно вежливо намекнуть на судебное решение вопроса при необходимости, хотя вряд ли поможет.

78.41.100.0/22 - RU-MEGAFON-20070808
https://apps.db.ripe.net/db-web-ui/query?searchtex...

45.12.19.0/24 - BEGET-NET-75, RU
https://apps.db.ripe.net/db-web-ui/query?searchtex...

46.29.192.128/25 - TrofimovOA-NET, RU, дружит с MEGAFON-RIPE-MNT
https://apps.db.ripe.net/db-web-ui/query?bflag=fal...

31.44.12.0/23 - RU-PUDLINK-SERVICES, LLC "PUDLINK", Saint-Peterburg
https://apps.db.ripe.net/db-web-ui/query?bflag=fal...

78.41.100.0/22 - Povolzhie Branch of OJSC MegaFon, broadband inet access pools
https://apps.db.ripe.net/db-web-ui/query?bflag=fal...

185.70.105.0/24, HOSTKEY-RU-MNT
https://apps.db.ripe.net/db-web-ui/query?bflag=fal...

178.35.0.0/16 - Rostelecom networks, ROSTELECOM-MNT
https://apps.db.ripe.net/db-web-ui/query?bflag=fal...