Мощная консольная утилита для перехвата сетевых пакетов. Обычно предустановлена в macOS/linux системах
git clone https://github.com/the-tcpdump-group/tcpdump git clone https://github.com/the-tcpdump-group/libpcap sudo apt-get install tcpdump
Для сообщения о проблемах безопасности, пожалуйста, отправляйте электронную почту на адрес security@tcpdump.org.
Для сообщения об ошибках и других проблемах, предложения патчей, запроса новых функций, предоставления общих отзывов и т.д., пожалуйста, ознакомьтесь с руководством по участию) в корневом каталоге исходного кода tcpdump.
Анонимный доступ к Git доступен через
https://github.com/the-tcpdump-group/tcpdump.git
Этот каталог содержит исходный код tcpdump — инструмента для мониторинга сети и захвата данных.
На протяжении последних лет tcpdump постоянно улучшался благодаря отличным вкладам сообщества Интернета (просто просмотрите журнал изменений)). Мы благодарны за все отклики.
Во многих операционных системах tcpdump доступен как нативный пакет или порт, что упрощает установку обновлений и долгосрочное сопровождение. Однако, нативные пакеты иногда отстают на несколько версий, и для тестирования более свежей сборки потребуется компиляция tcpdump из исходного кода.
tcpdump компилируется и работает как минимум на следующих платформах:
В прошлом tcpdump определённо или вероятно работал на следующих платформах:
tcpdump использует libpcap — независимый от системы интерфейс для захвата пакетов на уровне пользователя. Если ваша операционная система не предоставляет libpcap, или если она предоставляет libpcap, которая не поддерживает API из libpcap 1.0 или более поздней версии, вам необходимо сначала получить и собрать libpcap перед сборкой tcpdump.
После сборки libpcap (либо установите её, либо убедитесь, что она находится в
../libpcap), вы можете собрать tcpdump, используя процедуру из
заметок об установке).
Программа свободно основана на «etherfind» от SMI, хотя ни один фрагмент кода etherfind не сохранился. Изначально она была написана Ваном Якобсоном в рамках текущего исследовательского проекта по изучению и улучшению производительности TCP и шлюзов Интернета. Части программы, первоначально взятые из etherfind от Sun, были позднее переписаны Стивеном Макканном из LBL. Чтобы гарантировать отсутствие какого-либо проприетарного кода в tcpdump, Стив написал эти фрагменты по спецификации из руководства, не имея доступа к исходному коду tcpdump или etherfind.
formerly from Lawrence Berkeley National Laboratory
Network Research Group <tcpdump@ee.lbl.gov>
ftp://ftp.ee.lbl.gov/old/tcpdump.tar.Z (3.4)
Ричард Стивенс превосходно описывает протоколы Интернета в своей книге "TCP/IP Illustrated, Volume 1". Если вы хотите узнать больше о tcpdump и о том, как интерпретировать его вывод, возьмите эту книгу.
Ещё один инструмент, который может оказаться полезным для пользователей tcpdump — tcpslice. Это программа, которая может использоваться для извлечения частей бинарных файлов трассировки tcpdump.
Этот каталог также содержит несколько коротких программ на awk, предназначенных как
примеры способов сокращения данных tcpdump при отслеживании
конкретных сетевых проблем:
send-ack.awk
Упрощает трассировку tcpdump для ftp (или другого однонаправленного
передачи по tcp). Поскольку мы предполагаем, что один хост только отправляет,
а другой только подтверждает, вся информация об адресах опускается, и
мы лишь отмечаем, является ли пакет «отправкой» или «подтверждением».
Одна строка вывода на каждую строку исходной трассировки.
Поле 1 — время пакета в десятичных секундах относительно
начала разговора. Поле 2 — дельта-время от последнего пакета.
Поле 3 — тип/направление пакета.
«Send» означает данные, идущие от отправителя к получателю,
«ack» означает подтверждение, идущее от получателя к отправителю.
Предшествующая «*» означает, что данные являются повторной передачей.
Предшествующая «-» означает пропуск в пространстве последовательностей
(т.е. отсутствующий пакет(ы)), «#» означает пакет нестандартного размера
(не макс. размер сегмента). Поле 4 содержит флаги пакета
(тот же формат, что и в необработанной трассировке). Поле 5 — номер
последовательности (начальный номер последовательности для отправки,
ожидаемый следующий номер для подтверждений). Число в скобках после
подтверждения — это дельта-время от первой отправки пакета до
подтверждения. Число в скобках после отправки — это
дельта-время от первой отправки пакета до текущей
отправки (только для дублирующихся пакетов). Дублирующиеся
отправки или подтверждения имеют число в квадратных скобках,
показывающее количество дубликатов на данный момент.
Вот короткий пример из начала ftp:
3.00 0.20 send . 512
3.20 0.20 ack . 1024 (0.20)
3.20 0.00 send P 1024
3.40 0.20 ack . 1536 (0.20)
3.80 0.40 * send . 0 (3.80) [2]
3.82 0.02 * ack . 1536 (0.62) [2]
Три секунды после начала разговора были отправлены байты 512–1023.
Через 200 мс они были подтверждены. Вскоре после этого
байты 1024–1535 были отправлены и снова подтверждены через 200 мс.
Затем, по неясной причине, 0–511 повторно передаётся, через 3.8
секунды после первой отправки (время кругового обхода для этого
ftp составляло 1 сек, ±500 мс). Поскольку получатель ожидает
1536, 1536 повторно подтверждается, когда приходит 0.
packetdat.awk
Вычисляет сводные данные по блокам для ftp (или аналогичной
однонаправленной передачи по tcp). [«Блок» относится к
части пространства последовательностей — по сути, номер пакета
последовательности, делённый на максимальный размер сегмента.]
Выводится строка-сводка, показывающая количество блоков,
количество пакетов, потребовавшихся для отправки этого количества блоков
(если нет потерянных или дублированных пакетов, количество
пакетов должно равняться количеству блоков) и
количество подтверждений.
За строкой-сводкой следует по одной строке информации
на каждый блок. Строка содержит восемь полей:
1 — номер блока
2 — начальный номер последовательности для этого блока
3 — время первой отправки
4 — время последней отправки
5 — время первого подтверждения
6 — время последнего подтверждения
7 — сколько раз блок был отправлен
8 — сколько раз блок был подтверждён
(все времена в десятичных секундах относительно начала
разговора.)
В качестве примера, вот первая часть вывода для
трассировки ftp:
# 134 chunks. 536 packets sent. 508 acks.
1 1 0.00 5.80 0.20 0.20 4 1
2 513 0.28 6.20 0.40 0.40 4 1
3 1025 1.16 6.32 1.20 1.20 4 1
4 1561 1.86 15.00 2.00 2.00 6 1
5 2049 2.16 15.44 2.20 2.20 5 1
6 2585 2.64 16.44 2.80 2.80 5 1
7 3073 3.00 16.66 3.20 3.20 4 1
8 3609 3.20 17.24 3.40 5.82 4 11
9 4097 6.02 6.58 6.20 6.80 2 5
Это означает, что было передано 134 блока (около 70К,
поскольку средний размер пакета составлял 512 байт). Для передачи
данных потребовалось 536 пакетов (т.е. в среднем каждый блок
был передан четыре раза). Рассмотрим, например, блок 4 — он
представляет 512 байт пространства последовательности от 1561 до 2048.
Он был впервые отправлен через 1.86 секунды после начала разговора.
Последняя отправка была через 15 секунд, и всего он был
отправлен 6 раз (т.е. в среднем повторялся каждые
2 секунды). Он был подтверждён один раз, через 140 мс
после первого получения.
stime.awk
atime.awk
Выводят по одной строке на каждую отправку или подтверждение, соответственно, в формате
<время> <номер последовательности>
где <время> — время в секундах с момента начала
передачи, а <номер последовательности> — номер последовательности отправляемого
или подтверждаемого пакета. Обычно я строю график этих данных в поисках подозрительных
паттернов.
Проблемой, которую я изучал, была пропускная способность передачи
пакетных данных на сетевых путях со средней задержкой (время кругового обхода
1–6 сек.) в типичных условиях сети DARPA Internet. Трассировка
ftp-передачи большого файла использовалась как исходный необработанный источник данных.
Метод был следующим:
- На локальном хосте (но не на Sun, где запущен tcpdump), подключиться
к удалённому ftp.
- На отслеживающем Sun запустить трассировку. Например,
tcpdump host local-host and remote-host and port ftp-data >tracefile
- На локальном хосте выполнить get или put большого файла (~500КБ),
предпочтительно в нулевое устройство (чтобы минимизировать эффекты вроде
закрытия окна приёмника в ожидании записи на диск).
- По завершении передачи остановить tcpdump. Использовать awk для создания
двух файлов со сводными данными (maxsize — максимальный размер пакета,
tracedata — файл с данными трассировки tcpdump):
awk -f send-ack.awk packetsize=avgsize tracedata >sa
awk -f packetdat.awk packetsize=avgsize tracedata >pd
- Пока печатаются файлы сводных данных, посмотреть,
как вела себя передача:
awk -f stime.awk tracedata | xgraph
(90% того, что вы узнаёте, кажется, происходит на этом шаге).
- Повторить все вышеперечисленные шаги несколько раз, в обоих направлениях,
в разное время суток, с различными реализациями протоколов
на другом конце.
- Используя один из пакетов анализа данных Unix (в моём случае,
S и Unix|Stat Гэри Перлмана), потратить несколько месяцев на изучение
данных.
- Что-то изменить в локальной реализации протокола и
повторить описанные выше шаги.
- Раз в неделю сообщать вашему спонсору, что вы открываете
удивительные вещи и что вы напишете этот исследовательский отчёт
«в самое ближайшее время».