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

Как устроены сети: модели OSI/TCP-IP и движение пакета

Сети в пентесте — это не дополнительная тема, а фундамент. Сканирование портов, перехват трафика, анализ логов, поиск уязвимых сервисов, обход сегментации — всё это упирается в понимание: на каком уровне модели происходит событие и что именно путешествует по сети.

В этой статье разберём:

что такое модели OSI и TCP/IP и зачем они нужны

как данные превращаются в кадры/пакеты/сегменты

как пакет реально проходит путь от вашего компьютера до удалённого сервера

!Сопоставление OSI и TCP/IP с примерами протоколов и устройств

Зачем вообще нужны модели (и почему их две)

Модель — это способ описать сеть слоями, чтобы не путать разные типы задач.

OSI — учебная и концептуальная модель из 7 уровней. Её любят за точность терминов.

TCP/IP — практическая модель, ближе к тому, как реально устроен стек протоколов в интернете.

В пентесте модели помогают быстро отвечать на вопросы:

проблема в кабеле/вайфае или в IP-маршрутизации?

порт закрыт потому что файрвол режет TCP или потому что сервис не слушает?

это атака на приложение (HTTP) или на транспорт (TCP)?

Модель OSI простыми словами

Ниже — уровни OSI сверху вниз. Важно: верхние уровни ближе к приложениям, нижние — ближе к “железу”.

| Уровень OSI | Что делает | Примеры протоколов/данных | Что часто смотрит пентестер | |---|---|---|---| | Прикладной | Логика приложений и форматы запросов | HTTP, DNS, SMTP | заголовки, параметры, API, DNS-записи | | Представления | Представление данных: шифрование/кодировки/сжатие | TLS, UTF-8, JSON | версия TLS, сертификаты, шифры | | Сеансовый | Управление сеансом взаимодействия | (часто “растворён” в TLS/приложениях) | авторизация, длительные сессии | | Транспортный | Доставка между процессами (порты), надёжность | TCP, UDP | порты, флаги TCP, потери, RST | | Сетевой | Доставка между хостами (IP-адреса), маршрутизация | IPv4/IPv6, ICMP | маршруты, TTL, доступность, фильтрация | | Канальный | Доставка внутри одного канала/сегмента (MAC), кадры | Ethernet, Wi‑Fi (802.11), ARP | ARP-таблицы, VLAN, MAC-адреса | | Физический | Биты по среде передачи | кабель, радиоканал | уровень сигнала, линк, ошибки |

Практическая подсказка: если вы видите IP-адрес — это сетевой уровень. Если MAC-адрес — канальный. Если порт 443 — транспортный.

Модель TCP/IP (то, что вы встречаете в реальности)

В TCP/IP уровни обычно объединяют так:

| TCP/IP слой | Примерно соответствует OSI | Примеры | |---|---|---| | Прикладной | OSI 5–7 | HTTP, DNS, SSH, TLS | | Транспортный | OSI 4 | TCP, UDP | | Интернет (сетевой) | OSI 3 | IP, ICMP | | Канальный/доступ к сети | OSI 1–2 | Ethernet, Wi‑Fi, ARP |

Почему так: многие функции OSI “сеансового” и “представления” уровня в интернете реализуются внутри прикладных протоколов или TLS.

Инкапсуляция: как данные “обрастают заголовками”

Когда приложение отправляет данные, они проходят вниз по стеку. Каждый уровень добавляет свой заголовок (а иногда и “хвост”), чтобы следующий уровень понимал, как доставлять.

Типичный путь:

Приложение формирует данные (например, HTTP-запрос).

TCP добавляет заголовок: порты, номера последовательности, флаги.

IP добавляет заголовок: IP-адрес источника/назначения, TTL.

Ethernet/Wi‑Fi добавляет заголовок кадра: MAC-адреса, тип протокола.

На принимающей стороне происходит обратный процесс — деинкапсуляция.

Полезные термины:

Кадр (frame) — единица канального уровня (Ethernet/Wi‑Fi). Там живут MAC-адреса.

Пакет (packet) — обычно про IP (сетевой уровень). Там живут IP-адреса.

Сегмент (segment) — обычно про TCP (транспортный уровень).

Датаграмма (datagram) — часто говорят про UDP (транспортный уровень).

Что такое MAC, IP и порт — и почему это разные “адреса”

MAC-адрес нужен, чтобы доставить кадр внутри локального сегмента (например, в вашей сети Ethernet или в вашей Wi‑Fi сети до точки доступа).

IP-адрес нужен, чтобы доставить пакет между сетями через маршрутизаторы.

Порт нужен, чтобы доставить данные конкретному процессу на хосте (например, веб-сервер слушает 443).

Один и тот же запрос одновременно использует все три:

до ближайшего “соседа” (шлюза) — по MAC

до конечного сервера — по IP

до конкретного сервиса на сервере — по порту

Движение пакета: от браузера до сайта (пошагово)

Разберём реальный сценарий: вы открываете https://example.com.

Шаг 1. DNS: узнаём IP по имени

Браузер не может отправить IP-пакет “на домен”. Ему нужен IP-адрес.

Упрощённо:

Браузер спрашивает у системы: “какой IP у example.com?”

Система обращается к DNS-серверу (обычно по UDP/53, иногда TCP/53).

Получает IP-адрес и кеширует его.

Что важно в пентесте:

DNS — отдельная поверхность атаки и разведки (поддомены, зоны, утечки).

DNS-запросы часто видно в трафике, если нет защищённого DNS.

Официальная спецификация DNS: RFC 1034 и RFC 1035.

Шаг 2. Выбор следующего узла: локально или через шлюз

Компьютер сравнивает IP назначения с вашей сетью.

если сервер “в вашей подсети” — отправит напрямую

если “в другой сети/интернете” — отправит на шлюз по умолчанию (обычно домашний роутер)

Шаг 3. ARP: узнаём MAC-адрес получателя в локальной сети

Чтобы отправить Ethernet-кадр, нужен MAC-адрес получателя. Но у нас есть только IP (например, IP шлюза).

Тут включается ARP:

ПК отправляет в локальную сеть ARP-запрос: “кто имеет IP шлюза? сообщите MAC”.

Шлюз отвечает ARP-ответом со своим MAC.

ПК сохраняет соответствие IP→MAC в ARP-таблицу на некоторое время.

ARP описан в RFC 826.

Что важно в пентесте:

ARP работает только в пределах одного L2-сегмента.

ARP связан с атаками уровня локальной сети (например, подмена соответствий), но основа — понимание, что без ARP ваш кадр не уйдёт.

Шаг 4. Формирование кадра и работа коммутатора

ПК формирует Ethernet-кадр:

MAC-источник: MAC вашей сетевой карты

MAC-назначение: MAC шлюза

внутри кадра: IP-пакет до IP сервера

Дальше кадр попадает на коммутатор (или Wi‑Fi точку доступа), который пересылает кадр по таблице MAC-адресов.

Ключевая мысль: коммутатор видит MAC, но не обязан разбираться в IP.

Шаг 5. Маршрутизатор: пересылка IP-пакета между сетями

Шлюз (маршрутизатор) получает кадр, извлекает IP-пакет и смотрит:

IP-адрес назначения

таблицу маршрутизации

Затем он отправляет пакет дальше в сторону провайдера/интернета.

На каждом L2-участке пути меняются MAC-адреса (кадр пересобирается заново), но IP-адрес назначения остаётся тем же (если нет NAT).

IP описан в RFC 791 (IPv4) и RFC 8200 (IPv6).

Шаг 6. TCP-соединение: “рукопожатие” до передачи данных

HTTPS обычно работает поверх TCP (порт 443). Прежде чем передать HTTP-запрос, устанавливается TCP-соединение.

Упрощённо (TCP three-way handshake):

Клиент → сервер: SYN

Сервер → клиент: SYN-ACK

Клиент → сервер: ACK

После этого стороны могут надёжно передавать данные (с подтверждениями и порядком).

TCP описан в RFC 793. UDP — в RFC 768.

Что важно в пентесте:

SYN, ACK, RST помогают понять, порт реально открыт или фильтруется.

многие техники сканирования опираются именно на поведение TCP.

Шаг 7. TLS и HTTP: что видит сеть, а что скрыто

Для https:// поверх TCP поднимается TLS:

шифрует полезную нагрузку (HTTP внутри)

аутентифицирует сервер сертификатом

Сеть по пути обычно видит:

IP-адреса

TCP-порты

факт установки TLS и часть метаданных

Но содержимое HTTP-запросов шифруется.

TLS формально стандартизован в RFC 8446 (TLS 1.3).

Шаг 8. Ответ идёт обратно

Ответ сервера проходит обратный путь:

сервер отправляет данные в TCP-соединении

пакет маршрутизируется обратно до вашей сети

у вас деинкапсулируется до приложения

!Путь пакета: где меняются MAC-адреса, а где сохраняется IP

Где в этой картине NAT и файрвол

NAT

NAT (Network Address Translation) часто включён на домашнем/офисном роутере. Он меняет параметры соединения так, чтобы много внутренних устройств могли выходить в интернет через один внешний IP.

Типичный эффект:

внутренний IP (например, 192.168.x.x) не маршрутизируется в интернете

“снаружи” ваши соединения выглядят как идущие с публичного IP роутера

Для пентеста это важно, потому что NAT влияет на:

доступность внутренних хостов извне

интерпретацию логов (много пользователей за одним IP)

Файрвол

Файрвол может работать на разных уровнях:

на хосте (локальный файрвол на машине)

на периметре (межсетевой экран)

Он может:

блокировать порты

“дропать” пакеты (молчать)

“резетить” соединение (послать TCP RST)

Это напрямую влияет на то, как выглядят результаты сканирования.

Минимальный практический набор: что наблюдать на каждом уровне

| Что вы наблюдаете | Уровень | Чем обычно смотрят | |---|---|---| | “линк поднялся/упал”, качество Wi‑Fi | физический/канальный | системные индикаторы, драйвер, мониторинг | | MAC, ARP, VLAN | канальный | сниффер трафика, ARP-таблица ОС | | IP, маршруты, TTL, ICMP | сетевой | ping, traceroute/tracert, таблица маршрутов | | порты, TCP-флаги, соединения | транспортный | ss/netstat, сканеры портов, сниффер | | DNS/HTTP/TLS | прикладной | логи, прокси, анализатор трафика |

Частые ошибки новичков (и как мыслить правильно)

Путать MAC и IP: MAC — локально, IP — между сетями.

Думать, что “коммутатор маршрутизирует”: коммутатор в основном пересылает кадры по MAC, маршрутизатор пересылает пакеты по IP.

Считать, что “если не пингуется, значит хост мёртв”: ICMP может быть запрещён, а TCP-порт — открыт.

Игнорировать DNS: иногда “сеть не работает” на самом деле означает “DNS не отвечает”.

Что дальше по курсу

Дальше будем углубляться в практику:

адресация IPv4/IPv6, подсети и маршрутизация

TCP/UDP подробнее: порты, флаги, состояния

базовая диагностика и чтение трафика (чтобы понимать, что именно происходит)

Адресация IPv4/IPv6, подсети, NAT и ARP: практика и примеры

В прошлой статье мы разобрали уровни OSI/TCP-IP и путь пакета от браузера до сайта. Теперь закрепим фундамент на практике: научимся читать адреса, понимать в какой сети находится узел, что означает префикс /24 или /64, где и как появляется NAT, и почему без ARP локальная сеть просто не доставит кадр.

Эта тема напрямую влияет на пентест:

правильный выбор диапазона для сканирования

понимание, почему хост “виден” из одной сети и “пропадает” из другой

корректная интерпретация логов, где за одним публичным IP прячется много устройств

работа в локальном сегменте: ARP-таблица, L2-достижимость, сегментация

!Общая картина: где работают подсети, ARP и NAT

IPv4: что означает адрес и почему важен префикс

Структура IPv4-адреса

IPv4 — это адрес вида A.B.C.D, где каждое число от 0 до 255, например 192.168.1.10.

IPv4 сам по себе не говорит, где граница сети. Границу задаёт маска или префикс (CIDR):

192.168.1.10/24 означает, что первые 24 бита — это “часть сети”, оставшиеся — “часть хоста”

то же самое часто пишут маской 255.255.255.0

Практический смысл:

адрес сети: “имя” подсети

широковещательный адрес: “всем в подсети”

диапазон хостов: адреса, которые можно назначать устройствам

Пример: 192.168.1.10/24

Для /24 обычно получается:

сеть: 192.168.1.0

broadcast: 192.168.1.255

хосты: 192.168.1.1 – 192.168.1.254

Важно: это “обычная” логика для большинства IPv4-сетей. Есть исключения (например, /31 для point-to-point), но в базовой практике пентеста почти всегда сначала встречаются /24, /16, /20, /23.

Частные и специальные диапазоны IPv4

Самое частое в локальных сетях — частные (private) адреса, которые не маршрутизируются в интернете:

10.0.0.0/8

172.16.0.0/12

192.168.0.0/16

Они стандартизованы в RFC 1918.

Ещё полезные специальные диапазоны:

127.0.0.0/8 — loopback (ваш же хост), чаще всего 127.0.0.1

169.254.0.0/16 — link-local (самоназначение, когда нет DHCP), RFC 3927

Для пентеста это важно:

увидели 10.x.x.x в логах сервера — это может быть внутренний адрес, “протёкший” через прокси/балансировщик

увидели 169.254.x.x — вероятно, проблема с DHCP/адресацией, а не “файрвол что-то режет”

Подсети и CIDR: как быстро понимать “кто в одной сети”

Главное правило

Два IPv4-узла в одной подсети могут общаться напрямую на L2 (через коммутатор), если:

у них одинаковый префикс

их адреса попадают в один и тот же сетевой диапазон

Если адрес назначения в другой подсети, хост отправит трафик на шлюз по умолчанию.

Быстрая практика на примерах

Предположим, у вас хост 10.10.5.23/20.

Префикс /20 означает, что сеть режется крупнее, чем /24. Типичный диапазон для /20 в третьем октете идёт шагом 16.

10.10.0.0/20 покрывает 10.10.0.0 – 10.10.15.255

10.10.16.0/20 покрывает 10.10.16.0 – 10.10.31.255

Следовательно:

10.10.5.23 и 10.10.14.8 в одной подсети (0–15)

10.10.5.23 и 10.10.20.1 в разных подсетях (0–15 и 16–31)

Таблица-шпаргалка по “популярным” префиксам IPv4

| Префикс | Маска | Очень грубо: сколько хостов | Где часто встречается | |---|---|---:|---| | /24 | 255.255.255.0 | 254 | домашние сети, небольшие VLAN | | /23 | 255.255.254.0 | 510 | объединение двух /24 | | /22 | 255.255.252.0 | 1022 | средние сегменты | | /20 | 255.255.240.0 | 4094 | корпоративные подсети | | /16 | 255.255.0.0 | 65534 | крупные сети, иногда “плоские” |

Почему числа “не круглые”: в IPv4 адрес сети и broadcast обычно не назначают хостам.

Как это применяется в пентесте

при доступе в корпоративную VPN вы часто получаете, например, 10.8.12.34/24: это подсказка, где начинать разведку

если вы видите несколько интерфейсов на хосте (две подсети), это может быть “мост” между сегментами

понимание префикса помогает не сканировать лишнее и не пропустить нужное

IPv6: базовая адресация без боли

IPv6 выглядит непривычно: 2001:db8:1234:5678:abcd:ef01:2345:6789.

Ключевые идеи:

IPv6 — 128-битные адреса

подсети почти всегда имеют префикс /64 (это практический стандарт для LAN)

NAT в IPv6 обычно не нужен по задумке архитектуры (но встречаются исключения)

Основы IPv6 описаны в RFC 4291.

Сокращения в записи IPv6

ведущие нули в блоке можно опустить: 00ab → ab

одну последовательность блоков 0000 можно заменить на :: (только один раз в адресе)

Пример:

2001:0db8:0000:0000:0000:0000:0000:0001

сокращённо: 2001:db8::1

2001:db8::/32 — это документационный диапазон для примеров.

Самые полезные типы IPv6-адресов

Global Unicast — глобальные адреса “как публичные” в IPv4

Link-local — адреса для общения внутри канала, начинаются с fe80::/10 и есть почти всегда (даже без DHCP)

ULA (Unique Local Address) — “частные” IPv6, обычно fd00::/8, стандартизованы в RFC 4193

Практический смысл для пентестера:

даже если в сети “всё закрыто”, у узлов почти всегда есть link-local адреса, и локальные IPv6-взаимодействия могут неожиданно оказаться доступными

иногда безопасность “забывают” настроить для IPv6, хотя IPv4 фильтруют (типичная дыра в корпоративных сетях)

NAT: что он реально делает и как мешает/помогает в пентесте

Что такое NAT простыми словами

NAT — это переписывание параметров пакетов на границе сети. Чаще всего речь про IPv4.

Самый распространённый вариант — PAT (Port Address Translation), когда много внутренних хостов выходят в интернет через один публичный IP, различаясь портами.

Классическое описание NAT есть в RFC 3022.

Мини-пример NAT (PAT)

Внутри сети:

ваш ноутбук: 192.168.1.10

роутер LAN: 192.168.1.1

роутер WAN (публичный): 203.0.113.5

Вы открываете сайт по HTTPS. До NAT это выглядит как:

источник: 192.168.1.10:51514

назначение: 93.184.216.34:443

На роутере после NAT станет:

источник: 203.0.113.5:40001

назначение: 93.184.216.34:443

Роутер запоминает соответствие (в NAT-таблице), чтобы обратный трафик вернуть нужному внутреннему хосту.

Почему NAT важен для интерпретации логов

Если вы анализируете логи внешнего сервиса, то множество разных пользователей может выглядеть как один IP (публичный IP NAT):

в офисе сотни людей могут идти “с одного адреса”

у мобильных операторов это ещё заметнее

Это влияет на:

расследования (атрибуция)

rate-limit (может “банить всех”)

корреляцию событий (нужно учитывать заголовки прокси, X-Forwarded-For и архитектуру)

Port forwarding: как “пробрасывают” сервисы внутрь

Если нужно открыть доступ извне к внутреннему хосту, делают DNAT/port forwarding.

Пример:

внешний 203.0.113.5:2222 → внутренний 192.168.1.20:22

Для пентеста это означает:

снаружи вы видите сервис на нестандартном порту, но внутри это может быть обычный 22

иногда проброс делают временно и забывают закрыть

ARP: как IP превращается в доставку по MAC в локальной сети

Что решает ARP

В Ethernet/Wi‑Fi внутри одного L2-сегмента доставка идёт по MAC-адресам, а приложения оперируют IP-адресами.

ARP отвечает на вопрос:

“какой MAC соответствует IP-адресу X в моей локальной сети?”

ARP описан в RFC 826.

Как выглядит ARP-обмен

Сценарий: ваш ПК хочет отправить пакет на шлюз 192.168.1.1.

