Nmap proxychains настройка: от filtered до точных результатов через NAT и цепочку прокси

Nmap proxychains настройка: от filtered до точных результатов через NAT и цепочку прокси

На внутреннем пентесте получаешь шелл на сервере в DMZ, пробрасываешь SOCKS5 через SSH, запускаешь proxychains nmap -sS по внутренней подсети — и видишь все порты как filtered. Перезапускаешь с -sT — половина портов пропадает, -sV повисает. Минут через десять в терминале каша из [proxychains] timeout. Знакомо?

Проблема не в прокси и не в Nmap. Проблема в том, как proxychains подменяет сетевые вызовы на уровне libc — и почему отдельные типы сканирования через SOCKS физически не способны дать корректный результат. Разберём, как правильно настроить связку nmap + proxychains4, почему теряются пакеты и в какой момент стоит отказаться от proxychains в пользу другого инструмента.

Место в цепочке атаки: зачем сканировать через прокси

Если ты только начинаешь разбираться в пентесте, полезно сразу понять, где эта техника стоит в общей картине.

MITRE ATT&CK — открытая база тактик и техник атак. T-коды (T1046, T1090 и т.п.) — её идентификаторы, по которым специалисты быстро ссылаются на конкретное поведение атакующего. Когда в отчёте пишут «T1046», все понимают, о чём речь, без пересказа на три абзаца.

Сканирование через прокси-цепочку — этап на стыке разведки и продвижения внутри сети. В терминах MITRE ATT&CK это T1046 Network Service Discovery (тактика discovery): атакующий уже закрепился на скомпрометированном хосте и ищет, какие сервисы работают во внутренней подсети, недоступной напрямую. Сам механизм проксирования классифицируется как T1090.001 Internal Proxy (тактика command-and-control) — скомпрометированный хост превращается в relay для трафика.

Типичная цепочка: initial access (foothold на машине в DMZ) → network discovery через pivot (тема этой статьи) → lateral movement на найденные сервисы → post-exploitation. Без результатов сканирования двигаться некуда: не зная, что слушает на портах 10.30.1.0/24, невозможно выбрать следующий вектор.

[Применимо: внутренний пентест, grey box / black box, после получения шелла на хосте с несколькими сетевыми интерфейсами]

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

Прежде чем повторять шаги из статьи, проверь:

• ОС атакующей машины: Kali Linux 2024+ / Debian 12+ / Ubuntu 22.04+ (proxychains4 в стандартных репозиториях)
• RAM: минимум 2 ГБ для атакующей машины — Nmap и proxychains нетребовательны к ресурсам
• Pivot-хост: SSH-доступ с правом создания туннелей, либо возможность загрузить бинарь (Chisel, ligolo-ng agent)
• Пакеты на атакующей машине: proxychains4 (proxychains-ng, GitHub rofl0r/proxychains-ng, GPLv2, активно поддерживается), nmap, openssh-client
• Сеть: атакующая машина достигает pivot; pivot видит целевую подсеть; целевая подсеть недоступна напрямую с атакующей

Установка на Debian/Kali одной командой: sudo apt install proxychains4 nmap.

Почему SYN-сканирование не работает через proxychains

Этот вопрос возникает у каждого при первом запуске. Ответ — в том, как proxychains перехватывает сетевые вызовы.

Proxychains через механизм LD_PRELOAD (подгрузка своей библиотеки перед стартом программы) перехватывает стандартные сетевые вызовы: connect(), send(), recv(). Вместо прямого подключения к целевому адресу вызов уходит в SOCKS-прокси из конфигурации. Ключевое ограничение: proxychains работает только с TCP-соединениями через стандартные libc-функции.

SYN-скан (-sS) — Nmap формирует SYN-пакет через raw socket (сырой сокет на уровне ядра), минуя connect(). Proxychains raw sockets не видит — пакет уходит мимо прокси напрямую. Если целевая подсеть недоступна, ответа нет, и Nmap маркирует все порты как filtered.

TCP connect scan (-sT) — Nmap вызывает стандартный connect(), proxychains перехватывает вызов и передаёт через SOCKS-прокси. Единственный тип сканирования Nmap, который корректно работает через proxychains.

