Wireshark как способ заглянуть под капот

Здравствуйте,

Недавно я получил письмо с новогодним поздравлением и мне очень понравилась мысль, раскрывающая суть Нового года с точки зрения психологии, а не с точки зрения волшебства и сказки. Мы по инерции несем из детства эту красивую сказку, не задумываясь о истоках ее рождения. Если отбросить всю ауру красивого праздника, то вырисовывается обычная человеческая потребность, а точнее его разума в разделении непрерывного времени на части. Нам действительно так удобнее и радостнее. Новый год как чистый лист, попытка настроиться на новый лад, отпустить негатив в прошлое… Продолжительные праздники все воспринимают по-разному. Для кого-то это период поедания салатов и просмотра сериалов, путешествий, возможности повидать близких, а для некоторых помимо перечисленного это еще и период осознанности. Под осознанностью я понимаю такое состояние, при котором мы абстрагируемся от бытовой составляющей нашей жизни, останавливаемся на некоторое время подумать куда мы идем, что мы делаем, так сказать, сверяем свой жизненный компас с нашей картой жизни. Если экстраполировать данную идею на профессиональную составляющую, то наверняка в период новогодних праздников многие задумываются над тем, чтобы взяться наконец за изучение столь необходимого в профессии английского языка, записаться на курс по программированию, начать подготовку к сертификационному экзамену, разобраться с чем-то, что позволит выйти на новый уровень, сменить работу, повысить доходы. Если читая данную статью ты чувствуешь некую потребность в расширении своих компетенций в IT, поиске новых инструментов, которые позволили бы вам выгодно выделяться на фоне свои коллег, то прошу под кат где я расскажу о своей новой находке – сетевой аналитике, как о способе «заглянуть под капот» происходящего в сетях. Применение сетевой аналитики посредствам анализа пакетов – точка роста как для сетевого инженера, так и для специалиста по информационной безопасности.  

Интересно? - Тогда поехали…

Наверняка много слышали о таких явлениях DevOps, DevNet, SDN. Что объединяет такого рода явления? Ответ прост – TTM (Time to market). Бизнес стремится уменьшить время вывода на рынок нового продукта, снизить человеческих фактор, увеличить прогнозируемость и управляемость, ну и конечно снизить издержки на эксплуатацию. В связи с этими потребностями рынка появляются новые профессии зачастую объединяющие в себе ранее абсолютно не совместимые вещи. Так, к примеру, наиболее органичным бэкграундом DevOps инженера является системное администрирование. Добавляя к знаниям и опыту администрирования инструменты CI/CD и понимание методологий построения пайплайнов рождается новое направление, решающее задачи непрерывной интеграции, ускоренной разработки и вывода на рынок программных продуктов. DevNet – попытка уйти от ручного конфигурирования сетевой инфраструктуры, высоких рисков человеческого фактора. Тут цель достигается на стыке чистых сетевых технологий и инструментов автоматизации. SDN – программно-определяемые сети – апогей DevNet тренда. Если коротко, то SDN - декларативный подход к сетям. Вы, как субъект, описываете желаемое состояние объекта, в данном случае это сеть, и как по волшебству она принимает желаемое состояние. Вы можете переходить от состояния к состоянию, как в системе контроля версий. Однако описать желаемое состояние не так просто, как может показаться. Тут пригодится хороший багаж сетевого инженера, навыки администрирования систем, знания современных языков описания, языков высокого уровня, стека сетевых протоколов и протоколов прикладного уровня. Конечно, full stack инженерами не рождаются, но современные вызовы склоняют к тому, чтобы развивать некоторые компетенции параллельно. Этому есть логичное объяснение. Нам уже не нужно лезть на низкие уровни того, как работают операционные системы, только если вы не разработчик оных. Нам не нужно в деталях знать как работает тот или иной сетевой протокол. Почему? А зачем, протоколов много, при необходимости всегда можно поднять RFC и разобраться. Актуальнее стало не знание всего и вся, а кругозор в сфере информационных технологий, наличие у специалиста необходимого инструментария быстро локализовать и устранить проблему, автоматизировать рутинные задачи, обработать большой объём данных, проанализировать узкие места в части производительности, отказоустойчивости, безопасности. Так же актуальны навыки детализировано и понятно документировать архитектуру инженерных и программных систем.  И да совсем забыл – мониторинг, без него никуда. Примите тот факт, что придется параллельно основной специализации учить много нового, постоянно, чтобы успешно конкурировать и как минимум не оказаться на обочине.

