Как известно DDoS атаки на сайт бывают разной интенсивности, имеет значение количество хостов участвующих в атаке, количество сетевых пакетов и объем передаваемых данных. В самых тяжелых случаях отбить атаку возможно только применяя специализированное оборудование и сервисы.
Если же объем атаки меньше пропускной способности сетевого оборудования и вычислительных мощностей сервера (пула серверов) обслуживающих сайт, то можно попробовать “заглушить” атаку не прибегая к сторонним сервисам, а именно включить программный фильтр трафика поступающего на сайт. Этот фильтр будет отсеивать трафик ботов участвующих в атаке, при этом пропуская легитимный трафик “живых” посетителей сайта.
Схема программного фильтра от DDoS атак на сайт
Фильтр основан на том, что боты участвующие в DDoS атаках не способны выполнить JavaScript код, соответственно боты не пройдут дальше стоп-страницы фильтра, чем существенно разгрузят фронтенд/бекэнд и базу данных сайта. Т.к. на обработку каждого GET/POST запроса DDoS атаки потребуется выполнить не более 20 строк кода в бэкенде сайта и выдать страницу-заглушку объемом менее 2Кб данных.
- Фильтр вызываем первой строкой веб-приложения, до вызова всего остального кода приложения. Так можно максимально разгрузить “железо” сервера и уменьшить объем отдаваемого трафика в сторону ботов.
- Если посетитель попадает под условия фильтра, то выдаем посетителю специальную страницу-заглушку. На странице,
- Сообщаем о причинах выдачи специальной страницы вместо запрошенной
- Устанавливаем специальную куку в броузере пользователя посредством JavaScript.
- Выполняем JavaScript код перенаправления на исходную страницу.
- Если у посетителя установлена специальная кука, то фильтр прозрачно пропускает посетителя на запрошенную страницу сайта.
- Если IP адрес посетителя принадлежит автономной системе из списка исключений, то трафик так же прозрачно пропускаем. Это условие необходимо для исключения фильтрации ботов поисковых систем.
Проект фильтра на github.com.
Синтетические тесты фильтра
Тестировали утилитой ab от Apache Foundation на главной странице боевого сайта, предварительно сняв нагрузку с одной из нод.
Результаты с отключенным фильтром,
ab -c 100 -n 1000 https://cleantalk.org/
Total transferred: 27615000 bytes
HTML transferred: 27148000 bytes
Requests per second: 40.75 [#/sec] (mean)
Time per request: 2454.211 [ms] (mean)
Time per request: 24.542 [ms] (mean, across all concurrent requests)
Transfer rate: 1098.84 [Kbytes/sec] receivedТеперь тоже самое с включенным фильтром,
Total transferred: 2921000 bytes
HTML transferred: 2783000 bytes
Requests per second: 294.70 [#/sec] (mean)
Time per request: 339.332 [ms] (mean)
Time per request: 3.393 [ms] (mean, across all concurrent requests)
Transfer rate: 840.63 [Kbytes/sec] receivedКак видно из результатов тестирования, включение фильтра позволяет обработать веб-серверу почти на порядок больше запросов чем без фильтра. Естественно речь идет только о запросах, от посетителей без поддержки JavaScript.
Применение фильтра на практике, история спасения сайта от одной небольшой DDoS атаки
Периодически мы сталкиваемся с DDoS атаками на наш собственный, корпоративный сайт https://cleantalk.org. Собственно во время крайней из атак мы и применили фильтр от DDoS на уровне веб-приложений сайта.
Начало атаки
Атака началась в 18:10 UTC+5 18 Января 2018 года, атаковали GET запросами на URL https://cleantalk.org/blacklists. На сетевых интерфейсах Front-end серверов появились дополнительные 1000-1200 кбит/секунду входящего трафика, т.е. получили нагрузку 150/секунду GET запросов к каждому серверу, что выше штатной нагрузки в 5 раз. Как следствие резко вырос Load average серверов Front-end и серверов баз данных. В результате сайт начал выдавать ошибку 502 по причине отсутствия свободных процессов php-fpm.
Анализ атаки
Потратив некоторое время на изучение логов, стало понятно что это именно DDoS атака, т.к.,
- 5/6 запросов приходились на один и тот же URL.
- Отсутствовала ярко выраженная группа IP адресов создающая нагрузку на URL из пункта 1.
- CPU фронтенд серверов был загружен на порядок выше, чем всплеск нагрузки на сетевых интерфейсах.
Соответственно было решено включить фильтр посетителей сайта по алгоритму описанному выше, дополнительно включив в него проверку входящего трафика по нашей БД черных списков, тем самым уменьшив вероятность выдачи стоп-страницы легитимным посетителям сайта.
Включение фильтра
Потратив еще некоторое время на подготовку фильтра, в 19:15-19:20 он был включен.
Спустя несколько минут получили первые положительные результаты, сначала Load average вернулся к норме, затем упала нагрузка на сетевых интерфейсах. Спустя несколько часов атака повторилась дважды, но ее последствия были практически незаметны, фронтенды отработали без ошибок 502.
Заключение
В итоге, применением простейшего кода JavaScript мы решил задачу фильтрации трафика от ботов, тем самым погасили DDoS атаку и вернули показатели доступности сайта к штатному состоянию.
Честно говоря, этот алгоритм фильтрации ботов был придуман не в день атаки описанной выше. Еще несколько лет назад реализовали дополнительную функцию SpamFireWall к нашему Антиспам сервису, SpamFireWall используют более чем 10 тысяч веб-сайтов и о нем есть отдельная статья.
SpamFireWall был разработан прежде всего для борьбы со спам-ботами, но так как списки спам-ботов пересекаются со списками прочих ботов, используемых для сомнительных целей, то применение SFW вполне эффективно в том числе и для купирования небольших DDoS атак на сайт.
О сервисе CleanTalk
CleanTalk это облачный сервис защиты веб-сайтов от спамботов. CleanTalk использует методы защиты, которые незаметны для посетителей веб-сайта. Это позволяет отказаться от методов защиты, которые требуют от пользователя доказать, что он человек (captcha, вопрос-ответ и др.).
Автор: shagimuratov
