Перейти к статье

Пивотинг в сети: первые шаги с Chisel

Команда безопасности CyberLord

Пивотинг в сети: первые шаги с Chisel

Внутренняя сеть компании редко бывает плоской. Между внешним контуром, офисными сегментами и серверной зоной стоят межсетевые экраны, VLAN и правила, которые должны не пускать чужого дальше первой точки входа. Проверить, работают ли эти правила в реальности, а не только на схеме, и позволяет пивотинг — прокладывание маршрута через уже скомпрометированный узел.

Дальше речь идёт исключительно о легальной работе: проверка по договору, учебная лаборатория, которой вы владеете, и никаких чужих сетей. Chisel здесь интересен как инструмент, который показывает, насколько хорошо настроен исходящий трафик, — а он, как правило, настроен хуже, чем входящий.

Что такое пивотинг и зачем он нужен

Пивотинг — это использование одного узла как релея. У машины тестировщика нет маршрута во внутренний сегмент, но есть доступ к узлу, который в этот сегмент смотрит. Трафик идёт через такой узел: с точки зрения внутренней сети запросы приходят от доверенного хоста, а не из интернета.

В пентесте это не трюк ради трюка, а способ ответить на вопрос заказчика: что произойдёт, если внешний сервер будет взломан. Проверка честна только тогда, когда она воспроизводит реальный путь атакующего, а не имитирует его сканером из внешней сети.

Почему это работает: доверие внутри периметра

Сегментация защищает от внешнего шума, но внутри сегментов обычно царит доверие. Сервер приложений спокойно обращается к базе, административная консоль доступна из офисной сети, тестовый стенд связан с промышленным контуром «временно, на пару недель».

Пивотинг использует не уязвимость, а это допущение. Поэтому находка почти всегда формулируется не как «найден туннель», а как «из точки А достижимы системы Б и В, которые по проекту не должны быть доступны».

Проверка сегментации: что именно ломается

Типичные результаты авторизованной проверки укладываются в несколько категорий.

  • Слабая сегментация. С узла в демилитаризованной зоне достижимы контроллер домена, база данных или кадровая система. Это критическая находка: одной точки входа достаточно для полного захвата.
  • Разрешённый исходящий трафик. Внутренний хост может установить HTTPS-соединение с произвольным внешним адресом. Значит, вынос данных и управляющий канал технически возможны.
  • Отсутствие детекта. Туннель работает всю проверку и не вызывает ни одного события в системе мониторинга. Отсутствие алерта — самостоятельная находка, а не «всё хорошо».
  • Правила только на бумаге. Схема сегментации описана, но между сегментами стоит маршрутизатор без фильтрации.

Виды туннелей: от проброса порта до полного маршрута

Способ Как работает Когда уместен Ограничения
Проброс порта по SSH Один локальный порт связан с портом внутреннего узла Нужен доступ к одному сервису Требует SSH-доступа, ограничен одним портом
Динамический прокси по SSH На машине тестировщика поднимается SOCKS-прокси Нужен обзор нескольких сервисов Требует SSH, часть инструментов не умеет прокси
Обратный туннель Инициатор соединения — внутренний узел Входящие соединения запрещены Нужен внешний приёмник и стабильный канал
Туннель третьего уровня Внутренняя подсеть становится маршрутизируемой Сложные многосегментные проекты Требует прав и аккуратной настройки маршрутов

Выбор диктуется не удобством, а тем, что разрешено в договоре и что вообще возможно на конкретном узле. Часто самое простое решение — проброс одного порта — даёт заказчику больше пользы, чем универсальный прокси.

Где здесь Chisel

Chisel — инструмент туннелирования через HTTP и HTTPS. Он собран в один исполняемый файл, работает как клиент и сервер и не требует установки зависимостей на узле, где уже есть выполнение команд.

Ключевая деталь: трафик выглядит как обычный веб. Межсетевые экраны, которые режут нестандартные порты и прямые TCP-соединения, часто спокойно пропускают HTTPS наружу — потому что без него не работает половина бизнес-процессов. Именно эту разницу между «запрещено всё» и «запрещено всё, кроме веба» Chisel и показывает.

Как устроен канал

Схема из двух частей. Сервер запускается на машине тестировщика или на промежуточном узле, который вы контролируете, и ждёт подключений. Клиент запускается на узле внутри проверяемого контура и сам инициирует соединение наружу — поэтому входящие порты на нём открывать не нужно.

В обратном режиме сервер принимает от клиента запрос на публикацию портов. Клиент может попросить поднять SOCKS-прокси на стороне сервера или пробросить конкретный порт внутренней системы.

Минимальный пример в лаборатории

# сервер на машине тестировщика
chisel server --reverse --port 8443

# клиент на узле-релее: просим SOCKS-прокси на стороне сервера
chisel client https://test-stand.local:8443 R:socks

# проверка: обращаемся к внутреннему сервису через прокси
curl --socks5 127.0.0.1:1080 http://internal-lab-host/

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

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

Туннель не даёт прав. Если у узла-релея нет доступа к базе, никакой прокси его не создаст. Пивотинг лишь переиспользует сетевые разрешения скомпрометированного хоста — и именно поэтому он так хорошо показывает качество сегментации.

