Статья Сниффинг трафика и MITM-атаки: Wireshark, tcpdump и Ettercap в реальных сценариях

Спутанный кабель Ethernet на тёмном антистатическом коврике, подсвеченный бирюзовым светом снизу. На заднем плане в боке — экран ноутбука с колонками пакетов Wireshark.


На каждом втором внутреннем пентесте я нахожу учётные данные ещё до того, как запущу первый эксплойт. Не потому что заказчики глупы - потому что в плоской корпоративной сети достаточно включить сетевой интерфейс в режим прослушивания, чтобы увидеть всё: от FTP-паролей до NTLM-хешей в открытом виде. Сниффинг трафика и MITM-атаки - тот фундамент, без которого ни качественный пентест не провести, ни понять, что именно нужно защищать.
Статья написана от первого лица со слов моего коллеги. Приятного и полезного чтения!
Здесь - пошаговое руководство по трём инструментам: tcpdump для захвата на удалённых машинах без графики, Wireshark для визуального разбора дампов и Ettercap для ARP spoofing в лабораторных условиях. Каждый инструмент показан с реальным выводом терминала и объяснением каждого флага. Никакой теории ради теории - только то, что работает на практике.

Зачем пентестеру перехват трафика сети​

Прежде чем лезть в команды, разберёмся с мотивацией. В MITRE ATT&CK сниффинг - это техника Network Sniffing (T1040), входящая в тактики Credential Access и Discovery. Проще говоря, перехват трафика сети решает сразу две задачи: обнаружение структуры сети и сбор учётных данных.

На внутреннем пентесте первые 30 минут обычно уходят на пассивную разведку. Запускаешь tcpdump, пишешь весь трафик в pcap-файл, потом открываешь его в Wireshark. За эти полчаса узнаёшь больше, чем из любого скана: какие VLAN существуют, где стоят принтеры с веб-интерфейсом на голом HTTP, кто ходит на внутренний портал без шифрования, какие broadcast-протоколы выдают имена хостов. Вот почему сниффинг трафика Wireshark - первый шаг, а не архаизм из учебников.

Русскоязычные статьи обычно описывают MITM-атаку man-in-the-middle как академическую концепцию - Алиса, Боб, Мэлори и обмен ключами. Для понимания это полезно, но в реальной инфраструктуре всё проще и опаснее одновременно. Злоумышленнику в локальной сети не нужно подменять ключи шифрования - достаточно отравить ARP-кеш двух хостов и пропускать трафик через себя. Дальше дело техники: незашифрованные протоколы отдадут всё сами.

Пассивный и активный сниффинг - два режима работы​

Разница между пассивным и активным сниффингом - не просто классификация из учебника. От выбранного режима зависит, оставите ли вы следы в сети и какие инструменты пентеста сети понадобятся.

Пассивный сниффинг трафика - молчаливое наблюдение​

Пассивный сниффинг трафика - это перевод сетевого интерфейса в promiscuous mode и тихое прослушивание всего, что проходит по сегменту. Вы ничего не отправляете в сеть, не генерируете аномальный трафик, не ломаете ARP-таблицы. Просто слушаете.

Проблема: в современных сетях с коммутаторами (свитчами) пассивный сниффинг практически бесполезен. Коммутатор отправляет фреймы только на тот порт, где находится MAC-адрес получателя. В отличие от хабов, которые вещали всё на все порты, свитч изолирует трафик. Вы увидите только свои пакеты и broadcast-рассылки.

Включить promiscuous mode в Linux - одна команда: sudo ip link set eth0 promisc on. Для Wi-Fi - monitor mode через sudo airmon-ng start wlan0. В monitor mode беспроводной адаптер захватывает все 802.11-кадры в радиусе действия, включая кадры чужих сетей, но payload в сетях с WPA2/WPA3 зашифрован - для расшифровки нужен PSK и захваченный 4-way handshake. Открытые сети без шифрования сегодня встречаются редко (хотя в гостиницах и кофейнях - бывает). Именно поэтому более актуальный вектор - активная атака с поднятием rogue access point, а не пассивный monitor mode.

1777204203535.webp

Активный сниффинг через ARP-отравление сети​

