Глава 8. Анализ и подслушивание сетевого обмена

Как всем нам известно, на Уровне 3 OSI (Open Source Interconnection), который также носит название Сетевого уровня, всё взаимодействие одной машины с другой происходит в форме пакетов. Эти пакеты содержат реальные сведения, переносимые по сетевым каналам связи.

Таким образом, анализом пакетов называется перехват или прослушивание текущих данных для анализа их сведений для выполнения таких атак как атак MITM (Man in the Middle, с посредником в промежутке), воровства сведений и судебной экспертизы. Доказано, что анализ пакетов очень важен в процессе действий красной команды (специалистов- расследователей), в особенности при обходе начальных мер безопасности сети, таких как NAC (Network Access Control, Контроля доступа к сети) и осуществления боковых смещений.

Ниже приводятся некоторые аспекты, при которых анализ пакетов оказывается очень полезным:

Теперь, когда мы осознали важность фильтрации пакетов, давайте взглянем на архитектуру сетевого пакета чтобы разобраться с фильтрацией пакетов в процессе анализа в реальном масштабе времени.

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

На рынке присутствует большое число сетевых анализаторов, таких как Cain and Abel, CloudShark, Network Miner и Ettercap. Для целей этой главы мы сосредоточимся в основном на Wireshark с несколькими примерами для TCPdump.

 

Wireshark

Wireshark работает на уровне приложения и перехватывает весь сетевой обмен из кабеля через конкретную NIC (Network Interface Card, карту сетевого интерфейса) или, когда это необходимо, с применением нерегулярного режима. Приводимая ниже схема показывает как Wireshark работает для перехвата и отображения сведений пакета.

Как отображено на Рисунке 8.1, при начале перехвата пакета Wireshark инициализирует WinCap и прочие драйверы на канальном уровне, причём позволяет соответствующей NIC работать в нерегулярном (promiscuous) режиме, а пакет из Wireshark dumppcap.exe отвечает за перехват пакетов. После того как пакеты начинают перехватываться Wireshark, для просмотра конкретного обмена могут применяться дешифраторы, подключаемые модули и фильтры.

Итак, теперь, когда мы разобрались с тем как Wireshark работает в качестве сниффера, давайте изучим некие основы Wireshark:

Как показано на Рисунке 8.2, GUI (Graphical User Interface, графический интерфейс) Wireshark, содержит различные закладки File, Edit, Capture и Wireless и Tools, а в основном экране отображены сетевые адаптеры, такие как Wi-Fi (Wireless Fidelity), LANs (Local Area Connections) и VMware (виртуальные машины), а также сетевой обмен. Это помогает пользователю выбрать сетевой адаптер для сниффинга проходящего через него обмена.

В нашем случае это будет сетевой адаптер Wi-Fi. Дважды кликните по сетевому адаптеру Wi-Fi. Приводимый ниже снимок экрана отображает наблюдаемый сетевой обмен:

Как показано на Рисунке 8.3, отображаются сведения относительно значения адреса источника IP (Internet Protocol), IP адрес назначения, собственно протокол и сам пакет.

Теперь давайте применим некие фильтры для просмотра конкретного обмена, например, TLS (Transport Layer Security) и значения адреса IP:

Как это отражено на Рисунке 8.4, обмен фильтруется на основе значения адреса IP и TLS. Аналогично мы способны применять прочие фильтры, например, DNS, а также их включение или исключение.

Теперь, когда мы разобрались с основами Wireshark, давайте посмотрим на некие основы TCPdump.

 

TCPdump

TCPdump работает аналогично Wireshark с единственным отличием, состоящем в том, что Wireshark это сниффер на основе графического интерфейса, в то время как TCPdump имеет интерфейс командной строки. Итак, давайте разберёмся с некими основами TCPdump:

Как показано на Рисунке 8.5, по сетевому интерфейсу eth0 выполняется перехват сетевого обмена. Давайте применим соответствующий фильтр для перехвата обмена на основании значения IP адреса:

Как отображено на Рисунке 8.6, TCPdump перехватывает обмен в реальном масштабе времени когда его хост, 192.168.64.130, пытается осуществлять доступ к Google. Аналогично, на основе требований может применяться большое число фильтров.

Сейчас, когда мы ознакомились с основами сниффинга TCPdump, давайте разберёмся c самими сетевыми пакетами и сниффингом обмена в реальном времени при помощи сетевых снифферов.

Сетевые пакеты определяются как небольшие контейнеры сведений, которые делят весь набор взаимодействия. Теперь, осознав это определение, давайте изучим некоторые основы самой модели OSI.

Как известно, модель OSI делится на семь различных уровней, причём пользующиеся ею люди начинают взаимодействие с самого верхнего уровня, а именно с уровня приложения, или, в терминах сетевой среды, приступают к взаимодействию. Итак, после того как этот пользователь записывает какие- то данные, эти данные начинают перемещаться с его уровня приложения (седьмой, или самый верхний уровень) на физический уровень (самый первый, или нижний уровень).

Теперь, на всём этом пути, данные делятся на множество фрагментов, а на Уровне 3, сетевом уровне, такое деление на фрагменты носит название пакетов. Для различных протоколов имеющиеся внутри таких пакетов сведения могут быть отличающимися.

Теперь, прежде чем глубже окунаться в анализаторы пакетов, давайте разберёмся со структурой пакета в его сердцевине. Приводимая далее таблица представляет поток данных пакета на сетевом уровне:

Как отражено на Рисунке 8.6, обмен данными происходит с уровня приложения на физический уровень, а на самом физическом уровне кадры данных далее делятся на биты и затем передаются с подключаемого RJ-45 кабеля ethernet.

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

Рисунок 8.8 отображает полный анализ пакета данных некого пакета TLS, начиная с кадра Ethernet до его транспортного уровня. Давайте двинемся далее и проанализируем соответствующий уровень приложения протокола HTTP, как это показано на снимке экрана ниже:

Как показано на Рисунке 8.9, перехвачены запрос HTTP и отклик; давайте проанализируем их кликнув правой кнопкой и следуя за потоком HTTP для считывания содержимого, как это отражено на следующем снимке экрана:

Как показывает Рисунок 8.10, перехвачены в обмене реального времени весь запрос HTTP целиком и отклик. Теперь это может быть очень полезным когда дело доходит до эксфильтрации чтобы выделить удалённый хост и те данные, которые подлежат передаче через данный канал во внешнюю сеть. После анализа этого, профессионалы безопасности могут немедленно отсечь текущий обмен и предпринять надлежащие действия против злоумышленников.

Сейчас давайте проанализируем то же самое при помощи TCPdump. Приводимый далее снимок экрана показывает перехват TCPdump пакета HTTP:

Как отображено на Рисунке 8.11, обмен HTTP перехватывается в any (любом) интерфейсе, в котором происходит обмен от источника 192.168.64.130 и его сервера Apache, а следовательно получатель тот же самый, однако убедитесь что порт источника 59308, а порт получателя 80.

Теперь, уяснив, что TCPdump слегка сложнее, а следовательно сетевые администраторы и профессионалы безопасности обычно останавливаются в качестве первоначального сниффера на Wireshark. Однако по моему личному опыту, когда мы остановились на TCPdump, очень просто разобраться с потоком обмена и много раз мы ограничивали атаки вредоносного программного обеспечения в своей сетевой среде.

Итак, мы подробно разобрались с сетевыми снифферами и в прочих главах, таких как Главе 12, Атака на протоколы маршрутизации, Главе 13, Безопасность DNS, Главе 14, Безопасность веб служб и служб электронной почты и Главе 16, IP телефония и безопасность служб сотрудничества мы намного глубже обсудим подробности различных протоколов, таких как HTTP, DNS и VOIP. Сейчас мы двинемся к своему следующему разделу и изучим сетевой анализ с применением Python.

Мы изучили анализ пакетов с применением средств автоматизации, однако порой, в процессе анализа вредоносного программного обеспечения, эксфильтрации данных и атак туннелированием, таких как туннелирование DNS, необходим глубокий анализ пакета за пакетом, который несколько сложен в Wireshark. Применяя модули Python, такие как Pyshark это полезный способ к пониманию и локализации целей вредоносного ПО.

Итак, давайте выполним анализ пакетов с применением Pyshark. Установка Pyshark очень проста, как это отражено на приводимом ниже снимке экрана:

