Как обеспечить устойчивость онлайн-сервисов к DDoS-атакам

Рамиль Хантимиров

CEO и сооснователь StormWall

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

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

Необходимо сразу заметить, что единого, абсолютно универсального подхода к решению этой проблемы нет: действия, которые нужно предпринять ИТ-подразделениям, отвечающим за сопровождение и безопасность интернет-ресурсов, существенно зависят от того, что именно нужно защищать. Так, для повышения устойчивости сайтов и веб-приложений потребуются одни меры, различных интернет-сервисов и онлайн-игр на основе TCP и UDP — другие, сетей — третьи.

Сайты и веб-приложения

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

Стандартные настройки работающих в режиме продуктивной эксплуатации сетевого стека ОС и веб-сервера Apache или Nginx, как правило, имеют существенные ограничения, которые обязательно необходимо устранить. В частности, нужно обратить внимание на параметры, определяющие производительность сервера на Nginx и сетевого стека Linux. Также следует обратить внимание на оптимизацию ваших СУБД — MySQL или любой другой, какую вы выбрали, — они должны работать быстро.

Если на сайте используются популярные «движки» CMS, например, Joomla!, WordPress, Drupal, обязательно воспользуйтесь общедоступными рекомендациями по настройке их производительности. Необходимо добиться того, чтобы сайт обладал высокой производительностью в стандартном режиме — это повысит его шансы справиться с DDoS-атакой: когда она начнется, «быстрый» сайт будет проще защитить.

Если вы приняли решение развернуть приложение или сайт на внешней площадке и доверить защиту от DDoS-атак ее владельцу, то следует, по крайней мере, уточнить, сможет ли он обезопасить ваш интернет-ресурс от атак на уровне приложений — седьмом уровне модели OSI (L7). В любом случае можно подключить внешний сервис защиты, при этом нужно настроить его так, чтобы IP-адрес реального сервера не был виден злоумышленнику ни через почтовые заголовки, ни через открытые порты, ни через иные сервисы.

Вот пример из практики: интернет-магазин после начала атаки не может принимать заказы несмотря на то, что сервис защиты был подключен. Причина отказа в обслуживании — то, что прежний адрес сервера, на котором развернут веб-сервис, остался доступен через Интернет, чем и воспользовался злоумышленник. После того, как хостинг-провайдер «закрывает» этот адрес для доступа извне через порты HTTP, отказы в обслуживании на время прекращаются. Однако позже новые DDoS-атаки опять выводят сервис электронной торговли из строя, поскольку злоумышленник начал атаковать через порт 22 (SSH), который все еще открыт. Тогда хостинг-провайдер перемещает сервис на другой сервер, но через некоторое время снова начинаются отказы в обслуживании. Вероятно, опытный злоумышленник извлек адрес нового сервера из заголовков сообщений электронной почты…

Этот пример показывает, насколько важно добиться того, чтобы IP-адреса были недоступны для всех, кроме DDoS-защитника. Ну а проверить, видны ли извне адреса сервера, поможет, например, сервис Shodan. Также не лишним будет посмотреть историю прежних IP-адресов, например, тут.

Интернет-сервисы и онлайн-игры на основе TCP и UDP

Стремясь обеспечить устойчивость сервисов, взаимодействующих с пользователями посредством TCP и UDP, нужно в первую очередь оптимизировать сетевой стек операционной системы. Для начала стоит удостовериться, что прерывания сетевой карты распределены по разным процессорным ядрам. В большинстве современных систем это распределение производится автоматически, тем не менее, дополнительная осмотрительность не помешает.

