⚙️ Паровой сервер ROADIT
Войти Регистрация

Wireshark: анализ трафика на примерах — фильтры, поиск аномалий

от

Когда сеть начинает вести себя как старый паровой котёл — то задержки появляются, то DNS внезапно перестаёт отвечать, то приложение жалуется на «сетевые проблемы», — администратору нужны не догадки, а факты.

Wireshark — один из главных инструментов для такой работы. Он позволяет посмотреть на сетевой обмен практически на уровне отдельных пакетов: кто с кем разговаривал, по какому протоколу, сколько длился диалог, где появились retransmission, RST, ICMP-ошибки или подозрительные последовательности.

В этой статье разберём рабочий подход: захват → фильтрация → поиск проблемы → анализ потока → подтверждение гипотезы.

⚙️ Содержание

Как думать о захвате трафика

Главная ошибка начинающего сетевого следопыта — сразу открыть огромный .pcapng и начать прокручивать тысячи пакетов.

Так работать можно, но это примерно как искать одну неисправную шестерёнку, высыпав весь механизм паровой машины на стол.

Лучше идти от вопроса:

Какое сетевое утверждение я хочу проверить?

Например:

  • сервер 10.10.20.15 действительно не отвечает?
  • DNS-запросы уходят, но ответы не возвращаются?
  • TCP-соединение устанавливается слишком долго?
  • есть ли retransmission?
  • кто отправляет TCP RST?
  • какой клиент создаёт аномальный объём трафика?
  • куда обращается неизвестный процесс?
  • действительно ли проблема находится в сети, а не в приложении?

От ответа зависит и точка захвата, и фильтр.

Где снимать трафик

На Linux сначала определим интерфейсы:

ip -br addr

или:

tshark -D

Последняя команда покажет интерфейсы, доступные TShark. Сам TShark использует -f для capture filter и -Y для display filter — синтаксис этих фильтров различается.

Например:

sudo tshark -i eth0

Для быстрого сохранения полного захвата:

sudo tshark -i eth0 -w incident.pcapng

Для ограниченного захвата DNS:

sudo tshark -i eth0 -f "port 53" -w dns.pcapng

Capture filter применяется до сохранения пакетов. Это удобно, когда трафика много и заранее известно, что именно требуется поймать. Wireshark использует для capture filters синтаксис libpcap/BPF.

Capture filter и Display filter — не перепутать

Это фундаментальная вещь.

Capture filter

Определяет, какие пакеты вообще попадут в захват.

Примеры:

  • host 10.10.20.15
  • tcp port 443
  • udp port 53
  • host 10.10.20.15 and tcp port 443
  • src host 10.10.20.15

Например:

sudo tshark -i eth0 -f "host 10.10.20.15 and tcp port 443" -w web.pcapng

Display filter

Работает уже с захваченными пакетами и позволяет гораздо глубже исследовать их содержимое.

Например:

  • ip.addr == 10.10.20.15
  • tcp
  • dns
  • http.request
  • tcp.analysis.retransmission

Официальная документация описывает display filters как механизм выбора пакетов по протоколу, наличию поля, значению поля и сравнению нескольких полей.

💡 Совет

Не ограничивайте capture filter без необходимости. Если место на диске позволяет, лучше получить более полный захват и потом использовать display filters.
Иначе можно обнаружить, что нужного пакета просто нет в котле с доказательствами.

Первый запуск: что смотреть в интерфейсе

Открываем файл:

wireshark incident.pcapng

Типичный интерфейс состоит из трёх основных областей:

  1. список пакетов;
  2. дерево протоколов выбранного пакета;
  3. необработанные байты пакета.

Особенно полезна строка Display Filter. Wireshark проверяет синтаксис фильтра непосредственно при вводе и показывает, является ли выражение корректным.

Базовые display filters, которые стоит помнить

Начнём с простых.

По протоколу:

  • tcp
  • udp
  • dns
  • icmp
  • arp
  • tls

По IP

ip.addr == 192.168.1.100