Когда пассивный подход не работает, переходим к активному. Активный сниффинг - это вмешательство в работу сети для перенаправления чужого трафика на свой интерфейс. Самый распространённый метод - ARP-отравление сети, оно же ARP Cache Poisoning (T1557.002 в MITRE ATT&CK, тактики Credential Access и Collection).

Почему ARP так легко атаковать? Протокол ARP не имеет встроенной аутентификации. Представьте: в офисе любой может положить на стойку ресепшена визитку с чужим именем, и все будут звонить по указанному на ней номеру. Именно так работает ARP - любой хост может отправить gratuitous ARP-ответ, заявив, что MAC-адрес шлюза - это его собственный MAC. Жертва обновит свой ARP-кеш и будет слать кадры с MAC-адресом атакующего в качестве destination. Коммутатор по своей CAM-таблице доставит эти кадры на порт атакующего.

Весь трафик теперь проходит через нас. Читаем, записываем, модифицируем - а потом пересылаем настоящему получателю, чтобы жертва ничего не заметила. Это и есть MITM-атака man-in-the-middle в чистом виде.

1777204237896.webp

Подготовка лаборатории для сниффинга и MITM-атак​

Прежде чем запускать любые команды - подготовьте лабораторную среду. Никогда не тестируйте ARP spoofing в продакшн-сети без письменного разрешения. Это уголовно наказуемо, и «я просто учился» - не аргумент для суда.

Что понадобится:
  • ОС атакующего: Kali Linux 2024.x или Parrot OS (tcpdump, wireshark, ettercap-text-only стоят из коробки)
  • Виртуальная сеть: три VM в одном bridge-сегменте - атакующий, жертва (любая ОС), шлюз (можно роутер на OpenWrt или просто Linux с включённым forwarding)
  • Все VM в одной подсети без VLAN-сегментации, NAT через шлюзовую VM
  • IP forwarding на атакующей машине: echo 1 > /proc/sys/net/ipv4/ip_forward - без этого трафик жертвы будет тонуть на вашем интерфейсе
Я использую VirtualBox с Internal Network - он создаёт изолированный L2-сегмент, который отлично имитирует плоскую корпоративную сеть. VMware с Custom Network тоже подойдёт. Для полноты картины поднимите на одной из VM простой HTTP-сервер с формой логина: python3 -m http.server 8080 - так вы получите реальный трафик для перехвата.

tcpdump - анализ трафика в командной строке без GUI​

tcpdump - основной инструмент для захвата пакетов на удалённых серверах, где нет графической среды. На пентесте я часто получаю SSH-доступ к Linux-машине во внутреннем сегменте и первым делом запускаю tcpdump, чтобы понять, что вообще происходит вокруг.

Базовая команда: sudo tcpdump -i eth0 -nn -v. Флаг -i eth0 - интерфейс, -nn отключает DNS-резолвинг (без него tcpdump генерирует кучу DNS-запросов и тормозит вывод), -v добавляет verbose-информацию.

Для прицельного захвата - BPF-фильтры. Это тот же синтаксис, что и capture filters в Wireshark, обе утилиты работают поверх libpcap. Несколько боевых примеров:
  • sudo tcpdump -i eth0 port 80 or port 21 - HTTP и FTP, протоколы, где пароли летают открытым текстом
  • sudo tcpdump -i eth0 arp - только ARP-пакеты, незаменимо для обнаружения ARP-спуфинга в сети
  • sudo tcpdump -i eth0 -A -s0 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)' - только HTTP-пакеты с payload в ASCII (да, фильтр выглядит страшно, но работает безотказно)
Для записи в файл с последующим анализом сетевых пакетов в Wireshark: sudo tcpdump -i eth0 -w /tmp/capture.pcap -c 10000. Флаг -c 10000 остановит запись после 10 000 пакетов, чтобы дамп не разросся до неуправляемых размеров.

Вот реальный вывод tcpdump при перехвате HTTP-трафика с учётными данными:
Код:
$ sudo tcpdump -i eth0 -A -nn 'tcp port 80 and host 192.168.1.50'
tcpdump: verbose output suppressed, use -v for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:23:07.441223 IP 192.168.1.50.48212 > 192.168.1.10.80: Flags [P.], seq 1:224
...POST /login HTTP/1.1
Host: 192.168.1.10
Content-Type: application/x-www-form-urlencoded

