Прячем сервер за прокси. Часть 1: iptables и его пределы

Вот важная новость с фронта ИИ: lux_hacker 1 минуту назад Объяснить с Прячем сервер за прокси. Часть 1: iptables и его пределы 10 мин 0 Блог компании HEX. TEAM DevOps * Информационная безопасность * Обзор ВведениеПривет, Хабр!

Я DevOps-инженер в компании hex. Расскажу, как мы прятали сервер за цепочкой прокси: скрывали его реальный IP, строили из прокси-узлов цепочку для гео-распределения трафика — и при этом умудрялись сохранять IP клиента. team мы среди прочего занимаемся кибербезопасностью АСУ ТП и анализом защищённости сетей и информационных систем.

Технические детали

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

ЛегендаЕсть сервер, который принимает HTTPS-трафик на 443 порту и ещё произвольный TCP/UDP-трафик на других портах — например, игровой сервер или кастомный бинарный протокол поверх TCP/UDP. Сервер живёт в интернете и напрямую отвечает на запросы клиентов. Проблема в том, что реальный IP такого сервера постоянно светится наружу — виден в DNS, в трейсроутах, да и просто любой желающий может его просканировать и понять, что там крутится и на каких портах.

Причём речь не о теоретической угрозе: для клиента это означало реальный риск целевых атак на инфраструктуру в обход любых периметровых защит — достаточно узнать IP один раз, и все дальнейшие меры на уровне DNS/CDN/WAF теряют смысл, потому что до сервера можно достучаться напрямую. Отсюда возникло желание скрыть реальный IP: поставить перед сервером один или несколько промежуточных узлов, чтобы клиент никогда не видел настоящий адрес бэкенда напрямую. При этом задача сразу усложнялась парой требований:Нужна была возможность выстроить цепочку из нескольких таких прокси-узлов — например, чтобы клиент подключался к ближайшему географически узлу, а тот уже проксировал трафик дальше, до конечного сервера.

Отраслевые последствия

Это давало сразу два эффекта: гео-распределение (ниже задержка для клиентов в разных регионах) и дополнительный слой изоляции реального сервера — между клиентом и бэкендом может быть не один, а несколько узлов. Реальный IP клиента был важен только для HTTP-трафика — он нужен приложению для логов, антифрода и гео-детекции на уровне бизнес-логики. Для остального TCP/UDP-трафика такого требования не было — там важна была только доставка пакетов, а не то, с какого IP они пришли изначально.

Это первая статья из серии в три части про то, как мы шли от простого проброса портов через iptables к унифицированной схеме на Nginx Stream. В этой части — только про iptables: как он устроен, как с его помощью решить задачу проксирования, и где мы упёрлись в стену.

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