Трафик только от источника:

ip.src == 192.168.1.100

Только к адресу назначения:

ip.dst == 192.168.1.100

По порту

  • tcp.port == 443
  • tcp.dstport == 22
  • udp.port == 53

Комбинации

ip.addr == 10.10.20.15 && tcp.port == 443

или:

ip.addr == 10.10.20.15 && (tcp.port == 80 || tcp.port == 443)

Для сложных выражений используйте скобки — это избавляет от неоднозначности и делает фильтр читаемым.

HTTP: что реально отправляет клиент

Если трафик не зашифрован и Wireshark распознал HTTP, можно искать запросы:

http.request

Только GET:

http.request.method == "GET"

POST:

http.request.method == "POST"

Определённый Host:

http.host == "example.com"

Определённый URI:

http.request.uri contains "/api/"

Поиск подозрительного User-Agent:

http.user_agent contains "curl"

А если нужно увидеть конкретный разговор, удобнее выбрать пакет и использовать Follow → TCP Stream. Это позволяет восстановить последовательность TCP-обмена, а не рассматривать каждый пакет как независимую шестерёнку.

HTTPS: почему «посмотреть URL» уже не всегда получится

Современный HTTPS шифрует содержимое HTTP-сессии. Поэтому фильтр:

http.request

для обычного TLS-трафика, как правило, ничего полезного не покажет. Но это не означает, что HTTPS полностью невидим. Можно исследовать:

tls

Например, искать TLS ClientHello:

tls.handshake.type == 1

В зависимости от версии протокольного анализатора и конкретного TLS-стека можно исследовать поля ClientHello, включая SNI:

tls.handshake.extensions_server_name

Также полезно посмотреть TLS-ошибки, версии протокола и параметры handshake.

Для актуальных имён полей лучше пользоваться встроенным справочником Wireshark: список полей огромен и зависит от версии dissector’ов. Официальный Display Filter Reference предоставляет актуальную таблицу полей и протоколов.

Поиск TCP retransmission

Один из самых полезных фильтров при диагностике медленной сети:

tcp.analysis.retransmission

Также стоит проверить:

tcp.analysis.fast_retransmission

и:

tcp.analysis.duplicate_ack

Если retransmission много, это повод исследовать:

  • потерю пакетов;
  • перегрузку канала;
  • проблемы Wi-Fi;
  • ошибки физического интерфейса;
  • MTU;
  • перегруженный firewall;
  • перегрузку виртуального коммутатора;
  • асимметричную маршрутизацию;
  • проблемы на промежуточном оборудовании.

Но retransmission сам по себе ещё не доказывает неисправность сети. Нужно посмотреть:

  1. где именно возникает потеря;
  2. сколько retransmission относительно общего количества пакетов;
  3. есть ли burst-поведение;
  4. растёт ли RTT;
  5. есть ли корреляция с нагрузкой;
  6. видны ли ошибки интерфейса на сетевом оборудовании.

TCP RST: кто оборвал разговор

Фильтр:

tcp.flags.reset == 1

показывает TCP RST. RST может быть нормальным явлением, а может указывать на проблему. Например:

Client → Server: SYN
Server → Client: SYN,
ACK Client → Server: ACK
Client → Server: HTTP request
Server → Client: RST

Такое поведение уже интересно. Но причина может находиться на разных уровнях:

  • приложение закрыло сокет;
  • сервис не принимает запрос;
  • firewall вмешался в соединение;
  • балансировщик оборвал сессию;
  • сервер аварийно закрыл соединение;
  • пакет был сформирован промежуточным устройством.

Поэтому следующий шаг — определить MAC/IP-адрес отправителя RST и контекст TCP-сессии.

TCP handshake и диагностика установления соединения

Для SYN:

tcp.flags.syn == 1 && tcp.flags.ack == 0

Для SYN/ACK:

tcp.flags.syn == 1 && tcp.flags.ack == 1

Это позволяет быстро увидеть, кто начинает соединения и кто на них отвечает.

