Tcpdump примеры, описание, опции и другие детали
Tcpdump – это команда, используемая в различных операционных системах Linux (OS), которая собирает пакеты TCP/IP, которые проходят через сетевой адаптер. Так же, как инструмент перехвата пакетов, tcpdump может не только анализировать сетевой трафик, но и сохранять его в файл.
В отличие от некоторых команд, которые предоставляются операционной системой по умолчанию, вы можете обнаружить, что вы не можете использовать tcpdump, потому что он не установлен. Чтобы установить tcpdump, выполните apt-get install tcpdump или yum install tcpdump , в зависимости от вашей ОС.
Как работает Tcpdump
Tcpdump распечатывает заголовки пакетов на сетевом интерфейсе, которые соответствуют логическому выражению . Его также можно запустить с флагом -w , который заставляет его сохранять данные пакета в файл для последующего анализа, и/или с флагом -r , который заставляет его читать из сохраненного файла пакета, а не читать пакеты из сетевого интерфейса. Во всех случаях tcpdump будет обрабатывать только пакеты, которые соответствуют выражению .
Tcpdump будет, если не запущен с флагом -c , продолжать захват пакетов, пока он не будет прерван сигналом SIGINT (генерируемым, например, путем ввода символа прерывания, обычно Ctrl + C ) или сигнал SIGTERM (обычно генерируется командой kill (1)); если он запускается с флагом -c , он будет захватывать пакеты до тех пор, пока он не будет прерван сигналом SIGINT или SIGTERM или пока не будет обработано указанное количество пакетов.
Упомянутые выше переключатели подробно объясняются далее в этой статье.
Когда tcpdump заканчивает захват пакетов, он сообщит о количестве:
-
Пакеты “получены фильтром”.
- Смысл этого зависит от операционной системы, в которой вы запускаете tcpdump , и, возможно, от того, как была настроена ОС. Если в командной строке был указан фильтр, в некоторых ОС он считает пакеты независимо от того, были ли они сопоставлены выражением фильтра, а в других – только пакеты, которые были сопоставлены выражением фильтра и были обработаны tcpdump.
-
Пакеты “отброшены ядром”.
- Это количество пакетов, которые были отброшены из-за недостатка места в буфере механизмом захвата пакетов в ОС, в которой работает tcpdump , если ОС сообщает эту информацию приложениям. Если нет, он будет указан как 0.
На платформах, которые поддерживают сигнал SIGINFO, таких как большинство BSD (дистрибутивы программного обеспечения Berkeley), он будет сообщать эти подсчеты при получении сигнала SIGINFO (генерируемого, например, путем ввода символа «status»), обычно Ctrl + T ) и продолжит захват пакетов.
Совместимость с Tcpdump
Для чтения пакетов из сетевого интерфейса с помощью команды tcpdump могут потребоваться специальные привилегии ( чтение сохраненный файл пакета не требует таких привилегий):
- SunOS 3.x или 4.x с NIT или BPF . У вас должен быть доступ на чтение к /dev/nit или dev/bpf * .
- Solaris с DLPI . У вас должен быть доступ на чтение/запись к сетевому псевдоустройству, например /dev/le . Однако, по крайней мере, в некоторых версиях Solaris этого недостаточно для того, чтобы tcpdump мог захватывать в случайном режиме; в этих версиях Solaris вы должны быть пользователем root, или tcpdump должен быть установлен с настройкой root в целях захвата в случайном режиме. Обратите внимание, что на многих (возможно, на всех) интерфейсах, если вы не захватываете в случайном режиме, вы не увидите никаких исходящих пакетов, поэтому захват, не выполненный в случайном режиме, может быть не очень полезным.
- HP-UX с DLPI . Вы должны быть пользователем root или tcpdump должен быть установлен с настройкой root.
- IRIX with snoop : вы должны быть пользователем root или tcpdump должен быть установлен с установленным root-доступом.
- Linux : вы должны быть пользователем root или tcpdump должен быть установлен с установленным пользователем root.
- Ultrix and Digital UNIX/Tru64 UNIX . Любой пользователь может захватывать сетевой трафик с помощью tcpdump . Тем не менее, ни один пользователь (даже суперпользователь) не может захватывать в смешанном режиме на интерфейсе, если только суперпользователь не включил операцию смешанного режима на этом интерфейсе с помощью pfconfig (8) и ни один пользователь (даже не суперпользователь) может захватывать одноадресный трафик, полученный или отправленный машиной на интерфейсе, если только суперпользователь не включил операцию копирования всех режимов на этом интерфейсе, используя pfconfig , поэтому < Для захвата пакетов em> Полезная на интерфейсе, вероятно, требуется, чтобы на этом интерфейсе была включена либо операция с произвольным режимом, либо копирование всего режима, либо оба режима работы.
- BSD . У вас должен быть доступ на чтение к /dev/bpf * .
Синтаксис команды Tcpdump
Как и все компьютерные команды, команда tcpdump работает правильно, только если синтаксис правильный:
tcpdump [ -adeflnNOpqRStuvxX ] [ -c count ]
[ -C file_size ] [ -F файл ]
[ -i интерфейс ] [ -m модуль ] [ -r файл ]
[ -s snaplen ] [ -T тип ] [ -U пользователь ] [ -w файл ]
[ -E algo: secret ] [ выражение ]
Параметры команды Tcpdump
Это все параметры, которые вы можете использовать с командой tcpdump:
- -a . Попытка преобразовать сетевые и широковещательные адреса в имена.
- -c : выход после получения пакетов count .
- -C . Перед записью необработанного пакета в файл сохранения проверьте, не превышает ли размер файла file_size , и, если это так, закройте текущий файл сохранения и откройте новый. Файлы сохранения после первого файла сохранения будут иметь имя, указанное с флагом -w , с числом после него, начиная с 2 и продолжая вверх. Единицами file_size являются миллионы байтов (1 000 000 байтов, а не 1 048 576 байтов).
- -d : сбросить скомпилированный код сопоставления пакетов в удобочитаемой форме для стандартного вывода и остановки.
- -dd : выгрузить код сопоставления пакетов как фрагмент программы C .
- -ddd : сбросить код совпадения пакетов в виде десятичных чисел (с предварительным счетом).
- -e : печатать заголовок уровня ссылки в каждой строке дампа.
- -E : используйте algo: secret для расшифровки пакетов ESP IPsec. Алгоритмы могут быть des-cbc , 3des-cbc , blowfish-cbc , rc3-cbc , cast128-cbc или нет . По умолчанию используется des-cbc . Возможность дешифрования пакетов присутствует только в том случае, если tcpdump был скомпилирован с включенной криптографией. «секретный» – текст ASCII для «секретного» ключа ESP. Опция предполагает RFC2406 ESP, а не RFC1827 ESP. Опция предназначена только для целей отладки, и использование этой опции с истинным «секретным» ключом не рекомендуется. Представляя «секретный» ключ IPsec в командной строке, вы делаете его видимым для других с помощью ps (1) и других случаев.
- -f . Печатайте «чужие» интернет-адреса в числовом, а не в символическом виде (этот параметр предназначен для обхода сбоев в yp-сервере Sun – обычно он зависает при переводе нелокальных интернет-номеров).
- -F : используйте файл в качестве входных данных для выражения фильтра. Дополнительное выражение, данное в командной строке, игнорируется.
- -i : прослушивать интерфейс . Если не указано, tcpdump ищет в списке интерфейса системы настроенный интерфейс с наименьшим номером (исключая обратную связь). Связи разрываются, выбирая самый ранний матч. В системах Linux с ядром 2.2 или новее аргумент interface «any» может использоваться для захвата пакетов со всех интерфейсов. Обратите внимание, что захват на устройстве «any» не будет выполняться в случайном порядке Режим.
- -l : сделать буферизованную строку стандартного вывода. Полезно, если вы хотите увидеть данные во время их захвата. Например, «tcpdump -l | tee dat» или «tcpdump -l> dat & tail -f dat ‘».
- -m : загрузить определения модулей SMI MIB из файла module . Эту опцию можно использовать несколько раз для загрузки нескольких модулей MIB в tcpdump .
- -n : не преобразовывать адреса хостов в имена. Это может быть использовано, чтобы избежать поиска DNS.
- -nn . Не конвертируйте номера протоколов, портов и т. д. в имена.
- -N : не печатать квалификационные имена хостов. Например, если вы укажете этот флаг, то tcpdump напечатает «nic» вместо «nic.ddn.mil».
- -O . Не запускайте оптимизатор кода для сопоставления пакетов. Это полезно, только если вы подозреваете ошибку в оптимизаторе.
- -p : Не переводите интерфейс в беспорядочный режим. Обратите внимание, что интерфейс может быть в случайном режиме по какой-то другой причине; следовательно, “-p” не может использоваться как сокращение для “ether host {local-hw-addr} или ether broadcast”.
- -q : быстрый (тихий) вывод. Печатайте меньше протокольной информации, чтобы выходные строки были короче.
- -R . Предполагается, что пакеты ESP/AH основаны на старой спецификации: с RFC1825 по RFC1829.Если указано, tcpdump не будет печатать поле предотвращения воспроизведения. Поскольку в спецификации ESP/AH нет поля версии протокола, tcpdump не может определить версию протокола ESP/AH.
- -r : читать пакеты из файла (который был создан с помощью параметра -w). Стандартный ввод используется, если file равен “- ”.
- -S : выводить абсолютные, а не относительные порядковые номера TCP.
- -s : Snarf snaplen байт данных из каждого пакета вместо значения по умолчанию 68; с NIT SunOS минимальное значение составляет 96. Шестьдесят восемь байтов подходят для IP, ICMP, TCP и UDP, но могут обрезать информацию протокола от сервера имен и пакетов NFS (см. ниже). Пакеты, усеченные из-за ограниченного снимка, указываются в выходных данных как «[| proto ] ”, где proto – это имя уровня протокола, на котором произошло усечение Обратите внимание, что создание больших моментальных снимков увеличивает время обработки пакетов и эффективно уменьшает объем буферизации пакетов. Это может привести к потере пакетов. Вы должны ограничить snaplen наименьшим число, которое будет захватывать интересующую вас информацию о протоколе. Если для параметра snaplen установлено значение 0, используйте требуемую длину для перехвата целых пакетов.
- -T : принудительно интерпретировать пакеты, выбранные с помощью выражения , для указанного типа . В настоящее время известны следующие типы: cnfp (протокол Cisco NetFlow), rpc (удаленный вызов процедур), rtp (протокол приложений реального времени), rtcp (протокол управления приложениями реального времени), snmp (простой протокол управления сетью), vat (инструмент Visual Audio) и wb (распределенная белая доска).
- -t : не печатайте отметку времени в каждой строке дампа.
- -tt : печатать неотформатированную временную метку в каждой строке дампа.
- -U : удаляет привилегии пользователя root и изменяет идентификатор пользователя на пользователь , а идентификатор группы – на основную группу пользователя .
- Примечание . Red Hat Linux автоматически удаляет привилегии пользователю pcap, если ничего не указано.
- -ttt : вывод дельты (в микросекундах) между текущей и предыдущей строками в каждой строке дампа.
- -tttt : печатать метку времени в формате по умолчанию с указанием даты в каждой строке дампа.
- -u : печать недекодированных маркеров NFS.
- -v : (чуть больше) подробный вывод. Например, печатаются время жизни, идентификация, общая длина и параметры в IP-пакете. Также включает дополнительные проверки целостности пакета, такие как проверка контрольной суммы заголовка IP и ICMP.
- -vv : еще более подробный вывод. Например, дополнительные поля печатаются из ответных пакетов NFS, а пакеты SMB полностью декодируются.
- -vvv : еще более подробный вывод. Например, параметры telnet SB … SE напечатаны полностью. С -X параметры телнета также печатаются в шестнадцатеричном формате.
- -w : записывайте необработанные пакеты в файл , а не анализируйте и распечатывайте их. Позже они могут быть напечатаны с опцией -r. Стандартный вывод используется, если file равен “- ”.
- -x : печатать каждый пакет (без заголовка уровня ссылки) в шестнадцатеричном формате. Меньший из всего пакета или snaplen байтов будет напечатан. Следует отметить, что это полный пакет канального уровня, поэтому для канальных уровней, которые заполняют (например, Ethernet), байты заполнения также будут напечатаны, когда пакет более высокого уровня короче, чем требуемое заполнение.
- -X : при печати в шестнадцатеричном формате также печатайте ASCII. Таким образом, если также установлено -x , пакет печатается в шестнадцатеричном/ASCII-формате. Это очень удобно для анализа новых протоколов. Даже если -x также не установлен, некоторые части некоторых пакетов могут быть напечатаны в шестнадцатеричном/ASCII-формате.
- выражение : выбирает, какие пакеты будут выгружаться. Если выражение не задано, все пакеты в сети будут сброшены. В противном случае будут сброшены только пакеты, для которых expression равно ‘true’. выражение состоит из одного или нескольких примитивов. Примитивы обычно состоят из id (имени или номера), перед которым стоит один или несколько квалификаторов. Существует три различных типа классификатора:
- type : классификаторы говорят, к какому виду относится имя или номер идентификатора. Возможные типы: хост , net и порт , например, «host foo», «net 128.3», «port 20». Если нет спецификатора типа, предполагается хост .
- dir . Спецификаторы указывают конкретное направление передачи в и/или из id .Возможные направления: src , dst , src или dst и src и dst ( например, ‘src foo’, ‘dst net 128.3’, ‘ftp-данные src или dst port’). Если квалификатора dir нет, предполагается src или dst . Для «нулевых» канальных уровней (то есть для протоколов «точка-точка», таких как скольжение) можно использовать спецификаторы входящий и исходящий , чтобы указать желаемое направление.
-
proto : квалификаторы ограничивают соответствие определенным протоколом. Возможные варианты: эфир , fddi , tr , ip , ip6 , arp , rarp , decnet , tcp и udp , например, ‘ether src foo ‘,’ arp net 128.3 ‘,’ tcp port 21 ‘. Если квалификатора прото нет, предполагаются все протоколы, соответствующие типу. Например, «src foo» означает «(ip или arp или rarp) src foo» (за исключением последнего недопустимого синтаксиса), «net bar» означает «net bar» (ip или arp или rarp) и «порт 53» означает ‘(tcp или udp) порт 53’.
- [‘fddi’ на самом деле псевдоним ‘эфир’; синтаксический анализатор обрабатывает их одинаково как означающие «уровень канала передачи данных, используемый в указанном сетевом интерфейсе». Заголовки FDDI содержат Ethernet-подобные адреса источника и назначения и часто содержат Ethernet-подобные типы пакетов, поэтому вы можете фильтровать эти поля FDDI просто как и в аналогичных полях Ethernet. Заголовки FDDI также содержат другие поля, но их нельзя явно назвать в выражении фильтра.
- Точно так же ‘tr’ является псевдонимом для ‘эфира’; утверждения предыдущего абзаца о заголовках FDDI также применимы к заголовкам Token Ring.]
В дополнение к вышесказанному, есть несколько специальных «примитивных» ключевых слов, которые не соответствуют шаблону: шлюз , broadcast , less , < выражения strong> больше и арифметика . Все они описаны ниже.
Более сложные выражения фильтра создаются с использованием слов и , или и не для объединения примитивов, например, «host foo и not». порт ftp, а не порт ftp-данных “. Чтобы сохранить типизацию, идентичные списки квалификаторов могут быть опущены (например, «tcp dst port ftp или ftp-data или domain» в точности совпадает с «tcp dst port ftp или tcp dst port ftp-data или tcp dst port domain»).
Это примитивы, разрешенные командой tcpdump:
-
хост dst хост
- True, если поле назначения IPv4/v6 пакета – host , которое может быть либо адресом, либо именем.
-
хост src хост
- Истинно, если исходное поле пакета IPv4/v6 – host .
-
хост хоста
- Истинно, если источником или адресатом пакета IPv4/v6 является хост . К любому из приведенных выше выражений хоста можно добавить ключевые слова: ip , arp , rarp или ip6 , как в ip host host (что эквивалентно ether proto \ ip и host хост).
- Если host – это имя с несколькими IP-адресами, каждый адрес будет проверен на совпадение.
-
ether dst ehost
- Истинно, если адрес назначения Ethernet – ehost . Ehost может быть именем из/etc/ethers или числом (см. ethers (3N) для числового формата).
-
ether src ehost
- Истинно, если адрес источника Ethernet – ehost .
-
Эфирный хост ehost
- Истинно, если источником Ethernet или адресом назначения является ehost .
-
шлюз хоста
- True, если пакет использовал host в качестве шлюза (т. Е. Адрес источника или назначения Ethernet был host , но ни источником IP, ни адресатом IP не был host ).
- Хост должен быть именем и должен быть найден как механизмами разрешения имени хоста в IP-адресе машины (файл имени хоста, DNS, NIS и т. д.), так и именем хоста машины. механизм разрешения адресов в Ethernet (/ etc/ethers и т. д.).
- Эквивалентное выражение: эфирный хост ehost , а теперь хост хост , которое можно использовать с именами или номерами для host/ehost .) В данный момент этот синтаксис не работает в конфигурации с поддержкой IPv6.
-
dst net net
- Истинно, если адрес назначения IPv4/v6 пакета имеет сетевой номер net . Net может быть именем из/etc/networks или номером сети (подробности см. в networks (4) ).
-
src net net
- Истинно, если адрес источника IPv4/v6 пакета имеет сетевой номер net .
-
нетто нетто
- Истинно, если сетевой адрес источника или пункта назначения IPv4/v6 имеет сетевой номер net .
-
нетто нетто Маска маска подсети
- Истинно, если IP-адрес соответствует net с определенной маской сети . Может быть квалифицирован как src или dst . Обратите внимание, что этот синтаксис недопустим для IPv6 net .
-
нетто нетто / Len
- Истинно, если адрес IPv4/v6 соответствует net с шириной сетевой маски len . Может быть квалифицирован как src или dst .
-
Порт dst порт
- Истинно, если пакет является ip/tcp, ip/udp, ip6/tcp или ip6/udp и имеет значение порта назначения порт . порт может быть числом или именем, используемым в/etc/services (см. tcp (4P) и udp (4P)). Если используется имя, проверяются номер порта и протокол. Если используется номер или неоднозначное имя, проверяется только номер порта (например, dst port 513 будет печатать как трафик tcp/login, так и трафик udp/who, и домен порта Будет печатать трафик как tcp/domain, так и udp/domain).
-
Порт 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 – один из приведенных выше протоколов.
- Сокращения для ether proto p , где p – один из приведенных выше протоколов. Обратите внимание, что tcpdump в настоящее время не знает, как анализировать эти протоколы.
- Истинно, если пакет является пакетом VLAN стандарта IEEE 802.1Q. Если указан [vlan_id] , только значение true, если в пакете указан vlan_id . Обратите внимание, что первое ключевое слово vlan , обнаруженное в выражении , изменяет смещения декодирования для оставшейся части выражения , предполагая, что пакет является пакетом VLAN.
- Сокращения для ip proto p или ip6 proto p , где p является одним из вышеперечисленных протоколов.
-
iso proto протокол
- Истинно, если пакет является пакетом OSI с типом протокола protocol . Протокол может быть числом или одним из имен clnp , esis или isis .
-
CLNP , ESIS , ISIS
- Сокращения для iso proto p , где p – один из приведенных выше протоколов. Обратите внимание, что tcpdump выполняет неполный анализ этих протоколов.
-
expr relop expr
- Истинно, если отношение имеет место, где relop является одним из>, =, <=, =,! = И expr является арифметическим выражением, состоящим из целочисленных констант (выражается в стандартный синтаксис C), обычные двоичные операторы [+, -, *, /, &, |], оператор длины и специальные средства доступа к пакетным данным.Чтобы получить доступ к данным внутри пакета, используйте следующий синтаксис: proto [expr: size] .
Прото – это один из эфира , fddi , tr , ppp , слип , ссылка , ip , arp , rarp , tcp , udp , icmp или ip6 и указывает уровень протокола для операции индекса ( эфир , fddi , tr , ppp , slip и ссылка относятся к уровню ссылок) , Обратите внимание, что tcp, udp и другие типы протоколов верхнего уровня применяются только к IPv4, но не к IPv6. Смещение в байтах относительно указанного уровня протокола определяется как expr . Размер является необязательным и указывает количество байтов в поле интереса; это может быть один, два или четыре, по умолчанию один. Оператор длины, обозначенный ключевым словом len , дает длину пакета.
Например, ether [0] & 1! = 0 перехватывает весь многоадресный трафик. Выражение « ip [0] & 0xf! = 5 » перехватывает все IP-пакеты с опциями. Выражение « ip [6: 2] & 0x1fff = 0 » перехватывает только нефрагментированные дейтаграммы и фрагменты нулевых фрагментированных дейтаграмм. Эта проверка неявно применяется к индексным операциям tcp и udp . Например, tcp [0] всегда означает первый байт TCP заголовка и никогда не означает первый байт промежуточного фрагмента.
Некоторые смещения и значения полей могут быть выражены в виде имен, а не числовых значений. Доступны следующие смещения полей заголовка протокола: icmptype (поле типа ICMP), icmpcode (поле кода ICMP) и tcpflags (поле флагов TCP ).
Доступны следующие значения полей типа ICMP: icmp-echoreply , icmp-unreach , icmp-sourcequench , icmp-redirect , icmp-echo , icmp-routeradvert , icmp-routersolicit , icmp-timxceed , ICMP-paramprob , ICMP-TSTAMP , ICMP-tstampreply , ICMP-IREQ , ICMP-ireqreply сильный>, icmp-maskreq , icmp-maskreply .
Доступны следующие значения полей флагов 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:
- Звонящий отправляет SYN.
- Получатель отвечает SYN, ACK.
- Звонящий отправляет 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 удалял пакет из провода, и когда ядро обслуживало прерывание «новый пакет».