Крот: туннели, пивоты и обход периметра

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

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

В теме 19 основной программы VPN рассматривался как штатная технология: GRE, IPsec, WireGuard, site-to-site ⁶. Здесь тот же механизм берётся как средство обхода: что разрешено на выходе, как это использовать и почему фильтрация по порту не равна фильтрации по назначению. Границы: DNS-туннели — тема 05, сетевая сегментация ЦОД — тема 10.

Тень базового курса: VPN как легитимный туннель

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

Ключевое свойство — прозрачность для фильтра. Если туннель идёт по TCP/443 и похож на HTTPS, межсетевой экран видит разрешённый протокол. Если туннель идёт по ICMP, он выглядит как диагностика. Если по DNS — как разрешение имён. Фильтр, который смотрит только на порт и протокол, пропускает всё это.

Туннели без шифрования

GRE и IP-in-IP

GRE (RFC 2784) инкапсулирует произвольный протокол в IP с типом 47 ¹. IP-in-IP (RFC 2003) делает то же с типом 4, но без дополнительного заголовка ². Оба варианта не шифруют и не аутентифицируют, зато просты и дёшевы.

ip tunnel add gre0 mode gre remote 198.51.100.2 local 192.0.2.10 ttl 64
ip link set gre0 up
ip addr add 10.10.0.1/30 dev gre0
ip route add 10.20.0.0/24 dev gre0

ip tunnel add ipip0 mode ipip remote 198.51.100.2 local 192.0.2.10
ip link set ipip0 up
ip addr add 10.10.0.5/30 dev ipip0

С точки зрения внешнего наблюдателя это пакеты с протоколом 47 или 4 между двумя адресами. Если такие протоколы не фильтруются, туннель работает; если фильтруются — остаются TCP, UDP и ICMP.

SSH: -L, -R, -D, -w, ProxyJump

SSH — самый доступный туннель, потому что порт 22 часто открыт, а ключи уже есть. Четыре режима покрывают почти все задачи:

ssh -L 8080:192.0.2.20:80 user@192.0.2.10
ssh -R 9000:localhost:3000 user@198.51.100.7
ssh -D 1080 user@192.0.2.10
ssh -w 0:0 user@192.0.2.10

-L — локальный проброс: соединение на localhost:8080 уходит через SSH-сервер к 192.0.2.20:80. -R — обратный: сервер слушает 9000 и передаёт соединения клиенту. -D — динамический SOCKS5-прокси: любое соединение через localhost:1080 уходит через SSH-сервер ³. -w — туннель уровня 3: в туннель передаются IP-пакеты, а не TCP-потоки.

ssh -J user@198.51.100.7 user@192.0.2.10

ProxyJump строит цепочку: первый хост — прыжок, второй — цель. Для наблюдателя это два SSH-соединения, а не одно длинное.

Туннели с шифрованием и обход egress

chisel, ligolo-ng, socat

chisel несёт TCP и UDP поверх HTTP/WebSocket, что позволяет проходить через прокси и фильтры, разрешающие только веб. ligolo-ng поднимает TUN-интерфейс на стороне оператора и превращает удалённый агент в маршрутизатор. socat — универсальный мост между сокетами, полезный для одиночных пробросов.

chisel server -p 443 --reverse
chisel client https://198.51.100.7:443 R:socks

socat TCP-LISTEN:8080,fork TCP:192.0.2.20:80

chisel в режиме R:socks создаёт на клиенте SOCKS-прокси, через который оператор ходит в сеть за клиентом. Трафик выглядит как HTTPS к серверу.

Domain fronting и CDN

Domain fronting использует расхождение между именем в TLS SNI и заголовком Host: SNI указывает на разрешённый домен CDN, а Host — на нужный сервис за ним. CDN маршрутизирует по Host, фильтр видит SNI. После введения ECH и ужесточения политик у крупных провайдеров приём стал менее надёжным, но на мелких CDN встречается до сих пор.

curl -s https://cdn.example.com/ -H "Host: internal.example.com"

DoH, port knocking, SPA

DoH прячет DNS-запросы в HTTPS, port knocking открывает порт последовательностью подключений, single packet authorization (SPA) требует криптографически подписанный пакет до открытия порта. Все три решают одну задачу: сделать сервис невидимым для сканирования и при этом доступным для того, кто знает секрет.

curl -s -H 'content-type: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=example.com&type=A'

Пивот

Маршрут через хост и двойной пивот

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

ip route add 10.20.0.0/24 via 192.0.2.10

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

Bind, reverse, SOCKS и пространства имён

