Это – первая статья из серии статей-переводов автора Jasper Bongertz о сетевом анализе. Постепенно мы перейдем от базовых знаний к более глубоким, рассмотрим методы, тонкости и многие другие интересные моменты. Итак…

Собственно захват сетевого трафика – это первый шаг при любом анализе трафика на предмет как производительности, так и безопасности. Не так много специалистов полностью осознают, насколько критичен этот шаг и на какие неожиданные грабли (вплоть до безнадежно испорченного дампа) можно наступить, если не подойти к данному процессу с полным осознанием. На SharkFest 2016 я говорил о том, насколько важен сам процесс захвата и подготовки к нему, и теперь я решил создать серию статей, описывающих оптимальный  подход к захвату. Итак, начнем с начала – с самых основ по захвату трафика в проводной (wired) инфраструктуре.

Обо всем по порядку

Захват сетевого трафика может быть полезен для:

• Исследования на предмет активности ПО (что именно софт делает в сети, какой трафик генерирует).
• Траблшутинга проблем со связностью (не хочет подниматься TCP-соединение; или хочет, но потом внезапно обрывается).
• Диагностики плохой производительности как интерактивных «болтливых» соединений, так и при передаче объемных данных.
• Сетевой безопасности, восстановления порядка событий, которые произошли в сети.
• Deep Packet Inspection, поиска известных индикаторов компрометации (Indicators of Compromise, IOCs).
• Изучения потоков в сети и построения графиков (Metadata, NetFlow).
• Реверс-инжиниринга сетевых протоколов.
• Пересборки и извлечения файлов, “пролетающих” по сети.
• Хищения паролей, учетных данных, токенов и т.д.

Ну, то есть, полезен для многих вещей. Главная мысль здесь следующая. Перед самим захватом задайте себе важный вопрос:

Насколько достоверным должен быть дамп?

Если вам все равно – захватывайте прямо на клиенте, сервере или любом другом устройстве на пути. Этот метод называется «локальным захватом», потому что пакеты захватываются на самом устройстве, когда они создаются или просто проходят сквозь него.

Для такого способа захвата характерны 2 важных момента:

1. Его очень легко осуществить (нужен всего лишь софт захвата).
2. Этот способ искажает реальную картину больше, чем какой-либо другой.

Если искажение вас особо не беспокоит – пожалуйста, захватывайте локально. Но если вам нужен более достоверный дамп (а чаще всего так и есть, в особенности, если нужно получить точные данные временных задержек или для траблшутинга обрывов сессий) – то придется придумать что-то получше. Тут мы подходим к необходимости использовать выделенное, обособленное устройство для захвата, которое пассивно в сети (не создает и не передает никакие пакеты в сеть) и записывает все пакеты, которые видит на сетевом интерфейсе, с максимально возможной точностью. Давайте рассмотрим различные варианты такого подхода.

Медленно… но легко!

Помните те дни, когда Ethernet был всего лишь одним из многих L2-протоколов, используемых для соединения устройств? Возможно, некоторые из вас до сих пор помнят Толстый Желтый Кабель (Thick Yellow Cable), в который для подключения новых устройств нужно было (буквально) врезаться с помощью трансивера-вампира:

Рис.1 – Чертеж концепции Ethernet

Как насчет 10Base2 коаксиального кабеля с Т-коннекторами и терминаторами на концах? Да, как просто всё было в то время… Ну, не совсем – сеть была не очень надежна, терминаторы сбоили (или так постоянно казалось). И если у вас было 5 часов для пятничной игры по LAN с коллегами, как минимум 3 из них требовалось, чтобы хотя бы запустить эту сеть (иметь в запасе пару терминаторов было просто жизненно важно).

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

Рис.2 – Общая среда

Как видите, «Устройство захвата» видит всё, что происходит в сети, впрочем, и все остальные устройства.

Концентратор (он же хаб)

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

Still powered on at my son’s school. pic.twitter.com/vl1VmBsrEl

— Matthew Norwood (@matthewnorwood) 6 февраля 2016 г.

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

Общая среда Ethernet начинала испытывать проблемы с увеличением числа узлов сети, когда пакетов становилось больше и больше. Коллизии случались так часто, что заметно портили производительность – есть мнение, что из общей среды можно было «выдавить» 30-40% максимально возможной загрузки. Кстати, у Token Ring производительность была гораздо выше, но это не был открытый и дешевый стандарт как Ethernet, поэтому догадайтесь, кто из них выжил?

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

Рис.3 – Сетевая коллизия

Видите МАС-адрес назначения, который начинается с «ca:5e:00:50», и за которым следует много одинаковых 0x55? Последовательность шестнадцатеричных 55 выглядит в двоичном виде так:

Рис.4 – 0х55 в двоичном коде

Двоичный паттерн 010101010101… это преамбула Ethernet. Она используется для того, чтобы сказать «эй, я хочу передать пакет» и она может столкнуться с пакетом, который уже передается. Эту коллизию можно увидеть при захвате.

Больше скорости! С коммутаторами

