Блог компании cisco

Каждый год мы с друзьями ходим в баню. Каждый год, когда наши большие друзья, компания Positive Technologies проводит свое глобальное мероприятие для настоявших экспертов в области информационной безопасности PHDays. И каждый год мой друг и коллега Алексей Лукацкий говорит мне Миша, давай что-нибудь технологическое сделаем!. А потом выясняется, что заваленный рутиной, я опять все пропустил. Но этот год, как мы все уже заметили, глубоко особенный. И вместо PHDays было проведено очень эффективное и масштабное мероприятие под названием Standoff. В этот раз я решил послушать Алексея Викторовича и успеть что-то сделать! Тем более, что мероприятие существенно превосходило все, что когда-либо делалось ранее. Посмотреть детали этого впечатляющего киберполигона можно вот тут: https://standoff365.com/battlefield.
Вкратце скажу, что он эмулировал собой полноценный, и весьма немаленький город, в котором было практически все начиная от аэропорта, и заканчивая финансовыми организациями и парком аттракционов! Это давало злоумышленникам возможность проявить свои навыки взлома, а защитникам свои навыки обнаружения и отражения угроз.

Итак, возник вопрос, как же нам понаблюдать за этой битвой, с точки зрения информационной безопасности? Собственно, эта статья именно о подробностях построении такого процесса наблюдения и полученных нами результатах.

Мы понимали, что вмешиваться в работу полигона мы не должны, а также заниматься детальной подстройкой профилей обнаружения атак формат мероприятия не позволяет, то и было выбрано решения класса NTA (NTA Network Traffic Analytics) это решения, которые определяют угрозы по анализу сетевой телеметрии, или, попросту говоря, профилю сетевого трафика. Внедрение таких систем идет гораздо проще и бесшовнее, чем, например, внедрение классических систем обнаружения и предотвращения вторжений. Это связанно и с тем, что нет необходимости вносить изменения в сетевую топологию, а также тем, что ядром таких систем является машинное обучение в сочетании с данными аналитики угроз. Такой подход позволяет системе не только быстро идентифицировать типовые угрозы, но и обучиться за определенный интервал времени, а затем использовать полученные знания для обнаружения нештатного поведения пользователей, систем и приложений. Также такие системы, просто по своему подходу, являются существенно менее шумными с точки зрения оповещения о всевозможных угрозах и гораздо более точными с точки зрения идентификации реальных инцидентов. На этом краткий экскурс в данную тему я закончу, кто хочет почитать об этом подробнее, советую обратить внимание на вот такой материал:
http://personeltest.ru/aways/habr.com/ru/company/cisco/blog/348532/

Изначально, я решил использовать давно и хорошо известный продукт Cisco Stealthwatch Enterprise, успешно применяемый многими моими коллегами в разных организациях. И уже собрался позвонить коллегам в Positive чтобы рассказать им, сколько мне нужно процессоров, места дисках, виртуалок и т. п. В этот момент странная мысль посетила меня я вспомнил, как много ресурсов и людских и технических было положено на создание этого киберполигона, и подумал, что на то, что часть этих ресурсов попрошу я, никто не рассчитывал. С другой стороны, отказываться от идеи не хотелось, и в рамках современных тенденций в области обеспечения информационной безопасности я решил перейти на облачное решение под названием Stealthwatch Cloud. Надо сказать, что это решение называется облачным не зря, так как оно умеет собирать и анализировать телеметрию частных облаков, создаваемых внутри публичных облаков, через прикладные программные интерфейсы (API). Т. е. с помощью этого решения я могу анализировать, с точки зрения информационной безопасности, происходящее внутри Amazon AWS, Microsoft Azure, Google GCP, а также контейнеров Kubernetes. Но сейчас мне было нужно другое применение этого продукта а именно мониторинг частных сетей. В этом случае в такую сетку просто устанавливается датчик (сенсор), которые и отдает телеметрию в облачную консоль мониторинга и управления. В предыдущем предложении я употребил слово просто и теперь попробую развернуть его подробнее.

Итак, как же выглядит процесс?

Надо запросить триалку, это занимает пару минут.
Ссылка тут:
https://www.cisco.com/c/en/us/products/security/stealthwatch/stealthwatch-cloud-free-offer.html?dtid=osscdc000283

Потом, в течение пары дней начинают приходить разные полезные письма и в конце концов приходит письмо про то, что портал активирован!
После этого получаешь себе личный портал, ссылка на который выглядит так:

cisco-YOUR_CISCO_USERNAME.obsrvbl.com, например: cisco-mkader.obsrvbl.com.

Заходя туда, мы видим главный экран, откуда можно скачать виртуальную машину сенсора для мониторинга частных сетей. Требования под эту виртулку не велики 2 vCPU, 2 гига памяти и 32 гига места на диске. А в целом процесс установки крайне прост и описан в непривычно простом и удобном руководстве, сделанным в виде листаемой электронной книги:
https://ebooks.cisco.com/story/swc-sensor-install/
Сразу скажу, что у сенсора есть два интерфейса один служит для связи с консолью управления и также собирает на себе телеметрию, например NetFlow, а заодно и мониторит весь приходящий на него трафик. Второй же может работать в режиме захвата пакетов (promiscuous mode) и генерировать телеметрию по пойманному им трафику. В нашем конкретном случае мы использовали только первый интерфейс.

После установки сенсор бежит в облако, где размещена консоль это на самом деле AWS и выдает прекрасное сообщение:
{error:unknown identity,identity:185.190.117.34}

Это тот самый IP адрес, под которым сенсор считает, что видит себя во внешнем мире, пробившись через корпоративный межсетевой экран, трансляцию адресов и т. п. На всякий случай, сразу скажу, что сенсору нужен HTTP и HTTPs, а также настройка DNS-а. После получения указанного выше сообщения надо просто взять этот адрес и добавить его в список своих сенсоров на консоли:



И через некоторое время сенсор окрашивается в зеленый цвет это означает, что сенсор установил соединение с консолью.
И, в общем то, на этом запуск системы завершен. Следующий шаг это добавление источников телеметрии, в дополнение к том, что сенсор слушает сам. Если мы хотим получать телеметрию по протоколу NetFlow, то крайне полезным является сайт https://configurenetflow.info/

На нем мы можем выбрать нужное нам сетевое устройство, ввести пару параметров и получить готовую конфигурацию:



И скопировать полученную информацию на наши сетевые устройства. Все система готова к работе! Вернее даже уже начала работать.
Кстати, примеры настроек Netflow с этого сайта можно использовать не только под Steathwatch, а под любой другой продукт, которому может пригодится такая телеметрия например Cisco Tetration, IBM QRadar и т. п.

Теперь можно заняться и мелким тюнингом системы. Сразу хочу сказать, что я очень люблю смотреть, как разные продукты компании Cisco по информационной безопасности сообщают мне обо всем происходящим на единую консоль мониторинга и реагирования Cisco SecureX. На самом деле SecureX штука крайне интересная и заслуживает отдельного описания. В двух словах это облачная система мониторинга информационной безопасности (SIEM), проведения расследований (Threat Hunting), расследования и реагирования на инциденты, а заодно еще и автоматизации процессов (SOAR). Очень рекомендую подробнее ознакомиться с этой системой, причем она прилагается по умолчанию к любому продукту Cisco по информационной безопасности. Ну и немного маркетинга по это теме вот тут: https://www.cisco.com/c/ru_ru/products/security/securex.html

Итак, первым делом и настроил такую интеграцию:



Заодно я настроил интеграцию и с нашей облачной платформой предоставления услуг безопасности Cisco Umbrella: http://personeltest.ru/aways/habr.com/ru/company/jetinfosystems/blog/529174/



Особых надежд на нее я не возлагал, пологая, что все самое интересное будет происходить внутри полигона, а обеспечивать защиту этого полигона в мои задачи не входило.

После этого я создал себе новую консоль мониторинга в SecureX. Все это суммарно заняло минут 5, а может и того меньше. Пара картинок из моего SecureX -а ниже:





После этого я решил отключить неинтересные мне уведомления, и включить интересные. Для этого я вернулся в консоль SWC и пошел настраивать эти самые уведомления:



Сразу скажу, что по каждому из уведомлений можно посмотреть, что оно из себя представляет, сколько дней сбора телеметрической информации требуется для обнаружения соответствующей угрозы, и как она ложится, если ложится, на модель MITRE ATT&CK.
Количество обнаруживаемых угроз и связанных с ними уведомлений постоянно растет по мере развития самого по себе решения. Но мне про это думать особо не надо облако же, как что новое добавили, так это сразу в моем распоряжении.
Я отключил большую часть уведомлений, связанных с атаками на облака AWS, Azure, GCP, так как они в рамках данного полигона не использовались, и включил все уведомления, связанные с атаками на частные сети.
Также я могу поуправлять политиками мониторинга по разным подсетям, которые я хочу контролировать. Можно отдельно включить и мониторинг по особо интересующим нас странам:



В этом месте я прочитал свой текст выше и понял, что писал его гораздо больше времени, чем заняла настройка системы, включая все интеграции.

Ну а теперь что же мы увидели?

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





Во-вторых, оценить масштабность мероприятия с какими же странами был наиболее активный обмен трафиком:



На самом деле есть и более удобный формат представления этих данных, но тут я решил показать больше детализации.
Итак, основными внешними, помимо России, пользователями полигона были США, Германия, Голландия, Ирландия, Англия, Франция, Финляндия, Канада, хотя определенное взаимодействие было практически со всеми странами, включая страны Южной Америки, Африки и Австралию:



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



И при желании, спросить про них у других полезных аналитических источников:



Что позволило увидеть, например, активное взаимодействие с ресурсами компании Microsoft во многих странах.
Причем таблицу наиболее активных взаимодействий можно было увидеть и в виде динамической картинки соединений с возможностью ее более подробного анализа:



Но что-же все-таки мы собрали именно с точки зрения атак?
Об этом нам рассказывает список уведомлений, часть которого вы видите ниже:



Всего было идентифицировано 117 атак, подтвержденных множеством наблюдений (Observables) Мы видим тут и сетевые сканирования, и подозрительные длинные сессии, проблемы с SMB, некорректное использование сетевых портов и сервисов, странное поведение сетевых узлов, неожиданное изменение их поведения и прочие странности, которые должны насторожить специалиста по информационной безопасности.
По каждому интересующему нас событию мы можем получить подробную информацию, включая что оно из себя представляет, чем оно плохо и рекомендации по предотвращению. Пару таких интересный событий можно увидеть ниже это неожиданный запуск SSH сервера на рабочей станции Windows и использование нестандартного диапазона портов. Также можно обратить внимание на то, что, при настроенной интеграции можно прямо из описания события перейти в консоль проведения расследований SecureX Treat Response для подробного анализа данного инцидента:





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

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

Третий участники полигона тоже активно пользовались облачными сервисами, например сервисами компании Microsoft

Четвертый автоматизированный машинный анализ разнообразной сетевой телеметрии позволяет легко выявить инциденты ИБ, включая спланированную деятельность злоумышленников. И советую обратить внимание на то, что уже существует множество проработанных сценариев эффективного применения решения Cisco Stealthwatch для нужд информационной безопасности. Каждый из читателей может найти себе сценарий по душе вот тут: https://cisco.bravais.com/s/kCvJYJKyhuyQqAZSU6Xk.

Ну и маленький заключительный комментарий в этой статье я сознательно не стал подробно перечислять полученные списки адресов IP, доменов, детали взаимодействия и т. п., понимая, сколько усилий стоило компании Positive Technologies собрать данный полигон и надеясь, что он неоднократно пригодится им и нам и в дальнейшем. И облегчать жизнь будущим атакующим мы не будем.

С августа 2017 года, когда компания Cisco приобрела компанию Viptela, основной предлагаемой технологией организации распределенных корпоративных сетей стала Cisco SD-WAN. За прошедшие 3 года SD-WAN технология прошла множество изменений, как качественного, так и количественного характера. Так значительно расширились функциональные возможности и появилась поддержка на классических маршрутизаторах серий Cisco ISR 1000, ISR 4000, ASR 1000 и виртуального CSR 1000v. В то же время многие заказчики и партнеры Cisco продолжают задаваться вопросом в чем заключаются отличия Cisco SD-WAN от уже привычных подходов на базе таких технологий, как Cisco DMVPN и Cisco Performance Routing и насколько эти отличия важны?

Здесь сразу следует сделать оговорку, что до появления SD-WAN в портфолио Cisco, DMVPN совместно с PfR составляли ключевую часть в архитектуре Cisco IWAN (Intelligent WAN), которая в свою очередь представляла собой предшественника полновесной SD-WAN технологии. При общем сходстве, как самих решаемых задач, так и способов их решения, IWAN так и не получил необходимого для SD-WAN уровня автоматизации, гибкости и масштабируемости и со временем развитие IWAN значительно снизилось. В то же время сами технологии-составляющие IWAN никуда не делись, и многие заказчики продолжают их успешно использовать в том числе на современном оборудовании. В итоге сложилась интересная ситуация одно и то же оборудование Cisco позволяет выбрать наиболее подходящую технологию построения WAN (классическую, DMVPN+PfR или SD-WAN) в соответствии с требованиями и ожиданиями заказчиков.

Статья не предполагает подробно разбирать все особенности технологий Cisco SD-WAN и DMVPN (совместно или без Performance Routing) для этого имеется огромное количество доступных документов и материалов. Основная задача постараться оценить ключевые отличия этих технологий. Но все же прежде, чем перейти к обсуждению этих различий, кратко напомним о самих технологиях.

Что такое Cisco DMVPN и зачем он нужен?

Cisco DMVPN решает задачу динамического (=масштабируемого) подключения сети удаленного филиала к сети центрального офиса предприятия при использовании произвольных типов каналов связи в том числе Интернет (= с шифрованием канала связи). Технически это реализуется созданием виртуализированной наложенной сети класса L3 VPN в режиме точка много точка (point-to-multipoint) с логической топологией типа Звезда (Hub-n-Spoke). Для этого DMVPN использует комбинацию следующих технологий:

• IP маршрутизация
• Multipoint GRE туннели (mGRE)
• Next Hop Resolution Protocol (NHRP)
• IPSec Crypto профили

В чем основные преимущества Cisco DMVPN в сравнении с классической маршрутизацией с использованием MPLS VPN каналов?

• Для создания межфилиальной сети возможно использовать любые каналы связи подходит все, что способно обеспечить IP-связность между филиалами, при этом трафик будет и шифроваться (где надо) и балансироваться (где возможно)
• Автоматически формируется полно связная топология между филиалами. При этом между центральным и удаленным филиалами статические туннели, а между удаленными филиалами динамические туннели по требованию (при наличии трафика)
• На маршрутизаторах центрального и удаленного филиала однообразная конфигурация с точностью до IP-адресов интерфейсов. За счет использования mGRE нет необходимости в индивидуальной настройке десятков, сотен или даже тысяч туннелей. Как следствие, достойная масштабируемость при правильном дизайне.

Что такое Cisco Performance Routing и зачем он нужен?

При использовании DMVPN на межфилиальной сети остается нерешенным один крайне важный вопрос как динамически оценить состояние каждого из DMVPN туннелей на предмет соответствия требованиям критичного для нашей организации трафика и опять же на основе такой оценки динамически принимать решение о перемаршрутизации? Дело в том, что DMVPN в этой части немногим отличается от классической маршрутизации лучшее, что можно сделать, это настроить механизмы QoS, которые позволят приоритезировать трафик в исходящем направлении, но никак не способны учитывать состояние всего пути в тот или иной момент времени.

И что делать, если канал деградирует частично, а не полностью как это обнаружить и оценить? DMVPN сам по себе этого не умеет. Учитывая, что каналы, связывающие филиалы, могут проходить через совершенно разных операторов связи, используя совершенно разные технологии, то это задача становится крайне нетривиальной. И вот здесь на помощь приходит технология Cisco Performance Routing, которая к тому времени уже прошла несколько стадий развития.



Задача Cisco Performance Routing (далее PfR) сводится к измерению состояния путей (туннелей) прохождения трафика на основе ключевых метрик, важных для сетевых приложений задержка, вариация задержки (джиттер) и потери пакетов (в процентах). Дополнительно может измеряться используемая полоса пропускания. Эти измерения происходят максимально близко к реальному времени (насколько это возможно и оправданно) и результат этих измерений позволяет маршрутизатору, изпользующему PfR, динамически принимать решения о необходимости изменения маршрутизации того или иного вида трафика.

Таким образом задачу комбинации DMVPN/PfR можно кратко охарактеризовать следующим образом:

• Позволить заказчику использовать на WAN сети любые каналы связи
• Обеспечить максимально возможное качество важных приложений на этих каналах

Что такое Cisco SD-WAN?

Cisco SD-WAN это технология, которая использует SDN подход для создания и эксплуатации WAN сети организации. Это в частности означает использование так называемых контроллеров (программных элементов), которые обеспечивают централизованную оркестрацию и автоматизированную настройку всех компонентов решения. В отличии от канонического SDN (в стиле Clean Slate) в Cisco SD-WAN используется сразу несколько типов контроллеров, каждый из которых выполняет свою роль это сделано намеренно с целью обеспечить лучшую масштабируемость и гео-резервирование.



В случае SD-WAN задача использования любых типов каналов и обеспечение работы бизнес-приложений сохраняется, но при этом расширяются требования к автоматизации, масштабированию, безопасности и гибкости такой сети.

Обсуждение различий

Если теперь начать анализировать отличия этих технологий, то они будут попадать в одну из категорий:

• Архитектурные отличия как распределены функции по различным компонентам решения, как организовано взаимодействие таких компонентов и как это влияет на возможности и гибкость технологии?
• Функциональные возможности что такого может одна технология, чего не может другая? И так ли это важно?

В чем заключены архитектурные различия и так ли они важны?

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

Рассмотрим различные аспекты архитектуры более подробно:

Data-plane часть решения, отвечающее за передачу пользовательского трафика между источником и получателем. В DMVPN и SD-WAN реализуется в целом одинаково на самих маршрутизаторах на базе Multipoint GRE туннелей. Разница в том, за счет чего формируется необходимый набор параметров этих туннелей:

• в DMVPN/PfR это исключительно двухуровневая иерархия узлов с топологией типа Звезда или Hub-n-Spoke. Обязательна статическая настройка Hub и статическая привязка Spoke к Hub, а также взаимодействие по протоколу NHRP для формирования data-plane связности. Как следствие, значительно затруднены изменения на Hub, связанные, например с изменением/подключением новых WAN-каналов или изменения параметров существующих.
• в SD-WAN это полностью динамическая модель обнаружения параметров устанавливаемых туннелей с опорой на control-plane (протокол OMP) и orchestration-plane (взаимодействие с контроллером vBond для задач обнаружения контроллеров и NAT traversal). При этом наложенные топологии могут любые, в том числе иерархические. В рамках установленной наложенной топологии туннелей возможна гибкая настройка логической топологии в каждом отдельном VPN(VRF).

Control-plane функции обмена, фильтрации и модификации маршрутной и другой информации между компонентами решения.

• в DMVPN/PfR осуществляется только между маршрутизаторами Hub и Spoke. Прямой обмен маршрутной информацией между Spoke невозможен. Как следствие, без действующего Hub невозможно функционирование control-plane и data-plane, что накладывает на Hub дополнительные требования по высокой доступности, которые не всегда могут быть выполнены.
• в SD-WAN control-plane никогда не осуществляется напрямую между маршрутизаторами взаимодействие происходит на основе протокола OMP и обязательно осуществляется через отдельный специализированный тип контроллера vSmart, что обеспечивает возможность балансировки, гео-резервирования и централизованного управления сигнальной нагрузкой. Другой особенностью OMP протокола является его значительная устойчивость к потерям и независимость от скорости канала связи с контроллерами (в разумных пределах, конечно). Что одинаково успешно позволяет размещать контроллеры SD-WAN в публичных или частных облаках с доступом через Интернет.

Policy-plane часть решения отвечающее за определение, распространение и применение политик управления трафиком на распределенной сети.

• DMVPN фактически ограничено политиками качества обслуживания (QoS), настраиваемыми индивидуально на каждом маршрутизаторе через CLI или шаблоны Prime Infrastructure.
• DMVPN/PfR политики PfR формируются на централизованном маршрутизаторе Master Controller (MC) через CLI и далее автоматически распространяются в филиальные MC. При этом используются те же пути передачи политик, что и для data-plane. Возможности разнести обмен политиками, маршрутной информацией и пользовательскими данными нет. Распространение политик предполагает обязательное наличие IP-связности между Hub и Spoke. При этом функция MC может быть при необходимости совмещена с DMVPN маршрутизатором. Возможно (но не требуется) использование шаблонов Prime Infrastructure для централизованного формирования политик. Важная особенность политика формируется глобально на всей сети одинаково индивидуальные политики для отдельных сегментов не поддерживаются.
• SD-WAN политики управления трафиком и качеством обслуживания определяются централизовано через графический интерфейс Cisco vManage доступный в том числе и через Интернет (при необходимости). Распространяются по сигнальными каналам напрямую или опосредованно через контроллеры vSmart (зависит от типа политики). Не зависят от data-plane связности между маршрутизаторами, т.к. используют все доступные пути передачи трафика между контроллером и маршрутизатором.
  
  Для разных сегментов сети возможно гибкое формирование различных политик сфера применения политики определяется множеством уникальных идентификаторов, предусмотренных в решении номер филиала, тип приложения, направление движения трафика и т.д.
  

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

• в DMVPN/PfR взаимное обнаружение маршрутизаторами основано на статической конфигурации Hub устройств и соответствующей настройке Spoke устройств. Динамическое обнаружение происходит только для Spoke, который сообщает о своих параметрах соединения Hub устройству, которое в свою очередь заранее внесено в конфигурацию Spoke. Без IP-связности Spoke с хотя бы одним Hub невозможно сформировать ни data-plane, ни control-plane.
• в SD-WAN оркестрация компонентов решения происходит с использованием контроллера vBond, с которым каждому компоненту (маршрутизаторам и контроллерам vManage/vSmart) необходимо предварительно установить IP-связность.
  
  Изначально компоненты не знают о параметрах подключения друг друга для этого им необходим посредник-оркестратор vBond. Общий принцип следующий каждый компонент в начальной фазе узнает (автоматически или статически) только о параметрах подключения к vBond, далее vBond сообщает маршрутизатору о контроллерах vManage и vSmart (обнаруженных ранее), что делает возможным автоматическое установление всех необходимых сигнальных связей.
  
  Следующим шагом новый маршрутизатор узнает об остальных маршрутизаторах в сети через OMP-обмен с контроллером vSmart. Таким образом маршрутизатор, не зная изначально о параметрах сети вообще ничего, способен полностью автоматически обнаружить и подключиться к контроллерам и затем также автоматически обнаружить и сформировать связность с остальными маршрутизаторами. При этом параметры подключений всех компонентов изначально неизвестны и в процессе эксплуатации могут меняться.
  

Management-plane часть решения, обеспечивающая централизованное управление и мониторинг.

• DMVPN/PfR специализированного management-plane решения не предусмотрено. Для базовой автоматизации и мониторинга возможно использование таких продуктов, как Cisco Prime Infrastructure. Каждый маршрутизатор имеет возможность управления через командную строку CLI. Интеграции с внешними системами через API не предусмотрено.
• SD-WAN все штатное взаимодействие и мониторинг осуществляется централизовано через графический интерфейс контроллера vManage. Все возможности решения без исключения доступны к настройке через vManage, а также через полностью документированную библиотеку программного интерфейса REST API.
  
  Все настройки SD-WAN сети в vManage сводятся к двум основным конструктам формирование шаблонов устройств (Device Template) и формирование политики, которая определяет логику работы сети и обработки трафика. При этом vManage, транслируя сформированную администратором политику, автоматически выбирает какие изменения и на каких индивидуальных устройствах/контроллерах необходимо произвести, что значительно повышает эффективность и масштабируемость решения.
  
  Через интерфейс vManage доступна не только настройка решения Cisco SD-WAN, но и полноценный мониторинг состояния всех компонентов решения вплоть до текущего состояния метрик отдельных туннелей и статистики использования различных приложений на основе DPI анализа.
  
  Несмотря на централизацию взаимодействия, все компоненты (контроллеры и маршрутизаторы) обладают также полнофункциональной командной строкой CLI, которая необходима на этапе внедрения или в случае нештатной ситуации для локальной диагностики. В штатном режиме (при наличии сигнального канала между компонентами) на маршрутизаторах командная строка доступна только для диагностики и недоступна для внесения локальных изменений, что гарантирует и локальную безопасность и единственный источник изменений в такой сети vManage.

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

• в DMVPN/PfR предусмотрена возможность шифрования пользовательских данных и сигнальных протоколов. При использовании определенных моделей маршрутизаторов дополнительно доступны функции межсетевого экранирования с инспекцией трафика, IPS/IDS. Есть возможность сегментации филиальных сетей с использованием VRF. Есть возможность аутентификации (однофакторной) контрольных протоколов.
  
  При этом удаленный маршрутизатор по-умолчанию считается доверенным элементом сети т.е. не предполагаются и не учитываются случаи физической компрометации отдельных устройств и возможность несанкционированного к ним доступа, нет двухфакторной аутентификации компонентов решения, что в случае географически распределенной сети может нести серьезные дополнительные риски.
• в SD-WAN по аналогии с DMVPN предусмотрена возможность шифрования пользовательских данных, но со значительно расширенными функциями сетевой безопасности и L3/VRF сегментации (МСЭ, IPS/IDS, URL-фильтрация, DNS-фильтрация, AMP/TG, SASE, TLS/SSL proxy и т.д.). При этом обмен ключами шифрования осуществляется более эффективно через vSmart контроллеры (а не напрямую), по заранее установленным сигнальным каналам, защищенным DTLS/TLS шифрованием на основе сертификатов безопасности. Что в свою очередь гарантирует безопасность такого обмена и обеспечивает лучшую масштабируемость решения в плоть до десятков тысяч устройств в одной сети.
  
  Все сигнальные соединения (контроллер-контроллер, контроллер маршрутизатор) также защищены на основе DTLS/TLS. Маршрутизаторы оснащаются сертификатами безопасности при производстве с возможностью замены/продления. Двухфакторная аутентификация достигается за счет обязательного и одновременного выполнения двух условий для возможности функционирования маршрутизатора/контроллера в SD-WAN сети:
  
  
  • Действующий сертификат безопасности
  • Явное и осознанное внесение администратором каждого компонента в белый список разрешенных устройств.
  
  

Функциональные отличия SD-WAN и DMVPN/PfR

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

AppQ (Application Quality) функции обеспечения качества передачи трафика бизнес-приложений

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

DMVPN самостоятельно не предоставляет таких механизмов. Лучшее, что возможно сделать в классической DMVPN сети, это классифицировать исходящий трафик по приложениям и приоритезировать его при передаче в направлении WAN-канала. Выбор DMVPN туннеля обусловлен в этом случае только его доступностью и результатом работы протоколов маршрутизации. При этом никак не учитывается сквозное состояние пути/туннеля и его возможная частичная деградация с точки зрения ключевых метрик, значимых для сетевых приложений задержка, вариация задержки (джиттер) и потери (%). В связи с этим напрямую сравнивать классический DMVPN c SD-WAN в части решения AppQ задач теряет всякий смысл DMVPN не может решить эту задачу. При добавлении в этот контекст технологии Cisco Performance Routing (PfR) ситуация меняется и сравнение с Cisco SD-WAN становится более целесообразным.

Прежде, чем перейти к обсуждению различий, коротко о том, в чем технологии схожи. Итак, обе технологии:

• имеют в наличии механизм, который позволяет динамически оценить состояние каждого установленного туннеля в разрезе определенных метрик как минимум, задержка, вариация задержки и потери пакетов (%)
• используют определенный набор инструментов для формирования, распространения и применения правил (политик) управления трафиком с учетом результата измерения состояния ключевых метрик туннелей.
• классифицируют трафик приложений на уровнях L3-L4 (DSCP) модели OSI или по L7 сигнатурам приложений на основе встроенных в маршрутизатор DPI механизмов
• позволяют для значимых приложений определить допустимые пороговые значения метрик, правила передачи трафика по-умолчанию, правила перемаршрутизации трафика при превышении пороговых значений.
• при инкапсуляции трафика в GRE/IPSec используют уже устоявшейся в индустрии механизм переноса внутренней DSCP маркировки во внешний GRE/IPSEC заголовок пакета, что позволяет синхронизировать политики QoS организации и оператора связи (при наличии соответствующего SLA).

Как отличаются механизмы оценки сквозных метрик SD-WAN и DMVPN/PfR?

DMVPN/PfR

• Для оценки стандартных метрик состояния туннеля используются как активные, так и пассивные программные сенсоры (Probes). Активные на основе пользовательского трафика, пассивные эмулируют такой трафик (при его отсутствии).
• Тонкая настройка таймеров и условий обнаружения деградации отсутствует алгоритм фиксирован.
• Дополнительно доступно измерение используемой полосы пропускания в исходящем направлении. Что добавляет DMVPN/PfR дополнительную гибкость управления трафиком.
• При этом некоторые механизмы PfR при превышении метрик полагаются на обратную сигнальную связь в виде специальных TCA (Threshold Crossing Alert) сообщений, которые должны исходить от получателя трафика в сторону источника, что в свою очередь предполагает, что состояния измеряемых каналов должно быть как минимум достаточно для передачи таких TCA-сообщений. Что в большинстве случаев не является проблемой, но очевидно не может быть гарантировано.

SD-WAN

• Для сквозной оценки стандартных метрик состояния туннеля используется протокол BFD в echo-режиме. При этом специальной обратной связи в виде TCA или подобных сообщений не требуется соблюдается изолированность доменов отказа. Также не требуется присутствие пользовательского трафика для оценки состояния туннеля.
• Есть возможность тонкой настройки таймеров BFD для регулирования скорости срабатывания и чувствительности алгоритма к деградациям канала связи от нескольких секунд до минут.
  
  
  
• На момент написания статьи в каждом из туннелей предусмотрена только одна BFD сессия. Потенциально это создает меньшую гранулярность при анализе состояния туннеля. В действительности это может стать ограничением только в случае использования WAN-подключения на базе MPLS L2/L3 VPN с согласованным QoS SLA если DSCP-маркировка BFD трафика (после инкапсуляции в IPSec/GRE) будет совпадать с высокоприоритетной очередью в сети оператора связи, то это может повлиять на точность и скорость обнаружения деградации для низкоприоритетного трафика. При этом есть возможность изменения маркировки BFD по-умолчанию для снижения риска возникновения подобных ситуаций. В следующих версиях ПО Cisco SD-WAN ожидается появление более тонкой настройки BFD, а также возможность запуска нескольких BFD сессий в рамках одного туннеля с индивидуальными DSCP-значениями (для разных приложений).
• BFD дополнительно позволяет оценить максимальный размера пакета, который возможно передать по тому или иному туннелю без фрагментации. Это позволяет SD-WAN динамически настраивать такие параметры, как MTU и TCP MSS Adjust, чтобы максимально эффективно использовать доступную полосу пропускания на каждом канале.
• В SD-WAN также доступна опция синхронизации QoS с операторов связи не только на основе L3 DSCP поля, но и на основе L2 CoS значений, которые могут автоматически формироваться в филиальной сети специализированными устройствами например, IP-телефонами

Как отличаются возможности, способы определения и применения AppQ политик?

Политики DMVPN/PfR:

• Определяются на маршрутизаторе(-ах) центрального филиала (ЦФ) через командную строку CLI или CLI-шаблоны конфигураций. Формирование CLI-шаблонов требует подготовки и знания синтаксиса политик.
  
  
  
• Определяются глобально без возможности индивидуальной настройки/изменения под требования отдельных сегментов сети.
• Интерактивное формирование политик в графическом интерфейсе не предусмотрено.
• Отслеживание изменений, наследование, создание нескольких версий политик для быстрого переключения не предусмотрено.
• Распространяются автоматически на маршрутизаторы удаленных филиалов. При этом используется те же каналы связи, что и для передачи пользовательских данных. При отсутствии канала связи между центральным и удаленным филиалом распространение/изменение политик невозможно.
• Применяются на каждом маршрутизаторе и при необходимости модифицируют результат стандартных протоколов маршрутизации, имея более высокий приоритет.
• Для случаев, когда все WAN-каналы филиала испытывают значительные потери трафика, механизмов компенсации не предусмотрено.

Политики SD-WAN:

• Определяются в графическом интерфейсе vManage через интерактивный мастер шаблонов.
• Поддерживают создание нескольких политик, копирование, наследование, переключение между политиками в реальном режиме времени.
• Поддерживают индивидуальную настройку политики под разные сегменты (филиалы) сети
• Распространяются, используя любой доступный сигнальный канал между контроллером и маршрутизатором и/или vSmart не зависят напрямую от data-plane связности между маршрутизаторами. При этом конечно требуется IP-связность между самим маршрутизатором и контроллерами.
  
  
• Для случаев, когда все доступные каналы филиала испытывают значительные потери данных, превышающие допустимые пороговые значения для критичных приложений, возможно использование дополнительных механизмов, повышающих надежность передачи:
  
  
  • FEC (Forward Error Correction) использует специальный алгоритм избыточного кодирования. При передаче критичного трафика по каналам со значительным процентом потерь, FEC может быть автоматически активирован и позволяет при необходимости восстановить потерянную часть данных. При этом незначительно повышается используемая полоса передачи, но значительно повышается надежность.
    
    
  • Дубликация потоков данных дополнительно к FEC политика может предусматривать автоматическое дублирование трафика выбранных приложений в случае еще более серьезного уровня потерь, которые не удается компенсировать с помощью FEC. В этом случае выбранные данные будут передаваться по всем туннелям в сторону филиала-получателя с последующей де-дубликацией (отбрасывания лишних копий пакетов). Механизм заметно увеличивает утилизацию каналов, но так же значительно повышает надежность передачи.

Возможности Cisco SD-WAN, без прямых аналогов в DMVPN/PfR

Архитектура решения Cisco SD-WAN в некоторых случая позволяет получить возможности, реализация которых в рамках DMVPN/PfR либо крайне затруднена, либо нецелесообразна в силу необходимых трудозатрат, либо вообще невозможна. Рассмотрим наиболее интересные из них:

Traffic-Engineering (TE)

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

Сложность реализации TE заключается в необходимости заранее вычислить и зарезервировать (проверить) альтернативный путь. В MPLS сетях операторов связи эту задачу решают, используя такие технологии, как MPLS Traffic-Engineering с расширениями IGP протоколов и RSVP протокола. Также в последнее время все большую популярность набирает технология Segment Routing, которая более оптимизирована для централизованной настройки и оркестрации. В классических WAN сетях эти технологии, как правило, не представлены или сведены до использования hop-by-hop механизмов вроде Policy-Based Routing (PBR), которые способны ответвить трафик, но реализуют это на каждом маршрутизаторе отдельно без учета общего состояния сети или результата PBR на предыдущем или последующих шагах. Итог применения этих вариантов TE неутешительный MPLS TE ввиду сложности настройки и эксплуатации, используют, как правило, только в самой критичной части сети (ядро), а PBR используют на отдельных маршрутизаторах без возможности сформировать некую единую PBR политику на всей сети. Очевидно, это касается и сетей на базе DMVPN.



SD-WAN в этом плане предлагает гораздо более элегантное решение, которое не только легко настраивается, но и значительно лучше масштабируется. Это является результатом используемых архитектур control-plane и policy-plane. Реализация policy-plane в SD-WAN позволяет централизовано определить политику TE какой трафик интересует? для каких VPN? через какие узлы/туннели необходимо или наоборот запрещено формировать альтернативный маршрут? В свою очередь централизация управления control-plane на базе vSmart контроллеров позволяет модифицировать результаты маршрутизации, не прибегая к настройкам отдельных устройств маршрутизаторы уже видят только результат той логики, которая была сформирована в интерфейсе vManage и передана для применения на vSmart.

Service-chaining (Сервисные цепочки)

Формирование сервисных цепочек еще более трудоемкая задача в классической маршрутизации, чем уже описанный механизм Traffic-Engineering. Ведь в этом случае необходимо не только сформировать некий специальный маршрут для определенного сетевого приложения, но и обеспечить возможность вывода трафика из сети на определенных (или на всех) узлах SD-WAN сети для обработки специальным приложением или сервисом (МСЭ, Балансировка, Кэширование, Инспекция трафика и т.п.). При этом необходимо иметь возможность контролировать состояние этих внешних сервисов, чтобы не допускать ситуаций black-holing, а также нужны механизмы позволяющие размещать такие однотипные внешние сервисы в различных гео-локациях с возможностью сети автоматически выбирать наиболее оптимальный сервисный узел для обработки трафика того или иного филиала. В случае Cisco SD-WAN это достаточно легко достичь, создав соответствующую централизованную политику, которая склеит все аспекты целевой сервисной цепочки в единое целое и автоматически изменит логику data-plane и control-plane только там и тогда, где это необходимо.



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

Что в итоге?

Очевидно, что и DMVPN (совместно или без Performance Routing) и Cisco SD-WAN решают в конечном итоге очень похожие задачи по отношению к распределенной WAN сети организации. При этом существенные архитектурные и функциональные отличия технологии Cisco SD-WAN выводят процесс решения этих задач на другой качественный уровень. Резюмируя, можно отметить следующие значительные отличия технологий SD-WAN и DMVPN/PfR:

• DMVPN/PfR в целом используют проверенные временем технологии построения наложенных VPN сетей и в части data-plane схожи с более современной SD-WAN технологией, при этом есть ряд ограничений в лице обязательной статической конфигурации маршрутизаторов и выбор топологий ограничен Hub-n-Spoke. С другой стороны, у DMVPN/PfR есть некоторые функциональные возможности, которые пока недоступны в рамках SD-WAN (речь о per-application BFD).
• В рамках control-plane технологии отличаются принципиально. С учетом централизованной обработки сигнальных протоколов SD-WAN позволяет, в частности, значительно сузить домены отказа и развязать процесс передачи пользовательского трафика от сигнального взаимодействия временная недоступность контроллеров не влияет на возможность передачи пользовательского трафика. В то же время временная недоступность какого-либо филиала (в том числе центрального) никак не влияет возможность остальных филиалов взаимодействовать друг с другом и контроллерами.
• Архитектура формирования и применения политик управления трафиком в случае SD-WAN также превосходит таковую в DMVPN/PfR значительно лучше реализовано гео-резервирование, нет привязки к Hub, больше возможностей по тонкой настройки политик, список реализуемых сценариев управления трафиком также значительно больше.
• Процесс оркестрации решения также значительно отличается. DMVPN предполагает наличие заранее известных параметров, которые должны быть каким-то образом отражены в конфигурации, что несколько ограничивает гибкость решения и возможность динамических изменений. В свою очередь SD-WAN исходит из парадигмы, что в начальный момент времени подключения маршрутизатор не знает ничего о своих контроллерах, но знает у кого можно спросить этого достаточно не только для автоматического установления связи с контроллерами, но и для автоматического формирования полно связной data-plane топологии, которую затем можно гибко настроить/изменить с помощью политик.
• В части централизованного управления, автоматизации и мониторинга SD-WAN ожидаемо превосходит возможности DMVPN/PfR, которые стали результатом развития классических технологий и в большей степени полагаются на командную строку CLI и применение систем NMS на основе шаблонов.
• В SD-WAN по сравнению с DMVPN требования безопасности вышли на другой качественный уровень. Главные принципы нулевое доверие, масштабируемость и двухфакторная аутентификация.

Из этих несложных выводов может сложиться неверное впечатление, что создание сети на базе DMVPN/PfR потеряло сегодня всякую актуальность. Это конечно не совсем так. Например, в случаях, когда на сети используется множество устаревшего оборудования и нет возможности его заменить, DMVPN может позволить объединить старые и новые устройства в единую гео-распределенную сеть с большим количеством описанных выше преимуществ.

С другой стороны следует помнить, что Все актуальные корпоративные маршрутизаторы Cisco на базе IOS XE (ISR 1000, ISR 4000, ASR 1000, CSR 1000v) сегодня поддерживают любой режим работы и классическую маршрутизацию и DMVPN и SD-WAN выбор определяется текущими потребностями и пониманием, что в любой момент на том же самом оборудовании можно начать двигаться в сторону более продвинутой технологии.

В 2019 году консалтинговая компания Miercom провела независимую технологическую оценку Wi-Fi 6 контроллеров Cisco Catalyst серии 9800. Для данного исследования был собран тестовый стенд из контроллеров и точек доступа Wi-Fi 6 от Cisco, и была проведена оценка технического решения в следующих категориях:

• Доступность;
• Безопасность;
• Автоматизация.

Результаты исследования приведены ниже. С 2019 года функционал контроллеров Cisco Catalyst серии 9800 был существенно улучшен эти моменты также нашли отражение в данной статье.

О других преимуществах технологии Wi-Fi 6, примерах внедрения и сферах применения можно почитать здесь.

Обзор решения

Wi-Fi 6 контроллеры Cisco Catalyst серии 9800

Серия беспроводных контроллеров Cisco Catalyst серии 9800 на базе операционной системы IOS-XE (которая также используется для коммутаторов и маршрутизаторов Cisco) предлагается в различных вариантах.



Старшая модель контроллера 9800-80 поддерживает пропускную способность беспроводной сети до 80 Гбит/с. Один контроллер 9800-80 поддерживает до 6000 точек доступа и до 64 000 беспроводных клиентов.

Модель среднего уровня контроллер 9800-40 поддерживает пропускную способность до 40 Гбит/с, до 2000 точек доступа и до 32 000 беспроводных клиентов.

В дополнение к этим моделям в конкурентный анализ также вошел беспроводной контроллер 9800-CL (CL означает Cloud). Модель 9800-CL работает в виртуальных средах на гипервизорах VMWare ESXI и KVM, а его характеристики зависят от выделенных ресурсов оборудования для виртуальной машины контроллера. В максимальной конфигурации контроллер Cisco 9800-CL так же, как и старшая модель 9800-80, поддерживает масштабируемость до 6000 точек доступа и до 64 000 беспроводных клиентов.

При проведении исследования с контроллерами использовались точки доступа Cisco Aironet AP серии 4800, поддерживающие работу на частотах 2,4 и 5 ГГц с возможностью динамического переключения в режим dual 5-GHz.

Тестовый стенд

В рамках тестирования был собран стенд из двух беспроводных контроллеров Cisco Catalyst 9800-CL, работающих в кластере, и точек доступа Cisco Aironet AP серии 4800.

В качестве клиентских устройств использовались ноутбуки компаний Dell и Apple, а также смартфон Apple iPhone.

Тестирование доступности

Доступность определяется как способность пользователей получать доступ к системе или услуге и использовать их. Высокая доступность подразумевает непрерывный доступ к системе или услуге, не зависящий от тех или иных событий.

Высокая доступность была протестирована в четырех сценариях, первые три сценария это предсказуемые или запланированные события, которые могут проводиться в рабочее или нерабочее время. Пятый сценарий это классический сбой, который является непредсказуемым событием.

Описание сценариев:

• Исправление ошибок микрообновление системы (bugfix или security patch), которое позволяет исправить ту или иную ошибку, либо уязвимость без полного обновления системного ПО;
• Функциональное обновление добавление или расширение текущего функционала системы путем установки функциональных обновлений;
• Полное обновление обновление образа ПО контроллера;
• Добавление точки доступа добавление новой модели точки доступа в беспроводную сеть без необходимости перенастройки или обновления программного обеспечения беспроводного контроллера;
• Сбой отказ беспроводного контроллера.

Исправление ошибок и уязвимостей

Зачастую во многих конкурентных решениях установка исправлений требует полного обновления программного обеспечения системы беспроводного контроллера, что может привести к незапланированным простоям. В случае решения от Cisco установка исправлений выполняется без остановки продуктива. Исправления могут быть установлены на любой из компонентов, в то время как беспроводная инфраструктура продолжает работать.

Сама по себе процедура достаточно проста. Файл исправления копируется в папку начальной загрузки на одном из беспроводных контроллеров Cisco, а затем через графический интерфейс или командную строку выполняется подтверждение операции. Кроме того, через графический интерфейс или командную строку можно еще отменить и удалить исправление, тоже без прерывания работы системы.

Функциональное обновление

Функциональные обновления ПО применяются для активации новых функций. Одним из таких усовершенствований является обновление базы данных сигнатур приложений. Этот пакет был установлен в контроллерах Cisco в качестве теста. Так же, как и в случае с исправлениями, обновление функций применяется, устанавливается или удаляется без простоя или прерывания работы системы.

Полное обновление

На данный момент полное обновление образа ПО контроллера выполняется так же, как и функциональное, то есть, без простоев. Однако эта возможность доступна только в кластерной конфигурации, когда контроллеров более одного. Полное обновление выполняется последовательно: сначала на одном контроллере, потом на втором.

Добавление новой модели точки доступа

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

В процессе подключения новых точек доступа Wi-Fi 6 к кластеру контроллеров Cisco Catalyst серии 9800 подобных проблем не наблюдается. Подключение новых точек к контроллеру проводится без обновлений ПО контроллера, и этот процесс не требует перезагрузки, таким образом никак не влияя на беспроводную сеть.

Отказ контроллера

В тестовой среде используются два контроллера (Active / StandBy) Wi-Fi 6 и точка доступа имеет прямое подключение к обоим контроллерам.

Один беспроводной контроллер является активным, а другой, соответственно, резервным. При сбое активного контроллера управление принимает на себя резервный контроллер, и его статус меняется на активный. Данная процедура происходит без прерывания для точки доступа и Wi-Fi для клиентов.

Безопасность

В этом разделе рассматриваются аспекты обеспечения безопасности, которая в беспроводных сетях является крайне актуальной задачей. Безопасность решения оценивается по следующим характеристикам:

• Распознавание приложений;
• Отслеживание потока трафика (Flow tracking);
• Анализ зашифрованного трафика;
• Обнаружение и предотвращение вторжений;
• Средства аутентификации;
• Средства защиты клиентских устройств.

Распознавание приложений

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

Есть еще одна интересная особенность распознавания приложений: решения сильно различаются по точности идентификации.

Принимая во внимание все проведенные тесты, можно ответственно заявить, что Wi-Fi-6 решение Cisco распознавание приложений выполняет очень точно: были точно определены Jabber, Netflix, Dropbox, YouTube и прочие популярные приложения, а также веб-сервисы. Также решения Cisco могут глубже погрузиться в пакеты данных с помощью DPI (Deep Packet Inspection).

Отслеживание потоков трафика

Был проведен ещё один тест, чтобы выяснить, может ли система точно отслеживать и сообщать о потоках данных (например, о перемещениях больших файлов). Чтобы проверить это, по сети был отправлен файл размером 6,5 мегабайт по протоколу передачи файлов (FTP).

Решение Cisco полностью справилось с задачей и смогло отследить этот трафик благодаря NetFlow и своим аппаратным возможностям. Трафик был обнаружен и идентифицирован немедленно с точным объемом переданных данных.

Анализ зашифрованного трафика

Трафик пользовательских данных все чаще шифруется. Это делается для того, чтобы защитить его от отслеживания или перехвата злоумышленниками. Но вместе с этим хакеры все чаще используют шифрование, чтобы скрыть свою вредоносную программу и проводить другие сомнительные операции, такие как Man-in-the-Middle (MiTM) или, например, атаки с использованием кейлогинга.

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

Контроллеры Cisco Catalyst серии 9800 успешно решают задачу анализа зашифрованного трафика другими средствами. Решение носит название Encrypted Traffic Analytics (ETA). ETA это технология, аналогов которой у конкурентных решений на данный момент нет и которая обнаруживает вредоносное ПО в зашифрованном трафике без необходимости его дешифрования. ETA это базовая функция IOS-XE, которая включает в себя Enhanced NetFlow и использует расширенные поведенческие алгоритмы для выявления вредоносных моделей трафика, скрывающихся в зашифрованном трафике.



ETA не дешифрует сообщения, а собирает профили метаданных зашифрованных потоков трафика размер пакетов, временные промежутки между пакетами и многое другое. Затем метаданные экспортируются в записях NetFlow v9 в Cisco Stealthwatch.

Ключевой функцией Stealthwatch является постоянный мониторинг трафика, а также создание базовых показателей штатной сетевой активности. С помощью метаданных зашифрованного потока, отправленных ему ETA, Stealthwatch применяет многоуровневое машинное обучение для выявления поведенческих аномалий трафика, которые могут указывать на подозрительные события.

В прошлом году компания Cisco привлекла Miercom для независимой оценки решения Cisco Encrypted Traffic Analytics. В ходе этой оценки Miercom отдельно отправлял известные и неизвестные угрозы (вирусы, трояны, программы-вымогатели) в зашифрованном и незашифрованном трафике через крупные ETA и не-ETA сети, чтобы определить угрозы.

Для тестирования был запущен вредоносный код в обеих сетях. В обоих случаях подозрительная активность постепенно обнаруживалась. В ETA-сети на начальном этапе угрозы обнаруживались на 36% быстрее, чем в не-ETA сети. При этом по ходу работы продуктивность обнаружения в ETA-сети стала увеличиваться. В итоге после нескольких часов работы в ETA-сети были успешно обнаружены две трети активных угроз, что вдвое больше аналогичного показателя в не-ETA-сети.

Функционал ETA хорошо интегрирован со Stealthwatch. Угрозы ранжируются по степени серьезности, отображаются с подробной информацией, а также с вариантами действий по исправлению после подтверждения. Вывод ETA работает!

Обнаружение и предотвращение вторжений

Сейчас у Cisco есть еще один эффективный инструмент для обеспечения безопасности Cisco Advanced Wireless Intrusion Prevention System (aWIPS): механизм обнаружения и предотвращения угроз для беспроводных сетей. Решение aWIPS работает на уровне контроллеров, точек доступа и ПО управления Cisco DNA Center. Процесс обнаружения, оповещения и предотвращения угроз объединяет в себе анализ сетевого трафика, информацию о сетевых устройствах и сетевой топологии, методы на основе сигнатур и обнаружение аномалий, что в итоге обеспечивает высокую точность и предотвращение угроз беспроводной сети.

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

Средства аутентификации

На данный момент кроме классических средств аутентификации в решениях Cisco Catalyst серии 9800 доступна поддержка WPA3. WPA3 это последняя версия WPA, представляющая собой набор протоколов и технологий, обеспечивающих аутентификацию и шифрование для сетей Wi-Fi.

WPA3 использует метод одновременной аутентификации равноправных элементов (SAE Simultaneous Authentication of Equals) для обеспечения наиболее надежной защиты пользователей от попыток подбора пароля третьими лицами. Когда клиент подключается к точке доступа, он выполняет обмен SAE. В случае успеха каждый из них создаст криптографически надежный ключ, из которого будет получен ключ сеанса, а далее они переходят в состояние подтверждения. После этого клиент и точка доступа могут переходить в состояния подтверждения каждый раз, когда требуется сгенерировать ключ сеанса. Метод использует прямую секретность, при которой злоумышленник может взломать один ключ, но не все другие ключи.

То есть SAE построен таким образом, что у злоумышленника, перехватывающего трафик, есть только одна попытка угадать пароль, прежде чем перехваченные данные станут бесполезны. Для организации длительного подбора пароля потребуется физический доступ к точке доступа.

Средства защиты клиентских устройств

Основным средством защиты клиентов в беспроводных решениях Cisco Catalyst серии 9800 в настоящее время является Cisco Umbrella WLAN облачная служба сетевой безопасности, работающая на уровне DNS с автоматическим обнаружением как известных, так и новых угроз.

Cisco Umbrella WLAN обеспечивает клиентским устройствам защищенное подключение к Интернету. Это достигается с помощью фильтрации контента, то есть с помощью блокировки доступа к ресурсам в сети Интернет в соответствии с политикой предприятия. Таким образом, выполняется защита клиентских устройств в интернете от вредоносного ПО, программ-вымогателей, фишинга. Применение политик основано на 60-ти непрерывно обновляемых категориях контента.

Автоматизация

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

Для решения этих задач в беспроводных контроллерах Cisco Catalyst серии 9800 наряду с традиционным API предусмотрена поддержка протокола конфигурации сети RESTCONF / NETCONF с языком моделирования данных YANG (Yet Another Next Generation).

NETCONF это протокол на основе XML, который приложения могут использовать для запроса информации и изменения конфигурации сетевых устройств, таких, как беспроводные контроллеры.

В дополнение к этим методам в контроллерах Cisco Catalyst серии 9800 реализована возможность получения, выборки и анализа данных о потоке информации с помощью протокола NetFlow и sFlow.

Для обеспечения безопасности и для моделирования трафика возможность отслеживать конкретные потоки является ценным инструментом. Для решения этой задачи был реализован протокол sFlow, который позволяет захватывать два пакета из каждых ста. Однако иногда этого может быть недостаточно для анализа и адекватного изучения и оценки потока. Поэтому альтернативой является NetFlow, реализованный компанией Cisco, который позволяет на 100% собирать и экспортировать все пакеты в указанном потоке для последующего анализа.

Еще одной функцией, правда, доступной только в аппаратной реализации контроллеров, которая позволяет автоматизировать работу беспроводной сети в контроллерах Cisco Catalyst серии 9800, является встроенная поддержка языка Python в качестве надстройки для использования скриптов прямо на самом беспроводном контроллере.

И, наконец, для операций мониторинга и управления в контроллерах Cisco Catalyst серии 9800 поддерживается проверенный временем протокол SNMP версий 1, 2 и 3.

Таким образом, в ключе автоматизации решения Cisco Catalyst серии 9800 полностью отвечают современным требованиям бизнеса, предлагая как новые и уникальные, так и проверенные временем инструменты для автоматизированного выполнения операций и аналитики в беспроводных сетях любого размера и сложности.

Заключение

В решениях на базе контроллеров Cisco Catalyst серии 9800 компания Cisco продемонстрировала отличные результаты в категориях: высокая доступность, безопасность и автоматизация.

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

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

Для автоматизации операций и аналитики решения Cisco Catalyst серии 9800 обладают широкими возможностями, используя популярные стандартные модели: YANG, NETCONF, RESTCONF, традиционные API-интерфейсы и встроенные скрипты Python.

Таким образом компания Cisco в очередной раз подтверждает свой статус ведущего мирового производителя сетевых решений, идущего в ногу со временем и учитывающего все вызовы современного бизнеса.

Подробнее ознакомиться с информацией о семействе коммутаторов Catalyst можно на сайте Cisco.