Использовать 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 минут. Дополнительные действия по оповещению на почту, описанные в гайде, мне не требуются, поэтому их я не настраивал.
Комментариев нет:
Отправить комментарий