За последние пять лет российский рынок дата-центров демонстрирует устойчивый рост. Эксперты прогнозируют дальнейшее удвоение мощностей к 2030 году. Это напрямую усиливает привлекательность ЦОД для злоумышленников. Ведь чем больше сервисов размещается в ЦОД, тем выше потенциальный ущерб от их недоступности. И, действительно, в 2025 году количество DDoS-атак (Distributed Denial of Service) в России выросло более чем в два раза по сравнению 2024 годом. Особенно страдает телекоммуникационная отрасль: с июля 2024 года наблюдается резкий всплеск атак именно на операторов связи. Это также подтверждает наша собственная статистика.
Чтобы обеспечить стабильн��ю работу серверов и приложений во время мощных распределенных атак, необходимо решение Anti-DDoS. Полагаться только на защиту, которую предоставляет сторонний сервис – чревато рисками. Максимум, чем ответит подрядчик за недоступность сервиса во время атаки – лишь стоимость самой услуги. Кроме этого, кто лучше самого владельца сервиса знает обо всех его нюансах работы? – никто, а именно это определяет качество работы различных контрмер и механизмов обнаружения DDoS-атак. Взвешенный подход: оставить на провайдере задачу «защиты трубы» (интернет-каналов к защищаемым ресурсам) от объемных атак, а второй эшелон защиты делать на комплексе, устанавливаемом локально. Это реальный, а не иллюзорный контроль, возможность делать тонкие настройки для разных типов защищаемых ресурсов, получать аналитику и статусы в режиме реального времени, быстро реагируя на изменения.
В статье мы разберем три распространенные схемы интеграции локального комплекса в инфраструктуру ЦОД, уделив особое внимание архитектурным требованиям ЦОД. Экспертизой в этих вопросах сегодня будут делиться Вадим Солдатенков, руководитель направления продуктов «Гарда Anti-DDoS» компании «Гарда», и Дмитрий Ковалев, технический директор по информационной безопасности интегратора «Инлайн Телеком Солюшнс».
Архитектура и требования к ЦОД
Неправильно было бы говорить про схемы интеграции защитных комплексов, не коснувшись вопроса архитектуры ЦОД. Именно на этапе проектирования можно минимизировать ограничения, которые могут осложнить дальнейшую интеграцию защитных комплексов. Например, если при проектировании не учтена возможность перевода потоков трафика защищаемых ресурсов для анализа и фильтрации на специализированные системы, в будущем, при внедрении таких систем как Anti-DDoS может потребоваться модернизация и обновление самой сети. А это уже совсем другие бюджеты и сроки.
Современная сетевая инфраструктура ЦОД должна обеспечивать высокую:
надежность и отказоустойчивость;
производительность;
масштабируемость;
безопасность;
управляемость.
Сетевая инфраструктура ЦОД может включать в себя как IP-сеть, так и сеть хранения данных, а также системы безопасности и управления сетью. Важными аспектами являются обеспечение надежной работы систем виртуализации, поддержка различных типов нагрузок (включая контейнерные приложения), а также интеграция с внешними сетями и сервисами.
Центры обработки данных на текущий момент – это высоконагруженные, критически важные узлы цифровой инфраструктуры с множеством работающих сервисов и приложений, и поэтому к ним предъявляются повышенные требования. Сетевая инфраструктура большинства современных ЦОД базируется на spine–leaf архитектуре (см. схему ниже).
Далее разберем эту архитектуру более подробно.
Пограничные маршрутизаторы (DC Gateway) выступают границей между ЦОД (его внутренней инфраструктурой) и внешними сетями, а также могут обеспечивать underlay-соединение для связности между несколькими ЦОД (Data Center Interconnect – DCI).
Коммутаторы уровня «Spine-Leaf» являются модулем IP-фабрики, построенной на базе топологии неблокируемой сети CLOS («сложенной сетью Клоза»).
Архитектура состоит из двух уровней:
spine, состоящий из высокопроизводительных коммутаторов, которые соединяют между собой все leaf-коммутаторы. Как правило, к данным коммутаторам не подключаются конечные устройства и сервисы. Непосредственно к spine-коммутаторам допускается подключение граничных маршрутизаторов, например, в случае терминации на них VXLAN-туннелей (VTEP) при использовании протоколов EVPN-VXLAN для построения логической топологии сети (overlay).
leaf, состоящий из коммутаторов доступа, к которым подключаются конечные устройства: серверное оборудование, системы хранения данных, системы виртуализации и др. Каждый leaf-коммутатор имеет подключение ко всем spine-коммутаторам.
Также отдельно можно выделить коммутаторы border-leaf – это все те же leaf-коммутаторы, но к которым подключается внешние по отношению к внутренней сети ЦОД устройства и сервисы. Например, граничный маршрути��атор, межсетевые экраны, включая устройства фильтрации трафика систем защиты от DDoS-атак.
В отличие от классических моделей построения сетей, spine-leaf архитектура дает ряд ключевых преимуществ:
отказоустойчивость, которая обеспечивается за счет полного резервирования связей между уровнями;
высокая масштабируемость: при планировании расширения можно легко добавить leaf-коммутатор, а при необходимости и spine;
обслуживание инфраструктуры «без простоев», когда все коммутаторы полностью независимы: временное отключение одного узла не повлияет на работу всей инфраструктуры;
предсказуемая задержка (latency) для всех потоков, так как любой внутренний трафик проходит ровно через один spine-коммутатор.
За счет эффективной работы с большими потоками горизонтального трафика spine-leaf архитектура практически идеально подходит для использования при работе систем виртуализации, облачных инфраструктур, систем хранения данных, а также других инфраструктур и сервисов, внутренние компоненты которых активно обмениваются данными между собой.
Схемы интеграции локального комплекса Anti-DDoS
Существует несколько логических схем интеграции локального комплекса Anti-DDoS в сетевую инфраструктуру:
«в разрыв» uplink-каналов;
«out-of-path» или «сбоку» (в большинстве случаев с использованием схемы с BGP-ответвлением);
гибридная схема с использованием вышеуказанных способов.
На практике в ЦОД чаще всего комплекс Anti-DDoS ставят в разрыв uplink-каналов. Устройство работает в прозрачном режиме. В рамках этой защиты система видит входящий и исходящий трафик и может обнаруживать в нем аномалии.
При такой схеме включения оборудование комплекса Anti-DDoS должно быть оснащено сетевыми картами с аппаратным байпасом, чтобы в случае отказа устройства или выполнения на нем плановых работ трафик продолжал пропускаться без обработки. В решении «Гарда Anti-DDoS» дополнительно предусмотрена облачная сигнализация – это не имеющая аналогов в России функциональность, улучшающая управление защитой при отражении объемных атак. Более подробно про это писали в этой статье.
Следующая схема – BGP-ответвление. Именно ее чаще всего используют операторы связи и крупные компании. Дело в том, что вариант с включением «в разрыв» применим до определенного размера сетевой инфраструктуры.
Если защита стоит в разрыв uplink-каналов, необходимо постоянно защищать все эти каналы, а когда их много, это может быть достаточно дорого. BGP-ответвление позволяет использовать емкости для фильтрации более целевым образом. Например, каналы по совокупной пропускной способности могут быть на 1 Тбит/c, при этом большая часть мусорного трафика останавливается на уровне пограничных маршрутизаторов с помощью BGP Flowspec. Специализированная фильтрация на локальном комплексе потребуется только для более сложных атак, которые смогли пройти дальше в сеть. В этом случае потребуется закрывать существенно меньшую емкость, например, в 200 Гбит/с, вместо 1 Тбит/с.
Как работает решение в схеме BGP-ответвления
Модуль «Анализатор» собирает метаданные в виде NetFlow (или другого протокола семейства потоковой аналитики). Это позволяет видеть весь проходящий через сеть трафик, контролировать его, выделять аномалии и при их обнаружении перенаправлять трафик на фильтрацию в модули «Очиститель». Анализ «флоу» помогает не только обнаружить аномалии, но и закрыть задачи трафик-инжиниринга. В частности, распределения трафика, понимания, откуда и как он поступает, и что где нагружено.
«Анализатор» не хранит проходящее «флоу». Для этого есть специализированный модуль «Хранилище», который дает возможность проводить ретроспективный анализ. Вы можете смотреть, какие атаки были, какие аномалии происходили. Собирать метаданные/«флоу» с точки зрения объема гораздо выгоднее, чем делать дампы трафика, поскольку в этом случае хранятся не полные пакеты, а только заголовки с обогащенной информацией.
Все модули решения – это, прежде всего, логические сущности, которые, в зависимости от целевой схемы и нагрузки, могут быть реализованы как на одном, так и на разных физических серверах.
В заключение важно еще упомянуть про одно принципиальное различие между методами защиты, используемыми в описанных выше схемах. В частности, при установке решения «в разрыв» оно видит обе половинки трафика: входящий к ресурсам и исходящий от ресурсов. Это позволяет применять больше методов противодействия, например, TCP-проксирование или анализ ответов защищаемого сервера (для защиты DNS-серверов). В схеме BGP-ответвления трафик асимметричный. Мы видим только одну его половинку, поэтому доступно меньше методов, и основной упор делается на защиту на уровнях L3-L4. А для расширенного противодействия атакам на уровне L7 требуется комплексное решение Anti-DDoS с встроенным L7-экраном или отдельным WAF.
Логичное продолжение схемы BGP-ответвления – использование комбинированной схемы. Она сочетает в себе два подхода: BGP-ответвление для большей части сервисов и защиту «в разрыв» для особо важных, критичных ресурсов. Если у нас большой модульный ЦОД, и при этом есть очень важный критичный ресурс, которому нужен постоянный анализ трафика и защита, мы можем поставить на его uplink-каналы устройство «в разрыв», где будет непрерывный анализ. Такой подход особенно ценен, когда нужно минимизировать или вообще исключить время переключения с детекции на фильтрацию. Постоянно работающие методы фильтрации могут сильнее нагружать систему, однако позволяют мгновенно реагировать и быстрее отражать атаки.
Выводы
Все описанные схемы интеграции универсальны и хорошо работают не только в телеком-отрасли, но и в финансовых организациях, промышленных предприятиях, государственных структурах и любых других сферах, где требуется защита сетевой инфраструктуры от DDoS-атак. Различия будут лишь в масштабах и специфике защищаемых сервисов, но архитектурные подходы остаются неизменными.
При этом важно понимать, что Anti-DDoS – это не панацея для защиты ЦОД. Решение выступает как первый необходимый рубеж в рамках комплексного подхода к кибербезопасности. Для обеспечения устойчивости инфраструктуры требуется эшелонированная защита. В частности, помимо периметральной фильтрации, необходимо предусмотреть:
межсетевые экраны для сегментации сети и защиты расположенных за ними ресурсов от горизонтального перемещения злоумышленников;
специализированные средства в зависимости от типа сервисов. Например, L7-экран и WAF;
SOC (внутренний или внешний).
Не менее критична защита самой сетевой инфраструктуры. Рекомендуем выделять management plane в отдельный сегмент с контролем доступа. Необходимо также настраивать механизмы защиты control plane на маршрутизаторах и коммутаторах, чтобы ограничивать поток управляющего трафика к центральному процессору устройства и предотвращать его перегрузку во время атак.
Фундаментом для выбора и расстановки приоритетов в средствах защиты должна стать модель угроз. Анализ актуальных угроз, оценка потенциального ущерба и критичности сервисов позволяют сформировать сбалансированную стратегию безопасности. Такой подход обеспечивает не только устойчивость к внешним атакам, но и сохранение работоспособности инфраструктуры в условиях развития угроз.
