Лучшие практики противодействия DDoS-атакам

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

Модель угроз

В составлении модели угроз существуют два основных подхода. Первый – формирование списка актуальных на сегодняшний день атак.

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

Второй подход заключается в том, что заказчику гарантируется доступность его приложения извне с определенным SLA (соглашением об уровне предоставления услуг) вне зависимости от того, какие атаки могут случиться. В этом случае DDoS-атаки классифицируются, исходя из сетевой модели OSI: они могут производиться на канал, конечный автомат TCP или приложение. То есть атакующая сторона может или "забивать" каналы дата-центра/сервера/провайдера, или исчерпывать ресурсы операционной системы, например, открывая большое число соединений, или эксплуатировать слабые места Web-приложения.

Маршрутизация

Отдельно стоит отметить проблемы маршрутизации (протокол BGP, отвечающий за глобальную доступность сетей в Интернете). При помощи атак route leak злоумышленник может попытаться незаметно увести трафик на себя с целью его прослушивания. Безусловно, прослушивание не приводит к отказу в обслуживании, но во время DDoS-атаки, когда информационные ресурсы жертвы недоступны, атакующая сторона может создать поддельный ресурс взамен атакованного, что гораздо опаснее, чем просто просмотр чужого трафика. Во II квартале 2014 г. зарегистрировано 4153 подобных инцидента с маршрутизацией, из них 608 – с влиянием на внутрироссийский трафик.

Доступность

Популярность DDoS-атак объясняется низкой ценой: вывести из строя сайт конкурента дешевле, чем продвигать свой, а если атака реализована в период рекламной кампании у "жертвы", то к стоимости простоя онлайновой части бизнеса можно прибавить маркетинговый бюджет. Для осуществления "заливки" канала паразитным трафиком атакующей стороне потребуется один или два сервера в хостинге, который не реагирует или очень медленно реагирует на жалобы и старается не сотрудничать с правоохранительными органами (bulletproof hosting service), – это $50–70 в месяц за сервер с гигабитным подключением и список амплификаторов*, который можно купить на черном рынке или собрать самому за 2–3 часа.

В таблицах 1 и 2 приводится актуальная статистика по числу уязвимых серверов, которые могут выступать в качестве амплификаторов, в разбивке по типам. Сегодня амплификаторов так много, что технически нет проблемы организовать атаку на канал в несколько сотен гигабит.

Атаки на TCP несколько сложнее и дороже, так как для них необходимо арендовать ботнет. Атака же на само приложение всегда таргетирована: атакующая сторона выбирает ту часть, которая нагружает сервер больше всего, например поиск по сайту, и генерирует для этого функционала большое количество запросов при помощи ботов. На сегодняшний день была зарегистрирована самая большая атака с участием более 450 000 ботов, которые работали как полнофункциональный браузер и пытались имитировать поведение на сайте живого человека.

Решение проблемы. Лучшие практики

Защищаться от DDoS-атак можно по-разному. Первый способ, к которому обычно прибегают вначале, – это организация самостоятельной защиты, но подобный вид мер безопасности способен нейтрализовать лишь самые простые атаки: установка front-end Nginx, запрет протоколов ICMP и UDP могут значительно облегчить жизнь сервису, но только до определенного уровня.

Также защиту может предоставлять хостинг-провайдер или оператор связи, но их возможности ограничены доступным для них каналом, и ни один, ни другой не будут разбирать высокоуровневые протоколы HTTP/HTTPS.

Лучшей практикой будет использование облачного решения. Однако облако, которое действительно защищает от DDoS-атак, должно обладать следующими свойствами:

• Распределенность. В облаке должно быть несколько географически разнесенных узлов, чтобы вывод из строя любого из них не оказывал влияния на сервис.
• Собственная автономная система и собственные адресные блоки, из которых для защищаемого сервиса выделяется новый IP-адрес, скрывающий истинное его расположение в сети.
• Глобальная связность автономной системы с Интернетом. Только магистральные операторы в качестве провайдеров облачных сервисов дадут уверенность клиентам, находящимся под защитой облачного решения, в том, что их трафик не будет теряться вне зависимости от того, какие атаки осуществляются.
• Полная автоматизация процесса фильтрации. У хорошей системы защиты от DDoS-атак – тысячи клиентов и сотни инцидентов в день. Этот объем невозможно обработать вручную. Ручное вмешательство порождает ошибки, так как человек должен оперативно решать, какие фильтры подключать и пр., что не всегда приводит к нужному результату.
• Постоянная фильтрация должна быть приоритетной услугой, поскольку любое переключение по протоколу BGP или DNS означает время простоя сайта, измеряемое десятками минут, и раскрытие истинного местоположения сервера.
• Использование технологии MPLS (multiprotocol label switching) VPN в качестве резервной связности системы защиты и сервера. Это позволит даже при полностью забитых "мусором" каналах дата-центра сохранить полную работоспособность сервера. l SLA обязан включать в себя также и время атаки.

Приведем пример

Если фильтрация осуществляется в ручном режиме переводом DNS с TTL 5 минут (TTL – время жизни пакета данных в протоколе IP – предельно допустимое время его пребывания в системе), то сценарий может быть таким:

1. Начинается атака.
2. Дежурный по регламенту регистрирует ее факт (+5 минут).
3. Дежурный по регламенту звонит администратору сайта и обсуждает с ним, какие фильтры будут включены, чтобы, с одной стороны, защититься, с другой – чтобы не заблокировать легитимных пользователей. Без этого пункта нейтрализацию атаки можно было бы автоматизировать (+10–15 минут).
4. Перевод трафика, что составляет не менее TTL*2 (+10 минут).
5. Мониторинг и коррекция работы фильтров (+10–15 минут).

Итого, если все участники сработали штатно и по регламенту, реагировали достаточно быстро, то сервер заработает через 45 минут после начала атаки. Некоторые атакующие пользуются этим сценарием: они то снимают атаку, то возобновляют ее, получая недоступность защищаемого ресурса.

Сам сервер должен обладать рядом качеств, которые позволят ему быть всегда доступным для клиента:

• Возможность выдерживать рост легитимной нагрузки, чтобы не "падать" во время рекламных кампаний и быстро восстанавливаться, когда фильтры включились. Также важно понимать, что некоторое количество ботов (обычно 1–2%) может быть пропущено, и сервер должен быть способен это выдерживать.

"Один сервер – один сервис". Web-сервер должен быть на своем сервере единственным приложением. Иначе атакующая сторона узнает его IP, например из записи MX (Mail Exchanger – один из типов записей в DNS, указывающий способ маршрутизации электронной почты), или Web-сервер может быть выведен из строя исчерпанием ресурсов процессора за счет другого сервиса.

• Устойчивый распределенный DNS.

Какой бы метод защиты от DDoS ни выбрала компания, главное – помнить, что к атакам нужно быть готовым заранее. Кроме того, построенная IТ-инфраструктура должна полностью соответствовать объемам бизнеса компании. Это поможет минимизировать ущерб и не потерять лояльность клиентов даже в самый активный бизнес-сезон.