taurus2790
@taurus2790
Я не программер я только учусъ

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

Подскажите методы борьбы с 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 постоянно пополнялся.
  • Вопрос задан
  • 931 просмотр
Решения вопроса 3
SerafimArts
@SerafimArts
Senior Notepad Reader
Перекиньте DNS на халявную версию CloudFlare. Потом можно будет обратно, если будет желание.
Ответ написан
taurus2790
@taurus2790 Автор вопроса
Я не программер я только учусъ
В общем помогло следующее.
Взял весь файл access.log засунул в эксель, фильтранул по POST на главную. Далее все хосты которые делали больше 30 запросов заблокировал через iptables и перезагрузил сервер.
iptables -I INPUT -s 0.0.0.0 -j DROP

Далее подключил CloudFlare систему, чтобы не делать это вручную. Помогло сайт заработал нагрузка упала.
Большое всем спасибо!
Ответ написан
@remzalp
Программер чего попало на чем попало
Блокировать апачем поздно - ресурсы на обработку запроса уже выделены.
Поищите общие закономерности (возможно только пара организаций и блокируйте в 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...
Ответ написан
Комментировать
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы