Анализ скрытых MITM в Wireshark: часть 2
Приветствую в мире цифровой безопасности! В прошлой части смотрели на сертификаты и сетевые параметры. Теперь копнём глубже: разберём признаки, которые по отдельности ещё ничего не доказывают, но вместе могут вывести на след прокси или перехватывающего узла.
⏺Начнём с TLS Alert. Если посредник не может нормально обработать соединение, он может оборвать сессию прямо во время handshake: tls.alert_message Смотрим, какие соединения заканчиваются Alert, и сравниваем их с успешными сессиями того же клиента. Один случай - ещё не сенсация. Повторяющийся сценарий - уже повод насторожиться.
⏺Следующий фильтр ловит неожиданные сбросы TCP: tcp.flags.reset == 1 Особенно интересно, если RST прилетает сразу после Client Hello или Server Hello. Сам по себе сброс не означает MITM, но если он регулярно появляется в одном и том же месте handshake, картина становится подозрительной.
⏺Теперь проверим, куда клиент вообще пытается установить TLS-соединение: tls.handshake.extensions_server_name Сверяем SNI, DNS-ответ и фактический IP назначения. Например, клиент запрашивает api.example.com, DNS отдаёт один адрес, а соединение снова и снова уходит на другой. Это может быть CDN, балансировщик или корпоративная инфраструктура, но такое расхождение точно стоит проверить.
⏺Отдельно смотрим ALPN: tls.handshake.extensions_alpn_str Сравниваем несколько соединений одного клиента. Если обычно используется h2, а часть сессий внезапно переключается на http/1.1, возможны промежуточный прокси, TLS inspection или другая прослойка между клиентом и сервером.
⏺Ищем повторные handshake через Client Hello: tls.handshake.type == 1 Добавляем к просмотру: tcp.stream Теперь сравниваем потоки. Сценарий Client Hello → несколько пакетов → FIN/RST → новый Client Hello, который повторяется снова и снова, выглядит гораздо интереснее, чем единичный разрыв соединения.
⏺Ещё один полезный фильтр: tcp.analysis.retransmission || tcp.analysis.out_of_order Здесь важно не просто посчитать retransmission, а найти закономерность. Например, повторные передачи начинаются только после TLS handshake или возникают исключительно при обращении к конкретному IP.
⏺Чтобы быстро собрать всё в одну картину, открываем: Statistics → Conversations → TCP Сортируем соединения по количеству пакетов и смотрим пары IP:port. Затем открываем подозрительный поток через Follow → TCP Stream и проверяем всю цепочку: TCP handshake, TLS handshake, Alert, retransmission и завершение соединения. MITM редко оставляет один очевидный след. Гораздо интереснее, когда DNS, SNI, TLS, TCP и поведение нескольких сессий начинают противоречить друг другу. Вот тогда уже есть за что зацепиться.
