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

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

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

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

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

Мы начнем с самого начала: рассмотрим пакет на уровне битов. В главе 8, “Исследование полей IP-заголовка”, будет рассказано, как исследовать пакет в тех редких случаях, когда анализатор пакетов не в состоянии справиться с этой задачей. В следующих главах 9, “Анализ заголовков вложенных пакетов”, и 10, “Практический анализ”, описываются методы исследования пакетов на уровне полей. Как мы уже убедились на примере стека протоколов TCP/IP, невозможно сказать, что неправильно, не зная, как должно быть правильно. То же самое касается и полей пакетов. Затем в главе 11, “Необычный трафик”, мы перейдем к следующему уровню анализа пакетов, рассматривая их как единое целое. Другими словами, мы будем определять предназначение конкретных пакетов. Будет рассмотрено несколько реальных примеров трафика, перехваченного с помощью TCPdump, а также наборы пакетов, которые применялись при некоторых атаках. В завершающей эту часть главе 12, “Создание фильтров TCPdump”, будет подробно рассказано о некоторых реальных случаях анализа трафика. С помощью методов пассивного исследования трафика мы постараемся разобраться, использовалась подмена IP-адресов или действия на самом деле осуществлялись из соответствующих источников.

Операции в фоновом режиме

Как уже не раз указывалось в этой книге, системы обнаружения вторжений позволяют выявить определенные отклонения в передаваемом трафике согласно предопределенным для в них сигнатурам. Хотя и существуют NIDS, которые могут быть настроены на динамический перехват всех пакетов, следующих за подозрительным, но все остальные пакеты, которые не касаются текущей проблемы, при этом не сохраняются. Вот почему мы пропагандируем использование TCPdump или другого подобного средства для фонового контроля за проходящим трафиком. Ведь могут возникнуть опасные ситуации, которые не описаны в сигнатурах систем обнаружения вторжений.

Много лет назад, когда я работал в группе CERT военного ведомства, мы получили по электронной почте письмо от администратора другой сети, в котором он утверждал, что один из компьютеров нашей сети был использован для взлома компьютера его сети. Он предоставил сведения о дате, времени, компьютере - отправителе вредоносных пакетов и его IP-адрес. Этот администратор также сообщил крайне полезную информацию о том, что, по его мнению, в файл паролей нашего хоста была добавлена несанкционированная учетная запись для пользователя по имени Darren. Мы немедленно расследовали жалобу и обнаружили, что указанный в сообщении IP-адрес был статическим IP-адресом из диапазона IP-адресов, выделенных для нашей сети. Напомню, что это было много лет назад, когда протокол DHCP еще не приобрел широкой популярности. Владельцем компьютера с этим IP-адресом был менеджер с безукоризненной репутацией, который казался противоположностью принятому стереотипу хакера. После небольшого расследования мы узнали, что у этого человека есть сын - подросток, которого зовут Даррен (Darren). Без какого-либо чувства вины или стыда менеджер охотно рассказал офицеру контрразведки, что он дал своему сыну номер учетной записи, имя пользователя и пароль. Конечно, он горячо возражал против утверждения, что его сын является хакером.

Нам были нужны доказательства. Мы решили просмотреть записи TCPdump за несколько дней до и после случившегося инцидента. Мы обнаружили, что с интересующего 1Р-адреса было установлено соединение с атакованным компьютером чужой сети, а также пользователь заходил без преувеличения на сотни порнографических сайтов. Тем не менее все эти действия пользователя не вызвали тревоги системы обнаружения вторжений. И только информация, сохраненная с помощью TCPdump, позволила нам определить обоснованность жалобы.

