Перейти к основному содержанию

VMware — отправляем SPAN трафик на виртуалку

VMware

Снова пилотный проект. ИБшники опять придумали зеркалировать SPAN трафик в анализатор трафика. Перед покупкой железа и софта нужно проверить, заработает ли вообще всё это дело. Поэтому зеркалировать трафик будем на виртуальную машину. Работаем в vCenter 7.

Ранее уже было что-то подобное, мы зеркалировали RSPAN:

VMware — отправляем RSPAN трафик на виртуалку

Сегодня у нас тип трафика другой — SPAN, и настройки будут немного другие.

Зеркалирование портов делается для анализа трафика. Раньше, когда вместо коммутаторов стояли обычные хабы, зеркалировать трафик было просто. Слушаешь всё на своём порту и видишь все пакеты. С появлением коммутаторов перехватить чужие пакеты стало сложнее, и анализировать трафик тоже стало сложнее. Вендоры решили эту проблему, разработав различные механизмы зеркалирования трафика. Функция Port Mirroring (зеркалирование портов) позволяет копировать кадры, принимаемые и/или отправляемые портом-источником или группой портов-источников на порт-получатель коммутатора, к которому подключен компьютер с установленным анализатором трафика.

Зеркалирование может быть локальным (в пределах одного коммутатора: SPAN — Switch Port Analyzer) или удалённым. При удалённом зеркалировании порт-источник и порт-получатель находятся на разных коммутаторах и мониторинг выполняется через коммутируемую сеть. Такой мониторинг называется RSPAN — Remote Switch Port Analyzer.

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

Подготовка гипервизора

Проект временный, но всё временное очень часто становится постоянным. Делать будем по-нормальному. На гипервизор, расположенный поближе к портам с зеркалируемым трафиком, устанавливаю дополнительную сетевую карту с SFP+ портами, свободные гигабитные порты там и так есть. По плану у нас трафик будет собираться с одного 10G порта и с двух 1G портов. Здесь есть узкое место, если трафик превысит 10G, то сетевая карта на виртуальной машине перестанет справляться. В этом случае систему придётся переделать на несколько распределённых коммутаторов и подавать трафик на несколько сетевых карт виртуалки, но это уже другая история, просто имеем в виду, что такой минус разворачивоемой системы имеется.

Подключаю патчкорды, ведущие к зеркальным портам коммутаторов. Линки есть.

Распределённый коммутатор

В кластере с целевым хостом создаю новый распределённый коммутатор.

vCenter 7 — создаём Distributed Switch

Передавать трафик на виртуальную машину можно и обычным локальным коммутатором. Я просто привык работать с распределёнными, да и потом может понадобиться перекинуть линки на какой-то другой гипервизор. В кластере Actions → Distributed Switch → New Distributed Switch...

vmware

Открывается мастер создания распределённого коммутатора. Указываю имя. Next.

span

Указываю версию коммутатора, выбираю 7.0.0. Next.

vmware

Количество аплинков — 3, у меня три порта. Network I/O Control — Enabled. Создаю порт-группу по умолчанию, назову её M1_SPAN. Next.

vmware

Finish.

vmware

Коммутатор создан. Настроим коммутатор. В свойствах коммутатора в разделе Advanced отключаем Discovery protocol. По умолчанию там стоит Cisco Discovery Protocol, может быть ещё Link Layer Discovery Protocol. CDP и LLDP нам не нужны, дело в том, что это только внесёт дополнительную путаницу, вместе со SPAN трафиком мы станем получать данные с зеркалируемых портов и будет видеть именно их, а не тот порт, к которому подключен кабель. На момент тестирования эту опцию можно оставить, увидим зеркальный трафик прямо в vCenter, благо у нас Cisco коммутаторы с CDP. Но потом этот протокол в нашем коммутаторе нужно отключить.

vmware

Двигаюсь дальше.

Настройка группы портов

Редактирую созданную ранее порт-группу M1_SPAN. Actions → Edit Settings.

vmware

Вкладка General. Port binding — Static binding. Port allocation — Fixed.

vmware

Вкладка Advanced. По умолчанию.

vmware

Вкладка VLAN. VLAN type — None. Напоминаю, что трафик у нас не тегированный, SPAN.

vmware

Вкладка Security. MAC address changes — Reject. Forged transmits — Reject. Promiscuous mode — Accept.

Promiscuous mode или promisc mode — так называемый "неразборчивый" режим, в котором сетевая плата позволяет принимать все пакеты независимо от того, кому они адресованы.

vmware

Вкладка Traffic shaping. По умолчанию.

vmware

Вкладка Teaming and failover. Активные аплинки — все три, это должно быть по умолчанию.

vmware

Вкладка Monitoring. По умолчанию.

vmware

Вкладка Miscellaneous. По умолчанию.

vmware

OK. Группа портов настроена.

Подключение гипервизора к распределённому коммутатору

Перехожу к нашему коммутатору, добавляю хост. Add and Manage Hosts...

vmware

Add hosts. Next.

vmware

Select hosts. + New hosts... Выбираю подготовленный ранее гипервизор. Next.

vmware

Теперь нужно прицепить сетевые адаптеры. Это у меня добавленные ранее vmnic2, vmnic3 и vmnic7. Привязываю их к аплинкам. Next.

vmware

Адаптер ядра не трогаю. Next.

vmware

Next.

vmware

Finish.

vmware

Гипервизор подключён к распределённому коммутатору.

vmware

Линки есть.

vmware

Если ранее мы не отключали CDP протокол, то в разделе физических адаптеров можно увидеть данные зеркалируемых портов.

Пускаем SPAN трафик на виртуальную машину

Создаю на подготовленном гипервизоре виртуальную машину нашего пилотного проекта. Накатываю ОС, настраиваю. На нужный сетевой адаптер подключаю сеть M1_SPAN, которую я создал на распределённом коммутаторе. OK.

vmware

Ииии....

span

Сенсор видит SPAN трафик.

Немного про SPAN

Зеркалирование мы настроили, это хорошо. Однако, при использовании SPAN, RSPAN или ERSPAN следует помнить, что технология SPAN не является масштабируемой. Если немного углубиться в историю, то мы увидим, что сама возможность зеркалирования трафика на определённый порт коммутатора изначально использовалась вендорами для тестирования своих устройств. Это уже потом появилась идея использовать эту фичу для целей информационной безопасности. Если вооружиться калькулятором, то легко можно посчитать, что ни один аплинк, на который зеркалируется трафик, не выдержит потока данных, генерируемых на всех портах коммутатора при большой нагрузке. А RSPAN создаст ещё большую нагрузку при передаче SPAN трафика.

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

Таким образом, использование SPAN трафика в вашей сети целесообразно только при невысокой общей сетевой нагрузке. При большой нагрузке уже имеет смысл смотреть в сторону TAP (Test Access Point) устройств типа оптических разветвителей. При этом TAP устройство создает полную 100% копию двунаправленного сетевого трафика.

TAP (Test Access Point) — это простое, преимущественно пассивное, устройство, которое напрямую подключается к кабельной инфраструктуре сети между двумя сетевыми устройствами. Весь трафик проходит через него. Используя внутренний физический (оптический) или логический (электрический) делитель, TAP ответвляет копию данных для мониторинга, в то время как исходные данные беспрепятственно передаются по сети.

 

Похожие материалы

VMware — отправляем RSPAN трафик на виртуалку

Пилотный проект. ИБшники придумали зеркалировать RSPAN трафик в анализатор трафика. Перед покупкой железа и софта нужно проверить, заработает ли вообще всё это дело. Поэтому зеркалировать трафик будем на виртуальную машину.