Некоторые картинки не загружаются из РФ и РК, используйте VPN.

суббота, 1 июля 2023 г.

NGINX + f2b для предавторизации OWA

Использовать VPN - вот мой ответ на большинство вопросов о доступе к ресурсам внутри организации. Но порой VPN не подходят и ставится задача получить прямой доступ. В данном случае запросили доступ к веб интерфейсу сервера Exchange. Я чесал репу и подумал, а не это ли тот самый момент когда стоит окунуться в мир NGINX и Reverse Proxy? Быстрый гугел мне подсказал, что можно на базе NGINX организовать авторизацию, значит "дальше будем действовать мы"...

Library:

Что имеем:
  • Закрытая сеть с пачкой белых IP
  • Mikrotik RB4011 в качестве роутера
  • Собственный домен
  • Доменная сеть
  • 2 почтовых сервера Exchange с DAG
Подготовка и план:
  • домены mail.domain.ru заняты, да и палить так явно - не охота, будем пользовать ml.domain.ru
  • пропишем новый домен у DNS хостера
  • устанавливаем чистую ОС на тачку и NGINX (микросервисы как-нибудь в будущем, может вообще соберу вот это в контейнер)
  • проброс 80 и 443 порта сделаем, но в Disable=True, пока заглушки не будет
  • для прокси сервера добавим cname ml.domain.ru внутри сети, чтобы проверить (использовать SRC nat перебор, на данном этапе)
  • переходим к настройке
sudo apt-get update && sudo upt-get upgrade -y
# установка nginx
sudo apt-get install nginx
# установка инструмента для генерации файла паролей (пароли не хранятся в открытом виде)
sudo apt-get apache2-utils 
# установка certbot для настройки SSL
sudo apt-get install certbot
sudo apt-get install python3-certbot-nginx
# установка Fail2Ban для защиты от перебора паролей
sudo apt-get install fail2ban
# удаляем стандартный конфиг nginx
sudo rm /etc/nginx/sites-enabled/default
# создаем свой
sudo nano /etc/nginx/sites-available/mail.domain.ru
# активируем
sudo ln -s /etc/nginx/sites-available/mail.domain.ru /etc/nginx/sites-enabled/
# генерируем и покдлчюаем сертификат
sudo certbot --nginx -d ml.domain.ru
# создаем пользователя и пароль (первый с параметром -c, последующие без)
sudo htpasswd -c /etc/nginx/.htpasswd user1
sudo htpasswd /etc/nginx/.htpasswd user2
# настраиваем F2B, из коробки он уже умеет работать NGINX, нужно только активировать в jail.local
sudo nano /etc/fail2ban/filter.d/nginx-http-auth.conf
sudo nano /etc/fail2ban/jail.local
# активируем, если необходимо
sudo systemctl enable fail2ban
# перезапускаем и проверяем статус
sudo systemctl restart fail2ban
sudo systemctl status fail2ban
# вот так можно проверить текущее состояние и блокировки
sudo fail2ban-client status nginx-http-auth

# вот такой командой я правлю конфиг NGINX и сразу при закрытии проверка и применение конфига
sudo nano /etc/nginx/sites-available/mail.domain.ru && sudo nginx -t && sudo systemctl reload nginx.service
В итоге получились такие конфиги:
/etc/nginx/sites-available/mail.domain.ru:
server {
        listen  80;
        server_name     ml.domain.ru;
        access_log      /var/log/nginx/mail.domain.ru.access.log;
        #for letsencrypt
        location /.well-known {
                root /var/www/html;
        }
        location /owa {

                auth_basic      "Administrator’s Area";
                auth_basic_user_file    /etc/nginx/.htpasswd;

                proxy_set_header        Host    $host;
                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       $scheme;

                proxy_pass      https://mail.domain.ru;
                proxy_read_timeout      90;
        }
        location / {
                return 404;
        }

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/ml.domain.ru/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/ml.domain.ru/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}

Пара моментов о конфиге. Я не хочу, что бы кто то случайно обнаружив домен ml.domain.ru сразу попал под авторизацию, для этого используется последний location, который возвращает 404. При этом необходимо чтобы certbot отработал обновление сертификата, а для этого есть первый location /.well-known, который ведет в домашнюю директорию, куда при обновлении сертификата кладется файл для проверки. Если же в url будет owa, то тогда, и только тогда, пользователь получит окно авторизации, а после успешной авторизации будет допущен к авторизации на самом почтовом сервере. При этом на почтовом сервере не все имеют право входа в WEB-интерфейс.

/etc/fail2ban/jail.local

[DEFAULT]

findtime = 10m
maxretry = 5
bantime = 30m
ignoreip = 10.20.0.0/16 10.21.0.0/16

[nginx-http-auth]

enabled  = true
port     = http,https
logpath = %(nginx_error_log)s

[sshd]
enabled = true

Здесь все просто. В секции DEFAULT описаны общие правила, лочить будет на 30 минут как SSH, так и nginx при 5 неудачных попытках в пределах 10 минут. Дополнительные действия по оповещению на почту, описанные в гайде, мне не требуются, поэтому их я не настраивал.


Комментариев нет:

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