Network: SDN (Cisco ACI, Cisco DNA, VXLAN, Open/Juniper Contrail)

SDN – Software Defined Networking

Ни для кого не секрет, что оверлейная сеть, обеспечивающая мультитенантностьYandex.Cloud, реализована на OpenContrail (ныне Tungsten Fabric). Он, в свою очередь, требует IPv4-связно
  • На Cisco devnet сайте можно поизучать устройство и примеры работы с API разных продуктов Cisco и даже поделать различные лабы (пример с Cisco DNA)!
  • Хорошо скоординированный static = SDN
  • Концепция SDN подразумевает:
      • в первую очередь разделение control/management plane (vm/hardware controller/etc) и data plane (bare-metal/vm) на разные устройства
      • отказ обработки трафика box-by-box в пользу создания SDN фабрики – каждая “коробка” теперь сама не решает, как обрабатывать трафик
      • перенос control/management plane на централизованный контроллер управления сетью
      • потенциально лучшая безопасность:
        • микросегментация на уровне VM или даже контейнеров
        • легче поддерживать консистентность политик
        • проще организовать полную видимость сети
      • управление решением через API
      • легко – централизованно, удобно (без cli) и масштабируемо

SDN во многом является ответом на следующие вопросы:

  1. Все больше приложений/бизнес требуют все более быстрый (деплой и работу), качественный (ошибки конфигурации) и безопасный сетевой сервис (консистентность конфигурации)
  2. Сетевые сервисы меняются: добавляются новые протоколы и функции, сеть переносится из datacenters в облака и проч; все это нужно поддерживать с учетом первого пункта
Networking functions such as routing, optimization, and security have changed.

Примеры SDN контроллеров.

Концепция sdn очень широка и разные решения зачастую нацелены на разные вещи. Примеры SDN решений:
      • Cisco DNA (скрин DNA). Подробнее ниже.
Contiv is a powerful, 100% open source networking solution for modern compute workloads. Integration and support for VM’s and Bare Metal allow you to provide a single network fabric across your infrastructure.
      • Open vSwitch (OvS) и Open Virtual Network (OVN)
        • OVS это open source реализация multilayer виртуального коммутатора внутри гипервизора. Можно скачать open vswitch оффициального сайта openvswitch.org и играться с ним на основе документации на этом же сайта
        • OVN был изначально создан людьми из OVS для решения задачи создания open source решения для виртуальных сетей и SDN.
- OVN was originally created by the folks behind OVS for the purpose of bringing an open source solution for virtual network environments and SDN.
- Open vSwitch is an open source implementation of a multilayer virtual switch inside the hypervisor.

  • Opendaylight (ODL) – популярный SDN проект, который фокусируется на улучшении SDN контроллеров для предоставления сетевых сервисов используя оборудование различных вендоров. Подробнее можно почитать как на сайте opendaylight.org, так и на Cisco devnet.

 

 

Контроллеры имеют обычно два api интерфейса:

  • Northbound/intent based api – для интеграции с внешними системами и приложениями. Обычно это другой вендор, а не вендор, реализующий контроллер. Например – приложение запрашивает ресурсы у контроллера sdn через northbound api, а контроллер обеспечивает их. Это называется intent-based networking или intent-based api. Подробнее об этом ниже в Cisco DNA (business intent).
  • Southbound api (openflow, cisco opflex) – для управления устройствами, подключенными к контроллеру. Обычно этими устройствами являются устройства того же вендора, что и контроллер.
vxlan
  • Vxlan – virtual extensible lan
  • Vxlan обычно (если не настроить другое) работает на udp порту 4789
  • Vxlan использует идентификатор локального L2 сегмента в виде VXLAN network identifier (VNI/VNID)
  • Логический сегмент, идентифицируемый с VNID является бродкаст доменом, который туннелируется поверх vxlan tunnel endpoint (VTEP) туннелей.
  • Использование udp в vxlan позволяет роутерам применять операцию хеширования на внешний udp заголовок (т.е. на заголовок добавленный vxlan) для балансировки сетевого трафика по ECMP. В итоге:
      • сетевой трафик, передаваемый по overlay network туннелям балансируется на множество линков с использованием ECMP
      • есть возможность сделать балансировку (выше) и отказоустойчивость на l3 для l2 трафика, с явными преимуществами в сравнении с l2 решениями по типу stp и erps

 

OpenStack Neutron
Neutron от openstack – открытое решение, которое реализует SDN с микросегментацией. Neutron построен по принципу предоставлению сетевых ресурсов как сервиса в облачных структурах (частные, гибридные, открытые облака). Другие компоненты openstack, типо horizon (web ui), nova (compute service) взаимодействуют с neutron через api.
cisco aci

Cisco ACI (Application Centric Infrastructure) – позволяет организациям автоматически назначить endpoints к логическим security zones которые называют endpoint groups (EPG). EPG используются для группировки VM внутри tenant и применения политик/фильтров передачи (forwarding policies) к ним. Эти EPG основаны на разных network based и vm based атрибутах.

Cisco ACI имеет одну из лучших реализацией microsegmentation. Microsegmentation в cisco ACI может быть реализована с помощью интеграции с vCenter, microsoft system center VMM (virtual machine manager).

Микросегментация в ACI так же зачастую называется uSeg EPG. Можно объдинить endpoints и существующие application EPG в новый microsegment uSeg EPG. Далее сконфигурировать network/VM based атрибуты для данного uSeg EPG. К данному uSeg EPG можно применить динамические политики. Так же можно применить политики к любому endpoint внутри tenant. Например, вам нужно назначить WEB сервер в EPG и затем применить похожие настройки. По умолчанию все endpoint внутри EPG могу взаимодействовать с друг другом, но если вам нужно – вы можете это ограничить (напр. EPG состоит из production &  development серверов) . Для реализации этого ограничения нужно создать новый EPG и назначить к нему endpoints на основе атрибута имени VM (prod*, dev*).

Применение атрибутов к uSeg EPG позволяет вам применить forwarding/security политики с большей гранулярностью чем при использовании EPG без атрибутов. Атрибуты уникальны внутри tenant. Вы можете применить uSeg EPG используя два типа атрибутов

    • сетевые атрибуты (IP, IP/MAC address filter). Одному uSeg EPG можно сопоставить один или несколько MAC/IP адресов.
    • атрибуты VM. Одному uSeg EPG можно сопоставить несколько VM based атрибутов (тип ОС, VMM, domain, hypervisor ID, datacenter, VM ID, VM name, vnic domain name, custom attributes/TAGs).
aci APIC

APIC контроллер – мозги всей SDN фабрики ACI, отвечает за деплой политик/конфигурации фабрики Cisco ACI. APIC так же:

    • управляет топологией ACI pod (ACI fabric nodes)
    • владеет инвентарной информацией всех устройств ACI pod
    • осуществляет мониторинг всего ACI pod
    • осуществляет обновление ПО всех элементов ACI pod (leaf, spine, apic)
    • управление кластером из нескольких APIC
    • взаимодействует с hypervisor (напр. VMware vCenter), напр. для идентификации endpoint в виде VM
    • управляет и сохраняет все события ACI pod
    • сохраняет информацию о самом APIC  – inventory, state
Cisco DNA
Cisco DNA – digital network architecture.  DNA рассматривается как intent-based networking. DNA предоставляет сервисы автоматизации политик, валидации, аналитики в кампусных/branch/wan сетях. Решение основано на открытой и масштабируемой платформе.
DNA Controller (DNAС) – является  ядром решения DNA, которое обеспечивает централизованное управление.

Политики Cisco DNA могут быть:
  • Group base ACL (GBAC, group based access control) – для их работы требуется интеграция cisco DNA с cisco ISE с конфигурацией Single Matrix. Созданные группы на ISE в итоге передаются на DNA и могут использоваться им для конфигураций. Для большей сегментации в крупных инсталляциях при необходимости (access requirements) можно разделить группы на несколько виртуальных сетей.
  • IP base ACL – политики для сетевого трафика на основе адресов IP и направления (bi/uni-direction)
  • Access Contract – политики для сетевого трафика на основе протокола/порта
  • Application ACL – глубокая инспекция DPI и реализация QoS. Приложения можно забиндить в группы и к группам можно принимать политики. Приложения и группы можно привязывать к QoS traffic classes (RFC 4594).
  • Traffic copy ACL – в DNA center можно создать политику, которая реализует копирование ERSPAN потока IP трафика между двумя хостами до заданного назначения для задач мониторинга/траблшутинга/безопасности.
Assurance/monitoring сервисы позволяют настраивать сенсоры для мониторинга здоровья компонентов, например, беспроводных сетей (конфигурация AP, WLAN).
Сенсоры WLAN бывают двух видов:
  • Выделенные – AP работает только как сенсор и не используется клиентами.
  • Сенсоры по требованию – AP временно превращается в сенсор для проведения тестов, после тестов AP выводится из режима сенсора.
A dedicated sensor is when an AP is converted into a sensor, and it stays in sensor mode (is not used by wireless clients) unless it is manually converted back into AP mode.

An on-demand sensor is when an AP is temporarily converted into a sensor to run tests. After the tests are complete, the sensor goes back to AP mode.
Northbound rest API в DNA очень прокаченный, называют его intent-based API. Называют его так потому, что за политиками скрываются (policy based abstraction of business intent) конкретные бизнес задачи. А централизованная настройка через api дает тебе консистентность, которая, в свою очередь, ведет к лучшей безопасности.
Безопасность SDN, SDN SECURITY
SDN Firewall MICROSEGMENTATION, MACHINE TO MACHINE

Большая часть трафика в существующих ДЦ – это east-west, а не north-south. Он не выходит за периметр сети и файрвол на периметре, а зачастую даже и физический сервер (трафик между VM или даже контейнерами на одном гипервизоре или виртуальной машине).
Многие вендоры создали файрволы, в которых политики применяются на приложения, а сами файрволы независимы от топологии сети, направления сетевого трафика (north-south, east-west).
К примеру, может быть потребность во взаимодействии между приложением в vm1 и vm3, между vm2 и vm3.
При этом взаимодействие между приложением vm2 и vm3 должно быть запрещено.

Запрещение же это должно быть реализовано масштабируемо – не в виде router on a stick к какому то центральному firewall. Решениями прошлого считаются выделенные файрволы между VM/контейнерами.
Нельзя так же использовать vlan, subnet т.к. по факту это ненадежные идентификаторы в масштабируемых топологиях с динамическим назначением vlan/subnet.
Сильным усложнением являются контейнеры, которые нуждаются в аналогичных сервисах микросегментации в рамках одной хостовой машины.

Традиционная сегментация с vlan ограничена границами vlan в пределах дата центра или даже кампуса ((спорное утверждение – eoip, l2vpn, xconnect, vpls, l2tp v3 и проч. помогают пробрасывать vlan’ы в том или ином виде уже десятки лет)).

Traditional segmentation using VLANs introduces a lot of complexities. Application segmentation and policies were physically restricted to the boundaries of the VLAN within the same data center (or even in “the campus”).
В виртуальной среде проблема стала острой – сейчас приложения могут мигрировать между серверами в разных ДЦ.
Микросегментация может быть как на уровне vm, так и на уровне контейнеров. Микросегментация должен быть завязана (начинаться и заканчиваться приложением) на приложение, а не сетевые индикаторы (network, vlan id).
Micro-segmentation must be "application-aware".
Так же в контексте микросегментации часто применяется концепция zero trust – не доверяем ничему и не разрешаем ничего (доступ к ресурсам, работу юзера с приложением, работу приложения с приложением), пока
  • мы не поймем, с кем имеем дело
  • мы, пока нет явного правила, разрешающего взаимодействие

И даже после разрешения мы постоянно проверяем трафик/поведение/состояние объектов, чтобы определить, что “доверие не потеряно”.

Примеры атак на SDN и методы защиты от них
Примеры угроз SDN:
  1. установка «левого» контроллера (malicious controller) для управления sdn устройствами и сервисами
  2. Man in the middle атаки между SDN контроллером и SDN устройствами для снифинга/изменения/подмены инструкций, отправляемых контроллером
  3. Атаки на доступность SDN контроллера (DoS, DDoS)
Способы защиты от подобных атак (все реализовано в Cisco DNA):
  1. Контроллер должен находиться в безопасном месте с контролем доступа (СКУД)
  2. Путь данных и управления должен быть разнесен (out of band management)
  3. Безопасность при использовании API
  4. Безопасность взаимодействия контроллера и устройств, которыми он управляет (в том числе API security)
  5. Patch management
  6. Использование шифрования

Leave a Reply