Пивотинг в сети: первые шаги с Chisel
Команда безопасности CyberLord Профиль автора

Внутренняя сеть компании редко бывает плоской. Между внешним контуром, офисными сегментами и серверной зоной стоят межсетевые экраны, 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-прокси или проброс портов: проще, но менее универсально.
Где этому учат? Пивотинг входит в программы практических экзаменов по тестированию на проникновение и в многошаговые учебные стенды. Но главное — своя лаборатория: только там можно спокойно ломать и пересобирать схему.
Как защититься от таких туннелей? Проксировать и инспектировать исходящий трафик, ограничивать назначения по списку, запрещать прямой выход из внутренних сегментов и настроить правила на длительные соединения с внешними адресами.
Можно ли применять это в своей компании без договора? Нет. Внутренняя проверка тоже требует согласования: письменного разрешения руководителя, уведомления службы безопасности и фиксации окна работ. Иначе даже безвредный тест остаётся нарушением регламента.