Надеюсь, убедил вас открыться чему-то новому и это новое сегодня – сетевая аналитика. Многие из вас слышали про такие инструменты как Wireshark, tcpdump. Если нет, то потерпите, дальше я расскажу о них и их возможностях. Раньше я использовал данные инструменты, но не представлял, насколько они, в совокупности с методологиями, могут добавить осознанности в то, чем занимается сетевой инженер, специалист по информационной безопасности. Я бы даже так описал: сетевая аналитика (анализ пакетов сетевого трафика) – это как заглянуть под капот неисправного автомобиля вместо того, чтобы стоять на расстоянии и гадать, что же сломалось. Я не шучу. Мой опыт говорит о том, что, когда что-то работает не так, многие специалисты начинают гадать, пробовать что-то делать исходя из гипотез. В особо запущенных случаях сетевые администраторы «катят бочку» на ИБ-шников, разработчики на тех и других, получается замкнутый круг. Хотя из этого круга выход все же есть, как есть выход из любой ситуации. Главное желание! 

Не решенные и решенные кейсы. Как я искал и что нашел.

Как и многое в жизни осознание необходимости поиска инструмента пришло в попытках решить проблемы. Первой проблемой, требующей навыка проанализировать сетевой трафик, была проблема одного большого клиента. Суть проблемы была в том, что в произвольный момент времени у сотрудников клиента возникали проблемы с доступом к сервису электронного документооборота, предоставляемого нашей компанией. Из-за этого процесс документального взаимодействия с внешними контрагентами нарушался. По факту, выражаясь профессиональным языком, взаимодействие «клиент-сервис» в произвольные моменты времени, с произвольной продолжительностью испытывали состояние именуемое DoS. Для начала просто DoS, а не одноименная атака. Отказ в обслуживании не всегда может быть следствием атаки, направленной на отказ в обслуживании. Бывают и абсолютно не очевидные проблемы с некорректно функционирующим ПО сервиса, не правильной настройкой сети. Естественно, никто не хотел рассматривали вариант атаки. Клиент вышел с предположением, что проблема на стороне сервера, обслуживающего сервис. Выводы они сделали на основании дампа трафика, где было видно, что IP адрес назначения отправляет пакет с флагом RST. RST – отказ в установлении сессии. Пока сохранялась данная проблема клиент перебрасывал исходящий трафик пользователя на другой пограничный маршрутизатор, используемый для remote VPN клиентов, и проблема на время уходила. Это были временные решения, которые позволяли восстановить доступ пользователей к сервису. При проблем со стороны сервиса системы электронного документооборота не наблюдалось. Оставалась одна точка к которой у нас не было доступа – FW за которым находился сервис. Возможно, именно там мы бы смогли найти подсказки, но увы. В скором времени, после нескольких месяцев борьбы с внезапно проявляющимся симптомами DoS (примерно раз в неделю) клиент перестал выходить с данной проблемой, по всей видимости она была устранена. На тот момент я не знал про существование SYN-флуд атаки и как ее диагностировать. Уже по прошествии большого количества времени я поднял переписку с клиентом, дампы трафика. Применив правильно сформированные фильтры и отобразив статистику стало понятно, что у клиента в сети наблюдалась DoS атака (рис. 1):