Если клиент постоянно отправляет:

SYN 
SYN
SYN 
SYN

а SYN/ACK не появляется, ищем проблему между клиентом и сервером. Если SYN/ACK приходит, но финальный ACK не возвращается — уже появляется другой набор гипотез:

  • обратный маршрут;
  • firewall;
  • NAT;
  • асимметрия;
  • фильтрация;
  • проблемы на хосте клиента.

DNS: быстро ищем проблемы разрешения имён

Для DNS:

dns

Только запросы:

dns.flags.response == 0

Только ответы:

dns.flags.response == 1

Поиск NXDOMAIN:

dns.flags.rcode == 3

Поиск конкретного имени:

dns.qry.name == "example.com"

Или:

dns.qry.name contains "example"

Что искать в DNS

Если пользователь говорит: «Сайт иногда не открывается». можно проверить:

  • DNS-запрос действительно уходит?
  • Есть ли ответ?
  • Какой RCODE?
  • Сколько времени проходит между запросом и ответом?
  • Какой DNS-сервер отвечает?
  • Не идут ли повторные запросы?
  • Нет ли огромного количества NXDOMAIN?

Например, если запросы уходят на DNS-сервер, но ответов нет, проблема может находиться ещё до HTTP и TCP.

ICMP: сеть сама рассказывает, где ей больно

Начнём с:

icmp

Особенно интересны ICMP Destination Unreachable:

icmp.type == 3

Например, можно увидеть:

  • Network Unreachable;
  • Host Unreachable;
  • Port Unreachable;
  • Fragmentation Needed.

Последний вариант особенно интересен при диагностике MTU.

Для IPv6 используйте:

icmpv6

Поиск аномалий: не существует одной волшебной кнопки

Wireshark не является автоматическим детектором компрометации, который посмотрел на pcap и объявил: «Виноват злой хакер, котёл №3». Аномалии нужно искать по признакам.

Признак №1 — неожиданный внешний адрес

Например:

ip.dst == 203.0.113.50

Если неизвестны направления трафика, сначала исследуйте:

Statistics → Conversations

Там удобно посмотреть, какие IP-адреса и порты действительно участвовали в обмене.

Признак №2 — необычные порты

Можно искать:

tcp

и сортировать пакеты по TCP-порту. Необычный порт сам по себе не означает атаку. Администратор должен сначала установить:

  • какое приложение использует порт;
  • принадлежит ли адрес серверу;
  • соответствует ли это штатной архитектуре.

Признак №3 — огромный объём одного направления

Проверьте:

Statistics → Conversations → IPv4 / IPv6

и:

Statistics → Endpoints

Это помогает найти хосты, которые внезапно стали сетевыми паровозами.

Expert Information — автоматические подсказки

Wireshark умеет формировать Expert Information по некоторым обнаруженным состояниям. Обычно это хороший первый ориентир, но не окончательный диагноз. Идея проста: Expert Information говорит, куда посмотреть, а не кто виноват. Если Wireshark показывает retransmission, нужно проверить последовательность пакетов. Если виден malformed packet — проверить, действительно ли пакет повреждён, а не просто не полностью разобран конкретным dissector’ом. Если присутствует warning — проверить контекст.

Цвета пакетов: полезная автоматика

Coloring Rules позволяют визуально выделять интересующие типы трафика. Например, можно сделать отдельные правила для:

  • TCP retransmission;
  • TCP RST;
  • DNS;
  • HTTP;
  • ICMP;
  • подозрительных адресов.

Сохранённые display filters также можно создавать через интерфейс Wireshark, чтобы не вводить сложные выражения заново.

Для постоянной работы администратора это особенно полезно: собственная коллекция фильтров превращается в персональный набор гаечных ключей для сетевого котла.

Практический сценарий: «сервер стал медленным»

Предположим:

  • клиент: 10.10.10.50;
  • сервер: 10.10.20.15;
  • приложение работает на TCP/443;
  • пользователь жалуется на задержки.

