CDN или обратный прокси перед сайтом принимает на себя трафик и скрывает адрес сервера, но лишь пока настоящий IP остаётся неизвестным. Атакующие редко взламывают сам CDN. Они ищут исходный сервер напрямую. В этом руководстве перечислено, где происходят утечки адреса origin и как сделать так, чтобы origin отвергал всё, кроме вашего прокси.
Как находят origin
- История DNS: сервисы хранят старые записи, поэтому IP, которым вы пользовались до подключения CDN, всё ещё числится в базах.
- Поддомены: записи вроде
mail.,ftp.илиdev., указывающие прямо на сервер. - Заголовки писем: исходящая почта с того же хоста раскрывает его IP в заголовках.
- Certificate Transparency и сканирование интернета: сканеры сопоставляют сертификат со всеми IP, которые его отдают.
- Поведение приложения: вебхуки, загрузчики изображений и функции вроде «проверить этот URL» подключаются наружу с origin.
Шаг 1: начните с чистого листа
Если сервер уже был раскрыт, надёжнее всего сменить IP или перенести сайт на новый сервер. Скрыть адрес, который уже стал публичным, не получится. Спланируйте переезд по руководству по миграции без простоя.
Шаг 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.