Сетевая карта, прерывания, очереди…Первое, над чем нужно поработать, — это драйвер сетевой карты. Когда на нее приходит фрейм, она должна инициировать системное прерывание, которое «просит» процессор приостановить выполнение текущей задачи и обработать пришедшую порцию трафика. Однако если бы каждый фрейм вызывал незамедлительное прерывание и «отвлекал» CPU от текущих задач, заметное снижение производительности можно было бы наблюдать даже на простейших сетевых операциях, таких как передача файла по протоколу FTP. Поэтому эти прерывания выстроены в очередь, которая скапливается на сетевой карте и обрабатывается процессором за один раз. Обычно это происходит 250-1000 раз в секунду, и чем реже — тем меньше загрузка CPU, но тем выше задержка.С другой стороны, большинство современных серверов имеют несколько процессорных ядер. Поскольку ОС рассматривает каждое из них как отдельный процессор, мы можем равномерно распределить между ними нагрузку от прерываний. Есть два способа это сделать.
Первый и рекомендуемый — использовать аппаратные очереди. Современные сетевые карты имеют несколько очередей прерываний, обычно от 4 до 16. По какой-то причине в Linux они часто отключены по умолчанию. Нам нужно их включить, а затем равномерно распределить по процессорам.
Второй способ носит название RPS (Receive Packet Steering). Это относительно новый механизм ядра, который автоматически распределяет нагрузку между всеми ядрами, при этом неважно, есть ли на сетевой карте несколько аппаратных очередей или нет. Используйте этот способ, только если у вас больше ядер, чем аппаратных очередей (кстати, рассмотрите возможность отключения SMT/HyperThreading — во время атаки это будет весьма кстати).Шаги, которые нужно предпринять:1) Установите последнюю рекомендуемую версию ядра Linux для вашего дистрибутива — вместе с ним, скорее всего, будет идти свежая версия драйвера вашей сетевой карты. В отдельных случаях стоит собрать его отдельно для вашего ядра по инструкции.2) Распределите загрузки прерываний равномерно между ядрами. Для начала нужно определить, какие номера прерываний использует сетевая карта (в нашем случае eth0).# cat /proc/interrupts | grep eth0После выполнения этой команды вы сможете увидеть все номера прерываний, которые использует ваша NIC, а также их фактическое распределение по ядрам. Запишите эти числа.Теперь нам нужно поменять SMP affinity, чтобы назначить каждому прерыванию свое ядро (interrupt 1 > cpu 1, interrupt 2 > cpu 2 и т.д.). Вот как это делается:# echo > /proc/irq/xx/smp_affinityНапример, для 4-ядерного процессора:# echo 1 > /proc/irq/83/smp_affinity # 1=”0001″ т.е. 1-е ядро# echo 2 > /proc/irq/84/smp_affinity # 2=”0010″ т.е. 2-е ядро# echo 4 > /proc/irq/85/smp_affinity # 4=”0100″ т.е. 3-е ядро# echo 8 > /proc/irq/86/smp_affinity # 1=”1000″ т.е. 4-е ядроЕсли ядер больше, дальше используем шестнадцатеричные числа (hex).Примечание: в современных дистрибутивах Linux такое распределение часто производится автоматически сервисом irqbalance, но в некоторых случаях он осуществляет балансировку неоптимально. Если Вы решите распределить прерывания по ядрам самостоятельно, не забудьте выключить irqbalance.3) Опционально: включите RPS (это может не понадобиться, см. выше)# echo f > /sys/class/net/eth0/queues/rx-0/rps_cpusВыберите соответствующее устройство (если это не eth0) и все очереди приема, которое оно поддерживает (rx-0..n).

Также нужно оценить взаимозависимость компонентов защищаемого приложения и изучить, что произойдет, если, например, окажутся недоступными СУБД или один из сервисов. Ваша цель — добиться того, чтобы атака не привела к одновременному отказу сразу всех компонентов приложения, с которыми взаимодействуют пользователи. Рекомендации по повышению доступности каждого сервиса можно найти на официальных сайтах проектов.

Кроме того, нужно позаботиться, чтобы у защищаемого сервиса было, как минимум, несколько точек входа. Тогда если, например, атака приведет к недоступности одного из IP­-адресов, то можно будет оперативно заменить его в таблице DNS на другой адрес. Или другой вариант: если некоторые из IP-адресов, которые предоставляются вашим клиентам, подвергнутся атаке, вы можете предоставить им другие адреса, предварительно убедившись, что доступ к ним хотят получить действительно ваши клиенты — для их аутентификации могут использоваться, например, токены.

Важно спроектировать и настроить сервис таким образом, чтобы неавторизованные пользователи не смогли узнать реальные IP-адреса, которые используются для доступа к сервису авторизованными пользователями.

И снова пример из практики: у одного нашего клиента в игровом сервисе была реализована своего рода «иерархия» пользователей: после того, как игрок достигает 20-го уровня, ему выдается новый IP-адрес. Такой вариант защиты позволяет избежать ситуации, когда атакующий регистрируется, получает доступ к игре и практически сразу начинает атаку на игровой сервер.

Определенное преимущество в защите от DDoS-атак имеют сервисы, работающие на основе протокола TCP, поскольку сам протокол лучше приспособлен для отражения атак. Гораздо больше усилий потребуется, чтобы обезопасить серверы, работающие на основе протокола UDP. Этот протокол не подразумевает соединений, и если сервер подвергается не типичной, а целевой атаке, имитирующей при этом игровые пакеты, трафик фильтроваться не будет — если только вы не сообщите заранее о деталях архитектуры и функционирования сервера вашему DDoS-защитнику, не продумаете вместе с ним способы отражения нетипичных атак и не проверите их эффективность на нескольких тестовых атаках.

