Типичные сетевые атаки — MITM, ARP poisoning, DNS spoofing, sniffing

Когда вы открываете bank.com и видите зелёный замочек в адресной строке — это не магия и не маркетинг. Это результат десятилетий борьбы с конкретными классами атак, в которых злоумышленник пытался прочитать ваш трафик, подменить ответы или притвориться сервером. В этом уроке разберём четыре фундаментальные атаки: sniffing (пассивное прослушивание), ARP poisoning (атака на link layer), DNS spoofing (подмена DNS-ответов) и MITM (man-in-the-middle, общая категория «человек посередине»).

Это не уголовное руководство, а инженерное понимание. Вы должны знать, как эти атаки работают, чтобы понимать, зачем в современной инфраструктуре существуют TLS, DNSSEC, DoH, VPN, DHCP snooping и десятки других защитных механизмов. Без знания атак защиты выглядят как культ карго — «зачем-то так делают».

Pasive sniffing — слушаем чужой трафик

Простейшая атака — прослушивание трафика без вмешательства. Атакующий ставит свою сетевую карту в promiscuous mode (принимать все пакеты, а не только адресованные себе) и записывает всё, что пролетает через сетевой сегмент.

В 1990-е и начале 2000-х это была норма: HTTP, FTP, telnet, POP3, IMAP — все эти протоколы передавали данные в открытом виде. В Wi-Fi-кафе или в общем хабе достаточно было запустить tcpdump, и пароли, cookies, email-переписка летели открытым текстом.

Базовый sniffer руками:

# Запустить tcpdump на интерфейсе и выводить содержимое пакетов:
sudo tcpdump -i en0 -A 'tcp port 80'

# Захватить в pcap-файл для последующего анализа Wireshark-ом:
sudo tcpdump -i en0 -w /tmp/capture.pcap 'tcp port 80'

# Открыть в Wireshark, фильтровать только HTTP-запросы:
wireshark /tmp/capture.pcap
# Filter: http.request

Если трафик plain HTTP — atacking видит всё. Если HTTPS — видит только зашифрованный шум и метаданные (с каким IP/портом установлено соединение).

Защита: шифрование. TLS делает sniffing бесполезным: вы видите шум, не данные. С 2018 года TLS 1.3 устранил последние практические атаки на сам TLS-хендшейк. Поэтому plain HTTP в 2026 — табу. Google помечает HTTP-сайты как небезопасные, браузеры предупреждают пользователей, HSTS вынуждает использовать HTTPS.

ARP poisoning — ломаем link layer

Если коммутатор не пересылает чужие пакеты на атакующего, как ему стать MITM? Ответ — через атаку на ARP. Напомним: ARP (Address Resolution Protocol) — как hosts в локальной сети находят MAC-адрес по IP. Спросил «у кого 192.168.1.1?», получил ответ «у меня, мой MAC такой-то», ответы кэшируются в ARP-таблице на 1-5 минут.

Слабое место: ARP-ответы никак не аутентифицируются. Любой хост может прислать любому другому unsolicited ARP-ответ («Привет, 192.168.1.1 — это я»), и жертва обновит свою ARP-таблицу.

Подробнее:

1. Атакующий Eve посылает Alice unsolicited ARP-reply: «192.168.1.1 -> MAC Eve».
2. Параллельно посылает gateway: «192.168.1.10 (Alice) -> MAC Eve».
3. Теперь весь трафик Alice <-> Internet проходит через Eve. Eve включает forwarding (ip_forward=1) — пакеты транзитом идут к настоящему gateway, Alice ничего не замечает.
4. Eve видит весь plain-text трафик. Если HTTPS — может попытаться вынудить Alice к downgrade или внедрить фейковый сертификат (упадёт в браузере как security warning, но непродвинутый пользователь может проигнорировать).

Это active MITM. Атакующий не просто слушает — он сидит в самом потоке и может видоизменять трафик.

Защита:

• DHCP snooping и Dynamic ARP Inspection (DAI) на корпоративных коммутаторах. Switch отслеживает легитимные mappings и блокирует подозрительные ARP-ответы.
• Static ARP entries для критичных IP (gateway). Удобно для серверов.
• arpwatch / arp-scan — мониторинг изменений ARP. Если IP gateway внезапно поменял MAC — алерт.
• TLS — если атакующий и стал MITM, расшифровать HTTPS он не сможет. Поэтому ARP poisoning — угроза в основном для plain-text протоколов и для metadata.

# Посмотреть ARP-таблицу:
arp -a

# На macOS:
arp -n -a

# На Linux:
ip neigh show

# Зафиксировать gateway -- защита от ARP-poisoning:
sudo arp -s 192.168.1.1 aa:bb:cc:dd:ee:ff

DNS spoofing — подменяем ответы DNS

Когда вы вводите bank.com, ваш браузер делает DNS-запрос «какой IP у bank.com». Если злоумышленник может подменить ответ на этот запрос, он перенаправит вас на свой фейковый сервер.

Способы подмены:

1. DNS cache poisoning. Атакующий шлёт кучу фейковых DNS-ответов на резолвер, надеясь, что какой-то совпадёт с pending запросом по transaction ID (16-битный идентификатор — 65536 вариантов). Совпавший ответ резолвер примет и положит в кэш. Атака Каминского (2008) — классика.
2. MITM на DNS. Если атакующий уже в позиции MITM (через ARP poisoning, или контролирует Wi-Fi роутер), он перехватывает DNS-запросы и подсовывает свои ответы.
3. Скомпрометированный DNS-сервер. Если ваш resolver упал в руки злоумышленника (8.8.8.8 так не упадёт, но локальный роутер — запросто).
4. Rogue DHCP. Атакующий запускает свой DHCP-сервер в сети, который выдаёт клиентам адрес своего DNS-сервера. Жертвы используют атакующего как resolver.

Защита:

• HTTPS + TLS. Даже если DNS подменён, фейковый сервер не сможет предъявить валидный сертификат для bank.com. Браузер покажет security warning. Условие: пользователь не игнорирует warning.
• HSTS (HTTP Strict Transport Security). Сервер при первом HTTPS-визите шлёт заголовок Strict-Transport-Security: max-age=63072000. Браузер запоминает: «к bank.com только HTTPS, всегда». При следующем визите запрос на http:// автоматически конвертируется в https://. Это спасает от SSL stripping.
• HSTS preload list. Браузеры (Chrome/Firefox/Safari) встроенно знают список ведущих сайтов (Google, Facebook, банки), для которых HSTS включён с самого первого визита.
• DNSSEC. Криптографическая подпись DNS-ответов. Если zone подписана и resolver проверяет подписи, подменённый ответ не пройдёт. Внедрено плохо (~25% доменов в 2026), но для государственных и банковских доменов часто.
• DoH / DoT (DNS over HTTPS/TLS). DNS-запросы идут зашифрованно к доверенному резолверу. Локальный MITM не может их подменить.

# Проверить, поддерживает ли домен DNSSEC:
dig bank.com +dnssec | grep -E '(ad|RRSIG)'

# Использовать DoH через cloudflare:
curl -H 'accept: application/dns-json' \
  'https://1.1.1.1/dns-query?name=bank.com&type=A'

# Использовать публичный DoH вместо системного resolver:
# (в Chrome/Firefox в настройках Privacy/Network)

SSL stripping — хитрый downgrade attack

Отдельный класс атак — SSL stripping, открытый Moxie Marlinspike в 2009 на DefCon. Принцип: пользователь часто вводит bank.com без протокола, и браузер по умолчанию пробует HTTP, потом редирект на HTTPS. Атакующий в позиции MITM перехватывает HTTP-запрос и не даёт ему дойти до сервера, отвечает сам — притворяясь сервером, обслуживая через HTTP.