Что проверяют в рамках договора

  • Эффективность фильтрации исходящего трафика. Может ли внутренний узел открыть HTTPS-соединение с внешним адресом.
  • Доступность внутренних сервисов. Видны ли из точки входа административные панели, порты баз данных, внутренние API.
  • Границы сегментов. Не достигает ли веб-сервер из демилитаризованной зоны контроллера домена.
  • Работа средств обнаружения. Появляются ли события в SIEM, EDR и сетевом мониторинге при устойчивом туннеле.
  • Устойчивость к разрыву. Что происходит с сессией при смене адреса, перезапуске клиента, блокировке домена.

Каждый пункт должен иметь критерий «пройдено или нет», согласованный до начала работ. Иначе отчёт превращается в пересказ процесса.

Лаборатория: где тренироваться безопасно

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

Свои виртуальные машины

Соберите три узла: машина тестировщика, узел-релей с ограниченным исходящим доступом и внутренняя цель в отдельной виртуальной сети, недостижимой напрямую. Виртуальные сети в гипервизоре позволяют воспроизвести сегментацию без железа и без риска.

Полигоны

Учебные платформы с многошаговыми сценариями дают готовую инфраструктуру и легальные рамки. Отдельно полезны стенды, воспроизводящие корпоративную сеть с Active Directory: там пивотинг проверяется вместе с боковым перемещением, а не в отрыве.

Свой домен и внешний узел

Для проверки фильтрации нужен внешний приёмник, который принадлежит вам: дешёвая виртуальная машина и собственный домен. Никогда не используйте чужие адреса «для теста» — это уже не лаборатория.

Что попадает в отчёт

Хороший отчёт по пивотингу описывает не инструмент, а путь и последствия:

  • исходная точка входа и способ, которым она получена;
  • цепочка узлов-релеев и время работы каждого туннеля;
  • какие системы стали достижимы и с какими правами;
  • какие данные были видны, без выгрузки реальных записей;
  • сработавшие и не сработавшие средства защиты;
  • рекомендации с приоритетом: что закрыть за неделю, что за квартал.

Скриншоты и журналы прикладывают как доказательства, а не как украшение. Всё, что попало в отчёт, согласуется с заказчиком по правилам обработки чувствительных данных.

Защита: что делать обороняющейся стороне

  • Проксировать исходящий трафик. Весь HTTP и HTTPS наружу — через прокси с категориями, инспекцией и журналами. Тогда туннель виден, а не растворяется в общем потоке.
  • Запрещать по умолчанию. Внутренние сегменты не должны иметь прямого выхода в интернет; исключения — по заявке и с ограничением адресов.
  • Проверять сегментацию делом. Правила на схеме и правила в конфигурации — разные вещи. Раз в год их стоит проверять авторизованным тестом.
  • Искать устойчивые соединения. Долгая HTTPS-сессия с внешним адресом от сервера, которому там делать нечего, — аномалия, которую должны ловить правила SIEM и сетевого мониторинга.
  • Ограничивать исходящие соединения по процессам. Политики управления приложениями сокращают круг программ, которым вообще разрешено ходить наружу.
  • Смотреть на объём и регулярность. Туннель редко бывает идеально ровным: всплески, ночные сессии и необычные получатели заметны на длинном интервале.

Правовые границы

Инструмент двойного назначения: им пользуются и пентестеры, и атакующие. Разница только в документе.

Легальная работа начинается с письменного согласования: договор или приложение с перечнем адресов и систем, разрешёнными техниками, окном работ, контактными лицами и порядком экстренной остановки. Отдельно фиксируют, что делать при обнаружении реального инцидента: проверка прекращается, заказчик уведомляется.

Без такого документа запуск туннеля в чужой сети — правонарушение, независимо от намерений. Формулировки «я учился», «это сеть моей компании» или «я никого не взломал» не заменяют подписанного разрешения. Внутренние проверки оформляются так же: согласование с руководителем, уведомление службы безопасности, запись в журнале изменений.

Если нужна проверка сегментации по договору или помощь в подготовке такого согласования, обсудить задачу можно без обязательств.

Частые вопросы

Чем Chisel отличается от SSH-туннеля? SSH требует доступа к узлу по SSH, а его часто нет или он ограничен. Chisel работает поверх HTTPS, который почти всегда разрешён наружу, и не требует установки на узле: это один файл.

Это то же самое, что туннель третьего уровня? Нет. Инструменты вроде Ligolo-ng создают виртуальный сетевой интерфейс, и внутренняя подсеть выглядит как напрямую подключённая. Chisel даёт SOCKS-прокси или проброс портов: проще, но менее универсально.

Где этому учат? Пивотинг входит в программы практических экзаменов по тестированию на проникновение и в многошаговые учебные стенды. Но главное — своя лаборатория: только там можно спокойно ломать и пересобирать схему.

Как защититься от таких туннелей? Проксировать и инспектировать исходящий трафик, ограничивать назначения по списку, запрещать прямой выход из внутренних сегментов и настроить правила на длительные соединения с внешними адресами.

Можно ли применять это в своей компании без договора? Нет. Внутренняя проверка тоже требует согласования: письменного разрешения руководителя, уведомления службы безопасности и фиксации окна работ. Иначе даже безвредный тест остаётся нарушением регламента.

Похожие статьи

WhatsApp