• Курсы Академии Кодебай, стартующие в мае - июне, от команды The Codeby

    1. Цифровая криминалистика и реагирование на инциденты
    2. ОС Linux (DFIR) Старт: 16 мая
    3. Анализ фишинговых атак Старт: 16 мая Устройства для тестирования на проникновение Старт: 16 мая

    Скидки до 10%

    Полный список ближайших курсов ...

Статья Криминалистический анализ команды Ping

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

Используемые инструменты: Wireshark, командная строка/терминал,

В этой статье практические занятия основаны на 64-разрядной системе Windows 10 и 64-разрядной Debian Linux. Хотя это не должно иметь значения во многих случаях, это имеет значение для определенной части, где мы используем TTL, а также для случая аномалии. Больше об этом позже. Читая эту тему, я узнал множество новых вещей, которые для меня, как пентесттера, определенно были бы полезны для глубокого понимания того, как работают эксплойты.

Содержание:
  • Модель OSI
  • Протоколы Ethernet, IP и ICMP
  • Команда ping и пакет ping
  • Wireshark и базовые фильтры
  • Как датаграмма отправляется на хост назначения (понимание слоев, связанных с использованием Wireshark)
  • Понимание размера данных в ping
  • MTU в IEEE 802.3i
  • Фрагментация в пинге
  • Аномалия в пинге
Модель OSI:
OSI расшифровывается как Open System Interconnection - эталонная модель, которая описывает, как информация из программного приложения на одном компьютере перемещается через физический носитель к программному приложению на другом компьютере.

Он имеет семь слоев, и каждый слой выполняет специальную сетевую задачу. Они заключаются в следующем:

Screenshot_0.png


У каждого слоя есть определенная задача, и мы не будем углубляться в каждый из них. Давайте сохраним это на другой день. Давайте сосредоточимся на слоях 1, 2 и 3 на данный момент.

Объединенные уровни 1, 2 и 3 отвечают за эффективную передачу пакетов ICMP.

Протоколы Ethernet, IP и ICMP
Во время «пингования» системы слои 1, 2 и 3 работают. Каждый уровень определяет свой собственный «формат параметров протокола», известный как заголовок. Он предшествует фактическим данным, подлежащим отправке, и имеет такую информацию, как IP-адрес источника, IP-адрес назначения, контрольная сумма, тип протокола и т.д. А когда он присоединен к фактическим данным, которые должны быть отправлены, он образует блок данных протокола, который переименовывается за слой.

Протоколные единицы данных по умолчанию (PDU) в этих уровнях:
  • Уровень 1: биты
  • Слой 2: фрейм
  • Уровень 3: пакет
  • Уровень 4: датаграмма
Мы будем использовать эти термины довольно часто, и важно четко понимать, что означают эти термины. Пока данные проходят через эти уровни, они фактически преобразуются в собственный PDU.

Ethernet
IEEE 802.3 - это набор стандартов и протоколов, которые определяют сети на основе Ethernet. Технологии Ethernet в основном используются в локальных сетях. В IEEE 802.3 существует несколько версий, таких как 802.3a, 802.3i и т.д. Когда мы пропингуем, некоторые данные отправятса на хост назначения в определенном формате.

Ethernet-заголовок:
Screenshot_0.5.png


IP (интернет-протокол)
Это основной протокол связи для передачи дейтаграмм через границы сети. Задача IP заключается в доставке пакетов от источника к хосту исключительно на основе IP-адреса в заголовках пакетов. IP определяет структуры пакетов, которые инкапсулируют данные и заголовки.

ICMP (протокол управляющих сообщений Интернета)
Поскольку IP не имеет встроенного механизма контроля ошибок и отправки управляющих сообщений, ICMP здесь, чтобы обеспечить эту функциональность. Это вспомогательный протокол, используемый сетевыми устройствами, такими как маршрутизаторы, для отправки сообщений об ошибках.

Пинг
Ping - это сетевая утилита, используемая для проверки доступности хоста в IP-сети. Ping работает, отправляя пакеты запроса ICMP Echo и ожидает ответов ICMP Echo. Это сообщает об ошибке, TTL, потере пакетов и т.д.
Один запрос ping представляет собой комбинацию заголовков и данных Ethernet, IP и ICMP.

Ping отправляет IP-пакеты с ICMP_Echo_Request к месту назначения и ожидает его ответа (IP-пакет с ICMP_Echo_Reply).

Пакет ICMP инкапсулирован в пакет IPv4. Общий состав дейтаграммы IP выглядит следующим образом:
wiki1.png


