Снова пилотный проект. ИБшники опять придумали зеркалировать 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...
Открывается мастер создания распределённого коммутатора. Указываю имя. Next.
Указываю версию коммутатора, выбираю 7.0.0. Next.
Количество аплинков — 3, у меня три порта. Network I/O Control — Enabled. Создаю порт-группу по умолчанию, назову её M1_SPAN. Next.
Finish.
Коммутатор создан. Настроим коммутатор. В свойствах коммутатора в разделе Advanced отключаем Discovery protocol. По умолчанию там стоит Cisco Discovery Protocol, может быть ещё Link Layer Discovery Protocol. CDP и LLDP нам не нужны, дело в том, что это только внесёт дополнительную путаницу, вместе со SPAN трафиком мы станем получать данные с зеркалируемых портов и будет видеть именно их, а не тот порт, к которому подключен кабель. На момент тестирования эту опцию можно оставить, увидим зеркальный трафик прямо в vCenter, благо у нас Cisco коммутаторы с CDP. Но потом этот протокол в нашем коммутаторе нужно отключить.
Двигаюсь дальше.
Настройка группы портов
Редактирую созданную ранее порт-группу M1_SPAN. Actions → Edit Settings.
Вкладка General. Port binding — Static binding. Port allocation — Fixed.
Вкладка Advanced. По умолчанию.
Вкладка VLAN. VLAN type — None. Напоминаю, что трафик у нас не тегированный, SPAN.
Вкладка Security. MAC address changes — Reject. Forged transmits — Reject. Promiscuous mode — Accept.
Promiscuous mode или promisc mode — так называемый "неразборчивый" режим, в котором сетевая плата позволяет принимать все пакеты независимо от того, кому они адресованы.
Вкладка Traffic shaping. По умолчанию.
Вкладка Teaming and failover. Активные аплинки — все три, это должно быть по умолчанию.
Вкладка Monitoring. По умолчанию.
Вкладка Miscellaneous. По умолчанию.
OK. Группа портов настроена.
Подключение гипервизора к распределённому коммутатору
Перехожу к нашему коммутатору, добавляю хост. Add and Manage Hosts...
Add hosts. Next.
Select hosts. + New hosts... Выбираю подготовленный ранее гипервизор. Next.
Теперь нужно прицепить сетевые адаптеры. Это у меня добавленные ранее vmnic2, vmnic3 и vmnic7. Привязываю их к аплинкам. Next.
Адаптер ядра не трогаю. Next.
Next.
Finish.
Гипервизор подключён к распределённому коммутатору.
Линки есть.
Если ранее мы не отключали CDP протокол, то в разделе физических адаптеров можно увидеть данные зеркалируемых портов.
Пускаем SPAN трафик на виртуальную машину
Создаю на подготовленном гипервизоре виртуальную машину нашего пилотного проекта. Накатываю ОС, настраиваю. На нужный сетевой адаптер подключаю сеть M1_SPAN, которую я создал на распределённом коммутаторе. OK.
Ииии....
Сенсор видит SPAN трафик.
Немного про SPAN
Зеркалирование мы настроили, это хорошо. Однако, при использовании SPAN, RSPAN или ERSPAN следует помнить, что технология SPAN не является масштабируемой. Если немного углубиться в историю, то мы увидим, что сама возможность зеркалирования трафика на определённый порт коммутатора изначально использовалась вендорами для тестирования своих устройств. Это уже потом появилась идея использовать эту фичу для целей информационной безопасности. Если вооружиться калькулятором, то легко можно посчитать, что ни один аплинк, на который зеркалируется трафик, не выдержит потока данных, генерируемых на всех портах коммутатора при большой нагрузке. А RSPAN создаст ещё большую нагрузку при передаче SPAN трафика.
Cisco предупреждает, что коммутатор обрабатывает данные SPAN с более низким приоритетом, чем обычные данные от порта к порту. Если какой-либо коммутатор/маршрутизатор под нагрузкой будет выбирать между передачей обычного трафика и SPAN-трафика, то зеркальные кадры будут произвольно отбрасываться. И мы не увидим полную картину в анализаторе трафика.
Таким образом, использование SPAN трафика в вашей сети целесообразно только при невысокой общей сетевой нагрузке. При большой нагрузке уже имеет смысл смотреть в сторону TAP (Test Access Point) устройств типа оптических разветвителей. При этом TAP устройство создает полную 100% копию двунаправленного сетевого трафика.
TAP (Test Access Point) — это простое, преимущественно пассивное, устройство, которое напрямую подключается к кабельной инфраструктуре сети между двумя сетевыми устройствами. Весь трафик проходит через него. Используя внутренний физический (оптический) или логический (электрический) делитель, TAP ответвляет копию данных для мониторинга, в то время как исходные данные беспрепятственно передаются по сети.
