Как избежать ошибок в организации DDoS-защиты

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

Когда атакующий знает вашу инфраструктуру лучше вас

Злоумышленники могут попытаться провести атаку на внутреннюю часть (бэкенд) вашего веб-сервиса в обход защиты. В этом им поможет знание об IP-адресах этого сервиса и связанных с ними доменах. 

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

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

Если у вас имеется собственная автономная система со своим префиксом или вы используете динамическую маршрутизацию на основе протокола BGP, то надо защищать не только ваши ресурсы, но и саму сеть. Атака может обрушиться напрямую на незащищённый IP-адрес. Если она окажется достаточно мощной, то ваша сеть «ляжет», даже если вы используете межсетевой экран (firewall) или ACL (листы контроля доступа), пытаясь «закрыть» этот адрес от ненужного трафика. Если вы используете BGP, то также необходима защита через BGP.

Конечно, надо также предусмотреть возможность атак на DNS. Нужно обязательно оценить, надёжно ли работают сервисы DNS, к которым вы подключены, и проанализировать, насколько они защищены. Например, однажды под атакой оказался регистратор доменных имен Nic.ru. Когда он стал работать нестабильно, многие клиенты сильно пожалели о том, что не предусмотрели резервное подключение к другому сервису DNS, защищённому от DDoS-атак. Такие возможности предоставляют сегодня не только провайдеры anti-DDoS, но и многие компании, предоставляющие сервисы DNS. Мы рекомендуем подключаться как минимум к двум поставщикам DNS. И будет замечательно, если все эти провайдеры обеспечат DDoS-защиту ваших DNS-серверов.

Подробнее: Как защитить сеть от атак и DDoS-угроз >>

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

Примеры ошибок в организации DDoS-защиты

Разберём некоторые из ошибок, которые мы заметили в процессе подключения DDoS-защиты у одного крупного клиента с несколькими сотнями сайтов.

Ошибка №1: защита от DDoS-атак охватывает лишь часть ресурсов

Клиент подключил к нашим облачным сервисам DDoS-защиты лишь часть своих ресурсов.  При этом около сотни сайтов так и остались уязвимыми. Точнее, к ним была подключена защита только на уровнях L3/L4 по модели OSI, в то время как уровень HTTP-приложений (L7) на тот момент оставался незащищённым. По всей видимости, клиент полагал, что никто и никогда эти сайты не найдёт и интересоваться ими не будет. Возможно, так бы оно и было, если бы дело касалось обычных пользователей. Однако речь идёт о злоумышленниках. Они не поленились, нашли эти сайты и обрушили на них DDoS-атаку на уровне приложений. 

Этот пример в очередной раз доказывает: «кусочно-лоскутная» защита от DDoS-атак на практике оказывается «дырявой», а потому неэффективной. Чтобы надёжно обезопасить интернет-ресурсы от DDoS-рисков, необходимо обеспечить их всесторонний охват и реализовать комплекс взаимосвязанных мер, нацеленных на снижение этих рисков .

Из-за того, что атака злоумышленников была очень интенсивной, сервисы anti-DDoS быстро выявили основные источники нелегитимного трафика и подавили основную часть атаки на пакетном уровне. Однако объёма остаточного трафика оказалось достаточно, чтобы сделать недоступными сайты клиента, незащищённые на уровне L7.

Чтобы полностью решить проблему, потребовалось подключение сервисов фильтрации на уровне приложений. Обеспечить её удалось относительно быстро: получив от клиента полный список не полностью защищённых сайтов, мы поставили их под защиту наших сервисов anti-DDoS на уровне L7.

Как защититься от DDoS-атак на уровне L7 >>

Ошибка №2: сеть клиента также анонсировалась у других интернет-провайдеров

Наш клиент решил «подстраховаться». Он анонсировал свою сеть не только через StormWall, но также через двух интернет-провайдеров, рассматривая их каналы как резервные. Чтобы направить трафик в первую очередь через сеть StormWall, он попытался «ухудшить» его путь через двух других провайдеров, использовав для этого анонсирование с помощью механизма BGP Prepend.

Однако этот прием не сработал: из-за того, что анонсы с параметрами BGP Prepend фильтруют многие провайдеры, трафик пошёл не только через StormWall, но и через других провайдеров. И когда DDoS-атака началась, три четверти нелегитимного трафика стали направляться на интернет-ресурсы клиента, минуя защиту StormWall.

Чтобы обеспечить эксклюзивный анонс сети (другими словами, чтобы трафик шёл только через фильтры StormWall), потребовалось более часа, при этом атака продолжалась.

Отметим, что обеспечить защиту интернет-приложений и сайтов, работающих по протоколу HTTPS (а таких сейчас подавляющее большинство), можно тремя способами:

• с раскрытием приватного ключа SSL,
• с получением сертификата и приватного ключа Let’s Encrypt у провайдера сервисов anti-DDoS,
• без расшифровки SSL путём отправки провайдеру anti-DDoS содержимого системных журналов (логов) серверов приложений.

Так или иначе, провайдеру anti-DDoS необходимо получить данные о том, как происходит обмен данными на уровне L7. Без этого не выстроить надёжной защиты сайтов и интернет-приложений.

В нашем конкретном случае мы применили защиту с раскрытием приватного ключа SSL, потому что ресурсы носили информационных характер и не было жёстких требований по защите передаваемых данных.

Ошибка №3: на маршрутизаторах для подключения через GRE-туннель работал механизм ACL

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

Наши специалисты определили, что потеря сетевых пакетов происходила именно в GRE-туннеле. При этом пропускная способность канала была вполне достаточной, да и объём трафика в GRE-туннеле, не был слишком большим. 

В ходе дальнейшего анализа выяснилось, что на маршрутизаторах клиента, обеспечивающих подключение через GRE-туннели, работал механизм списков контроля доступа (ACL). Он был применён к туннельным интерфейсам. В итоге пакеты обрабатывались программно, а не аппаратно, что существенно снижало производительность маршрутизаторов. 

Специалисты клиента, следуя нашим рекомендациям, отключили механизм ACL на маршрутизаторах, которые были подключены к GRE-туннелям. После этого потери пакетов прекратились.

Каскад ошибок усиливает снижение устойчивости к DDoS-рискам

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

Применительно к нашему кейсу можно сделать минимум три главных вывода-рекомендации:

• Чтобы защита от DDoS-атак была эффективной, она должна быть комплексной и всесторонней — охватывать все интернет-ресурсы и все уровни, которые могут быть использованы для DDoS-атак на эти ресурсы.
• Чтобы минимизировать объём нелегитимного трафика во время DDoS-атак, необходимо направлять весь трафик через фильтры провайдера anti-DDoS.
• Чтобы обеспечить высокую устойчивость интернет-ресурсов к DDoS-атакам, нужно оптимизировать работу маршрутизаторов. Важно добиться их максимальной производительности. В частности, надо убедиться, что в GRE-туннеле не работает механизм ACL.