Дамп трафика сети
tcpdump [-AdDefKlLnNOpqRStuUvxX] [-c количество] [-C размер_файла] [-E spi-адрес алгоритм:секрет,...] [-F файл]
[-G интервал_сек] [-i интерфейс] [-m модуль] [-M секрет] [-r файл] [-s размер_снимка] [-T тип] [-w файл] [-W число_файлов]
[-y тип_канала] [-z команда_postrotate] [-Z пользователь] [выражение]
![]() | Установка секрета для пакетов ESP IPv4 в настоящее время не поддерживается. |
-
, утилита tcpdump использует стандартный поток ввода.![]() | Создание снимков повышенного размера ведет к увеличению времени, затрачиваемого на обработку пакетов, и, как следствие, снижает объем буферизации пакетов. Это может приводить к потере пакетов. Значение размер_снимка следует ограничить наименьшим числом, позволяющим захватывать всю требуемую информацию о протоколе. Если размер_снимка имеет нулевое значение, то утилита tcpdump будет использовать размер, необходимый для захвата полных пакетов. |
-
, утилита tcpdump использует стандартный поток вывода.![]() | Утилита tcpdump запускает эту команду параллельно с захватом макетов с использованием самого низкого приоритета, во избежание нарушения процесса захвата. |
ЗОСРВ «Нейтрино»
aarch64, arm, armv7, e2k, mips, ppc, x86
Утилита tcpdump выводит описание содержимого пакетов на сетевом интерфейсе, соответствующем указанному булевому выражению. При запуске этой утилиты с опцией -w данные из пакетов сохраняются в файл для последующего анализа; при дополнительном (или самостоятельном) использовании опции -r вместо сетевого интерфейса производится чтение из сохраненного файла пакетов. Во всех случаях утилита tcpdump обрабатывает только пакеты, сооветствующие указанному выражению.
Для получения информации об аргументе выражение см. раздел "Выражения" далее.
Если утилита tcpdump запущена без опции -c, она продолжает захват пакетов до прерывания работы по сигналу SIGINT
(который подается, например, при вводе символа прерывания, т.е. Control - C
) или SIGTERM
(обычно подается командой kill); при запуске с опцией -c утилита tcpdump захватывает пакеты до прерывания работы по сигналу SIGINT
или SIGTERM
или достижения определенного количества обработанных пакетов.
По окончании захвата пакетов утилита tcpdump сообщает следующие количества:
Для чтения пакетов из сетевого интерфейса сети могут потребоваться специальные полномочия:
/dev/nit
или /dev/bpf*
. /dev/le
. Однако в некоторых версиях Solaris этого недостаточно для работы утилиты tcpdump в режиме прослушивания трафика; в этих версиях Solaris для захвата в режиме прослушивания трафика необходимо войти в систему с учетной записью root или установить tcpdump в качестве setuid для root. Следует отметить, что на многих (вероятно, всех) интерфейсах невозможно увидеть исходящие пакеты, если захват не выполняется в режиме прослушивания трафика, поэтому захват в другом режиме может оказаться не очень удобным. CAP_NET_RAW
, и содержит код, который позволяет присваивать эти биты функций определенным учетным записям и устанавливать эти биты для начальных процессов пользователей, выполняемых при входе в систему; в этом случае необходим бит CAP_NET_RAW
для захвата и бит CAP_NET_ADMIN
для перечисления сетевых устройств с помощью, например, опции -D). /dev/bpf*
(в системах, не имеющих устройства клонирования BPF) или каталогу /dev/bpf
(в системах, имеющих это устройство). В системах BSD с поддержкой "devfs" (в том числе Mac OS X) в дополнение к установке принадлежности или полномочий на работу с устройствами BPF пользователем с полномочиями суперпользователя может потребоваться конфигурирование "devfs" для установки принадлежности и полномочий при каждой загрузке системы, если такая операция поддерживается в этой системе; если такая поддержка отсутствует, то потребуется найти другой способ для выполнения этой операции в процессе загрузки. Для чтения сохраненного файла пакетов специальные полномочия не требуются.
Выражения
Выражение в командной строке используется для отбора захватываемых пакетов. Если выражение не указано, создается дамп всех пакетов в данной сети. Если выражение указано, то в дамп вносятся только пакеты, для которых это выражение оказывается истинным.
Выражение состоит из одного или нескольких примитивов, каждый из которых обычно содержит идентификатор (имя или номер), перед которым находится один или несколько спецификаторов. Существуют следующие типы спецификаторов:
Помимо вышеперечисленных, имеется несколько специальных "примитивных" ключевых слов, не соответствующих описанному шаблону:
и арифметические выражения. Все они описаны далее.
С помощью слов and, or и not можно комбинировать примитивы и создавать более сложные выражения фильтров. Пример: host xyz and not port ftp and not port ftp-data. Для сокращения ввода вручную можно не указывать спецификаторы в каждом из тех сочетаний, для которых они одинаковы. Например, выражение
tcp dst port ftp or ftp-data or domain
полностью аналогично выражению
tcp dst port ftp or tcp dst port ftp-data or tcp dst port domain.
Допустимые примитивы:
/etc/ethers
или номером (формат номера см. в описании ethers(3N)). /etc/networks
и т.д.) или номер сети. /etc/services
. (Cм. описание tcp(4P) и udp(4P).) ![]() | Идентификаторы tcp, udp и icmp одновременно являются ключевыми словами, поэтому их следует отделять обратной косой чертой (\), что в командном интерпретаторе csh будет выглядеть как \\. Этот примитив не относится к последовательности заголовка протокола. |
![]() | Первое ключевое слово vlan в выражении изменяет смещения декодирования для остальной части выражения, поскольку предполагается, что данный пакет является пакетом VLAN. Для фильтрации иерархий VLAN можно использовать несколько выражений vlan[идентификатор_vlan]. Каждый экземпляр этого выражения увеличивает смещения фильтра на 4. |
![]() | Первое ключевое слово mpls в выражении изменяет смещения декодирования для остальной части выражения, поскольку предполагается, что данный пакет является IP-пакетом с инкапсуляцией MPLS. Для фильтрации иерархий MPLS можно использовать несколько выражений mpls[номер_метки]. Каждый экземпляр этого выражения увеличивает смещения фильтра на 4. |
![]() | Первое ключевое слово pppoes в выражении изменяет смещения декодирования для остальной части выражения, поскольку предполагается, что данный пакет является пакетом сеанса PPPoE. |
![]() | Первое ключевое слово lane в выражении изменяет смещения декодирования для остальной части выражения, поскольку предполагается, что данный пакет является пакетом Ethernet в эмуляции LANE или пакетом LANE LE Control. Если аргумент lane не указан, то при проверке пакет считается пакетом с инкапсуляцией LLC. |
![]() | Типы протоколов высокого уровня tcp, udp и др. применяются только для IPv4 и не применяются для IPv6 (ожидается исправление). |
Примитивы можно комбинировать следующими способами:
Отрицание имеет наивысший приоритет. Чередование и конкатенация имеют равный приоритет и анализируются слева направо. Следует отметить, что для конкатенации в настоящее время операторы and требуется указывать явно (не подразумевать их).
Если идентификатор указан без ключевого слова, используется последнее указанное ключевое слово. Пример: not host vs and ace является сокращением выражения not host vs and host ace которое не следует путать с выражением not ( host vs or ace )
Передать утилите tcpdump аргументы выражения можно в форме одного аргумента или нескольких аргументов, по собственному усмотрению. Как правило, если выражение содержит метасимволы командного интерпретатора, то его проще перенести как единственный, обрамленный кавычками, аргумент. Если аргументов несколько, то перед синтаксическим анализом они соединяются с пробелами.
Выходной формат
Выходные данные утилиты tcpdump зависят от протокола. Далее приведено краткое описание большинства форматов с примерами.
Заголовки канального уровня
Если указана опция -e, то заголовок канального уровня выводится. Для сетей Ethernet выводятся адреса источника и назначения, протокол и длина пакета.
Для сетей FDDI при использовании опции -e утилита tcpdump выводит поле управления кадрами, адреса источника и назначения и длину пакета. Поле управления кадрами определяет интерпретацию остальной части пакета. Стандартные пакеты (например, содержащие дейтаграммы IP), являются "асинхронными" ("async") пакетами со значением приоритета от 0 до 7, например async4. Каждый такой пакет должен включать в себя пакет 802.2 LLC (Logical Link Control – управление логическим каналом); заголовок LLC выводится в том случае, если он не является дейтаграммой ISO или так называемым пакетом SNAP.
Для сетей Token Ring при использовании опции -e утилита tcpdump выводит поля управления доступом и управления кадрами, адреса источника и назначения и длину пакета. Как и в случае сетей FDDI, предполагается, что каждый пакет содержит пакет LLC. Независимо от использования опции -e, для пакетов с маршрутом от источника выводится информация о маршруте от источника.
Для сетей 802.11 при использовании опции -e утилита tcpdump выводит поля управления кадрами, все адреса в заголовке 802.11 и длину пакета. Как и в случае сетей FDDI, предполагается, что каждый пакет содержит пакет LLC.
![]() | Перед чтением нижеследующего описания рекомендуется ознакомиться с алгоритмом сжатия SLIP, описанным в RFC 1144. |
Для каналов SLIP выводится индикатор направления (I для входящего, O для исходящего), тип пакета и информация о сжатии. Первым выводится тип пакета. Существует три типа таких пакетов: ip, utcp, ctcp. Другая информация о канале для пакетов ip не выводится. Для TCP-пакетов после типа пакета выводится идентификатор соединения. Если пакет является сжатым, выводится его кодированный заголовок. Особые случаи выводятся в форме *S+n и *SA+n, где n – число, на которое изменился номер последовательности (или номер последовательности и данные подтверждения). Если случай не является особым, выводятся изменения в количестве ноль или более. Изменение обозначается символом U (указатель срочности), W (окно), A (подтверждение), S (номер последовательности) и I (идентификатор пакета), за которыми следует дельта (+n или -n) или новое значение (=n). В конце выводится объем данных в пакете и длина сжатого заголовка.
Например, следующая строка описывает исходящий сжатый TCP-пакет с неявным идентификатором соединения; подтверждение изменилось на 6, порядковый номер – на 49, идентификатор пакета – на 6; имеется 3 байта данных и 6 байт сжатого заголовка:
O ctcp * A+6 S+49 I+6 3 (6)
Пакеты ARP/RARP
Выходные данные ARP/RARP содержат тип запроса и его аргументы. Предполагается, что формат не требует дополнительных пояснений. Ниже приведен короткий пример запуска rlogin с хоста rtsg на хост csam:
arp who-has csam tell rtsg arp reply csam is-at CSAM
Первая строка означает, что хост rtsg отправляет ARP-пакет с запросом Ethernet-адреса хоста csam в Интернете. В ответ csam отправляет свой Ethernet-адрес (в данном примере Ethernet-адреса указаны в верхнем регистре, а IP-адреса – в нижнем регистре).
Если выполнить команду tcpdump -n, то избыточность будет меньше:
arp who-has 128.3.254.6 tell 128.3.254.68 arp reply 128.3.254.6 is-at 02:07:01:00:01:c4
Если выполнить команду tcpdump -e, то станет видно, что первый пакет является широковещательным, а второй имеет тип "точка-точка":
RTSG Broadcast 0806 64: arp who-has csam tell rtsg CSAM RTSG 0806 64: arp reply csam is-at CSAM
Для первого пакета это означает, что Ethernet-адрес источника – RTSG, адрес назначения – широковещательный Ethernet-адрес, поле типа содержит шестнадцатеричное значение 0806 (тип ETHER_ARP), а общая длина составляет 64 байта.
TCP-пакеты
![]() | Перед чтением нижеследующего описания рекомендуется ознакомиться с протоколом TCP, описанным в RFC 793. Если читатель не знаком с этим протоколом, то описание и утилита tcpdump будут для него малополезны. |
Общий формат строки протокола TCP:
src > dst: flags data-seqno ack window urgent options
Значения src и dst представляют собой IP-адреса и порты источника и назначения. Значение flags представляет собой комбинацию S (SYN), F (FIN), P (PUSH), R (RST), W (ECN CWR) и E (ECN-Echo) или одиночный символ . (флаги отсутствуют). Значение data-seqno описывает часть пространства последовательности, занятое данными в пакете (см. пример далее). Значение ack является номером последовательности следующих данных, ожидаемых для другого направления на этом соединении. Значение window представляет собой размер пространства в приемном буфере в байтах, доступного для другого направления на этом соединении. Значение urg указывает на то, что в пакете содержатся срочные данные. Опции options представляют собой опции TCP и выводятся в угловых скобках (например, <mss 1024>).
Значения src, dst и flags присутствуют всегда. Другие поля зависят от содержания заголовка пакета протокола TCP и выводятся только при необходимости.
Ниже представлен начальный фрагмент rlogin с хоста rtsg на хост csam:
rtsg.1023 > csam.login: S 768512:768512(0) win 4096 csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096 rtsg.1023 > csam.login: . ack 1 win 4096 rtsg.1023 > csam.login: P 1:2(1) ack 1 win 4096 csam.login > rtsg.1023: . ack 2 win 4096 rtsg.1023 > csam.login: P 2:21(19) ack 1 win 4096 csam.login > rtsg.1023: P 1:2(1) ack 21 win 4077 csam.login > rtsg.1023: P 2:3(1) ack 21 win 4077 urg 1 csam.login > rtsg.1023: P 3:4(1) ack 21 win 4077 urg 1
Первая строка означает, что TCP-порт 1023 на rtsg отправляет пакет для login порта на csam. Символ S указывает на то, что установлен флаг SYN. Пакет имел порядковый номер 768512 и не содержал данных. (Используется нотация первый:последний(число_байт), что означает: "порядковые номера с первого до последнего, не включая его, что составляет число_байт пользовательских данных"). Сообщение ACK отсутствует, доступное окно приема составляло 4096 байт, использовалась опция максимального размера сегмента с запросом mss, равного 1024 байтам.
Csam ответил аналогичным пакетом, но с сообщением ACK для сообщения SYN, полученного от rtsg. Затем rtsg подтверждает SYN, поступившее от csam. Символ . означает, что флаги не установлены. Пакет не содержал данных, поэтому номер последовательности данных отсутствует. Следует отметить, что номером последовательности сообщения ACK является малое целое число (1). При первом появлении "переговоров" TCP утилита tcpdump выводит порядковый номер из пакета. Для последующих пакетов диалога выводится разность между порядковым номером текущего пакета и вышеупомянутым начальным номером последовательности. Это означает, что порядковые номера после начального можно интерпретировать как относительные позиции в байтах в потоке данных диалога (первый байт данных в каждом направлении имеет номер 1). Опция -S переопределяет это поведение – при ее использовании выводятся исходные порядковые номера.
На шестой строке rtsg отправляет на csam 19 байт данных (байты 2–20 на стороне диалога rtsg -> csam). В пакете установлен флаг PUSH. На седьмой строке csam сообщает о получении данных, отправленных от rtsg, до байта 21 (не включая его). Большая часть этих данных, очевидно, находится в буфере сокета, поскольку окно приема csam уменьшилось на 19 байт. Кроме того, в этом пакете csam отправляет на rtsg один байт данных. На восьмой и девятой строках csam отправляет rtsg два байта срочных данных push.
Если снимок был настолько маленьким, что утилита tcpdump не захватила полный заголовок TCP, то она интерпретирует все имеющиеся данные и выводит строку "[|tcp]", означающую, что оставшуюся часть интерпретировать невозможно. Если заголовок содержит некорректную опцию (слишком короткую или, наоборот, выходящую за пределы заголовка), утилита tcpdump обозначает ее как неверную ("[bad opt]") и не интерпретирует остальные опции (поскольку становится невозможно определить, где они начинаются). Если длина заголовка указывает на то, что в нем присутствуют опции, но длина дейтаграммы IP недостаточна для фактического наличия опций в нем, утилита tcpdump сообщает о неверной длине заголовка ("[bad hdr length]").
Сбор TCP-пакетов с определенными комбинациями флагов (SYN-ACK, URG-ACK и т.д.)
В разделе служебных битов заголовка TCP имеется 8 битов:
CWR | ECE | URG | ACK | PSH | RST | SYN | FIN
Предположим, что требуется отследить пакеты, используемые при установлении соединения TCP. Учтем, что в TCP при инициализации нового соединения используется 3-сторонний протокол установления связи. Последовательность установления соединения с точки зрения служебных битов TCP следующая:
Требуется захватить пакеты, в которых установлен только бит SYN (шаг 1). Отметим, что пакеты из шага 2 (SYN-ACK) не требуются, требуется только начальный пакет SYN. Для утилиты tcpdump необходимо указать корректное выражение фильтра.
Вспомним структуру заголовка TCP без опций:
0 15 31 ----------------------------------------------------------------- | source port | destination port | ----------------------------------------------------------------- | sequence number | ----------------------------------------------------------------- | acknowledgment number | ----------------------------------------------------------------- | HL | rsvd |C|E|U|A|P|R|S|F| window size | ----------------------------------------------------------------- | TCP checksum | urgent pointer | -----------------------------------------------------------------
Заголовок TCP обычно содержит 20 октетов данных, если отсутствуют опции. В первой строке диаграммы представлены октеты 0–3, во второй строке – октеты 4–7 и т.д. Если считать с 0, соответствующие биты управления TCP содержатся в октете 13:
0 7| 15| 23| 31 ----------------|---------------|---------------|---------------- | HL | rsvd |C|E|U|A|P|R|S|F| window size | ----------------|---------------|---------------|---------------- | | 13th octet | | |
Рассмотрим тринадцатый октет:
| | |---------------| |C|E|U|A|P|R|S|F| |---------------| |7 5 3 0|
В нем представлены требуемые служебные биты TCP. Биты в этом октете пронумерованы от 0 до 7 справа налево; таким образом, бит PSH – это бит 3, а бит URG – бит 5.
Вспомним, что требуется захватывать только пакеты с установленным SYN. Рассмотрим изменения октета 13 при поступлении дейтаграммы TCP с установленным битом SYN в заголовке:
|C|E|U|A|P|R|S|F| |---------------| |0 0 0 0 0 0 1 0| |---------------| |7 6 5 4 3 2 1 0|
В разделе битов управления видно, что установлен только бит 1 (SYN).
Учитывая, что октет 13 представляет собой 8-битное целое число без знака в последовательности байт адреса, двоичное значение этого октета будет равно 00000010, а его десятичное представление:
7 6 5 4 3 2 1 0 0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 1*2 + 0*2 = 2
Анализ почти завершен: известно, что если установлен только бит SYN, то значение тринадцатого октета в заголовке TCP, если он представляется 8-битным целым числом без знака в последовательности байт адреса, должно быть точно равно 2.
Это отношение может быть выражено следующим образом:
tcp[13] == 2
Это выражение можно использовать в качестве фильтра для утилиты tcpdump, позволяющего отслеживать пакеты, в которых установлен только бит SYN:
tcpdump -i xl0 tcp[13] == 2
Это выражение означает: "пусть тринадцатый октет дейтаграммы TCP имеет десятичное значение 2", что и требуется.
Теперь предположим, что требуется захватывать пакеты SYN, но в данном случае не требуется проверять, установлен ли одновременно бит ACK или любой другой бит управления TCP. Рассмотрим изменения октета 13 при поступлении дейтаграммы TCP с установленными битами SYN-ACK:
|C|E|U|A|P|R|S|F| |---------------| |0 0 0 1 0 0 1 0| |---------------| |7 6 5 4 3 2 1 0|
Теперь в тринадцатом октете установлены биты 1 и 4. Двоичное значение октета 13 равно 00010010, что в десятичном виде составляет:
7 6 5 4 3 2 1 0 0*2 + 0*2 + 0*2 + 1*2 + 0*2 + 0*2 + 1*2 + 0*2 = 18
Использовать в выражении фильтра tcpdump просто выражение 'tcp[13] == 18' не получится, поскольку ему соответствуют только пакеты с установленными битами SYN-ACK, т.е. пакеты только с установленным битом SYN выбираться не будут. Отметим, что если установлен бит SYN, то состояние бита ACK и любого другого бита управления не имеет значения.
Для получения требуемого результата необходимо логически сложить (AND) двоичное значение октета 13 с каким-либо другим значением для сохранения бита SYN. Известно, что бит SYN должен быть установлен в любом случае, поэтому логически сложим значение в тринадцатом октете и бинарное значение SYN:
00010010 SYN-ACK 00000010 SYN AND 00000010 (требуется SYN) AND 00000010 (требуется SYN) -------- -------- = 00000010 = 00000010
Видно, что эта операция AND дает одинаковый результат независимо от того, установлен ли бит ACK или другой бит управления TCP. Десятичное представление значения AND (а также результат этой операции) равно 2 (00000010 в двоичной форме); таким образом, известно, что для пакетов с установленным битом SYN должно сохраняться следующее отношение:
( ( значение октета 13 ) AND ( 2 ) ) == ( 2 )
Отсюда получаем выражение фильтра tcpdump
tcpdump -i xl0 'tcp[13] & 2 == 2'
Следует отметить, что специальный символ AND ('&') в выражении необходимо экранировать от командного интерпретатора с помощью апострофов или обратной косой черты.
UDP-пакеты
Формат UDP представлен в следующем пакете rwho:
actinide.who > broadcast.who: udp 84
Это означает, что порт who на хосте actinide отправляет UDP-дейтаграмму на порт who на хосте broadcast (широковещательный Интернет-адрес). Пакет содержит 84 байта пользовательских данных.
Некоторые службы UDP распознаются (на основе номера порта источника или назначения), и выводится информация о протоколе высокого уровня. К ним, в частности, относятся запросы службы доменных имен (RFC 1034 и 1035) и вызовы Sun RPC (RFC 1050) для NFS.
Запросы к серверу имен UDP
![]() | Перед чтением нижеследующего описания рекомендуется ознакомиться с протоколом службы доменных имен, описанным в RFC 1035. |
Запросы к серверу имен имеют следующий формат:
src > dst: id op? flags qtype qclass name (len) h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)
Хост h2opolo запрашивает у сервера домена на хосте helios запись адреса (qtype=A), связанную с именем ucbvax.berkeley.edu. Запрос имеет идентификатор 3. Символ + означает, что установлен флаг recursion desired. Длина запроса составляла 37 байт, не включая заголовки протоколов UDP и IP. Операция запроса была обычной (Query), поэтому поле операции "op" отсутствует. Другая операция была бы указана между символами 3 и +. Аналогичным образом, параметр qclass был обычным (C_IN) и не указан. Другой параметр qclass был бы отображен после символа A.
Выполняется проверка на нестандартные параметры, результатом которой могут быть дополнительные значения в квадратных скобках: если запрос содержит в себе ответ, записи авторизации или раздел дополнительных записей, то отображается параметр ancount, nscount или arcount в форме [na], [nn] или [nau], где n – соответствующее количество. Если установлен какой-либо из битов ответа (AA, RA, rcode) или любой из битов, которые "должны быть нулевыми" в байтах 2 и 3, то выводится строка [b2&3=x], где x – шестнадцатеричное значение байт 2 и 3 заголовка.
Ответы сервера имен UDP
Ответы сервера имен имеют следующий формат:
src > dst: id op rcode flags a/n/au type class data (len) helios.domain > h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273) helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97)
В первом примере хост helios отвечает на запрос с идентификатором 3 от h2opolo тремя записями ответа, тремя записями сервера имен и семью дополнительными записями. Первая запись ответа имеет тип A (адрес), ее данные представляют собой IP- адрес 128.32.137.3. Общий размер ответа составляет 273 байта, не считая заголовков IP и UDP. Значение "op" ("Query") и код ответа ("NoError") не указаны, как не указан и класс записи A (C_IN).
Во втором примере хост helios отвечает на запрос 2 кодом запроса, означающим несуществующий домен ("NXDomain"), без ответов, одним сервером имен, без записей авторизации. Символ '*' означает, что установлен бит authoritative answer. Поскольку ответы отсутствуют, тип, класс и данные не отображаются.
Кроме того, существуют флаговые символы '-' (RA (возможна рекурсия) не установлен) и '|' (TC (обрезанное сообщение) установлен). Если в разделе запроса содержится не ровно одна запись, выводится строка [nq].
Следует отметить, что запросы серверу имен и его ответы обычно имеют большой размер, и размер_снимка в 68 байт может не охватывать достаточную длину пакета для вывода полной информации. Если требуется детально изучить трафик сервера имен, используется флаг -s для увеличения размера снимка. Пример: -s 128.
Декодирование SMB/CIFS
Утилита tcpdump теперь включает в себя расширенные средства декодирования SMB/CIFS/NBT для данных UDP/137, UDP/138 и TCP/139. Кроме того, выполняется базовое декодирование данных IPX и NetBEUI SMB.
По умолчанию декодирование выполняется в минимальном объеме, для расширения используется опция -v. Следует учитывать, что при использовании опции -v один пакет SMB может занимать целую страницу или более, поэтому опция -v применяется только при необходимости получения всех подробных данных.
Запросы и ответы NFS
Запросы и ответы Sun NFS (Network File System – сетевая файловая система) выводятся в следующем виде:
src.xid > dst.nfs: len op args src.nfs > dst.xid: reply stat len op results
Пример.
sushi.6709 > wrl.nfs: 112 readlink fh 21,24/10.73165 wrl.nfs > sushi.6709: reply ok 40 readlink "../var" sushi.201b > wrl.nfs: 144 lookup fh 9,74/4096.6878 "xcolors" wrl.nfs > sushi.201b: reply ok 128 lookup fh 9,74/4134.3150
Первая строка: хост sushi посылает транзакцию с идентификатором 6709 хосту wrl (обратите внимание, что число, следующее за хостом-отправителем, является идентификатором транзакции, а не портом источника). Размер запроса составляет 112 байт, не считая заголовки UDP и IP. Была выполнена операция readlink (чтение символьной ссылки) в отношении описателя файла (fh) 21,24/10.731657119. (В оптимальном случае, аналогичном данному, описатель файла можно интерпретировать как пару из старшего и младшего номеров устройства, за которой следует индексный дескриптор и номер поколения). Хост wrl отвечает ok и передает содержимое ссылки.
В третьей строке хост sushi запрашивает у хоста wrl поиск имени xcolors в файле каталога 9,74/4096.6878. Следует отметить, что выводимые данные зависят от типа операции. Предполагается, что формат при чтении совместно со спецификациями протокола NFS не требует дополнительных пояснений.
Если указана опция -v (режим вывода расширенной информации), то выводится дополнительная информация. Пример.
sushi.1372a > wrl.nfs: 148 read fh 21,11/12.195 8192 bytes @ 24576 wrl.nfs > sushi.1372a: reply ok 1472 read REG 100664 ids 417/0 sz 29388
(При использовании опции -v также выводятся поля предельного срока существования, идентификатора, длины и фрагментации заголовка IP, не представленные в этом примере). В первой строке sushi запрашивает у wrl чтение 8192 байт из файла 21,11/12.195 по смещению 24576 в байтах. Хост wrl отвечает ok; пакет на второй строке является первым фрагментом ответа, и следовательно, его длина составляет всего 1472 байта (остальные байты поступают в последующих фрагментах, но эти фрагменты не имеют заголовков NFS или UDP и поэтому могут не выводиться, в зависимости от используемого выражения фильтра). Поскольку указан флаг -v, выводятся некоторые атрибуты файла (возвращаемые вместе с данными файла): тип файла (для стандартного файла – "REG"), режим файла (в восьмеричном виде), идентификаторы пользователя и группы, размер файла.
Если указано несколько опций -v, то отображается более подробная информация.
Следует отметить, что запросы NFS имеют большой размер, и большая часть данных не будет выводиться, если не увеличить размер_снимка. Для просмотра трафика NFS рекомендуется использовать, например, опцию -s 192.
Операция RPC не определяется в пакетах ответа NFS явно. Вместо этого утилита tcpdump отслеживает "последние" запросы и сопоставляет их с ответами по идентификатору транзакции. Если ответ значительно расходится с соответствующим запросом, его синтаксический анализ может оказаться невозможным.
Запросы и ответы AFS
Запросы и ответы Transarc AFS (Andrew File System) выводятся в следующем виде:
src.sport > dst.dport: rx packet-type src.sport > dst.dport: rx packet-type service call call-name args src.sport > dst.dport: rx packet-type service reply call-name args elvis.7001 > pike.afsfs: rx data fs call rename old fid 536876964/1/1 ".newsrc.new" new fid 536876964/1/1 ".newsrc" pike.afsfs > elvis.7001: rx data fs reply rename
В первой строке хост elvis отправляет хосту pike пакет RX. Он представляет собой пакет данных RX для службы fs (fileserver, файловый сервер) и является началом вызова RPC. Вызовом RPC была запрошена операция переименования; идентификатор старого файла каталога – 536876964/1/1, старое имя файла – .newsrc.new
, идентификатор нового файла каталога – 536876964/1/1, новое имя файла – .newsrc
. Хост pike посылает ответ RPC на запрос переименования (которое было выполнено успешно, поскольку поступил пакет данных, а не пакет отмены).
В общем случае декодирование всех RPC AFS выполняется как минимум по имени вызова RPC. По крайней мере для некоторых аргументов большинства RPC AFS существует расшифровка (обычно только для "значимых" аргументов, в зависимости от значимости).
Предполагается, что формат не требует дополнительных пояснений, но может оказаться непонятным для пользователей, незнакомых с работой AFS и RX.
Если флаг -v (режим вывода расширенной информации) указан дважды, то выводятся пакеты подтверждения и дополнительная информация из заголовков, такая как идентификатор вызова RX, номер вызова, порядковый номер, серийный номер и флаги пакетов RX.
Если флаг -v указан дважды, то выводится дополнительная информация, такая как идентификатор вызова RX, серийный номер и флаги пакетов RX. Кроме того, выводится информация согласования MTU и пакетов ACK RX.
Если опция -v указана три раза, выводится индекс безопасности и идентификатор службы.
Для пакетов отмены выводятся коды ошибок, за исключением сигнальных пакетов Ubik (поскольку пакеты отмены используются для индикации голосования "да" в протоколе Ubik).
Следует отметить, что запросы AFS имеют большой размер, и большая часть аргументов не будет выводиться, если не увеличить размер_снимка. Для просмотра трафика AFS рекомендуется использовать, например, опцию -s 256.
Операция RPC не определяется в пакетах ответа AFS явно. Вместо этого утилита tcpdump отслеживает "последние" запросы и сопоставляет их с ответами по номеру вызова и идентификатору службы. Если ответ значительно расходится с соответствующим запросом, его синтаксический анализ может оказаться невозможным.
KIP AppleTalk (DDP в UDP)
Для пакетов AppleTalk DDP, инкапсулированных в дейтаграммы UDP, производится декапсуляция, после чего они выводятся в дамп как пакеты DDP (т.е. все данные заголовка UDP отбрасываются). Для преобразования номеров сетей и узлов AppleTalk в имена используется файл /etc/atalk.names. Строки в этом файле имеют следующий формат:
номер имя 1.254 her 16.1 csd-net 1.254.110 ace
Первые две строки содержат имена сетей AppleTalk. В третьей строке указано имя конкретного хоста. (Хост отличается от сети третьим октетом номера; номер сети обязательно содержит два октета, номер хоста обязательно содержит три октета.) Номер и имя должны быть разделены пробельным символом (символ пробела или символ табуляции). Файл /etc/atalk.names
может содержать пустые строки или строки комментариев (комментарии начинаются с символа #
).
Адреса AppleTalk выводятся в следующем формате:
сеть.хост.порт 144.1.209.2 > icsd-net.112.220 office.2 > icsd-net.112.220 jssmag.149.235 > icsd-net.2
(Если файл /etc/atalk.names
не существует или не содержит записи для какого-либо номера хоста/сети AppleTalk, то адреса выводятся в числовом виде.) В первом примере NBP (порт DDP 2) в сети 144.1, узел 209, посылает данные любому прослушивающему сервису на порт 220 в сети icsd, узел 112. Вторая строка является аналогичной, за исключением того, что известно полное имя узла источника (office). В третьей строке описывается широковещательная передача с порта 235 в сети jssmag, узел 149, на порт NBP сети icsd-net (отметим, что широковещательный адрес (255) обозначается именем сети без номера хоста, поэтому в файле /etc/atalk.names рекомендуется присваивать узлам и сетям различные имена).
Содержание пакетов NBP (name binding protocol, протокол привязки имен) и ATP (AppleTalk transaction protocol, протокол транзакций AppleTalk) обрабатывается. Для других протоколов в дамп выводится только имя протокола (или номер, если для протокола не зарегистрировано имя) и размер пакета.
Пакеты NBP выводятся в следующем формате:
icsd-net.112.220 > jssmag.2: nbp-lkup 190: “=:LaserWriter@*” jssmag.209.2 > icsd-net.112.220: nbp-reply 190: “RM1140:LaserWriter@*” 250 techpit.2 > icsd-net.112.220: nbp-reply 190: “techpit:LaserWriter@*” 186
Первая строка содержит запрос поиска имен принтеров LaserWriter, отправленный хостом 112 сети icsd, и подлежащий широковещательной рассылке по сети jssmag. Идентификатор nbp для поиска равен 190. Вторая строка содержит ответ на этот запрос (отметим, что он имеет тот же идентификатор) от хоста jssmag.209, в котором сообщается о наличии ресурса LaserWriter RM1140, зарегистрированном по порту 250. Третья строка содержит ответ на этот же запрос, сообщающий о наличии на хосте techpit принтера LaserWriter techpit, зарегистрированному по порту 186.
Пример формата вывода пакетов ATP:
jssmag.209.165 > helios.132: atp-req 12266<0-7> 0xae030001 helios.132 > jssmag.209.165: atp-resp 12266:0 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:1 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:2 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:4 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:6 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp*12266:7 (512) 0xae040000 jssmag.209.165 > helios.132: atp-req 12266<3,5> 0xae030001 helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000 jssmag.209.165 > helios.132: atp-rel 12266<0-7> 0xae030001 jssmag.209.133 > helios.132: atp-req* 12267<0-7> 0xae030002
Хост jssmag.209 инициирует транзакцию с идентификатором 12266 с хостом helios, для чего запрашивает до 8 пакетов (<0-7>). Шестнадцатеричное число в конце строки является значением поля пользовательские_данные в запросе.
В ответ хост helios посылает 8 пакетов по 512 байт каждый. Значение :digit, следующее за идентификатором транзакции, соответствует порядковому номеру пакета в транзакции, а номер в скобках объему данных в пакете, не считая заголовка ATP. Символ * в пакете 7 указывает на установленный бит EOM.
Затем хост jssmag.209 запрашивает повторную передачу пакетов 3 и 5; хост helios повторяет их отправку, после чего хост jssmag.209 завершает транзакцию. Наконец, хост jssmag.209 инициирует следующий запрос. Символ * в запросе указывает, что бит XO ("только один раз") не был установлен.
Фрагментация IP-пакетов
Фрагментированные дейтаграммы Интернета выводятся в следующем виде:
(frag идентификатор:размер@смещение+) (frag идентификатор:размер@смещение)
В первом случае указывается на наличие последующих фрагментов. Вторая – на то, что данный фрагмент является последним.
Идентификатор – это идентификатор фрагмента. Размер соответствует размеру пакета (в байтах), не считая заголовка IP. Смещение – это смещение этого фрагмента (в байтах) в исходной дейтаграмме.
Информация о фрагменте выводится для каждого фрагмента. Первый фрагмент содержит заголовок протокола высокого уровня, а информация о фрагменте выводится после информации о протоколе. Фрагменты, следующие за первым, не содержат заголовки протокола высокого уровня, а информация о фрагменте выводится после адресов источника и назначения. Пример обращения по FTP от хоста arizona.edu к хосту lbl-rtsg.arpa через соединение CSNET, не поддерживающего дейтаграммы размером 576 байт:
arizona.ftp-data > rtsg.1170: . 1024:1332(308) ack 1 win 4096 (frag 595a:328@0+) arizona > rtsg: (frag 595a:204@328) rtsg.1170 > arizona.ftp-data: . ack 1536 win 2560
Следует отметить некоторые детали. Во-первых, адреса во второй строке не содержат номера портов. Причиной является то, что вся информация протокола TCP находится в первом фрагменте, а при выводе последующих фрагментов информация о портах или порядковых номерах отсутствует. Во- вторых, информация последовательности TCP в первой строке выводится с учетом 308 байт пользовательских данных, тогда как фактически данные занимают 512 байт (308 в первом фрагменте и 204 во втором). Это может затруднить поиск разрывов в пространстве последовательности и сопоставление пакетов с сообщениями ACK.
Пакеты с флагом IP не_фрагментировать отмечаются завершающим сочетанием (DF).
Метки времени
По умолчанию перед каждой строкой вывода указывается метка времени. Метка времени представляет собой текущее время в виде чч:мм:сс.доли, а ее точность соответствует точности часов ядра. Время метки соответствует времени обнаружения пакета процессом io-pkt-*. Время запаздывания между получением пакета интерфейсом Ethernet с физической линии связи и обработкой прерывания "новый пакет" процессом io-pkt-* не учитывается.
Вывод всех пакетов, поступающих на sundown или отправляемых с него:
tcpdump host sundown
Вывод трафика между helios и либо hot, либо ace:
tcpdump host helios and \( hot or ace \)
Вывод всех IP-пакетов, передаваемых между ace и любым хостом, кроме helios:
tcpdump ip host ace and not helios
Вывод всего трафика между локальными хостами и хостами в Беркли:
tcpdump net ucb-ether
Вывод всего трафика FTP между Интернет-шлюзом snup (обратите внимание, что выражение обрамлено кавычками во избежание неверной/излишней обработки скобок командным интерпретатором):
tcpdump 'gateway snup and (port ftp or ftp-data)'
Вывод трафика, не поступающего от локальных хостов и не предназначенный им (с точки зрения шлюза между этой и другой сетью эти данные не должны проникать в эту локальную сеть):
tcpdump ip and not net локальная_сеть
Вывод первого и последнего пакетов (пакеты SYN и FIN) каждого диалога TCP с участием нелокального хоста:
tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net локальная_сеть'
Вывод всех HTTP-пакетов IPv4, поступающих на порт 80 и отправляемых с него, т.е. только пакетов, содержащих данные; например, пакеты SYN и FIN, а также пакеты только с ACK не выводятся (IPv6 можно проанализировать самостоятельно):
tcpdump 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'
Вывод IP-пакетов длиннее 576 байт, переданных через шлюз snup:
tcpdump 'gateway snup and ip[2:2] > 576'
Вывод широковещательных или многоадресных IP-пакетов, не переданных путем широковещательной или многоадресной передачи Ethernet:
tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'
Вывод всех пакетов ICMP, не являющиеся эхо-запросами/ответами (т.е. пакетами ping):
tcpdump 'icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply'
Базовые подсистемы ЗОСРВ «Нейтрино», NetBSD
ЗОСРВ
«Нейтрино»
редакции 2020
утилита обновлена до версии 4.9.3
Предыдущий раздел: Утилиты