Корректна ли конфигурация nginx для Unbound DNS?
По вводным: использую Nginx, стоящий перед Unbound для шифрования и управления клиентскими профилями и для доступа к Unbound по ссылкам вида dns. domain. xyz/FgCKkdkf
Сейчас ситуация такая: это моя конфигурация nginx для unbound. Что тут не так с точки зрения безопасности и что можно улучшить? На данный момент этот конфиг полностью работает. Плюсом там прикручен скрипт, который генерит HTML-страницу, на которой можно скачать.mobileconfig для iOS и сгенерированные DoH-ссылки для других клиентов. Страница автоматически удаляется через 10 минут
Опишите проблему, и специалист поможет с настройкой, исправлением ошибки или доработкой сайта. Подберём понятный план работ без лишней переписки.
Пока нет других ответов. Будьте первым, кто поможет автору.
Ответить на вопрос
Схема “Nginx перед Unbound для DoH/профилей” может быть нормальной, но безопасность зависит от деталей: кто имеет доступ к endpoint, как ограничены клиенты, не открыт ли resolver наружу как публичный DNS, как настроены TLS, rate limit и логирование. Если всё работает, это ещё не значит, что конфиг безопасен.
Минимально я бы проверил такие вещи. Во-первых, Unbound должен слушать только локальный адрес или внутренний интерфейс, а не весь интернет:
ss -lntup | grep -E ':53|:853|:443'
Если Unbound торчит наружу на 53/853 без контроля — это риск open resolver. Для DoH лучше, чтобы наружу смотрел только Nginx, а до Unbound он ходил локально.
Во-вторых, endpoint вида
/FgCKkdkfне должен быть единственной защитой. Ссылка может утечь. Добавьте хотя бы basic auth, allowlist, rate limit или отдельные токены с возможностью отзыва. Для Nginx полезны ограничения:limit_req_zone $binary_remote_addr zone=doh_limit:10m rate=10r/s; location /FgCKkdkf { limit_req zone=doh_limit burst=30 nodelay; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_pass http://127.0.0.1:8053; }
В-третьих, временная HTML-страница с mobileconfig должна отдаваться с правильными заголовками и не кэшироваться:
add_header Cache-Control "no-store, no-cache, must-revalidate" always; add_header X-Content-Type-Options "nosniff" always; add_header Referrer-Policy "no-referrer" always;
Если страница удаляется через 10 минут, убедитесь, что удаляется не только HTML, но и связанные временные файлы, а URL нельзя угадать перебором. Токен должен быть достаточно длинным: 128 бит энтропии и выше.
Также проверьте TLS: отключить старые протоколы, включить OCSP stapling при необходимости, не использовать слабые cipher suites. Логи с DNS-запросами могут содержать чувствительные данные, поэтому продумайте срок хранения и доступ к ним.
Итог: рабочая конфигурация может быть приемлемой, если Unbound не является open resolver, Nginx ограничивает доступ и частоту запросов, временные ссылки действительно одноразовые/короткоживущие, а HTML/mobileconfig не кэшируются. Без этих ограничений такой сервис легко превращается в публичный DNS или точку утечки клиентских настроек.