воскресный DDoS. Что это было и как я его смог победить

Время на прочтение: 3 мин

Всем привет, дорогие друзья!
У себя в telegram я обещал выпустить разбор воскресной ситуации.
Не хочу долго что-то расписывать здесь, по этому, начали!

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

В 18:23 МСК мониторинг сообщил мне о недоступности моего ресурса.
К решению проблемы я приступил где-то около 18:30, 18:45.
Для начала я предположил, что проблема с веб сервером или чего хуже, с php-fpm.
Проверив конфигурации, посмотрев на статус процессов я понял, что все должно быть в порядке.
Открываем сайт и наблюдаем ооооочень долгую загрузку. Если до 18:55 сайт ещё худо бедно открывался, то после этого времени уже нет.

19:00- 20:00 МСк

Решаю проанализировать логи и из картины, которая мне была предоставлена сделал вывод:
Кто-то пытается все-таки сайт уложить. Метод был выбран очень странный. Задача атакующего была в том, чтобы веб сервер или то, что обрабатывает запросы пользователей, захлебнулось от тех самых запросов.
Были попытки вызвать несуществующие страницы, неизвестные запросы к wordpress через api, которые должны были быть отключены, и ещё множество действий, которые были направлены на прекращение работы веб сервера.
Как итог, apache захлебнулся, но продолжал работать!


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


Снова вернулись к конфигам apache и php-fpm.
Увеличил все лимиты, которые мог, подкорректировал конфиг fpm.
Дальше, методом проб и ошибок и анализа логов понял, что http/2 у меня работает совсем не так, как мне бы этого хотелось.
Погуглив немного, изменил некоторые настройки apache, чтобы все работало как нужно. Но проблему этим не победили!

заключение и кратко о дальнейшей развязке

Если совсем кратко:
В 20:51 сайт вроде отпустило.
Вчера в ходе технических работ я подправил конфигурации фаервола, сделал правила ещё более агрессивно, поправил ошибки в модулях php-fpm, настроил правильный кеш, задействовав одновременно redis и OPCache, выпилил с сайта лишние плагины, тк это может создавать угрозы безопасности и открывать злоумышленникам уязвимости.
Теперь я думаю, что подобная проблема больше не повторится.

резюмирую

Эта ситуация стала возможна благодаря совокупности следующих факторов:
1. Веб сервер и php-fpm не были настроены должным образом после переезда.
2. На сайте часть правил для плагина с фаерволом были ослаблены, что и сделало возможность отправлять такое множество различных запросов.
3. На сервере в фаерволе не было достаточно реализованных правил и фильтров, чтобы не пропускать все эти действия.
А на этом у нас все!
Ожидаю ваши предложения по данной рубрике в комментариях.
Возможно вы ждали больше технических подробностей, но получилось, как получилось.
Первый блин комом!
Предлагайте идеи, а я постараюсь учесть их в будущих материалах.
Всем спасибо за внимание!
Не прощаемся!

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *