Не SPANом единым: о способах зеркалирования трафика
Проблема получения копий трафика существует довольно давно. Зеркалировать трафик нужно прежде всего при выполнении задач информационной безопасности. Например, различные системы обнаружения вторжений, работающие в пассивном режиме, то есть не блокирующие, а только уведомляющие об атаках, используют копии трафика. Также системы предотвращения утечек данных используют копии трафика при анализе. Антивирусы могут отлавливать в потоке данных файлы и собирать их для последующего анализа.
Кроме безопасников зеркалирование трафика может потребоваться например, сетевикам в процессе отладки межсетевого взаимодействия. В общем, копия трафика — вещь полезная, но как ее можно получить?
Старый добрый SPAN
Итак, Switch Port Analyzer (SPAN) — это одна из функций, доступная в большинстве современных сетевых коммутаторов, позволяющая отслеживать трафик посредством копирования пакетов с одного или нескольких портов источников на порт назначения. Порты источники являются обычными портами, к которыми подключены узлы, к порту назначения подключаются компоненты соответствующих систем мониторинга IDS, DLP и т.д.
Когда коммутатор получает пакеты от портов источников, настроенных на работу со SPAN, он пересылает копии пакетов на порт назначения, который обрабатывает их независимо от другого трафика в сети. Этот процесс выполняется в режиме реального времени и, по идее, не должен влиять на доставку исходного трафика по сети.
Казалось бы, все замечательно. Мы выбираем, с каких портов источника хотим получать копии трафика и какой порт использовать для пересылки, выполняем необходимые настройки на коммутаторе и получаем копии трафика. Но не все так просто.
Когда-то, много десятилетий лет назад я сдавал экзамены из трека CCNP (помните, был такой вендор?) и в учебных материалах явно указывалось, что SPAN порт должен использоваться для диагностики неполадок в сети. То есть, при отладке администратор включал SPAN, решал возникшие проблемы с трафиком и затем выключал зеркалирование. Нигде не говорилось о том, что этот режим должен использоваться на постоянной основе (пусть поправят меня более опытные сетевики, если это не так). Однако сейчас в официальной документации большинства решений, работающих с копиями трафика, в явном виде указывается использование SPAN порта.
Так, ниже в качестве примера представлен фрагмент схемы из документации для решения по анализу трафика в промышленных сетях.
Так что же не так со SPAN?
SPAN и его проблемы
Порты SPAN на коммутаторе имеют наименьший приоритет и при интенсивной загрузке процессора коммутатора первыми будут отбрасываться именно пакеты, передаваемые на зеркалирование.
В результате мы рискуем потерять часть трафика, что не позволит получить полную картину происходящего в сети, и средства анализа упустят важную активность. На практике потери пакетов на SPAN портах могут достигать 25 процентов — что, согласитесь, довольно много.
Если говорить об отладке сети, то искаженные пакеты и ошибки низкого уровня в пакетах могут быть отфильтрованы коммутатором и не переданы на SPAN порт. Кроме того, теги VLAN также могут теряться при передаче по SPAN порту.
Похожая ситуация может возникнуть, если вы хотите захватить LACP-пакеты, которые используются для агрегации линков. Многие коммутаторы не пересылают такие пакеты в мониторный порт.
Использование технологий, позволяющих получать трафик с портов других коммутаторов, таких как RSPAN, ERSPAN создает дополнительную нагрузку на сеть и коммутаторы, участвующие в передаче данных.
Также мы рискуем получить неверные данные по времени получения пакетов, что будет критично при передаче VoIP и аналогичных протоколов, работающих в реальном времени.
Отдельно стоит отметить, что некоторые модели коммутаторов имеют ограничения на количество портов, с которых можно снимать трафик. Так, некоторые промышленные коммутаторы позволяют получать копии трафика только с одного порта. То есть, мы можем зеркалировать один физический порт в другой физический порт. В некоторой степени такой подход честнее, так как нам сложнее будет перегрузить коммутатор излишним объемом трафика для зеркалирования, и в результате меньше риски потери пакетов.
И наконец, для зеркалирования трафика наш коммутатор должен быть управляемым. Не все дешевые коммутаторы уровня доступа являются управляемыми, и это тоже надо учитывать при внедрении систем, работающих с копиями трафика.
SPAN не всегда зло
После прочтения предыдущих абзацев может возникнуть впечатление, что SPAN — это абсолютно ненадежная технология, которую лучше вообще не использовать. Но это не совсем так. Во-первых, SPAN можно и нужно использовать при отладке сети, как и завещал ушедший вендор.
Во-вторых, если средняя загрузка вашего коммутатора не превышает 50 процентов, объем трафика не слишком большой, то у вас вряд ли будут возникать потери пакетов.
Также, если вы не используете RSPAN/ERSPAN, то проблем с зеркалированием будет значительно меньше.
Теперь давайте поговорим о том, что можно сделать там, где нельзя использовать SPAN.
TAPаем, но не хомяка
В качестве альтернативы использованию SPAN обычно предлагаются TAP устройства (ответвители). Общий принцип съема трафика здесь достаточно прост: мы устанавливаем TAP устройство в разрыв между узлами, с которых надо снять трафик. Соответственно, на TAP один порт подключен к узлу отправителю, другой — к узлу получателю и один или несколько портов используются для передачи копии трафика.
На рисунке представлена топология для Ethernet, но TAP также можно использовать и с оптическим кабелем.
Основные преимущества TAP заключаются в том, что мы получаем полную 100-процентную копию двунаправленного сетевого трафика, включая теги VLAN, ошибочные пакеты, короткие или большие кадры, обеспечивая полную точность для сетевого мониторинга. При этом не изменяются временные соотношения между кадрами, интервалом и временем отклика.
TAP не являются адресными сетевыми устройствами и поэтому не могут быть взломаны, они не требуют дополнительной настройки, у них нет интерфейса управления или командной строки.
По сути, TAP работают по принципу «включил и работай».
В рамках данной статьи мы специально не упоминаем кого-либо из присутствующих ныне на рынке вендоров, но на просторах Хабра можно найти статью одного из российских разработчиков TAP устройств, в которой подробно расписываются все преимущества TAP и модели устройств.
В принципе, TAP можно собрать самому. Например, на схеме, представленной ниже, предлагается TAP устройство для Ethernet. На практике для сборки подобного устройства потребуется четыре Ethernet розетки и немного сетевого кабели для того, чтобы сделать распиновку.
При планировании количества портов важно не забывать, что два порта всегда нужны отправителю и получателю, а количество остальных портов определяется количеством устройств, работающих с копией трафика.
К недостаткам TAP можно отнести то, что они являются точкой отказа при передаче трафика, хотя на практике эти устройства слишком просты для того, чтобы в них могли возникнуть сбои, и главной проблемой здесь может стать неожиданная потеря питания на самом устройстве.
Много пакетов — тоже плохо
Итак, завернули мы на свои сенсоры копии трафика с помощью TAP, все хорошо, получаем полную копию. И тут выясняется, что наши сенсоры, предназначенные для анализа трафика, сами захлебываются от большого объема приходящего трафика. Теперь то, что мы считали достоинством TAP, а именно, полная копия трафика, стало большим недостатком — сенсор получает слишком много ненужного трафика и не успевает его отфильтровывать.
Конечно, решать эту проблему можно по-разному. Можно попробовать поставить несколько TAP на разные каналы и использовать несколько сенсоров. Если топология сети позволяет, то можно завернуть на коммутаторах трафик из нужных VLAN на отдельный порт и этот канал подключить к VLAN.
Но в случае, если все эти способы не помогают, можно воспользоваться пакетными брокерами. Эти устройства могут решать различные задачи, связанные с распределением пакетов. В рамках нашей задачи фильтрации ненужных пакетов из копии трафика пакетный брокер подойдет как нельзя кстати.
Получая копию трафика с TAP, мы с помощью пакетного брокера отбрасываем все лишнее, а то, что нужно, можно распределить между несколькими портами для передачи соответствующим анализаторам.
Да, пакетный брокер — это более сложное устройство, чем TAP, здесь уже требуются и настройки и возможные сбои, но так как оно находится за TAP и работает только с копией трафика, на передаче основного трафика проблемы с данными устройствами никак не скажутся.
О конкретных решениях данного класса можно почитать всё у того же российского вендора.
Заключение
Мы рассмотрели различные варианты съема сетевого трафика. Использование SPAN не всегда является наилучшим решением и при внедрении систем анализа трафика стоит рассматривать и другие варианты.
В завершение напоминаю про бесплатные открытые уроки, посвященные сетям, которые пройдут в Otus совсем скоро:
3 декабря: Использование /31 префикса в ip сетях. Рассмотрим необходимость появления такого варианта настройки. Сравним его с классическим префиксом /30. Записаться
18 декабря: Повторители, мосты, хабы, медиаконвертеры и коммутаторы. Кто из них выжил и почему? И (немного) о принципах их работы. Записаться