ПК проверяет ARP-кеш: знает ли он MAC для 192.168.1.1.

Если не знает — отправляет ARP Request широковещательно: “кто имеет 192.168.1.1, ответьте 192.168.1.10”.

Шлюз отвечает ARP Reply: “192.168.1.1 — это aa:bb:cc:dd:ee:ff”.

ПК кладёт запись в ARP-кеш на некоторое время.

Ключевые ограничения:

ARP работает только внутри одного L2-сегмента (обычно один VLAN/одна Wi‑Fi сеть)

для адресов “в интернете” ARP не ищет MAC удалённого сервера — он ищет MAC шлюза

ARP-таблица: что смотреть на практике

Полезно уметь быстро проверить ARP-кеш и связать его с наблюдаемой связностью.

Примеры команд:

Что вы обычно увидите:

записи вида 192.168.1.1 lladdr aa:bb:cc:dd:ee:ff REACHABLE

со временем записи могут стать STALE (Linux) и обновиться при необходимости

ARP и безопасность: почему пентестеру нельзя это игнорировать

В локальной сети ARP — часть “повседневной магии”. Но из-за своей природы ARP исторически связан с классом атак, где злоумышленник пытается подменить соответствия IP→MAC.

Здесь важно базовое понимание, что именно ломается:

хост начинает отправлять кадры “не тому” устройству

трафик можно перехватывать или ронять, пока запись в ARP-кеше актуальна

Мы не углубляемся в техники атак в этой статье, но понимание механики ARP — обязательная база.

Связка “подсеть + ARP + NAT”: три частых сценария из практики

Сценарий: “я пингую IP, но не понимаю, почему это не локально”

Проверка:

посмотрите свой IP и префикс (ip addr / ipconfig)

определите, попадает ли IP назначения в ваш диапазон

если нет — трафик уйдёт на шлюз, а ARP будет по IP шлюза, а не по IP назначения

Сценарий: “в логах 10.0.0.5, но сервис же в интернете”

Возможные причины:

вы смотрите логи внутреннего сервиса

перед сервисом стоит reverse proxy/LB, который пишет внутренние адреса

клиент приходит через VPN/туннель

Действие: уточнить, где именно точка логирования и какие прокси-заголовки используются.

Сценарий: “из интернета ничего не открывается на мой хост”

Частые причины:

вы за NAT и нет port forwarding

провайдер использует CGNAT

локальный/периметровый файрвол блокирует входящие

Действие: проверить внешний IP, наличие проброса портов, и где именно стоит фильтрация.

Мини-чеклист для пентестера: что фиксировать при входе в новую сеть

ваш IPv4/IPv6 адрес и префикс (какая подсеть)

шлюз по умолчанию (куда уйдёт “вне подсети”)

DNS-серверы (часто дают подсказки о домене/инфраструктуре)

есть ли IPv6 и какие типы адресов (global/ULA/link-local)

ARP/NDP соседи (кто рядом в L2)

Что дальше по курсу

Дальше логично углубляться в транспорт:

TCP и UDP: состояния, флаги, отличие “filtered/closed/open”

как это проявляется в сканировании и в анализе трафика

базовая диагностика: как быстро понять, на каком уровне проблема

Коммутация и маршрутизация: VLAN, trunk, routing и ACL

В прошлых статьях мы разобрали, как пакет “обрастает” заголовками и почему в локальном сегменте всё упирается в MAC и ARP, а между сетями — в IP и маршрутизацию. Теперь соберём это в практическую картину корпоративной сети: коммутаторы, VLAN, trunk-порты, маршрутизация между VLAN и ACL (списки контроля доступа).

Это основа для пентеста, потому что именно здесь обычно “живут”:

сегментация сети (где вам нельзя ходить)

точки, где трафик можно фильтровать и логировать

ошибки конфигурации, из-за которых сегментация “на бумаге” не работает

!Общая схема: как VLAN разделяют L2, а маршрутизация и ACL контролируют связь между подсетями

Коммутация и маршрутизация: что делает кто

Коммутация (switching)

Коммутатор (обычно L2) пересылает Ethernet-кадры по MAC-адресам. Он строит MAC-таблицу (какой MAC “за каким портом”) и использует её для доставки внутри одного L2-домена.

Ключевое ограничение:

L2-коммутация работает внутри одного L2-сегмента

VLAN как раз и “рисует границы” L2-сегмента

Маршрутизация (routing)

Маршрутизатор (или L3-коммутатор) пересылает IP-пакеты между разными сетями/подсетями на основе таблицы маршрутизации.

Ключевая мысль:

если хост в VLAN10 хочет попасть в VLAN20, ему нужен L3-узел (шлюз), который выполнит маршрутизацию

VLAN: виртуальная сегментация на канальном уровне

VLAN (Virtual LAN) — это способ разделить один физический коммутатор (и даже несколько коммутаторов) на несколько независимых L2-сегментов.

Практический эффект VLAN:

устройства в разных VLAN не находятся в одном L2-домене

широковещательные кадры (включая ARP-запросы) не “проливаются” между VLAN

чтобы обмениваться трафиком между VLAN, нужен routing (inter-VLAN)

Почему это важно в пентесте:

“видимость” соседей в L2 обычно ограничена вашей VLAN

многие локальные техники завязаны на L2 (например, ARP), поэтому сегментация VLAN резко меняет картину

Справочный материал по концепции VLAN и 802.1Q:

VLAN (Wikipedia)

IEEE 802.1Q (Wikipedia)

Access-порт: порт “в одну VLAN”

Access-порт коммутатора принадлежит одной VLAN. Кадры на таком порту идут “без тегов” (обычный Ethernet для конечного устройства).

Пример:

ПК сотрудника подключён в access-порт VLAN10

сервер подключён в access-порт VLAN20

С точки зрения ПК:

он просто в своей сети (подсети) и шлёт ARP, IP и т.д.

про VLAN он не думает

Trunk: как несколько VLAN проходят по одному кабелю

Trunk-порт нужен, чтобы соединять:

коммутатор ↔ коммутатор

коммутатор ↔ L3-коммутатор

коммутатор ↔ маршрутизатор (например, “router-on-a-stick”)

По trunk одному физическому соединению “едут” кадры из нескольких VLAN. Чтобы различать VLAN, применяется тегирование 802.1Q.

Идея простая:

внутри Ethernet-кадра появляется VLAN ID (номер VLAN)

на принимающей стороне тег читается, и кадр попадает в нужную VLAN

Native VLAN: куда попадают нетегированные кадры

В 802.1Q есть понятие native VLAN: это VLAN, в которую trunk может положить кадры, пришедшие без тега.

Почему это важно в эксплуатации и безопасности:

если на двух концах trunk разные native VLAN, можно получить странные утечки трафика и “призрачные” проблемы

нетегированный трафик на trunk — почти всегда повод разобраться, кто и зачем его генерирует

> Практическое правило: на trunk-портах обычно ожидают только тегированный трафик “разрешённых VLAN”, а native VLAN либо не используют, либо жёстко контролируют.

Inter-VLAN routing: как VLAN начинают “общаться”

VLAN разделяют L2, но бизнес почти всегда требует связи между сегментами: пользователям нужен доступ к серверам, принтерам, AD, DNS и т.д.

Значит нужен inter-VLAN routing: маршрутизация между VLAN, где каждая VLAN обычно соответствует отдельной IP-подсети.

Типовой дизайн:

VLAN10 (Users): 192.168.10.0/24, шлюз 192.168.10.1

VLAN20 (Servers): 192.168.20.0/24, шлюз 192.168.20.1

Хост из VLAN10, отправляя трафик на 192.168.20.10, понимает “это не моя подсеть” и шлёт пакет на default gateway (192.168.10.1). Дальше L3-узел решает, можно ли и куда маршрутизировать.

Вариант: L3-коммутатор

L3-коммутатор умеет:

L2-коммутацию внутри VLAN

L3-маршрутизацию между VLAN (через интерфейсы VLAN, часто называемые SVI)

Плюсы:

высокая производительность

удобная агрегация маршрутизации “рядом” с VLAN

Вариант: “router-on-a-stick”

Это распространённый вариант, когда один интерфейс маршрутизатора подключён к коммутатору по trunk, а на маршрутизаторе создаются подинтерфейсы (subinterfaces) для каждой VLAN.

Как это выглядит логически:

порт коммутатора в trunk несёт VLAN10 и VLAN20

маршрутизатор принимает кадры с тегами и обрабатывает их разными подинтерфейсами

Важно для понимания трафика:

внутри VLAN кадры коммутируются по MAC

между VLAN кадры превращаются в IP-маршрутизацию через шлюз

ARP всегда локален для VLAN: хост будет ARP-ить MAC шлюза в своей VLAN, а не MAC удалённого сервера из другой VLAN

Где “включаются” ACL и что они реально контролируют

ACL (Access Control List) — это набор правил “разрешить/запретить”, который применяют на сетевом устройстве.

ACL чаще всего работают на уровне L3/L4:

IP-адрес источника и назначения

протокол (TCP/UDP/ICMP)

порт (например, TCP/443)

С точки зрения пентеста ACL — это причина, почему:

ping может не проходить, но HTTPS открывается

порт может выглядеть “filtered” (пакеты молча отбрасываются)

из пользовательского сегмента нельзя напрямую ходить на серверный, хотя маршрутизация есть

Справочно:

Access control list (Wikipedia)

Stateless vs stateful: ACL и “файрвол” не одно и то же

