Девятнадцать поддоменов, один ... Заметка
DEV Community на русском

Девятнадцать поддоменов, один разрешенный IP-адрес

Запись DNS с подстановочным знаком упрощает публикацию сервисов, автоматически разрешая любой поддомен одному IP-адресу. Nginx Proxy Manager (NPM) еще больше упрощает публикацию, требуя всего несколько полей для безопасного предоставления доступа к сервисам с помощью HTTPS. Эта автоматизация привела к созданию девятнадцати прокси-хостов, все из которых запускают саморазмещенное программное обеспечение с различными методами аутентификации. Основная выявленная проблема заключается в том, что простота публикации обходит критически важные решения по безопасности, касающиеся контроля доступа.Цель автора заключалась не в том, чтобы полностью скрыть сервисы, а в том, чтобы сделать их доступными только из частной сети, построенной на общедоступной инфраструктуре. Запись DNS с подстановочным знаком, хотя и упрощает настройку, сама по себе не обеспечивает безопасности. NPM использует вызовы HTTP-01 для сертификатов Let's Encrypt, что требует, чтобы порт 80 оставался открытым, что является уязвимостью безопасности. Подстановочный сертификат через DNS-01 позволил бы закрыть порт 80, но требует предоставления прав на запись в зоне DNS.Сервисы публикуются путем размещения их контейнеров в общей сети Docker, что позволяет NPM проксировать запросы внутри сети. Это означает, что сервисам не нужно напрямую открывать порты для хоста, что повышает безопасность. Саморазмещенный прокси-шлюз на том же VPS направляет трафик обратно в NPM, представляясь как входящий HTTPS с общедоступного IP-адреса VPS. Поведение этого шлюза, первоначально ошибочно принятое за ошибку маршрутизации, является неотъемлемой частью схемы безопасности.NPM обеспечивает контроль доступа с помощью блоков конфигурации Nginx, которые разрешают запросы только с внутреннего IP-адреса Docker шлюза или общедоступного IP-адреса VPS, за которыми следует базовая HTTP-аутентификация. Это гарантирует, что, несмотря на то, что сервисы общедоступны и имеют действительные сертификаты, доступ к ним ограничен. Отдельное расположение для вызовов Let's Encrypt остается открытым для Интернета, как того требует проверка сертификата. Два критически важных хоста, панель администратора шлюза и конечная точка распространения конфигурации, являются исключениями из строгого контроля доступа, поскольку они должны быть доступны до полной интеграции шлюза.Серьезная проблема возникла, когда сервис, который встраивал свой серверный адрес в профили подключений пользователей, ошибочно рекламировал неправильный адрес. Поскольку NPM передает реальный IP-адрес клиента через заголовок X-Forwarded-For, сервис интерпретировал этот заголовок как свой собственный общедоступный адрес, что приводило к тому, что клиенты подключались к неправильному серверу. Эта ошибка оставалась незамеченной, потому что собственное тестирование автора, использующее шлюз, всегда представляло правильный ожидаемый адрес. Терминация TLS происходит в NPM, а трафик между NPM и серверными контейнерами передается в виде незашифрованного HTTP по сети Docker.