OffshoreVps
Безопасность19 окт. 20268 мин чтенияАвтор: команда OffshoreVps

Скрываем IP исходного сервера: прокси, CDN и утечки

CDN скрывает ваш сервер, только если его больше ничто не выдаёт. Узнайте, как IP исходного сервера утекает через историю DNS, почту и сертификаты и как закрыть исходный сервер.

CDN или обратный прокси перед сайтом принимает на себя трафик и скрывает адрес сервера, но лишь пока настоящий IP остаётся неизвестным. Атакующие редко взламывают сам CDN. Они ищут исходный сервер напрямую. В этом руководстве перечислено, где происходят утечки адреса origin и как сделать так, чтобы origin отвергал всё, кроме вашего прокси.

Иллюстрация со щитом и замком и подписями «Прокси впереди», «Белый список для исходного сервера», «Без утечек», показывающая, как сохранить IP-адрес исходного сервера в тайне
Основные идеи этой статьи.

Как находят origin

  • История DNS: сервисы хранят старые записи, поэтому IP, которым вы пользовались до подключения CDN, всё ещё числится в базах.
  • Поддомены: записи вроде mail., ftp. или dev., указывающие прямо на сервер.
  • Заголовки писем: исходящая почта с того же хоста раскрывает его IP в заголовках.
  • Certificate Transparency и сканирование интернета: сканеры сопоставляют сертификат со всеми IP, которые его отдают.
  • Поведение приложения: вебхуки, загрузчики изображений и функции вроде «проверить этот URL» подключаются наружу с origin.

Шаг 1: начните с чистого листа

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

Шаги этого руководства по порядку: 1. Как находят исходные серверы; 2. начните с чистого листа; 3. принимайте трафик только от прокси; 4. отделите всё, что может протечь; 5. тестируйте как атакующий
Шаги этого руководства по порядку.

Шаг 2: принимайте трафик только от прокси

Разрешите веб-порты только для опубликованных диапазонов прокси и ни для чего больше. В UFW это выглядит так, с диапазонами, которые публикует ваш провайдер.

sudo ufw default deny incoming
sudo ufw allow OpenSSH
for ip in $(cat proxy-ranges.txt); do sudo ufw allow from "$ip" to any port 443 proto tcp; done
sudo ufw enable

Обновляйте список по расписанию, так как диапазоны меняются. Для более надёжной защиты используйте authenticated origin pulls (взаимный TLS), чтобы Nginx отклонял любого клиента без сертификата прокси.

Шаг 3: разделите всё, что может «протечь»

  • Отправляйте почту через другой хост или релей, но никогда с origin.
  • Не держите невеб-поддомены на IP origin.
  • Пусть исходящие запросы приложения идут через прокси или отдельный воркер.
  • Настройте серверный блок Nginx по умолчанию, который возвращает пустой ответ на неизвестный Host, чтобы сканирование голого IP ничего не показало.
server {
    listen 443 ssl default_server;
    ssl_reject_handshake on;
}

Шаг 4: проверьте всё как атакующий

Поищите свой домен в инструментах истории DNS, просканируйте свой диапазон IP на наличие сертификата и проверьте заголовки тестового письма. Если хоть где-то виден origin, смените IP и повторите проверку.

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