Анализ сетевого трафика как метод диагностики сети

Анализ работы протокола ARP

Используем хостовую систему и виртуальную машину с сетевым адаптером, настроенным на виртуальную сеть узла. Установим на сетевом адаптере виртуальной машины IP-адрес из той же подсети, что и на адаптер vboxnet0 (адаптер виртуальной сети узла) основной системы.

Настройки адаптера vboxnet0 в основной системе:

# ip addr show dev vboxnet0
5: vboxnet0:  <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 vboxnet0
    inet6 fe80::800:27ff:fe00:0/64 scope link 
       valid_lft forever preferred_lft forever

Настройки сетевого адаптера в виртуальной машине:

# 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

Можно проверить командой ip neigh show dev vboxnet0, что в ARP-таблице основной системы нет записей связанных с интерфейсом vboxnet0.

Откроем еще одну консоль на основной системе и запустим tcpdump:

# tcpdump -ne -i vboxnet0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vboxnet0, link-type EN10MB (Ethernet), capture size 65535 bytes

Запустим ping виртуальной машины с основной системы:

# 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-таблице основной системы появилась запись об IP-адресе виртуальной машины:

# ip neigh show dev vboxnet0
192.168.56.33 lladdr 08:00:27:fd:e5:aa STALE

Вывод tcpdump:

# tcpdump -ne -i vboxnet0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vboxnet0, 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 08:00:27:fd:e5:aa > 0a:00:27:00:00:00, ethertype ARP (0x0806), 
      length 42: Reply 192.168.56.33 is-at 08:00:27:fd:e5:aa, length 28
12:16:29.466815 0a:00:27:00:00:00 > 08:00:27:fd:e5:aa, 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 08:00:27:fd:e5:aa > 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-адреса интерфейса vboxnet0 основной системы ("У кого адрес 192.168.56.33 ответь 192.168.56.1"). Вторая запись — ответ с MAC-адреса виртуальной машины на MAC-адрес основной системы ("192.168.56.33 имеет определенный MAC-адрес"). Третья и четвертая записи (ICMP-запрос и ICMP-ответ) являются результатом работы команды ping на основной системе.

Таким образом, основная система для того, чтобы отправить стандартный эхо-запрос виртуальной машине, предварительно по протоколу ARP получила MAC-адреса виртуальной машины и внесла его с привязкой к IP-адресу в свою ARP-таблицу.

Работа tcpdump была прервана комбинацией клавиш Ctrl+C. Перед завершением работы tcpdump печатает статистику работы: количество перехваченных, полученных фильтром и отброшенных ядром пакетов.

Анализ трафика на транспортном уровне с помощью tcpdump

Для фильтрации трафика определенного порта на транспортном уровне можно использовать ключевое слово port. Например:

# tcpdump -n -i eth0 src port 53
# tcpdump -n -i eth0 tcp port 80

В первом случае будут отбираться пакеты, несущие единицы передачи транспортного уровня (TCP или UDP), в которых порт-источник установлен в 53. Во втором случае — пакеты с TCP-сегментами, у которых порт источника или назначения равен 80.

Обратимся с основной системы к WEB-серверу, установленному на виртуальной машине:

# lynx 192.168.56.33

предварительно, запустив tcpdump на другой консоли:

# tcpdump -n -i vboxnet0 host 192.168.56.33 and port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vboxnet0, 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-сегмента, помимо номеров портов получателя и отправителя содержит ряд параметров [ 7 ] :

• Номер последовательности ( 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

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 (сброса соединения).

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-сообщения исходному узлу о недостижимости порта.