Рассмотренную ситуацию можно сравнить с системой безопасности в супермаркетах. Большинство из них оснащены охранной сигнализацией, которая срабатывает при взломе, 136 Часть II. Анализ трафика и устройствами, поднимающими тревогу при попытке вынести товар с неоткрепленной биркой. Таким образом, тревога поднимается при определенных обстоятельствах. Но, кроме этого, в различных местах супермаркетов установлены видеокамеры. Эти камеры фиксируют все события. Я помню репортаж о поимке известного похитителя детей. Он использовал свою кредитную карточку при покупке товаров в супермаркете. Камеры сохранили его изображение вместе с похищенным ребенком. Поэтому, хотя его действия и не вызвали немедленной тревоги, но пленка постоянно работающей видеокамеры позволила раскрыть ®; преступление.

Зачем нужен анализ содержимого пакетов

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

В качестве примера можно привести программу sidestep, которая была создана Робертом Грехэмом (Robert Graham) - руководителем технического отдела компании NIDS. С помощью этой программы автор хотел продемонстрировать, что, так как системы обнаружения вторжений должны уметь различать протоколы, используемые при передаче пакетов, то они не выявят скрытого сканирования. Появился даже специальный термин network grep (packet grep), описывающий системы обнаружения вторжений, которые просто ищут в трафике строку символов. Эта строка служит в качестве сигнатуры обозначения опасного пакета (с помощью UNIX-команды grep осуществляется поиск заданной строки символов в тексте или файле). Если система обнаружения вторжений не способна различать пакеты разных протоколов, то для ее обмана хакеру достаточно провести манипуляции с полезной нагрузкой пакетов.

Программа sidestep может быть запущена в скрытом режиме для различных протоколов, например DNS, RPC и др. При работе с DNS sidestep запрашивает DNS-сервер о запущенной версии BIND. Если не установлен запрет на отправку подобных ответов, DNS-сервер отвечает на этот запрос. Большинство систем обнаружения вторжений выявляют DNS-запрос о версии BIND, отправленный в стандартном формате. При этом осуществляется поиск строки “07version04bind”. Числовые приставки, называемые ярлыками, всего лишь указывают на количество символов в следующем слове.

В RFC 1035 описано использование указателей в полезной нагрузке сообщений DNS. Согласно этому документу указатели применяются в ответах службы DNS, которые содержат несколько записей с повторяющейся информацией. Например отправляется запрос на определение IP-адресов нескольких хостов сети veryveryverylongname. Если в первой записи ответа содержится имя хоста hostl .veryveryverylongname . com, то во второй записи вместо полного отве та hostl.veryveryverylongname.com может быть использовано имя хоста host2 плюс указатель на расположение строки veryveryverylongname.com в первой записи. Очевидно, что это позволяет значительно сократить размер ответа. Более подробное описание использования указателей в запросах DNS содержится в разделе “DNS-запросы программы sidestep”.

Программа sidestep позволяет продемонстрировать использование указателей не в ответах, а в запросах DNS с целью скрыть истинное назначение запроса. Указатели позволяют отказаться от необходимости последовательного порядка слов ‘Version” и “bind” в DNS-запросе. Теперь порядок их расположения в запросе может быть любым. Значение будет иметь только то, как запрос “расшифровывается” на DNS-сервере. DNS-сервер отвечает на подобный запрос, т.е. сигнатура системы обнаружения вторжений “07version04bind” оказывается абсолютно бесполезной.

До того как был раскрыт механизм работы программы sidestep, я пытался сделать это самостоятельно. Я запускал программу в скрытом режиме и использовал Ethereal для отслеживания проходящего трафика. Ethereal прекрасно справляется с идентификацией пакетов в обычном формате со стандартными значениями, но при определении смысла операций в скрытом режиме это средство оказалось недееспособным. Поэтому я начал разбирать передаваемые пакеты по битам и вчитываться в документы RFC. Б большинстве случаев нашим читателям не потребуется проводить такое исследование, современные анализаторы пакетов позволят точно определить предназначение пакетов. Тем не менее в редких случаях, когда программные средства ничем не смогут помочь, вы будете полностью зависеть от собственного умения разбираться в содержимом пакетов. Если вы все еще сомневаетесь в необходимости изучения материала этой главы, то подумайте, насколько понятней станет вам работа различных протоколов.

