Использовать VPN - вот мой ответ на большинство вопросов о доступе к ресурсам внутри организации. Но порой VPN не подходят и ставится задача получить прямой доступ. В данном случае запросили доступ к веб интерфейсу сервера Exchange. Я чесал репу и подумал, а не это ли тот самый момент когда стоит окунуться в мир NGINX и Reverse Proxy? Быстрый гугел мне подсказал, что можно на базе NGINX организовать авторизацию, значит "дальше будем действовать мы"...
Library:
- Что такое Reverse Proxy
- Доходчиво по верхушкам об NGINX
- How To Install Nginx on Ubuntu 20.04
- Using Free Let’s Encrypt SSL/TLS Certificates with NGINX
- Restricting Access with HTTP Basic Authentication
- How To Protect an Nginx Server with Fail2Ban on Ubuntu 20.04
- Закрытая сеть с пачкой белых 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
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 минут. Дополнительные действия по оповещению на почту, описанные в гайде, мне не требуются, поэтому их я не настраивал.
Комментариев нет:
Отправить комментарий