Введение
В процессе тестирования на проникновение и работы в составе Red Team вы часто получаете доступ к серверу, смотрящему в интернет, и обнаруживаете, что он имеет доступ к внутренней сети, недоступной напрямую с вашей атакующей машины. Чтобы атаковать эти внутренние системы, вам нужен способ маршрутизации трафика через скомпрометированный сервер. Эта техника называется «пивотинг» (pivoting).
Пивотинг — это, по сути, смена точки обзора. Вы больше не проводите тестирование только из сетевого расположения вашей исходной машины; вы используете скомпрометированный узел в качестве новой точки наблюдения и доступа.
Одной из самых мощных и распространенных техник пивотинга является использование динамической переадресации портов SSH для создания SOCKS-прокси в сочетании с инструментом proxychains. Эта комбинация позволяет беспрепятственно направлять практически любой внешний сетевой инструмент (например, Nmap, Nikto или Metasploit) через скомпрометированный узел.
В этой лабораторной работе мы смоделируем сценарий, в котором у вас есть SSH-доступ к выделенному промежуточному узлу (pivot host), работающему в контейнере Docker. Второй контейнер в той же частной сети Docker содержит скрытую внутреннюю веб-службу. Эта служба не доступна напрямую из виртуальной машины LabEx, поэтому вы должны получить к ней доступ через SSH-промежуточный узел. Вы узнаете, как настроить динамическую переадресацию портов SSH, сконфигурировать proxychains и использовать его для доступа к скрытой службе через промежуточный узел.
Настройка динамической переадресации портов SSH (-D)
На этом этапе вы установите SSH-соединение с контейнеризированным промежуточным узлом и создадите локальный SOCKS-прокси.
Динамическая переадресация портов позволяет указать локальный порт на вашей атакующей машине. SSH-клиент будет прослушивать этот порт, и всякий раз, когда приложение подключается к нему, соединение будет перенаправляться через защищенный SSH-канал на SSH-сервер. Затем SSH-сервер выступает в роли прокси, пересылая трафик к конечному пункту назначения.
Это более гибкий метод, чем переадресация одного порта, поскольку SOCKS-прокси может передавать множество различных запросов к разным пунктам назначения через один туннель.
Для настройки мы используем флаг -D в нашей команде SSH. Мы также добавим несколько других флагов, чтобы соединение работало в фоновом режиме.
Для вас уже создан закрытый ключ по пути ~/project/pivot_key, а SSH-служба промежуточного узла выведена на локальный порт 2222. Выполните следующую команду в терминале, чтобы создать SOCKS-прокси на локальном порту 9050:
ssh -f -D 9050 -q -C -N \
-o StrictHostKeyChecking=no \
-o UserKnownHostsFile=/dev/null \
-i ~/project/pivot_key -p 2222 pivot@127.0.0.1
Разберем флаги, использованные в этой команде. Флаг -D 9050 задает динамическую переадресацию портов и устанавливает локальный порт прослушивания на 9050. Флаг -q включает тихий режим (quiet mode), который подавляет предупреждения и диагностические сообщения. Флаг -C запрашивает сжатие всех данных, что может ускорить соединение. Флаг -N указывает SSH не выполнять удаленную команду, что полезно, когда вы только перенаправляете порты. Флаг -f переводит SSH-клиент в фоновый режим после аутентификации, чтобы вы могли продолжать использовать текущую сессию терминала. Опции -o StrictHostKeyChecking=no и -o UserKnownHostsFile=/dev/null предотвращают прерывание рабочего процесса запросами подтверждения ключа хоста при первом подключении. Флаг -i указывает SSH, какой закрытый ключ использовать, а -p 2222 указывает на необходимость подключения к контейнеру промежуточного узла, а не к стандартной SSH-службе виртуальной машины LabEx.
После выполнения команды вы можете убедиться, что порт открыт и прослушивается, используя команду ss, которая выводит статистику сокетов.
ss -tuln | grep 9050
Вы должны увидеть вывод, похожий на этот, указывающий на то, что ваша машина теперь прослушивает порт 9050:
tcp LISTEN 0 128 127.0.0.1:9050 0.0.0.0:*
tcp LISTEN 0 128 [::1]:9050 [::]:*
Настройка Proxychains (/etc/proxychains.conf)
На этом этапе вы изучите конфигурацию proxychains.
Хотя у вас уже запущен SOCKS-прокси на порту 9050, большинство инструментов командной строки (например, Nmap) не умеют нативно направлять свой трафик через SOCKS-прокси. Здесь на помощь приходит proxychains. Это инструмент, который заставляет любое TCP-соединение, инициированное приложением, проходить через прокси.
На практике proxychains — это то, что превращает туннель из разового ручного теста в многократно используемый рабочий процесс для множества инструментов.
Файл конфигурации для proxychains находится по адресу /etc/proxychains4.conf. Для этой лабораторной работы запись прокси должна указывать на SOCKS5-прокси на 127.0.0.1 порт 9050, что соответствует созданной нами динамической переадресации SSH.
Давайте посмотрим на конец файла конфигурации, чтобы подтвердить эту настройку. Используйте команду tail для вывода последних 10 строк файла:
tail -n 10 /etc/proxychains4.conf
Вы должны увидеть вывод, похожий на следующий:
[ProxyList]
## add proxy here ...
## meanwile
## defaults set to "tor"
socks5 127.0.0.1 9050
Секция [ProxyList] — это место, где определяются прокси. Строка socks5 127.0.0.1 9050 указывает proxychains направлять трафик через локальный порт 9050. Поскольку наша команда SSH -D создала прокси именно на этом порту, после обновления типа протокола дополнительная настройка не требуется.
Если вам когда-нибудь понадобится использовать другой порт или другой тип прокси, вы сможете отредактировать этот файл с помощью текстового редактора, например nano.
Тестирование SOCKS-прокси
На этом этапе вы проверите правильность настройки прокси, получив доступ к скрытой внутренней веб-службе.
Помните, что веб-служба работает на скрытом внутреннем контейнере по адресу 172.30.0.20:80. В реальном сценарии это представляет собой внутренний интранет-сайт, к которому нельзя получить доступ напрямую из внешнего интернета.
Чтобы использовать proxychains, просто добавьте команду proxychains4 перед инструментом, который хотите запустить. Давайте используем curl для получения веб-страницы.
Выполните следующую команду:
proxychains4 curl http://172.30.0.20
Когда вы это сделаете, proxychains перехватит сетевой запрос, сделанный curl, и пропустит его через SSH SOCKS-прокси на порту 9050. Затем промежуточный узел выполнит запрос к 172.30.0.20:80 во внутренней сети Docker и вернет результат.
Вы должны увидеть вывод, похожий на этот:
[proxychains] config file found: /etc/proxychains4.conf
[proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4
[proxychains] DLL init: proxychains-ng 4.14
[proxychains] Strict chain ... 127.0.0.1:9050 ... 172.30.0.20:80 ... OK
Secret Internal Data: You have successfully pivoted
Сообщение OK указывает на то, что соединение через прокси прошло успешно, а последняя строка отображает секретные данные с внутреннего веб-сервера.
Запуск внешних инструментов через промежуточный узел
На этом заключительном этапе вы будете использовать более продвинутый внешний инструмент, Nmap, для сканирования внутренней сети через установленный вами пивот.
При использовании proxychains с Nmap важно понимать существующие технические ограничения. SOCKS-прокси поддерживают только полные TCP-соединения. Они не поддерживают ICMP (ping) или полуоткрытые SYN-сканирования (которые Nmap использует по умолчанию при запуске с sudo).
Поэтому при запуске Nmap через proxychains вы должны принудительно использовать полное TCP-сканирование (TCP Connect scan) и отключить обнаружение хостов с помощью ping.
Выполните следующую команду Nmap для сканирования внутренней веб-службы на порту 80:
proxychains4 nmap -sT -Pn -p 80 172.30.0.20
Разберем использованные здесь флаги Nmap. Флаг -sT принудительно выполняет TCP Connect сканирование, что обязательно, так как SOCKS-прокси не могут обрабатывать «сырые» пакеты или SYN-сканирования. Флаг -Pn отключает обнаружение хостов (ping); поскольку SOCKS-прокси не могут маршрутизировать ICMP-запросы эхо-ответа, Nmap ошибочно посчитал бы хост недоступным, если бы этот флаг был опущен. Наконец, флаг -p 80 указывает конкретный порт для сканирования.
Вы увидите, как proxychains логирует попытки соединения, за которыми последуют результаты сканирования Nmap:
[proxychains] config file found: /etc/proxychains4.conf
[proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4
[proxychains] DLL init: proxychains-ng 4.14
Starting Nmap 7.91 ( https://nmap.org ) at 2024-01-01 12:00 UTC
[proxychains] Strict chain ... 127.0.0.1:9050 ... 172.30.0.20:80 ... OK
Nmap scan report for 172.30.0.20
Host is up (0.0020s latency).
PORT STATE SERVICE
80/tcp open http
Nmap done: 1 IP address (1 host up) scanned in 0.10 seconds
Это подтверждает, что вы можете успешно направлять сложные инструменты безопасности через скомпрометированный узел для взаимодействия с внутренними сегментами сети.
Резюме
Поздравляем! Вы успешно завершили лабораторную работу по динамической переадресации портов с помощью Proxychains.
В этой лабораторной работе вы узнали, как создать локальный SOCKS-прокси с помощью динамической переадресации портов SSH (-D). Вы также научились понимать и проверять конфигурацию proxychains. Кроме того, вы успешно направили базовые HTTP-запросы через прокси для доступа к скрытым внутренним службам. Наконец, вы адаптировали продвинутые инструменты сканирования, такие как Nmap, для работы через SOCKS-прокси, используя TCP Connect сканирование (-sT) и отключив обнаружение ping (-Pn).
Эти техники пивотинга являются важными навыками для навигации в сложных сетевых средах во время тестирования на проникновение и оценки безопасности.