UDP-скан (-sU) — SOCKS-прокси не передают UDP-трафик. Даже SOCKS5 (расширенный протокол проксирования с поддержкой аутентификации и DNS-резолвинга) в реализации proxychains не поддерживает UDP relay. Пакеты исчезают бесследно.

OS detection (-O) — требует отправки специально сформированных TCP/UDP-пакетов через raw sockets. Та же проблема, что у -sS.

Но есть менее очевидная причина нестабильности, которую русскоязычные источники обычно не упоминают. Согласно разбору Simon Frey (simon-frey.com/blog/nmap-through-ssh-pivot/): proxychains конвертирует non-blocking сокеты Nmap в blocking. Nmap проектировался для параллельной отправки десятков connect() в non-blocking режиме с отслеживанием через select()/poll(). Proxychains делает каждый вызов блокирующим — Nmap интерпретирует задержку как «нет ответа» и маркирует порт filtered. Даже собственный флаг Nmap --proxies socks4://127.0.0.1:1080 страдает от той же проблемы — сканирующий движок никогда не проектировался для работы через SOCKS.

Вывод прямой: при сканировании через proxychains используй исключительно -sT -Pn. Флаг -Pn отключает host discovery (ICMP-пинг через SOCKS не пройдёт в любом случае).

TCP connect scan через прокси: три уровня сканирования через pivot

По практике, описанной в исследовании Level Up Coding (тестирование на реальной лабораторной инфраструктуре: Kali, Metasploitable2 как pivot, второй Metasploitable2 как цель), есть три подхода к сканированию через pivot. Они не взаимозаменяемы — каждый следующий снимает ограничения предыдущего ценой усложнения.

Уровень 1 — сканирование прямо с pivot. SSH на скомпрометированную машину, запуск Nmap на ней командой ssh user@pivot "nmap -sT -Pn -sV target". Самый надёжный вариант: все типы сканирования, нет потерь пакетов. Ограничение: на pivot может не быть Nmap, а загрузка статического бинаря создаёт операционный шум.

Уровень 2 — SOCKS-прокси + proxychains. Создаёшь SOCKS5-прокси через SSH dynamic forwarding (туннелирование трафика через SSH), сканируешь с помощью proxychains4 nmap -sT. Работает только TCP connect scan. Это основной сценарий статьи.

Уровень 3 — TUN-маршрутизация через ligolo-ng. На атакующей машине создаётся виртуальный сетевой интерфейс (tun), весь IP-трафик маршрутизируется к целевой подсети. Ядро ОС видит внутреннюю сеть как напрямую подключённую — работают -sS, -sU, -O, NSE-скрипты. Требует загрузки агента на pivot (ligolo-ng, GitHub nicocha30/ligolo-ng).

Условие	Уровень	Инструмент
На pivot есть Nmap	1	SSH + nmap на pivot
Нужен только TCP-скан, SSH доступен	2	SSH -D + proxychains4 + nmap -sT
Нужны SYN/UDP/OS-скан или массовое сканирование	3	ligolo-ng (TUN-интерфейс)
SSH недоступен, есть HTTP-связность	2	Chisel SOCKS + proxychains4
Есть meterpreter-сессия	2	Metasploit autoroute + socks_proxy

Начинай с уровня 1 и спускайся ниже только когда предыдущий не подходит.

Nmap proxychains настройка: конфиг и dynamic chain через SOCKS5

Конфигурационный файл proxychains4 находится по пути /etc/proxychains4.conf (или /etc/proxychains.conf — зависит от дистрибутива). Открой его: sudo nano /etc/proxychains4.conf.

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

Режим цепочки. Раскомментируй dynamic_chain, закомментируй strict_chain. Dynamic chain (динамическая цепочка) пропускает недоступные прокси и продолжает через работающие. При сканировании это критично: отвалившийся прокси в strict mode ломает весь скан.

DNS через прокси. Раскомментируй proxy_dns. Без этого DNS-запросы пойдут напрямую мимо прокси, раскрывая твою активность. Для Nmap дополнительно используй флаг -n, чтобы утилита не резолвила DNS самостоятельно.