Как показано на Рисунке 8.12, Pyshark бул успешно установлен в Windows в качестве пакета модуля Python. Итак, давайте импортируем Pyshark и приступим к перехвату обмена в реальном масштабе времени:

Как изображено на Рисунке 8.13, при помощи Pyshark успешно перехвачены пакеты обмена в реальном времени. Таким образом, для того чтобы удостовериться, давайте откроем перехваченный пакет обмена реального времени в Wireshark:

Как показывает Рисунок 8.14, все необходимые пакеты сетевого обмена перехвачены успешно, а потому теперь давайте импортируем полученный в Pyshark файл для последующего анализа:

Как отображает Рисунок 8.15, этот файл перехваченного сетевого обмена был импортирован успешно. Следовательно давайте пошагово проанализируем эти пакеты:

Как показывает Рисунок 8.16, перехвачены пакеты UDP (User Datagram Protocol). Теперь давайте проанализируем соответствующие поля в этих пакетах UDP, такие как адрес IP источника, адрес получателя IP, версия IP и хост IP:

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

Как показывает Рисунок 8.18, все сведения успешно выведены дампом из выбранных пакетов UDP. Эта информация в действительности полезна в процессу устранения сетевых неполадок или, в особенности, на протяжении анализа атак.

Итак, теперь, когда мы разобрались с пакетами UDP, давайте выполним аналогичный анализ в пакетах DNS, как это показано на снимке экрана ниже:

Как отражено на Рисунке 8.19, импортирован обмен пакетами DNS. Поэтому, давайте теперь выведем дамп сведений пакетов DNS при помощи pretty_print(), как это видно из приводимого далее снимка экрана:

Как видно из Рисунка 8.20, успешно выдан дамп всех сведений из полученных пакетов DNS.

Тем самым, теперь, когда мы ознакомились с анализом пакетов при помощи Pyshark, давайте двинемся далее к следующему крайне интересному разделу, посвящённому препарированию пакетов.

Сейчас, прежде чем мы перейдём к препарированию пакетов, давайте разберёмся с ним.

Препарирование пакетов означает анализ определённой части данных пакетов, таких как TCP или IPv4, которые содержат множество читающих автоматов. Они написаны на языке программирования C старой школы.

Считывающий автомат (dissector) это просто синтаксический анализатор протокола, который способствует много чему при устранении неисправностей пакетов сетевого уровня, в особенности когда все данные содержатся в TCP и трудно разбираться с обменом уровня приложения.

Следовательно, на настоящий момент, мы наблюдали пакеты в читаемых форматах для анализа форматов пакетов, однако имеются доступными некие сырые данные, которые рисуют некое описание в текстовом виде, сообщают данные регистрации соответствующего приложения, а из них выводится что это за пакет. Или же, что если нам требуется ввести новый пакет протокола для упрощения анализа, скажем пакет ECHO?

Именно здесь выходит на сцену препарирование пакетов, как очень удобное для анализа на уровне самого ядра. Приводимая далее схема представляет препарирование пакета в простых терминах:

Как показано на Рисунке 8.21, препарирование пакета вовлекает в себя выработку вручную такого пакета из байтов данных для препарирования протокола.

Итак, давайте в качестве образца возьмём предыдущий ICMP (Internet Control Message Protocol) и соберём простые запрос и отклик.

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

Таким образом, давайте приступим к сборке своего препаратора пакетов:

Итак, когда теперь мы изучили препарирование пакетов, давайте ознакомимся с протоколом ARP (Address Resolution Protocol) и его атаками.

Теперь мы обладаем глубоким пониманием пакетов, фильтрацией пакетов и написанием простых пакетов. В этом разделе мы попробуем разобраться с вредоносными пакетами изучая различные атаки сетевого уровня, такие как взлом данных или сеанса через отравление ARP. Однако прежде чем мы глубже окунёмся в отравление ARP, давайте разберёмся с самим протоколом ARP и анализом пакетов на сетевом уровне через перехват обмена в реальном масштабе времени при помощи Wireshark.