На рисунке 1 видно, что за 1 минуту 17 секунд было инициировано 30018 уникальных попыток установить сессию с сервисом системы электронного документооборота из ЛВС сети клиента. Это очень много и вручную сгенерировать такое количество траффика невозможно. Давайте я вам поясню какая логика используется в применяемом фильтре:

tcp.flags.syn==1 – все пакеты с установленным флагом SYN. SYN- попытка установить tcp сессию (первый этап трехэтапного процесса рукопожатия);

 - исключаем повторные попытки синхронизаций (обычные и быстрые), а также сообщения о повторном использовании портов.

Данный фильтр позволяет выявить только уникальные syn транзакции.

Умение составить правильный фильтр для корректной диагностики и локализации проблемы – главная задача сетевого аналитика. Без глубокого понимания стека TCP/IP и аналитических возможностей Wireshark, в купе со знаниями методик проведения различных видов атак и порядка съёма трафика для последующего анализа, составить подобный фильтр и сделать правильные выводы не получится. 

При анализе трафика в данном кейсе также необходимо было обратить внимание на такие атрибуты как «Time to live». По значению данного атрибута, в зависимости от точки съёма трафика, можно понять кто именно отсылает RST. Дело в том, что в большинстве случаев работает NAT, маскирующий реальный источник/назначение трафика. TTL помогает вычислить кто инициатор того или иного сообщения: оконечные хоты/сервисы или файрвол/роутер. Так же не помешало бы проверить параметры защиты от SYN-flood атаки как на стороне клиента, так и на стороне сервиса. Тот факт, что при смене роутера на стороне клиента проблема временно пропадала, говорил о том, что на одной из сторон отрабатывает система защиты от аномально большого количества попыток соединений. Обычно критерием таких систем защиты является максимально допустимое количество одновременно устанавливаемых сессий с одного IP адреса. По правде говоря то как действовать и на что обращать внимание в такого рода ситуациях стало понятно после того как была прочитана полезная книга, пройден вводный курс, просмотрено и прочитано не мало ресурсов на следующие темы:   

- Сбор сведений о сети;

-Диагностика проводных и беспроводных сетей;

-Борьба с медленно работающими сетями;

-Обеспечение сетевой безопасности;

-методики сбора, хранения, анализа для судебной экспертизы.

О изученных материалах и возможных вариантах дальнейшего развития в области сетевой аналитики расскажу в заключительной части.

Успешные кейсы сетевого инженера

1.Поиск необходимого порта

Есть несколько интересных моментов. Они очень важны в реальной жизни специалистов IT сферы. Первый момент: на начальном этапе любого траблшутинга очень часто не понятно в чьей зоне ответственности источник проблемы. Большинство специалистов предпочитают подход «проблема не на моей стороне». Сетевые специалисты (связисты) в этом смысле находятся не в выгодном положении. Существует стереотип о том, что если трафик ходит медленно или совсем не ходит или происходит его потеря, то это обязательно проблема на сети. Своего рода презумпция виновности сетевых инженеров в сфере IT. Однако часто при детальном изучении обнаруживается, что либо проблема была в корявой архитектуре приложений, либо в сети присутствуют проблемы с информационной безопасностью, выражающиеся в эксплуатации злоумышленниками уязвимостей системы или в просто неразборчивой блокировке специалистами отдела информационной безопасности всего, что система обнаружения вторжений посчитала не заслуживающим доверия трафиком. Бывают и проблемы на 8-м уровне модели OSI. Не слышали про такой уровень? Если не слышали, то вот ссылочка - https://ru.wikipedia.org/wiki/Layer_8.

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

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

Итак, вооружившись небольшим количеством знаний и инструментарием случается следующий кейс:

IDS фиксирует срабатывание одной из своих сигнатур на что незамедлительно реагируют специалисты по ИБ. Причиной срабатывания является подозрительный обмен между сервисом внутреннего потребителя ресурсов и внешним ресурсом. При детальном изучении сигнатуры и описания уязвимости обнаруживается, что внутренний сервис имеет в своем составе уязвимое ПО. Принятое решение – полная изоляция виртуальной машины с последующим восстановлением из бэкапа чистой копии. Дополнительно принимается решение о настройке на межсетевом экране более узких правил сетевого взаимодействия. Т.е. не просто permit 443 port to all public ip, а конкретные IP. Это бесспорно увеличивает трудозатраты тех, кто отвечает за сервис и тех, кто настраивает правила. Решение логичное ведь тогда даже если эксплойт попадет на машину, то у него не будет возможности загрузить с не доверенного сайта вредоносный код для его исполнения.

И, казалось бы, все хорошо, владелец сервиса предъявляет перечень ресурсов доступ, к которым необходимо открыть для полноценной работы сайта и прикрученной CRM системы. Доступы настраиваются, а CRM звонки не принимает. Вернее, со стороны клиента выглядит все так, как будто кол-центр не берет трубку. После того как клиент завершает звонок в CRM системе регистрируется пропущенный. И тут начинается свистопляска на несколько дней. Еще раз все перепроверяем: порты, IP указанные на сайте поставщика облачной телефонии – все учли, все настроили верно. Однако же полноценно колл центр работать с жесткими политиками безопасности не мог.

В подобных ситуациях обычно начинается поиск виновных, недовольные лица и большое количество переписки в почте с нарастающим числом адресатов в поле «В копии». 

В данном случае источник проблемы был найден довольно быстро, еще до того, как кому-либо прилетела шайба. Найти причину помог Wireshark, простая логика и немного знаний. Первое в голову пришло снять дамп в момент эмитируемого входящего звонка клиента и проанализировать, используя незамысловатый фильтр отображения tcp.flags.syn==1 && tcp.flags.ack==0. Я использовал простую логику– облачная телефония использует SIP протокол. Для работы SIP в качестве транспорта используется как TCP так и UDP. Для согласования звонка однозначно в начале используется TCP. Для уменьшения объёма дампа трафика при его сборе мной был использован фильтр захвата состоящий из IP адреса CRM и примененный к исходящему в сеть Интернет потоку трафика. На выходе получили интересующий нас трафик (рис.2)

  Применяя далее фильтр отображения tcp.flags.syn==1 && tcp.flags.ack==0 для вычленения неудавшихся попыток установления TCP получаем результат (рис.3):

Очевидно, что наша система с IP X.Y.114.10 пытается установить TCP сессию с «белым» IP адресом 185.164.149.34 в сети интернет по порту 12092. Данный IP принадлежит сервису облачной телефонии и как оказалось данный порт не был указан в технической документации как необходимый к открытию. По факту другим способом как описан выше мы бы и не смогли запустить телефонию. О данной проблеме уведомили и данный порт добавили в документацию. В большинстве случаев владельцы внутренних ресурсов не заморачиваются и открывают полный доступ в сеть Интернет если иного не требует политика безопасности. Однако это плохой подход, идущий в разрез с главным принципом информационной безопасности – принципом минимальных привилегий. Это если коротко. А если охватить пошире, то я сформулировал бы так: «Сервисы, пользователи, процессы должны иметь минимально достаточные для их штатной работы доступы».

Завершая описание данного кейса хочу еще заострить ваше внимание на поле TTL (Рис.3). TTL = 64. Если иметь небольшое представление о стеке TCP/IP разных операционных систем, то по данному значению можно сделать несколько полезных умозаключений. Первое – CRM c IP адресом X.Y.114.10 развернута на Linux машине. Linux машины при генерации пакетов устанавливают TTL равным 64-м. Второе - порт 12092 закрыт на дефолтном для анализируемой машины маршрутизирующем устройстве. В нашем случае это межсетевой экран. В нашем случае не очень-то и важно на какой ОС «крутится» сервис, но данное поле полезно при обследовании сети и получении отпечатков операционных систем. В нашем же случае значение TTL указатель на то, что межсетевой экран отправил пакет в /dev/null или простым языком не стал дальше маршрутизировать иначе значение было бы меньше 64-х. Надеюсь все знают, что каждый хоп минусует единицу от значения TTL.

 2.Вдруг сломалась 1С и бухгалтерия не может отправить отчетность. Что делать, куда бежать, кто виноват и вот это вот все.