Таймауты. Значения по умолчанию (15000 мс) малы для сканирования через цепочку прокси. Увеличь оба параметра.

dynamic_chain
proxy_dns
tcp_read_time_out 30000
tcp_connect_time_out 20000

[ProxyList]
socks5 127.0.0.1 1080

В [ProxyList] указан адрес SOCKS-прокси — 127.0.0.1:1080 будет создан SSH в следующем шаге. Если используешь Tor, замени на socks5 127.0.0.1 9050. Для цепочки из нескольких прокси добавь их построчно — proxychains пропустит трафик последовательно через каждый (T1090.003 Multi-hop Proxy — многоуровневое проксирование для затруднения отслеживания).

Создание SOCKS5-прокси через SSH dynamic forwarding

Подними SSH dynamic port forwarding командой ssh -f -N -D 1080 user@pivot-host. Разбор флагов: -f отправляет SSH в фон после аутентификации; -N запрещает выполнение команд (только туннель); -D 1080 создаёт SOCKS5-прокси на локальном порту 1080. Если pivot требует нестандартных параметров SSH (legacy-сервер), добавь -o KexAlgorithms=+diffie-hellman-group1-sha1 -o HostKeyAlgorithms=+ssh-rsa.

Проверь, что туннель работает: ss -tlnp | grep 1080. Ожидаемый результат — строка с LISTEN на порту 1080. Если строки нет — SSH не создал туннель, смотри логи подключения.

Запуск сканирования

Базовая команда: proxychains4 nmap -sT -Pn -n -p 22,80,443,3306,8080 10.30.1.111. Разбор: -sT — TCP connect scan (единственный рабочий тип через прокси); -Pn — без host discovery; -n — без DNS-резолвинга через Nmap; -p — конкретные порты (полное сканирование 65535 портов через прокси займёт часы).

Ожидаемый вывод при успешной работе — строки proxychains вида |S-chain|-<>-127.0.0.1:1080-<><>-10.30.1.111:22-<><>-OK, а Nmap покажет статус портов. Если видишь [proxychains] timeout — проблема в таймаутах или нерабочем туннеле.

Для чистого вывода без шума proxychains добавь 2>/dev/null в конец команды.

Half-open scan ограничения: как заставить -sV работать через прокси

[Применимо: внутренний пентест, любая инфраструктура с TCP-сервисами за NAT]

Определение версий сервисов (-sV, service version detection) — штука, без которой ты знаешь только номер порта, но не что за ним стоит: Apache 2.2 с известной CVE или Nginx последней версии. Разница между «порт 80 открыт» и «Apache 2.2.8 с mod_cgi» — это разница между «может быть интересно» и «вот конкретный эксплойт».

Флаг -sV через proxychains работает, но с оговорками. По умолчанию Nmap отправляет множество версионных проб параллельно — через SOCKS-прокси это вызывает лавинные таймауты. Три правила для стабильного определения версий:

Первое — всегда указывай -sT явно вместе с -sV. Без -sT Nmap может попытаться отправить часть проб через raw sockets, минуя proxychains.

Второе — снизь интенсивность и параллелизм. Добавь --version-intensity 3 (по умолчанию 7 — слишком много проб для прокси) и --max-parallelism 1. Медленнее, но каждый probe дойдёт до цели.

Третье — увеличь RTT-таймаут: --max-rtt-timeout 3000ms. Прокси добавляет задержку к каждому соединению, стандартного лимита не хватает.

Итоговая команда: proxychains4 nmap -sT -Pn -n -sV --version-intensity 3 --max-parallelism 1 --max-rtt-timeout 3000ms -p 22,80,443 target.

В исследовании Level Up Coding прямой скан с pivot (уровень 1) занял 6.5 секунд и вернул точные версии всех сервисов — vsftpd 2.3.4, OpenSSH 4.7p1, Apache httpd 2.2.8. Через proxychains часть версий определялась неточно или не определялась вовсе. Если точное определение версий критично — используй уровень 1 или 3.

Когда -sV через прокси не работает

