Мы уже кратко упоминали о технологии SPAN (Switched Port Analyzer) в предыдущих частях серии. Но есть очень много моментов, о которых нужно помнить, и поэтому давайте рассмотрим преимущества и недостатки SPAN подробнее. Также достойна упоминания постоянная битва между сторонниками SPAN и TAP: часть аналитиков будет настаивать на использовании «только ТАР!», другая часть – наоборот.

Порты SPAN
Я уже говорил это раньше и, наверное, буду повторять ещё несколько раз в следующих статьях: когда вы захватываете трафик, всё сводится к вопросу – «насколько достоверный дамп вам необходим?»
Цель этой статьи – предоставить как можно более полную информацию о практике использования SPAN в реальных задачах анализа трафика, о недостатках и преимуществах этой технологии. Обладая такой информацией, вы и сами будете в состоянии понять, сможет ли SPAN дать вам тот результат, который нужен, в части достоверности.

Повторим основы
Сейчас я немного повторюсь и опишу понятия, которые мы уже рассмотрели в первой части серии. Зачем? Просто потому, что вы, возможно, сразу начали чтение с этой части, без предыдущих. Как вы, скорее всего, уже знаете, SPAN – это функция коммутатора, которая необходима, чтобы получить копию трафика на нужном порту. Не забывайте, что для этого коммутатор должен быть управляемым. То есть, обычный «тупой» коммутатор с 5-16 портами, скорее всего, не имеет такой способности (бывают редкие исключения, когда зеркалирование порта «зашито» в конструкцию изначально).

SPAN означает «Switched Port Analyzer». Если я правильно помню, эта функция изначально была разработана для того, чтобы иметь возможность отладки работы самого коммутатора, а не траблшутинга конечных узлов сети. Но в настоящее время SPAN в подавляющем большинстве случаев используется для анализа трафика – он дает возможность увидеть и прослушать трафик, который в обычном режиме работы коммутатора вы не увидите. Для этого мы назначаем порт-источник (это порт, трафик с которого мы хотим перенаправить, он же «mirror-порт»), и порт-назначение, приемник (это порт, в который мы хотим перенаправить трафик, он же «мониторный порт»). Стоит отметить, что мониторный порт – это самый обычный порт коммутатора, которому мы назначаем данную роль при настройке SPAN-сессии.

Для большинства моделей коммутаторов мониторный порт ведет себя не так, как обычный – он прекращает прием пакетов с подсоединенного к нему устройства. Это означает, что такой порт занимается только отправкой пакетов на устройство анализа и отбрасывает всё, что приходит на него. Это важно по нескольким причинам, например, ваше устройство захвата не будет взаимосвязано с боевой сетью и не будет привносить туда никаких возмущений своим «шумом». Но также это значит, что как только вы настроите мониторный порт, вы через него не сможете общаться ни с кем, включая и сам коммутатор. В общем, будьте бдительны и не отпилите ветку под собой в случае, если вдруг этот порт был единственным портом, через который возможно управление коммутатором (иначе придется заморочиться с консольным доступом, а если нет и его – вас спасет только сброс конфигурации).

Бывают коммутаторы, у которых мониторный порт продолжает работать параллельно и в обычном режиме (один из таких как раз стоит у нас в офисе – прим. перев.) Это означает, что, наряду с мониторингом, порт участвует в обычном обмене данными. Об этом факте нужно помнить. Особенно это присуще более дешевым коммутаторам, или тем, у которых мониторный порт «железно» зашит изначально. То есть, не забывайте протестировать порт перед «боевым» использованием.

Когда SPAN – хороший
SPAN-порт может быть очень полезным:

1. Он позволяет получить доступ к трафику, который иначе не так просто увидеть, при этом не нужно ничего покупать дополнительно.
2. Использование SPAN не требует временного прерывания линка.
3. SPAN-сессию можно достаточно просто включить/выключить CLI-командой или через Веб-интерфейс.
4. SPAN позволяет получить агрегированный доступ к нескольким портам-источникам или даже к целому VLAN’у.

1. Доступ к трафику
Еще раз напомним, без SPAN-порта устройство захвата не увидит трафика, который вам нужен, потому что коммутатор отправляет пакеты напрямую между теми узлами, которые общаются между собой:

Рис.1 – Коммутация без SPAN

Но с помощью SPAN коммутатор создает копии всех пакетов, проходящих через «mirror»-порт, и отправляет их в мониторный порт, куда мы и присоединяем анализатор трафика:

Рис.2 – Отправка копий пакетов на анализатор

2. Нет прерывания линка
Включить сессию SPAN очень просто: вам не нужно временно отключать линк в боевой сети (до тех пор, пока у вас есть хоть один свободный порт и не нужно освобождать какой-нибудь из занятых). Нужно всего лишь внести пару строк в конфигурацию. Всё, что остается – найти этот свободный (а теперь – мониторный) порт и подключить к нему анализатор трафика – зачастую ноутбук или ПК.

3. Конфигурирование через CLI или Веб-интерфейс
В общем, как и указано – это можно сделать или через CLI, или… да-да. Скорее всего, вы все сейчас говорите «Только командная строка! Никто даже с минимальным скиллом сисадмина не пользуется Веб-интерфейсом!» – я вас слышу. Вы правы. Но все же он существует… Веб-интерфейс. Веб-интерфейс может быть единственным вариантом в дешевых коммутаторах из списка внизу моей первой статьи данной серии. Стоит отметить, что в некоторых коммутаторах не так-то просто найти нужные команды или пункты меню, чтобы запустить сессию, но, я уверен, гугл вам поможет с этим.
Несколько примеров, с которыми я сталкивался раньше.
Cisco CLI:

Switch(config)#monitor session 1 source interface gigabitEthernet 1/7 both
Switch(config)#monitor session 1 destination interface gigabitEthernet 1/24

HP веб-интерфейс:

Рис.3 -Веб-интерфейс SOHO-коммутатора НР

Вы можете выбрать, копировать входящий трафик, исходящий или оба типа одновременно (см. «ТХ» и «RX» на рис.3 или параметр «both» в примере с Cisco). Если вы хотите мониторить трафик с одного порта, чаще всего вам нужен вариант «both», иначе одно направление трафика потеряется. Основная причина не выбирать «both» – гибкость конфигурации в случае, если мониторинг обоих направлений одновременно приводит к дублированию в дампе (об этом чуть позднее).

Кстати. Есть некоторые самые старые коммутаторы, которые, несмотря на то, что управляемые, не имеют функции SPAN. Последний такой я видел в одном из немецких госпиталей несколько лет назад, там до сих пор в работе коммутаторы 3COM Superstack. Если вдруг вы увидите где-нибудь подобный коммутатор, сделайте себе мысленную пометку поменять его вчера (без шуток. Это серьезно).

4. SPAN позволяет получить агрегированный доступ к нескольким источникам
Большинство коммутаторов позволяют указать больше, чем один источник трафика в конфигурации. Это означает, что вы можете мониторить больше одного устройства одновременно на мониторном порту. Профессиональные коммутаторы (я намекаю на те, в которых есть команды “enable” и “config”, а также контракт на обслуживание) также позволяют указать как источник один или несколько VLAN’ов. Постепенно такая возможность появляется и в более дешевом оборудовании (естественно, управляемом).

Зеркалирование VLAN’а означает, что выможете перенаправлять все пакеты, входящие/выходящие в коммутатор, принадлежащие определенному (указанному при настройке) VLAN’у. Несмотря на то, что это звучит очень круто, при такой настройке нужно быть невероятно осторожным. Почему – увидим немножко позже. Ну и также надо помнить, что, указав VLAN как источник, мы, естественно, не увидим ну прямо ВСЕ пакеты, входящие в данный VLAN, но только те, которые проходят через наш настроенный коммутатор. Всё же это не магический инструмент, уж простите.

Если вы захотите, вы можете настроить коммутатор так, чтобы он зеркалировал все порты или VLAN’ы в один мониторный порт – многие неопытные пользователи (а временами и админы) считают, что это хороший способ «мониторить все, что происходит в сети». Но нет. В самом деле, эта идея не так уж хороша, скоро увидим почему (ключевое понятие – «бутылочное горлышко»).

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