DNS-запросы программы sidestep

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

Стандартный запрос

Давайте рассмотрим отчет TCPdump о действиях программы sidestep при использовании стандартного запроса (здесь приведен стандартный отчет TCPdump, а также отчет в шестнадцатеричном формате).

12:39:30.027400 10.100.100.201.1128 > DNS.SERVER.domain : 10+ TXT CHAOS)?

’Ъ version.bind. (30)

4500 003a 052c 0000 8011 c056 0a64 64c9 E..:.,.....V.dd.

0a64 6402 0468 0035 0026 6325 <000a 0100 .....h.5.&c%....

0001 0000 0000 0000 0776 6572 7369 6f6e .........version

0462 696e 6400 0010 0003> .bind.....

В представленном первым стандартном отчете TCPdump хост 10.100.100.201 отправляет запрос на UDP-порт 53 (domain) сервера DNS. SERVER. Идентификационный номер запроса - 10, кроме того, задана рекурсия. При этом запрашиваются данные записей TXT и CHAOS, а также версия BIND (version. bind).

Теперь обратимся к отчету об этом же запросе в шестнадцатеричном формате. DNS-часть пакета выделена символами < и >. Для всех DNS-запросов предопределен одинаковый формат: последовательность частей запроса, после которой установлено значение 00. В IP-адресах и именах хостов имена узлов разделяются точками. Например, если нужно найти IP-адрес для хоста www.yahoo.com, то генерируемый DNS-запрос будет рассматривать имя хоста как последовательность частей - www, yahoo и com. Указанию каждой части предшествует значение байта (byte count) - число байтов, которые занимает следующая часть адреса.

Запрос version.bind, создаваемый в обычном режиме работы программы sidestep, в шестнадцатеричном формате выглядит следующим образом.

0776 6572 7369 6f6e 0462 696е 6400

Жирным шрифтом выделены значения байтов, соответствующие значениям ярлыков. Первый ярлык 07 означает, что первая часть запроса занимает 7 байт. В данном случае следующие после 07 шестнадцатеричные символы являются ASCII-значениями букв слова ‘Version”. Затем следует ярлык 04, указывающий, что следующая часть запроса занимает 4 байт - ASCII-символы слова “bind”. Завершает запрос ярлык 00.

Для каждого запроса службы DNS должен быть указан тип и класс запроса. Для этого используются 2-байтовые поля. Значения различных типов и классов запросов DNS можно найти в RFC 1035. Для запроса о версии BIND типом запроса является TXT (десятичный код 16, представленный шестнадцатеричным значением 0010), а классом - CHAOS (десятичный код 3, представленный шестнадцатеричным значением 00 0 3). DNS-сервер, на котором не установлено ограничений на выдачу сведений о версии BIND, ответит на данный запрос.

Скрытый запрос

Теперь рассмотрим отчет TCPdump о действиях программы sidestep при отправке скрытого запроса.

12:39:56.674320 10.100.100.201.1129 > DNS.SERVER.domain : 42 (32)

4500 003с 0577 0000 8011 С009 0а64 64с9 E..<.w.......dd.