В базовом сетевом дизайне ACL часто stateless: устройство проверяет каждый пакет по правилам без полноценного “учёта состояния” соединения.

Это влияет на практику:

правила для TCP/UDP могут потребовать явно разрешать обратный трафик (в зависимости от платформы и места применения)

ошибки в порядке правил легко ломают доступ

При этом многие современные устройства умеют и stateful-функции, но в “базовой сетевой” модели полезно мыслить так:

ACL — это простая фильтрация по полям пакета

stateful firewall — более сложная логика с состояниями соединений

Порядок правил: почему “первое совпадение” критично

Почти во всех реализациях ACL действует принцип:

правила проверяются сверху вниз

срабатывает первое подходящее

Практический вывод:

более специфичные правила обычно ставят выше

в конце часто существует неявный “запрет всего остального” (это зависит от платформы, но как модель мышления полезно ожидать, что “если явно не разрешили — может быть запрещено”)

Мини-сценарий: сегментация, trunk и ACL в одной истории

Представим офис:

VLAN10 Users: 192.168.10.0/24

VLAN20 Servers: 192.168.20.0/24

L3-коммутатор маршрутизирует между VLAN

Политика доступа:

пользователям нужен только HTTPS к серверу 192.168.20.10:443

к SSH (22) доступ должен быть только из админской подсети (допустим, VLAN30)

Как это выражается на практике:

Пользователь из VLAN10 открывает https://192.168.20.10.

Его хост отправляет пакет на шлюз VLAN10 (192.168.10.1), предварительно узнав MAC шлюза через ARP внутри VLAN10.

L3-устройство получает пакет, видит маршрут в 192.168.20.0/24 и одновременно проверяет ACL.

Если ACL разрешает TCP/443 на 192.168.20.10, пакет уходит в VLAN20.

Если пользователь попробует ssh 192.168.20.10, ACL отработает и заблокирует, даже при наличии маршрута.

В результате для пентестера “ощущения” будут такими:

хост в серверной подсети “пингуется” или нет — зависит от ICMP-политики, а не от факта существования

443 открыт, 22 “фильтруется” или “закрыт” — зависит от того, как именно ACL/устройство реагирует (drop или reject)

Что смотреть в реальной сети: минимальная диагностика

Набор наблюдений, которые связывают предыдущие темы (IP, подсети, ARP) с текущими (VLAN, routing, ACL).

На хосте

свой IP и префикс: ip addr (Linux), ipconfig (Windows)

default gateway: ip route (Linux), route print (Windows)

соседи L2: ip neigh (Linux), arp -a (Windows)

Интерпретация:

если цель в другой подсети, ARP-записи на цель не будет, будет ARP на шлюз

если шлюз не отвечает на ARP, межсегментная связь невозможна “с самого низа”

На сетевом оборудовании (как общий смысл)

Команды зависят от вендора, но логика почти везде одинаковая:

посмотреть VLAN и какие порты в них входят

проверить trunk: какие VLAN разрешены и какая native VLAN

проверить SVI/шлюзы VLAN и маршруты

найти ACL и понять, где она применена (inbound/outbound на каком интерфейсе)

Если вы работаете в лаборатории с Cisco-подобным CLI, типовые команды для ориентировки:

Типичные ошибки и “симптомы” в пентест-практике

Путать отсутствие маршрута и запрет ACL: маршрут может быть, но ACL режет конкретные порты.

Думать, что VLAN = безопасность: VLAN — это сегментация L2, а безопасность обычно делают L3/L4 политиками (ACL/файрвол) и архитектурой.

Игнорировать IPv6: в сегментированной сети IPv4 может быть жёстко отфильтрован, а IPv6 включён “по умолчанию” и контролируется хуже.

Не проверять trunk: если trunk неправильно настроен (allowed VLAN, native VLAN), появляются странные “то работает, то нет” эффекты.

Как эта тема связывается с предыдущими

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

из статьи про подсети и NAT: вы уже умеете определять “локально или через шлюз”

Теперь добавилось ключевое:

VLAN определяет, какой именно “локальный сегмент” у вас есть (границы L2)

routing определяет, какие VLAN могут общаться (L3)

ACL определяет, какой именно трафик разрешён между сегментами (политика)

Дальше по курсу логично углубляться в транспорт и наблюдаемое поведение портов:

TCP/UDP подробнее: почему open/closed/filtered выглядят именно так

как ACL и stateful-фильтрация меняют картину сканирования и диагностики

TCP/UDP и ключевые протоколы: DNS, DHCP, HTTP(S), SSH

После моделей OSI/TCP-IP, адресации, ARP, VLAN и ACL логичный следующий шаг — понять транспорт: как именно данные доходят до конкретного сервиса на порту и почему в пентесте результаты “порт открыт/закрыт/фильтруется” зависят не только от сервера, но и от сетевой политики.

В этой статье разберём:

чем отличаются TCP и UDP и как это проявляется в сети

что такое порты, флаги TCP и почему они важны для диагностики и сканирования

как работают ключевые прикладные протоколы, с которыми пентестер сталкивается постоянно: DNS, DHCP, HTTP(S), SSH

!Сравнение логики TCP (соединение) и UDP (без соединения) и типовых реакций сети

TCP и UDP: что это и почему пентестеру важно различать

Транспортный уровень отвечает за доставку данных между процессами на хостах. Именно здесь появляются порты: например, 443 у HTTPS или 22 у SSH.

TCP простыми словами

TCP — протокол с установлением соединения и контролем доставки.

Ключевые свойства TCP:

соединение устанавливается перед передачей данных

данные доставляются надёжно (подтверждения, повторные передачи)

порядок данных сохраняется

есть управление перегрузкой (важно для поведения в реальной сети)

Практический вывод для пентеста:

TCP обычно даёт более “чёткие” ответы при проверке порта

по реакции на TCP-пакеты часто можно отличить закрыто от фильтруется

Нормативная спецификация TCP: RFC 9293.

UDP простыми словами

UDP — протокол без установления соединения.

Ключевые свойства UDP:

нет рукопожатия, отправитель просто шлёт датаграмму

нет встроенных подтверждений и повторных передач

“тишина” в ответ может быть нормой

Практический вывод для пентеста:

UDP-порты сложнее интерпретировать: отсутствие ответа не означает, что порт закрыт

многое зависит от того, отправляет ли цель ICMP-ошибки и не режет ли их ACL

Спецификация UDP: RFC 768.

Порты: как сеть находит нужный сервис

IP-адрес доставляет пакет на хост, а порт доставляет данные в конкретный процесс.

TCP-порт и UDP-порт — разные “пространства” портов

один и тот же номер порта может существовать одновременно для TCP и UDP (например, DNS часто использует и UDP/53, и TCP/53)

Короткая шпаргалка портов, которые встречаются постоянно

| Протокол | Транспорт | Порт | Что это обычно значит в сети | |---|---|---:|---| | DNS | UDP/TCP | 53 | резолвинг имён, иногда зонные операции | | DHCP (server/client) | UDP | 67/68 | выдача адресов и сетевых параметров в LAN | | HTTP | TCP | 80 | веб без TLS | | HTTPS | TCP | 443 | веб поверх TLS | | SSH | TCP | 22 | удалённый доступ и администрирование |

TCP глубже: рукопожатие, флаги и типовые “симптомы”

TCP three-way handshake

Перед передачей данных TCP устанавливает соединение:

клиент отправляет SYN

сервер отвечает SYN-ACK

клиент подтверждает ACK

Если вы проверяете TCP-порт, вы по сути проверяете, способен ли удалённый хост корректно отработать эту последовательность.

Главные TCP-флаги, которые полезно узнавать

SYN — запрос на установление соединения

ACK — подтверждение получения

RST — “сброс”, часто признак закрытого порта или запрещённого соединения

FIN — корректное завершение соединения

Как выглядит “open/closed/filtered” на практике

Важно: конкретные формулировки зависят от инструмента, но логика обычно такая:

Открыто (open): вы получаете SYN-ACK на ваш SYN (или устанавливаете TCP-соединение полностью)

Закрыто (closed): вы получаете RST (хост доступен, но сервис не слушает)

Фильтруется (filtered): нет ответа или приходят сообщения о недоступности, потому что пакет где-то по пути отбрасывается ACL/файрволом

Связь с предыдущими статьями:

ACL на L3/L4 часто делает порт “filtered” просто потому, что отбрасывает трафик

VLAN определяет, вообще есть ли L2/L3 путь до цели

NAT может менять видимую схему соединений и логи на сервере

Минимальные команды для проверки TCP-состояния на хосте

UDP глубже: почему “молчание” — это нормально

UDP не обязан отвечать. Типовой сценарий:

вы отправили UDP-датаграмму на порт

если там есть сервис, он может ответить (но не обязан немедленно)

если порта нет, хост часто отвечает ICMP-ошибкой “Port Unreachable”

если ICMP режется ACL, вы можете не увидеть вообще ничего

Практическое следствие:

UDP-диагностика часто строится вокруг ожидаемого ответа протокола (например, DNS-ответа), а не вокруг “рукопожатия”, как в TCP

DNS: как имена превращаются в IP и где здесь поверхность атаки

DNS (Domain Name System) сопоставляет имена хостов с IP-адресами и другой служебной информацией.

База DNS: RFC 1034 и RFC 1035.

Кто участвует в DNS-цепочке

клиент (stub resolver) на вашем хосте

рекурсивный резолвер (например, DNS провайдера или корпоративный)

авторитативные серверы зоны (они “источник правды” для домена)

!Путь DNS-запроса от клиента до авторитативного сервера и обратно

UDP и TCP в DNS