1. Недостаточная полоса пропускания мониторного порта.
2. Излишняя нагрузка на ЦП коммутатора.
3. Недостаточная достоверность.

1. Недостаточная полоса пропускания мониторного порта

Недостаток полосы пропускания (Bandwidth bottleneck) – частая проблема со SPAN. Даже если вы мониторите всего лишь один порт, который имеет ту же скорость, что и мониторный порт. То есть, создаете сессию 1 Гбит/с -> 1 Гбит/с. Причина в том же, о чем я уже упоминал в статье о сетевых картах: настоящая комбинированная скорость 1-гигабитного порта – 2 Гбит/с (1 Гбит/с на прием и столько же на отдачу). Мониторный же порт использует только свою полосу на отдачу (в сторону анализатора). В худшем случае это значит, что 2 Гбит/с нужно будет впихнуть в 1 Гбит/с – линк. Теперь представьте, что будет с таким интенсивным трафиком (в 2 раза больше максимальной пропускной способности)? Наверное, что-то типа этого:

Рис.4 – Потери пакетов на SPAN-порту

Ответ: коммутатор начнет дропать пакеты. И это также значит, что анализатор увидит не весь трафик, и ведь он даже не будет знать, что пакеты где-то были отброшены (это случилось перед сетевой картой, она даже не будет подозревать, что пакетов изначально-то было больше). У коммутатора нет никакого способа сообщить: «мне пришлось тут выкинуть часть трафика!»
Итак, создание SPAN-сессии, если вы знаете, что у порта-источника высокая нагрузка – не такая уж хорошая идея. А может быть и ещё хуже – попытка зеркалировать источник в 10 Гбит/с на порт 1 Гбит/с. В итоге вы скорее всего получите дамп трафика, подобный такому:

Рис.5 – Так выглядит дамп, если были дропы

Скорее всего, вы будете видеть много пакетов с предупреждением “ТСР ACKed unseen segment”. Оно создается автоматически экспертной системой Wireshark в случае, когда большие пакеты с полезной нагрузкой теряются по пути, а мелкие АСК-пакеты оказываются достаточно юркими, чтобы проскочить-таки к анализатору через «бутылочное горлышко».

Ситуация стремительно усугубляется, если вы добавляете больше портов-источников или целые VLAN’ы к SPAN-сессии. Представим на секунду, что у вас есть хост с виртуальными машинами, который соединен с коммутатором четырьмя гигабитными портами. Виртуальные машины могут использовать любой из этих портов в соответствии с правилами балансировки трафика. Поэтому, лучше, конечно, зеркалировать все 4 – ведь вы не знаете, куда направится трафик в определенную секунду. И получается, что мы создаем SPAN-сессию, у которой на входе 4 потенциально загруженных гигабитных порта «падают» на 1 гигабитный мониторный порт. В наихудшем случае 8 Гбит/с попытается уместиться в 1 Гбит/с. К чему это приведет? 7 из 8 пакетов отбросятся на коммутаторе. Конечно, это уж очень далеко от приемлемой достоверности дампа.

2. Излишняя нагрузка на ЦП коммутатора

Следующий момент при использовании SPAN – дополнительная нагрузка на ЦП коммутатора. Естественно, это будет зависеть от конкретной модели коммутатора. Как правило, коммутаторы пересылают пакеты между «боевыми» портами с использованием специализированных «железных» цепей даже без участия ЦП как такового. При использовании SPAN ситуация может в корне измениться. ЦП задействуется в процессе зеркалирования, и, как итог, добавление портов к сессии может вызвать следующие эффекты:

• Некоторые коммутаторы реагируют отбрасыванием пакетов в процессе зеркалирования, то есть оригинальный пакет все-таки проходит к назначению, его копия теряется в коммутаторе или задерживается и приходит позже или не в изначальном порядке.
• Другие коммутаторы теряют пакеты как в сессии, так и на «боевых» портах.
• Наихудший случай, с которым я сталкивался – коммутатор начал пересылку всех пакетов во все порты, как я понял, он пытался этим сказать: «всё, я сдаюсь, перехожу в экстренный режим и притворяюсь хабом»

3. Недостаточная достоверность

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

• Окружения с высокой загрузкой по трафику. Всегда помните, что мониторный порт вынужден сливать исходящий и входящий потоки источников в один. И если вы зеркалируете гигабитный полнодуплексный порт в один гигабитный мониторный порт – вы легко превысите его максимальную скорость в 1 Гбит/с, что приведет к дропам. Конечно же, вы можете зеркалировать гигабитный полнодуплексный порт в более скоростной, например, в 10 Гбит/с – порт, и это решит проблему. Но – в этом случае вам нужен свободный 10-гигабитный порт (нечастый случай), а также нужен анализатор с таким же портом, способный к тому же захватывать на скорости 10 Гбит/с. Ноутбук с такими характеристиками встретить нелегко (по крайней мере, на момент написания статьи, в 2016г. ноутбуков с такими портами не было). Вдобавок, в основном 10-гигабитные порты на коммутаторах в большинстве своем оптические, а это уже совсем другая история, в которой вам нужна подходящая сетевая карта захвата.

• Случаи, когда вам нужно определить место, в котором теряются пакеты. Здесь SPAN-порт малополезен. А проблема вот в чем: если вы определили при анализе дампа, что пакет был потерян в точке захвата, вы всего лишь определили, что вы не захватили пакет. И тогда я спрошу: «а вы можете дать 99,99% гарантии того, что эта потеря пакета не была вызвана перегрузкой коммутатора или мониторного порта? Можете с уверенностью заявить, что этот пакет вообще не приходил на коммутатор?». Нет, не сможете. Однажды у меня был случай, когда нужно было доказать, что брандмауэр не пропускает некоторые пакеты, которые пропускать должен. В то же время, другие проходили нормально. Это как раз проблема из тех, где нельзя использовать SPAN. Тут для неоспоримого доказательства вам будет нужен ответвитель – ТАР – на входящем и исходящем портах. Поверьте, производитель брандмауэра будет изо всех сил оспаривать ваши результаты, если они не были получены высокоточным профессиональным устройством захвата. Бывали там, сталкивались с этим много раз.

• Случаи, когда нужно доказать, что пакет вообще существовал и был доставлен. Вы можете быть уверены, что пакет действительно отправился в «боевой» порт только потому, что вы его увидели на мониторном порту? У меня случались ситуации, когда пакет действительно был отправлен в продакшн-линк по направлению на сетевую карту сервера, которая сбоила и отбрасывала его. Невозможно быть уверенным, что пакет действительно отправился и «полетел» куда нужно. Мы можем только предположить это. Далеко не всегда этого оказывается достаточно (в этом случае теперь уже админ сервера вступит с вами в схватку, защищая свою зону ответственности). Если вам нужна точная информация, что сеть выполняет свою работу, SPAN вам не поможет, увы. Использовать дамп трафика, полученный таким образом, не выйдет. Придется использовать ТАР.

• При определении задержек пакетов между двумя точками в сети (что само по себе является очень непростой задачей). Если вы заняты определением задержки, как правило, вы охотитесь за миллисекундами, а иногда даже за наносекундами. В моей практике был случай, когда софтовое решение мигрировало с мейнфрейма на Linux-сервера, и ТСР RTT к базе данных полностью убило производительность (я даже писал статью об этом). Заказчик хотел узнать, что было причиной столь низкой производительности – сеть или сам дизайн ПО (они надеялись, что, все-таки, это сеть, потому что устранить проблему с дизайном ПО вышло бы гораздо дороже). Я знал, что между двумя серверами было всего лишь три коммутатора на пути, а практика говорит нам о том, что коммутаторы не привносят каких-либо существенных задержек, если только они не сбойные или уж совсем из рук вон плохо спроектированы. Задержки коммутации находятся в диапазоне микро- или наносекунд, и это сразу же исключило возможность испльзования SPAN для этой задачи, ведь SPAN всегда вносит искажения во временные показатели. Вы не должны доверять timestamp’ам зеркалированных пакетов, если речь идет о диапазоне микро- и наносекунд. И мне самому тогда пришлось использовать полнодуплексные ТАР для того, чтобы доказать, что с сетью всё в порядке.

Когда SPAN – злой
Там, где есть хороший и плохой, обычно присутствует и злой. Под этим заголовком я расскажу о случаях, когда все как бы и работает, но может вызвать весьма неожиданную проблему.

1. Задержка пакетов в очереди на продакшн-линках (queuing). Попадаются коммутаторы, которые по непонятным причинам вносят задержку на «боевых» линках, если на них активна SPAN-сессия. В то время, как эта задержка может быть не столь существенна с единичными пакетами, она имеет привычку аккумулироваться до совсем неприличных величин в действующей сети. Случаи такие нечасты, но – бывают.
2. Когда сеть до сих пор работает на коммутаторах, настроенных по умолчанию. Однажды я работал у клиента, у которого ни один коммутатор не был конфигурирован с момента установки. Было забавно пытаться войти по дефолтному IP на 24-портовый коммутатор и оказаться в веб-интерфейсе 48-портового (я даже сперва подумал, что кто-то недопилил дизайн веб-интерфейса, но нет, это-таки и был 48-портовый Длинк, если я правильно помню). Причина этого всего безобразия понятна – на всех коммутаторах остался один и тот же IP по умолчанию. 24-портовый коммутатор стоял в ядре, а 48-портовый – на дистрибьюции. Так почему же я попал на 48-портовый, если даже физически был подключен к 24-портовому? Потому что «кто последний ответил на ARP – тот и выиграл». Подумайте об этом: мой ноутбук отправил ARP-запрос для поиска IP, ествественно, 24-портовый коммутатор ответил первым (он-то ближе), но в промежутке перед тем, как браузер зашел на страницу интерфейса, прилетел и второй ARP-ответ от 48-портового. Он успешно переписал строку в таблице МАС-адресов. И, соответственно, я перешел на интерфейс к самому медленному коммутатору. Мне пришлось тогда переконфигурировать 3 коммутатора на разные IP-адреса, пока наконец-то я зашел туда, куда хотел.
3. Нестабильная ОС коммутатора. Я было понадеялся, что это дела давно ушедших дней, но – я видел огромные профессиональные коммутаторы ядра (в названии производителя есть буквы «sys»), которые просто уходили в перегрузку после того, как я выключал SPAN-сессию (было это примерно в 2006). Уж поверьте, вы точно никогда не пожелаете, чтобы коммутатор ядра решил перегрузиться вне окна обслуживания в финансовой организации высокочастотного трейдинга. Поэтому будьте готовы к возможным проблемам во время конфигурирования SPAN-сессии, если, конечно, вы раньше уже не имели дела с этим коммутатором и уже знаете, что он переносит перенастройку спокойно. Ну или, как говорил Джек Ричер, «надейтесь на лучшее, но будьте готовы к худшему».
4. Задублированные пакеты. SPAN-порт способен генерировать добликаты пакетов, которые спокойно могут нанести ущерб вашему анализу, если вы окажетесь не готовы к подобному. Главная причина – процесс зеркалирования создает копию трафика больше одного раза.
   

   Рис.6 – Дублирование пакетов

   Чаще всего дубликаты появляются в случае, когда вы зеркалируете больше одного порта за раз, как показано на рис.6. Ну и также это происходит, если вы зеркалируете целый VLAN (или даже несколько): это даст вам копию пакета, когда он входит в VLAN, и копию того же пакета, но который выходит из VLAN. Такая ситуация, в общем-то, аналогична зеркалированию нескольких портов. Как обойти подобную неприятность – указать, что вы хотите видеть только пакеты, входящие во VLAN или только выходящие, но не оба вместе. В большинстве случаев это срабатывает – теперь вы получите только одну копию пакета. А вот если вы зеркалируете несколько портов – увы, фокус не пройдет.
   Некоторые (более дешевые?) коммутаторы также могут дублировать пакеты даже в случае, если зеркалируется только один порт, потому что они зачем-то пересылают броадкастовые и мультикастовые пакеты в мониторный порт, а потом копии этих же пакетов из порта-источника SPAN (в данной фразе автор описывает реальный случай в моей (переводчика) сети, который мы обсуждали. Коммутаторы, поступающие подобным образом – промышленные LCSI, не такие и дешевые – прим. перев.)
   Загляните в пост, где я обсуждаю возможности работы с большим количеством дубликатов, и почему это сбивает с толку экспертную систему анализа Wireshark TCP expert (да и, по сути, практически все другие ТСР экспертные системы).

5. RSPAN (Remote SPAN, удаленный SPAN-порт) – технология, которая позволяет получить трафик с порта другого коммутатора:
   

   Рис.7 – Технология RSPAN

   С виду это кажется хорошей идеей, но, как по мне, это больше для комфорта администратора. Я видел сетевых администраторов, которые пользуются RSPAN, потому что не хотят идти в холодный и шумный датацентр, если можно захватить трафик, сидя в теплом офисе и пользуясь специальным VLAN’ом для пересылки пакетов. Но я лично сталкивался по крайней мере с двумя проблемами с RSPAN.
   Первая из них – RSPAN вызывает дополнительную нагрузку на рабочую сеть. Ведь вам надо перенести некоторый объем данных к анализатору. Возможно, это не так много, но, если сеть и так неслабо загружена, могут проявиться неприятности. Ну и по пути некоторые пакеты могут потеряться, если не пролезут в тонкий канал. Стоит запомнить: чем дольше путь, тем больше возможности потеряться в процессе. SPAN-пакеты всегда стоят первыми в очереди на свалку по логике коммутатора.
   Вторая проблема – точность по времени приходящих пакетов невероятно искажена. Ведь timestamp на пакет ставит сам анализатор, а он находится далеко от непосредственной точки захвата, и видит уже по факту то, «что и когда прилетело к нему». В итоге, вы приходите к пониманию, что, если задача – как раз разобраться с потерями пакетов или точными таймингами, RSPAN вам всё испортит.

6. ERSPAN. Подобен RSPAN’у (включая и его проблемы). Разница только в том, что, вместо использования отдельного VLAN, он инкапсулирует захваченные пакеты в L3 и отправляет на анализатор, что позволяет передавать захваченный трафик по цепочке роутеров. Не сказать, чтобы это было так уж хорошо, ведь обычно соединения между роутерами медленнее, чем локальные.
   

   Рис. 8 – RSPAN, туннелирование захваченного трафика

   А вот как выглядит пакет, который переслался через туннель (на рисунке “пакеты-транспортники”, которые переносят собственно захваченные пакеты):

   Рис. 9 – Пакет ERSPAN в дампе

   Тут можно увидеть, как ТСР-пакет транспортируется, завернутый в заголовок GRE; он имеет тип протокола ERSPAN. Анализатор, находящийся на конце ERSPAN-туннеля, увидит уже декапсулированный трафик, начиная с заголовка Ethernet II. Итого, все проблемы с RSPAN актуальны и тут, только всё ещё хуже.

7. VLAN-теги. Во многих случаях SPAN-порт не дает информации о VLAN-тегах и пересылает только нетегированные пакеты или даже очищает пакеты от тегов. Это может неслабо раздражать, если вам нужны пакеты именно с тегами для траблшутинга. И особенно это не радует, если вы захватываете трафик, источником которого являются несколько VLAN’ов одновременно. Коммутатор обрезает теги, и вы уже не понимаете, из какого VLAN’а «прилетело». Некоторые коммутаторы можно принудительно попросить не обрезать теги, указав тип инкапсуляции, как, например, на некоторых коммутаторах Cisco:

   Switch(config)# monitor session 1 source interface fastEthernet0/5 both
   Switch(config)# monitor session 1 destination interface fastEthernet0/24 encapsulation dot1q

   Однажды в моей практике был случай, когда пришлось работать с коммутатором Cisco (вроде как он был серии Catalyst 6509), у которого просто не было параметра «encapsulation» в настройках. Пришлось обходить эту проблему, настроив мониторный порт в качестве транка, и тогда коммутатор стал отправлять в него тегированные кадры.

8. LACP. Примерно та же ситуация может возникнуть, если вы хотите захватить LACP-пакеты, которые используются для агрегации линков. Очень часто порт-источник не пересылает их в мониторный порт (сам я видел это в коммутаторах Cisco и НР, но, возможно, уже что-то поменялось). Если вы точно хотите захватить пакеты LACP, лучше используйте для этого ТАР.
9. Доверие. Функциональность SPAN запрограммирована в ОС коммутатора. То есть, если кто-то проник в сеть и получил доступ к оборудованию и ОС – он может манипулировать как настройками SPAN, так и самим трафиком. Таким образом, если вы подозреваете возможность вмешательства со стороны злоумышленника – снова-таки, используйте ТАР, который перенастроить невозможно.

Подведем итоги
SPAN – это очень полезная технология, и сейчас это наиболее распространенный способ получения трафика для анализа. Но не стоит забывать о некоторых моментах. Даже принимая во внимание то, что точность при захвате со SPAN-порта меньше, чем при использовании ТАР, часто предпочитается именно SPAN. Суммируя все преимущества: легко запустить, легко выключить обратно, не требуется прерывание линка. Можно просто сказать: «ведь это удобно!»

Краткие рекомендации

1. Не опасайтесь использовать SPAN, если достоверность результатов вас устраивает (смотрите список ниже, где это не так). Отсутствие необходимости разрывать линк, для установки ТАР – это уже очень немало.
2. Знаете поговорку «семь раз отмерь, один отрежь»? Она подойдет и тут. Определите порты источника и назначения дважды. Запишите их. Потом конфигурируйте. Бонус: дважды проверьте, что команда конфигурации совпадает с тем, что вы записали. 75% проблем со SPAN-сессиями оказываются вызваны тем, что кто-то неправильно указал порт-источник и порт назначения. А ведь это может «положить» всю вашу сеть. Испугались? Хорошо. «Семь раз отмерьте» и всё будет нормально.
3. Отслеживайте загрузку ЦП, когда добавляете порты источника. Старайтесь оставаться в пределах 50%, никогда не превышайте 75%. Конечно же, это зависит от текущей загрузки коммутатора. Но помните: если вы все же доведете коммутатор, он озадачит вас далеко не самыми легкими и предсказуемыми проблемами.
4. Захватите трафик в течение нескольких секунд, и проверьте, правда ли это именно то, что вам нужно (диапазоны IP, VLAN’ы и т.д.) – потому что запустить захват на неделю, а потом, придя за результатом, увидеть, что вы указали не тот порт источника – вот что по-настоящему печально.
5. Поглядывайте на тикеты, которые приходят, пока SPAN-сессия активна, и удостоверьтесь, что сама сессия не является причиной сбоев сети. Это бывает редко, но всё же случается.
6. Если подумываете об использовании SPAN в forensics-задачах, при анализе проникновения – не забывайте, что взломать можно и коммутатор со SPAN, скрыв от вас трафик.
7. Избегайте использования RSPAN и ЕRSPAN всеми силами – дополнительный транспорт исказит тайминги и порядок пакетов и в худшем случае приведет к неверным выводам вашего анализа.
8. Отключите SPAN, когда закончите работу, иначе порт останется недоступен для обычной передачи трафика.

Ну и, наконец, список ситуаций, для которых SPAN не подойдет (но, конечно же, никто вам не запретит попробовать его и тут):

• Поиск устройства, которое является причиной потерь пакетов.
• Определение максимально точных таймингов, особенно при задержках менее 50 мс.
• Неоспоримое доказательство того, что пакет действительно был передан в сегмент сети.
• Слишком большая загрузка источника, которую мониторный порт не потянет.
• Расследования, forensics – ситуации, где вы не можете себе позволить потерять ни один пакет (потому что потом надо извлекать из них и анализировать полезную нагрузку).

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

Статья переведена и опубликована с разрешения автора (Jasper Bongertz) только для сайта packettrain.net 

Использование материала статьи без согласования запрещено!

Оригинал статьи находится по адресу: https://blog.packet-foo.com/2016/11/the-network-capture-playbook-part-4-span-port-in-depth/

This article has been translated and published with author’s (Jasper Bongertz) permission. For packettrain.net website only.

Original article can be found at: https://blog.packet-foo.com/2016/11/the-network-capture-playbook-part-4-span-port-in-depth/