0а64 6402 0469 0035 0028 е445 <002а 0000 .....i.5.(.E.*..

0001 0000 0000 0000 0756 6572 7369 6f6e .........version

cOla 0010 0003 0442 494e 4400> .......BIND

V V

Pointer 26 26 Bytes

bytes into DNS Payload

Рассмотрим отчет в шестнадцатеричном формате. Жирным шрифтом выделен текст запроса в скрытом режиме. Как и раньше, запрос начинается с ярлыка 07, после которого указано первое слово запроса, но вместо слова ‘Version” из предыдущего примера теперь используется слово “Version”. Так просто можно обмануть любое программное обеспечение, которое при поиске соответствий не выполняет преобразований прописных (строчных) букв.

Это еще не вся хитрость. Посмотрим на значение следующего байта: сО. Максимальное значение ярлыка равно 63, а шестнадцатеричному числу сО соответствует двоичное число 192. Если значение старших полубайтов ярлыка равно 1 (шестнадцатеричное с), то оно интерпретируется как указатель. Указатель определяет смещение байтов в сообщении DNS, т.е. место, где находится истинное значение ярлыка (или другого указателя). В данном случае значением указателя является шестнадцатеричное число 1а, которое соответствует десятичному значению 26. Таким образом, для того, чтобы найти значение следующей части запроса, нам следует отсчитать 26 байт от начала сообщения DNS (в отчете TCPdump сообщение DNS ограничено символами < и >).

Отсчитав 26 байт от начала сообщения DNS, мы попадаем на строку 0442 494е 4400. Ярлык 04, как и ожидалось, указывает на последующие 4 байт для передачи строки “BIND”. Запрос завершается ярлыком 00. Итак, указатель дает ссылку на продолжение строки запроса. Мы снова получили строку “0010 0003”, которая обозначает тип запроса TXT и класс CHAOS. DNS-сервер отправляет ответ о запущенной версии BIND.

Программу sidestep можно получить по адресу www. robertgraham. com/tmp/ sidestep.html.

Введение в исследование пакетов с помощью TCPdump

При запуске программы TCPdump в обычном режиме сохраняются наиболее важные поля пакетов. Большинство полей содержатся в регистрируемых по умолчанию первых 68 байт любого пакета ( 14 байт заголовка кадра Ethernet и оставшаяся часть IP-дейтаграммы). Содержимое всех полей по умолчанию не отображается, для этого нужно запустить tcpdump с параметром командной строки -х. До начала любого вида анализа пакетов следует изучить стандартные форматы заголовков пакетов для таких протоколов стека TCP/IP, как IP, TCP, UDP и ICMP.

Рассмотрим следующий отчет как пример выдачи результатов работы TCPdump в шестнадцатеричном формате (используется параметр командной строки -х).

11:55:52.069484 192.168.143.5 > 192.168.143.101: icmp: echo request

4500 0054 064b 0000 4001 bcl2 c0a8 8f05

C0a8 8f65 0800 620a 850a 0000 889f 4b39

510f 0100 0809 OaOb OcOd OeOf 1011 1213

1415 1617 1819

На первый взгляд, выдается бессмысленный набор цифр и символов. Давайте приступим к методичному изучению выданного результата. Во-первых, как можно было догадаться из названия режима, каждый представленный символ является шестнадцатеричным. Значение каждого шестнадцатеричного символа может быть от 0 до Oxf, что соответствует двоичным значениям от 0 до 15 (напомним, что приставка Ох обозначает шестнадцатеричную систему счисления). Для хранения каждого шестнадцатеричного символа используется 4 бит (полубайт). Следовательно, два шестнадцатеричных символа составляют байт данных. Б каждой строке отчета TCPdump содержится по 16 байт данных или по 32 шестнадцатеричных символа.

Выдача отчета в шестнадцатеричном формате значительно информативнее стандартного отчета TCPdump. В данном случае мы видим заголовок IP-дейтаграммы, а далее следует вложенный пакет какого-то протокола. На рис. 7.1 представлен стандартный формат ІР-заголовка, который мы уже рассматривали в этой книге. Перед тем как двинуться дальше, давайте проверим, можем ли мы найти то или иное поле. Например, первое поле ІР-заголовка длиной в 4 бит указывает на использованную версию протокола IP. Если мы посмотрим на предыдущий отчет в шестнадцатеричном формате, то увидим, что значение первого шестнадцатеричного символа равно 4. Таким образом, используется версия 4 протокола IP.

Это было довольно просто. Попробуем что-то посложнее. Еще одним важным полем ІР-заголовка является поле протокола, указывающее на протокол, пакет которого следует после ІР-заголовка. Это 8-битовое поле можно найти в третьей строке нашей схемы ІР-заголовка (см. рис. 7.1). Эта схема отличается от отчета TCPdump в шестнадцатеричном формате, так как каждая строка схемы соответствует 32 бит данных (4 байт). Тем не менее мы можем найти значение поля “Protocol”, отсчитав нужное смещение от начала заголовка (не забывайте, что счет начинается с 0). Итак, каждая строка содержит по 4 байт, значит, поле “Protocol” занимает 9-й байт ІР-заголовка. Шестнадцатеричное значение этого поля в отчете TCPdump равно 01. Это означает, что в данную дейтаграмму вложено сообщение протокола ICMP. Другими стандартными значениями этого поля являются Об для протокола TCP и шестнадцатеричное значение 11 (десятичное 17) для протокола UDP.

Где заканчивается ІР-заголовок

Только что мы повторили, как определять протокол, использованный для формирования вложенного в IP-дейтаграмму пакета. Это очень важный момент при анализе пакетов. Следующей важной проблемой является определение окончания ІР-заголовка и начала других частей дейтаграммы. Длина стандартного ІР-заголовка без параметров (например, маршрутизации от источника) составляет 20 байт. Длина ІР-заголовка указывается в младшем полубайте нулевого байта ІР-заголовка. В отчете TCPdump это шестнадцатеричный символ, следующий после номера версии IP. В нашем случае он равен 5. Как это согласуется с нормальной длиной 20-байтового заголовка? На самом деле длина ІР-заголовка указывается с.помощью 32-битовых слов, т.е. значение поля следует умножить на 4.

Хотя было бы здорово и намного проще, если бы все многочисленные длины полей указывались бы в байтах, но это не соответствует действительности. Можно задуматься (или даже посетовать), почему мудрые создатели стека TCP/IP не соблаговолили стандартизировать всех длины и указывать их в байтах? Наиболее вероятным объяснением является то, что при создании TCP/IP много лет тому, программные и аппаратные средства работали на значительно меньших скоростях и требовалось значительно больше времени на отправку даже нескольких битов. Идея заключалась в том, что если сжимать количество битов, то они будут обрабатываться или отправляться значительно быстрее. Вот почему данное указание длины в битах имеет определенный смысл, хотя и может показаться нелепой случайностью.

Рис. 7.1. Формат IP-заголовка

Итак, теперь мы знаем длину 1Р-заголовка - 20 байт, поэтому можно отсчитать 20 байт в отчете ТСРсІитр (шестнадцатеричный формат). При этом можно не задумываться о смещении и не нужно начинать счет с нуля. Мы просто отсчитываем 20 байт от начала отчета. В первой строке содержится 16 байт, следовательно, нужно добавить к ним еще 4 байт из второй строки, и мы найдем нужное место, где заканчивается 1Р-заголовок и начинается заголовок ІСМР-пакета. В нашем случае ІСМР-заголовок начинается двумя байтами 0 8 0 0.

Другие поля с указанием длины

Рассмотрим другие поля 1Р-дейтаграммы, в которых указывается длина данных. Очевидно, нужно знать, как интерпретировать их значения для правильного анализа пакета.

Длина 1Р-дейтаграммы

Еще одним важным полем 1Р-заголовка является поле, в котором содержится общая длина 1Р-дейтаграммы. Значение длины указано в байтах, поэтому никаких преобразований не требуется. Это поле занимает второй и третий байты ІР-заголовка. Единственная сложность заключается в преобразовании шестнадцатеричного значения в десятичное.

Преобразование шестнадцатеричных значений в десятичные

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

1. Определите количество шестнадцатеричных символов поля.

2. Начинайте с крайнего справа символа.

3. Установите соответствие для каждого символа числу 16, степень которого увеличивается на единицу для каждого следующего символа, начиная со степени 0.

4. Перемножьте числа и установленные им в соответствие числа 16, возведенные в разные степени. Сложите все произведения.

Рассмотрим наш конкретный случай и преобразуем шестнадцатеричное значение 0054 общей длины IP-дейтаграммы в десятичный формат.

1. Длина поля для хранения общей длины IP-дейтаграммы составляет 16 бит.

2. Всего есть 4 шестнадцатеричных символа.

3. Начинаем с крайнего справа символа (4).

4. Устанавливаем соответствия числу 16 с возрастающими степенями, начиная со степени 0 (от 16° до 163).

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

163 1 62 1 61 16°

0 0 5 4

5*161 + 4*160 = 84

В этом примере мы рассматривали поле, хранящее значение длины. У нас было 4 шестнадцатеричных символа, так как длина пол я равна 16 бит. Установка соответствий для числа 16 с различными степенями потребовалась только для двух крайних справа символов, так как только они отличались от 0. Сумма двух произведений дала нам конечный результат 84.

Длина заголовка ТСР-сегмента

Как и IP-заголовок, заголовок ТСР-сегмента тоже состоит из нескольких полей. Шестнадцатеричное значение длины TCP-заголовка указано как значение полубайта в виде 32-битового слова. Это значение, как и значение длины IP-заголовка, необходимо умножить на 4, чтобы получить значение в байтах. ТСР-заголовок без дополнительных параметров имеет длину 20 байт. Значение длины TCP-заголовка содержится в старшем полубайте 12-го байта TCP-заголовка. Это важное значение, так как оно позволяет определить, где заканчивается ТСР-заголовок и начинаются сами TCP-данные (полезная нагрузка).

Ниже представлен пример отчета о прохождении стандартного ТСР-пакета без дополнительных параметров в обычном и шестнадцатеричном формате.

15:43:40.705372 1.2.3.4.63220 > 4.3.2.1.139: S 776342897:776342897(0) win 3072

4500 0028 e34f 0000 ЗаОб е534 0102 0304 0403 0201 <f6f4 008b 2е46 0d71 0000 0000 5002 0с00 b85f 0000>

TCP-сегмент выделен символами < и >. Жирным шрифтом выделено значение длины заголовка ТСР-сегмента, которое, как обычно, равно 5. После умножения этого значения на 4 мы получаем стандартную длину TCP-заголовка - 20 байт.

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

15:48:24.620314 1.2.3.4.3088 > 4.3.2.1.139: S 1212214992:1212214992(0)

win 32120 <mss 1460,sackOK,timestamp 7748460 0,nop,wscale 0> (DF)

4500 003c lla8 4000 4006 70c8 0102 0304 0102 0304 <0cl0 008b 4840 eedO 0000 0000 a002 7d78 92b4 0000 0204 05b4 0402 080a 0076 3b6c 0000 0000 0103 0300>

В этом примере шестнадцатеричным значением длины TCP-заголовка является Оха, что соответствует десятичному значению 10. Умножив его на 4, мы получаем длину TCP-заголовка В 40 байт. Если посмотреть на строку стандартного отчета TCPdump, то мы увидим, что данный TCP-заголовок включает такие параметры, как максимальный размер сегмента (1460), выборочное подтверждение (sackOK), временная метка, заполнитель (пор) для дополнения до 4 байт и размер окна (wscale).

Увеличение фиксируемой длины

Зададим вопрос: почему мы видим только 54 байт в следующем отчете в шестнадцатеричном формате, хотя по умолчанию значение фиксируемой длины пакета составляет 68 байт?

4500 0054 064Ь 0000 4001 bcl2 с0а8 8f05

с0а8 8f65 0800 620а 850а 0000 889f 4Ь39

510f 0100 0809 0a0b 0c0d 0e0f 1011 1213

1415 1617 1819

На самом деле TCPdump дополнительно фиксирует 14 байт заголовка кадра Ethernet, хотя и не выводит их без явного указания. Для отображения сохраненной информации заголовка кадра предназначена команда tcpdump -е.

20:55:48.520619 0:10:Ь5:39:сб:93 0:10:Ь5:39:сб:9а ip 102

^192.168.143.5 > 192.168.143.101: icmp: echo request

Бывают ситуации, в которых необходимо проанализировать заголовок кадра Ethernet. Это делается при необходимости узнать МАС-адрес отправителя, чтобы определить, откуда пришел пакет - от хоста или от маршрутизатора.

В предыдущем отчете о транзакции, в которой использовался механизм инкапсуляции Ethernet, определенный в RFC 894, жирным шрифтом выделен текст, отображенный в результате применения параметра командной строки -е. Как видите, это МАС-адреса отправителя и получателя. (МАС-адрес отправителя - 0 :10 :Ь5 : 39 : сб : 93, а МАС-адрес получателя - 0 :10 :Ь5 : 39 : сб : 9а). Может показаться, что эти МАС-адреса подложные (уж слишком они похожи), но на самом деле они настоящие. Просто два компьютера с процессорами Compaq были куплены одновременно. После МАС-адресов указан тип пакета, передаваемого в данном кадре. Типами передаваемых пакетов могут быть IP, АРР и RARP. Значения этих полей хранятся в заголовке кадра. Последнее поле содержит значение длины в байтах всего кадра, включая заголовок кадра и инкапсулированные данные. В данном случае заголовок кадра составляет 14 байт, а размер вложенной IP-дейтаграммы равен 88 байт, что в сумме составляет 102 байт. Если в поле “Туре” (“Тип”) содержится значение 0x0800, это указывает на то, что после заголовка кадра инкапсулирована IP-дейтаграмма. Минимальная длина IP-дейтаграммы равняется 46 байт, а значение длины заголовка кадра согласно RFC 894 вообще ш указывается в заголовке кадра Ethernet. По умолчанию TCPdump фиксирует 68 байт передаваемого кадра, чего обычно достаточно для сохранения ІР-заголовка, заголовка вложенного пакета и небольшого количества данных. Но, если установлено большое количество параметров, будь то параметры протокола IP или параметры TCP, может оказаться, что заголовки будут сохранены не полностью.

Для увеличения установленной по умолчанию фиксируемой длины в TCPdump используется параметр командной строки -s. В качестве примера давайте определим сохранение полной дейтаграммы, передаваемой при выполнении любого действия в сети Ethernet. В этом случае нам необходимо увеличить размер фиксируемой длины до максимального размера дейтаграммы плюс заголовок кадра. Максимальная единица передачи данных в сети Ethernet равна 1500 байт. Добавив 14 байт для заголовка кадра, мы получаем значение 1514 байт. После введения команды tcpdump -s 1514 запустим программу TCPdump и проверим, сохраняется ли теперь вся информация передаваемой дейтаграммы.

4500 0054 064Ь 0000 4001 Ьс12 С0а8 8f05

с0а8 8f65 0800 620а 850а 0000 889f 4Ь39

510f 0100 0809 OaOb 0c0d 0e0f 1011 1213

1415 1617 1819 lalb lcld lelf 2021 2223

2425 2627 2829 2a2b 2c2d 2e2f 3031 3233

3435 3637

Итак, мы сохраняем передаваемые данные в шестнадцатеричном формате, и фиксируемый объем информации превышает принятый по умолчанию размер в 54 байт. Длина дейтаграммы указана во втором и третьем байтах ІР-заголовка. Шестнадцатеричное значение 0 054 этих байтов соответствует десятичному значению в 84 байт. Как мы видим, сохранены все 84 байт дейтаграммы.

Dns | Обнаружение нарушений безопасности в сетях | Исследование всего пакета


Обнаружение нарушений безопасности в сетях



Новости за месяц

  • Июль
    2021
  • Пн
  • Вт
  • Ср
  • Чт
  • Пт
  • Сб
  • Вс