Протокол ARP, как и предполагает его название, разрешает адреса и создаёт их карту. Теперь, основной вопрос, какие адреса? ARP создаёт соответствие адресов MAC (Media Access Control) адресам IP. Следовательно, протокол ARP работает на Уровне 2 модели OSI.

Однако как это работает? Сейчас, когда нам известно что входит в сетевую среду, системы идентифицируют друг друга через IP адреса, тем не менее, при взаимодействии друг с другом в реальном масштабе времени необходимы адреса MAC. Следовательно, именно на протоколе ARP лежит ответственность за сбор сведений сведений об имеющихся адресах MAC и установке их соответствия адресу IP его машины. Это можно наблюдать на следующей схеме:

Как показано на Рисунке 8.24, сведения в соответствующем пакете будут заполнены значением IP адреса машины получателя и именно ARP отправляет необходимый запрос ко всем подключённым в данную сетевую среду машинам или то же самое для VLAN (Virtual Local Area Network).

Теперь, когда соответствующая система получила такой запрос, она заполнит значение адреса MAC в свободном пространстве этого пакета ARP и отправляет его обратно первоначальной машине запроса.

Сейчас, эта машина и коммутатор, которым она подключена, сделают некую запись в таблице с названием таблицы кэширования ARP, что отражено на приводимом далее снимке:

Как показывает Рисунок 8.25, это текущая таблица ARP машины. Теперь давайте взглянем на сам пакет ARP:

Как отражает Рисунок 8.26, такой пакет ARP обладает всеми необходимыми сведениями. Сам протокол ARP отправит этот пакет по адресу получателя и просит систему заполнить адрес MAC. Таким образом, давайте взглянем на это через трассировку пакета:

Как изображает Рисунок 8.27, PC0 и PC1 подключены к коммутатору и на данный момент в этой машине нет никаких записей ARP. Давайте отправим какой- то ICMP, как это показано на идущем далее снимке экрана:

Как отображено на Рисунке 8.28, когда PC1 отправляет пакет ICMP, вначале инициализируется пакет ARP и этот пакет затем отправляется к PC0, который откликается PC1 совместно со значением адреса MAC в этом пакете ARP, как изображает следующий снимок экрана:

Как показывает Рисунок 8.29, необходимый цикл ARP завершён, соответствующий пакет ICMP успешно достигает PC1 из PC0 и в обеих системах успешно делается соответствующая запись ARP. Теперь давайте взглянем на имеющуюся таблицу кэширования ARP, как это отображено на снимке экрана далее:

Как изображает Рисунок 8.30, эта таблица ARP инициализирована и совместно со значением адреса IP поставлен в соответствие адрес MAC. Теперь давайте посмотрим на перехват такого пакета ARP в Wireshark:

Рисунок 8.31 показывает пакет ARP со всеми имеющимися записями. Теперь, когда мы разобрались с ARP, давайте рассмотрим отравление ARP.

Отравление ARP также носит название подделка (spoofing) ARP, который применяется для взлома сеансов или данных. Такая атака чрезвычайно распространена в сетевой среде для перехвата полномочий реального времени, хэширования NTLM (New Technology LAN Manager), сигналов и вызовов VOIP ( Voice Over IP) и тому подобного. Такая атака обсуждается в прочих главах, включая Главе 16, IP телефония и безопасность служб сотрудничества. Однако в данной главе мы взглянем на взлом данных или сеанса посредством отравления ARP:

Как показывает Рисунок 8.32, при помощи средства arpspoof инициализирована подделка под цель 192.168.64.153. Итак, теперь давайте перенаправим этот обмен с порта 80 в порт 8080:

Как отражено на Рисунке 8.33, весь этот обмен с порта 80 перенаправляется в порт 8080. Для взлома соответствующих данных или сеансов давайте запустим средство ssltrip:

Как изображает Рисунок 8.345, инструмент ssltrip инициализирован по порту 8080 и теперь весь обмен с порта 80 будет перенаправляться в нашу машину из жертвенной машины.

Для демонстрации нам придётся создать поддельную страницу Facebook. Когда жертва вводит свои регистрационные данные, они будут перехвачены машиной злоумышленника при помощи Wireshark:

Как это отражает Рисунок 8.35, наша жертва вводит свои полномочия. Теперь для перехвата этих регистрационных данных открываем Wireshark на машине злоумышленника:

