Как обеспечить надежность сервиса под атакой

24 сентября 2020

На нынешней неделе мы рассмотрим последнюю по порядку, но отнюдь не по значимости задачу по повышению защищаемости от DDoS — обеспечение надежности сервиса под атакой.

Первые три задачи мы рассмотрели в предшествующих постах. На всякий случай перечислим их:

Предоставить как можно меньше информации атакующему
Предоставить как можно больше информации DDoS-защитнику
Обеспечить понятные возможности фильтрации атаки

В ЧЕМ ПРОБЛЕМА

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

Какие параметры могут влиять на доступность сервиса во время атаки?

Число точек отказа — чем их меньше, тем надежнее будет работать сервис. И наоборот. Поэтому, например, необдуманно широкое применение Round-Robin DNS опасно тем, что в случае «падения» доступности одного из IP-адресов для части клиентов сервис станет недоступным.
Резервирование на уровне приложения. В одном из предыдущих постов мы уже рассказывали о сервисе такси, который параллельно использует несколько IP-адресов для подключения водителей и, если один адрес «падает», то переподключает таксистов, которые на нем работали, на другой адрес. Согласитесь, вывести из строя сервис, где само серверное приложение “заботится” о доступности, злоумышленнику будет сложно.
Зависимость компонентов системы друг от друга и способность работать автономно. Вспомним пример игрового сервиса, который использует общую базу данных. Критичные функции без нее могут выполняться, но если база данных станет недоступна, то, например, сайт не сможет подгрузить из нее список лучших игроков и в целом тоже окажется недоступен.

УСТОЙЧИВОСТЬ К СЛАБЫМ АТАКАМ — ОСНОВА НАДЕЖНОСТИ СЕРВИСА

Идея проста: если сервис не выстоит во время слабой атаки, то против серьезной и вовсе будет бессилен.

В некоторых случаях обеспечить стопроцентную фильтрацию трафика сервиса невозможно — например, при асимметричном подключении защиты Anti-DDoS. А между тем, его очень часто используют и дата-центры, и хостинг-провайдеры, и интернет-провайдеры. В подобных ситуациях атака минимизируется не полностью — она ослабляется. В идеале Ваш сервис должен суметь обеспечить работоспособность и доступность во время такой ослабленной атаки.

Рассмотрим характерный пример

Один из наших клиентов подвергся атаке посредством UDP, и его сервис против нее выстоял. Следом началась не такая уж сильная атака через HTTP. Если бы сервис защиты от атак такого рода был подключен, ее легко можно было бы легко отсечь, но поскольку клиент не захотел подключать защиту от HTTP-атак, сервис «лёг». Непосредственной причиной отказа стало то, что клиент использовал «древний» роутер, использовавшийся в качестве Edge-маршрутизатора, который «загнулся» от непомерной для него атаки 10 тыс. ботов посредством HTTP. Отсюда вывод: необходимо оценивать устойчивость к слабым атакам не только сервера, на котором развернут сервис, но и всей сети, внутри которой он расположен. В частности, настоятельно не рекомендуем использовать старые маломощные сетевые устройства, а также устройства класса SOHO в домашней сети.

Для повышения устойчивости системы очень полезно оптимизировать сетевой стек операционной системы: например, прерывания сетевой карты должны быть разнесены по разным процессорным ядрам. В Интернете есть множество статей о том, как это лучше сделать.

И конечно, необходимо позаботиться об устойчивости приложения. В частности, нужно убедиться, что оно начинает выполнять по-настоящему «тяжелые» функции только после того, как завершится процедура авторизации, — в этом случае приложение, скорее всего, сможет выдержать «нашествие» ботов, поскольку основной запас производительности сервера оно расходует только на легальных пользователей.

Наконец, нужно разделять сервисы, разводя их функции по разным IP-адресам: сайт — отдельно, сервис аутентификации — отдельно, основные сервисы — также на отдельные адреса. Такое разделение позволит заранее отсечь множество векторов DDoS-атак.

ФИКСИРУЕМ РЕКОМЕНДАЦИИ

Позаботьтесь о доступности сервиса БЕЗ атаки: проверьте точки отказа, зависимость компонентов друг от друга и возможности резервирования.
Обеспечьте устойчивость системы к слабым атакам — как на уровне сети, так на уровнях ОС и приложения.
Разнесите разные функции на разные адреса — и сообщите об этом защитнику.