Как да конфигурирате Authelia с Nginx Proxy Manager стъпка по стъпка

Когато хоствате свои собствени приложения, е обичайно да имате множество табла за управление, файлови мениджъри и вътрешни услуги, достъпни чрез различни поддомейни. Nginx Proxy Manager улеснява публикуването на тези приложения и управлението на HTTPS сертификати, но не може да поправи нито една HTTPS уязвимост. слабо или липсващо удостоверяване в услугата по местоназначение.

Authelia добавя бариера към тези приложения. Преди да предостави достъп, тя може да изисква потребителско име, парола и втори фактор за удостоверяване. Комбинацията от Authelia с Nginx Proxy Manager Това позволява централизиране на достъпа, без да е необходимо да се модифицира всяко защитено приложение.

Тази система е особено полезна за подобряване на сигурността на уеб приложенията самостоятелно хоствани, при условие че директният достъп до техните вътрешни портове също е затворен.

Как Authelia работи с Nginx Proxy Manager

В тази интеграция, Nginx Proxy Manager остава единственият компонент, който получава публични връзки. Когато някой се опита да отвори защитено приложение, Nginx извършва заявка за вътрешно оторизиране към Аутелия.

Ако потребителят вече има валидна сесия и отговаря на съответната политика, Nginx доставя приложението. Ако не е удостоверен, той се пренасочва към портала на Authelia. След въвеждане на идентификационните си данни и, където е приложимо, TOTP кода, той автоматично се връща към заявената услуга.

Маршрутът е следният:

1. Посетителят отваря https://app.example.com.
2. Nginx Proxy Manager отправя заявки към Authelia.
3. Authelia проверява сесията и политиката за достъп.
4. Потребителят се удостоверява в https://auth.example.com.
5. Nginx позволява достъп до вътрешното приложение.

Този механизъм се нарича пренасочено удостоверяванеТова не бива да се бърка с OpenID Connect: в този случай крайното приложение не е необходимо директно да интегрира доставчик на идентичност.

Какво ви е необходимо, преди да започнете

За да завършите настройката, ще ви е необходимо:

• Функционална инсталация на Nginx прокси мениджър.
• Docker и Docker Compose са инсталирани на сървъра.
• Един домейн и два поддомейна, например auth.example.com y app.example.com.
• DNS записи, които насочват и двата поддомейна към проксито.
• Валиден HTTPS сертификат за всеки домейн.
• Споделена Docker мрежа между Nginx Proxy Manager, Authelia и защитените приложения.
• Вътрешно приложение, което не е директно достъпно от интернет.

Използването на HTTPS не е по избор. Authelia изисква защитени бисквитки и всички приложения, защитени от Forward Auth, трябва да ги използват. HTTPS или WSS в публичното си обръщение.

Как да създадете споделена мрежа и да затворите вътрешни портове

Създайте външна мрежа, която различните Docker Compose файлове могат да споделят:

docker network create proxy

След това свържете Nginx Proxy Manager, Authelia и защитените приложения към тази мрежа:

networks:
  proxy:
    external: true

Основно определение на контейнера Authelia може да изглежда така:

services:
  authelia:
    image: authelia/authelia:latest
    container_name: authelia
    restart: unless-stopped
    volumes:
      - ./config:/config
    expose:
      - "9091"
    networks:
      - proxy
    environment:
      TZ: Europe/Madrid

networks:
  proxy:
    external: true

Директивата expose Документира порта, използван в мрежата, но Не е това, което пречи на външния достъпНаистина важната мярка е да не се включва раздел ports нито за Authelia, нито за защитени приложения.

Само Nginx Proxy Manager трябва да рекламира портове 80 и 443. Вашият порт за управление, обикновено 81, трябва да бъде ограничен до локалната мрежа, VPN или адреси, оторизирани през защитната стена.

В производството е препоръчително също да се замени latest за конкретна тествана от вас версия, като по този начин се избягват неочаквани актуализации.

Как да настроите Authelia

Вътре в папката, монтирана като /config, създава файла configuration.ymlЗа самостоятелна инсталация можете да използвате SQLite и доставчика на сесии в паметта:

identity_validation:
  reset_password:
    jwt_secret: 'CAMBIA_ESTE_SECRETO_JWT'

authentication_backend:
  file:
    path: '/config/users_database.yml'

access_control:
  default_policy: 'deny'
  rules:
    - domain: 'app.example.com'
      policy: 'two_factor'

session:
  secret: 'CAMBIA_ESTE_SECRETO_DE_SESION'
  cookies:
    - domain: 'example.com'
      authelia_url: 'https://auth.example.com'
      default_redirection_url: 'https://app.example.com'

storage:
  encryption_key: 'CAMBIA_ESTA_CLAVE_DE_CIFRADO'
  local:
    path: '/config/db.sqlite3'

notifier:
  filesystem:
    filename: '/config/notification.txt'

Промяна example.com от вашия действителен домейн. В текущата конфигурация на Authelia, „бисквитките“ са декларирани в session.cookiesи authelia_url Трябва да съдържа пълния HTTPS адрес на портала.