Шаг 1. Отбираем трафик

ip.addr == 10.10.20.15 && tcp.port == 443

Шаг 2. Ищем retransmission

ip.addr == 10.10.20.15 && tcp.port == 443 && tcp.analysis.retransmission

Шаг 3. Проверяем RST

ip.addr == 10.10.20.15 && tcp.port == 443 && tcp.flags.reset == 1

Шаг 4. Смотрим handshake

ip.addr == 10.10.20.15 && tcp.port == 443 && tcp.flags.syn == 1

Шаг 5. Смотрим конкретный TCP stream

Выбираем пакет → Follow → TCP Stream.

Шаг 6. Проверяем статистику

Открываем:

Statistics → Conversations

и смотрим объём и длительность соединений.

Шаг 7. Формируем гипотезу

Например:

В захвате видно большое количество retransmission между клиентом и сервером, причём они группируются в моменты высокой нагрузки.

Но это ещё не вывод:

«сломался коммутатор».

Нужно подтвердить гипотезу другими источниками:

ip -s link show eth0
ethtool -S eth0
ss -s
ss -ti

И, если есть доступ к сетевому оборудованию, проверить counters интерфейсов.

Анализ через TShark без GUI

Wireshark особенно хорош, когда нужно расследовать инцидент на рабочей станции. Но на сервере без графического интерфейса пригодится TShark. Например:

tshark -r incident.pcapng -Y 'tcp.analysis.retransmission'

Получить DNS-запросы:

tshark -r incident.pcapng -Y 'dns.flags.response == 0'

Показать HTTP-запросы:

tshark -r incident.pcapng -Y 'http.request'

Применить фильтр и вывести подробности:

tshark -r incident.pcapng -Y 'ip.addr == 10.10.20.15' -V

TShark поддерживает -Y для display filter, а -f — для capture filter. Это различие сохраняется и в CLI-инструменте. Узнать доступные поля можно через:

tshark -G fields

А доступные протоколы:

tshark -G protocols

Как искать неизвестное соединение

Допустим, IDS или EDR сообщает:

Хост 10.10.10.25 устанавливает подозрительное внешнее соединение.

Первый фильтр:

ip.addr == 10.10.10.25

Далее:

ip.src == 10.10.10.25

Смотрим:

  • destination IP;
  • destination port;
  • протокол;
  • частоту соединений;
  • DNS перед соединением;
  • TLS ClientHello;
  • длительность TCP-сессии;
  • объём переданных данных.

Если есть DNS:

ip.addr == 10.10.10.25 && dns

Если есть TLS:

ip.addr == 10.10.10.25 && tls

Если обнаружен SNI:

tls.handshake.extensions_server_name

Так постепенно строится цепочка:

Фильтр для аномального поведения: пример

Допустим, нужно посмотреть TCP-пакеты, которые могут быть интересны с точки зрения неисправности:

tcp.analysis.retransmission ||
tcp.analysis.fast_retransmission || 
tcp.analysis.duplicate_ack ||
tcp.flags.reset == 1

Получается своеобразный «аварийный клапан» для TCP.

Дальше нельзя просто сказать: «Вот оно, всё красное — сеть сломана». Нужно разбить поток по хостам и соединениям. Например:

ip.src == 10.10.10.25 &&
(
tcp.analysis.retransmission ||
tcp.flags.reset == 1  
)

Так мы уже задаём конкретный вопрос: Какие подозрительные TCP-события генерирует именно этот клиент?

Поиск конкретного текста в пакетах

Wireshark позволяет искать данные в захвате. Это может пригодиться при работе с незашифрованными протоколами или тестовыми стендами. Например, ищем:

password

или:

error

Однако важно понимать разницу между поиском текста и display filter. Display filter обращается к разобранным полям протокола. Поиск текста может работать с содержимым пакета. На production-трафике будьте осторожны: дамп может содержать пароли, токены, cookies, персональные данные и другую чувствительную информацию.

Что делать после обнаружения проблемы

