Tcpdump Linux Command

• Порт src порт
  • Истинно, если пакет имеет значение исходного порта порт .
• порт Порт
  • Истинно, если исходным или целевым портом пакета является порт . Любое из приведенных выше выражений порта может начинаться с ключевых слов tcp или udp , как в порт TCP src порт , который соответствует только пакетам tcp, исходный порт которых порт .
• меньше Длина
  • Истинно, если длина пакета меньше или равна длине . Это эквивалентно len <= Length .
• больше Длина
  • Истинно, если длина пакета больше или равна length . Это эквивалентно len> = Length .
• ip proto протокол
  • Истинно, если пакет является IP-пакетом (см. ip (4P)) типа протокола protocol . Протокол может быть числом или одним из имен icmp , icmp6 , igmp , igrp , pim , ах , esp , vrrp , udp или < эм> TCP . Обратите внимание, что идентификаторы tcp , udp и icmp также являются ключевыми словами и должны быть экранированы через обратную косую черту (\), которая \\ в С-оболочка. Обратите внимание, что этот примитив не преследует цепочку заголовков протокола.
• ip6 proto протокол
  • Истинно, если пакет является пакетом IPv6 с типом протокола protocol . Обратите внимание, что этот примитив не преследует цепочку заголовков протокола.

• протокол ip6 протокол
  • Истинно, если пакет является пакетом IPv6 и содержит заголовок протокола с типом protocol в своей цепочке заголовков протокола. Например, ipv6 protochain 6 сопоставляет любой пакет IPv6 с заголовком протокола TCP в цепочке заголовков протокола. Пакет может содержать, например, заголовок аутентификации, заголовок маршрутизации или заголовок параметра переход за участком между заголовком IPv6 и заголовком TCP. Код BPF, генерируемый этим примитивом, является сложным и не может быть оптимизирован кодом оптимизатора BPF в tcpdump , поэтому это может быть несколько медленным.
• ip protochain протокол
  • Эквивалент ip6 protochain протокол , но это для IPv4.
• эфирная трансляция
  • Истинно, если пакет является широковещательным пакетом Ethernet. Ключевое слово ether необязательно.
• IP-трансляция
  • Истинно, если пакет является широковещательным IP-пакетом. Он проверяет как широковещательные, так и единичные соглашения о широковещании и ищет маску локальной подсети.
• эфирная многоадресная рассылка
  • Истинно, если пакет является многоадресным пакетом Ethernet. Ключевое слово ether необязательно. Это сокращение для ether [0] & 1! = 0 ‘.

• ip multicast
  • Истинно, если пакет является многоадресным IP-пакетом.
• Многоадресная рассылка ip6
  • Истинно, если пакет является многоадресным пакетом IPv6.
• эфирный прото протокол
  • Истинно, если пакет имеет эфирный тип протокол . Протокол может быть числом или одним из имен ip , ip6 , arp , rarp , atalk , aarp , decnet , sca , lat , mopdl , moprc , iso , stp , ipx или netbeui . Обратите внимание, что эти идентификаторы также являются ключевыми словами и должны быть экранированы через обратную косую черту (\).
  • [В случае FDDI (например, протокол fddi arp ‘) и Token Ring (например, tr протокол arp ‘), для большинства этих протоколов протокол Идентификация происходит из заголовка 802.2 Logical Link Control (LLC), который обычно размещается поверх заголовка FDDI или Token Ring.
  • При фильтрации большинства идентификаторов протоколов в FDDI или Token Ring tcpdump проверяет только поле идентификатора протокола заголовка LLC в так называемом формате SNAP с идентификатором организационной единицы (OUI) 0x000000 для инкапсулированного Ethernet ; он не проверяет, имеет ли пакет формат SNAP с OUI 0x000000.
  • Исключениями являются iso , для которых он проверяет поля DSAP (Точка доступа к службе назначения) и SSAP (Точка доступа к исходной службе) заголовка LLC, stp и netbeui , где он проверяет DSAP заголовка LLC, и atalk , где он проверяет пакет формата SNAP с OUI 0x080007 и типом Appletalk.
  • В случае Ethernet tcpdump проверяет поле типа Ethernet для большинства этих протоколов; Исключениями являются iso , sap и netbeui , для которых он проверяет кадр 802.3, а затем проверяет заголовок LLC, как и для FDDI. и Token Ring; atalk , где он проверяет etype Appletalk в кадре Ethernet и пакет формата SNAP, как это делается для FDDI и Token Ring; aarp , где он проверяет тип APP Appletalk ARP либо в кадре Ethernet, либо в кадре SNAP 802.2 с OUI 0x000000; и ipx , где он проверяет etype IPX в кадре Ethernet, DSAP IPX в заголовке LLC, 802.3 без инкапсуляции заголовка LLC IPX и etype IPX в кадре SNAP.]