Генерира независими случайни стойности за JWT секрета, сесията и криптирането на съхранението:

docker run --rm authelia/authelia:latest authelia crypto rand --length 64 --charset alphanumeric

Изпълнете командата три пъти и не използвайте повторно една и съща стойност. За чувствителни среди е за предпочитане тези данни да се запазят с помощта на Тайните на Докер или секретни файлове с ограничени разрешения.

Файловият известител е полезен по време на тестване, защото запазва лог файловете и връзките за възстановяване в notification.txtЗа производствена среда трябва да конфигурирате SMTP. Authelia поддържа само SMTP. активен доставчик на известия и двете.

Redis също не е необходим в това внедряване. Съхранението на сесии в паметта е достатъчно за един екземпляр. Ако планирате да стартирате множество реплики на Authelia, ще ви е необходим споделен доставчик като Redis и външна база данни вместо SQLite.

Как да създадете сигурни потребителски имена и пароли

Authelia не съхранява пароли в обикновен текст. За да генерирате интерактивно хеш на Argon2, изпълнете:

docker run --rm -it authelia/authelia:latest authelia crypto hash generate argon2

Въведете паролата, когато командата ви подкани, и копирайте целия резултат, започвайки с $argon2id$След това създайте users_database.yml:

users:
  usuario:
    disabled: false
    displayname: 'Usuario principal'
    password: '$argon2id$PEGA_AQUI_EL_HASH_COMPLETO'
    email: '[email protected]'
    groups:
      - 'admins'

Запачената стойност е хеш на паролатане е обратимо криптиран низ. Ако активирате нулирането на паролата, Authelia трябва да има права за запис в този файл.

Групите ви позволяват да дефинирате по-прецизни правила. Например, можете да изисквате двуфакторно удостоверяване само за администратори или да забраните на определени потребители достъп до конкретно приложение.

Как да дефинираме правила за достъп

Authelia оценява правилата в реда, в който се появяват, и прилага първото съвпадение. Следователно, специфичните правила трябва да бъдат поставени преди общите.

access_control:
  default_policy: 'deny'
  rules:
    - domain: 'panel.example.com'
      policy: 'two_factor'
      subject:
        - 'group:admins'

    - domain: 'wiki.example.com'
      policy: 'one_factor'

    - domain: '*.example.com'
      policy: 'two_factor'

Основните политики са:

• отричам: Това напълно блокира заявката.
• байпас: Позволява достъп без удостоверяване.
• един_фактор: Изисква потребителско име и парола.
• два_фактора: Това изисква и втори фактор.

Не е необходимо да се създава правило bypass за auth.example.com Ако прокси хостът на портала не включва проверка на оторизацията, защитете портала със собствен прокси. auth_request може да причини безкраен цикъл на пренасочване.

Как да публикувате портала Authelia в Nginx Proxy Manager

Официалната интеграция използва няколко фрагмента за конфигурация:

• proxy.conf
• authelia-location.conf
• authelia-authrequest.conf
• websocket.conf, когато приложението използва WebSockets

Изтеглете текущите версии на тези фрагменти и монтирайте папката им в контейнера на Nginx Proxy Manager:

volumes:
  - ./data:/data
  - ./letsencrypt:/etc/letsencrypt
  - ./snippets:/snippets:ro

Текущите фрагменти използват крайната точка /api/authz/auth-requestНе използвайте повторно стари конфигурации, базирани на /api/verify, тъй като те съответстват на наследена интеграция.

След това създайте прокси хоста на портала със следните стойности:

• Имена на домейни: auth.example.com
• Схема: http
• Име/IP адрес на пренасочващ хост: authelia
• Пренасочващ порт: 9091
• SSL сертификат: валиден сертификат
• Принудително SSL: активиран

В раздела РазширеноТой добавя:

location / {
    include /snippets/proxy.conf;
    proxy_pass $forward_scheme://$server:$port;
}

Този прокси хост публикува портала, но не го защитава със собствена заявка за удостоверяване.

Как да защитите приложение с Authelia

Създайте друг прокси хост за приложението. Например:

• Имена на домейни: app.example.com
• Схема: http
• Име/IP адрес на пренасочващ хост: име на контейнера на приложението
• Пренасочващ порт: вътрешен сервизен порт
• Принудително SSL: активиран

В раздела Разширено, използва:

include /snippets/authelia-location.conf;

location / {
    include /snippets/proxy.conf;
    include /snippets/authelia-authrequest.conf;
    proxy_pass $forward_scheme://$server:$port;
}

Включената конфигурация отправя запитвания към Authelia преди да достави всяка заявка. Ако приложението изисква WebSockets, добавете също:

include /snippets/websocket.conf;

Когато блокът е дефиниран ръчно location В раздела „Разширени“ някои превключватели в раздела „Детайли“ спират да се прилагат. Затова активирайте само показаните. Поддръжка на уебсокети Само интерфейсът може да не е достатъчен.

Тази схема може да се използва и за Защитете Open WebUI с парола и втори фактор, при условие че контейнерът е достъпен от споделената мрежа.

