VMware NSX для самых маленьких. Часть 1
О новых функциях в vCloud Director, которые упростят жизнь сетевикам и безопасникам.
Если посмотреть конфиг любого файрвола, то, скорее всего, мы увидим простыню с кучей IP-адресов, портов, протоколов и подсетей. Так классически реализуются политики сетевой безопасности для доступа пользователей к ресурсам. Сначала в конфиге стараются поддерживать порядок, но потом сотрудники начинают переходить из отдела в отдел, сервера размножаться и менять свои роли, появляются доступы для разных проектов туда, куда им обычно нельзя, и получаются сотни неизвестных козьих тропок.
Около каких-то правил, если повезет, прописаны комментарии «Попросил сделать Вася» или «Это проход в DMZ». Сетевой администратор увольняется, и все становится совсем непонятно. Потом кто-то решил почистить конфиг от Васи, и упал SAP, потому что когда-то Вася просил этот доступ для работы боевого SAP.
Сегодня я расскажу про решение VMware NSX, которое помогает точечно применять политики сетевого взаимодействия и безопасности без неразберихи в конфигах файрвола. Покажу, какие новые функции появились по сравнению с тем, что было раньше у VMware в этой части.
VMWare NSX – платформа виртуализации и обеспечения безопасности сетевых сервисов. NSX решает задачи маршрутизации, коммутации, балансировки нагрузки, файрвола и умеет много другого интересного.
NSX – это преемник собственного продукта VMware vCloud Networking and Security (vCNS) и приобретенного Nicira NVP.
От vCNS к NSX
Раньше у клиента в облаке, построенном на VMware vCloud, была отдельная виртуальная машина vCNS vShield Edge. Он выполнял роль пограничного шлюза, где можно было настроить множество сетевых функций: NAT, DHCP, Firewall, VPN, балансировщика нагрузки и пр. vShield Edge ограничивал взаимодействие виртуальной машины с внешним миром согласно правилам, прописанным в Firewall и NAT. Внутри сети виртуальные машины общались между собой свободно в пределах подсетей. Если очень хочется разделять и властвовать трафиком, можно сделать отдельную сеть для отдельных частей приложений (разных виртуальных машин) и прописать в файрволе соответствующие правила по их сетевому взаимодействию. Но это долго, сложно и неинтересно, особенно когда у вас несколько десятков виртуальных машин.
В NSX VMware реализовала концепцию микросегментации с помощью распределенного файрвола (distributed firewall), встроенного в ядро гипервизора. В нем прописываются политики безопасности и сетевого взаимодействия не только для IP- и MAC-адресов, но и для других объектов: виртуальных машин, приложений. Если NSX развернут внутри организации, то такими объектами могут стать пользователь или группа пользователей из Active Directory. Каждый такой объект превращается в микросегмент в своем контуре безопасности, в нужной подсети, со своей уютненькой DMZ :).
Раньше периметр безопасности был один на весь пул ресурсов, защищался пограничным коммутатором, а с NSX можно оградить от лишних взаимодействий отдельную виртуальную машину даже в пределах одной сети
Политики безопасности и сетевого взаимодействия адаптируются, если объект переезжает в другую сеть. Например, если мы перенесем машину с базой данных в другой сетевой сегмент или даже в другой связанный виртуальный дата-центр, то правила, прописанные для этой виртуальной машины, продолжат действовать безотносительно ее нового положения. Сервер приложений по-прежнему сможет взаимодействовать с базой данных.
На смену самому пограничному шлюзу vCNS vShield Edge пришел NSX Edge. У него есть весь джентльменский набор старого Edge плюс несколько новых полезных функций. Про них и пойдет речь дальше.
Что нового у NSX Edge?
Функциональность NSX Edge зависит от редакции NSX. Всего их пять: Standard, Professional, Advanced, Enterprise, Plus Remote Branch Office. Все новое и интересное можно увидеть только начиная с Advanced. В том числе и новый интерфейс, который до полного перехода vCloud на HTML5 (VMware обещает лето 2019-го) открывается в новой вкладке.
Firewall. В качестве объектов, к которым будут применяться правила, можно выбрать IP-адреса, сети, интерфейсы шлюза и виртуальные машины.
DHCP. Помимо настройки диапазона IP-адресов, которые будут автоматически выдаваться виртуальным машинам этой сети, в NSX Edge стали доступны функции Binding и Relay.
Во вкладке Bindings можно привязать MAC-адрес виртуальной машины к IP-адресу, если нужно чтобы IP-адрес не менялся. Главное, чтобы этот IP-адрес не входил в DHCP Pool.
Во вкладке Relay настраивается ретрансляция DHCP-сообщений DHCP-серверам, которые находятся за пределами вашей организации в vCloud Director, в том числе и DHCP-серверам физической инфраструктуры.
Маршрутизация. У vShield Edge можно было настраивать только статическую маршрутизацию. Здесь появилась динамическая маршрутизация с поддержкой протоколов OSPF и BGP. Также стали доступны настройки ECMP (Active-active), а значит и аварийное переключение типа «активный-активный» на физические маршрутизаторы.
Настройка OSPF
Настройка BGP
Еще из нового – настройка передачи маршрутов между различными протоколами, перераспределение маршрутов (route redistribution).
L4/L7 Балансировщик нагрузки. Появился X-Forwarded-For для заголовка HTTPs. Без него все плакали. Например, у вас есть сайт, который вы балансируете. Без проброса этого заголовка все работает, но в статистике веб-сервера вы видели не IP посетителей, а IP балансировщика. Теперь все стало правильно.
Также во вкладке Application Rules теперь можно добавлять скрипты, которые будут напрямую управлять балансировкой трафика.
VPN. В дополнение к IPSec VPN, NSX Edge поддерживает:
SSL-сертификаты. На NSX Edge теперь можно поставить сертификаты. Это снова к вопросу, кому нужен был балансировщик без сертификата для https.
Группы объектов (Grouping Objects). В этой вкладке как раз задаются группы объектов, для которых будут действовать те или иные правила сетевого взаимодействия, например правила файрвола.
Этими объектами могут быть IP- и MAC-адреса.
Здесь также указан список сервисов (сочетание протокол-порт) и приложений, которые можно использовать при составлении правил файрвола. Новые сервисы и приложения добавлять может только администратор портала vCD.
Статистика. Статистика по подключениям: трафик, который проходит через шлюз, файрвол и балансировщик.
Статус и статистику по каждому туннелю IPSEC VPN и L2 VPN.
Логирование. Во вкладке Edge Settings можно задать сервер для записи логов. Логирование работает для DNAT/SNAT, DHCP, Firewall, маршрутизации, балансировщика, IPsec VPN, SSL VPN Plus.
Для каждого объекта/сервиса доступны следующие типы оповещений:
Размеры NSX Edge
В зависимости от решаемых задач и объемов VMware рекомендует создавать NSX Edge следующих размеров:
| NSX Edge (Compact) | NSX Edge (Large) | NSX Edge (Quad-Large) | NSX Edge (X-Large) | |
|---|---|---|---|---|
| vCPU | 1 | 2 | 4 | 6 |
| Memory | 512MB | 1GB | 1GB | 8GB |
| Disk | 512MB | 512MB | 512MB | 4.5GB + 4GB |
| Назначение | Одно приложение, тестовый дата-центр | Небольшой или средний дата-центр | Нагруженный файрвол | Балансировка нагрузки на уровне L7 |
Ниже в таблице – рабочие метрики сетевых служб в зависимости от размера NSX Edge.
| NSX Edge (Compact) | NSX Edge (Large) | NSX Edge (Quad-Large) | NSX Edge (X-Large) | |
|---|---|---|---|---|
| Interfaces | 10 | 10 | 10 | 10 |
| Sub Interfaces (Trunk) | 200 | 200 | 200 | 200 |
| NAT Rules | 2,048 | 4,096 | 4,096 | 8,192 |
| ARP Entries Until Overwrite | 1,024 | 2,048 | 2,048 | 2,048 |
| FW Rules | 2000 | 2000 | 2000 | 2000 |
| FW Performance | 3Gbps | 9.7Gbps | 9.7Gbps | 9.7Gbps |
| DHCP Pools | 20,000 | 20,000 | 20,000 | 20,000 |
| ECMP Paths | 8 | 8 | 8 | 8 |
| Static Routes | 2,048 | 2,048 | 2,048 | 2,048 |
| LB Pools | 64 | 64 | 64 | 1,024 |
| LB Virtual Servers | 64 | 64 | 64 | 1,024 |
| LB Server / Pool | 32 | 32 | 32 | 32 |
| LB Health Checks | 320 | 320 | 320 | 3,072 |
| LB Application Rules | 4,096 | 4,096 | 4,096 | 4,096 |
| L2VPN Clients Hub to Spoke | 5 | 5 | 5 | 5 |
| L2VPN Networks per Client/Server | 200 | 200 | 200 | 200 |
| IPSec Tunnels | 512 | 1,600 | 4,096 | 6,000 |
| SSLVPN Tunnels | 50 | 100 | 100 | 1,000 |
| SSLVPN Private Networks | 16 | 16 | 16 | 16 |
| Concurrent Sessions | 64,000 | 1,000,000 | 1,000,000 | 1,000,000 |
| Sessions/Second | 8,000 | 50,000 | 50,000 | 50,000 |
| LB Throughput L7 Proxy) | 2.2Gbps | 2.2Gbps | 3Gbps | |
| LB Throughput L4 Mode) | 6Gbps | 6Gbps | 6Gbps | |
| LB Connections/s (L7 Proxy) | 46,000 | 50,000 | 50,000 | |
| LB Concurrent Connections (L7 Proxy) | 8,000 | 60,000 | 60,000 | |
| LB Connections/s (L4 Mode) | 50,000 | 50,000 | 50,000 | |
| LB Concurrent Connections (L4 Mode) | 600,000 | 1,000,000 | 1,000,000 | |
| BGP Routes | 20,000 | 50,000 | 250,000 | 250,000 |
| BGP Neighbors | 10 | 20 | 100 | 100 |
| BGP Routes Redistributed | No Limit | No Limit | No Limit | No Limit |
| OSPF Routes | 20,000 | 50,000 | 100,000 | 100,000 |
| OSPF LSA Entries Max 750 Type-1 | 20,000 | 50,000 | 100,000 | 100,000 |
| OSPF Adjacencies | 10 | 20 | 40 | 40 |
| OSPF Routes Redistributed | 2000 | 5000 | 20,000 | 20,000 |
| Total Routes | 20,000 | 50,000 | 250,000 | 250,000 |
Из таблицы видно, что балансировку на NSX Edge для продуктивных сценариев рекомендуется организовывать, только начиная с размера Large.
На сегодня у меня все. В следующих частях подробно пройдусь по настройке каждой сетевой службы NSX Edge.
Если не хватает NSX Edge: как клиенты нашего облака переезжают в сервис NGFW
Когда клиент размещает свой сайт, почту или другой сервис в нашем облаке на базе VMware, то в 90% случаев в качестве граничного устройства используется виртуальный маршрутизатор NSX Edge. Это решение выполняет для виртуального дата-центра функции межсетевого экрана, NAT, DHCP, VPN и так далее.
Но если, например, клиент привык получать на межсетевом экране расширенную аналитику по трафику и более детальный мониторинг, то в облаке ему может понадобиться межсетевой экран нового поколения (Next Generation Firewall, NGFW). К тому же, такие решения предоставляют модули IPS и IDS, антивирус и другие фишки. Для клиентов c такими запросами в качестве одного из решений мы предлагаем NGFW как сервис на базе FortiGate. В статье покажу, как и для чего мы организуем переезд в этот сервис.
Когда стоит рассмотреть NGFW как сервис
Чаще всего наши клиенты рассматривают альтернативы NSX Edge, если на уровне межсетевого экрана нужно решать дополнительные задачи:
обнаруживать и предотвращать вторжения ― с помощью модулей IPS и IDS;
обеспечивать дополнительную антивирусную защиту;
контролировать приложения, которые используют сотрудники на рабочих местах в облаке;
интегрировать политики безопасности с каталогами AD и IDM;
отслеживать и расследовать сложные атаки и инциденты с помощью продвинутой аналитики.
Вместо сервиса можно выбрать и приватное решение ― закупить виртуальные или физические ресурсы в частное облако под нужды заказчика. К примеру, частное решение разворачивается, если нужен межсетевой экран, сертифицированный по требованиям ФСТЭК. Но у частного варианта есть минус: если проект живет в приватном облаке долго, рано или поздно может возникнуть проблема сайзинга. Например, мы закупили для проекта заказчика межсетевые экраны с небольшим запасом, под этот объем закупили лицензии. Через несколько лет трафик вырос сильнее ожидаемого. Заказчик захотел расширить пропускную способность и уперся в пакетную политику лицензирования вендора: докупить ровно необходимое количество лицензий было нельзя.
NGFW как сервис позволяет избежать проблем с сайзингом, если предсказать рост пропускной способности нельзя. В этом случае заказчику на одном из межсетевых экранов предоставляются выделенные сетевые сегменты ― виртуальные домены (VDOM’ы). Трафик предоставляется по принципу Pay-as-you-go: заказчик платит только за ту пропускную способность, которую потребил на виртуальном домене. Количество VDOM’ов можно увеличивать: в сервисе за это отвечает сервис-провайдер, заказчику достаточно сформулировать запрос.
Вот как упрощенно выглядит сегментация:
Это же решение используется и в составе сервиса виртуальных рабочих столов.
Еще одна причина для перехода на NGFW как сервис ― желание заказчика отдать администрирование на сторону. Настройка таких межсетевых экранов требует знания нюансов конкретного вендора, и не у каждого заказчика есть специалисты нужного профиля. В сервисе с администрированием заказчику не нужно самому настраивать правила и анализировать трафик и срабатывания: этим занимается сервис-провайдер. При необходимости заказчик может поправить свою политику доступа или создать NAT ― преобразование сетевых адресов.
Как происходит переезд
При переезде из NSX Edge есть один нюанс: у клиента поменяется внешняя адресация. Мы заранее предупреждаем об этом клиента и затем идем пошагово по нашему плану.
Перенос «как есть». На первом этапе вся защита переносится в том виде, в котором ее настроил заказчик.
Общаемся с клиентом, выясняем его задачи и уточняем, какие модули NGFW нужны.
Запрашиваем у клиента необходимую информацию:
как сегментирована сеть,
какие VLAN’ы используются,
какие типы сетей: routed, isolated,
как клиент выходит в интернет,
какая полоса пропускания,
как все мониторится,
какие NAT-трансляции используются.
Так мы выстраиваем архитектуру будущего решения.
Запрашиваем конфигурацию с оборудования заказчика либо просим доступ к Edge, чтобы выгрузить конфигурацию самим.
Анализируем конфигурацию и заводим сети клиентов: создаем отдельный VDOM на FortiGate и подаем туда VLAN’ы.
Переносим все правила доступа со старого оборудования.
Создаем NAT-трансляции с новыми адресами, составляем IP-план и отправляем его клиенту.
Согласовываем время даунтайма во время миграции. Общее время зависит от количества VLAN’ов.
Переводим трафик с минимальным простоем. Чаще всего делаем это ночью, чтобы влияние переезда было минимальным. Тушим интерфейс на Edge и поднимаем интерфейс с таким же адресом на FortiGate. Параллельно с этим клиент меняет DNS. На каждый VLAN достаточно несколько минут.
Если в этом процессе возникнет какая-то проблема, мы сможем откатиться назад за пару минут.
Оптимизация. После переноса мы мониторим активность, наблюдаем за трафиком и собираем аналитику. Через неделю анализируем работу правил и проверяем их корректность. Какие-то могут оказаться слишком широкими или слишком узкими, они могут затенять друг друга. Если видим какие-то неработающие правила, обсуждаем с клиентом и при необходимости выключаем или корректируем их.
Тут видим, что для выбранного правила трафика вообще нет.
Включение модулей безопасности. Здесь мы настраиваем модули NGFW: IPS, контроль приложений, антивирус, ― всю работу делаем в тесной связке с клиентом. Сначала мы создаем профили безопасности в режиме мониторинга и только наблюдаем за срабатываниями, но не блокируем их. Например, у нас начал срабатывать модуль IPS. Сначала мы смотрим, что это за трафик, и сообщаем клиенту. Решение принимаем совместно: блокировать такие срабатывания, или это легитимный трафик и срабатывание оказалось ложным. Только после совместного обсуждения включаем правила в режиме блокировки.
Так выглядит топ критичных угроз за семь дней в модуле IPS.
Как решаются особые кейсы NGFW+
Иногда NGFW как сервис становится частью комплексного решения, к которому мы подключаем другие модули:
система управления журналами безопасности,
сервис защиты веб-приложений (WAF),
Кратко расскажу, как эти решения работают совместно.
Журналы событий FortiAnalyzer вместе с NGFW помогают видеть более детальную картину трафика. Например, есть модуль индикаторов компрометации: мы видим, что какие-то хосты ломятся на скомпрометированные IP-адреса. Этот трафик блокируется, а хосты мы проверяем антивирусом.
Отдельной политикой на NGFW можно настроить передачу трафика по syslog’у в клиентскую SIEM-систему. Или можем просто передавать журналы в клиентский лог-коллектор через IPsec.
FortiAnalyzer также помогает организовать долговременное хранение журналов.
Дополнительный VPN-шлюз для доступа к внутренней инфраструктуре можно настроить с помощью FortiClient VPN. Это средство для защиты конечных точек (endpoint-защиты). С его помощью доступ на удаленный сервер настраивается определенным группам пользователей.
WAF совместно с NGFW позволяет вести на межсетевой экран уже очищенный трафик. Мы уже рассказывали, как устроен наш комплексный WAF как сервис и как мы предусмотрели в нем дополнительную защиту от DDoS и сканирование. С подключением NGFW его схема будет выглядеть так:
Клиентам с WAF мы рекомендуем ограничивать на межсетевом экране доступ к сайтам только с адресов WAF. NGFW в этой связке работает в режиме explicit proxy: запрещено все, что не разрешено.
Разрешен только трафик с WAF.
WAF в такой схеме отбивает все, что связано с вебом. NGFW работает и на вход, и на выход: он также контролирует выход базы данных и веб-серверов за обновлениями. Также NGFW следит за взаимодействием внутренних серверов между собой: как один сегмент сети общается с другим. Даже если какой-то внутренний сервер заразится, то сегментация сети на NGFW не позволит заразе распространиться дальше.
Такие комплексные решения помогают нам в крупных и сложных проектах. Для заказчика они более выгодны и позволяют снять нагрузку с сотрудников.
Единственный случай, когда лучше выбрать комплексный сервис в виде частного решения, — необходимость сертификации NGFW или WAF по требованиям ФСТЭК. Администрировать такое решение тоже может сервис-провайдер, но это будет межсетевой экран или WAF под конкретного заказчика.