Работает если: целевой сервис отвечает на стандартные TCP version probes; задержка через прокси не превышает 3 секунд; сканируется небольшое количество портов (до 50-100).

Не работает если: сервис отвечает только на нестандартные пробы с определённым timing; между pivot и целью стоит stateful firewall, обрывающий соединения с аномальным поведением; сканируется более 200 портов одновременно — каскадные таймауты делают результаты бесполезными.

Потеря пакетов при сканировании: диагностика и тюнинг

Потеря пакетов (packet loss) через proxychains — не баг, а следствие архитектуры. Четыре основных причины:

Таймауты proxychains слишком малы. Значения tcp_read_time_out и tcp_connect_time_out по умолчанию рассчитаны на один прокси с низкой задержкой. Через SSH-туннель или цепочку задержка растёт, proxychains закрывает соединение до получения ответа. Диагностика: proxychains4 nmap -sT -Pn -n -p 22 target (один известно-открытый порт). Если [proxychains] timeout — увеличивай таймауты до 30000-60000 мс.

Non-blocking → blocking конвертация. Nmap отправляет десятки connect() параллельно, proxychains делает каждый блокирующим. При сканировании диапазонов это приводит к каскадным задержкам. Решение: --max-parallelism 1 или --max-parallelism 2.

SOCKS4 vs SOCKS5. SOCKS4 (ранняя версия протокола) не поддерживает DNS-резолвинг на стороне прокси. SSH -D создаёт SOCKS5. В конфиге proxychains используй socks5. При использовании Metasploit auxiliary/server/socks_proxy (который создаёт SOCKS4a по умолчанию) укажи socks4 в конфиге proxychains с соответствующим портом.

Прокси перегружен. Tor-нода или бесплатный SOCKS — пропускная способность ограничена. Если хочется посмотреть, что происходит: открой Wireshark на атакующей машине с фильтром tcp.port == 1080. Большое количество TCP Retransmission и RST означает, что прокси не справляется. Уменьши --max-rate в Nmap или сканируй порты пачками по 10-20.

Ловушка sshuttle: все порты показывает open

Есть инструмент, который выглядит как идеальное решение для pivoting — sshuttle. Он использует iptables-правило REDIRECT для перенаправления всего исходящего TCP в локальный Python-процесс, который пересылает трафик через SSH. Запуск: sudo sshuttle -r user@pivot 10.30.1.0/24.

Проблема, описанная Simon Frey: sshuttle принимает каждое TCP-соединение локально до того, как узнаёт, доступен ли реальный сервис на целевом хосте. С точки зрения Nmap, трёхстороннее рукопожатие (three-way handshake: SYN → SYN-ACK → ACK) завершается успешно на каждом порту — потому что handshake происходит с локальным Python-процессом, а не с целью. Nmap честно сообщает «open» на всех 1000 дефолтных портах. Первый раз это выглядит как jackpot. Второй раз — как потраченный час.

Вывод: sshuttle непригоден для сканирования портов. Для проксирования трафика к конкретным, уже известным сервисам (curl к внутреннему веб-серверу, SSH ко второму хосту) — работает нормально. Для Nmap — нет.

Ограничения proxychains и когда нужен другой инструмент

Критерий	proxychains + SSH -D	Chisel SOCKS	ligolo-ng (TUN)	Nmap на pivot
Типы Nmap-сканирования	Только -sT	Только -sT	Все (-sS, -sU, -O)	Все
Скорость	Медленно	Медленно	Нативная	Нативная
Загрузка бинарей на pivot	Нет	Да (~8 МБ)	Да (~5-8 МБ)	Нет (если Nmap есть)
UDP-сканирование	Нет	Нет	Да	Да
NSE-скрипты	Частично (TCP)	Частично (TCP)	Полностью	Полностью
Сложность настройки	Низкая	Средняя	Средняя	Минимальная
Операционный шум	Минимальный	Средний	Средний	Минимальный

proxychains достаточен когда: нужен TCP-скан до 100-200 портов на нескольких хостах; SSH-доступ к pivot уже есть; UDP и OS detection не требуются; допустима низкая скорость.

