Введение
Очень часто для поиска проблем в работе сети используются анализаторы сетевого трафика.tcpdump является одним из представителей данного класса программ, она позволяет прослушать (отобразить/сохранить) и проанализировать работу сети на уровне передаваемых сетевых пакетов, фреймов и др. единиц передачи сетевого трафика.В зависимости от конфигурации сети, tcpdump может прослушивать не только пакеты, предназначенные данному MAC-адресу, но и широковещательные пакеты.
Прослушивание
перехват сетевых пакетов основан на "беспорядочном" (promiscuous) режиме работы сетевого адаптера.
В зависимости от используемого сетевого оборудования для соединения компьютеров в сети Ethernet существуют следующиевозможности прослушивания трафика:
- В сети на основе концентраторов весь трафик с
концентраторахаба доступен любому сетевому хосту. - В сетях на основе коммутаторов (свичей) сетевому хосту доступен только ее трафик, а также весь широковещательный трафик данного сегмента.
- Некоторые управляемые коммутаторы имеют функцию копирования трафика данного порта на порт мониторинга ("зеркалирование",мониторинг порта).
- При использовании специальных средств (ответвителей), включаемых в разрыв сетевого подключения и передающих трафик подключения на отдельный порт возможно прослушивание соответствующего порта.
- "Трюк" с концентратором — порт коммутатора, трафик которого необходимо прослушать, включают через концентратор, подключив к концентратору также узел-монитор (при этом в большинстве случаев уменьшается производительность сетевого подключения).
Итак, утилита tcpdump входит в большинство дистрибутивов Unix и позволяет перехватывать и отображать/сохранять в файл сетевой трафик. Утилита использует библиотеку libpcap. Для Windows тоже существует . Для работы утилиты ее необходимо установить. Например, в Debian она устанавливается с помощью команды:
debian:~# apt-get install tcpdump
Для работы утилиты необходимы права суперпользователя (т.к. изменяются настройки сетевого интерфейса - переводится в "безпорядочный" режим). В общем случае формат команды tcpdump имеет следующий вид:
debian:~# tcpdump <опции> <фильтр>
Опции утилиты tcpdump
-i интерфейс
Задает интерфейс, с которого необходимо анализировать трафик (без указания интерфейса - анализ "первого попавшегося").
-n
Отключает преобразование IP в доменные имена. Если указано -nn, то запрещается преобразование номеров портов в название протокола.
-e
Включает вывод данных канального уровня (например, MAC-адреса).
-v
Вывод дополнительной информации (TTL, опции IP).
-s размер
Указание размера захватываемых пакетов. (по-умолчанию - пакеты больше 68 байт)
-w имя_файла
Задать имя файла, в который сохранять собранную информацию.
-r имя_файла
Чтение дампа из заданного файла.
-p
Захватывать только трафик, предназначенный данному узлу. (по-умолчанию - захват всех пакетов, например в том числе широковещательных).
-q
Переводит tcpdump в "бесшумный режим", в котором пакет анализируется на транспортном уровне (протоколы TCP, UDP, ICMP), а не на сетевом (протокол IP).
-t
Отключает вывод меток времени.
Фильтрующие выражения tcpdump
В команде tcpdump возможно задать фильтрующее правило. Фильтрующее выражение состоит из параметра отбора пакетов и значения задаваемого параметра. Например, команда
debian:~# tcpdump -i eth0 host 10.0.0.1
имеет опцию -i eth0, задающую прослушиваемый интерфейс eth0 и фильтрующее выражение, заставляющее tcpdump отображать все пакеты, у которых в поле отправителя и в поле получателя стоит адрес 10.0.0.1. При этом, host - это параметр отбора, а 10.0.0.1 - это значение параметра.
Фильтрующие выражения можно комбинировать между собой с помощью дополнительных операторов and, or и not. C помощью этих операторов можно строить довольно сложные логические конструкции, группируя параметры в скобки. Например, команда:
debian:~# tcpdump -i eth0 dst 10.0.0.5 and port 53
ограничит отображение только пакетами отправленные на хост 10.0.0.5 по протоколу DNS (порт 53).
Наиболее часто используемые фильтрующие параметры команды tcpdump:
dst хост
Проверяет, совпадает ли адрес получателя IP-пакета с указанным значением. Возможно задавать как IP, подсеть в формате 10.0.0.1/24, так и имя хоста.
src хост
Проверяет, совпадает ли адрес отправителя IP пакета с указанным значением. Возможно задавать как IP, подсеть в формате 10.0.0.1/24, так и имя хоста.
host хост
Проверяет, совпадает ли адрес отправителя или получателя с заданным значением. Возможно задавать как IP, подсеть в формате 10.0.0.1/24, так и имя хоста.
net имя_сети
Проверяется, находится ли адрес отправителя/получателя в заданной сети. Возможно указание сети в формате CIDR (например 10.0.0.1/22), либо указание имени сети, заданной в файле /etc/networks.
ip | arp | rarp | tcp | udp | icmp [хост]
Проверяет, принадлежит ли пакет одному из указанных протоколов и при указании адреса хоста проверяет, совпадает ли адрес отправителя\получателя с заданным. Возможно задавать как IP, подсеть в формате 10.0.0.1/24, так и имя хоста.
[tcp | udp] dst port номер_порта
Проверяется, принадлежит ли пакет протоколу TCP/UDP и равен ли порт назначения заданному. Можно указать номер порта, либо имя, заданное в файле /etc/services.
[tcp | udp] src port номер_порта
Проверяется, принадлежит ли пакет протоколу TCP/UDP и равен ли порт источника заданному. Можно указать номер порта, либо имя, заданное в файле /etc/services.
[tcp | udp] port номер_порта
Проверяется, принадлежит ли пакет протоколу TCP/UDP и равен ли порт назначения или источника заданному. Можно указать номер порта, либо имя, заданное в файле /etc/services.
ip broadcast
Проверяется, является ли IP пакет широковещательным.
ether { src | dst | host } MAC_адрес
Проверяется, принадлежит ли сетевой пакет источнику, назначению, источнику или назначению имеющему заданный MAC_адрес.
ether broadcast
Проверяется, является ли ARP-пакет широковещательным.
Примеры использования команды tcpdump
Анализ трафика на сетевом уровне (ARP, ICMP) с помощью tcpdump
Предположим, у нас имеется 2 хоста. Хост 1 с интерфейсом eth0 и следующими параметрами:
host1:~# ip addr show dev eth0
5: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UNKNOWN qlen 1000
link/ether 0a:00:27:00:00:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.56.1/24 brd 192.168.56.255 scope global eth0
inet6 fe80::800:27ff:fe00:0/64 scope link
valid_lft forever preferred_lft forever
А так же хост2 с интерфейсом eth1
host2:~# ip addr show dev eth1
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast state UP qlen 1000
link/ether 08:00:27:fd:e5:aa brd ff:ff:ff:ff:ff:ff
inet 192.168.56.33/24 scope global eth1
inet6 fe80::a00:27ff:fefd:e5aa/64 scope link
valid_lft forever preferred_lft forever
Предположим, что до текущего момента сетевого обмена данными между хостами не происходило и если на хосте 2 запустить команду ip neigh show, то будет видно что в ARP-таблице нет записей. Проведем маленький эксперимент. Запустим на одном из виртуальных интерфейсов host1 утилиту tcpdump:
host1:~# tcpdump -ne -i eth0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
Далее запустим ping машины host2 с машины host1:
host1:~# ping -c 1 192.168.56.33 PING 192.168.56.33 (192.168.56.33) 56(84) bytes of data. 64 bytes from 192.168.56.33: icmp_req=1 ttl=64 time=1.06 ms --- 192.168.56.33 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.067/1.067/1.067/0.000 ms
После этого в ARP-таблице системы host1 появилась запись об IP-адресе машины host2:
host1:~# ip neigh show dev eth0 192.168.56.33 lladdr 01:00:27:77:e5:00 HOST2
На виртуальной консоли tcpdump нам отобразил следующую информацию:
host1:~# tcpdump -ne -i eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:16:29.465780 0a:00:27:00:00:00 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806),
length 42: Request who-has 192.168.56.33 tell 192.168.56.1, length 28
12:16:29.466786 01:00:27:77:e5:00 > 0a:00:27:00:00:00, ethertype ARP (0x0806),
length 42: Reply 192.168.56.33 is-at 01:00:27:77:e5:00, length 28
12:16:29.466815 0a:00:27:00:00:00 > 01:00:27:77:e5:00, ethertype IPv4 (0x0800),
length 98: 192.168.56.1 > 192.168.56.33: ICMP echo request, id 5284, seq 1, length 64
12:16:29.467934 01:00:27:77:e5:00 > 0a:00:27:00:00:00, ethertype IPv4 (0x0800),
length 98: 192.168.56.33 > 192.168.56.1: ICMP echo reply, id 5284, seq 1, length 64
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel
Каждая запись о сетевом пакете в таком формате содержит время перехвата пакета, MAC-адреса отправителя и получателя, тип протокола, длину пакета и сведения о содержимом пакета. Первая запись описывает широковещательный ARP-запрос с MAC-адреса интерфейса eth0 системы host1 ("У кого адрес 192.168.56.33, это говорит 192.168.56.1"). Вторая запись— ответ с MAC-адреса машины host2 на MAC-адрес системы host1 ("192.168.56.33 имеет MAC-адрес 01:00:27:77:e5:00"). Третья и четвертая записи(ICMP-запрос и ICMP-ответ) являются результатом работы команды ping на системе host1. Далее работа tcpdump была прерванакомбинацией клавиш Ctrl+C. Перед завершением работы tcpdump печатает статистику работы: количество перехваченных, полученных фильтром и отброшенных ядром пакетов
Таким образом, система host1 для того, чтобы отправить стандартный эхо-запрос машине host2, предварительно по протоколу ARP получила MAC-адреса машины host2 и внесла его с привязкой к IP-адресу в свою ARP-таблицу.
Анализ трафика на транспортном уровне (TCP, UDP) с помощью tcpdump
Предположим на системе host2 установлен некий WEB-сервер. Попробуем на машине host1 открыть страницу с этого web-сервера с помощью консольного браузера lynx:
host1:~# lynx 192.168.56.33
На другой консоли предварительно запустим tcpdump с фильтрующими параметрами:
host1:~# tcpdump -n -i eth0 host 192.168.56.33 and port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
15:44:37.837393 IP 192.168.56.1.41533 > 192.168.56.33.80: Flags [S], seq 1209026235,
win 5840, options [mss 1460,sackOK,TS val 2934847 ecr 0,nop,wscale 7], length 0
15:44:37.838118 IP 192.168.56.33.80 > 192.168.56.1.41533: Flags [S.], seq 370041518,
ack 1209026236, win 5792, options [mss 1460,sackOK,TS val 3275261 ecr 2934847,nop,wscale 2], length 0
15:44:37.838157 IP 192.168.56.1.41533 > 192.168.56.33.80: Flags [.], ack 1,
win 46, options [nop,nop,TS val 2934847 ecr 3275261], length 0
15:44:37.839254 IP 192.168.56.1.41533 > 192.168.56.33.80: Flags [P.], seq 1:222,
ack 1, win 46, options [nop,nop,TS val 2934847 ecr 3275261], length 221
15:44:37.839921 IP 192.168.56.33.80 > 192.168.56.1.41533: Flags [.], ack 222,
win 1716, options [nop,nop,TS val 3275262 ecr 2934847], length 0
15:44:37.848118 IP 192.168.56.33.80 > 192.168.56.1.41533: Flags [P.], seq 1:446,
ack 222, win 1716, options [nop,nop,TS val 3275264 ecr 2934847], length 445
15:44:37.848156 IP 192.168.56.1.41533 > 192.168.56.33.80: Flags [.], ack 446,
win 54, options [nop,nop,TS val 2934848 ecr 3275264], length 0
15:44:37.849738 IP 192.168.56.33.80 > 192.168.56.1.41533: Flags [F.], seq 446,
ack 222, win 1716, options [nop,nop,TS val 3275264 ecr 2934848], length 0
15:44:37.850366 IP 192.168.56.1.41533 > 192.168.56.33.80: Flags [F.], seq 222,
ack 447, win 54, options [nop,nop,TS val 2934848 ecr 3275264], length 0
15:44:37.851267 IP 192.168.56.33.80 > 192.168.56.1.41533: Flags [.], ack 223, win 1716,
options [nop,nop,TS val 3275265 ecr 2934848], length 0
…
В данном примере клиент (192.168.56.1) c TCP-порта 41533 устанавливает соединение с сервером (192.168.56.33), слушающим на порту 80, делает запрос, получает необходимые данные и соединение завершается.
Заголовок TCP-сегмента, помимо номеров портов получателя и отправителя содержит ряд параметров:
- Номер последовательности ( seq ). Определяет порядок следования байт в отправляемом в сеть потоке (смещение первого байта в сегменте относительно начала потока данных).
- Подтвержденный номер ( ACK ). Максимальный номер байта в полученном сегменте увеличенный на 1. Отправляемые отправителю подтверждения одновременно служат запросом новой порции данных.
- Управляющие флаги ( SYN - S, ACK, FIN -F , RST — R , PSH - P, URG )
- Окно ( win ) — количество байтов данных, ожидаемых отправителем данного, начиная с байта номер которого указан в поле ack. Для оптимизации передачи отправитель не ждет подтверждения для каждого отправленного сегмента, а может отправить в сеть группу сегменту (но в байтах не больше размера окна). Если качество канала плохое (много запросов на повторную передачу, теряются подтверждения) окно уменьшается, если хорошее — окно увеличивается.
- Опции. Используются для решения вспомогательных задач. Например, передается MSS (Maximum segment size) — максимальный размер сегмента.
Процесс установления двунаправленного соединения по протоколу TCP отражают первые три записи tcpdump:
- Клиент отправляет серверу TCP-сегмент с установленным флагом SYN, начальным "случайным" номером ( 1209026235 ), с которого будут нумероваться байты в отправляемом им потоке, максимальный размер окна — объем, который разрешено передавать серверу без подтверждения от клиента (5840):
15:44:37.837393 IP 192.168.56.1.41533 > 192.168.56.33.80: Flags [S], seq 1209026235, win 5840, options [mss 1460,sackOK,TS val 2934847 ecr 0,nop,wscale 7], length
- Сервер отправляет клиенту TCP-сегмент с установленными флагами SYN и ACK, начальным "случайным" номером ( 370041518 ), с которого будут нумероваться байты в отправляемом им потоке, и максимальный размер окна для клиента (5792). Данный сегмент также является подтверждением получения запроса на установление соединения от клиента:
15:44:37.838118 IP 192.168.56.33.80 > 192.168.56.1.41533: Flags [S.], seq 370041518, ack 1209026236, win 5792, options [mss 1460,sackOK,TS val 3275261 ecr 2934847,nop,wscale 2], length
- Клиент отправляет серверу TCP-сегмент с установленным флагом ACK, который является подтверждением получения сегмента от сервера (далее tcpdump отображает относительные значения seq и ask ):
15:44:37.838157 IP 192.168.56.1.41533 > 192.168.56.33.80: Flags [.], ack 1, win 46, options [nop,nop,TS val 2934847 ecr 3275261], length
После этого соединение считается установленным.
В следующей паре записей клиент передает в секции данных сегмента серверу запрос протокола прикладного уровня (221 байт) и получает от сервера подтверждение его получения:
15:44:37.839254 IP 192.168.56.1.41533 > 192.168.56.33.80: Flags [P.], seq 1:222, ack 1, win 46, options [nop,nop,TS val 2934847 ecr 3275261], length 221 15:44:37.839921 IP 192.168.56.33.80 > 192.168.56.1.41533: Flags [.], ack 222, win 1716, options [nop,nop,TS val 3275262 ecr 2934847], length 0
При этом флаг PSH (P) используется для оповещения отправляющей стороны о том, что принимающая готова принимать данные. Далее сервер отправляет данные клиенту (445 байт) и получает от него подтверждение получения:
15:44:37.848118 IP 192.168.56.33.80 > 192.168.56.1.41533: Flags [P.], seq 1:446, ack 222, win 1716, options [nop,nop,TS val 3275264 ecr 2934847], length 445 15:44:37.848156 IP 192.168.56.1.41533 > 192.168.56.33.80: Flags [.], ack 446, win 54, options [nop,nop,TS val 2934848 ecr 3275264], length 0
Затем по инициативе сервера соединение завершается. Сервер шлет пакет с установленным флагом FIN:
15:44:37.849738 IP 192.168.56.33.80 > 192.168.56.1.41533: Flags [F.], seq 446, ack 222, win 1716, options [nop,nop,TS val 3275264 ecr 2934848], length 0
Клиент в ответ также отправляет пакет с установленным флагом FIN, данный пакет одновременно является подтверждением получения запроса на завершение соединения от сервера:
15:44:37.850366 IP 192.168.56.1.41533 > 192.168.56.33.80: Flags [F.], seq 222, ack 447, win 54, options [nop,nop,TS val 2934848 ecr 3275264], length 0
Серверу остается лишь подтвердить получение FIN-сегмента от клиента:
15:44:37.851267 IP 192.168.56.33.80 > 192.168.56.1.41533: Flags [.], ack 223, win 1716, options [nop,nop,TS val 3275265 ecr 2934848], length 0
Реакция tcpdump на попытку подключения к закрытому порту 23/tcp:
21:56:14.381091 IP 192.168.56.1.54040 > 192.168.56.33.23: Flags [S], seq 2956835311, win 5840, options [mss 1460,sackOK,TS val 5164501 ecr 0,nop,wscale 7], length 0 21:56:14.381688 IP 192.168.56.33.23 > 192.168.56.1.54040: Flags [R.], seq 0, ack 2956835312, win 0, length 0
В данном примере с системы 192.168.56.1 делается попытка подключится к несуществующему TCP-сервису на узле 192.168.56.33. Удаленная система реагирует отправкой сегмента с установленным флагом RST (сброса соединения).
Реакция tcpdump на отправку UDP-датаграммы на закрытый порт 53/udp:
21:55:16.925906 IP 192.168.56.1.41979 > 192.168.56.33.53: 6561+ A? www.tut.by. (28) 21:55:16.926615 IP 192.168.56.33 > 192.168.56.1: ICMP 192.168.56.33 udp port 53 unreachable, length 64
В данном примере сделана попытка отправить UDP-датаграмму на несуществующий порт удаленной системы. Протокол UDP обычно реагирует отправкой ICMP-сообщения исходному узлу о недостижимости порта.
Другие примеры использования команды tcpdump:
# tcpdump -n -i ppp0 ether src 11:20:b3:d8:d8:2c
Вывод сетевой статистики с интерфейса ppp0 (-i ppp0) без преобразования IP в DNS (-n) тех фреймов, у которых MAC-адресом источника равен 11:20:b3:d8:d8:2c.
# tcpdump -n -e -i vlan0 ether broadcast
Вывод широковещательного трафика с интерфейса vlan0.
# tcpdump -n -i eth0 src 192.168.66.1
Фильтруются сетевые пакеты, в заголовке которых в поле источник указан IP-адрес192.168.66.1.
# tcpdump -n -i eth0 host 192.168.66.1
Фильтруются пакеты, в которых данный IP-адрес указан как источник или как получатель пакета.
# tcpdump -n -i eth0 src net 10.0.0.0 mask 255.0.0.0
Фильтруются пакеты, в которых источником указаны узлы сети 10.0.0.0/8.
# tcpdump -n -i eth0 icmp
Вывод только ICMP-пакетов с интерфейса eth0.
