Часто возникают ситуации, когда хочется силами веб сервера закрыть доступ к какому-то непубличному ресурсу. Причём не обязательно у этого ресурса нет своей аутентификации. Если нет явной необходимости то и её стоит закрыть от посторонних глаз. Расскажу, какими способами это можно сделать в веб сервере 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 скорее всего что-то придётся собирать самому в зависимости от дистрибутива. Где-то в репозиториях есть модули, где-то нет.
Современным и удобным способом является использование сервиса SSO. Наиболее известные - Keycloak, Authentik, Authelia, ZITADEL. Список составлен от сложного и тяжёлого к более простому и лёгкому. Они реализуют в том числе современные технологии типа OAuth2, OTP (one-time password), OpenID Connect и т.д. Но и, соответственно, требуют больше внимания и времени на настройку. Если какой-то модуль Nginx можно быстро установить и настроить, то с SSO придётся повозиться. Для простых ситуаций это может быть неоправданно.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#nginx #angie
Please open Telegram to view this post
VIEW IN TELEGRAM
Nginx
Restricting Access with HTTP Basic Authentication
Control access using HTTP Basic authentication, and optionally in combination with IP address-based access control.
2👍106👎2
Расскажу про одну простую настройку в Nginx/Angie, которую использую постоянно, но с некоторыми нюансами, про которые возможно кто-то не знает. По крайней мере я не сразу об этом узнал. Речь пойдёт про basic_auth.
Я уже много раз упоминал про эту настройку, которая позволяет очень просто и быстро скрыть от посторонних глаз какой-то сервис с помощью простой аутентификации с использованием имени пользователя и пароля. Делается это примерно так:
Создали файл
Теперь при попытке открыть сайт, будет выскакивать окно с аутентификацией. И пока не введешь логин с паролем, невозможно узнать, что в принципе находится на сайте.
Таким способом очень удобно скрывать различные непубличные сервисы или технические панели. Например, я всегда так закрываю публикацию баз 1C, доступ в Phpmyadmin, Zabbix, Grafana, Apache Guacamole, какую-нибудь веб панель для управления, если используется и т.д. В общем, всё, что не для широкой публики лучше скрыть от посторонних глаз.
Иногда хочется, чтобы кого-то пускало напрямую без аутентификации. Первое, что приходит в голову, добавить директивы allow и deny, потому что они тоже часто используются. По крайней мере я постоянно использую. Но они напрямую не работают с basic_auth, либо одно, либо другое. Нужен ещё один параметр - satisfy.
В этом примере пользователи из подсети 192.168.137.0/24 зайдут на ресурс напрямую без аутентификации, а всем остальным нужно будет ввести пароль. Это удобно для той же публикации 1С, когда люди из офиса ходят напрямую в локальную базу, а снаружи с аутентификацией. В случае публикации на внешнем сервере удобно разрешить доступ с внешнего IP адреса офиса прямой доступ, а всем остальным с паролем.
Точно так же удобно открыть прямой доступ к техническим панелям администраторам или только себе лично напрямую, а всем остальным закрыть паролем. Точнее даже не всем остальным, а тоже себе, если вдруг придётся подключаться с каких-то недоверенных адресов.
Если нужно указать несколько подсетей и отдельных IP адресов, то их можно добавлять новыми строками, примерно так:
Повторю на всякий случай ещё раз, что не оставляйте ничего лишнего в прямом доступе из интернета. Вопрос времени, когда в нём найдётся какая-нибудь уязвимость. И хорошо, если для неё выйдет исправление, а вы успеете обновиться. Иногда люди забывают о чём-то и панели годами висят без обновления, пока не случится какая-нибудь беда с ними.
Basic_auth простая и надёжная технология. Не припоминаю, чтобы хоть раз была какая-то уязвимость в обход неё. Пароль можно только перехватить, если не используется HTTPS, либо сбрутить, но это трудно, так как во-первых, стоит настраивать ограничение в веб-сервере на количество одновременных запросов. Я всегда это делаю по умолчанию. Плюс, производительности веб сервера будет недостаточно, чтобы подбирать сложный пароль с хорошей скоростью. Это не локально брутить. По интернету несловарный сложный пароль не подобрать.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#nginx #angie
Я уже много раз упоминал про эту настройку, которая позволяет очень просто и быстро скрыть от посторонних глаз какой-то сервис с помощью простой аутентификации с использованием имени пользователя и пароля. Делается это примерно так:
# sh -c "echo -n 'user01:' >> /etc/nginx/.htpasswd"# sh -c "openssl passwd -apr1 >> /etc/nginx/.htpasswd"Создали файл
.htpasswd, куда добавили пользователя user01 и задали ему интерактивно пароль. Теперь настраиваем Nginx/Angie, добавляя в секцию server или отдельной location настройку:location / { auth_basic "Access Denied"; auth_basic_user_file /etc/nginx/.htpasswd; try_files $uri $uri/ =404;}Теперь при попытке открыть сайт, будет выскакивать окно с аутентификацией. И пока не введешь логин с паролем, невозможно узнать, что в принципе находится на сайте.
Таким способом очень удобно скрывать различные непубличные сервисы или технические панели. Например, я всегда так закрываю публикацию баз 1C, доступ в Phpmyadmin, Zabbix, Grafana, Apache Guacamole, какую-нибудь веб панель для управления, если используется и т.д. В общем, всё, что не для широкой публики лучше скрыть от посторонних глаз.
Иногда хочется, чтобы кого-то пускало напрямую без аутентификации. Первое, что приходит в голову, добавить директивы allow и deny, потому что они тоже часто используются. По крайней мере я постоянно использую. Но они напрямую не работают с basic_auth, либо одно, либо другое. Нужен ещё один параметр - satisfy.
location / { satisfy any; allow 192.168.137.0/24; deny all; auth_basic "Access Denied"; auth_basic_user_file /etc/nginx/.htpasswd; try_files $uri $uri/ =404;}В этом примере пользователи из подсети 192.168.137.0/24 зайдут на ресурс напрямую без аутентификации, а всем остальным нужно будет ввести пароль. Это удобно для той же публикации 1С, когда люди из офиса ходят напрямую в локальную базу, а снаружи с аутентификацией. В случае публикации на внешнем сервере удобно разрешить доступ с внешнего IP адреса офиса прямой доступ, а всем остальным с паролем.
Точно так же удобно открыть прямой доступ к техническим панелям администраторам или только себе лично напрямую, а всем остальным закрыть паролем. Точнее даже не всем остальным, а тоже себе, если вдруг придётся подключаться с каких-то недоверенных адресов.
Если нужно указать несколько подсетей и отдельных IP адресов, то их можно добавлять новыми строками, примерно так:
allow 192.168.0.0/24;allow 10.20.5.0/24;allow 185.25.48.189;Повторю на всякий случай ещё раз, что не оставляйте ничего лишнего в прямом доступе из интернета. Вопрос времени, когда в нём найдётся какая-нибудь уязвимость. И хорошо, если для неё выйдет исправление, а вы успеете обновиться. Иногда люди забывают о чём-то и панели годами висят без обновления, пока не случится какая-нибудь беда с ними.
Basic_auth простая и надёжная технология. Не припоминаю, чтобы хоть раз была какая-то уязвимость в обход неё. Пароль можно только перехватить, если не используется HTTPS, либо сбрутить, но это трудно, так как во-первых, стоит настраивать ограничение в веб-сервере на количество одновременных запросов. Я всегда это делаю по умолчанию. Плюс, производительности веб сервера будет недостаточно, чтобы подбирать сложный пароль с хорошей скоростью. Это не локально брутить. По интернету несловарный сложный пароль не подобрать.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#nginx #angie
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
10👍221👎5