Если коротко, то при использовании ИТС 1С, в частности 1С: Контрагент выскочила ошибка: «Удаленный узел не прошел проверку. Не удалось выполнить проверку отзыва сертификата». Первое что сделал программист 1С это загуглил все что можно, сделал все что смог и как вы догадались - ничего не помогло. Дальше за дело взялись опытные и матерые системные администраторы в попытках проанализировать логи, но как уже и говорилось ранее очень часто нужно заглянуть под капот (проанализировать трафик) чтобы получить реальные подсказки, а не сообщения программного обеспечения по факту зачастую просто сигнализирующему, что есть проблема. Этот кейс не стал исключением и пришлось прибегнуть к великому и суперэффективному анализу пакетов. Опять моделируем ситуацию, требующую проверки отзыва сертификата, и применяя фильтр захвата собираем интересующий нас трафик. Открывая полученный дамп сразу же обращаем внимание на подсветку красным цветом, так Wireshark обращает наше внимание на явную проблему, которая может нас заинтересовать и не ошибается (рис.4):

Дело в том, что в Wireshark присутствует мощная встроенная экспертиза, аналитика способная подсказывать и направлять наше внимание на важные события:

Анализируя дамп, а если точнее пакеты #100, 101 и 144. Пакет #100 с относительной временной меткой 19.7826 это http запрос корневой директории сервиса проверки отзыва сертификатов. Пакет #101 с временной меткой 19.7827 – почти молниеносный ответ сервиса. Пакет #144 с временной меткой 31.315 – разрыв соединения по инициативе CRL сервиса. Логично заключить, что после отправки сервисом пакета #101 должен был последовать ACK пакет от получателя, но обратного трафика нет и по истечению таймаута (примерно 12 секунд) сервис рвет соединение. И тут возникают опасения, что трафик не ходит в Интернет по 80 порту на адрес 93.184.220.29. Как оказалось в последствии, при обращении к службе ИБ, данная связка IP/порт были добавлены в фильтр после сообщения от IDS о наличии аномалий при обмене с участием указанного IP. Естественно ИБ никого не предупредили…

Вот этот фильтр о котором не знали сетевой инженер, 1С программист, системные инженеры:

Опять базовые знания Wireshark, TCP/IP и методик анализа пакетов помогли оперативно разрулить ситуацию, хотя обошлось не без нервов😊

3.Еще один кейс, когда оказалось, что проблема не в сети, а в проблеме сбоя процесса авторизации камер на портале единого центра сбора и хранения информации

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

По перехваченным пакетам можем сразу удается установить следующее:

1.      IP адреса источника запроса на подключение (IP адреса проблемных камер нам известны, по ним мы и ограничивали съем дампа трафика);

2.      Тип протокола – rtsp, метод – options, URL медиа потока rtsp://ip_адрес_камеры/mediainput/h264

Сверяемся с настройками камер, на данном этапе все корректно. Ищем ответ на request (запрос). А вот он:

Погуглив данную проблему получаем намек на проблему с авторизацией. Но откуда она взялась, ведь никто ничего не менял. На этот вопрос ответа я так и не нашел. Но после пересоздания учетной записи на проблемных камерах и перерегистрации на портале все заработало, хотя по мнению лиц в части касающихся проблемы как обычно были на сети) Портал большой, камер там тысячи, а людей как обычно – одЫн… Вот пришлось сузить зону поиска проблемы и Wireshark как нельзя снова пришелся, кстати.