Позже для того, чтобы увеличить производительность Ethernet, были созданы коммутаторы. И если хаб это как Уоки-токи, то коммутатор – это уже как полноценный телефон: вы можете и говорить, и слушать одновременно (ну.. теоретически. Обычно мужчины не могут. Женщины обычно могут. Я подозреваю, у них лучше реализована мультизадачность). Возможность говорить и слушать одновременно называется «полный дуплекс».

Для реализации полнодуплексного общения коммутаторы работают как телефонная коммутационная панель, управляемая оператором: когда пакет попадает на коммутатор, он будет передан только на тот порт, которому предназначен. А все остальные порты никогда этот пакет и не увидят (включая и устройство захвата, которое будет недоумевать, в чем же дело). Точно так же, как и телефонный звонок, который перенаправляется только тому, кому вы позвонили:

Рис.5 – Коммутатор в нормальном режиме

Сетевое устройство захвата не получит пакетов (сейчас мы говорим про юникаст), которые принадлежат потоку между другими узлами. А всё это просто потому, что устройство захвата – это не тот узел, которому пакеты были адресованы. А настоящий «получатель» определяется по его MAC-адресу. Но не по IP-адресу или ещё чему-то – коммутаторы это layer 2 устройства, что подразумевает работу с именно с MAC-адресами.

Таким образом, устройство захвата сможет захватить только те пакеты, которые адресованы всем узлам (они же «широковещательные» или broadcast), и, возможно, те пакеты, которые адресованы отдельной группе узлов (они же «многоадресные» или multicast). Во втором случае все будет зависеть от того, как коммутатор работает с мультикастом (сейчас я не буду углубляться в тонкости работы таких коммутаторов). Как коммутатор знает, в какой именно порт отправить юникаст-пакет? Все потому, что он имеет список узлов, подключенных к его портам.

Использование коммутаторов вместо хабов означает, что аналитики потеряли возможность легкого доступа ко всем пакетам в сети, и никогда уже это не вернется назад. Поэтому, всем, кто спрашивает «а как захватить все пакеты в сети?» можно смело ответить: никак! (Строго говоря, можно попытаться приблизиться к чему-то подобному, но велика вероятность, что производительность сети будет при этом убита почти полностью).

Время развлечься: вопросы на засыпку

Вопрос 1. Сколько юникаст-пакетов захватит устройство захвата на коммутаторе как на рисунке 5, если оставить его включенный на какое-то время?

Ноль?

Неправда. Оно будет захватывать юникаст-пакеты время от времени, но только один пакет за соединение (на самом деле, по моему (переводчика) мнению, все может быть несколько сложнее, о чем я написал в своем комментарии к оригиналу статьи – прим. перев.). Причина этого в том, что коммутатор стирает записи в своем списке МАС-адресов по прошествии некоторого времени и потом изучает узлы заново. Эта функция полезна для обнаружения узлов, которые были физически переключены в другой порт. Иначе юникаст-пакеты продолжали бы попадать в старый, ранее известный порт и не попали бы к узлу в его новый порт.

Для того, чтобы изучить, в какой порт подключен узел, коммутатор отправит юникаст-пакет с неизвестным ему MAC-адресом назначения во все порты. Этот процесс называется «port flooding» или «MAC flooding». Коммутатор надеется, что узел подключен к одному из его портов, и когда ответный пакет придет назад, коммутатор изучит его source MAC-адрес и добавит себе в таблицу. А вот все последующие пакеты этого соединения уже пойдут прямо по адресу и благополучно обойдут сбоку устройство захвата, и вы ничего не увидите до следующего «port flooding».

Вопрос 2.  А что произойдет, если пакеты будут продолжать отправляться для узла, которого нет, или который просто не отвечает?

Коммутатор не сможет изучить порт этого узла и продолжит рассылать юникаст-пакеты во все порты.

Вопрос 3. А если пакет проходит через другой коммутатор, в который я (устройство захвата) даже не подключен? Я смогу вообще хоть как-то захватывать трафик?

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

Понял. Давайте дальше!

Итак, что же делать, когда нам очень надо захватить трафик, а у нас коммутатор? Мы должны попросить коммутатор прислать нам копии всех нужных нам пакетов на наш порт:

Рис.6 – Отправка копий на устройство захвата

Естественно, коммутатор должен уметь это делать. Данная функция обычно называется «SPAN» или «port mirror». Без такой функции вы не сможете захватить юникаст-пакеты (кроме тех, из вопроса 1). Для того, чтобы настроить SPAN-сессию, вы должны иметь доступ на коммутатор по SSH (если на коммутаторе есть только Telnet, разбейте его об стену обновите/замените его ) или HTTPS (опять же, если на нем есть только HTTP…) Например, на одном из моих коммутаторов НР есть только веб-интерфейс (лучше, чем вообще ничего), через который возможно настроить SPAN-сессию:

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

На своем коммутаторе Cisco я предпочитаю использовать командную строку для той же задачи:

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

Коммутаторы и SPAN-порты

Когда речь идет о SPAN/port mirroring, коммутаторы бывают четырех типов:

1. «Тупые» вообще такой функции не имеют. Они как правило очень дешевые и продаются в обычных компьютерных магазинах. Когда речь заходит о захвате трафика, в такой коммутатор все и упрется: ничего полезного из него выдавить не получится.
2. «Устаревшие управляемые» коммутаторы. Обычно конфигурируются (при помощи Telnet), но не имеют функции SPAN – я иногда встречал подобные в больницах (3Com), и да, это был 2009 год. Мой совет: меняйте как можно быстрее.
3. «Управляемые» коммутаторы, которые могут настраиваться через SSH или по другому протоколу. Стоят дороже, чем «тупые», в зависимости от их возможностей и функций. Я рекомендую всегда покупать только управляемые коммутаторы.
4. Коммутаторы со вшитым SPAN-портом («hard wired monitor port»). Это коммутаторы, которые зачастую не конфигурируются, НО изначально уже имеют один из портов, настроенный как SPAN. Например, коммутатор по умолчанию зеркалирует трафик из порта 1 в порт 5.

Если вы хотите просто позахватывать трафик в домашней обстановке, я обычно рекомендую купить один из следующих управляемых портативных коммутаторов, их можно установить в разрыв линка, который вы хотите захватить (ну, или, конечно, можно такой коммутатор использовать на постоянной основе, если на нем хватает портов):

• Cisco SG200 8 Port Web Managed Gigabit switch
• NETGEAR ProSAFE GS105Ev2 5 Port Gigabit Web Managed Switch

Или, если ищете что-то дешевое со вшитым зеркальным портом для захвата время от времени и даже вообще без необходимости что-то настраивать (но, конечно, все же нужно где-то взять питание по USB):

• Dualcomm DCGS-2005L 10/100/1000Base-T Gigabit 5 Port Hardwired Mirror Port Switch

TAP ( он же “ответвитель трафика”; “сетевой отвод”)

Ещё один способ захвата трафика – использовать TAP (в дальнейшем будет использоваться именно этот термин как наиболее краткий и устоявшийся – прим. перев.) ТАР – это профессиональные устройства, которые физически устанавливаются в разрыв соединения, предоставляя дополнительный выход, к которому можно подключить устройство захвата и видеть всё, что протекает через этот линк. Большое преимущество ТАР в том, что они более точны, чем обычный SPAN-порт коммутатора. Но есть у них и недостатки:

1. Они стоят денег, в то же время, когда SPAN обходится бесплатно как встроенная функция коммутатора (ну, не совсем бесплатно, ведь это часть цены коммутатора).
2. Для установки ТАР будет необходимо разорвать линк на время установки. Позже для снятия ТАР нужно разорвать линк ещё раз. Для обычного пользовательского ПК ничего страшного тут нет, а вот на backbone-линке, который должен работать в режиме 24/7, не всегда возможно это сделать.

Я опишу ТАР, их возможности и преимущества в одной из следующих статей, поэтому пока что оставим эту тему (последняя фраза была необходима, чтобы производители устройств ТАР и Тим О’нил не выразили мне свое недоверие 🙂 )

«Hub-out»:  табу!

Когда-то был третий способ захвата трафика в коммутируемых сетях, который называется «hubbing out». Идея его заключалась в том, чтобы установить хаб в разрыв линка (по примеру ТАР) и присоединить к нему устройство захвата. Если мы внедряем хаб в сеть, наш линк вынужден перейти в режим общей среды, и тогда мы увидим все, что там происходит. Я, бывало, и сам так делал, у меня всегда был с собой 5-портовый хаб с USB-питанием. В то время (10-15 лет назад) коммутаторы со SPAN-портом были ещё не очень распространены. Сегодня я настойчиво не рекомендую пользоваться таким способом, потому что:

• Он вынуждает линк перейти в режим полудуплекса, тем самым существенно изменяя окружение и снова вызывая сетевые коллизии
• Если вам не повезет, какое-то из устройств останется в полнодуплексном режиме, и вы нарветесь на duplex mismatch (что выльется в такое количество коллизий, что вы и не представляете)
• Хаб работает только на 10/100 Мбит/с – линках
• Хаб уже не так просто найти
• Сейчас SPAN-порты гораздо чаще встречаются, поэтому их использовать просто легче.

Заключительные слова

Начать захват трафика несложно. Хотя раньше, во времена хабов, это было вообще элементарно – каждый из узлов видел всё. Теперь, когда мы везде используем коммутаторы, нам нужны функции SPAN коммутаторов или отдельные устройства ТАР. Если ваши коммутаторы не могут зеркалировать трафик, ничего не получится без использования ТАР. В следующих статьях мы увидим, что в некоторых случаях правильная система захвата может быть достаточно сложной, со многими моментами, которые нужно иметь в виду (особенно в виртуальном окружении), но на сегодня достаточно.

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

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

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

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

Оригинал статьи находится по адресу: https://blog.packet-foo.com/2016/10/the-network-capture-playbook-part-1-ethernet-basics/

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/10/the-network-capture-playbook-part-1-ethernet-basics/