DNS чаще всего работает по UDP/53, но TCP/53 тоже важен:

TCP используется, когда ответ большой или нужна надёжная передача

TCP используется для некоторых операций управления зоной (например, в классических сценариях зонных передач)

Практический вывод:

если в сети фильтруют TCP/53, это может ломать “нестандартные”, но легитимные DNS-сценарии

Самые полезные типы DNS-записей

A — имя → IPv4

AAAA — имя → IPv6

CNAME — псевдоним (алиас)

MX — почтовые серверы домена

TXT — произвольный текст (часто SPF/DKIM/DMARC и верификации)

NS — серверы зоны

Практика наблюдения DNS

Что важно для пентеста:

DNS часто раскрывает структуру инфраструктуры (поддомены, внешние сервисы, почтовые шлюзы)

ошибки конфигурации DNS могут приводить к утечкам информации

кеширование и TTL влияют на то, как быстро изменения “доедут” до клиентов

DHCP: как хост получает адрес, шлюз и DNS в локальной сети

DHCP (Dynamic Host Configuration Protocol) выдаёт хосту сетевые настройки автоматически.

База DHCP: RFC 2131.

Почему DHCP почти всегда UDP и широковещание

Когда новый хост появляется в сети, он часто не знает:

свой IP

IP DHCP-сервера

Поэтому он использует широковещание в локальном сегменте (а это сразу связывает DHCP с темами VLAN и L2-границ).

DHCP работает обычно так:

клиент отправляет DHCPDISCOVER (broadcast)

сервер отвечает DHCPOFFER

клиент запрашивает конкретное предложение DHCPREQUEST

сервер подтверждает DHCPACK

Порты:

сервер слушает UDP/67

клиент использует UDP/68

DHCP и VLAN: где чаще всего “ломается магия”

DHCP-запросы — широковещательные, а широковещание не проходит между VLAN.

Чтобы хосты в отдельной VLAN получали адреса, обычно используют:

DHCP-сервер в каждой VLAN, или

DHCP relay (ретранслятор) на L3-устройстве

Практический вывод для пентеста и диагностики:

если у вас “нет сети” и вы видите 169.254.x.x, проблема может быть в DHCP, а не в маршрутизации

если вы подключились в “не тот” access-порт или VLAN, вы можете получать “не тот” адрес, DNS и шлюз

Как посмотреть DHCP-настройки на хосте

HTTP и HTTPS: что реально видно в сети и что важно для пентеста

HTTP как протокол запрос-ответ

HTTP работает поверх TCP и выглядит как:

клиент отправляет запрос (метод, путь, заголовки)

сервер отвечает (статус-код, заголовки, тело)

Спецификация HTTP: RFC 9110 и HTTP/1.1: RFC 9112.

Мини-словарь:

методы: GET, POST, PUT, DELETE, OPTIONS

частые заголовки: Host, User-Agent, Cookie, Authorization

статус-коды: 200, 301/302, 401, 403, 404, 500

HTTPS = HTTP поверх TLS

HTTPS — это HTTP внутри защищённого канала TLS.

TLS 1.3: RFC 8446.

Важно различать:

что видно на сетевом уровне

что защищено шифрованием

Обычно в пути видно:

IP-адреса и TCP-порты

факт установки TLS

сертификат сервера (передаётся при рукопожатии)

имя сервера в SNI (часто видно, если не используется ECH)

Обычно не видно (без доступа к конечной точке или TLS-терминации):

URL-пути

HTTP-заголовков (включая cookies)

тела запросов и ответов

Прокси и балансировщики: почему IP клиента в логах может быть “не настоящий”

В реальных инфраструктурах перед вебом часто стоят reverse proxy или балансировщики.

Тогда:

TCP-соединение до приложения может приходить с IP прокси

реальный клиентский IP передают в заголовках вроде X-Forwarded-For (зависит от архитектуры)

Это перекликается с NAT и маршрутизацией: один “видимый” IP не всегда соответствует одному пользователю.

Минимальная практика проверки HTTP(S)

SSH: безопасный удалённый доступ и что в нём важно замечать

SSH обычно работает по TCP/22 и используется для:

администрирования серверов

безопасной передачи файлов (SCP/SFTP)

туннелирования трафика

База SSH transport: RFC 4253.

Две разные “проверки подлинности” в SSH

В SSH важно не путать два независимых механизма:

аутентификация сервера через host key (клиент проверяет, что подключился к тому же серверу, что и раньше)

аутентификация пользователя паролем или ключом (сервер проверяет, кто вы)

Практический смысл:

предупреждения про “host key changed” — это не “ошибка пароля”, это сигнал, что изменился ключ сервера (легитимно или подозрительно)

Что можно увидеть “снаружи”

Даже без доступа внутрь:

баннер/версию SSH-сервера часто видно при подключении

по сетевому поведению можно понять, что порт “живой” (TCP открыт)

Минимальная практика диагностики SSH

Быстрый практический сценарий: как разбирать “не работает доступ к сервису”

Чтобы связать всё с предыдущими темами (подсети, VLAN, routing, ACL), полезно мыслить сверху вниз и снизу вверх одновременно:

Уточните адресацию и маршрут: ip addr, ip route.

Проверьте DNS, если обращаетесь по имени: dig или nslookup.

Разделите проблему на TCP и UDP.

Для TCP попробуйте “дотянуться” до порта и смотрите реакцию (есть ли RST, есть ли рукопожатие, есть ли таймаут).

Для UDP ожидайте, что ответа может не быть, и проверяйте “смысловой” ответ протокола (например, DNS-ответ).

Если это межсегментный доступ, помните, что ACL может резать часть протоколов (например, ICMP запрещён, а TCP/443 разрешён).

Итоги

TCP надёжен и даёт диагностически понятные реакции (SYN-ACK, RST), UDP часто “молчит”, и это нормально.

DNS почти всегда первым ломает “доступ по имени”, DHCP определяет, получите ли вы вообще корректные адрес/шлюз/DNS.

HTTP(S) — главный прикладной протокол интернета, а TLS меняет то, что видно в сети.

SSH — базовый админский доступ, где важно отличать аутентификацию сервера (host key) от аутентификации пользователя.

На этой базе дальше проще разбирать поведение сканеров, отличия open/closed/filtered, и то, как ACL и сегментация меняют картину доступности.

Диагностика и анализ трафика: ping, traceroute, ss, tcpdump, Wireshark

В прошлых темах мы разобрали уровни OSI/TCP-IP, адресацию, ARP, VLAN, ACL и различия TCP/UDP. Теперь соберём это в практический навык: быстро понять, где именно ломается связь и увидеть это в трафике.

В пентесте диагностика нужна постоянно:

вы не можете сканировать то, до чего нет маршрута или что режется ACL

вы должны отличать порт закрыт от пакеты не доходят

вы должны уметь обосновать выводы артефактами: вывод команд, pcap, конкретные флаги TCP/ICMP

Инструменты статьи:

ping и traceroute/tracert для проверки L3-достижимости и пути

ss для проверки, что реально слушает/куда подключается хост

tcpdump для точечного захвата пакетов

Wireshark для визуального анализа и фильтрации

!Карта: какой инструмент проверяет какой уровень и где чаще всего ломается доступ

Базовый подход к диагностике

Главная идея: проверяем снизу вверх, но фиксируем результат в терминах модели.

Канальный/доступ к сети: есть ли линк и корректная адресация (это вы обычно проверяете ip addr, ip route, ipconfig, но в этой статье фокус на трафике)

Сетевой уровень: IP-достижимость и путь (ping, traceroute)

Транспорт: что происходит с TCP/UDP (флаги, таймауты) и что слушает хост (ss, tcpdump, Wireshark)

Прикладной: уже потом проверяем DNS/HTTP/SSH и их ошибки (см. предыдущую статью)

Практическое правило для пентестера: если вы не видите пакеты — вы не знаете, что происходит. Логи и сообщения приложений полезны, но трафик даёт “физическое” подтверждение.

ping: проверка IP-достижимости (и почему она часто обманывает)

ping отправляет ICMP Echo Request и ждёт ICMP Echo Reply. Это проверка IP-достижимости и базовой задержки.

Спецификация ICMP: RFC 792.

Типовые выводы ping и что они означают

Есть ответы, небольшая задержка: L3-достижимость есть, но это не гарантирует, что нужные TCP/UDP порты доступны

Таймауты (Request timeout): пакет мог не дойти, ответ мог не вернуться, или ICMP режется

Сообщение “Destination Host Unreachable” (или аналог): часто означает, что промежуточное устройство или локальный стек знает, что маршрута нет, или ARP/next-hop недоступен

Важно для пентеста:

многие сети блокируют ICMP, поэтому “не пингуется” не равно “хоста нет”

иногда ICMP разрешён, а TCP к нужному порту запрещён ACL

Минимальные практические примеры

Что фиксировать в отчёте/заметках:

факт наличия или отсутствия ответа

среднюю задержку

потери пакетов

traceroute/tracert: понять путь и место, где “обрывается”

traceroute показывает, через какие L3-узлы проходит трафик.

Как это работает концептуально:

У пакета есть TTL (в IPv4) или Hop Limit (в IPv6).

Каждый маршрутизатор уменьшает TTL на 1.

Когда TTL становится 0, маршрутизатор отправляет ICMP Time Exceeded.

traceroute увеличивает TTL шаг за шагом и собирает ответы.

Почему traceroute бывает “пустым”

ICMP Time Exceeded может фильтроваться

маршрутизаторы могут не отвечать на такие сообщения