Вышеописанные кейсы - лишь малое с чем может помочь умелое использование таких мощных инструментов как Wireshark или tcpdump. Далее я ознакомлю вас с различными областями применения инструментов, а также расскажу какие ресурсы помогут вам быстро приобрести минимально необходимый навык использования и знания для эффективного использования в практике. Для тех, кому этого будет мало расскажу о тернистых, но возможных путях дальнейшего совершенствования в этом направлении)

Итак, для начала я бы посоветовал вам начать с прочтения отличной и по всей видимости единственной в своем роде книги «Анализ пакетов. Практическое руководство по использованию Wireshark и tcpdump для решения реальных проблем в локальных сетях» замечательного автора, мирового эксперта в области информационной безопасности и анализа трафика Криса Сандерса:

Данная книга поможет ознакомится с принципами анализа пакетов и основами организации сетей. Вы также научитесь правильно подбирать место и метод подключения к сети с целью сбора трафика для дальнейшего анализа. Автор ознакомит с разнообразными возможностями Wireshark и tcpdump, порядком обработки перехваченных пакетов. Не лишним будет ознакомиться с нюансами работы протоколов сетевого, транспортного, прикладного уровней. На примере реальных сценариев автор расскажет от том, как выяснить причины отсутствия веб-содержимого, отсутствия доступа к сети Интернет, нежелательной переадресации, наличия проблем с обратным потоком данных, не работающего сетевого принтера, отсутствия связи с филиалом, повреждение данных программы. На типовых сценариях будет показан принцип работы аналитика. Поняв принцип, вы сможете применить подход в жизни, как на не сложных кейсах было показано выше. Помимо всего в книге глубоко затронуты меры по борьбе с медленной сетью, анализ пакетов на безопасность, особенности анализа пакетов в беспроводных сетях.

Могу посоветовать не плохой, легкий, дающий первичное представление курс от онлайн школы NetSkills:

http://blog.netskills.ru/2020/12/6network-traffic-analysis-and.html

В конце курса можно сдать тест и получить сертификат об успешном завершении.

Вот пример:

Из русскоязычных ресурсов – все.

Из англоязычных ресурсов я также советую обратить внимание на еще одного эксперта и идеолога сетевой аналитики Chris Greer

https://www.youtube.com/channel/UCHN1aYRP473xX6Z13H_mxMQ

У него также имеется курсы на Pluralsight https://www.pluralsight.com/authors/christopher-greer

На счет курсов отзыва у меня нет – не проходил. Однако короткие видео на его YouTube канале помогут разобраться как работает Wireshark, TCP in depth, основы применения Wireshark в сфере Infosec (ИБ).

Ну и у того же Криса Сандерса есть свой сайт, на котором вы можете что-то получить бесплатно, ну а курсы уже за денюжку, причем не малую. Вот ссылка на крутые курс: https://chrissanders.org/training/

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

P.S. Сейчас пошел тренд на автоматизацию. Я сам в 2019 году поддался и прошел курс Наташи Самойленко https://t.me/info_comm/190 . Да – польза есть, кругозор как минимум точно расширился, но на практике далеко не всегда и не везде удается применить эти знания. Автоматизация, где Вам пришлось бы писать скрипты на python, с использованием различных библиотек это скорее исключение, чем правило. Ну по крайней мере пока, хотя тренд есть. А вот Wireshark и основы аналитики – поверьте, если вы сетевой инженер, системный администратор, специалист по информационной безопасности то это must have. Не знаю почему так мало об этом говорят, но, уверяю вас, это пока. Так что, если размышляете во что инвестировать время инвестируйте в аналитику – не пожалеете. Помимо указанного, для сетевого инженера умение использовать Wireshark поможет в углубленном изучение работы сетевых протоколов. Если вы заметили, то курсы и статьи уровня CCNP/CCIE часто используют дампы трафика для анализа работы control plane.

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