Когда на хост отправляется команда ping, датаграмма также содержит заголовок Ethernet, заголовок IP, заголовок ICMP и полезную нагрузку. Минимальный размер заголовка IPv4 составляет 20 байтов, а максимальный размер - 60 байтов.

По умолчанию размер данных полезной нагрузки в ping в Windows составляет 32 байта.
Давайте добавим в него 20 байтов заголовка IP и 8 байтов заголовка ICMP. 32 + 20 + 8, получается 60 байт.

Но когда мы анализируем ping в Wireshark, размер кадра, записанного в журнале, составляет 74 байта. Это связано с тем, что при пинге нам также понадобится MAC-адрес назначения и источника, который доступен в заголовке Ethernet.

14 + 20 + 8 + 32 = 74 байта.

Итак, ping отправляет инкапсулированный IP-пакет, который представляет собой комбинацию:
Заголовок Ethernet + заголовок IP + заголовок ICMP + полезная нагрузка ICMP
Продолжайте читать для очень интересных случаев, которые заставили меня написать эту статью.


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

Screenshot_1.png


Давайте пройдем шаг за шагом и посмотрим, что только что произошло.
  1. Я пропинговал IP-адрес 192.168.217.128 с моего исходного IP 192.168.238.1 и перехватил только один пакет, чтобы ясно увидеть действие.
  2. Сверху есть фильтр Wireshark для IP-адреса, который выглядит как addr == 192.168.217.128
  3. Некоторые другие полезные фильтры Wireshark:
    http или dns
Код:
tcp.port==xxx
tcp.flags.reset==1
tcp contains xxxx
tcp.stream eq X
tcp.seq == x
http.request
udp contains xx:xx:xx
  1. Далее вы можете увидеть общую длину отправленной датаграммы, то есть 74 байта, как уже объяснялось выше.
  2. Затем вы можете увидеть, в желтом цвете, фрейм Ethernet. Здесь вы найдете заголовок Ethernet.
  3. После этого это пакет IPv4. IP используется для доставки пакетов от источника к месту назначения на основе IP-адресов.
  4. Наконец, мы видим заголовок ICMP и данные полезной нагрузки.
  5. Все эти уровни вовлечены в простой пинг по IEEE 802.3. В следующем разделе мы узнаем, как анализировать пакетные данные с помощью Wireshark, чтобы получить подробное представление о проверке пакетов.
Как датаграмма отправляется в пункт назначения?
Когда датаграмма отправляется из источника в пункт назначения, в нашем случае, когда мы пингуем, формат дейтаграммы выглядит следующим образом:

Screenshot_1_2.PNG


Мы пингуем пункт назначения с параметрами по умолчанию:
Код:
ping 192.168.217.128

Давайте начнем анализировать трафик в Wireshark.
Я просто захватил одну датаграмму в Wireshark, когда пинговал целевой хост, и анализировал ее слой за слоем.
Говоря об уровне 2 здесь, мы можем видеть, что используется тип Ethernet 2.

Screenshot_2.png


Как мы говорили в пункте 2, кадр Ethernet, отправляемый с помощью ping, включает в себя MAC-адрес источника и назначения, а также тип используемого протокола.

0000 00 0c 29 d7 b1 35 00 50 56 c0 00 08 08 00

MAC-адрес получателя MAC EtherType

(6 байтов) (6 байтов) (2 байта)


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

Типы EthernetШестнадцатеричное значение
ARP08 06
IPv408 00
IPv686 дд
IEEE 802.1Q81 00

Переходя к уровню 3, мы видим IP-пакет, поскольку ping, очевидно, использует IP-протокол, чтобы проверить, жив хост или нет. Вот наблюдение шестнадцатеричного дампа IP-пакета:

Screenshot_3.png


0000 ... 45 00 00 3c да 40 00 00 80 01 2c ad c0 a8 d9 01

Тип заголовка Общий IP-адрес источника протокола TTL

Продолжительность
службы Длина

(1 байт) (1 байт) (2 байта) (1 байт) (1 байт) (4 байта)

0010 с0 а8 д9 80

IP-адрес назначения

(4 байта)


Из анализа этого IP-пакета мы видим, что IP-заголовок затем добавляется в кадр Ethernet, чтобы создать пакет с указанными выше опциями. Анализируя эти данные, мы можем наблюдать много разных вещей. Некоторые из которых:

TTL:
Операционные системыHex Value TTLДесятичное значение TTL
Windows80128
Linux4064
Mac3957
Тип протокола:
протоколШестнадцатеричное значениеДесятичное значение
ICMP11
TCP66
EGP88
UDP1111