путь может быть асимметричным (туда и обратно разные маршруты), и “картина” будет неточной

Практические примеры

Как интерпретировать:

трасса обрывается сразу на первом хопе: подозрение на проблемы локального сегмента, шлюза, VLAN, ACL

трасса проходит несколько хопов и затем “звёздочки”: вероятно, ICMP режется дальше по пути, но это не доказывает отсутствие маршрута

трасса доходит до сети назначения, но сервис недоступен: проблема вероятнее на L4/L7 (порт, файрвол, сервис)

!Как traceroute «вычисляет» каждый хоп через TTL и ICMP Time Exceeded

ss: что происходит с сокетами на вашем хосте

ss показывает состояние сокетов (что слушает, куда есть соединения, какие процессы держат порты). Это диагностика на границе хоста и транспорта.

Почему это важно в пентесте:

вы отличаете “сервис реально слушает” от “порт кажется открытым из-за прокси/перенаправления”

вы видите зависшие соединения (например, множество SYN-SENT при фильтрации)

Базовые команды ss (Linux)

Как читать состояния (самые частые):

LISTEN: процесс слушает порт

ESTAB (ESTABLISHED): соединение установлено

SYN-SENT: вы отправили SYN, но не получили SYN-ACK (часто фильтрация или маршрут)

TIME-WAIT: нормальное состояние после закрытия TCP; большое количество может быть симптомом высокой нагрузки или агрессивных проверок

Windows-эквивалент обычно делают через netstat -ano, но в этой статье основной акцент на ss как типовой инструмент в Linux-окружении пентестера.

tcpdump: точечно увидеть пакеты и доказать гипотезу

tcpdump захватывает пакеты и позволяет фильтровать их до записи в файл. Это “скальпель”: быстро проверить, идут ли SYN, приходят ли ответы, есть ли ARP/DNS/ICMP.

Официальный сайт и документация: tcpdump.

Важные практические принципы

сначала выберите интерфейс (часто ошибка новичка: слушают не тот интерфейс)

сначала сузьте фильтр (иначе утонете в трафике)

сохраняйте в pcap и анализируйте в Wireshark, если нужно глубже

Быстрый старт: выбрать интерфейс и начать захват

Часто используемые фильтры (BPF)

Запись в файл для Wireshark

Как по tcpdump отличить “closed” от “filtered” (идея)

На TCP-проверке порта логика обычно такая:

SYN ушёл, пришёл RST: порт закрыт (хост жив, сервис не слушает)

SYN ушёл, пришёл SYN-ACK: порт открыт (дальше зависит от приложения)

SYN ушёл, ответа нет: возможно фильтрация (drop), проблема маршрута, или ответ не возвращается обратно

Ключ: tcpdump на вашей стороне показывает, ушёл ли SYN и пришло ли что-то обратно. Это связывает транспорт с темами ACL/маршрутизации из предыдущих статей.

Wireshark: анализ pcap и чтение протоколов “по слоям”

Wireshark удобен, когда нужно:

быстро фильтровать и “собрать картину” по протоколам

разбирать TCP-рукопожатие и последовательность пакетов

находить DNS-запросы, ICMP, TLS-рукопожатия

показывать артефакты в отчёте (скриншоты, экспорт объектов, статистика)

Официальная документация:

Wireshark User's Guide

Wireshark Display Filters

Wireshark Capture Filters

Разница между capture filter и display filter

Capture filter применяется до захвата: в файл попадёт только выбранное (экономит место и шум)

Display filter применяется после захвата: файл содержит всё, но вы отображаете только нужное

Практический совет: если вы не уверены, что именно понадобится, лучше захватить чуть шире (но в рамках разумного) и отфильтровать display filter.

Самые полезные display filters для базовой диагностики

| Задача | Display filter в Wireshark | |---|---| | Показать трафик конкретного хоста | ip.addr == 192.168.10.10 | | Только DNS | dns | | Только ICMP | icmp | | Только TCP 443 | tcp.port == 443 | | Найти RST (часто “closed”) | tcp.flags.reset == 1 | | Найти SYN без ACK (попытки соединения) | tcp.flags.syn == 1 && tcp.flags.ack == 0 | | TLS рукопожатие (видно даже при HTTPS) | tls.handshake |

Что именно смотреть в типовых протоколах

ICMP (ping): есть ли Echo Reply, или приходят ли ICMP ошибки

Traceroute: ICMP Time Exceeded от промежуточных узлов

TCP: рукопожатие SYN → SYN-ACK → ACK, затем данные; RST как сигнал отказа

DNS: запрос/ответ, время, какой сервер отвечает

TLS: ClientHello/ServerHello, SNI часто виден, сертификат сервера виден

Wireshark-приём, который экономит время:

Follow TCP Stream помогает увидеть поток данных в одном месте (полезно для незашифрованных протоколов; для HTTPS полезно хотя бы увидеть структуру соединения и метаданные TLS)

Практические сценарии: как связать инструменты в одну цепочку

Сценарий: “хост не доступен”

ping до IP.

Если нет ответа, запускаете tcpdump на своей стороне и смотрите, выходят ли ICMP Echo Request и возвращается ли что-то.

Делаете traceroute, чтобы понять, где путь “пропадает”.

Интерпретация:

ICMP уходит, ответов нет, traceroute обрывается рано: вероятны ACL/файрвол, проблема маршрута, неправильный шлюз/VLAN

traceroute показывает путь до сети назначения, но ping не отвечает: ICMP может быть запрещён на цели (это нормально для многих серверов)

Сценарий: “TCP-порт не открывается”

Проверяете на клиенте ss -tan: есть ли SYN-SENT на цель.

Снимаете tcpdump по фильтру host <цель> and tcp port <порт>.

В Wireshark смотрите, что возвращается: SYN-ACK, RST или тишина.

Интерпретация:

RST обратно: порт закрыт (или активный reject)

тишина: фильтрация (drop), проблема обратного маршрута, stateful-фильтрация, асимметрия

Сценарий: “по имени не работает, по IP работает”

Захватываете DNS трафик tcpdump -i <iface> port 53 -w dns.pcap.

В Wireshark фильтр dns и смотрите: запрос уходит? ответ возвращается? какой код ответа?

Интерпретация:

запрос уходит, ответ не возвращается: фильтрация/не тот DNS/маршрут

ответ есть, но NXDOMAIN: проблема в записи DNS

Типичные ошибки новичков при анализе трафика

Слушают не тот интерфейс в tcpdump (например, VPN-интерфейс вместо физического)

Путают не пингуется с не существует

Делают вывод “порт закрыт”, не увидев RST или другого подтверждения

Захватывают “всё подряд” без фильтров и теряют сигнал в шуме

Не фиксируют время: иногда проблема не в сети, а во временных задержках и повторных передачах

Итоги

ping и traceroute отвечают на вопросы есть ли L3-достижимость и где проходит путь, но их может искажать фильтрация ICMP.

ss показывает, что происходит на самом хосте: какие порты слушают и какие соединения “застряли”.

tcpdump позволяет быстро доказать: пакет ушёл и что пришло обратно.

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

Это завершает “базовый набор” по сетям для пентеста: теперь у вас есть и модель мышления (OSI/TCP-IP), и практические инструменты, чтобы подтверждать гипотезы на уровне пакетов.

Сетевая разведка и сканирование: Nmap, service discovery и баннер-граббинг

Сетевая разведка отвечает на практический вопрос пентестера: что реально доступно по сети прямо сейчас. После понимания уровней OSI/TCP-IP, адресации, VLAN/ACL, TCP/UDP и базовой диагностики (ping, traceroute, tcpdump) вы готовы к следующему шагу: системно находить хосты, порты и сервисы, а затем подтверждать выводы артефактами.

В этой статье разберём:

как мыслить в терминах host discovery → port scanning → service discovery → подтверждение баннером

как Nmap соотносится с тем, что вы уже знаете про TCP/UDP/ICMP и ACL

как аккуратно делать баннер-граббинг и почему баннеру нельзя верить без проверки

> Используйте техники из статьи только в рамках явного разрешения (ваша лаборатория, CTF, письменное согласие заказчика). Неконтролируемое сканирование может нарушать правила эксплуатации, договоры и закон.

!Конвейер сетевой разведки: что делаем по шагам и чем

Модель мышления: что именно мы ищем

Чтобы не путать понятия, держите в голове четыре уровня результата:

Хост найден: есть признаки, что IP-адрес “живой” или хотя бы маршрутизируется.

Порт доступен: по TCP/UDP видно, что порт открыт, закрыт или фильтруется.

Сервис идентифицирован: мы понимаем, что за протокол на порту и часто версию.

Подтверждено вручную: баннер, handshake или тестовый запрос подтверждают вывод.

Связь с предыдущими статьями:

если ACL режет ICMP, host discovery “по ping” будет ложно отрицательным

если ACL режет SYN или ответы, порты будут выглядеть как filtered

если вы в другой VLAN без inter-VLAN routing, вы не “увидите” часть сети вообще

различия TCP и UDP определяют, насколько “чётким” будет результат сканирования

Nmap: что это и почему он стандарт де-факто

Nmap решает две задачи одновременно:

активно отправляет сетевые пробы и классифицирует ответы

пытается определить, какой сервис стоит за портом (service discovery)

Официальные источники для опоры на синтаксис и поведение:

Nmap Reference Guide

Nmap Scripting Engine (NSE) Documentation

Host discovery: как понять, что цель “живая”

Почему “не пингуется” не значит “не существует”

Вы уже видели это на диагностике:

ICMP может быть запрещён на цели или по пути

