Reverse proxy и Basic Auth: быстро прикрыть внутреннюю вебку
Цикл «Не светим лишнего». Выпуск 9.
Есть внутренняя панель, написанная когда-то давно. Она умеет показывать графики, но не умеет пользователей. Разработчика рядом нет, а доступ двум сотрудникам нужен завтра.
Самый быстрый аккуратный вариант — поставить перед ней reverse proxy и включить HTTP Basic Authentication.
Что делает reverse proxy
Внешний клиент соединяется только с NGINX, Caddy, Traefik или другим прокси. Прокси завершает TLS, проверяет пользователя и отправляет разрешённый запрос внутреннему backend.
Внутренний сервис может жить на приватном адресе и вообще не иметь прямого DNAT. На одном внешнем IP удобно публиковать несколько hostname: monitoring.example.ru, dev.example.ru, reports.example.ru.
Basic Auth — стандартная HTTP-схема, в которой браузер отправляет имя пользователя и пароль в заголовке Authorization. Сами данные кодируются Base64, а не шифруются. Защиту канала даёт только HTTPS.
NGINX хранит проверочные значения в htpasswd-файле и может ограничивать отдельные location. Можно одновременно потребовать и разрешённый IP, и пароль либо разрешить один из этих вариантов — зависит от политики.
Плюсы
- разворачивается быстро;
- старое приложение не надо переделывать;
- работает в обычном браузере;
- backend остаётся во внутренней сети;
- легко добавить TLS и журнал запросов;
- можно закрывать разные сайты разными файлами пользователей.
Минусы
- только HTTP/HTTPS;
- неудобное управление большим числом пользователей;
- нет красивого входа, MFA и восстановления учётки;
- браузер может надолго сохранить пароль;
- общие пароли быстро расходятся по чатам;
- не все приложения хорошо живут за изменившимся hostname и префиксом пути.
Где можно больно ошибиться
Basic Auth без HTTPS. Base64 легко декодируется. В открытом HTTP пароль уходит практически как текст.
Один пароль на отдел. В журнале будет одна учётка, отозвать конкретного человека невозможно.
Backend доступен в обход. Если внутренний сервис всё ещё опубликован отдельным DNAT или слушает доступный внешний интерфейс, пользователь обойдёт proxy и Basic Auth.
Слабый TLS и забытые сертификаты. Прокси становится внешней точкой, поэтому обновления, сертификаты и безопасная конфигурация обязательны.
Доверие к X-Forwarded-For от всех. Прокси должен перезаписывать служебные заголовки. Backend — принимать их только от адреса прокси.
Отсутствие защиты от перебора. Basic Auth вызывает окно входа снова и снова. Rate limit, fail2ban или внешний firewall никто не отменял.
WebSocket и длинные запросы. Некоторые панели используют WebSocket, SSE или большие загрузки. Для них на прокси нужны отдельные timeout и Upgrade-заголовки.
Когда Basic Auth достаточно
Для двух-трёх технических пользователей, временной панели или read-only-отчёта — вполне. Особенно если дополнительно ограничить доступ по IP.
Но когда появляются десятки людей, увольнения, группы, MFA и аудит, htpasswd начинает изображать систему управления доступом. В следующем выпуске поставим перед proxy нормального провайдера идентичности.
Ранее в цикле
- 1. Зачем прятать то, что всё равно должно быть доступно снаружи
- 2. Firewall без магии: закрыть всё и открыть ровно нужное