Действительно интересная вещь - длина заголовка. Мы видим, что длина заголовка записывается как 45 в шестнадцатеричном виде, что оказывается 69, что невозможно. Далее, разбив этот байт, мы увидим, что первый полубайт (полбайта) сообщает версию протокола.

4 = шестнадцатеричное значение = 4 (версия протокола), то есть IPv4

5 = шестнадцатеричное значение = IHL (длина Интернет-заголовка) = следующая для битов

И так далее (общая длина = 00 3c = 60 байтов)

Датаграмма завершается и транспортируется, когда заголовок ICMP добавляется на уровне 3. Мы знаем, что в IP отсутствует механизм контроля ошибок, поэтому ping использует ICMP для этой цели. Протокол ICMP указан в заголовке IP, как мы видели выше, и поэтому важно проанализировать заголовок ICMP, чтобы лучше понять механизм проверки связи.

Screenshot_4.png


0000 08 00 4d 53 00 01 00 08 61 62 63 64 65 66 67 68

Тип Код Контрольная сумма данных

(1 байт) (1 байт) (2 байта) (32 байта)


0010 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 61

0020 62 63 64 65 66 67 68 69

Тип: это тип запроса отправленного ICMP-запроса. Согласно IANA, есть 45 назначенных запросов.

Screenshot_5_1.png


Мы можем видеть тип запроса 08, который означает Эхо-запрос. Когда одна система отправляет эхо-запрос другой системе, она отправляет запрос типа 8, а если хост активен, хост отправляет обратно запрос типа 0 (ответ эхо-запроса).

Код: это просто шестнадцатеричное значение типа сообщения запроса ICMP. Он варьируется от 0 до 15 для каждого из типов. Эта ссылка взята из Википедии:

Screenshot_5_2.png


Контрольная сумма: «Контрольная сумма является 16-битным дополнением к сумме дополнения сообщения ICMP, начиная с типа ICMP. Для вычисления контрольной суммы поле должно быть нулевым. Если общая длина нечетна, полученные данные дополняются одним октетом нулей для вычисления контрольной суммы. Эта контрольная сумма может быть заменена в будущем ». - RFC 792

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

Здесь состояние контрольной суммы отображается как правильное, поэтому нам не нужно смотреть дальше.

Данные: содержит другие важные данные, такие как отметка времени, порядковый номер, магический номер и т.д.

Размер данных в пинге
Согласно RFC 791, IP может обрабатывать датаграмму с максимальным размером 65 535 байтов. Однако по умолчанию данные в ping составляют 32 байта, а вся дейтаграмма по умолчанию составляет 60 байтов в случае Windows. С добавлением 14 дополнительных байтов заголовка Ethernet получается 74 байта, которые мы видим в Wireshark. Сосредоточьтесь на цветовых кодах здесь:

Red = размер данных полезной нагрузки ICMP

Green = Общая длина пакета IPv4

Maroon = общая длина дейтаграммы

Screenshot_5_3.png


Давайте сейчас поговорим о Linux. Размер IP-пакета по умолчанию в случае Linux составляет 56 байт. Добавление дополнительных 28 байтов заголовка IP и ICMP дает 84 байта . Добавление более 14 байтов заголовка кадра Ethernet дает 98 байтов.

Тем не менее, мы можем добавлять данные по нашему желанию, если они не превышают 65 535 байт, используя опцию ping –l в Windows. Это имеет некоторые ограничения. Давайте поговорим о них в следующем разделе.

MTU в IEEE 802.3i
MTU означает Максимальный блок передачи, и это размер самого большого протокольного блока данных, который может быть передан в одной операции сетевого уровня. Стандарты IEEE 802.3 ограничивают минимум до 48 байтов и максимум до 1500 байтов. Таким образом, если мне нужно передать более 1500 байтов данных в одной дейтаграмме, они будут фрагментированы на несколько пакетов.

Чтобы понять MTU, мы рассмотрим четыре случая:

Размер полезной нагрузки данных = 200 байт, 1472 байт, 2000 байт, 65500 байт

Размер полезной нагрузки 200 байт:
Код:
ping –l 200 192.168.217.128

Мы видим, что размер датаграммы IPv4 составляет 242 байта. Это результат 200 байтов полезной нагрузки + 8 байтов заголовка ICMP + 20 байтов заголовка IP + 14 байтов заголовка Ethernet. Примечательным здесь является то, что по-прежнему отправляется одна датаграмма, а фрагментация не выполняется. Давайте теперь увеличим предел MTU.

