Nginx авторизация http: HTTP авторизация Nginx

12.08.201921.02.2021 No Comments

Содержание

HTTP авторизация Nginx

Иногда возникает необходимость ограничить доступ к сайту или определенному его разделу на уровне HTTP. Для веб-сервера Apache доступ ограничивается через файл .htaccess, который размещается в корне сайта или раздела. http авторизация Nginx задается только непосредственно в конфигурационном файле.

Ограничение может быть необходимо для административной части сайта или служебным ресурсам, к которым нужен веб-доступ — например, таким как мониторинг.

Чтобы описанные ниже действия принесли результат на сервере должен быть установлен и использоваться в качестве веб-сервера Nginx.

Создаем файл указывая путь к нему и имя пользователя вместо USERNAME

htpasswd -c /etc/nginx/htpasswd.users USERNAME

После выполнения команды возникнет диалог с запросом пароля. После его ввода пароль будет зашифрован и более недоступен в виде открытого текста.

Теперь осталосу указать в конфиге веб-сервера, что нужно использовать созданный только что файл для определенного виртуального хоста — пусть это будет хост, существующий по умолчанию. В качестве имени сайта укажем example.com

mcedit /etc/nginx/sites-available/default

server {
listen 80;
server_name example.com;
auth_basic «Restricted Access»;
auth_basic_user_file /etc/nginx/htpasswd.users;
location / {
..}
}

Проверяем конфигурацию Nginx

nginx -t

Даем команду на перечитывание конфигурационных файлов

nginx -s reload

На этом настройка HTTP авторизации средствами Nginx завершена. Сейчас при обращении к сайту будет открываться диалог, запрашивающий имя пользователя и пароль.

Любая попытка авторизоваться с неверными реквизитами или без них будет заканчиваться ошибкой 400.

Ограничение доступа с помощью HTTP basic authentication

Иногда возникает потребность ограничить доступ к определенному сайту-проекту, например, на время разработки или к сайту, который должен быть доступен только для определенного круга лиц. При этом не всегда удобно добавлять модуль авторизации в сам проект.

На простом примере будет показана настройка доступа для веб-серверов Nginx и Apache.

Создание файла с ключами

Для создания пар пользователь-пароль воспользуемся утилитой htpasswd. Установить её можно следующей командой:

$ apt install apache2-utils

Создадим файл с ключами .htpasswd и добавим первого пользователя. Для этого запустим утилиту htpasswd с флагом -c и путем к файлу, где будут храниться ключи, а также именем первого пользователя.

Рекомендуется разместить этот файл в рабочей директории вашего веб-сервера /etc/nginx или /etc/apache2.

$ htpasswd -c /etc/nginx/.htpasswd user1

Во время выполнения команды вам будет предложено дважды ввести пароль пользователя user1.

Если файл с ключами уже создан и вы добавляете уже не первого пользователя, то не нужно больше передавать ключ -c. Создадим второго пользователя.

$ htpasswd /etc/nginx/.htpasswd user2

Когда все пользователи будут созданы, можно проверить, что находится в файле с ключами

$ cat /etc/nginx/.htpasswd

На каждой строчке есть имя пользователя и его зашифрованный пароль

user1:$apr1$cuyHIt1g$KBw/cVxx/0AwGg8Xab6yd/ user2:$apr1$FmoTpfYo$VTOJN10R98RRie7r7t46w1

Далее необходимо настроить веб-сервер Nginx или Apache, в зависимости от того, какой из них вы используете.

Настройка Nginx

Добавьте следующие директивы в конфигурационный файл вашего проекта.

auth_basic — включение проверки авторизации
auth_basic_user_file — путь к файлу с ключами

Их можно использовать в контекстах: http, server, location, limit_except. Это значит, что можно, например, ограничить доступ ко всему серверу (файл /etc/nginx/nginx.conf):

http { ... auth_basic "Restricted Area"; auth_basic_user_file /etc/nginx/.htpasswd; ... }

к определенному проекту:

server { ... auth_basic "Restricted Area"; auth_basic_user_file /etc/nginx/.htpasswd; ... }

или к конкретному адресу в проекте:

server { ... location / { auth_basic "Restricted Area"; auth_basic_user_file /etc/nginx/. htpasswd; ... } }

Настройка Apache

Документация по модулю mod_authn_core доступна на официальном сайте.

AuthType — тип авторизации пользователя
AuthName — название защищенной области
AuthUserFile — путь к файлу с ключами
Require — проверка доступа

Можно настроить обязательную проверку авторизации для всего сервера. Для этого в конфигурационном файле /etc/apache2/apache2.conf добавим в соответствующие теги Directory требование.

<Directory /var/www/> Options Indexes FollowSymLinks AllowOverride None # Require all granted

AuthType Basic AuthName "Restricted Content" AuthUserFile /etc/apache2/.htpasswd Require valid-user </Directory>

Если необходимо настроить доступ только к определенному хосту, то редактируем его конфигурационный файл

<VirtualHost *:80> DocumentRoot /var/www/html . ..

<Directory "/var/www/html"> AuthType Basic AuthName "Restricted Area" AuthUserFile /etc/apache2/.htpasswd Require valid-user </Directory> </VirtualHost>

Файл .htaccess

Вместо редактирования настроек хоста можно добавить параметры авторизации в файл .htaccess в самом проекте.

... AuthType Basic AuthName "Restricted Content" AuthUserFile /etc/apache2/.htpasswd Require valid-user ...

Чтобы Apache мог применять настройки файлов .htaccess в проектах, необходимо установить для AllowOverride значение «All» в соответствующей директории в настройках сервера.

<Directory /var/www/> Options Indexes FollowSymLinks # AllowOverride None AllowOverride All Require all granted </Directory>

О том, как работать с файлом . htaccess можно прочитать в этой статье.

Результат

После перезагрузки сервера можно открыть страницу проекта и увидеть окно с просьбой авторизоваться.

Ссылки

Документация по модулю ngx_http_auth_basic_module для Nginx.

Документация по модулю mod_authn_core для Apache.

Модуль ngx_http_auth_request_module

Модуль ngx_http_auth_request_module (1.5.4+) предоставляет
возможность авторизации клиента, основанной на результате подзапроса.
Если подзапрос возвращает код ответа 2xx, доступ разрешается.
Если 401 или 403 — доступ запрещается с соответствующим кодом ошибки.
Любой другой код ответа, возвращаемый подзапросом, считается ошибкой.

При ошибке 401 клиенту также передаётся заголовок
“WWW-Authenticate” из ответа подзапроса.

По умолчанию этот модуль не собирается, его сборку необходимо
разрешить с помощью конфигурационного параметра
--with-http_auth_request_module.

Модуль может быть
скомбинирован с другими модулями доступа, такими как
ngx_http_access_module,
ngx_http_auth_basic_module
и
ngx_http_auth_jwt_module,
с помощью директивы satisfy.

До версии 1.7.3 ответы на авторизационные подзапросы не могли быть закэшированы
(с использованием директив
proxy_cache,
proxy_store и т.п.).

Пример конфигурации

location /private/ {
    auth_request /auth;
    ...
}

location = /auth {
    proxy_pass ...
    proxy_pass_request_body off;
    proxy_set_header Content-Length "";
    proxy_set_header X-Original-URI $request_uri;
}

Директивы

Синтаксис:	`auth_request uri \| off;`
Умолчание:	auth_request off;
Контекст:	`http`, `server`, `location`

Включает авторизацию, основанную на результате выполнения подзапроса,
и задаёт URI, на который будет отправлен подзапрос.

Синтаксис:	`auth_request_set $переменная значение;`
Умолчание:	—
Контекст:	`http`, `server`, `location`

Устанавливает переменную в запросе в заданное
значение после завершения запроса авторизации.
Значение может содержать переменные из запроса авторизации,
например, $upstream_http_*.

basic авторизация с капчей / Хабр

Для приготовления авторизации с капчей нам понадобится сам nginx и его плагины encrypted-session, form-input, ctpp2, echo, headers-more, auth_request, auth_basic, set-misc. (Я дал ссылки на свои форки, т.к. делал некоторые изменения, которые пока не удалось пропихнуть в оригинальные репозитории. Можно также воспользоваться готовым образом.)

Для начала зададим

encrypted_session_key "abcdefghijklmnopqrstuvwxyz123456";

Дальше, на всякий случай, отключаем авторизационный заголовок

more_clear_input_headers Authorization;

Теперь защищаем всё авторизацией

auth_request /auth;
location =/auth {
    internal;
    subrequest_access_phase on; # разрешаем авторизационную фазу в подзапросе
    auth_request off; # не использовать авторизацию
    set_decode_base64 $auth_decode $cookie_auth; # раскодируем авторизационную куку
    set_decrypt_session $auth_decrypt $auth_decode; # расшифровываем авторизационную куку
    if ($auth_decrypt = "") { return 401 UNAUTHORIZED; } # если не удалось расшифровать, то значит пользователь не авторизован
    more_set_input_headers "Authorization: Basic $auth_decrypt"; # подменить авторизацию на basic (чтобы использовать переменную $remote_user)
    auth_basic_user_file /data/nginx/. htaccess; # задаём файл basic авторизации
    auth_basic Auth; # включаем basic авторизацию
    echo -n OK; # пользователь авторизован
}