Согласно Рисунку 8.36, полномочия учётной записи жертвенного Facebook успешно перехвачены в машине злоумышленника.

Таким образом, на данный момент мы изучили протокол ARP и, то, как применяя подделку ARP мы можем прерывать данные реального времени. Итак, давайте теперь перейдём к изучению различных средств, которые мы можем применять для выработки пакетов и откликов в сетевой среде чтобы разбираться с её инфраструктурой как с точки зрения сетевого администратора, так и с точки зрения злоумышленника.

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

Например, в процессе некоторых реализаций, сервер утрачивает подключение ко всей сетевой среде. По этой причине, чтобы разобраться с таким отказом, администраторы отправляют пакеты Traceroute и ICMP. Таким образом, самый последний перехваченный пакет был отброшен в каком- то промежуточном межсетевом экране, что означает, что в процессе реализации, сетевая команда забыла открыть необходимое соединение в этом межсетевом экране.

Следовательно, выработка пакетов и пакеты воспроизведения это те техники, посредством которых наша сетевая команда создаёт необходимые пакеты, такие как TCP, ICMP, UDP и ARP, причём в сыром виде, чтобы обозначить целью соответствующее устройство и перехватить соответствующий отклик с целью изучения данного устройства или выполнения на нём устранения неисправностей.

И снова, злоумышленники применяют те же самые методологии для изучения сетевой инфраструктуры имея целью конкретную сетевую среду. Другой вариант применения воспроизводства пакетов состоит в выполнении стресс теста для изучения загруженности устройства в процессе DOS (Denial of Service) или DDOS (Distributed DOS).

Вот различные средства для выполнения выработки пакетов и воспроизведения пакетов:

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

Как отображает Рисунок 8.37, в настоящее время разрешаемый IP адрес для Google это 172.217.18.238. Поэтому, давайте применим в Wireshark фильтр конкретно для TCP чтобы выдавать дамп обмена с Google, как это показано на снимке экрана далее:

Как изображает Рисунок 8.38, этот фильтр в Wireshark не применяется для захвата обмена ARP и перехватывает только обмен с Google.

Теперь, для анализа выработки пакетов Google давайте запустим NetScanTools, что отражено на снимке экрана ниже:

Как это показывает Рисунок 8.39, NetScanTools будет вырабатывать все свои пакеты и отклики и воспроизводить их в отношении Google для сбора необходимых сведений. Таким образом, давайте взглянем на вырабатываемые NetScanTools результаты, отображаемые следующим снимком экрана:

Согласно Рисунку 8.40, NetScanToolsвырабатывает общие сведения относительно Google, такие как его головной офис, местоположение и зарегистрированное название. Таким образом, давайте рассмотрим результаты PING:

Как показано на Рисунке 8.41, NetScanTools вырабатывает результаты PING при помощи протокола ICMPv4. Итак, давайте взглянем на результаты treceroute, как это отражено на следующем снимке экрана:

В соответствии с Рисунком 8.42, NetScanTools вырабатывает простой traceroute от текущего ISP (Internet Service Provider, поставщика Интернет услуг) к серверу Google. Следовательно, давайте взглянем на открытые порты и запущенные службы, что отражает снимок экрана далее:

Как показывает Рисунок 8.53, наш текущий веб сервер Google исполняется по двум известным портам, 80 и 443, и в настоящий момент исполняющими HTTP и HTTPS, соответственно.

В данной главе мы глубоко изучили сетевые пакеты и их соответствующий анализ, причём с применением Wiresharp и TCPdump средств на основе графики, которые широко применяются сетевыми администраторами. Затем мы изучили анализ пакетов при помощи модуля Python Pyshark, предоставили в качестве образцов глубокий анализ пакетов UDP и DNS. Затем мы рассмотрели различные подходы к анализу сетевого обмена, называемого препарацией пакетов при помощи языка программирования LUA. Помимо сетевого анализа мы выполнили подделку ARP и взлом данных с применением атаки отравлением ARP, а в своём последнем разделе мы изучили средства выработки и воспроизводства при помощи NetScanTools.

В своей следующей главе мы изучим анализ поведения и выявление анатомии сетевых пакетов, IPfix и NetFlow.