Screenshot_6.png


Теперь давайте расширим пределы пакета ping для MTU, то есть 1500 байтов в случае IEEE 802.3.
Код:
ping -l 1472 192.168.217.128

Обратите внимание на некоторые вещи здесь. Мы не установили размер данных равным 1500, что является MTU, а не 1472 из-за того, что в протоколе есть несколько байтов для резервных заголовков.

Как мы видели, в каждую транзакцию автоматически добавляются 20 байтов IP и 8 байтов заголовков ICMP. Итак, 1500-28 = 1472 - это максимальный размер данных полезной нагрузки, который мы можем указать в команде ping.

Затем эти 1500 байтов сопоставляются с заголовком Ethernet и, наконец, передается датаграмма 1514 байтов.

Screenshot_7.png


Итак, что произойдет, когда этот размер данных станет больше чем 1472? Давай проверим.

Фрагментация в пинге
Фрагментация IP или фрагментация ping - это процесс, в котором пакет, размер которого превышает размер MTU, разбивается на несколько частей и передается на хост назначения. RFC 791 имеет процедуру фрагментации IP, передачи и повторной сборки пакетов.

Давайте увеличим размер полезных данных до 2000 байт и посмотрим, что произойдет.

Код:
ping –l 2000 192.168.217.128

Теперь мы видим, что фрагментация выполнена, и датаграмма разделена на два фрагмента размером 1480 и 520 байтов. Почему?

Screenshot_8.png


Первый фрагмент имеет общую длину 1500 байт, но объем данных составляет всего 1480, поскольку для заголовка протокола IP всегда резервируется 20 байт, а второй фрагмент имеет размер 520 байт в размере данных полезной нагрузки.

Первый фрагмент = 1480 (размер данных) + 20 (заголовок IP)

Второй фрагмент = 520 (размер данных) + 20 (заголовок IP) + 8 (заголовок ICMP)


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

Screenshot_9.png


Теперь мы раздвигаем эти пределы до максимального размера.
Код:
ping –l 65500 192.168.217.128

Screenshot_10.png


Здесь датаграмма разбита на несколько (44) фрагментов по 1480 байтов каждый, а последний пакет имеет размер 408 (минус 28 = 380 байтов) байтов.

Вы не должны запутаться здесь. 65500 - это максимальный размер полезной нагрузки, который мы можем указать в ping.

Screenshot_10_2.png


Однако каждый из 44 кадров имеет размер 1500 байт, а последний кадр составляет 388 + 20 + 8 байт, что составляет 66416 байт. Следовательно, совокупный размер дейтаграммы пакета может составлять максимум 66416 байтов.

Добавьте дополнительные 14 байтов заголовка Ethernet, и получится: 67,046 байтов.

Аномалия в пинге
Давайте сосредоточимся на случае, когда размер полезной нагрузки указан как 0. Давайте посмотрим, что протоколы делают с 0 байтами данных.

Код:
ping –l 0 192.168.217.128
Код:

Screenshot_11.png


Как и ожидалось, запрос идет с 42 байтами (20 + 8 + 14) с 0 байтами данных, но подождите, почему ответ возвращается как 60 байт?

Анализируя шестнадцатеричный дамп, мы видим, что система Linux отвечает с 18 нулевыми байтами данных.

Screenshot_12.png


Если мы укажем ping –s 0 на машине Linux, возможно, мы получим какой-то ответ.

Screenshot_13.png


Итак, в терминале мы видим «ping с 0 (28) байтами данных», что означает 28 байтов IP, плюс заголовок ICMP и 0-байтовые данные. НО, Wireshark показывает нам что-то размером 60 байтов и снова добавил дополнительные 18 байтов.

Screenshot_14.png


Оказывается, что эти 18 байтов являются байтами заполнения Ethernet, и именно поэтому возникла эта аномалия. IEEE 802.3 добавляет дополнительные байты, если данные меньше 18 байтов в случае Linux, известные как байты дополнения.

Укажем данные в диапазоне: 1 <x <18, например, 10 байтов. Давай посмотрим что происходит.

Screenshot_15.png


В Wireshark мы видим, что размер по-прежнему составляет 60 байт. И 10 байтов были записаны шестнадцатеричными значениями от 0 до 9, в то время как остальные из них по-прежнему нулевые байты.

Screenshot_16.png


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

Это было интересной аномалией и заставило нас понять некоторые детали различия стандартов IEEE 802.3 в Windows и Linux.

Перевод:
 
Последнее редактирование:
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!