Переходи на ligolo-ng когда: нужно полноценное сканирование с -sS, -sU, -O; много хостов во внутренней подсети; критична скорость; нужны NSE vulnerability-скрипты. Ligolo-ng создаёт реальный tun-интерфейс — ядро атакующей машины видит целевую подсеть как напрямую маршрутизируемую, Nmap работает без ограничений. Настройка: на атакующей — sudo ip tuntap add user $(whoami) mode tun ligolo && sudo ip link set ligolo up && sudo ip route add 10.30.1.0/24 dev ligolo, затем запуск proxy; на pivot — запуск agent, подключение к proxy.

Metasploit autoroute — промежуточный вариант. Если у тебя уже есть meterpreter-сессия, добавь маршрут командой run autoroute -s 10.30.1.0/24, подними auxiliary/server/socks_proxy и направь proxychains на созданный порт. Ограничения те же — только TCP connect scan через proxychains.

Ограничения в modern-инфраструктуре

Stateful firewall (межсетевой экран с отслеживанием состояния соединений — Palo Alto, Fortinet, Check Point) между pivot и целевой подсетью может фильтровать паттерн множественных connect() на разные порты. Proxychains сканирует медленнее, чем прямой -sS, что парадоксально снижает срабатывание rate-based правил IDS. Но от правил на основе количества уникальных destination-портов за период это не спасёт.

EDR (endpoint detection and response — агент на хосте, отслеживающий подозрительное поведение) на pivot-хосте может задетектить SSH-туннель как аномальное сетевое поведение. CrowdStrike Falcon и SentinelOne фиксируют SSH-сессии с -D как suspicious network tunneling — в контексте red team это дополнительный риск обнаружения.

На CTF-платформах и лабораторных стендах эти ограничения обычно не действуют. На реальном пентесте — учитывай. Формулу на бумаге понять можно, но pivoting по-настоящему ощущается только когда сам прогоняешь сценарий. Готовый стенд с тасками по сетевой разведке есть на HackerLab.pro — категории web, pwn, forensics, crypto и другие; нужна регистрация, после неё доступны задачи всех уровней.

# Полная последовательность: туннель → проверка → скан
# Шаг 1: создать SOCKS5-прокси через SSH
ssh -f -N -D 1080 user@pivot-host
# Шаг 2: убедиться, что порт слушает
ss -tlnp | grep 1080
# Шаг 3: скан с определением версий
proxychains4 nmap -sT -Pn -n -sV \
  --version-intensity 3 \
  --max-parallelism 1 \
  --max-rtt-timeout 3000ms \
  -p 22,80,443 10.30.1.111

Ожидаемый результат третьего шага: proxychains выведет цепочки |S-chain|...-<><>-OK для каждого порта, Nmap отобразит open или closed с версиями сервисов. Если вместо этого — сплошные timeout — вернись к шагу 2 и проверь таймауты в /etc/proxychains4.conf.

Весь мой опыт с nmap через proxychains сводится к одному: это инструмент для тактических задач, а не для стратегического сканирования. Нужно проверить 5-10 портов на конкретном хосте — proxychains4 с SSH -D справляется за минуту. Нужно просканировать /24 с version detection и NSE-скриптами — это работа для ligolo-ng или для Nmap, запущенного прямо на pivot. Большинство руководств подают proxychains как универсальный инструмент pivoting для Nmap, и это создаёт ложное ожидание: новичок тратит час на отладку таймаутов вместо того, чтобы просто сделать ssh user@pivot "nmap -sV target" и получить точные результаты за секунды. Proxychains решает другую задачу — проксирование произвольных TCP-утилит (curl, sqlmap, Burp Suite) через pivot, и в этой роли он хорош. Для Nmap конкретно — это костыль с архитектурными ограничениями на уровне сокетов, который никакой тюнинг таймаутов не устранит полностью. Если только начинаешь разбираться с сетевым пентестом и хочешь не тыкаться вслепую — на IB Basics показывают, что делать в первый месяц после «хочу в ИБ».

🚀 Хочешь закрепить на практике? Реши задачи по теме на HackerLab — категория «pentest-machines».