Сети

Обеспечение устойчивости сети — пожалуй, самый сложный случай в плане обеспечения эффективной защиты от DDoS-атак. С одной стороны, это обусловлено тем, что зачастую приходится защищать не только свои интернет-ресурсы, но и те, что принадлежат вашим клиентам, разместившим свои ИТ-активы внутри вашей сети, — а среди них, заметим, могут быть какие угодно сервисы. С другой стороны, большое количество IP-адресов, которыми вы, скорее всего, располагаете, стимулирует злоумышленников воспользоваться ими, например, для организации хотя и относительно слабых атак, но производимых одновременно на множество адресов, — такое воздействие существенно замедлит работу всей инфраструктуры.

Первое, о чем следует позаботиться, — чтобы пограничный (Edge) маршрутизатор располагал достаточной производительностью, чтобы справиться с повышенной нагрузкой, которая может возникнуть после начала DDoS-атаки. И, конечно же, не следует устанавливать на границе сети дешевые маршрутизаторы, предназначенные для использования в условиях дома или небольшого офиса, а также старые маломощные маршрутизаторы — скорее всего, они станут первыми жертвами DDoS-атаки на сеть. Следует уточнить заявленную производителем пропускную способность, оценить текущую нагрузку и по возможности провести ряд стресс-тестов с использованием доступных в Интернете инструментов, таких как hping3 — он есть практически в любом дистрибутиве Linux.

Второе — нужно убедиться, что ваши IP-адреса нельзя определить путем трассировки (traceroute), а те, что можно, защищены средствами ACL. Дело в том, что злоумышленник может провести трассировку до DDoS-защитника и узнать стыковой IP-адрес, который, как правило, не защищен, и начать атаку на него. Поэтому нужно, с одной стороны, обезопасить адреса с помощью ACL (в этом вам поможет ваш защитник), и, с другой стороны, необходимо скрывать адреса от трассировки как извне, так и изнутри сети (это необходимо, чтобы адреса не смогли выявить инсайдеры).

hping3Пример утилиты, которая часто используется для осуществления примитивных атак, — hping3. С ее помощью вы можете провести стресс-тест своего сервера до того, как злоумышленники сделают это за вас.hping3 — богатая возможностями утилита, которая может имитировать множество типов атак с различными параметрами. Вот пример того, как проверить свой сервер на уязвимость к небольшой SYN-атаке:# hping3 -S <–fast|–faster|–flood> -p 80 xx.xx.xx.xx80 (HTTP) в это примере — это порт назначения. Обратите внимание на другие параметры (hping3 –help), чтобы понять, как атаки могут отличаться друг от друга.Рекомендую изучить документацию к утилите, доступную по команде man hping3 и самостоятельно попробовать генерировать пакеты различных протоколов, чтобы посмотреть, как это скажется на нагрузке. Так как утилита умеет использовать только одно ядро процессора, на одном компьютере можно запустить несколько экземпляров hping3, чтобы повысить мощность тестовой атаки.Пользуйтесь этой утилитой аккуратно и только в целях тестирования собственных ресурсов! К сожалению, большая часть Интернета уязвима к таким простым операциям, даже если атакующий использует канал значительно меньший, чем атакуемый.

Общие рекомендации

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

Кроме того, надо продумать, каким образом вы будете подключать DDoS-защиту и сколько времени на это потребуется. В частности, нужно проверить сроки наступления тайм-аута (TTL) для записей DNS: если, например, тайм-аут составляет двое суток, то во время переключения на новую DNS­-запись ваш сайт не будет доступен в течение двух суток. И, конечно, защищая критически важные ресурсы, необходимо позаботиться о DDoS-защите заранее.

Для динамического обнаружения атак и автоматического включения защиты настоятельно рекомендуем использовать сенсор — эта мера обеспечит более широкие возможности управления трафиком, позволяет сэкономить на подключении DDoS­-защиты, уменьшить задержку в режиме работы без атаки и — главное — существенно повысить скорость реакции на начало атаки благодаря автоматическому срабатыванию сенсора вместо включения защиты вручную. Поэтому перед тем, как заключить договор с поставщиком услуг anti-DDoS, полезно уточнить, предоставляет ли он DDoS-сенсор.