Для авторизованных пользователей показываем контент из их папки

location / {
    alias html/$remote_user/;
}

А при отсутствии авторизации показываем авторизационную форму с капчей

error_page 401 = @error401;
location @error401 {
    set_escape_uri $request_uri_escape $request_uri; # кодируем запрос
    return 303 /login?request_uri=$request_uri_escape; # перенаправляем на авторизационную форму с капчей, сохранив запрос
}
location =/login {
    default_type "text/html; charset=utf-8"; # задаём тип
    if ($request_method = GET) { # если только показать авторизационную форму с капчей
        template login.html.ct2; # задаём шаблон
        ctpp2 on; # включаем шаблонизатор
        set_secure_random_alphanum $csrf_random 32; # задаём случайное csrf
        encrypted_session_expires 300; # задаём время жизни csrf 5 минут (5 * 60 = 300)
        set_encrypt_session $csrf_encrypt $csrf_random; # зашифровываем случайное csrf
        set_encode_base64 $csrf_encode $csrf_encrypt; # кодируем зашифрованное csrf
        add_header Set-Cookie "CSRF=$csrf_encode; Max-Age=300"; # помещаем зашифрованное csrf в куку на 5 минут (5 * 60 = 300)
        return 200 "{\"csrf\":\"$csrf_random\"}"; # возвращаем json для шаблонизатора
    } # иначе - обработать авторизационную форму с капчей
    set_form_input $csrf_form csrf; # получаем csrf из формы
    set_unescape_uri $csrf_unescape $csrf_form; # раскодируем csrf из формы
    set_decode_base64 $csrf_decode $cookie_csrf; # раскодируем csrf из куки
    set_decrypt_session $csrf_decrypt $csrf_decode; # расшифровываем csrf из куки
    if ($csrf_decrypt != $csrf_unescape) { return 303 $request_uri; } # если csrf из формы не совпадает с csrf из куки, то перенаправить на показ формы снова
    set_form_input $captcha_form captcha; # получаем капчу из формы
    set_unescape_uri $captcha_unescape $captcha_form; # раскодируем капчу из формы
    set_md5 $captcha_md5 "secret${captcha_unescape}${csrf_decrypt}"; # считаем md5
    if ($captcha_md5 != $cookie_captcha) { return 303 $request_uri; } # если md5 не совпадает с капчей из куки, то перенаправить на показ формы снова
    set_form_input $username_form username; # получаем логин из формы
    set_form_input $password_form password; # получаем пароль из формы
    set_unescape_uri $username_unescape $username_form; # раскодируем логин из формы
    set_unescape_uri $password_unescape $password_form; # раскодируем пароль из формы
    encrypted_session_expires 2592000; # задаём время жизни сессии 30 дней (30 * 24 * 60 * 60 = 2592000)
    set $username_password "$username_unescape:$password_unescape"; # задаём basic авторизацию
    set_encode_base64 $username_password_encode $username_password; # кодируем basic авторизацию
    set_encrypt_session $auth_encrypt $username_password_encode; # зашифровываем basic авторизацию
    set_encode_base64 $auth_encode $auth_encrypt; # кодируем зашифрованную basic авторизацию
    add_header Set-Cookie "Auth=$auth_encode; Max-Age=2592000"; # помещаем зашифрованную basic авторизацию в авторизационную куку на 30 дней (30 * 24 * 60 * 60 = 2592000)
    set $arg_request_uri_or_slash $arg_request_uri; # копируем запрос из аргумента
    set_if_empty $arg_request_uri_or_slash "/"; # если аргумент не задан, то начало
    set_unescape_uri $request_uri_unescape $arg_request_uri_or_slash; # раскодируем запрос
    return 303 $request_uri_unescape; # перенаправляем на сохранённый запрос
}

<html>
    <body>
        <form method="post">
            <input type="hidden" name="csrf" value="<TMPL_var csrf>" />
            username: <input type="text" name="username" placeholder="Enter User Name..." /><br />
            password: <input type="password" name="password" /><br />
            captcha: <img src="/captcha?csrf=<TMPL_var csrf>"/><input type="text" name="captcha" autocomplete="off" /><br />
            <input type="submit" name="submit" value="submit" />
        </form>
    </body>
</html>

Jenkins/Nginx-двойной запрос на базовую аутентификацию, почему? Почему существует внутренний Jenkins auth?

Ниже приведен мой конфигурационный файл nginx для Jenkins. Большая часть его в точности соответствует тому, что я читал в документации.

Конфигурационный файл:

upstream app_server {
    server 127. ~ /jenkins/ {

    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_redirect off;

    if (!-f $request_filename) {
        proxy_pass http://app_server;
        break;
    }

    auth_basic "[....] Please confirm identity...";
    auth_basic_user_file /etc/nginx/.htpasswd;
}

}

При переходе к http://sub.mydomain.net/jenkins мне предлагают мой базовый auth с сервером говорит: [….] Пожалуйста, подтвердите идентификацию… .

Это правильно, но как только я ввожу правильные учетные данные, мне снова предлагают базовую аутентификацию, но на этот раз: сервер говорит: Jenkins .

Откуда берется этот второй скрытый basic_auth?! Для меня это не имеет никакого смысла.

Нажав CANCEL в первом приглашении, я затем правильно получаю ошибку 401 authorization required .

Нажав CANCEL на второй базовый auth ( «Server says: Jenkins» ), я получаю:

HTTP ERROR 401

Problem accessing /jenkins/.  Reason:

Invalid password/token for user: _____
Powered by Jetty://

Кто-нибудь знает, что это, возможно, происходит?

authentication

nginx

jenkins

nginx-location

Поделиться

Источник

skålfyfan

22 февраля 2016 в 20:47

2 ответа

Jenkins за nginx без подкаталога
У меня есть Jenkins, работающий внутри моей установки Glassfish, так что Jenkins может быть достигнуто @ http://localhost:8090/jenkins/ Мне удалось настроить nginx так, чтобы до Jenkins можно было добраться снаружи @ http://build.example.com/jenkins/ Эта установка работает хорошо до сих пор, но я…
почему Jenkins не может видеть некоторые файлы System32?
Ситуация : Раб, о котором идет речь, — настоящий Windows (а не VM) Проблема : Я запускаю следующую команду windows line в своей системе Bcdedit.exe -set TESTSIGNING ON Когда я пытаюсь запустить его через Jenkins, я получаю это сообщение : Bcdedit. exe не распознается как внутренняя или внешняя…

Я нашел решение своей проблемы, выполнив поиск Nginx, используемого в качестве обратного прокси-сервера для любого другого приложения с basic_auth.

Решение было ответом, найденным здесь:
https://serverfault.com/questions/511846/basic-auth-for-a-tomcat-app-jira-with-nginx-as-reverse-proxy

Строка, которую я пропустил в своей конфигурации nginx, была:

 # Don't forward auth to Tomcat
 proxy_set_header   Authorization "";

По умолчанию кажется, что после basic auth Nginx дополнительно переадресует заголовки auth в Jenkins, и именно это привело к моей проблеме. Jenkins получает переадресованные заголовки auth, а затем думает, что ему тоже нужно авторизоваться?!

Если мы настроим наш обратный прокси-сервер так, чтобы он не пересылал никаких заголовков авторизации, как показано выше, то все будет работать так, как должно. Nginx запросит basic_auth, и после успешной аутентификации мы явно очистим (сбросим?) заголовки auth при пересылке на наш обратный прокси-сервер.

Поделиться

skålfyfan

26 февраля 2016 в 20:30

У меня тоже была эта проблема, в моем случае она была вызвана включением безопасности в самом jenkins, отключение безопасности решило эту проблему.

Согласно их документам:

Если вы делаете контроль доступа в Apache, не включайте безопасность в Jenkins, так как эти две вещи будут мешать друг другу.

https://wiki.jenkins-ci.org/display/JENKINS/Apache+приложение+для+безопасность

По-видимому, происходит то, что nginx пересылает ответ auth_basic на jenkins, который пытается выполнить auth_basic в ответ. Я еще не нашел удовлетворительного решения этой проблемы.

Поделиться

Ohm

24 февраля 2016 в 21:50

Nginx + LDAP авторизация : DevOps: servers abuse

Задача

Довольно часто в корпоративной среде встречаются два сервиса:

Nginx
LDAP

И очень часто надо сделать авторизацию к какому-то сервису авторизацию
через LDAP на Nginx. Сам Nginx не имеет встроенного модуля авторизации в
LDAP, в отличие от Apache или Tomcat.

Итак, давайте сделаем basic авторизацию пользователей в Nginx через
LDAP.

Сервер авторизации

