На заре создания сетевых устройств к ним предъявляли только одно требование: чтобы пакеты данных летели. Сетевые коммутаторы и маршрутизаторы должны были просто и быстро доставлять трафик по назначению, строго следуя логике уровней L1–L4 модели OSI ISO. Чем меньше устройство думало, тем лучше: выше предсказуемость, меньше задержки, проще эксплуатация. Но, как только индустрия выстроилась вокруг витой пары, исчезли разнообразные технологии построения сетей, а вендоры научились делать надежные и быстрые каналы передачи трафика, довольно однообразные и с идентичной функциональностью, – возник закономерный вопрос: за счет чего обгонять конкурентов?
Автор: Игорь Гиркин, архитектор систем информационной безопасности компании "Гарда"
Почему добавлять новые функции в коммутатор затратно?
Обычно, если базовая функциональность одинакова, то выигрывает тот, кто предложит больший потенциал роста без потери скорости. Однако добавить новые возможности в коммутатор, особенно в ядро обработки трафика, намного сложнее и дороже, чем кажется. Например, коммутаторы используют специализированные микросхемы ASIC для обработки пакетов данных, позволяющие без снижения скорости передачи информации производить необходимые манипуляции с трафиком. Но за производительность приходится платить гибкостью: чтобы добавить дополнительные функции в плоскость обработки трафика, часто, недостаточно обновить прошивку – нужно менять микросхему. А это означает длинный и дорогой цикл, включающий в себя проектирование микросхемы, изготовление опытных образов, многоэтапное тестирование, исправление возможных ошибок, повторные тесты и только после этого – изготовление промышленной партии. Ошибки стоят дорого, сроки измеряются годами, риски существенные – нет гарантии, что покупатель захочет платить за новую функцию. Поэтому первопроходцами обычно становятся компании, у которых есть несколько следующих составляющих: значительная доля рынка, дающая преимущество во времени на изобретение нового устройства; мощное подразделение продаж, способное упаковать новинку так, чтобы люди готовы были заплатить за нее больше денег; свободные финансы, потому что разработка ASIC – затратное дело.
Исторически одним из таких пионеров была компания Cisco. Именно на примере ее устройств многие впервые увидели, что обычный коммутатор может быть еще и активным элементом защиты.
Как безопасность пришла в коммутаторы?
Пожалуй, самый уязвимый участок корпоративной сети – уровень доступа. Там, где к портам подключаются пользовательские устройства, появляются типовые атаки: подмена адресов, попытки перехвата трафика, нелегитимные DCHP-серверы и т. д. Если раньше это считалось проблемой не коммутатора, а безопасности, то со временем стало понятно, что многие атаки проще и правильнее останавливать в точке входа – прямо на порту.
Так появились механизмы, которые сегодня воспринимаются как норма:
- Port Security, ограничивая изучение MAC-адресов на порту, резко усложнил попытки превратить коммутатор в подобие хаба для перехвата трафика;
- DHCP Snooping закрыл проблему появления нелегитимного DHCP, который раздает пользователям неправильный шлюз или DNS, после чего трафик аккуратно уходит в нужные руки;
- Dynamic ARP Inspection и IP Source Guard стали ответом на ARP-spoofing и подмену адресов – типовой способ устроить MITM внутри VLAN.
Параллельно в индустрии закрепился 802.1X. Идея "воткнулся в порт – получи сеть" перестала быть приемлемой для зрелых инфраструктур. 802.1X стал фундаментом подходов, которые позже оформились в Zero Trust: сеть начинает требовать аутентификацию, различать типы устройств, выдавать разные уровни доступа, постоянно мониторить состояние подключенного устройства. В том же направлении работает и Private VLAN, который ограничивает латеральный трафик внутри одного широковещательного домена: даже если устройства формально в одной сети, им не обязательно разговаривать друг с другом напрямую.
Отдельная история – устойчивость топологий. В сложных разветвленных схемах, где много L2-участков, атаки на spanning tree могут привести не просто к локальным проблемам, а к весьма заметным инцидентам. Поэтому появились защитные механизмы вроде BPDU Guard, BPDU Filter, Root Guard и др., которые страхуют сеть от случайного или злонамеренного влияния на дерево SPF.
Наконец, производители занялись защитой самого сетевого устройства. Control Plane Policy ограничивает трафик, попадающий на центральный процессор коммутатора, помогая защищаться от DoS-воздействия на плоскость управления. Важный нюанс: даже если плоскость обработки трафика работает в ASIC на скоростях линий, перегрузить ЦПУ шумным трафиком или специфическими пакетами иногда проще, чем кажется.
Маршрутизаторы: безопасность как расширение роли устройства
Обновление функциональности в маршрутизаторах происходит значительно легче, чем в коммутаторах. Раньше многие функции реализовывались на ЦПУ общего назначения, а требования к пропускной способности были значительно ниже, поэтому именно маршрутизаторы первыми начали примерять на себя роли, принадлежавшие ранее отдельным ИБ-устройствам (межсетевым экранам, системам обнаружения и предотвращения вторжений, VPN-концентраторам, анти-DoS/DDoS решениям).
Но и здесь индустрия снова оказалась в знакомой точке компромисса: скорости – росли, требования к пропускной способности – менялись. Появились специализированные сетевые процессоры, способные на скорости в десятки и сотни Гбит/с (а порой и Тбит/с) выполнять многие задачи по обработке пакетов данных, включая функции информационной безопасности.
Почему встроенная безопасность стала нормой, и почему она решает не все?
Массированное продвижение встроенных механизмов со стороны лидеров рынка сделало свое дело – индустрия привыкла, как производители, так и потребители. Сегодня все мировые производители сетевых устройств и микросхем ASIC предлагают в своих продуктах похожий базовый набор защитных технологий, список которых значительно расширился благодаря наличию механизмов Zero Trust Networking, микросегментации, карантинных VLAN, динамических ACL и т. д. Фактически, встроенные функции ИБ в сетевых устройствах стали обязательными. Но достаточно ли этих функций ИБ в сетевых устройствах, чтобы на 100% защитить инфраструктуру? Конечно же – нет! И на это существует две причины.
- Экономика и технологические ограничения ASIC. Сюда входят и долгий срок проектирования, и высокая стоимость конечного решения, и риск потери производительности с ростом задержек в обработке информации, и чисто физические ограничения на реализацию алгоритмов в кремнии.
- Управленческая и эксплуатационная реальность корпоративных сетей. Индустрия предлагает множество решений "всё в одном". Такие продукты хороши для домашнего использования или применения в небольших компаниях, но в крупных организациях требования к доступности и отказоустойчивости оборудования гораздо серьезнее. Кроме того, инфраструктура управляется различными командами, отвечающими за разные аспекты: уровень подключения пользователей, ЦОД, периметр, ИБ, мониторинг, реагирование и т. п. Когда все задачи сразу пытаются закрыть одним продуктом, то это почти всегда приводит к конфликтам ответственности, трудностям адаптации и двусмысленным компромиссам.
Сеть как сенсор
Как только стало понятно, что встроенная безопасность важна, но не всесильна, внимание сместилось к наблюдаемости. Коммутаторы и маршрутизаторы стоят в тех точках, где видно практически все: кто с кем общается, какие протоколы используются, куда идут потоки, где начинаются аномалии. Поэтому производители добавили возможности отправки телеметрии: NetFlow и его аналоги (IPFIX, sFlow, jFlow, NetStream, NSEL и др.), классический SNMP для статусов и счетчиков. Кроме телеметрии, устройства используют зеркалирование трафика – SPAN/RSPAN/ERSPAN, позволяющее снять копию и отправить внешней системе анализа. В итоге сетевое устройство становится идеальным источником, превращая всю сетевую инфраструктуру в распределенный сетевой сенсор для целей ИБ и мониторинга.
Симбиоз с NDR и NPM
В данный момент ключевым трендом является интеграция сетевого оборудования с платформами класса NDR (Network Detection and Response) и NPM (Network Performance Monitoring). Сеть перестает быть изолированным железом, которое просто пересылает пакеты данных, и становится активным участником интеллектуальной системы.
Коммутаторы и маршрутизаторы, используя технологии NetFlow/IPFIX, передачу копии трафика (SPAN/ERSPAN), становятся главными источниками сырых данных для NDR-платформ.
NDR применяет к этим данным машинное обучение, поведенческий анализ, а также иную интеллектуальную аналитику, и находит то, что традиционные сигнатурные подходы пропускают – сложные, замаскированные атаки, например, горизонтальное перемещение, утечку данных.
Обнаружив угрозу, NDR-система может через API (RESTCONF, NETCONF) тут же отдать команду сетевому устройству на изоляцию хоста (через ACL, изменение VLAN), заблокировать подозрительный IP-адрес или перенаправить трафик на песочницу для дополнительной проверки.
Параллельно те же данные начинают использовать еще и для мониторинга производительности (NPM). Один и тот же поток метаданных позволяет увидеть, где перегружены интерфейсы и каналы, каков путь прохождения пакетов данных, есть ли задержки в их обработке, какие приложения и пользователи больше всего нагружают каналы связи, в какой точке инфраструктуры возникает узкое место. NPM помогает быстрее находить причины деградаций, снижать время простоя и, что критично для бизнеса, грамотнее планировать модернизацию.
Таким образом, безопасность и производительность перестают конкурировать за внимание и инструменты. Они начинают опираться на общий слой наблюдаемости и общий язык данных.
Куда все движется?
Движется все к открытым, программируемым платформам. На этот раз уже благодаря не вендорам, а крупным покупателям: мировым гигантам в индустрии социальных сетей, публичных облаков, глобальных сервисов.
Будущее за устройствами, которые предоставляют богатые API (REST, gRPC) для управления и сбора телеметрии в реальном времени. Это делает интеграцию с NDR/NPM платформами глубокой и бесшовной. Переход от периодического опроса по SNMP к потоковой телеметрии меняет качество управления: события и состояния сети становятся видны с высокой детализацией и практически без задержек. Передовые мировые вендоры активно развивают подходы к анализу телеметрии с сетевых устройств, и мы считаем это критически важным направлением. Что касается российского опыта, то компания "Гарда" выступает одним из первопроходцев этого подхода и в своих продуктах активно использует анализ телеметрии наравне со SPAN.
Ведущие производители (Cisco, Juniper, Arista) также развивают модели, где на сетевую ОС (IOS XE, Junos, EOS) можно устанавливать контейнеризованные приложения, в том числе от сторонних разработчиков, например, агенты NDR-систем или анализаторы трафика. Это открывает путь к новым сценариями: легкие агенты мониторинга, локальная предобработка телеметрии, специализированные интеграционные модули.
Идеальная цель – проста и прагматична: чтобы сетевой инженер и специалист по безопасности видели события в одном интерфейсе, где данные от оборудования контекстуализированы, то есть сетевое событие автоматически связывается с инцидентом безопасности и показателями производительности.
Интеграция функций ИБ в сетевое оборудование – не приятный бонус или маркетинговая уловка, а необходимый эволюционный шаг и базовая потребность зрелой сети, в которой маршрутизаторы и коммутаторы не автономные крепости, но управляемые программно-интеллектуальные узлы в единой экосистеме видимости и контроля. А симбиоз с платформами класса NDR и NPM становится ключом к построению устойчивой, производительной и безопасной сети.