17 ноября 2022
Ошибки в организации защиты от рисков, связанных с DDoS-атаками, практически всегда приводят к снижению устойчивости их интернет-ресурсов к этим рискам, причем компенсировать их одним только подключением сервисов Anti-DDoS, даже самых передовых, невозможно. Ситуация нередко усугубляется за счет того, что сочетание нескольких ошибок усиливает их общий негативный эффект.
Разберем некоторые из таких ошибок, которые мы встретили в ходе выстраивания защиты от DDoS-рисков у одного достаточно крупного клиента, управляющего несколькими сотнями сайтов.
Ошибка №1: защита от DDoS-атак охватывает лишь часть интернет-ресурсов
Клиент подключил к нашим облачным сервисам DDoS-защиты лишь часть своих ресурсов, при этом около сотни сайтов так и остались незащищенными. Точнее, к ним была подключена защита только на уровнях L3/L4 по модели OSI, в то время как уровень HTTP-приложений (L7) на тот момент оставался незащищенным. По всей видимости, клиент полагал, что никто и никогда эти сайты не найдет и интересоваться ими не будет. Возможно, так бы оно и было, если бы дело касалось обычных пользователей. Однако злоумышленники не поленились, нашли эти сайты и обрушили на них DDoS-атаку на уровне приложений.
Этот пример в очередной раз доказывает: «кусочно-лоскутная» защита от DDoS-атак на практике оказывается «дырявой», а потому неэффективной. Чтобы надежно обезопасить интернет-ресурсы от DDoS-рисков, необходимо обеспечить их всесторонний охват и реализовать целый комплекс взаимосвязанных мер, нацеленных на снижение этих рисков (подробности нашего подхода мы изложили в этой статье).
И-за того, что атака злоумышленников была очень интенсивной, сервисы Anti-DDoS быстро выявили основные источники нелегитимного трафика и подавили основную часть атаки на пакетном уровне. Однако объема остаточного трафика оказалось достаточно, чтобы сделать недоступными незащищенные на уровне L7 сайты клиента.
Чтобы полностью решить проблему, потребовалось подключение сервисов фильтрации на уровне приложений. Обеспечить ее удалось относительно быстро: получив от клиента полный список не полностью защищенных сайтов, мы поставили их под защиту наших сервисов Anti-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-атак, необходимо направлять весь трафик через фильтры провайдера Anti-DDoS.
- Чтобы обеспечить высокую устойчивость интернет-ресурсов к DDoS-атакам, нужно оптимизировать работу маршрутизаторов так, чтобы добиться их максимальной производительности. В частности, надо убедиться, что в GRE-туннеле не работает механизм ACL.
Карта российского банка
Система быстрых платежей
Банковский перевод