Хороший сетевой анализ заканчивается не фразой: «Wireshark показал retransmission». А цепочкой доказательств, например:

  1. Клиент отправляет TCP-сегмент.
  2. Сервер его не подтверждает.
  3. Клиент повторяет передачу.
  4. Возникает retransmission.
  5. Через некоторое время сервер отвечает.
  6. На интерфейсе клиента одновременно растёт RX/TX error counter.
  7. После замены проблемного интерфейса retransmission исчезают.

Вот это уже расследование. Wireshark дал наблюдение, а системные и сетевые метрики позволили превратить его в диагноз.

Типичные ошибки при работе с Wireshark

Ошибка №1. Снимать всё подряд

Огромный capture быстро превращается в цифровой угольный склад. Лучше заранее определить:

  • интерфейс;
  • направление;
  • время;
  • хосты;
  • протокол.

Ошибка №2. Путать capture и display filters

tcp port 443

и:

tcp.port == 443

выглядят похоже, но относятся к разным языкам фильтрации. Первый вариант характерен для capture filter, второй — для display filter.

Ошибка №3. Делать вывод по одному пакету

Один RST ничего не доказывает. Одна retransmission тоже. Ищите последовательность событий.

Ошибка №4. Игнорировать временную шкалу

Сетевые проблемы часто видны именно по времени: 

request → 1 ms → ответ

против:

request → 1 ms → retransmission → 1 s → ответ

Ошибка №5. Смотреть только на IP

Иногда проблема очевидна на уровне Ethernet:

  • ошибки интерфейса;
  • MAC-flapping;
  • ARP;
  • VLAN;
  • duplex;
  • MTU.

Поэтому при необходимости начинайте с нижнего уровня модели и поднимайтесь вверх.

Мини-шпаргалка администратора

ЗадачаDisplay filter
TCPtcp
UDPudp
DNSdns
ICMPicmp
ARParp
TLStls
Хостip.addr == 10.0.0.10
Источникip.src == 10.0.0.10
Назначениеip.dst == 10.0.0.10
TCP/443tcp.port == 443
HTTP-запросыhttp.request
GEThttp.request.method == “GET”
DNS-запросыdns.flags.response == 0
DNS NXDOMAINdns.flags.rcode == 3
TCP RSTtcp.flags.reset == 1
SYNtcp.flags.syn == 1 && tcp.flags.ack == 0
Retransmissiontcp.analysis.retransmission
Fast retransmissiontcp.analysis.fast_retransmission
Duplicate ACKtcp.analysis.duplicate_ack

Список полей Wireshark очень велик, поэтому эту таблицу стоит воспринимать как стартовый набор, а не как полный справочник. Официальный Display Filter Reference содержит значительно более широкий набор полей.

Финальный алгоритм расследования

Когда приходит тикет «сеть тормозит», можно действовать по короткому алгоритму:

1.Определить проблему
↓
2. Найти точку захвата
↓
3. Сделать ограниченный или полный capture
↓
4. Отфильтровать нужный хост
↓
5. Проверить DNS
↓
6. Проверить TCP handshake
↓
7. Проверить retransmission / duplicate ACK / RST
↓
8. Проверить RTT и временные интервалы
↓
9. Follow TCP Stream
↓
10. Сверить с логами и counters
↓
11. Подтвердить или отвергнуть гипотезу

Самое важное здесь — последний пункт. Wireshark не должен становиться гадальным шаром администратора. Его задача — дать настолько подробную картину происходящего в сети, чтобы гипотезу можно было проверить. Когда пакеты выстроены в последовательность, сеть перестаёт быть чёрным ящиком. Она начинает разговаривать — SYN-ами, ACK-ами, DNS-запросами, TLS handshake и retransmission. А задача админа — научиться понимать этот разговор.

⚙️ Машинное отделение ROADIT благодарит за прочтение.
Больше команд, шпаргалок и обзоров — на roadit.ru и в нашем Телеграф-канале.
📋 Все команды

Оставьте комментарий