Как да се справяме с персонализирани API и местоположения

Маршрутите, създадени от раздела Персонализирани местоположения Екземплярите на Nginx Proxy Manager не наследяват автоматично защитата на Authelia. Незащитено местоположение може да позволи заобикаляне на конфигурираните правила.

Ако имате нужда от персонализиран маршрут, декларирайте го в Advanced и изрично включете проверката:

location /custom {
    include /snippets/proxy.conf;
    include /snippets/authelia-authrequest.conf;
    proxy_pass http://servicio:8080;
}

Мобилните приложения и някои API също не могат да следват пренасочване към портала за удостоверяване. Не бива обаче да прилагате bypass към целия API за удобство.

Изключете само конкретен маршрут, когато има такъв собствен механизъм за удостоверяванеНапример:

- domain: 'app.example.com'
  policy: 'bypass'
  resources:
    - '^/api/health$'

Проверете дали регулярният израз не включва случайно други чувствителни крайни точки.

Как да активирате втория фактор

С политиката two_factor Активирайте, влезте и регистрирайте TOTP устройство. По време на тестването Authelia ще запише линка за регистрация на:

./config/notification.txt

Отворете връзката, сканирайте QR кода със съвместимо приложение и потвърдете временния код. В производствения режим трябва да замените файла-известител със SMTP, така че връзките да достигат до потребителя по имейл.

Ако TOTP кодовете бъдат отхвърлени, проверете времето на сървъра:

timedatectl status

Определящият фактор е, че часовникът е синхронизиран чрез NTP. Променливата TZ Помага правилното представяне на датите, но Не коригира време, което не е синхронизирано..

Как да проверя дали защитата работи

След като стартирате Authelia, проверете записите си:

docker compose logs --tail=200 authelia

Също така проверете дали Nginx Proxy Manager може да разреши името на контейнера:

docker exec nginx-proxy-manager getent hosts authelia

Заменя nginx-proxy-manager с действителното име на вашия контейнер. След това:

1. Затворете всички отворени сесии в Authelia.
2. Отворете директно защитеното приложение.
3. Проверете дали ви пренасочва към auth.example.com.
4. Завършете очакваното ниво на удостоверяване.
5. Потвърдете, че се връщате към оригиналното приложение.
6. Проверете дали вътрешният порт не отговаря от друго устройство.

Ако използвате политики, базирани на IP адреси, уверете се, че Nginx замества заглавките X-Forwarded-For изпратени от клиента. Сляпото доверяване на тези заглавки би позволило фалшифициране на изходния IP адрес и заобикаляне на определени мрежови правила.

След като сте внедрени, можете Следете приложението с Uptime Kuma, като се има предвид, че външна проверка трябва да получи пренасочване към Authelia, вместо към частното съдържание.

Често срещани грешки при свързване на Authelia с Nginx Proxy Manager

Грешка 502 Лош шлюз

Nginx Proxy Manager не може да се свърже с Authelia или с приложението. Проверете дали контейнерите принадлежат към една и съща Docker мрежа и дали вътрешното име и порт са правилни.

Пренасочване към портала

Проверете дали прокси хостът на auth.example.com не включвай authelia-authrequest.confПроверете също домейна на бисквитката, адреса authelia_url и последователното използване на HTTPS.

Authelia показва „Достъпът е отказан“

Заявката не съответства на никое разрешено правило или е била прехваната от предишно правило. Не забравяйте, че правилата се оценяват последователно и правилото се прилага. първо съвпадение.

Приложението остава достъпно без влизане в системата

Проверете дали контейнерът няма директно публикуван порт. Проверете и персонализираните местоположения в Nginx Proxy Manager, тъй като те може да бъдат пропуснати от проверката на Authelia.

Интерфейсът се зарежда, но някои функции не реагират.

Приложението вероятно използва WebSockets. То включва websocket.conf в рамките на блока location и проверете връзките от инструментите за разработчици на браузъра.

Линкът за регистрация на втория фактор не работи.

Ако използвате инструмента за известяване на файлове, проверете notification.txt и неговите разрешения. Ако използвате SMTP, проверете сървъра, порта, криптирането и идентификационните данни.

TOTP кодовете винаги се показват като неправилни

Проверете времето на хоста и контейнера. Разминаване само от няколко минути може да направи всички кодове невалидни, дори ако часовата зона е правилно конфигурирана.

Промените в конфигурацията не се прилагат

Първо, проверете лог файловете за синтактични грешки и рестартирайте Authelia:

docker compose restart authelia

Валидирайте отново потока, след като промените правилата, актуализирате Nginx Proxy Manager или промените някой от фрагментите.

Защитата на приложенията с Authelia и Nginx Proxy Manager ви позволява да добавите централизиран слой за удостоверяване и двуфакторно удостоверяване, без да променяте оригиналните услуги. Сигурността обаче зависи от затварянето на преки пътища, използването на HTTPS, актуализирането на фрагменти и внимателната проверка на персонализираните правила и местоположения. С правилно конфигурираните тези елементи, проксито се превръща в единствената точка за влизане, а Authelia решава кой може да премине през него.