username=admin&password=Qwerty123!
Три строки - и у вас логин с паролем. Именно это я показываю заказчику в отчёте, когда объясняю, почему внутренние сервисы без TLS - не «приемлемый риск», а прямая угроза. Флаг -A декодирует payload в ASCII, а фильтр tcp port 80 and host 192.168.1.50 сужает захват до HTTP-трафика конкретного хоста.

Wireshark - сниффинг трафика с визуальным анализом​

Если tcpdump - это стетоскоп, то Wireshark - полноценный микроскоп для сетевого трафика. На воркшопах я всегда говорю: захватывайте tcpdump-ом, анализируйте в Wireshark. Каждому инструменту - своё место.

Установка на Linux: sudo apt install wireshark. На Windows - скачиваете с wireshark.org и ставите вместе с Npcap (драйвер для перехвата пакетов). При установке Wireshark предложит добавить пользователя в группу wireshark - соглашайтесь, иначе придётся запускать от root.

Открываем pcap-файл, записанный tcpdump: File → Open → выбираем capture.pcap. Wireshark разложит каждый пакет по протокольным слоям: Ethernet, IP, TCP/UDP, прикладной протокол. Это и есть анализ сетевых пакетов в чистейшей форме.

Display filters - главное оружие. В отличие от capture filters, display filters работают постфактум и используют собственный синтаксис. Вот фильтры, с которых я начинаю на каждом пентесте:
  • http.request.method == "POST" - все POST-запросы, где обычно передаются формы логина
  • ftp.request.command == "PASS" - FTP-пароли открытым текстом
  • tcp.port == 23 - Telnet-сессии, вся аутентификация без шифрования
  • http.authorization contains "Basic" - HTTP Basic Auth с base64-кодированными (не зашифрованными!) учётными данными
  • dns.qry.name contains "internal" - DNS-запросы к внутренним доменам, которые раскрывают структуру инфраструктуры
Отдельно про Follow Stream - без этой функции я не провожу ни один анализ. Правый клик по пакету → Follow → TCP Stream. Wireshark соберёт все пакеты одной TCP-сессии и покажет диалог между клиентом и сервером в читаемом виде. Для HTTP - полный запрос и ответ, для FTP - всю последовательность команд включая: USER и PASS.

Пример через tshark (консольный Wireshark) - фильтрация HTTP-запросов с учётными данными:
Код:
$ tshark -r capture.pcap -Y 'http.request.method == "POST"' \
  -T fields -e ip.src -e http.host -e http.request.uri
192.168.1.50    portal.corp.local    /auth/login
192.168.1.55    helpdesk.corp.local  /api/v1/session
192.168.1.42    wiki.corp.local      /dologin.action
Три внутренних сервиса, три хоста, которые шлют учётные данные по HTTP. Флаг -Y задаёт display filter, -T fields переключает вывод в табличный формат, -e указывает поля для извлечения. Я регулярно вставляю этот однострочник в скрипты для автоматического сбора «low-hanging fruit» из большого дампа.

Ettercap и ARP spoofing - MITM-атака на практике​

Ettercap - инструмент, заточенный под MITM-атаки в локальных сетях. Он автоматизирует ARP-отравление, перехват трафика и даже модификацию пакетов на лету. В MITRE ATT&CK это Adversary-in-the-Middle (T1557) и подтехника ARP Cache Poisoning (T1557.002).
📚 Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме


1777204283689.webp

Маппинг на MITRE ATT&CK - инструменты пентеста сети в контексте фреймворка​

Каждое действие, описанное выше, имеет точный идентификатор в MITRE ATT&CK. Это нужно не только для отчёта - маппинг помогает защитникам понять, какие детекшн-правила писать.

ДействиеТехника MITRE ATT&CKТактикаИнструмент
Пассивный захват пакетовNetwork Sniffing (T1040)Credential Access, Discoverytcpdump, Wireshark
ARP-отравление и перехватARP Cache Poisoning (T1557.002)Credential Access, CollectionEttercap, arpspoof
MITM-проксированиеAdversary-in-the-Middle (T1557)Credential Access, CollectionEttercap, mitmproxy
LLMNR/NBT-NS PoisoningLLMNR/NBT-NS Poisoning and SMB Relay (T1557.001)Credential Access, CollectionResponder
Модификация трафика на летуTransmitted Data Manipulation (T1565.002)ImpactEttercap filters
Зеркалирование трафикаTraffic Duplication (T1020.001)ExfiltrationPort mirroring