Защита — HSTS (упомянуто выше). С HSTS preload для критичных доменов первый запрос обязательно HTTPS, SSL stripping не работает.

MITM — общая категория

«Man in the middle» — это не одна атака, а класс. Любая ситуация, где атакующий находится в середине коммуникации, может читать и/или модифицировать трафик. Конкретные способы стать MITM:

• ARP poisoning в локальной сети.
• Rogue Wi-Fi access point. «Free Wi-Fi» с похожим именем — жертвы подключаются к фейковому AP, весь их трафик идёт через атакующего.
• DNS-based redirect.
• BGP hijacking. Атака на уровне маршрутизации интернета — атакующий объявляет, что IP-блок жертвы принадлежит его AS. Маршрутизаторы верят — трафик потёк к нему.
• Compromised router/ISP. Если ваш домашний роутер заражён или провайдер недобросовестный.

Главная защита — end-to-end шифрование и аутентификация:

1. TLS с верификацией сертификата. Атакующий не предъявит валидный сертификат для bank.com.
2. Certificate pinning в мобильных приложениях. Приложение знает, какой именно сертификат должен быть у сервера — любой другой отклоняется.
3. End-to-end шифрование в мессенджерах (Signal, WhatsApp, iMessage) — даже сервер не может прочитать сообщения, не говоря о MITM по дороге.

Wireshark и анализ атак

Wireshark — главный инструмент для отладки сети и для понимания атак (с разрешения). Открывает pcap-файлы и показывает каждый пакет в деталях.

Пример фильтров:

# Все ARP-пакеты (полезно для детекта ARP poisoning):
arp

# Только ARP-ответы (replies, не requests):
arp.opcode == 2

# Если видите больше одного reply для одного IP с разными MAC -- подозрительно

# Все DNS-запросы и ответы:
dns

# DNS-запросы по конкретному имени:
dns.qry.name == "bank.com"

# Если на один запрос пришло несколько ответов с разными IP -- подозрительно

# Все HTTP-запросы:
http.request

# Все попытки HTTPS handshake (TLS):
tls.handshake.type == 1  # client hello

# Live capture в Wireshark с фильтром на ARP:
sudo wireshark -i en0 -k -Y arp

# tcpdump эквивалент:
sudo tcpdump -i en0 arp -v

Попробуй сам

Запустите безопасный эксперимент — посмотрите ARP-трафик в своей сети.

# Откройте ARP-таблицу вашей машины:
arp -a

# Вы увидите что-то вроде:
# (192.168.1.1) at aa:bb:cc:dd:ee:ff on en0 ifscope [ethernet]
# (192.168.1.5) at 11:22:33:44:55:66 on en0 ifscope [ethernet]

# Запустите захват ARP-пакетов:
sudo tcpdump -i en0 arp -v

# Откройте другой терминал и пингуйте IP в вашей сети, которого ещё нет в кэше:
ping 192.168.1.42

# Вернитесь в первый терминал -- увидите ARP request "Who has 192.168.1.42?"
# и (если такой хост существует) -- ARP reply с его MAC

# Просмотрите DNS-резолв глазами:
sudo tcpdump -i en0 -n 'port 53' -A

# Откройте новый терминал и сделайте DNS-запрос:
dig example.com

# В первом терминале увидите DNS query и DNS response

Не пытайтесь делать ARP poisoning в реальной сети — это незаконно (преступление по УК РФ ст. 272 «Неправомерный доступ к компьютерной информации»). Для практики используйте изолированную лабу (3 виртуальные машины + virtualbox-overlay, или kathara/gns3).

Установите Wireshark и откройте bank.com в браузере с включённым capture. Найдите TLS Client Hello — посмотрите, какой Server Name Indication (SNI) браузер посылает. SNI — это домен в открытом виде до handshake. Это та информация, которую MITM может видеть даже при HTTPS — но не содержимое запросов.