Вышла новая версия Nginx Proxy Manager 2.17 — инструмента с веб-интерфейсом для управления обратными прокси-серверами Nginx, SSL-сертификатами и правилами доступа. Основное внимание в обновлении уделено безопасности панели управления, защите конфиденциальных данных сертификатов и повышению надёжности автоматического продления SSL.
Разработчики также обновили Certbot и несколько DNS-плагинов, добавили поддержку нового провайдера Scaleway и исправили ряд ошибок, связанных с конфигурациями виртуальных хостов. При этом некоторые изменения DNS-интеграций могут потребовать дополнительных действий от администраторов. Поэтому обновление не стоит воспринимать как обычную замену версии контейнера: перед установкой важно проверить используемые способы выпуска сертификатов.
Дополнительные сведения о проекте, его возможностях и исходном коде доступны в официальном репозитории Nginx Proxy Manager на GitHub.
Что такое Nginx Proxy Manager и для чего он нужен
Nginx Proxy Manager (NPM) — открытый проект, который позволяет управлять Nginx через графический веб-интерфейс. Он особенно востребован среди владельцев домашних серверов, небольших компаний и пользователей self-hosted-инфраструктуры, которые размещают несколько веб-приложений на одном сервере.
Вместо ручного редактирования конфигурационных файлов Nginx администратор может создать прокси-хост, указать доменное имя и адрес внутреннего сервиса, настроить HTTPS и определить правила доступа. Например, на одном сервере могут одновременно работать Nextcloud, Gitea, Home Assistant, панель мониторинга и другие приложения. Nginx Proxy Manager принимает входящие запросы и направляет их к нужным службам.
К основным возможностям NPM относятся:
- создание и настройка обратных прокси для нескольких доменов;
- перенаправление запросов и настройка специальных страниц ошибок;
- выпуск и автоматическое продление сертификатов Let’s Encrypt;
- подключение собственных SSL-сертификатов;
- создание списков доступа и настройка HTTP-аутентификации;
- управление пользователями и разграничение их полномочий;
- дополнительная настройка Nginx для более сложных сценариев.
Проект распространяется в виде Docker-контейнера, что упрощает его развёртывание и обновление. Однако удобство графического управления не отменяет необходимости защищать саму панель NPM: получив к ней административный доступ, злоумышленник потенциально может повлиять на маршрутизацию запросов и работу размещённых за прокси приложений.
Усиление безопасности: защита авторизации и приватных ключей
Наиболее значительная часть Nginx Proxy Manager 2.17 связана с безопасностью. В обновлении затронуты механизмы аутентификации, проверка сертификатов, права пользователей и обработка данных, возвращаемых API.
Ограничение частоты попыток входа. Для конечных точек авторизации добавлено ограничение количества запросов. Это усложняет автоматизированный подбор паролей и массовые попытки входа в административную панель. Rate limiting не заменяет надёжный пароль и другие меры защиты, но создаёт дополнительный барьер для атак методом brute force.
Исправление уязвимости типа authentication oracle. Разработчики устранили проблему, связанную с возможностью получать информацию о состоянии аутентификации или проверять определённые сведения без надлежащих полномочий. Подобные ошибки опасны тем, что даже без прямого доступа к защищённой функции злоумышленник может использовать различия в ответах приложения для получения дополнительной информации.
Аутентификация перед проверкой сертификата. Проверка сертификатов теперь требует предварительной авторизации. Это ограничивает возможность обращаться к соответствующей функциональности без подтверждения личности пользователя.
Более строгие права на прокси-хосты. Область полномочий пользователей, работающих с proxy hosts, стала уже. Это важно для серверов, где административную панель используют несколько человек с разными уровнями доступа. Пользователь должен иметь только те возможности, которые необходимы ему для выполнения своих задач.
Защита приватных ключей SSL. Одно из наиболее важных исправлений касается API сертификатов. Ранее ответы соответствующего API могли содержать приватные ключи сертификатов. В версии 2.17 эта информация исключена из ответов.
Приватный ключ является критически важной частью инфраструктуры HTTPS. Если он попадёт к постороннему лицу, это может создать угрозу для конфиденциальности и доверия к защищённым соединениям. В зависимости от обстоятельств компрометация ключа может потребовать выпуска нового сертификата, замены ключевых материалов и проверки связанных с ним систем.
Также обновлены серверные зависимости: согласно информации о выпуске, изменения закрывают 15 из 16 отмеченных предупреждений безопасности. Среди затронутых проблем упоминается уязвимость отказа в обслуживании в пакете body-parser. При этом формулировка «15 из 16» означает, что обновление не следует считать подтверждением полного отсутствия уязвимостей во всех зависимостях.
Подробности о политике безопасности проекта и поддерживаемых версиях публикуются в официальном файле SECURITY.md в репозитории Nginx Proxy Manager. Информацию о выпусках и исправлениях следует также проверять на странице GitHub Releases.
Исправления управления SSL-сертификатами
Вторая важная группа изменений касается HTTPS и автоматического продления сертификатов. Для серверов, на которых Nginx Proxy Manager обслуживает большое количество доменов, корректная работа этой подсистемы имеет непосредственное значение: просроченный сертификат может привести к предупреждениям браузера и проблемам с доступом к сайту.
Корректная перезагрузка Nginx после продления. Исправлена ошибка, из-за которой после обновления сертификата Nginx мог продолжать использовать прежние данные. В результате новый сертификат уже существовал на диске, но обслуживаемые подключения не обязательно сразу начинали использовать его. Теперь после успешного продления Nginx должен корректно перезагружать конфигурацию и применять обновлённый сертификат.
Это важное различие: успешное получение нового сертификата ещё не гарантирует, что веб-сервер начал предъявлять его клиентам. Для корректной работы необходимо, чтобы Nginx перечитал соответствующие файлы и использовал актуальную конфигурацию.
Более понятные сообщения об ошибках Certbot. Ранее при некоторых сбоях интерфейс мог показывать обобщённое сообщение Internal Error. В версии 2.17 веб-панель отображает более конкретную причину ошибки Certbot. Это упрощает диагностику ситуаций, когда выпуск или продление сертификата не удаётся из-за DNS-проверки, неправильных учётных данных, ограничений Let’s Encrypt или проблем с доступностью DNS API.
Информация о сертификатах в таблице прокси-хостов. Данные о сертификатах теперь отображаются непосредственно в списке proxy hosts. Администратору проще заметить домены, для которых сертификат отсутствует, настроен неправильно или требует внимания. Это особенно полезно при обслуживании нескольких десятков виртуальных хостов.
В совокупности изменения делают управление сертификатами более предсказуемым. Тем не менее после обновления рекомендуется проверить состояние HTTPS на важных доменах, а не полагаться исключительно на статус в интерфейсе.
Обновление Certbot и поддержка DNS-провайдеров
Nginx Proxy Manager использует Certbot для получения и продления сертификатов Let’s Encrypt. В частности, DNS-01 challenge позволяет подтвердить владение доменом через создание специальной DNS-записи. Такой способ полезен для выпуска wildcard-сертификатов, например для домена *.example.com, а также в ситуациях, когда проверка через HTTP недоступна или неудобна.
В версии 2.17 обновлены Certbot и несколько плагинов DNS-провайдеров. Одновременно добавлена поддержка Scaleway DNS.
| Изменение | Провайдеры и компоненты |
|---|---|
| Новая интеграция | Scaleway DNS |
| Обновление плагинов | Hetzner, Infomaniak, Baidu, Akamai Edge DNS, dns-multi |
| Несовместимые изменения | Akamai Edge DNS, Beget, Infomaniak |
Самое важное для администраторов — предупреждение о несовместимых изменениях в интеграциях EdgeDNS, Beget и Infomaniak. После обновления Certbot и соответствующих DNS-плагинов существующая конфигурация может перестать работать в прежнем виде. В некоторых случаях разработчики рекомендуют заново создать DNS-сертификаты, а старые удалить.
Это не означает, что каждый пользователь перечисленных провайдеров обязательно столкнётся с проблемой. Результат зависит от используемой конфигурации, версии плагина и способа хранения параметров DNS API. Но если выпуск сертификатов автоматизирован через один из этих сервисов, обновление необходимо планировать заранее.
Перед переходом на новую версию стоит проверить:
- какие DNS-провайдеры используются для выпуска и продления сертификатов;
- какие сертификаты зависят от EdgeDNS, Beget или Infomaniak;
- сохранены ли актуальные API-токены и другие учётные данные DNS-провайдера;
- можно ли повторно выпустить сертификат без нарушения работы сайта;
- есть ли резервная копия данных NPM и возможность вернуться к предыдущей конфигурации.
Для понимания принципа работы DNS-проверки полезна официальная документация Certbot. Сведения о конкретных плагинах и их параметрах следует дополнительно сверять с документацией соответствующих DNS-провайдеров.
Исправления обратного прокси и конфигураций виртуальных хостов
Помимо безопасности и SSL, Nginx Proxy Manager 2.17 содержит несколько исправлений, влияющих на повседневную работу обратного прокси.
Сохранение списков доступа и параметров SSL. Исправлена ошибка, из-за которой правила access list и настройки SSL могли исчезать при повторной генерации конфигурационных файлов хоста. Для администратора это не просто неудобство интерфейса: потеря правил доступа может привести к тому, что ресурс окажется доступен пользователям, которым ранее был закрыт доступ.
Сохранение порта клиента в заголовке Host. Исправлена обработка заголовка Host, передаваемого проксируемому приложению. Теперь в соответствующих сценариях сохраняется порт клиента. Это важно для приложений и серверных компонентов, которые используют исходный адрес и порт при формировании ссылок, проверке запросов или обработке перенаправлений.
Настройка HSTS для отдельных хостов. Параметр, отвечающий за применение HSTS к поддоменам, теперь корректно обрабатывается на уровне каждого хоста. HSTS (HTTP Strict Transport Security) — механизм, который сообщает браузеру о необходимости использовать HTTPS при обращении к сайту. Настройка includeSubDomains распространяет это требование на поддомены.
Последняя возможность требует осторожности. Если включить HSTS с охватом поддоменов, но один из них не поддерживает HTTPS, пользователи могут столкнуться с проблемами доступа. Поэтому настройки следует выбирать с учётом реальной структуры доменов и готовности всех поддоменов к работе по защищённому протоколу.
Изменения веб-интерфейса и Docker-контейнера
В пользовательском интерфейсе появилась дополнительная защита от случайной потери несохранённых изменений в формах. Это небольшое, но практичное улучшение: при редактировании большого количества параметров администраторам не придётся повторно вводить настройки из-за случайного перехода на другую страницу.
Также обновлена цветовая схема тёмной темы вслед за изменениями в Tabler — UI-фреймворке, на котором основана административная панель. Обновления переводов делают интерфейс более согласованным для пользователей разных языков.
В контейнере обновлён s6-overlay до версии 3.2.3.2. Этот компонент используется для управления процессами внутри контейнера. Кроме того, перед запуском удаляются устаревшие PID-файлы Nginx. Такие файлы могут оставаться после некорректного завершения работы и мешать последующему запуску службы.
Эти изменения не добавляют принципиально новых возможностей для проксирования, но повышают стабильность работы контейнера и уменьшают вероятность проблем после аварийного завершения или перезапуска.
Как безопасно обновить Nginx Proxy Manager до версии 2.17
Обновление особенно важно для пользователей, которые открывают административную панель в интернет или используют NPM для обслуживания большого количества доменов. Однако перед установкой стоит подготовить резервную копию и проверить DNS-интеграции.
Если Nginx Proxy Manager развёрнут через Docker Compose, общий порядок действий выглядит следующим образом. Команды необходимо выполнять в каталоге, где находится файл compose.yaml или docker-compose.yml.
Сначала сохраните резервные копии постоянных каталогов NPM. Обычно это каталоги, подключённые к контейнеру как /data и /etc/letsencrypt. Если используется внешняя база данных, её также необходимо отдельно сохранить. Точные пути зависят от конфигурации конкретной установки.
После резервного копирования проверьте используемые DNS-плагины и подготовьте учётные данные провайдеров. Если задействованы EdgeDNS, Beget или Infomaniak, заранее изучите необходимость повторного выпуска сертификатов.
Затем можно загрузить новый образ и пересоздать контейнер:
docker compose pull
docker compose up -d
Эти команды подходят для типовой установки, но не заменяют проверку собственного compose-файла. Если в нём используется фиксированный тег образа, убедитесь, что он указывает на нужную версию, а не на более старый выпуск.
После обновления рекомендуется проверить следующие элементы:
- веб-интерфейс открывается, а вход в систему работает штатно;
- список proxy hosts содержит все ожидаемые домены;
- правила access list и параметры SSL сохранились;
- сайты открываются по HTTPS и предъявляют актуальные сертификаты;
- автоматическое продление сертификатов не выдаёт ошибок;
- DNS-проверки работают с используемыми провайдерами;
- контейнер и Nginx не сообщают об ошибках при запуске и перезагрузке.
Для критически важных сайтов желательно дополнительно проверить сертификат извне — например, через браузер или команду openssl s_client. Это позволит убедиться, что сервер действительно отдаёт ожидаемый сертификат, а не только хранит его обновлённую копию на диске.
Не рекомендуется обновлять рабочую систему без резервной копии, особенно если NPM управляет доступом к нескольким важным сервисам. При несовместимости DNS-плагинов последствия могут проявиться не сразу, а во время следующего автоматического продления сертификата.
Почему обновление важно даже для небольших серверов
Nginx Proxy Manager часто устанавливают на домашних серверах и недорогих VPS, поскольку он позволяет быстро организовать HTTPS и маршрутизацию без глубокого знания синтаксиса Nginx. Но небольшая инфраструктура не обязательно означает низкий уровень риска.
Если через один экземпляр NPM проходят запросы к файловому хранилищу, системе управления проектами, панели виртуализации или другим внутренним сервисам, компрометация административного интерфейса может затронуть сразу несколько приложений. Поэтому защита авторизации и приватных ключей имеет значение даже для домашней лаборатории.
Кроме установки обновлений, желательно ограничить доступ к административной панели. В типовой конфигурации NPM интерфейс управления использует порт 81, однако конкретная схема зависит от Docker Compose и настроек сети. Если нет необходимости управлять системой из интернета, разумнее разрешить подключение только из локальной сети или через VPN. Дополнительную защиту могут обеспечить сложный уникальный пароль, двухфакторная аутентификация, межсетевой экран и регулярное резервное копирование.
Важно также разделять публичные прокси-хосты и административный интерфейс. Сайтам может требоваться доступ из интернета, но это не означает, что аналогичным образом должна быть доступна панель управления сервером.
Выводы
Nginx Proxy Manager 2.17 — обновление, в котором приоритет отдан безопасности и надёжности инфраструктуры. Разработчики усилили защиту механизмов авторизации, устранили проблему раскрытия приватных ключей через API, ужесточили права пользователей и исправили обработку проверки сертификатов.
Не менее важны изменения в работе SSL: Nginx корректнее перезагружает конфигурацию после продления сертификата, интерфейс показывает более подробные ошибки Certbot, а сведения о сертификатах стали доступнее в таблице прокси-хостов. Обновление DNS-плагинов расширяет совместимость с провайдерами, включая добавление Scaleway DNS.
Главный нюанс версии — несовместимые изменения для интеграций Akamai Edge DNS, Beget и Infomaniak. Владельцам таких конфигураций необходимо заранее проверить сертификаты и подготовить план обновления. Остальным администраторам также стоит сделать резервную копию, проверить работу HTTPS и ограничить доступ к панели управления.
В целом Nginx Proxy Manager 2.17 представляет собой важный выпуск для тех, кто использует NPM как центральную точку управления обратным прокси и сертификатами. Обновление закрывает существенные проблемы безопасности, но требует внимательного отношения к DNS-плагинам и процедуре перехода на новую версию.
Часто задаваемые вопросы
Выпуск включает усиление защиты авторизации, исправление проблемы раскрытия приватных ключей через API, улучшения работы SSL-сертификатов, обновление Certbot и DNS-плагинов, а также исправления конфигураций обратного прокси.
Обновление содержит важные исправления безопасности, поэтому откладывать его без причины не стоит. Если панель управления доступна из интернета или через неё обслуживаются важные сервисы, приоритет обновления особенно высок. Перед установкой необходимо сделать резервную копию.
Да, потенциально это возможно для пользователей определённых DNS-плагинов. Для EdgeDNS, Beget и Infomaniak отмечены несовместимые изменения, из-за которых может потребоваться повторное создание DNS-сертификатов. Остальные конфигурации также следует проверить после обновления.
Это способ подтверждения владения доменом через создание специальной TXT-записи в DNS. Он позволяет выпускать wildcard-сертификаты и получать сертификаты для доменов, которые не могут пройти стандартную HTTP-проверку.
Приватный ключ используется для защиты HTTPS-соединений. Если он становится доступен посторонним лицам, это создаёт риск компрометации сертификата и связанных с ним сервисов. Исключение ключей из ответов API снижает вероятность такого раскрытия через интерфейс приложения.
В типовой конфигурации необходимо перейти в каталог с compose-файлом, сохранить данные и выполнить docker compose pull, а затем docker compose up -d. Перед обновлением следует проверить используемый тег образа и особенности DNS-плагинов.
В большинстве случаев в этом нет необходимости. Если администратору нужен удалённый доступ, безопаснее организовать подключение через VPN или ограничить доступ по IP. Публичные веб-сайты могут продолжать работать через обратный прокси без открытой для всего интернета панели управления.
Список выпусков и изменений публикуется в официальном разделе Releases на GitHub. Там же следует проверять доступность образов Docker и примечания к конкретной версии.