Обратите внимание: T1040 и T1557 - в разных тактиках. Пассивный сниффинг - Discovery и Credential Access. Активный MITM - Credential Access и Collection. Это не формальность: разные тактики подразумевают разные методы обнаружения.

Обнаружение и защита от прослушивания сетевого трафика​

Знать атаки и не знать защиту - полдела. Вот что реально работает против сниффинга и MITM-атак на уровне сетевой инфраструктуры.

Dynamic ARP Inspection (DAI) - функция управляемых коммутаторов, которая проверяет ARP-пакеты по привязке IP-MAC из DHCP Snooping таблицы. Кто-то отправил gratuitous ARP с чужим IP - пакет дропается, порт может быть заблокирован. Это единственная надёжная защита от Ettercap ARP spoofing на уровне L2.

DHCP Snooping - предшественник DAI. Коммутатор запоминает, какой IP выдал DHCP-сервер какому MAC-адресу, и строит таблицу легитимных привязок. Без DHCP Snooping DAI работать не будет - они идут в связке.

Обнаружение promiscuous mode. Хост в promiscuous mode по-другому обрабатывает некоторые Ethernet-фреймы. Утилита nmap --script=sniffer-detect отправляет специально сформированные пакеты и анализирует ответы - так можно обнаружить сниффер в сети. Метод работает только в пределах L2-сегмента и часто даёт false negatives на современных ОС с включённым rp_filter - не стоит полагаться на него как на единственное средство детекции.

Мониторинг ARP-аномалий. IDS вроде Suricata или Snort детектируют аномально частые ARP-ответы от одного хоста - признак ARP-спуфинга. Правило: отслеживать количество gratuitous ARP с одного source MAC за единицу времени. Если коммутатор не поддерживает DAI - это единственный оставшийся механизм детекции.

Шифрование всего. Самая радикальная и самая надёжная мера. HTTPS с HSTS на всех внутренних сервисах, SMB signing, отказ от FTP и Telnet в пользу SFTP и SSH, WPA3-Enterprise для Wi-Fi. Если весь трафик зашифрован, сниффинг превращается в бесполезный захват мусора. Но я ни разу не видел корпоративную сеть, где это было реализовано на 100%.

Сегментация сети. Плоская сеть - подарок для атакующего. VLAN-сегментация с ACL между сегментами ограничивает broadcast-домен и делает ARP-отравление возможным только в пределах одного VLAN. Бухгалтерия, разработка и серверный сегмент в разных VLAN - атакующий в одном сегменте не достанет до другого через ARP spoofing.

Вопрос к читателям​

Для тех, кто разворачивал Ettercap в лаборатории с тремя VM: при запуске ettercap -T -M arp:remote с включённым IP forwarding через /proc/sys/net/ipv4/ip_forward жертва обычно сохраняет связность. Но при работе через bridge-интерфейс в VirtualBox часто возникает packet loss у жертвы выше 30%, даже если forwarding включён. Какой параметр ядра или настройку виртуальной сети вы используете, чтобы минимизировать потери? Поделитесь конкретной конфигурацией: тип сети в гипервизоре, значения net.bridge.bridge-nf-call-iptables или другие sysctl, которые решили проблему.
 
Последнее редактирование модератором:
Мы в соцсетях:

Взломай свой первый сервер и прокачай скилл — Начни игру на HackerLab

🚀 Первый раз на Codeby?
Гайд для новичков: что делать в первые 15 минут, ключевые разделы, правила
Начать здесь →
🔴 Свежие CVE, 0-day и инциденты
То, о чём ChatGPT ещё не знает — обсуждаем в реальном времени
Threat Intel →
💼 Вакансии и заказы в ИБ
Pentest, SOC, DevSecOps, bug bounty — работа и проекты от проверенных компаний
Карьера в ИБ →

HackerLab