ответы могут быть асимметричны (туда дошло, обратно нет)

NAT и фильтры могут менять наблюдаемую картину

Поэтому Nmap обычно делает discovery несколькими способами (что именно получится, зависит от прав, ОС и сети).

Практические варианты discovery в Nmap

Базовый (часто достаточно в лаборатории):

Что это делает в общем смысле:

пытается определить “живые” хосты, не сканируя порты глубоко

методы будут отличаться по среде (LAN, VPN, интернет)

Если вы уверены, что ICMP блокируют, и вам нужно всё равно сканировать, часто используют отключение discovery (Nmap будет считать хост “up” и перейдёт к портам):

В терминах прошлых тем это означает: мы не пытаемся доказать L3-достижимость ICMP-ом, а проверяем L4 по поведению TCP/UDP.

Сканирование TCP-портов: как Nmap отличает open/closed/filtered

Ключевая логика (повторяем транспорт)

Вы уже знаете базовые маркеры:

TCP SYN → SYN-ACK обычно означает порт открыт

TCP SYN → RST обычно означает порт закрыт

TCP SYN → тишина часто означает filtered (drop на ACL/файрволе) или проблемы маршрута

Nmap автоматизирует эту классификацию.

Типовой старт: быстро проверить “самое частое”

По умолчанию Nmap обычно сканирует ограниченный набор популярных TCP-портов. Это полезно для первичного обзора, но для пентеста чаще нужно явно управлять диапазоном.

Частые варианты:

Что значит filtered и почему это важно

Filtered почти всегда означает не “на хосте сервиса нет”, а “вам не дают до него достучаться”.

Связь с VLAN/ACL:

маршрут может существовать, но ACL блокирует конкретные порты

ICMP может быть запрещён, но TCP/443 разрешён (поэтому “пинг не идёт, сайт открывается”)

Если результат сомнительный, подтверждайте через tcpdump/Wireshark:

UDP-сканирование: почему это всегда “неуверенно”

UDP сложнее по причинам из транспортной статьи:

нет рукопожатия

отсутствие ответа — нормальная ситуация

ICMP ошибки могут быть отфильтрованы

В Nmap UDP обычно сканируют осознанно и точечно:

Практический подход:

выбирайте порты, где вы сможете распознать “смысловой” ответ (например, DNS)

не делайте вывод “закрыто”, пока не увидели явный признак (например, ICMP Port Unreachable) и понимаете, что ICMP не режется

Service discovery: определить, что за сервис на порту

Открытый порт ещё не означает, что там “ожидаемый” протокол. Например:

443/tcp может быть не HTTPS, а какой-то кастомный TLS-сервис

80/tcp может отдавать не веб, а простую заглушку или админку прокси

22/tcp может быть не OpenSSH, а другой SSH-демон или даже эмуляция

Определение версий в Nmap

Что важно понимать:

Nmap отправляет набор проб и сравнивает ответы с базой сигнатур

точность зависит от того, как сервис отвечает и не прячется ли за прокси/балансировщиком

баннер и “версия” могут быть подменены или обрезаны

Практический совет: версию из Nmap используйте как гипотезу, затем подтверждайте вручную.

NSE-скрипты: быстрые проверки поверх service discovery

Nmap Scripting Engine позволяет запускать сценарии, которые делают прикладные проверки (аккуратно и обычно быстрее, чем писать своё).

Базовые примеры:

Принципиально важно:

не все скрипты “безопасны”: некоторые могут быть агрессивными или менять состояние

в реальном проекте нужно согласование на активные проверки

Ориентируйтесь на документацию NSE:

Nmap Scripting Engine (NSE) Documentation

Баннер-граббинг: что это и зачем, если есть -sV

Баннер-граббинг — это ручное получение “первого ответа” сервиса или метаданных протокола, чтобы подтвердить, что за сервис на порту и как он реально выглядит.

Почему это нужно даже при -sV:

баннер может содержать важные детали конфигурации (например, конкретную сборку)

баннер может отсутствовать, но протокол всё равно определяется рукопожатием

Nmap мог ошибиться из-за прокси, WAF, нестандартного поведения

Баннер-граббинг для HTTP

Если HTTPS:

Что вы подтверждаете:

это действительно HTTP(S)

какие заголовки отдаёт сервер (часто видно тип сервера, прокси, редиректы)

какой статус и куда ведёт редирект

Баннер-граббинг для TLS (включая HTTPS, но без HTTP)

Что полезно увидеть:

сертификат (CN/SAN, срок, цепочка)

поддерживаемые версии/параметры TLS (частично)

факт, что это TLS-сервис, даже если дальше не HTTP

Справка по инструменту:

OpenSSL s_client

Баннер-граббинг для “простых” TCP-сервисов

Часто используют nc (netcat), чтобы подключиться и посмотреть, что выдаёт сервис:

Типичный SSH сразу вернёт строку вида SSH-2.0-....

Для SMTP/FTP и других “баннерных” протоколов это тоже работает, но помните: некоторые сервисы баннер не шлют, пока вы не отправите корректную команду.

Почему баннеру нельзя верить

Баннер может быть:

намеренно скрыт или изменён администратором

заменён прокси/балансировщиком

подделан (honeypot, обманка)

Поэтому правильная связка такая:

Nmap нашёл порт и предположил сервис.

Вы вручную подтвердили протокол через “естественный” клиент (curl/openssl/ssh).

Если нужно, вы сняли трафик tcpdump и показали рукопожатие или ключевые поля.

Как снизить шум и не “сломать сеть” при сканировании

Сканирование создаёт нагрузку. В корпоративной сети это может:

задеть IPS/IDS и вызвать реакцию

создать заметный поток соединений (особенно при -p- по большим подсетям)

привести к временным блокировкам

Практические меры аккуратности:

Начинайте с малого объёма: один хост, топ портов, затем расширяйтесь.

Явно ограничивайте цели и порты.

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

У Nmap есть параметры тайминга, но смысл важнее синтаксиса:

чем агрессивнее тайминги, тем выше риск ложных результатов и проблем в сети

чем осторожнее тайминги, тем дольше, но надёжнее и “тише”

Синтаксис и режимы описаны в руководстве:

Nmap Reference Guide

Артефакты для отчёта: как сохранять результаты

Сканирование полезно только тогда, когда результаты можно повторить и показать.

Практика:

сохраняйте вывод Nmap в файл (как минимум обычный текст)

при спорных местах сохраняйте pcap (tcpdump) и делайте скриншот Wireshark с фильтром

Пример сохранения в несколько форматов:

Это удобно тем, что вы получаете набор файлов для чтения человеком и для парсинга.

Мини-сценарий: от “ничего не видно” до подтверждённого сервиса

Ситуация: вы в VLAN пользователей и пытаетесь понять, доступен ли сервер из VLAN серверов.

Действуйте последовательно:

Пробуете ping, но ответа нет.

Делаете traceroute -T -p 443 к серверу и видите, что путь хотя бы частично существует.

Делаете nmap -Pn -p 443 <ip> и видите open.

Делаете nmap -sV -p 443 <ip> и получаете гипотезу “https”.

Подтверждаете curl -vk https://<ip>/ и видите сертификат и HTTP-ответ.

Ключ: отсутствие ICMP не помешало доказать доступность прикладного сервиса.

Итоги

Nmap систематизирует активную разведку: хосты → порты → сервисы → гипотезы о версиях.

Результаты всегда нужно интерпретировать через базу из прошлых тем: TCP/UDP, ICMP, VLAN, routing и ACL.

Service discovery даёт гипотезу, а баннер-граббинг и ручные клиенты дают подтверждение.

Для уверенных выводов сохраняйте артефакты: вывод команд и при необходимости pcap.

Типовые атаки и защита: MITM, ARP spoofing, DNS spoofing, DoS и hardening

Понимание сетевых атак в пентесте нужно не для магии, а чтобы быстро отвечать на практические вопросы:

почему “всё работает, но странно” (MITM, подмена маршрута, подмена DNS)

почему “то открывается, то нет” (инъекции/дроп трафика на L2/L3)

почему сервис “упал”, хотя железо живое (DoS)

какие настройки реально снижают риски (hardening)

Эта статья связывает предыдущие темы курса:

из OSI/TCP-IP и движения пакета вы уже знаете, где живут MAC, IP и порты

из адресации и ARP — почему в одном L2-сегменте ARP решает доставку

из VLAN/ACL — как сегментация и фильтрация ограничивают радиус атак

из TCP/UDP — почему DoS часто “бьёт” по состояниям TCP или по полосе

из диагностики и анализа трафика — как подтверждать выводы tcpdump/Wireshark

> Все примеры ниже рассматривайте как основу для защиты и для проверки в собственной лаборатории или при наличии явного разрешения.

!Общая карта: где в сети возникают MITM, ARP spoofing и DNS spoofing

Термины: что именно мы называем атакой

| Термин | Простое определение | Где чаще происходит | Основная цель атакующего | |---|---|---|---| | MITM (Man-in-the-Middle) | атакующий оказывается “между” двумя сторонами и может читать/менять трафик | L2 (локальная сеть), L3 (маршрутизация), L7 (прокси) | перехват данных, подмена ответов | | Spoofing | подмена идентичности (адресов/ответов), чтобы трафик пошёл “не туда” | L2 (ARP), L7 (DNS) | перенаправить, перехватить или сломать доступ | | DoS (Denial of Service) | отказ в обслуживании из-за перегрузки канала/устройства/сервиса | L3/L4/L7 | сделать сервис недоступным | | Hardening | усиление конфигурации, чтобы атаки были сложнее или менее эффективны | везде | снизить вероятность и ущерб |