• decnet src хост
  • Истинно, если адрес источника DECNET – host , который может быть адресом формы «10.123» или именем хоста DECNET. [Поддержка имени хоста DECNET доступна только в системах Ultrix, которые настроены на запустить DECNET.]
• decnet dst хост
  • Истинно, если адрес назначения DECNET – хост .
• хост decnet хост
  • Истинно, если источником или адресом назначения DECNET является хост .
• ф , ip6 , агр , RARP , ATALK , ААП , DECnet изо , СТП , IPX NetBEUI <уль >
• Сокращения для ether proto p , где p – один из приведенных выше протоколов.

Доступны следующие значения полей флагов TCP: tcp-fin , tcp-syn , tcp-rst , tcp-push , ТСР нажатием ТСР-извед ТСР-УРГ .

Примитивы могут быть объединены с использованием любого из следующего:

• Группа примитивов и операторов в скобках (скобки являются специальными для командной консоли и должны быть экранированы)
• Отрицание (‘! ‘ или ` не ‘)
• Конкатенация ( && или и ‘)
• Чередование ( || или или ‘)

Отрицание имеет наивысший приоритет. Чередование и сцепление имеют одинаковый приоритет и ассоциируются слева направо. Обратите внимание, что для конкатенации необходимы явные токены и , а не сопоставление.

Если идентификатор указан без ключевого слова, предполагается самое последнее ключевое слово. Например, not host vs and ace – это сокращение от not host vs and host ace . Однако это не следует путать с not (host vs или ace) .

Аргументы выражения могут быть переданы tcpdump как один аргумент или как несколько аргументов, в зависимости от того, что удобнее. Как правило, если выражение содержит метасимволы Shell, его проще передать в виде одного аргумента в кавычках. Несколько аргументов объединяются с пробелами перед анализом.

Tcpdump Примеры

  Закат хоста tcpdump  
 

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

  tcpdump host helios и \ (hot или ace \)  
 

В этом примере tcpdump печатается трафик между helios и hot или ace.

  tcpdump ip host ace, а не helios  
 

Вы можете использовать эту команду tcpdump для печати всех IP-пакетов между ace и любым хостом, кроме helios.

  tcpdump net ucb-ether  
 

В приведенном выше примере tcpdump печатает весь трафик между локальными хостами и хостами в Беркли.

  tcpdump 'snup шлюза и (порт ftp или ftp-данные)'  
 

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

  tcpdump ip, а не net   localnet  
 

В приведенном выше примере tcpdump команда печатает трафик, не полученный и не предназначенный для локальных хостов.

  tcpdump 'tcp [tcpflags] & (tcp-syn | tcp-fin)! = 0, а не src и dst net   localnet ' 
 

Для приведенного выше примера tcpdump команда используется для печати начального и конечного пакетов (пакетов SYN и FIN) каждого диалога TCP, который включает нелокальный хост.

  tcpdump 'шлюз snup и ip [2: 2]> 576'  
 

Приведенная выше команда напечатает IP-пакеты длиной более 576 байтов, отправленные через шлюз snup.

  tcpdump 'ether [0] & 1 = 0 и ip [16]> = 224'  
 

Команда tcpdump, показанная выше, печатает IP-широковещательные или многоадресные пакеты, которые не были отправлены через Ethernet-широковещательную или многоадресную рассылку.

  tcpdump 'icmp [icmptype]! = icmp-echo и icmp [icmptype]! = icmp-echoreply'  
 

В этом последнем примере tcpdump команда печатает все пакеты ICMP, которые не являются эхо-запросами или ответами (то есть не являются пакетами ping).

Выходной формат Tcpdump

Вывод tcpdump зависит от протокола. Ниже приводится краткое описание и примеры большинства форматов.

Заголовки уровня ссылки . Если задана опция -e, заголовок уровня ссылки распечатывается. В сетях Ethernet указываются адреса источника и назначения, протокол и длина пакета.

В сетях FDDI опция ‘-e’ заставляет tcpdump печатать поле ‘frame control’, адреса источника и назначения, а также длину пакета. (Поле ‘frame control’ управляет интерпретацией остальной части пакета. Обычные пакеты (например, содержащие дейтаграммы IP) являются асинхронными пакетами со значением приоритета от 0 до 7: например, async4 ‘. Предполагается, что такие пакеты содержат пакет 802.2 Logical Link Control (LLC); заголовок LLC печатается, если он не является датаграммой ISO или так называемым пакетом SNAP.

В сетях Token Ring опция ‘-e’ заставляет tcpdump печатать поля ‘access control’ и ‘frame control’, адреса источника и получателя, а также длину пакета. Как и в сетях FDDI, предполагается, что пакеты содержат пакет LLC. Независимо от того, указана опция ‘-e’ или нет, информация о маршрутизации источника печатается для пакетов с маршрутизацией от источника.

(примечание: следующее описание предполагает знакомство с алгоритмом сжатия SLIP, описанным в RFC-1144.)

На каналах SLIP выводятся указатель направления («I» для входящего, «O» для исходящего), тип пакета и информация о сжатии. Тип пакета печатается первым. Три типа: ip , utcp и ctcp . Для пакетов ip дополнительная информация о ссылке не печатается. Для пакетов TCP идентификатор соединения печатается в соответствии с типом. Если пакет сжат, его закодированный заголовок распечатывается. Особые случаи распечатываются как * S + n и * SA + n , где n – это величина, на которую изменился порядковый номер (или порядковый номер и ack). Если это не особый случай, выводится ноль или более изменений. Изменение обозначается как U (срочный указатель), W (окно), A (ack), S (порядковый номер) и I (идентификатор пакета), за которым следует дельта (+ n или -n) или новое значение (= п). Наконец, количество данных в пакете и длина сжатого заголовка печатаются.

Например, следующая строка показывает исходящий сжатый пакет TCP с неявным идентификатором соединения; ack изменился на 6, порядковый номер на 49, а ID пакета на 6; есть 3 байта данных и 6 байтов сжатого заголовка:

  O ctcp * A + 6 S + 49 I + 6 3 (6)  
 

Arp/rarp пакеты . Выходные данные arp/rarp показывают тип запроса и его аргументы. Формат предназначен для пояснений. Вот краткий пример, взятый с начала ‘rlogin’ с хоста rtsg на хост csam :

 arp who-has csam Расскажите rtsg 
 arp ответ csam is-at CSAM 
 

В первой строке написано, что rtsg отправил пакет arp с запросом адреса Ethernet интернет-хоста csam. Csam отвечает своим Ethernet-адресом (в этом примере Ethernet-адреса указаны заглавными буквами, а интернет-адреса строчными).

Это выглядело бы менее излишне, если бы мы выполнили tcpdump -n :

 arp who-has 128.3.254.6 скажи 128.3.254.68 
 arp ответ 128.3.254.6 is-at 02: 07: 01: 00: 01: c4 
 

Если бы мы выполнили tcpdump -e , тот факт, что первый пакет транслируется, а второй является двухточечным, будет виден:

 RTSG Broadcast 0806 64: arp who-has csam Расскажите rtsg 
 CSAM RTSG 0806 64: arp ответ csam is-at CSAM 
 

Для первого пакета это говорит, что адрес источника Ethernet – RTSG, адрес назначения – широковещательный адрес Ethernet, поле типа содержало шестнадцатеричный 0806 (тип ETHER_ARP), и общая длина была 64 байта.

TCP-пакеты (NB. Следующее описание предполагает знакомство с протоколом TCP, описанным в RFC-793. Если вы не знакомы с протоколом, ни это описание, ни tcpdump не будут очень полезны для вы) . Общий формат строки протокола tcp:

 src> dst: флажки срочных опций окна data-seqno ack 
 

Src и dst – IP-адреса и порты источника и назначения. Флаги представляют собой некоторую комбинацию S (SYN), F (FIN), P (PUSH) или R (RST) или одного ‘.’ (без флагов). Data-seqno описывает часть пространства последовательности, охватываемую данными в этом пакете (см. пример ниже). Ackno – порядковый номер следующих данных, ожидаемых в другом направлении в этом соединении. Окно – это количество байтов пространства приемного буфера, доступного в другом направлении для этого соединения. Urg указывает, что в пакете есть «срочные» данные. Параметры – это параметры tcp, заключенные в угловые скобки (например,).

Флаги Src, dst, и присутствуют всегда. Другие поля зависят от содержимого заголовка протокола tcp пакета и выводятся только при необходимости.

Вот первая часть rlogin от хоста rtsg до хоста csam .

 rtsg.1023> csam.login: S 768512: 768512 (0) победа 4096 
 csam.login> rtsg.1023: S 947648: 947648 (0) ack 768513 победа 4096 
 rtsg.1023 > csam.login: ack 1 победа 4096 
 rtsg.1023> csam.login: P 1: 2 (1) ack 1 победа 4096 
 csam.login> rtsg.1023:. ack 2 победа 4096 
 rtsg.1023> csam.login: P 2:21 (19) ack 1 победа 4096 
 csam.login> rtsg.1023: P 1: 2 (1) ack 21 победа 4077 
 csam.login> rtsg.1023: P 2: 3 (1) ack 21 победа 4077 ург 1 
 csam.login> rtsg.1023: P 3: 4 (1) ack 21 победа 4077 ург 1 
 

Первая строка говорит, что tcp порт 1023 на rtsg отправил пакет на порт login на csam. S указывает, что был установлен флаг SYN . Порядковый номер пакета был 768512 и не содержал данных. (Обозначение «first: last (nbytes)», что означает «порядковые номера first до, но не включая last , что составляет nbytes байт. пользовательских данных.) Не было подтвержденного подтверждения, доступное окно приема было 4096 байт, и была опция максимального размера сегмента, запрашивающая mss 1024 байта.

Csam отвечает аналогичным пакетом, за исключением того, что в него входит ack для SYN от rtsg. Затем Rtsg подтверждает SYN csam. “.” означает, что флаги не были установлены. Пакет не содержит данных, поэтому отсутствует порядковый номер данных. Обратите внимание, что порядковый номер подтверждения представляет собой небольшое целое число (1). Когда tcpdump в первый раз видит tcp ‘разговор’, он печатает порядковый номер из пакета. На последующих пакетах разговора печатается разница между порядковым номером текущего пакета и этим начальным порядковым номером. Это означает, что порядковые номера после первого могут быть интерпретированы как относительные позиции байтов в потоке данных диалога (причем первый байт данных в каждом направлении равен ‘1’). ‘-S’ переопределит эту функцию, в результате чего будут выведены исходные порядковые номера.

В шестой строке rtsg отправляет csam 19 байтов данных (байты со 2 по 20 на стороне разговора rtsg -> csam). Флаг PUSH устанавливается в пакете. В седьмой строке csam сообщает, что полученные данные отправлены rtsg, но не включают в себя байт 21. Большая часть этих данных, очевидно, находится в буфере сокетов, поскольку окно приема csam уменьшилось на 19 байтов. Csam также отправляет один байт данных в этот пакет rtsg. В восьмой и девятой строках csam отправляет два байта срочных данных в rtsg.

Если моментальный снимок был достаточно маленьким, чтобы tcpdump не захватил полный заголовок TCP, он интерпретирует как можно большую часть заголовка и затем сообщает “[| tcp ] ‘ ‘чтобы указать, что остаток не может быть интерпретирован. Если заголовок содержит фиктивную опцию (длина которой слишком мала или превышает конец заголовка), tcpdump сообщает об этом как “[ bad opt ] ” и не интерпретирует дальнейшие параметры (так как невозможно определить, с чего они начинаются). Если длина заголовка указывает, что параметры присутствуют, но длина дейтаграммы IP недостаточно велика для того, чтобы параметры действительно были там, tcpdump сообщает об этом как «[ bad hdr length ] ‘ ».

Захватывать пакеты с определенными комбинациями флагов .В разделе контрольных битов заголовка TCP есть восемь битов:

CWR | ЕЭК | УРГ | ACK | PSH | RST | SYN | FIN

Давайте предположим, что мы хотим посмотреть пакеты, используемые при установлении TCP-соединения. Напомним, что TCP использует трехсторонний протокол рукопожатия при инициализации нового соединения; последовательность соединения с учетом битов управления TCP:

1. Звонящий отправляет SYN.
2. Получатель отвечает SYN, ACK.
3. Звонящий отправляет ACK.

Теперь мы заинтересованы в захвате пакетов, в которых установлен только бит SYN (Шаг 1). Обратите внимание, что нам не нужны пакеты с шага 2 (SYN-ACK), просто начальный SYN. Нам нужно правильное выражение фильтра для tcpdump .

Напомним структуру заголовка TCP без параметров:

 0 15 31 
 ---------------------------------------- ------------------------- 
 | исходный порт | порт назначения | 
 ------------------------------------------- ---------------------- 
 | порядковый номер | 
 ------------------------------------------- ---------------------- 
 | номер подтверждения | 
 ------------------------------------------- ---------------------- 
 | HL | rsvd | C | E | U | A | P | R | S | F | размер окна | 
 ------------------------------------------- ---------------------- 
 | Контрольная сумма TCP | срочный указатель | 
 ------------------------------------------- ---------------------- 
 

Заголовок TCP обычно содержит 20 октетов данных, если параметры не присутствуют. Первая строка графика содержит октеты 0–3, вторая строка – октеты 4–7 и т. Д.

Начиная отсчет с 0, соответствующие биты управления TCP содержатся в октете 13:

 0 7 | 15 | 23 | 31 
 ---------------- | --------------- | ------------ --- | ---------------- 
 | HL | rsvd | C | E | U | A | P | R | S | F | размер окна | 
 ---------------- | --------------- | ---------- ----- | ---------------- 
 | | 13-й октет | | | 
 

Давайте внимательнее посмотрим на октет №. 13:

 | | 
 | --------------- | 
 | 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, значение 13-го октета в заголовке TCP, если интерпретировать его как 8-разрядное целое число без знака в сетевом порядке байтов, должно быть ровно 2.

Эта связь может быть выражена как

tcp [13] == 2

Мы можем использовать это выражение в качестве фильтра для tcpdump для просмотра пакетов, в которых установлен только SYN:

tcpdump -i xl0 tcp [13] == 2

Выражение говорит: «пусть 13-й октет дейтаграммы 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-м октете. Двоичное значение октета 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 
 

Мы не можем просто использовать ‘tcp [13] == 18’ в выражении фильтра tcpdump , потому что при этом выбираются только те пакеты, для которых установлен SYN-ACK, но не те, для которых установлен только SYN. Помните, что нам все равно, установлен ли ACK или любой другой бит управления, пока установлен SYN.

Чтобы достичь нашей цели, нам нужно логически И двоичное значение октета 13 с некоторым другим значением, чтобы сохранить бит SYN. Мы знаем, что мы хотим, чтобы SYN был установлен в любом случае, поэтому мы будем логически И значение в 13-м октете с двоичным значением SYN:

 00010010 SYN-ACK 00000010 SYN 
 И 00000010 (мы хотим SYN) и 00000010 (мы хотим SYN) 
 -------- -------- 
 = 00000010 = 00000010 
 

Мы видим, что эта операция И дает одинаковый результат независимо от того, установлен ли ACK или другой бит управления TCP.Десятичное представление значения AND, а также результат этой операции равен 2 (двоичный код 00000010), поэтому мы знаем, что для пакетов с установленным SYN должно соблюдаться следующее соотношение:

((значение октета 13) И (2)) == (2)

Это указывает на выражение фильтра tcpdump

tcpdump -i xl0 ‘tcp [13] & 2 == 2’

Обратите внимание, что вы должны использовать одинарные кавычки или обратную косую черту в выражении, чтобы скрыть специальный символ AND (‘&’) от оболочки.

UDP-пакеты. формат UDP иллюстрируется следующим пакетом:

 actinide.who> broadcast.who: udp 84 
 

Это говорит о том, что порт who на хосте actinide отправил дейтаграмму udp на порт who на хосте broadcast , интернет-трансляция адрес. Пакет содержал 84 байта пользовательских данных.

Некоторые службы UDP распознаются (по номеру порта источника или назначения) и печатается информация протокола более высокого уровня, в частности запросы службы доменных имен (RFC-1034/1035) и вызовы Sun RPC (RFC-1050) в NFS.

Запросы сервера имен UDP (NB. Следующее описание предполагает знакомство с протоколом доменной службы, описанным в RFC-1035. Если вы не знакомы с протоколом, приведенное ниже описание не имеет большого смысла. )

Запросы сервера имен форматируются как:

  src> dst: id op? флаги qtype имя класса (len)  
 h2opolo.1538> helios.domain: 3+ A? ucbvax.berkeley.edu. (37) 
 

Хост h2opolo запросил у сервера домена на helios запись адреса (qtype = A), связанную с именем ucbvax.berkeley.edu. Запрос идентификатор был «3». «+» Указывает, что установлен флаг требуемая рекурсия . Длина запроса составляла 37 байт, не считая заголовков протоколов UDP и IP. Операция запроса была обычной, Query , поэтому поле op было опущено. Если бы операция была чем-то еще, она была бы напечатана между «3» и «+». Точно так же qclass был обычным, C_IN , и опущен. Любой другой класс q был бы напечатан сразу после «A».

Несколько аномалий проверяются и могут привести к тому, что дополнительные поля будут заключены в квадратные скобки: если запрос содержит ответ, раздел авторитетных записей или раздел дополнительных записей, ancount , nscount или arcount печатаются как ‘[ n a]’, ‘[ n n]’ или ‘[ n au ] ‘где n – соответствующий счетчик. Если какой-либо из битов ответа установлен (AA, RA или rcode) или любой из битов «должен быть нулем» установлен в байтах два и три, печатается «[b2 & 3 = x ]» где x – шестнадцатеричное значение байтов заголовка два и три.

UDP-сервер имен отвечает. ответы сервера имен имеют следующий формат:

  src> dst: id op rcode помечает a/n/au данные класса данных (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 отвечает на запрос id 3 из h2opolo тремя записями ответов, тремя записями сервера имен и семью дополнительными записями. Первая запись ответа имеет тип A (адрес), а ее данные – интернет-адрес 128.32.137.3. Общий размер ответа составил 273 байта, исключая заголовки UDP и IP. Оператор (Query) и код ответа (NoError) были опущены, так же как и класс (C_IN) записи A.

Во втором примере helios отвечает на запрос 2 кодом ответа несуществующего домена (NXDomain) без ответов, с одним сервером имен и без авторитетных записей. Символ * означает, что был установлен бит авторитетный ответ . Поскольку ответов не было, тип, класс или данные не печатались.

Другие символы флага, которые могут появиться: ‘-‘ (рекурсия доступна, RA, not установлена) и ‘|’ (усеченное сообщение, TC, set). Если раздел «вопрос» не содержит ровно одну запись, печатается «[ n q]».

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

Декодирование SMB/CIFS. tcpdump включает довольно обширное декодирование SMB/CIFS/NBT для данных по UDP/137, UDP/138 и TCP/139. Некоторое примитивное декодирование данных IPX и NetBEUI SMB также выполняется.

По умолчанию выполняется довольно минимальное декодирование, с гораздо более детальным декодированием, если используется -v. Имейте в виду, что при использовании -v один SMB-пакет может занимать страницу или более, поэтому используйте -v только в том случае, если вам действительно нужны все подробности.

Если вы декодируете сеансы SMB, содержащие строки Unicode, вы можете установить переменную среды USE_UNICODE равной 1.Патч для автоматического определения Unicode-строк будет приветствоваться.

Информацию о форматах пакетов SMB и о том, что означают все поля, можно найти на сайте www.cifs.org или в каталоге pub/samba/specs/на вашем любимом зеркале samba.org. Патчи для SMB были написаны Эндрю Триджеллом (tridge@samba.org).

NFS запросы и ответы. Запросы и ответы Sun NFS (Network File System) печатаются в виде:

  src.xid> dst.nfs: len op args  
  src.nfs> dst.xid: ответить на stat len ​​op результаты  
 суши .6709> wrl.nfs: 112 ссылка для чтения fh 21,24/10.73165 
 wrl.nfs> sushi.6709: ответить нормально 40 ссылка для чтения "../var" 
 sushi.201b> wrl.nfs: < br /> 144 просмотр fh 9,74/4096.6878 "xcolors" 
 wrl.nfs> sushi.201b: 
 ответить нормально 128 просмотр fh 9,74/4134.3150 
 

В первой строке хост sushi отправляет транзакцию с идентификатором 6709 на wrl (обратите внимание, что номер, следующий за хостом src, является идентификатором транзакции, не порт источника). Запрос был 112 байтов, исключая заголовки UDP и IP. Операция была readlink (чтение символической ссылки) для дескриптора файла ( fh ) 21,24/10.731657119. (Если вам повезет, как в этом случае, дескриптор файла может быть интерпретирован как пара основных, второстепенных номеров устройств, за которыми следуют номер инода и номер генерации.) Wrl отвечает «ок» с содержание ссылки.

В третьей строке sushi просит wrl найти имя « xcolors » в файле каталога 9,74/4096.6878. Обратите внимание, что напечатанные данные зависят от типа операции. Предполагается, что формат не требует пояснений, если его читать вместе со спецификацией протокола NFS.

Если указан флаг -v (подробный), выводится дополнительная информация. Например:

 sushi.1372a> wrl.nfs: 
 148 прочитано fh 21,11/12.195 8192 байта @ 24576 
 wrl.nfs> sushi.1372a: 
 ответить ok 1472 читать REG 100664 идентификаторов 417/0 сз 29388 
 

(-v также выводит поля TTL, ID, длину и фрагментацию IP-заголовка, которые были опущены в этом примере.) В первой строке sushi просит wrl прочитать 8192 байта из файла 21,11/12.195 со смещением байтов 24576. Wrl отвечает ‘ok’; пакет, показанный во второй строке, является первым фрагментом ответа и, следовательно, имеет длину всего 1472 байта (другие байты будут следовать в последующих фрагментах, но эти фрагменты не имеют заголовков NFS или даже UDP и поэтому могут не печататься, в зависимости от используемого выражения фильтра). Поскольку указан флаг -v, выводятся некоторые атрибуты файла (которые возвращаются в дополнение к данным файла): тип файла («REG», для обычного файла), режим файла (в восьмеричном), UID и GID, а также размер файла.

Если флаг -v указан более одного раза, будет напечатано еще больше деталей.

Обратите внимание, что запросы NFS очень велики, и большая часть деталей не будет напечатана, пока snaplen не будет увеличено. Попробуйте использовать -s 192 для просмотра трафика NFS.

Ответные пакеты NFS не идентифицируют явно операцию RPC. Вместо этого tcpdump отслеживает «недавние» запросы и сопоставляет их с ответами с использованием идентификатора транзакции. Если ответ не следует непосредственно за соответствующим запросом, он может не обрабатываться.

Transarc AFS (Andrew File System) запрашивает и отвечает.

  src.sport> dst.dport: тип пакета rx  
  src.sport> dst.dport: вызов службы имени типа пакета rx args  
  src.sport> dst.dport: rx аргументы имени вызова службы пакетного типа  
 elvis.7001> pike.afsfs: 
 rx data fs call переименовать старый fid 536876964/1/1 ".newsrc.new" 
 new fid 536876964/1/1 ".newsrc" 
 pike.afsfs> elvis.7001: rx data fs reply переименовать 
 

В первой строке хост elvis отправляет пакет RX пике. Это был пакет данных RX для службы fs (fileserver) и является началом вызова RPC. Вызов RPC представлял собой переименование со старым идентификатором файла каталога 536876964/1/1 и старым именем файла «.newsrc.new», а также новым идентификатором файла каталога 536876964/1/1 и новым именем файла «. newsrc. Узловая щука отвечает RPC-ответом на вызов переименования (который был успешным, поскольку это был пакет данных, а не пакет прерывания).

В общем, все RPC AFS декодируются как минимум по имени вызова RPC. Большинство RPC AFS имеют, по крайней мере, некоторые из декодированных аргументов (как правило, только «интересные» аргументы, для некоторого определения интересных).

Формат предназначен для самоописания, но, вероятно, он не будет полезен для людей, которые не знакомы с работой AFS и RX.

Если флаг -v (подробный) задается дважды, печатаются пакеты подтверждения и дополнительная информация заголовка, такая как идентификатор вызова RX, номер вызова, порядковый номер, серийный номер и флаги пакетов RX.

Если флаг -v указан дважды, выводится дополнительная информация, такая как идентификатор вызова RX, серийный номер и флаги пакета RX.Информация о согласовании MTU также выводится из пакетов подтверждения приема.

Если флаг -v указан три раза, будет напечатан индекс безопасности и идентификатор сервиса.

Коды ошибок печатаются для пакетов прерывания, за исключением пакетов маяка Ubik (поскольку пакеты прерывания используются для обозначения голосования «за» для протокола Ubik).

Обратите внимание, что запросы AFS очень велики, и многие аргументы не будут напечатаны, если snaplen не будет увеличено. Попробуйте использовать ` -s 256 ‘для просмотра трафика AFS.

Ответные пакеты AFS явно не идентифицируют операцию RPC. Вместо этого tcpdump отслеживает «недавние» запросы и сопоставляет их с ответами с использованием номера вызова и идентификатора службы. Если ответ не следует непосредственно за соответствующим запросом, он может не обрабатываться.

KIP Appletalk (DDP в UDP) . DDP-пакеты Appletalk, инкапсулированные в дейтаграммы UDP, де-инкапсулируются и выгружаются как пакеты DDP (то есть вся информация заголовка UDP отбрасывается). Файл /etc/atalk.names используется для перевода номеров сети и узлов appletalk в имена.

Строки в этом файле имеют следующую форму:

  номер имени  
 1,254 эфира 
 16,1 icsd-net 
 1,254,110 аса 
 

Первые две строки дают названия сетей appletalk. В третьей строке указано имя конкретного хоста (хост отличается от сети третьим октетом в номере – у сетевого номера must есть два октета, а номер хоста must /etc/atalk.names может содержать пустые строки или строки комментариев (строки, начинающиеся с `# ‘).

Адреса Appletalk печатаются в виде:

  net.host.port  
 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. Вторая строка такая же, за исключением того, что известно полное имя исходного узла («офис»). Третья строка – это отправка с порта 235 на сетевом узле jssmag 149 для широковещательной передачи через порт icsd-net NBP (обратите внимание, что широковещательный адрес (255) указывается сетевым именем без номера хоста; по этой причине это хороший Идея сохранить разные имена узлов и сетевых имен в /etc/atalk.names).

Пакеты NBP (протокол привязки имени) и ATP (протокол транзакции 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 
 

Первая строка – это запрос на поиск имени для лазерных писателей, отправленный хостом net icsd 112 и переданный по сети jssmag. Идентификатор nbp для поиска равен 190. Во второй строке показан ответ на этот запрос (обратите внимание, что он имеет тот же идентификатор) от хоста jssmag.209, в котором говорится, что у него есть ресурс Laserwriter с именем “RM1140”, зарегистрированный на порту 250. Третья строка line – это еще один ответ на тот же запрос о том, что хост techpit зарегистрировал лазерный писатель “techpit” на порту 186.

Форматирование ATP-пакета показано на следующем примере:

 jssmag.209.165> helios.132: atp-req 12266 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 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 0xae030001 
 jssmag.209.133> helios.132: atp-req * 12267 0xae030002 
 

Jssmag.209 инициирует транзакцию с идентификатором 12266 с помощью helios узла, запрашивая до восьми пакетов (`’). Шестнадцатеричное число в конце строки является значением поля ‘userdata’ в запросе.

Гелиос отвечает восемью 512-байтовыми пакетами.’: Цифра’ после идентификатора транзакции дает порядковый номер пакета в транзакции, а число в скобках – это количество данных в пакете, исключая заголовок atp. Символ * в пакете 7 указывает, что бит EOM был установлен.

Jssmag.209 затем запрашивает повторную передачу пакетов 3 и 5. Helios отправляет их повторно, затем jssmag.209 освобождает транзакцию. Наконец, jssmag.209 инициирует следующий запрос. «*» В запросе указывает, что XO («ровно один раз») было не установлено.

Фрагментация IP . Фрагментированные интернет-дейтаграммы печатаются так:

  (frag   id  :   размер   @   смещение   +)  
  (фрагмент   id  :   размер   @   смещение  )  
 

(Первая форма указывает, что есть больше фрагментов. Вторая указывает, что это последний фрагмент.)

Id – это идентификатор фрагмента. Размер – размер фрагмента (в байтах), исключая заголовок IP. Смещение – это смещение этого фрагмента (в байтах) в исходной дейтаграмме.

Информация о фрагменте выводится для каждого фрагмента. Первый фрагмент содержит заголовок протокола более высокого уровня, а информация о фрагменте печатается после информации о протоколе. Фрагменты после первого не содержат заголовка протокола более высокого уровня, а информация о фрагменте печатается после адресов источника и назначения. Например, вот часть ftp из arizona.edu в lbl-rtsg.arpa по соединению CSNET, который не обрабатывает 576-байтовые дейтаграммы:

 arizona.ftp-data> rtsg.1170:. 1024: 1332 (308) 1 победа 4096 (фрагмент 595a: 328 @ 0 +) 
 Аризона> rtsg: (фрагмент 595a: 204 @ 328) 
 rtsg.1170> arizona.ftp-data:. 1536 победа 2560 
 

Здесь следует отметить несколько вещей: во-первых, адреса во второй строке не включают номера портов. Это связано с тем, что информация о протоколе TCP находится в первом фрагменте, и мы не знаем, что это за порт или порядковые номера, когда печатаем более поздние фрагменты. Во-вторых, информация о последовательности tcp в первой строке печатается так, как если бы было 308 байтов пользовательских данных, когда фактически 512 байтов (308 в первом фрагменте и 204 во второй). Если вы ищете дыры в пространстве последовательностей или пытаетесь сопоставить acks с пакетами, это может вас обмануть.

Пакет с флагом не фрагментировать по IP помечается завершающим (DF) .

Timestamps. По умолчанию всем выходным строкам предшествует отметка времени.

  чч: мм: ss.frac  
 

Отметка времени – это текущее время в приведенной выше форме, и оно точно такое же, как и часы ядра. Отметка времени отражает время, когда ядро ​​впервые увидело пакет. Не делается никаких попыток учесть временную задержку между тем, когда интерфейс Ethernet удалял пакет из провода, и когда ядро ​​обслуживало прерывание «новый пакет».