Метод, который предлагают сами разработчики Nginx заключается в
следующем: необходимо поднять промежуточный сервер, который будет
проверять введеные данные в LDAP и возвращать результат в Nginx. В
случае ответа HTTP/200 — пользователь авторизован. В любом другом случае
— даные не верны.

Компания Nginx предоставляет такой простой демон, который можно взять
тут.

Клонируем репу к себе на сервер:

$ git clone https://github.com/nginxinc/nginx-ldap-auth.git /opt/nginx-ldap-auth

и запускаем этот сервер (дополнительной настройки он не требует):

$ /opt/nginx-ldap-auth/nginx-ldap-auth-daemon-ctl.sh start

Остальная настройка будет производиться из конфига Nginx. Для этого нам
надо добавить в Nginx что-то типа такого:

        location = /auth-proxy {
            internal;
            proxy_pass_request_body off;
            proxy_set_header Content-Length "";
            proxy_pass http://127.0.0.1:8888;
            proxy_set_header X-Ldap-URL "ldap://127.0.0.1:389";
            proxy_set_header X-Ldap-Template "(uid=%(username)s)";
            proxy_set_header X-Ldap-BaseDN "dc=example,dc=com";
        }
        location /private-storage {
            auth_request /auth-proxy;
            proxy_pass http://application-backend;
        }

По умолчанию, будет произведена попытка simple bind с анонимным
пользователем. Если же у вас не поддерживается этот метод, то вам
необходимо раскомментировать строки и указать DN и пароль пользователя,
который может искать по дереву LDAP. Это самая простая конфигурация и
она может быть расширена другими модулями авторизации.

Tweet

LDAP — Nginx + LDAP Auth

OS: «Linux Debian 8/9/10», «Linux Ubuntu 16/18 LTS».
Application: Nginx, Python, LDAP.

Задача: обеспечить аутентификацию пользователей сайта через внешний LDAP-сервис, средствами web-сервера «Nginx».

С точки зрения эксплуатационщика на предприятии удобно проводить аутентификацию пользователей внутренних сервисов через некий централизованный каталог с учётными данными. Чаще всего для этого применяется сервис «Microsoft Active Directory», но технически почти всегда в этой роли можно использовать иные реализации LDAP, вроде «OpenLDAP» или «389-DS».

В сложносочинённых сайтах задачи аутентификации и авторизации обычно возлагаются на специально для этого предназначенные компоненты внутри информационной системы, для реализации которых во всех распространённых языках программирования имеются библиотеки функций взаимодействия с LDAP. С мелкими сайтами, возможно даже полностью статическими, сложнее — у них нет подкапотных механизмов, посредством которых можно было бы проверять право доступа пользователя к запрашиваемым данным. В таком случае на роль привратника остаётся один кандидат — web-браузер. И вот на этом этапе выясняется, что любимый нами «Nginx» не имеет модуля аутентификации через LDAP.

Как вариант решения поставленной задачи, можно воспользоваться системных модулем «auth_pam», указав «Nginx» проводить аутентификацию через PAM несущей операционной системы («Linux» или xBSD), в которой настроена связка с LDAP. Лет пять назад разрабатывалась реализация в виде модуля «nginx-auth-ldap», но он устарел сейчас разработчики «Nginx» официально предлагают использовать другой подход, с промежуточным сервисом «nginx-ldap-auth-daemon».

Предлагаемая схема взаимодействий проста и прозрачна. Когда пользователь обращается к защищённому разделу сайта, web-сервер «Nginx» запрашивает посредством протокола «HTTP Basic authentication» логин и пароль. Полученные аутентификационные данные встроенным модулем «http_auth_request» сразу отправляются по протоколу проксирования фоновому web-сервису «LDAP Auth Daemon», который в свою очередь обращается к указанному в его настройках LDAP-серверу за подтверждением существования пользователя с предъявленными логином и паролем. Положительный или отрицательный ответ доставляется обратно по цепочке web-серверу «Nginx», который допускает или нет пользователя до запрашиваемого контента. Этот процесс красиво расписан в официальной документации.

Перейдём же к практике.

Установка «Nginx LDAP Auth Daemon».

Простенькое приложение-посредник написано на «Python», который почти всегда уже установлен:

# aptitude install python2.7-minimal python-ldap git

Загружаем дистрибутив «Nginx LDAP Auth Daemon»:

# cd /usr/src
# git clone https://github.com/nginxinc/nginx-ldap-auth

Копируем единственный нужный исполняемый файл в наиболее подходящее ему место в файловой системе:

# cp . /nginx-ldap-auth/nginx-ldap-auth-daemon.py /usr/local/bin/

Заготавливаем место для журналов событий (аутентификация дело ответственное):

# mkdir -p -m 740 /var/log/nginx-ldap-auth
# chown -R www-data /var/log/nginx-ldap-auth

Пробуем запустить приложение:

# cd /usr/local/bin
# LOG=/var/log/nginx-ldap-auth/daemon.log ./nginx-ldap-auth-daemon.py start

По умолчанию «Nginx LDAP Auth Daemon» прослушивает запросы только на «локальной сетевой петле», на обычно свободном порту, что меня полностью устраивает и освобождает от необходимости что-то настраивать:

# netstat -apn | grep -i python

tcp … 127.0.0.1:8888 0.0.0.0:* LISTEN …/python

Оставим пока приложение запущенным и перейдём к настройке web-сервера.

Настройка аутентификации через LDAP в «Nginx».

Принимая за данность, что web-сервер «Nginx» уже корректно настроен, дополним настройки конкретного сайта блоком параметров проксирования запросов аутентификации к «Nginx LDAP Auth Daemon»:

# vi /etc/nginx/sites-available/site. example.net.conf

….
server {
….

  # Перечисляем требования, которым должны удовлетворять пользователи сайта
  satisfy all;
  #
  # (пользователи из локальных сетей)
  allow 10.0.0.0/8;
  allow 172.16.0.0/12;
  allow 192.168.0.0/16;
  deny  all;
  #
  # (прошедшие аутентификацию)
  auth_request /auth-proxy;

  # Блок параметров запроса к «Nginx LDAP Auth Daemon»
  location = /auth-proxy {
    internal;
    proxy_pass_request_body off;
    proxy_set_header Content-Length «»;
    proxy_pass http://127.0.0.1:8888;
    proxy_set_header X-Ldap-URL «ldaps://ldap.example.net:636»;
    proxy_set_header X-Ldap-Template «(&(uid=%(username)s)(objectclass=person)(memberOf=cn=web-service-users,ou=groups,dc=example,dc=net))»;
    proxy_set_header X-Ldap-BaseDN «ou=People,dc=example,dc=net»;
    proxy_set_header X-Ldap-BindDN «uid=nginx-web-service,ou=Accounts,ou=Services,dc=example,dc=net»;
    proxy_set_header X-Ldap-BindPass «***»;
  }

. …
}
….

Конструкция «%(username)s» в примере выше используется для получения из набора внутренних переменных «Nginx» имени пользователя (логина), введённого в форму «HTTP Basic authentication».

Проверяем синтаксическую корректность конфигурации «Nginx» и применяем её:

# nginx -t && nginx -s reload

Сразу после запуска можно пробовать обращаться к закрытой части сайта и проверять, работает ли связка «Nginx», «Nginx LDAP Auth Daemon» и LDAP в соответствии с ожиданиями. Если что-то пошло не так, смотрим предусмотрительно заготовленный журнал событий.

Подключение к LDAP с «самоподписанным» SSL-сертификатом.

Почти наверняка LDAP-сервер, работающий только в локальной сети, для шифрования соединений будет предлагать «self-signed» SSL-сертификат. Типовое python-приложение доверяет сертификатам, размещённым в соответствующем хранилище несущей операционной системы, так что самым простым способом наладить связь будет добавление публичной части самодельного сертификата LDAP-сервиса в перечень «доверенных»:

# cp . /ss-rootCA.crt /usr/local/share/ca-certificates/
# update-ca-certificates

Последующая проверка (с несущего «Nginx LDAP Auth Daemon» сервера) не должна демонстрировать предупреждений о проблемах распознавания подписи SSL-сертификата целевого сервера:

$ echo QUIT | openssl s_client -connect ldap.exfmple.net:636 -CApath /etc/ssl/certs

О кешировании запросов аутентификации.

Аутентификация через «auth_request» в «Nginx» работает так, что на каждый запрос любого ресурса (даже мелкой картинки в составе страницы) генерируется внутреннее событие требования аутентификации, по которому отправляется запрос в промежуточную подсистему «ldap‑auth», которая в свою очередь обращается за подтверждением подлинности пользователя в LDAP. Таким образом на каждый запрос web-страницы создаётся от десятка до нескольких сотен подзапросов, в которых совершенно нет необходимости. Для снижения затрат ресурсов на такую непродуктивную деятельность в «Nginx» применяется кеширование.

Вначале на уровне глобальной конфигурации «Nginx» указываем желаемое месторасположение директории для файлов данных кешируемых запросов и максимальное время хранения таковых, а после в конфигурации сайта, для доступа к которому требуется аутентификация через LDAP, добавляем указание кешировать успешно завершённые запросы к подсистеме «ldap-auth» на срок до десяти минут:

# vi /etc/nginx/sites-available/site. example.net.conf

proxy_cache_path /var/lib/nginx/cache/ keys_zone=auth_cache:10m;
….
server {
….

  location = /auth-proxy {
    internal;
    proxy_cache auth_cache;
    proxy_cache_valid 200 10m;
    ….

# nginx -t && nginx -s reload

Настройка автозапуска «Nginx LDAP Auth Daemon» посредством «Systemd».

Ранее мы запустили приложение-прослойку вручную. Автоматизируем эту процедуру, описав подсистему аутентификации как постоянно работающий простой сервис:

# vi /etc/systemd/system/nginx-ldap-auth-daemon.service

[Unit]
Description=LDAP authentication helper for Nginx
After=network.target network-online.target

[Service]
Type=simple
User=www-data
Group=www-data
WorkingDirectory=/var/run
Environment=LOG=/var/log/nginx-ldap-auth/daemon.log
ExecStart=/usr/local/bin/nginx-ldap-auth-daemon.py
KillMode=process
KillSignal=SIGINT
Restart=on-failure

[Install]
WantedBy=multi-user. target

Указываем «Systemd» перечитать и принять новую конфигурацию, а также явно активируем и запускаем новый сервис:

# systemctl daemon-reload
# systemctl enable nginx-ldap-auth-daemon.service
# systemctl start nginx-ldap-auth-daemon

Журналы событий нам в помощь, если что-то работает не так, как задумывалось:

# systemctl status nginx-ldap-auth-daemon
# journalctl -xe

Наладка ротации журналов событий.

Выше упоминалось, что реализация аутентификации в «Nginx» склонна генерировать массу запросов, которые записываются в журнал событий. Если забыть об этом, то через полгода в файловой системе вырастет огромный ненужный файл. Заранее натравим на него подсистему усечения и оборота журналов:

# vi /etc/logrotate.d/nginx-ldap-auth-daemon

/var/log/nginx-ldap-auth/*.log {
  monthly
  rotate 12
  compress
  delaycompress
  missingok
  notifempty
  copytruncate
  su www-data www-data
}

Проверяем корректность конфигурации, не воздействуя при этом на файлы журналов:

# logrotate -d /etc/logrotate. d/nginx-ldap-auth-daemon

документов NGINX | Ограничение доступа с помощью базовой аутентификации HTTP

Введение

Вы можете ограничить доступ к своему веб-сайту или его частям, реализовав аутентификацию по имени пользователя и паролю. Имена пользователей и пароли берутся из файла, созданного и заполняемого инструментом создания файла паролей, например, apache2-utils .

Базовая аутентификация

HTTP также может быть объединена с другими методами ограничения доступа, например, ограничением доступа по IP-адресу или географическому положению.

Предварительные требования

NGINX Plus или NGINX с открытым исходным кодом
Утилита для создания файлов паролей, например apache2-utils (Debian, Ubuntu) или httpd-tools (RHEL / CentOS / Oracle Linux).

Создание файла паролей

Чтобы создать пары имя пользователя и пароль, используйте утилиту для создания файла паролей, например, apache2-utils или httpd-tools

Убедитесь, что установлено apache2-utils (Debian, Ubuntu) или httpd-tools (RHEL / CentOS / Oracle Linux).
Создайте файл паролей и первого пользователя. Запустите утилиту htpasswd с флагом -c (для создания нового файла), указав путь к файлу в качестве первого аргумента и имя пользователя в качестве второго аргумента:
```
 $ sudo htpasswd -c /etc/apache2/.htpasswd пользователь1
 
```
Нажмите Enter и введите пароль для user1 по запросу.
Создайте дополнительные пары пользователь-пароль. Опустите флаг -c , потому что файл уже существует:
```
 $ sudo htpasswd / etc / apache2 /.htpasswd user2
 
```

Вы можете подтвердить, что файл содержит парные имена пользователей и зашифрованные пароли:

 $ cat /etc/apache2/.htpasswd
user1: $ apr1 $ / woC1jnP $ KAh0SsVn5qeSMjTtn0E9Q0
user2: $ apr1 $ QdR8fNLT $ vbCEEzDj7LyqCMyNpSoBh /
user3: $ apr1 $ Mr5A0e.U $ 0j39Hp5FfxRkneklXaMrr /

Настройка NGINX и NGINX Plus для базовой аутентификации HTTP

Внутри области, которую вы собираетесь защищать, укажите директиву auth_basic и дайте имя защищенной паролем области. Имя области будет показано в диалоговом окне имени пользователя / пароля при запросе учетных данных:
```
 location / api {
    auth_basic «Администраторский кабинет»;
    # ...
}
 
```
Укажите директиву auth_basic_user_file с путем к файлу .htpasswd , который содержит пары пользователь / пароль:
```
 location / api {
    auth_basic «Администраторский кабинет»;
    auth_basic_user_file /etc/apache2/.htpasswd;
}
 
```

В качестве альтернативы вы можете ограничить доступ ко всему веб-сайту с помощью базовой аутентификации, но все же сделать некоторые области сайта общедоступными.В этом случае укажите параметр off в директиве auth_basic , которая отменяет наследование с верхних уровней конфигурации:

 server {
    ...
    auth_basic «Администраторский кабинет»;
    auth_basic_user_file conf / htpasswd;

    location / public / {
        auth_basic off;
    }
}

Сочетание базовой аутентификации с ограничением доступа по IP-адресу

Базовую аутентификацию

HTTP можно эффективно комбинировать с ограничением доступа по IP-адресу. Вы можете реализовать как минимум два сценария:

пользователь должен быть аутентифицирован и иметь действующий IP-адрес
пользователь должен быть аутентифицирован или иметь действующий IP-адрес

Разрешить или запретить доступ с определенных IP-адресов с помощью директив allow и deny :
```
 location / api {
    # ...
    отрицать 192.168.1.2;
    разрешить 192.168.1.1/24;
    разрешить 127.0.0.1;
    все отрицать;
}
 
```
Доступ будет предоставлен только для 192.168.1.1 / 24 сеть , за исключением адреса 192.168.1.2 . Обратите внимание, что директивы allow и deny будут применяться в том порядке, в котором они определены.
Совместное ограничение по IP и HTTP-аутентификации с соответствует директиве .
Если вы установите для директивы значение для всех , доступ предоставляется, если клиент удовлетворяет обоим условиям. Если вы установите для директивы значение любое , доступ предоставляется, если клиент удовлетворяет хотя бы одному условию:
```
 location / api {
    #...
    удовлетворить всех;

    отрицать 192.168.1.2;
    разрешить 192.168.1.1/24;
    разрешить 127.0.0.1;
    все отрицать;

    auth_basic «Администраторский кабинет»;
    auth_basic_user_file conf / htpasswd;
}
 
```

Полный пример

В примере показано, как защитить область состояния с помощью простой аутентификации в сочетании с ограничением доступа по IP-адресу:

 http {
    server {
        слушайте 192.168.1.23:8080;
        корень / usr / share / nginx / html;

        location / api {
            api;
            удовлетворить всех;

            Сказать 192.168.1.2;
            разрешить 192.168.1.1/24;
            разрешить 127.0.0.1;
            все отрицать;

            auth_basic «Администраторский кабинет»;
            auth_basic_user_file /etc/apache2/.htpasswd;
        }
    }
}

При переходе на страницу статуса вам будет предложено войти в систему:

Если предоставленное имя и пароль не совпадают с файлом паролей, вы получите ошибку 401 (требуется авторизация) .

Как настроить HTTP-аутентификацию с Nginx в Ubuntu 12.10

Что означает красный

Строки, которые пользователь должен ввести или настроить, будут в этом уроке красным! Остальные в основном должны быть скопированы и вставлены.

О Nginx

Nginx (произносится как «движок x») — это HTTP и обратный прокси-сервер, а также почтовый прокси-сервер, написанный Игорем Сысоевым, который является гибкой и легкой программой по сравнению с apache. Официальная документация nginx находится здесь.

Предварительные требования

В качестве предварительного условия мы предполагаем, что вы прочитали статью о том, как настроить свой VPS, а также установили на нем Nginx.Если нет, вы можете найти статью о настройке VPS в статье о начальной настройке сервера, а также дополнительную информацию об установке nginx в нашем сообществе.

Шаг 1. Apache Utils

Нам нужен htpasswd для создания и генерации зашифрованного файла для пользователя с использованием базовой аутентификации. Установите apache2-utils, используя команду ниже.

  sudo apt-get install apache2-utils

Шаг 2: Создайте пользователя и пароль

Создайте файл .htpasswd в каталоге вашего веб-сайта, обслуживаемого nginx.Следующая команда создаст файл, а также добавит в него пользователя и зашифрованный пароль.

  sudo htpasswd -c /etc/nginx/.htpasswd exampleuser

Инструмент предложит вам ввести пароль.

Новый пароль:
Введите повторно новый пароль:
Добавление пароля для пользователя exampleuser

Структура файла htpasswd будет такой:

логин Пароль

Обратите внимание, что этот htpasswd должен быть доступен учетной записи пользователя, на которой запущен Nginx.

Шаг 3. Обновите конфигурацию Nginx

Ваш файл конфигурации nginx для веб-сайта должен находиться в / etc / nginx / sites-available /. Добавьте две записи ниже для пути к домену, который вы хотите защитить.

    auth_basic «Ограничено»;
    auth_basic_user_file /etc/nginx/. htpasswd;

Вторая строка — это расположение файла htpasswd для вашего веб-сайта.

Например, предположим, что наш файл конфигурации nginx — это / etc / nginx / sites-available / website_nginx.conf откройте файл с помощью vi или любого другого редактора по вашему выбору.

  sudo vi /etc/nginx/sites-available/website_nginx.conf

Затем добавьте две строки в следующий путь:

 
 server {
  прослушивать номер порта;
  server_name ip_address;
  место расположения / {
      root /var/www/mywebsite.com;
      index index.html index.htm;
      auth_basic «Ограничено»; # For Basic Auth
      auth_basic_user_file / etc / nginx /.htpasswd; # For Basic Auth
  }
}

Шаг 4. Перезагрузите Nginx

Чтобы отразить изменения на нашем веб-сайте, перезагрузите конфигурацию nginx и попробуйте получить доступ к домену, который был защищен с помощью базовой проверки подлинности.

$ sudo /etc/init.d/nginx reload
* Перезагрузка конфигурации nginx . ..

Теперь попробуйте получить доступ к своему веб-сайту или пути к домену, который вы защитили, и вы увидите запрос браузера, в котором вас попросят ввести логин и пароль.Введите данные, которые вы использовали при создании файла .htpasswd. Запрос не позволяет вам получить доступ к веб-сайту, пока вы не введете правильные учетные данные.

И вуаля! У вас есть путь к домену вашего сайта, защищенный с помощью базовой аутентификации Nginx.

Как настроить базовую HTTP-аутентификацию с Nginx в Ubuntu 14.04

Введение

Nginx — один из ведущих активно используемых веб-серверов. Он и его коммерческая версия Nginx Plus разработаны Nginx, Inc.

В этом руководстве вы узнаете, как ограничить доступ к веб-сайту на базе Nginx, используя базовый метод аутентификации HTTP в Ubuntu 14.04. Базовая аутентификация HTTP — это простой метод аутентификации по имени пользователя и (хешированному) паролю.

Предварительные требования

Для выполнения этого руководства вам понадобится следующее:

Вам понадобится команда htpassword , чтобы настроить пароль, который будет ограничивать доступ к целевому веб-сайту. Эта команда является частью пакета apache2-utils , поэтому первым шагом является установка этого пакета.

    sudo apt-get install apache2-utils

Шаг 2. Настройка учетных данных базовой аутентификации HTTP

На этом шаге вы создадите пароль для пользователя, запустившего веб-сайт.

Этот пароль и соответствующее имя пользователя будут сохранены в указанном вами файле. Пароль будет зашифрован, а имя файла может быть любым. Здесь мы используем файл /etc/nginx/.htpasswd и имя пользователя nginx .

Чтобы создать пароль, выполните следующую команду. Вам нужно будет пройти аутентификацию, а затем указать и подтвердить пароль.

    sudo htpasswd -c /etc/nginx/.htpasswd nginx

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

Пример /etc/nginx/.htpasswd

  nginx: $ apr1 $ ilgq7ZEO $ OarDX15gjKAxuxzv0JTrO /

`Шаг 3. Обновление конфигурации Nginx`

Теперь, когда вы создали учетные данные для базовой аутентификации HTTP, следующим шагом будет обновление конфигурации Nginx для использования целевым веб-сайтом.

Базовая аутентификация HTTP стала возможной благодаря директивам auth_basic и auth_basic_user_file . Значение auth_basic — это любая строка, которая будет отображаться при запросе аутентификации; значение auth_basic_user_file — это путь к файлу паролей, который был создан на шаге 2.

Обе директивы должны быть в файле конфигурации целевого веб-сайта, который обычно находится в каталоге / etc / nginx / sites-available .Откройте этот файл с помощью nano или вашего любимого текстового редактора.

    sudo nano / etc / nginx / сайты-доступные / по умолчанию

В разделе location добавьте обе директивы:

/etc/nginx/sites-available/default. conf

 . . .
server_name localhost;

место расположения / {
        # Сначала пытаемся обработать запрос как файл, затем
        # в качестве каталога, затем вернитесь к отображению 404.
        try_files $ uri $ uri / = 404;
        # Раскомментируйте, чтобы включить naxsi в этом месте
        # включить / etc / nginx / naxsi.правила
        auth_basic «Частная собственность»;
        auth_basic_user_file /etc/nginx/.htpasswd;
}
. . .

Сохраните и закройте файл.

`Шаг 4 — Тестирование установки`

Чтобы применить изменения, сначала перезагрузите Nginx.

    sudo service nginx reload

Теперь попробуйте получить доступ к только что защищенному веб-сайту, перейдя по адресу http: // your_server_ip / в своем любимом браузере. Вам должно быть представлено окно аутентификации (в котором написано «Частная собственность», строка, которую мы установили для auth_basic ), и вы не сможете получить доступ к веб-сайту, пока не введете правильные учетные данные. Если вы введете заданные вами имя пользователя и пароль, вы увидите домашнюю страницу Nginx по умолчанию.

`Заключение`

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

`Модуль ngx_http_auth_request_module`

Модуль ngx_http_auth_request_module (1.5.4+) реализует авторизация клиента на основе результата подзапроса.Если подзапрос возвращает код ответа 2xx, доступ разрешен. Если он возвращает 401 или 403, доступ запрещен с соответствующим кодом ошибки. Любой другой код ответа, возвращенный подзапросом, считается ошибкой.

Для ошибки 401 клиент также получает Заголовок «WWW-Authenticate» из ответа на подзапрос.

Этот модуль не собирается по умолчанию, его нужно включить с помощью --with-http_auth_request_module параметр конфигурации.

Модуль можно комбинировать с другие модули доступа, такие как ngx_http_access_module, ngx_http_auth_basic_module, и ngx_http_auth_jwt_module, через директиву удовлетворения.

До версии 1.7.3 ответы на подзапросы авторизации нельзя было кэшировать. (используя proxy_cache, proxy_store и т. д.).

`Пример конфигурации`

location / private / {
    auth_request / auth;
    ...
}

location = / auth {
    proxy_pass ...
    proxy_pass_request_body off;
    proxy_set_header Content-Length "";
    proxy_set_header X-Original-URI $ request_uri;
}

`Директивы`

Синтаксис:	`auth_request uri \| от ;`
Дефолт:	auth_request off;
Контекст:	`http` , `сервер` , `расположение`

Включает авторизацию на основе результата подзапроса и устанавливает URI, на который будет отправлен подзапрос.

Синтаксис:	`auth_request_set $ переменная значение ;`
Дефолт:	—
Контекст:	`http` , `сервер` , `расположение`

Устанавливает для переменной запроса заданное значение значение после завершения запроса авторизации.Значение может содержать переменные из запроса авторизации, например $ upstream_http_ * .

`Как настроить базовую HTTP-аутентификацию в Nginx`

Базовая HTTP-аутентификация — это механизм безопасности для ограничения доступа к вашему веб-сайту / приложению или некоторым его частям путем настройки простой аутентификации по имени пользователя и паролю. Его можно использовать по существу для защиты всего HTTP-сервера, отдельных блоков сервера (виртуальных хостов в Apache) или блоков местоположения.

Читайте также : Как настроить виртуальные хосты на основе имен и IP (серверные блоки) с NGINX

Как следует из названия, полагаться на этот метод небезопасно; вы должны использовать его вместе с другими более надежными мерами безопасности.Например, если ваше веб-приложение работает по протоколу HTTP, учетные данные пользователя передаются в виде обычного текста, поэтому вам следует рассмотреть возможность включения HTTPS.

Цель этого руководства — помочь вам добавить небольшой, но полезный уровень безопасности для защиты частного / привилегированного контента в ваших веб-приложениях (таких как, но не ограничиваясь, стороны администратора). Вы также можете использовать его для предотвращения доступа к веб-сайту или приложению, которое все еще находится на стадии разработки.

`Требования`

Установить стек LEMP в CentOS / RHEL 7
Установите стек LEMP в Ubuntu / Debian

`Создать файл пользователя HTTP-аутентификации`

Вы должны начать с создания файла, в котором будет храниться пар имя пользователя: пароль . Для создания этого файла мы воспользуемся утилитой htpasswd от Apache HTTP Server.

Сначала убедитесь, что в вашей системе установлены пакеты apache2-utils или httpd-tools , которые предоставляют утилиту htpasswd , в противном случае выполните соответствующую команду для вашего дистрибутива, чтобы установить ее:

 # yum install httpd-tools [RHEL / CentOS]
$ sudo apt install apache2-utils [Debian / Ubuntu]

Затем запустите команду htpasswd ниже, чтобы создать файл паролей для первого пользователя.Параметр -c используется для указания файла passwd. Как только вы нажмете [Enter] , вам будет предложено ввести пароль пользователя.

 # htpasswd -c /etc/nginx/conf.d/.htpasswd разработчик

Добавьте второго пользователя и не используйте здесь опцию -c .

 # htpasswd /etc/nginx/conf.d/.htpasswd admin

Теперь, когда у вас есть готовый файл паролей, переходите к настройке частей вашего веб-сервера, к которым вы хотите ограничить доступ. Чтобы просмотреть содержимое файла паролей (включая имена пользователей и зашифрованные пароли), используйте команду cat ниже.

 # cat /etc/nginx/conf.d/.htpasswd

Просмотр файла паролей HTTP

`Настройка аутентификации HTTP для Nginx`

Как мы упоминали ранее, вы можете ограничить доступ к своему веб-серверу, отдельному веб-сайту (используя его серверный блок) или директиве местоположения. Для этого можно использовать две полезные директивы.

auth_basic — включает проверку имени пользователя и пароля по протоколу « HTTP Basic Authentication ».
auth_basic_user_file — указывает файл паролей.

`Защита паролем виртуальных хостов Nginx`

Чтобы реализовать базовую аутентификацию для всего веб-сервера, которая применяется ко всем блокам сервера, откройте файл /etc/nginx/nginx.conf и добавьте следующие строки в контекст http:

 http {
auth_basic «Ограниченный доступ!»;
    auth_basic_user_file /etc/nginx/conf. d/.htpasswd;
…… ...
}

`Защита паролем веб-сайта или домена Nginx`

Чтобы включить базовую аутентификацию для определенного домена или субдомена, откройте его файл конфигурации в / etc / nginx / conf.d / или / etc / nginx / conf / sites-available (в зависимости от того, как вы установили Nginx), затем добавьте конфигурацию ниже в серверный блок или контекст:

 server {
слушать 80;
имя_сервера example.com;
auth_basic «Ограниченный доступ!»;
    auth_basic_user_file /etc/nginx/conf.d/.htpasswd;
место расположения /  {
…… ..
}
…… ...
}

`Защита паролем веб-каталога в Nginx`

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

 server {
слушать 80;
имя_сервера example.com www.example.com;

место расположения / {
…… . .
}
location  / admin /  {
auth_basic «Ограниченный доступ!»;
    auth_basic_user_file /etc/nginx/conf.d/.htpasswd;
}

location / public / {
auth_basic off; # отключает базовую HTTP-аутентификацию для этого блока
}
……..
}

Если вы настроили базовую HTTP-аутентификацию, у всех пользователей, которые попытаются получить доступ к вашему веб-серверу, субдомену или определенной части сайта (в зависимости от того, где вы это реализовали), будет запрошено имя пользователя и пароль, как показано на снимке экрана. ниже.

Nginx Basic Authentication

В случае неудачной аутентификации пользователя отобразится ошибка « 401 Требуется авторизация », как показано ниже.

401 Требуется авторизация. Ошибка

. Дополнительные сведения см. В разделе «Ограничение доступа с помощью обычной проверки подлинности HTTP».

Вы также можете прочитать следующие полезные руководства по HTTP-серверу Nginx.

Как защитить паролем веб-каталоги в Nginx
Полное руководство по защите, укреплению и повышению производительности Nginx
Настройка HTTPS с помощью SSL-сертификата Let’s Encrypt для Nginx

В этом руководстве мы показали, как реализовать базовую HTTP-аутентификацию на веб-сервере Nginx HTTP. Чтобы задать любые вопросы, воспользуйтесь формой обратной связи ниже.

`Если вы цените то, что мы делаем здесь, на TecMint, вам следует принять во внимание:`

TecMint — это самый быстрорастущий и пользующийся наибольшим доверием сайт сообщества, где можно найти любые статьи, руководства и книги по Linux в Интернете.Миллионы людей посещают TecMint! для поиска или просмотра тысяч опубликованных статей доступны БЕСПЛАТНО для всех.

Если вам нравится то, что вы читаете, пожалуйста, купите нам кофе (или 2) в знак признательности.

Мы благодарны за вашу бесконечную поддержку.

`Как настроить HTTP-аутентификацию (базовую) с Nginx в Ubuntu 16.04`

Ограничение частей веб-приложения или каталогов на веб-сервере небольшой группой доверенных пользователей может значительно повысить безопасность веб-сайта или веб-приложения.Большинство веб-приложений предоставляют свои собственные методы аутентификации на основе форм, однако мы также можем использовать встроенные возможности HTTP-аутентификации веб-сервера, когда аутентификация по форме не реализована или недостаточна.

В этом практическом руководстве мы будем защищать ресурсы на веб-сервере Nginx, работающем в Ubuntu 16.04. Дополнительные советы по укреплению Nginx можно найти в нашей серии статей по укреплению Nginx, состоящей из двух частей.

`Начало работы`

Для начала вам понадобится Ubuntu 16.04 серверная среда, а также установлен Nginx.

Если вы еще не установили Nginx, вы можете сделать это, выполнив следующие две команды.

 sudo apt update
sudo apt установить nginx

Чтобы убедиться, что Nginx установлен и запущен, выполните следующую команду. Он должен вернуть что-то похожее на вывод ниже.

 sudo service nginx status

-> ● nginx.service - высокопроизводительный веб-сервер и обратный прокси-сервер.
Загружен: загружен (/ lib / systemd / system / nginx.служба; включено; предустановка поставщика: включена)
Активен: активен (работает) с среды 2016-08-03 09:42:19 UTC; 2мин 38с назад
Основной PID: 12947 (nginx)
CGroup: /system. slice/nginx.service
├─12947 nginx: главный процесс / usr / sbin / nginx -g демон включен; master_process на
├─12948 nginx: рабочий процесс
└─12949 nginx: рабочий процесс

03 августа, 09:42:19 ubuntu-xenial systemd [1]: Запуск высокопроизводительного веб-сервера и обратного прокси-сервера ...
03 августа, 09:42:19 ubuntu-xenial systemd [1]: запущен Высокопроизводительный веб-сервер и обратный прокси-сервер.

`Создание файла паролей`

Чтобы настроить HTTP-аутентификацию с помощью Nginx, нам нужно сохранить комбинацию имен пользователей и хешированных паролей в файле. Чтобы сгенерировать этот файл, мы можем использовать OpenSSL (который уже должен быть автоматически установлен в вашей системе).

Heads up — Если вы переносите существующую установку HTTP-сервера Apache на Nginx, вы обычно можете сохранить один и тот же файл, поскольку Nginx и HTTP-сервер Apache используют один и тот же формат пароля (APR1).Вы также можете использовать специальную утилиту htpasswd из пакета apache2-utils , если вы предпочитаете ее OpenSSL.

Мы начнем с создания файла с именем .htpasswd в / etc / nginx , который является каталогом конфигурации Nginx по умолчанию для хранения наших комбинаций имени пользователя и пароля.

Вы можете добавить имена пользователей в .htpasswd , выполнив следующую команду. Мы выбрали имя пользователя alice , разумеется, измените его в соответствии со своими требованиями.

 sudo bash -c "echo -n 'alice:' >> /etc/nginx/.htpasswd"

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

 sudo bash -c "openssl passwd -apr1 >> /etc/nginx/.htpasswd"

-> Пароль:
Проверка - Пароль:

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

 кот /etc/nginx/.htpasswd

-> Алиса: $ apr1 $ rxVhn96T $ nm0 / ZD4J0w9xv6rDvYQ36 /

`Настройка HTTP-аутентификации Nginx`

Предупреждение — При HTTP / базовой аутентификации учетные данные не зашифрованы, , поскольку они передаются между клиентом и сервером. Следовательно, небезопасно использовать HTTP-аутентификацию , если соединение не зашифровано с помощью TLS .

После создания файла .htpasswd мы можем настроить Nginx для просмотра этого файла перед обслуживанием содержимого в определенном каталоге.

Мы будем настраивать конфигурацию сайта по умолчанию , поскольку она устанавливается через пакет Ubuntu Nginx. Если вы установили Nginx из другого пакета или самостоятельно скомпилировали его из исходного кода, путь ниже может быть другим.

 судо нано / и т. Д. / Nginx / сайты-включены / по умолчанию

Прежде чем что-либо ограничивать, вам нужно решить, что вы хотите ограничить. Nginx здесь очень гибкий и позволяет ограничить доступ ко всему серверу (следовательно, ваша конфигурация должна находиться в блоке сервера конфигурации) или в определенном месте (следовательно, ваша конфигурация должна находиться в блоке location конфигурации).

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

Чтобы добиться этого, мы будем использовать директиву Nginx auth_basic , чтобы обеспечить соблюдение этого ограничения.Нам нужно будет указать имя области , которое будет отображаться пользователю, пытающемуся пройти аутентификацию. Мы будем использовать директиву auth_basic_user_file , чтобы направить Nginx в файл .htpasswd , который мы создали ранее.

  сервер {
слушаем 80 default_server;
слушать [::]: 80 default_server;

корень / вар / www / html;
индекс index. html index.htm index.nginx-debian.html;

server_name localhost;

место расположения / {
try_files $ uri $ uri / = 404;
}

location / private {
try_files $ uri $ uri / = 404;
auth_basic «Зона ограниченного доступа»;
auth_basic_user_file / etc / nginx /.htpasswd;
}
}

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

 sudo service nginx перезапуск

Вот и все! Теперь все, что находится в частном каталоге, теперь должно требовать HTTP-аутентификации, прежде чем веб-сервер обслужит клиента с запрошенным ресурсом.

`Тестирование`

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

Страница с ограничениями отображается только в том случае, если введены правильные учетные данные.

В противном случае мы получаем ответ HTTP 401, сообщающий нам, что нам требуется авторизация для просмотра запрошенного ресурса.

Получайте последнюю информацию о веб-безопасности в свой почтовый ящик каждую неделю.

`АВТОР`

Ян Маскат

Разработчики и технические агенты Acunetix регулярно вносят вклад в блог.Все разработчики Acunetix имеют многолетний опыт работы в сфере веб-безопасности.

`Использование nginx для добавления аутентификации в любое приложение`

Вы когда-нибудь обнаруживали, что хотите поместить приложение за формой входа в систему, но боитесь написать весь этот код для работы с OAuth 2.0 или паролями? В этом руководстве я покажу вам, как использовать модуль nginx auth_request для защиты любого приложения, работающего за вашим сервером nginx, с помощью OAuth 2.0, без написания кода! Vouch, микросервис, написанный на Go, обрабатывает танец OAuth для любого количества различных провайдеров аутентификации, поэтому вам не придется это делать.

Совет: Если вы хотите добавить логин (и авторизацию на основе URL-адреса) к большему количеству приложений через пользовательский интерфейс, интегрировать их с более сложными приложениями, такими как Oracle или SAP, или заменить устаревшую систему единого входа на месте, проверьте шлюз Okta Access. .

`Зачем нужна аутентификация на веб-сервере?`

Представьте, что вы используете nginx для запуска небольшой частной вики для своей команды.Сначала вы, вероятно, начнете с добавления учетной записи пользователя вики для каждого человека. Это не так уж и плохо — добавлять новые аккаунты для новых сотрудников и удалять их, когда они уходят.

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

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

На этом этапе, когда кто-то новый присоединяется, вы должны создать для него вики-аккаунт, добавить его в организацию GitHub и дать им общий пароль для другой системы. Когда кто-то уходит, вы можете удалить его вики-аккаунт и удалить его из GitHub, но давайте посмотрим правде в глаза, вы, вероятно, не будете менять общий пароль какое-то время, так как необходимость снова распространять его среди всех раздражает.

Конечно, должен быть лучший способ интегрировать все эти системы для использования общей системы общего входа! Проблема в том, что вики написана на PHP, система мониторинга сервера просто публикует папку статического HTML, а система CI написана на Ruby, писать которую может только один человек в вашей команде.

Если бы веб-сервер мог обрабатывать аутентификацию пользователей, то каждой бэкэнд-системе не нужно было бы беспокоиться об этом, поскольку единственные запросы, которые могли бы пройти, уже были бы аутентифицированы!

`Использование модуля nginx auth_request`

Введите модуль nginx auth_request .

Этот модуль поставляется с nginx, но требует включения при компиляции nginx. Когда вы загружаете исходный код nginx и компилируете, просто включите флаг --with-http_auth_request_module вместе с любыми другими, которые вы используете.

Модуль auth_request находится между Интернетом и вашим внутренним сервером, на который nginx передает запросы, и каждый раз, когда поступает запрос, он сначала перенаправляет запрос на отдельный сервер, чтобы проверить, аутентифицирован ли пользователь, и использует ответ HTTP. чтобы решить, разрешить ли передачу запроса на серверную часть.

На этой диаграмме показан запрос, который поступает для имени сервера stats.avocado.lol . Сначала nginx запускает подзапрос на login.avocado.lol (1), и если ответ (2) на этот запрос возвращает HTTP 200, он затем продолжает пересылку запроса на бэкэнд stats.avocado. ржунимагу.

`Выбор прокси для аутентификации`

Поскольку модуль nginx auth_request не имеет понятия о пользователях или способах аутентификации кого-либо, нам нужно что-то еще в этом миксе, которое действительно может обрабатывать вход пользователей в систему.На диаграмме выше это проиллюстрировано именем сервера login.avocado.lol .

Этот сервер должен обрабатывать HTTP-запрос и возвращать HTTP 200 или 401 в зависимости от того, вошел ли пользователь в систему. Если пользователь не вошел в систему, ему необходимо знать, как заставить их войти в систему и установить cookie сеанса.

Для этого мы воспользуемся проектом с открытым исходным кодом Vouch. Vouch написан на Go, поэтому его очень легко развернуть. Все можно настроить с помощью одного файла YAML.Vouch можно настроить для аутентификации пользователей через различные серверные части OAuth и OpenID Connect, такие как GitHub, Google, Okta или любые другие настраиваемые серверы.

Мы вернемся к настройке Vouch через несколько минут, а пока давайте продолжим настройку защищенного сервера в nginx.

`Настройте защищенный хост nginx`

Начиная с типичного серверного блока nginx, вам просто нужно добавить пару строк, чтобы включить модуль auth_request . Вот пример серверного блока, который должен быть похож на вашу собственную конфигурацию.В этом примере просто обслуживается папка со статическими HTML-файлами, но та же идея применима независимо от того, передаете ли вы запрос в серверную часть fastcgi или используете proxy_pass .

  сервер {
  прослушать 443 ssl http2;
  имя_сервера stats.avocado.lol;

  ssl_certificate /etc/letsencrypt/live/avocado.lol/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/avocado.lol/privkey.pem;

  корень /web/sites/stats.avocado.lol;

  index index.html;
}

Добавьте следующее к существующему блоку server :

  # Любой запрос к этому серверу сначала будет отправлен на этот URL
auth_request / vouch-validate;

location = / vouch-validate {
  # Это адрес, по которому Вач будет слушать
  proxy_pass http: // 127.0.0.1: 9090 / проверить;
  proxy_pass_request_body off; # не нужно отправлять тело POST

  proxy_set_header Content-Length "";
  proxy_set_header X-Real-IP $ remote_addr;
  proxy_set_header X-Forwarded-For $ proxy_add_x_forwarded_for;
  proxy_set_header Схема X-Forwarded-Proto $;

  # эти возвращаемые значения передаются вызову @ error401
  auth_request_set $ auth_resp_jwt $ upstream_http_x_vouch_jwt;
  auth_request_set $ auth_resp_err $ upstream_http_x_vouch_err;
  auth_request_set $ auth_resp_failcount $ upstream_http_x_vouch_failcount;
}

error_page 401 = @ error401;

# Если пользователь не вошел в систему, перенаправьте его на URL-адрес входа в Vouch
location @ error401 {
  вернуть 302 https: // логин.avocado.lol/login?url=https://$http_host$request_uri&vouch-failcount=$auth_resp_failcount&X-Vouch-Token=$auth_resp_jwt&error=$auth_resp_err;
}

Давайте посмотрим, что здесь происходит. Первая строка, auth_request / vouch-validate; — вот что обеспечивает этот поток. Это сообщает модулю auth_request сначала отправлять любой запрос по этому URL-адресу, прежде чем решить, разрешено ли ему продолжить работу с внутренним сервером.

Блок location = / vouch-validate захватывает этот URL и передает его на сервер Vouch, который будет прослушивать порт 9090.Нам не нужно отправлять тело POST в Vouch, поскольку все, что нас действительно волнует, — это файлы cookie.

Строка error_page 401 = @ error401; сообщает nginx, что делать, если Vouch возвращает ответ HTTP 401, который должен передать его в блок, определенный как location @ error401 . Этот блок перенаправит браузер пользователя на URL-адрес входа Vouch, который запустит поток к реальному серверу аутентификации.

`Настроить серверный блок для поручения`

Затем настройте новый блок сервера для Vouch, чтобы он имел общедоступный URL-адрес, например https: // login.avocado.lol . Все, что для этого нужно, — это проксировать запрос на внутренний Vouch-сервер.

  сервер {
  слушайте 443 ssl;
  имя_сервера login.avocado.lol;

  ssl_certificate /etc/letsencrypt/live/login.avocado.lol/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/login.avocado.lol/privkey.pem;

  # Прокси для вашего экземпляра Vouch
  место расположения / {
    proxy_set_header Host login.avocado.lol;
    proxy_set_header X-Forwarded-Proto https;
    proxy_pass http: //127.0.0.1: 9090;
  }
}

`Настройка и развертывание Vouch`

Вам необходимо скачать Vouch и скомпилировать двоичный файл Go для своей платформы. Вы можете следовать инструкциям в файле README проекта.

После того, как у вас есть двоичный файл, вам нужно будет создать файл конфигурации, чтобы определить способ аутентификации пользователей Vouch.

Скопируйте config / config.yml_example в config / config.yml и прочтите там настройки. Большинство значений по умолчанию подойдут, но вам нужно создать свою собственную секретную строку JWT и заменить значение заполнителя your_random_string .

Самый простой способ настроить Vouch — разрешить любому пользователю, который может пройти аутентификацию на сервере OAuth, получить доступ к бэкэнду. Это отлично работает, если вы используете частный сервер OAuth, например Okta, для управления пользователями. Идите вперед и установите allowAllUsers: true , чтобы включить это поведение, и закомментируйте domains: chunk.

Вам нужно выбрать поставщика OAuth 2.0, который будет использоваться для фактической аутентификации пользователей. В этом примере мы будем использовать Okta, поскольку это самый простой способ получить полный сервер OAuth / OpenID Connect и иметь возможность управлять всеми своими учетными записями пользователей с единой панели управления.Прежде чем вы сможете завершить заполнение файла конфигурации, вам необходимо зарегистрировать учетную запись разработчика Okta на сайте developer.okta.com/. После создания учетной записи щелкните Applications в верхнем меню и создайте новое приложение. Выберите Web в качестве платформы приложения.

На следующем экране вам нужно настроить базовый URI и URI перенаправления входа в соответствии с настройками вашего собственного сервера. URI перенаправления Vouch оканчивается на / auth , поэтому ваша конфигурация должна выглядеть, как на скриншоте ниже.

Как только вы это сделаете, Okta предоставит вам идентификатор клиента и секрет, которые вам нужно будет включить в файл конфигурации.

config.yml

  oauth:
  провайдер: oidc
  client_id: {yourClientID}
  client_secret: {yourClientSecret}
  auth_url: https: // {yourOktaDomain} / oauth3 / default / v1 / authorize
  token_url: https: // {yourOktaDomain} / oauth3 / default / v1 / token
  user_info_url: https: // {yourOktaDomain} / oauth3 / default / v1 / userinfo
  объемы:
    - openid
    - электронное письмо
  # Установите URL-адрес обратного вызова для домена, на котором работает Vouch
  callback_url: https: // логин.avocado.lol/auth

Теперь вы можете запустить Vouch! Он будет прослушивать порт 9090, на котором вы настроили nginx для отправки проверок auth_request , а также для обслуживания трафика с login.avocado.lol .

Когда вы перезагружаете конфигурацию nginx, все запросы к stats.avocado.lol потребуют, чтобы вы сначала авторизовались через Okta!

`Бонус: Кто вошел в систему?`

Если вы размещаете динамическое веб-приложение за nginx и вас волнует не только , смог ли кто-то войти в систему , но и , кто они , есть еще один прием, который мы можем использовать.

По умолчанию Vouch извлекает идентификатор пользователя через OpenID Connect (или GitHub или Google, если вы настроили их в качестве поставщиков аутентификации) и включает этот идентификатор пользователя в HTTP-заголовок, который передается обратно на главный сервер.

В главном серверном блоке чуть ниже строки auth_request / vouch-validate; , который включает модуль auth_request , добавьте следующее:

  auth_request_set $ auth_user $ upstream_http_x_vouch_user;

Это возьмет заголовок HTTP, который устанавливает Vouch, X-Vouch-User , и назначит его переменной nginx $ auth_user .Затем, в зависимости от того, используете ли вы fastcgi или proxy_pass, включите одну из двух строк ниже в свой серверный блок:

  fastcgi_param REMOTE_USER $ auth_user;
proxy_set_header Удаленный пользователь $ auth_user;

Они установят заголовок HTTP со значением $ auth_user , который ваш внутренний сервер может прочитать, чтобы узнать, кто вошел в систему. Например, в PHP вы можете получить доступ к этим данным, используя:

Теперь вы можете быть уверены, что к вашему внутреннему приложению могут получить доступ только авторизованные пользователи!

`Узнайте больше об OAuth 2.0 и безопасном управлении пользователями с помощью Okta`

Для получения дополнительной информации и руководств по OAuth 2.0 ознакомьтесь с некоторыми другими сообщениями в нашем блоге!

Как всегда, мы будем рады услышать от вас об этом посте или о чем-нибудь еще! Напишите нам в комментариях или на Twitter @oktadev!

История изменений:

17 мая 2019 г . No related posts.

Share :

Апрель 2024
Пн	Вт	Ср	Чт	Пт	Сб	Вс
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30

Nginx авторизация http: HTTP авторизация Nginx

HTTP авторизация Nginx

Ограничение доступа с помощью HTTP basic authentication

Создание файла с ключами

Настройка Nginx

Настройка Apache

Файл .htaccess

Результат

Ссылки

Модуль ngx_http_auth_request_module

Модуль ngx_http_auth_request_module

Пример конфигурации

Директивы

basic авторизация с капчей / Хабр

Jenkins/Nginx-двойной запрос на базовую аутентификацию, почему? Почему существует внутренний Jenkins auth?

2 ответа

Похожие вопросы:

Nginx + LDAP авторизация : DevOps: servers abuse

Задача

Сервер авторизации

LDAP — Nginx + LDAP Auth

документов NGINX | Ограничение доступа с помощью базовой аутентификации HTTP

Введение

Предварительные требования

Создание файла паролей

Настройка NGINX и NGINX Plus для базовой аутентификации HTTP

Сочетание базовой аутентификации с ограничением доступа по IP-адресу

Полный пример

Как настроить HTTP-аутентификацию с Nginx в Ubuntu 12.10

Что означает красный

О Nginx

Предварительные требования

Шаг 1. Apache Utils

Шаг 2: Создайте пользователя и пароль

Шаг 3. Обновите конфигурацию Nginx

Шаг 4. Перезагрузите Nginx

Как настроить базовую HTTP-аутентификацию с Nginx в Ubuntu 14.04

Введение

Предварительные требования

Шаг 2. Настройка учетных данных базовой аутентификации HTTP

Шаг 3. Обновление конфигурации Nginx

Шаг 4 — Тестирование установки

Заключение

Модуль ngx_http_auth_request_module

Модуль ngx_http_auth_request_module

Пример конфигурации

Директивы

Как настроить базовую HTTP-аутентификацию в Nginx

Требования

Создать файл пользователя HTTP-аутентификации

Настройка аутентификации HTTP для Nginx

Защита паролем виртуальных хостов Nginx

Защита паролем веб-сайта или домена Nginx

Защита паролем веб-каталога в Nginx

Если вы цените то, что мы делаем здесь, на TecMint, вам следует принять во внимание:

Как настроить HTTP-аутентификацию (базовую) с Nginx в Ubuntu 16.04

Начало работы

Создание файла паролей

Настройка HTTP-аутентификации Nginx

Тестирование

АВТОР

Использование nginx для добавления аутентификации в любое приложение

Зачем нужна аутентификация на веб-сервере?

Использование модуля nginx auth_request

Выбор прокси для аутентификации

Настройте защищенный хост nginx

Настроить серверный блок для поручения

Настройка и развертывание Vouch

Бонус: Кто вошел в систему?

Узнайте больше об OAuth 2.0 и безопасном управлении пользователями с помощью Okta

Добавить комментарий Отменить ответ

`Шаг 3. Обновление конфигурации Nginx`

`Шаг 4 — Тестирование установки`

`Заключение`

`Модуль ngx_http_auth_request_module`

`Модуль ngx_http_auth_request_module`

`Пример конфигурации`

`Директивы`

`Как настроить базовую HTTP-аутентификацию в Nginx`

`Требования`

`Создать файл пользователя HTTP-аутентификации`

`Настройка аутентификации HTTP для Nginx`

`Защита паролем виртуальных хостов Nginx`

`Защита паролем веб-сайта или домена Nginx`

`Защита паролем веб-каталога в Nginx`

`Если вы цените то, что мы делаем здесь, на TecMint, вам следует принять во внимание:`

`Как настроить HTTP-аутентификацию (базовую) с Nginx в Ubuntu 16.04`

`Начало работы`

`Создание файла паролей`

`Настройка HTTP-аутентификации Nginx`

`Тестирование`

`АВТОР`

`Использование nginx для добавления аутентификации в любое приложение`

`Зачем нужна аутентификация на веб-сервере?`

`Использование модуля nginx auth_request`

`Выбор прокси для аутентификации`

`Настройте защищенный хост nginx`

`Настроить серверный блок для поручения`

`Настройка и развертывание Vouch`

`Бонус: Кто вошел в систему?`

`Узнайте больше об OAuth 2.0 и безопасном управлении пользователями с помощью Okta`

`Добавить комментарий Отменить ответ`