Часто возникают ситуации, когда хочется силами веб сервера закрыть доступ к какому-то непубличному ресурсу. Причём не обязательно у этого ресурса нет своей аутентификации. Если нет явной необходимости то и её стоит закрыть от посторонних глаз. Расскажу, какими способами это можно сделать в веб сервере Angie/Nginx.

1️⃣ Basic Authentication. Самый простой и быстрый способ, известный очень давно. Для аутентификации используется текстовый файл с сохранёнными там парами логин-пароль. Очевидное неудобство – этот файл нужно вести отдельно от любых других хранилищ учётных записей.

2️⃣ Модуль ngx_http_auth_request_module. Это модуль от команды Nginx, который работает относительно просто. Он создаёт подзапрос к какому-то внешнему сервису и если получает от него код ответа 2xx, доступ разрешается, если 401 и 403, то запрещается. В качестве внешнего сервиса могут использоваться разные системы с разными бэкендами для хранения учётных данных. Например, для аутентификации через LDAP обычно используют nginx-ldap-auth. Полная схема работы с ним есть в статье на сайте Nginx.

Удобство этой схемы в том, что конфигурация веб сервера не содержит в себе логики аутентификации, не привязана к ней. А внешний сервис может располагаться где угодно.

3️⃣ Модуль ngx_http_auth_ldap_module. Это внешний модуль стороннего разработчика для аутентификации через внешний LDAP сервис. Его отличие от предыдущего варианта в намного более простой настройке. Вся логика подключения к LDAP каталогу настраивается в конфигурации веб сервера. Он делает все запросы к каталогу и выполняет аутентификацию.

4️⃣ Модуль ngx_http_auth_spnego_module. Этот модуль позволяет настроить аутентификацию через Active Directory с помощью Kerberos. Его удобство относительно описанных выше способов в том, что если у вас браузер поддерживает сквозную аутентификацию Kerberos, то доменные пользователи будут автоматически попадать на закрытые ресурсы без необходимости отдельно вводить учётные данные.

5️⃣ Сервис SSO, например, Authentik. Решил вынести этот способ в отдельный пункт, хотя это и не совсем корректно. Это может быть комбинация различных методов аутентификации, так как тот же Authentik, к примеру, может выступать в качестве LDAP каталога, либо реализовывать тот же метод Basic Authentication, только с хранением учётных данных у себя.

Если будете использовать внешние модули, то удобнее взять Angie, так как там в базовом репозитории они все уже есть. Для Nginx скорее всего что-то придётся собирать самому в зависимости от дистрибутива. Где-то в репозиториях есть модули, где-то нет.

Современным и удобным способом является использование сервиса SSO. Наиболее известные - Keycloak, Authentik, Authelia, ZITADEL. Список составлен от сложного и тяжёлого к более простому и лёгкому. Они реализуют в том числе современные технологии типа OAuth2, OTP (one-time password), OpenID Connect и т.д. Но и, соответственно, требуют больше внимания и времени на настройку. Если какой-то модуль Nginx можно быстро установить и настроить, то с SSO придётся повозиться. Для простых ситуаций это может быть неоправданно.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#nginx #angie

Думаю, все уже слышали или знают такой продукт, как Angie. Это веб сервер, форк Nginx, который развивается, насколько я понимаю, независимо от него. Я уже давно нигде не устанавливаю Nginx. Если только по привычке на тестах каких-нибудь, потому что он есть в базовых репах дистрибутивов, а Angie - нет. В работу везде ставлю Angie, потому что он функциональнее и удобнее Nginx.

Мне сейчас сходу трудно перечислить ключевые отличия от Nginx, потому что за последним банально перестал следить. Мне лично Angie сразу понравился в первую очередь тем, что там:

🔹Удобнее устанавливать дополнительные модули. Они все упакованы в пакеты в едином репозитории. Просто берёшь, ставишь и настраиваешь. В то время, как Nginx приходилось собирать самому с нужными модулями.

🔹У Angie реализован экспорт метрик для мониторинга, плюс панель веб управления, где своя визуализация некоторых метрик и настроек. Я сделал себе шаблон для Zabbix, но после того, как разработчики опубликовали свой дашборд для Grafana, перешёл на него, так как стало лень поддерживать свой шаблон самому. А тут всё уже есть в готовом виде.

🔹Над Angie активно работают и улучшают, в том числе полностью бесплатную open source версию. Бесплатный Nginx после продажи компании F5 как-будто развивать вообще перестали и просто поддерживают на плаву.

Сейчас Angie умеет, как и Traefik, проксировать запросы в Docker контейнеры на основании их меток. На этой теме последний поднялся в своё время, потому что никто так больше не умел. Я недавно случайно увидел эту возможность. Не знаю, когда она появилось, но это удобно.

Про настройку Angie написал отличный содержательный цикл статей Лавлинский Николай. Его материалы, как и анонсы вебинаров Отуса с его участием, можно периодически наблюдать на моём канале.

Каждая статья содержит как текстовое описание, так и подробное видео с примерами. Очень содержательный материал. Рекомендую. Я смотрел все видео. Там и по базовой, и не только, настройки есть всё, что нужно. Цикл опубликован на Хабре:

◽️Почему стоит переходить на Angie.
◽️Установка Angie из пакетов и в докере.
◽️Переезд с Nginx на Angie. Пошаговая инструкция.
◽️Настройка location в Angie. Разделение динамических и статических запросов.
◽️Перенаправления в Angie: return, rewrite и примеры их применения.
◽️Сжатие текста в Angie: статика, динамика, производительность.
◽️Серверное кэширование в Angie: тонкости настройки.
◽️Настройка TLS в Angie: безопасность и скорость.
◽️Настройка Angie в роли обратного HTTP-прокси.
◽️Балансировка нагрузки для HTTP(S) в Angie.
◽️Мониторинг Angie с помощью Console Light и API.
◽️Балансировка и проксирование L4-трафика в Angie.
◽️Клиентское кэширование в Angie.
◽️Динамические группы проксируемых серверов в Angie.
◽️Мониторинг Angie с Prometheus и Grafana.

Немного не в тему, но добавлю ещё одну интересную ссылку с полезным материалом:

⇨ Ещё одно тестирование Angie, HAProxy, Envoy, Caddy и Traefik от Devhands
HAProxy показывает наиболее сбалансированные и стабильные результаты на стандартных настройках. Старый, проверенный универсальный балансировщик.

Если всё ещё используете Nginx, рекомендую попробовать Angie. Переезд на него не требует практически никаких изменений конфигурации. Возможно где-то только пути придётся поправить с /etc/nginx на /etc/angie, а может и этого не придётся в зависимости от структуры вашей конфигурации.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#webserver #angie #отечественное

Вчера была заметка про Angie. Хочу подробнее остановиться на одной из его настроек, о которой кто-то возможно не знает. Привычное применение веб сервера - непосредственно обработка HTTP запросов или их проксирование с балансировкой куда-то ещё. Последнее обычно называют работой в качестве обратного прокси. Но помимо HTTP трафика Angie может обрабатывать и другие соединения.

У Nginx, следовательно и у Angie, есть модуль Stream для обработки TCP и UDP соединений. По умолчанию он не включён в стандартный состав веб-сервера, да и появился он в Nginx не сразу. С его помощью можно проксировать соединения, к примеру RDP протокола, DNS запросов или подключений к VPN серверу. Применений можно найти массу. Очень удобно управлять всеми соединениями в единой точке входа.

Раньше для подобных задач проще было взять HAProxy, потому что он изначально всё это умеет. Не надо ничего пересобирать. Сейчас, в принципе, тоже это просто сделать, но если у вас уже есть Angie и хочется всё реализовать с его помощью, то удобнее будет именно его и использовать.

У Angie модуль stream включён в сборку в стандартных пакетах, так что ничего не нужно дополнительно делать. Можно сразу настраивать нужную функциональность. Выглядит она примерно так:

stream {
  limit_conn_zone $binary_remote_addr zone=addr:10m;
  log_format basic '$remote_addr [$time_local] '
    '$protocol $status $bytes_sent $bytes_received '
    '$session_time ' "$upstream_addr";
  include /etc/angie/stream.d/*.conf;
}

upstream rdp {
  server 192.168.100.2:3389;
  server 192.168.100.3:3389;
}

server {
  listen 3390;
  allow 192.168.100.0/24;
  deny all;
  limit_conn addr 1;
  proxy_pass rdp;
  access_log /var/log/angie/rdp-access.log basic;
}

❓Что мы тут сделали:

- Запустили Angie на TCP порту 3390 слушать входящие соединения.
- Настроили перенаправление соединений на 2 терминальных сервера:
  server 192.168.100.2:3389;
  server 192.168.100.3:3389;
- Настроили ограничение на 1 соединение с одного IP адреса.
- Настроили ограничение на доступ только из подсети 192.168.100.0/24.
- Настроили логирование соединений в rdp-access.log с заданным форматом.

Это немного синтетический пример просто для демонстрации возможностей. Конкретно RDP протокол может не только транслироваться куда-то дальше, но и разбираться прямо на сервере с помощью ещё одного модуля stream_rdp_preread_module. Можно идентифицировать сессию и направить её на конкретный сервер. Отдельно отмечу, что подобная настройка будет актуальна и для одного RDP сервера. Мы просто скрываем его за Angie.

❓В чём вообще смысл подобных настроек? Балансировщиков много разных, плюс сам сервис может иметь свой балансировщик, как тот же RD Gateway (Remote Desktop Gateway).

Основное удобство в том, что вы получаете все инструменты по управлению, ограничению, логированию запросов, которые уже есть в Angie. Я тут как раз их и продемонстрировал. Мы, во-первых, логируем все запросы, в том числе и неудачные, мы, во-вторых, ограничили число запросов и доступ с определённых подсетей. И это далеко не всё, что умеет Angie.

В дополнение к этому можно настроить TLS соединения с клиентами для тех сервисов, которые сами это не умеют делать. То есть клиенты подключатся к Angie по TLS, а дальше соединения проксируются на сервис без шифрования. Какой-нибудь старый почтовый сервер так можно закрыть, который стоит локально и не умеет в шифрование. Или соединения к СУБД временно направить извне, не меняя конфигурацию, которая настроена на локальные подключения без шифрования.

Плюс, можно на основе имени домена в SNI направить трафик в нужном направлении. Например, при обращении к домену example.com направлять запросы на веб сервер с сайтом, а при запросе домена rdp.example.com направить соединения на бэкенды с RDP. То есть мы не по портам раскидываем трафик, а по доменным именам в TLS соединениях.

В общем, функциональность очень удобная и простая в настройке. По хорошему, имеет смысл так закрывать все публичные службы.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#angie