MITM: как атакующий вообще может оказаться “между”

MITM — это не одна техника, а позиция в пути трафика. Варианты зависят от уровня.

MITM на L2: локальный сегмент и “игра” с доставкой

В локальной сети доставка Ethernet-кадров идёт по MAC-адресам, а соответствие IP→MAC обеспечивает ARP (в IPv4). Если атакующий заставит жертву считать, что “шлюз” имеет MAC атакующего, трафик можно перенаправить.

Основа ARP описана в RFC 826.

Признаки, что MITM возможен:

атакующий и жертва в одном L2-сегменте (обычно одна VLAN)

есть L2-доступ к трафику жертвы (через подмену ARP или неправильную конфигурацию сети)

MITM на L3: маршрут или шлюз “не тот”

На уровне IP MITM чаще появляется из-за:

неверных статических маршрутов

компрометации маршрутизатора/шлюза

вредоносной VPN/прокси-конфигурации на хосте

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

MITM на L7: прокси как точка контроля

Даже без контроля L2/L3 MITM возможен, если:

трафик идёт через корпоративный прокси

TLS “терминируется” на периметре (например, TLS inspection)

у клиента установлены доверенные корневые сертификаты организации

Здесь ключевая мысль: TLS защищает от наблюдателя в сети, но не защищает от доверенного посредника, которому клиент сам доверяет сертификатом.

Полезная база по корректной настройке TLS: OWASP Transport Layer Protection Cheat Sheet.

ARP spoofing: подмена IP→MAC в локальной сети

Почему ARP spoofing работает

ARP в классическом виде не содержит встроенной криптографической проверки “правды”. Устройство принимает ARP-ответ и обновляет ARP-кеш, даже если оно не запрашивало этот ответ (поведение зависит от ОС и настроек, но общий риск исторически известен).

Как это выглядит на проводе

Типовая “аномалия”, которую можно увидеть в трафике:

внезапные ARP Reply, которые меняют соответствие IP шлюза на другой MAC

частые ARP-обновления без причины

одинаковый IP встречается с разными MAC

Практические артефакты на хосте:

в ip neigh (Linux) или arp -a (Windows) MAC-адрес для default gateway неожиданно меняется

появляются “дубли IP” (конфликты), нестабильность соединений

Команды наблюдения (для диагностики и фиксации фактов):

Для анализа в трафике:

Защита от ARP spoofing

Меры защиты делятся на архитектуру и контроль на L2/L3.

Архитектура:

сегментация VLAN, чтобы уменьшить радиус атаки

минимизация “плоских” сетей, где сотни устройств в одном L2-домене

Контроль на коммутаторах (концептуально):

привязка доверенных соответствий (статические ARP там, где оправдано)

механизмы проверки ARP против “источника правды” DHCP (в корпоративных сетях это делается функциями сетевого оборудования)

Контроль на хостах:

локальный файрвол и политики, ограничивающие неожиданные входящие соединения

мониторинг изменений ARP для шлюза (важно для критичных сегментов)

Ограничение ущерба:

повсеместное использование TLS с корректной проверкой сертификатов

отказ от “игнорирования” предупреждений TLS/SSH

DNS spoofing: подмена ответа на DNS-запрос

DNS преобразует имя в IP. Если атакующий может подменить ответ (или подменить DNS-сервер в настройках клиента), жертва пойдёт на неправильный IP.

База DNS: RFC 1034 и RFC 1035.

Два типовых сценария DNS spoofing

Подмена ответа “в пути”

Подмена того, кого клиент спрашивает (через DHCP, ручные настройки, вредоносный профиль VPN/MDM)

Связь с прошлой статьёй про DHCP:

если атакующий влияет на DHCP-параметры, он может раздать клиентам “свой” DNS

в VLAN без правильного DHCP relay клиенты могут получать неожиданную конфигурацию

Как это проявляется в диагностике

Симптомы:

по имени открывается “не тот” сайт/сертификат

dig показывает неожиданный IP-адрес

ответы DNS приходят от неожиданного сервера

Проверка вживую (наблюдение):

Защита от DNS spoofing

Технические меры:

DNSSEC в зоне и валидация DNSSEC на резолвере (где применимо)

защищённые каналы к резолверу (DoT/DoH) как способ снизить подмену “в пути”

жёсткий контроль DHCP, кто имеет право выдавать адреса и параметры

ограничение исходящих DNS-запросов: разрешать только корпоративные резолверы

Архитектурные меры:

разделение резолверов по сегментам и логирование DNS

мониторинг “внезапных” изменений DNS-серверов на рабочих станциях

Важное ограничение:

DoH/DoT защищают канал до резолвера, но не гарантируют, что сам резолвер “добрый” или что политика резолвинга корректна

DoS: отказ в обслуживании на L3/L4/L7

DoS проще понимать как перегрузку одного из ресурсов:

полоса пропускания (канал)

состояние и таблицы (например, много незавершённых TCP-соединений)

CPU/память сервиса (например, тяжёлые запросы)

Общее обсуждение угроз DoS и практик снижения риска есть в RFC 4732.

!Типы DoS по уровням и по ресурсу

DoS на L3: “залить канал”

Признаки:

растёт задержка и потери пакетов до множества разных целей

traceroute деградирует не на одном хопе, а “в целом”

мониторинг интерфейсов показывает близость к 100% утилизации

Защита:

фильтрация и rate limiting на границе

анти-DDoS сервисы, scrubbing, CDN (для публичных сервисов)

исходная фильтрация подменённых адресов у провайдеров

Практика исходной фильтрации описана как BCP в RFC 2827.

DoS на L4: перегрузка состояниями TCP/UDP

Класс проблем на TCP часто связан с тем, что устройства и сервисы хранят состояние соединений:

много входящих попыток соединений

растут очереди, таблицы conntrack, лимиты на сокеты

Симптомы на хосте:

резкий рост SYN-RECV (на сервере) или массовые SYN-SENT (на клиенте)

увеличивается число “зависших” попыток подключения

Наблюдение:

Защита:

лимиты и rate limiting на периметре

корректная настройка очередей и параметров TCP на сервере

stateful-файрвол и балансировщики с защитными механизмами

DoS на L7: перегрузка приложением

На прикладном уровне атака может выглядеть как “нормальные” запросы, но их слишком много или они слишком дорогие.

Признаки:

сеть и TCP выглядят “нормально”, но приложение отвечает медленно или ошибками

растёт нагрузка CPU/DB, увеличиваются времена ответа

Защита:

лимиты на запросы, rate limiting на уровне приложений/шлюзов

кэширование, очереди, graceful degradation

WAF и правила на уровне HTTP

Hardening: практический чеклист усиления сети

Hardening удобнее делать слоями: L2, L3/L4, L7 и хосты.

L2 hardening: уменьшить шанс локальных атак

уменьшать L2-домен: VLAN по ролям и зонам доверия

не смешивать пользователей и управление инфраструктурой в одной VLAN

контролировать физический доступ к портам (не “любой порт в любую VLAN”)

мониторить аномалии ARP и дубли IP

L3/L4 hardening: контроль маршрута и доступа

явные ACL по принципу минимально необходимого

закрывать межсегментный доступ по умолчанию, открывать точечно (порты, адреса)

разделять пользовательские, серверные и админские подсети

вести логи на границе сегментов (чтобы расследовать “почему filtered”)

DNS/DHCP hardening: защита “системы адресации”

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

защищать DHCP-инфраструктуру и отслеживать “левые” DHCP-сервера

мониторить изменения DNS-серверов на хостах

TLS/SSH hardening: защита от MITM даже при наличии перехвата

TLS везде, где есть учётные данные и чувствительные данные

запрещать устаревшие версии TLS и слабые наборы шифров

не игнорировать предупреждения о сертификатах

в SSH контролировать host key: предупреждение о смене ключа — это событие безопасности

База TLS 1.3: RFC 8446. База SSH transport: RFC 4253.

Базовая “памятка пентестера”: что проверить в новой сети

границы L2: какая VLAN, кто рядом по ip neigh/arp -a

шлюз и маршруты: ip route/route print

кто DNS и как он отвечает: dig/nslookup

что режется ACL: сравнить ping, traceroute -T, проверку TCP портов

есть ли признаки MITM: неожиданные MAC для шлюза, неожиданные DNS-ответы, странные сертификаты

Как подтверждать выводы артефактами (без “догадок”)

Требование хорошего пентеста и расследования — подтверждать сетевые гипотезы наблюдаемыми фактами:

ARP аномалии: захват tcpdump arp, скрин Wireshark с ARP Reply и изменением соответствия IP→MAC

DNS аномалии: pcap с запросом и ответом, указание источника ответа, сравнение с ответом доверенного резолвера

DoS симптомы: метрики потерь/задержек, состояния TCP в ss, графики утилизации интерфейсов, логи балансировщиков

Документация по фильтрам Wireshark полезна для оформления артефактов: Wireshark Display Filters.

Итоги

MITM — это позиция “между”, которая достигается разными методами на L2/L3/L7.

ARP spoofing опасен в пределах одного L2-сегмента; сегментация и контроль L2 резко снижают риски.

DNS spoofing часто сводится к тому, кто ваш резолвер и можно ли подменить ответ; защищайте DHCP/DNS и контролируйте резолвинг.

DoS бьёт по ресурсу: каналу, состояниям или приложению; защита — это фильтрация, лимиты, архитектура и наблюдаемость.

Hardening — системная работа слоями: L2, L3/L4, DNS/DHCP, TLS/SSH и хосты.