Обратная оболочка инициирует соединение изнутри наружу — это проходит там, где входящие запрещены. Прямая (bind) работает, только если порт доступен снаружи. SOCKS-прокси на хосте даёт доступ ко всем TCP-назначениям, которые видит хост ⁴.

ssh -D 1080 -N -f user@192.0.2.10
curl --socks5 127.0.0.1:1080 http://10.20.0.5/

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

Перехват TLS

REDIRECT, TPROXY и mitmproxy

Прозрачный перехват на шлюзе перенаправляет трафик на прокси без настройки клиента. REDIRECT работает в nat-таблице для локально сгенерированного трафика, TPROXY — для транзитного и сохраняет исходный адрес. Цепочка с redirect обязана иметь тип nat: в цепочке type filter правило redirect не добавляется — nft отвечает Operation not supported.

nft add table inet mitm
nft add chain inet mitm prerouting '{ type nat hook prerouting priority dstnat; policy accept; }'
nft add rule inet mitm prerouting tcp dport 80 redirect to :8080

mitmproxy --mode transparent --showhost -p 8080

Для HTTPS нужен свой корневой сертификат, установленный в хранилище клиента. Тогда прокси выпускает сертификат на каждое имя, клиент ему доверяет, и содержимое читается. Если клиент проверяет pinning — привязку к конкретному сертификату или ключу — подмена обнаруживается.

JA3, JA4, ECH и 0-RTT

Отпечаток TLS (JA3, затем JA4) строится по набору шифров, расширений и порядка их следования в ClientHello. Разные клиенты дают разные отпечатки, и по ним можно отличить curl от браузера, даже если трафик шифрован.

Рукопожатие TLS 1.3 описано в RFC 8446 ⁵; для перехвата важны две его особенности. ECH (Encrypted Client Hello) скрывает SNI, оставляя видимым только адрес сервера. 0-RTT ускоряет повторное соединение, но создаёт риск повторного воспроизведения данных. Оба механизма меняют то, что видит защита, и оба учитываются при построении детекторов.

Числа: накладные расходы и MTU

Каждый слой инкапсуляции уменьшает полезную нагрузку. GRE добавляет 24 байта, IP-in-IP — 20, VXLAN — 50, WireGuard — 60 для IPv4 и 80 для IPv6. При MTU 1500 путь через GRE даёт 1476 байт, а TCP-сегмент — 1436 байт полезной нагрузки.

MTU 1500
  GRE:        1500 - 24 = 1476
  TCP/IP:     1476 - 40 = 1436 (MSS)
  WireGuard:  1500 - 60 = 1440
  TCP/IP:     1440 - 40 = 1400

Если MTU на пути меньше, крупные пакеты теряются, и соединение «зависает» на передаче файла или TLS-рукопожатии. Лечение — MSS clamping на границе: маршрутизатор переписывает MSS в SYN, чтобы отправитель сразу выбрал размер, проходящий через туннель.

nft add rule inet filter forward tcp flags syn tcp option maxseg size set rt mtu

Второе следствие — стоимость туннеля в полосе. При полезной нагрузке 1400 из 1500 байт эффективность составляет 93 процента; двойная инкапсуляция снижает её до 87 процентов. Для канала 1 Гбит/с это разница в 60 Мбит/с, которую нужно учитывать при планировании.

Обнаружение и защита

Правило nftables, запрещающее GRE на выход:

nft add table inet egress
nft add chain inet egress output '{ type filter hook output priority 0; policy accept; }'
nft add rule inet egress output ip protocol gre drop
nft add rule inet egress output ip protocol ipip drop

Итоги темы

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

Пивот превращает точку опоры в маршрут. Чем меньше сегментов видит хост, тем меньше пользы от пивота; поэтому микросегментация — не бюрократия, а прямое ограничение ущерба.

Перехват TLS возможен только там, где клиент доверяет подменённому корню. Pinning, ECH и контроль Certificate Transparency уменьшают окно, но не закрывают его полностью; поэтому чувствительный трафик защищают на прикладном уровне.

Следующая тема поднимается на уровень глобальной маршрутизации — к BGP, где ошибка в одном анонсе меняет путь для половины Интернета.

Литература

1. Farinacci D., Li T., Hanks S., Meyer D., Traina P. Generic Routing Encapsulation (GRE). — RFC 2784, IETF, 2000. https://www.rfc-editor.org/rfc/rfc2784
2. Perkins C. IP Encapsulation within IP. — RFC 2003, IETF, 1996. https://www.rfc-editor.org/rfc/rfc2003
3. Ylonen T., Lonvick C. The Secure Shell (SSH) Connection Protocol. — RFC 4254, IETF, 2006. https://www.rfc-editor.org/rfc/rfc4254
4. Leech M., Ganis M., Lee Y., et al. SOCKS Protocol Version 5. — RFC 1928, IETF, 1996. https://www.rfc-editor.org/rfc/rfc1928
5. Rescorla E. The Transport Layer Security (TLS) Protocol Version 1.3. — RFC 8446, IETF, 2018. https://www.rfc-editor.org/rfc/rfc8446
6. Barker E., Dang Q. Guide to IPsec VPNs. — NIST Special Publication 800-77 Rev. 1, 2020. https://doi.org/10.6028/NIST.SP.800-77r1
7. Kurose J. F., Ross K. W. Computer Networking: A Top-Down Approach. 8th ed. — Pearson, 2021.

Дополнительные материалы

Вопросы для самопроверки

1. Почему инкапсуляция — это всегда обход фильтрации по протоколу?
2. Чем GRE отличается от IP-in-IP по возможностям и по накладным расходам?
3. Что происходит с MTU при инкапсуляции и как это проявляется?
4. Почему SSH-туннель сложнее обнаружить, чем GRE?
5. Чем -L, -R и -D отличаются по направлению инициативы?
6. Как ProxyJump меняет картину для наблюдателя?
7. Почему chisel выбирает HTTP/WebSocket, а не raw TCP?
8. Что такое single packet authorization и чем он лучше port knocking?
9. Как отличить пивот от легитимной маршрутизации между сегментами?
10. Почему прозрачный перехват TLS требует установки корневого сертификата?
11. Что показывает JA3 и что он не показывает?
12. Почему egress-allowlist по адресу ломает больше легитимных сценариев, чем по порту?

Глоссарий темы

Инкапсуляция — вложение пакета одного протокола в пакет другого.

Пивот — использование скомпрометированного хоста как промежуточной точки.

SOCKS5 — протокол проксирования TCP-соединений, часто используется для динамического проброса.

Domain fronting — расхождение SNI и Host для обхода фильтрации.

SPA — single packet authorization, доступ по криптографически подписанному пакету.

TPROXY — механизм прозрачного проксирования транзитного трафика.

JA3/JA4 — отпечатки TLS-клиента по параметрам ClientHello.

ECH — Encrypted Client Hello, скрывает SNI.

0-RTT — ранние данные TLS 1.3, отправляемые до завершения рукопожатия.

Шпаргалка по инструментам

Что почитать и посмотреть

• RFC 2784 — GRE: формат заголовка и инкапсуляция.
• RFC 2003 — IP-in-IP: минимальная инкапсуляция.
• RFC 4254 — SSH connection protocol: пробросы и их семантика.
• RFC 1928 — SOCKS5: как устроен прокси-протокол.
• RFC 8446 — TLS 1.3: рукопожатие, 0-RTT, ECH-совместимость.
• NIST SP 800-77 Rev. 1 — IPsec VPN: что защищает и где границы.

Углубление

MTU и туннели. Каждый заголовок инкапсуляции уменьшает полезную нагрузку. GRE добавляет 24 байта, IP-in-IP — 20, TLS — ещё больше. Если MTU не согласован, крупные пакеты теряются, и соединение «зависает» на передаче файла. Лечение — MSS clamping и PMTUD.

Туннель внутри туннеля. Двойная инкапсуляция увеличивает накладные расходы, но позволяет пройти два независимых фильтра. Обнаружение — по вложенным заголовкам и по необычно большому размеру пакетов для заявленного протокола.

Прокси-цепочки. Несколько прокси подряд меняют источник, но не меняют профиль: задержка растёт, поток остаётся ровным. Детектор туннеля смотрит на стабильность размера и интервалов, а не на адрес.

Pinning в приложениях. Мобильные приложения часто прибивают сертификат или открытый ключ. Это делает перехват невозможным без модификации приложения, но не мешает перехвату на уровне API, если приложение само доверяет системному хранилищу.

Лабораторная работа 6. Крот

• Раздел курса: апокриф 6 «Крот: туннели, пивоты и обход периметра»

Введение

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

Часть работы выполняется на SSH, часть — на chisel и socat, часть — на GRE. Если в среде нет SSH-сервера или chisel, используются замены, указанные в задании; вывод в журнале всё равно описывает механизм.

Цель работы

После выполнения работы получится:

• собрать три сегмента с фильтром, разрешающим только 443 и 80;
• поднять SOCKS-прокси через SSH и пройти в внутренний сегмент;
• сделать то же через chisel поверх HTTPS;
• поднять GRE-туннель и объяснить, почему он не проходит через фильтр;
• имитировать domain fronting расхождением SNI и Host;
• перехватить HTTPS через прозрачный прокси и показать, что видно без pinning;
• снять отпечаток JA3 и отличить клиентов;
• настроить egress-allowlist и проверить, что туннели перестают работать.

Теоретический минимум

Разделы теории «Туннели без шифрования», «Туннели с шифрованием и обход egress», «Пивот» и «Перехват TLS».

Перечень оснащения

Уровень воспроизводимости: 1 — пространства имён; chisel и mitmproxy — уровень 2.

Linux с iproute2, nftables, openssh-server, socat, chisel, mitmproxy, tshark, curl. Всё в unshare -rnm. Для GRE нужен модуль ядра ip_gre; если он недоступен, часть выполняется на ip6tnl или помечается как непроверенная.

Порядок выполнения работы

unshare -rnm --propagation private bash
mount -t tmpfs none /run
mkdir -p /run/netns

Часть 1. Три сегмента и фильтр

Задание

Создать три моста: dmz (192.0.2.0/24), internal (10.20.0.0/24), outside (198.51.100.0/24). Узел jump имеет два интерфейса — в dmz и internal; узел op — в outside и dmz; узел db — в internal. На op поставить правило, разрешающее только TCP 443 и 80 наружу.

ip netns exec op nft add table inet egress
ip netns exec op nft add chain inet egress output \
  '{ type filter hook output priority 0; policy drop; }'
ip netns exec op nft add rule inet egress output tcp dport { 80, 443 } accept
ip netns exec op nft add rule inet egress output ct state established,related accept

Проверить, что SSH до jump не проходит, а HTTPS — проходит.

Что должно получиться

nc -zv jump 22 зависает или получает отказ; curl https://jump проходит. Записать, какие направления остались разрешёнными и почему.

Часть 2. SOCKS через SSH

Задание

На jump поднять SSH-сервер на порту 443 (чтобы пройти фильтр) и подключиться с динамическим пробросом:

ip netns exec jump /usr/sbin/sshd -D -p 443 -o PermitRootLogin=yes \
  -o PasswordAuthentication=yes &
ip netns exec op ssh -D 1080 -N -f -p 443 root@192.0.2.10
curl --socks5 127.0.0.1:1080 http://10.20.0.5/

Если SSH-сервер недоступен, заменить на socat:

ip netns exec jump socat TCP-LISTEN:443,fork TCP:10.20.0.5:80 &
ip netns exec op socat TCP-LISTEN:8080,fork TCP:192.0.2.10:443 &
curl http://127.0.0.1:8080/

Что должно получиться

Запрос к внутреннему серверу проходит через jump; в захвате на внешнем интерфейсе видно только соединение к порту 443. Объяснить, чем SOCKS отличается от простого проброса порта.

Часть 3. chisel поверх HTTPS

Задание

Поднять сервер chisel на op и подключить клиент на jump в режиме обратного SOCKS:

ip netns exec op chisel server -p 443 --reverse &
ip netns exec jump chisel client https://198.51.100.10:443 R:socks &
curl --socks5 127.0.0.1:1080 http://10.20.0.5/

Что должно получиться

Туннель работает, хотя открыт только 443. В захвате — TLS-соединение с ровным потоком данных. Сравнить профиль с обычным HTTPS-сёрфингом: что выдаёт туннель.

Часть 4. GRE и его границы

Задание

Поднять GRE-туннель между op и jump и попробовать провести трафик через фильтр:

ip netns exec op ip tunnel add gre0 mode gre remote 192.0.2.10 local 198.51.100.10
ip netns exec op ip link set gre0 up
ip netns exec op ip addr add 10.99.0.1/30 dev gre0
ip netns exec jump ip tunnel add gre0 mode gre remote 198.51.100.10 local 192.0.2.10
ip netns exec jump ip link set gre0 up
ip netns exec jump ip addr add 10.99.0.2/30 dev gre0
ip netns exec op ping -c 2 10.99.0.2

Что должно получиться

Если фильтр пропускает только TCP 80/443, GRE не работает: пакеты отбрасываются. Убрать правило и повторить — туннель поднимается. Объяснить, почему протокол 47 не проходит через фильтр, написанный для TCP.

Часть 5. Domain fronting

Задание

Поднять на op TLS-сервер с сертификатом на cdn.example.com и виртуальным хостом internal.example.com. Отправить запрос с SNI cdn.example.com и заголовком Host: internal.example.com:

curl -k --resolve cdn.example.com:443:198.51.100.10 \
  https://cdn.example.com/ -H "Host: internal.example.com"

Снять захват и сравнить SNI с Host:

tshark -r front.pcap -Y "tls.handshake.extensions_server_name" \
  -T fields -e tls.handshake.extensions_server_name
tshark -r front.pcap -Y "http.request" -T fields -e http.host

Что должно получиться

SNI указывает на cdn.example.com, Host — на internal.example.com; сервер отдаёт внутренний контент. Объяснить, какое правило ловит расхождение и почему ECH усложняет обнаружение.

Часть 6. Прозрачный перехват TLS

Задание

Перенаправить HTTP и HTTPS на прокси и поднять mitmproxy в прозрачном режиме:

ip netns exec jump nft add table inet mitm
ip netns exec jump nft add chain inet mitm prerouting \
  '{ type nat hook prerouting priority dstnat; policy accept; }'
ip netns exec jump nft add rule inet mitm prerouting tcp dport 443 redirect to :8443
ip netns exec jump mitmproxy --mode transparent -p 8443 --set confdir=/tmp/mitm &

Установить корневой сертификат mitmproxy на клиента и выполнить запрос:

curl --cacert /tmp/mitm/mitmproxy-ca-cert.pem https://internal.example.com/

Что должно получиться

Прокси видит метод, путь и тело запроса. Затем включить на клиенте pinning (проверку отпечатка сертификата) и повторить — соединение отклоняется. Объяснить, почему pinning ломает перехват, но не мешает перехвату на прикладном уровне.

Часть 7. Отпечаток JA3

Задание

Снять два ClientHello — от curl и от Python — и сравнить отпечатки:

ip netns exec op tshark -i eth0 -f "tcp port 443" -a duration:20 -w ja3.pcap &
curl -s -o /dev/null https://198.51.100.10/
python3 -c "import ssl,urllib.request; urllib.request.urlopen('https://198.51.100.10', context=ssl._create_unverified_context())"
wait
tshark -r ja3.pcap -Y "tls.handshake.type==1" \
  -T fields -e ip.src -e tls.handshake.ciphersuite -e tls.handshake.extension.type

Что должно получиться

Наборы шифров и расширений различаются; по ним клиенты различимы. Объяснить, почему отпечаток устойчив к смене IP и что его меняет (порядок расширений, версия библиотеки).

Часть 8. Egress-allowlist и проверка

Задание

Заменить правило «разрешить 80/443» на список конкретных назначений и повторить части 2–3:

ip netns exec op nft add rule inet egress output ip daddr 198.51.100.20 tcp dport 443 accept

Что должно получиться

Туннели перестают работать, потому что их серверы не входят в список. Записать, почему allowlist по адресу надёжнее allowlist по порту и что он ломает в легитимной работе.

Часть 9. Найти и исправить ошибку

Задание

Правило nftables должно было блокировать GRE, но не блокирует:

nft add rule inet egress output ip protocol gre drop

Правило добавлено в цепочку с политикой drop, но стоит после accept для ct state established. Найти причину и исправить порядок, объяснив, почему established-трафик обходит проверку протокола.

Что должно получиться

Работающее правило, стоящее до accept, и объяснение, что ct state established — не универсальный пропуск.

Журнал работы

Контрольные вопросы

1. Почему инкапсуляция обходит фильтр, который смотрит только на порт?
2. Чем ssh -L отличается от -D и когда нужен каждый?
3. Почему chisel выглядит как обычный HTTPS?
4. Что мешает GRE пройти через фильтр TCP и как это используют защитники?
5. В чём идея domain fronting и почему ECH её усложняет?
6. Что видит прокси при перехвате TLS и что остаётся скрытым?
7. Почему pinning ломает перехват, а ECH — только усложняет?
8. Из чего строится отпечаток JA3 и почему он устойчив?
9. Чем двойной пивот отличается от одиночного по заметности?
10. Почему allowlist по адресу надёжнее allowlist по порту?
11. Какие признаки туннеля видны в NetFlow без содержимого?
12. Почему 0-RTT считается риском при перехвате?

Уборка

pkill -f "chisel"
pkill -f "mitmproxy"
pkill -f "sshd -D"
pkill -f "socat"
nft delete table inet egress 2>/dev/null
nft delete table inet mitm 2>/dev/null
ip tunnel del gre0 2>/dev/null
for n in op jump db; do ip netns del $n 2>/dev/null; done
ip link del dmz 2>/dev/null; ip link del internal 2>/dev/null; ip link del outside 2>/dev/null
rm -f front.pcap ja3.pcap