Расскажу про одну простую настройку в Nginx/Angie, которую использую постоянно, но с некоторыми нюансами, про которые возможно кто-то не знает. По крайней мере я не сразу об этом узнал. Речь пойдёт про basic_auth.

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

# sh -c "echo -n 'user01:' >> /etc/nginx/.htpasswd"
# sh -c "openssl passwd -apr1 >> /etc/nginx/.htpasswd"

Создали файл .htpasswd, куда добавили пользователя user01 и задали ему интерактивно пароль. Теперь настраиваем Nginx/Angie, добавляя в секцию server или отдельной location настройку:

location / {
auth_basic "Access Denied";
auth_basic_user_file /etc/nginx/.htpasswd;
try_files $uri $uri/ =404;
}

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

Таким способом очень удобно скрывать различные непубличные сервисы или технические панели. Например, я всегда так закрываю публикацию баз 1C, доступ в Phpmyadmin, Zabbix, Grafana, Apache Guacamole, какую-нибудь веб панель для управления, если используется и т.д. В общем, всё, что не для широкой публики лучше скрыть от посторонних глаз.

Иногда хочется, чтобы кого-то пускало напрямую без аутентификации. Первое, что приходит в голову, добавить директивы allow и deny, потому что они тоже часто используются. По крайней мере я постоянно использую. Но они напрямую не работают с basic_auth, либо одно, либо другое. Нужен ещё один параметр - satisfy.

location / {
satisfy any;
allow 192.168.137.0/24;
deny all;
auth_basic "Access Denied";
auth_basic_user_file /etc/nginx/.htpasswd;
try_files $uri $uri/ =404;
}

В этом примере пользователи из подсети 192.168.137.0/24 зайдут на ресурс напрямую без аутентификации, а всем остальным нужно будет ввести пароль. Это удобно для той же публикации 1С, когда люди из офиса ходят напрямую в локальную базу, а снаружи с аутентификацией. В случае публикации на внешнем сервере удобно разрешить доступ с внешнего IP адреса офиса прямой доступ, а всем остальным с паролем.

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

Если нужно указать несколько подсетей и отдельных IP адресов, то их можно добавлять новыми строками, примерно так:

allow 192.168.0.0/24;
allow 10.20.5.0/24;
allow 185.25.48.189;

Повторю на всякий случай ещё раз, что не оставляйте ничего лишнего в прямом доступе из интернета. Вопрос времени, когда в нём найдётся какая-нибудь уязвимость. И хорошо, если для неё выйдет исправление, а вы успеете обновиться. Иногда люди забывают о чём-то и панели годами висят без обновления, пока не случится какая-нибудь беда с ними.

Basic_auth простая и надёжная технология. Не припоминаю, чтобы хоть раз была какая-то уязвимость в обход неё. Пароль можно только перехватить, если не используется HTTPS, либо сбрутить, но это трудно, так как во-первых, стоит настраивать ограничение в веб-сервере на количество одновременных запросов. Я всегда это делаю по умолчанию. Плюс, производительности веб сервера будет недостаточно, чтобы подбирать сложный пароль с хорошей скоростью. Это не локально брутить. По интернету несловарный сложный пароль не подобрать.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#nginx #angie

На днях проскочила новость о том, что Let's Encrypt запускает выпуск сертификатов на IP адреса. Меня это сразу заинтересовало, так как давно думал, почему этого нельзя сделать. Мне нередко хотелось выпустить сертификат на IP адрес, чтобы нормально работал запущенный на нём сервис, для которого нет необходимости делать доменное имя.

Сейчас многий софт без TLS и доверенного сертификата не хочет подключаться в принципе. Если выпускаешь самоподписанный сертификат, то надо настраивать доверие через передачу сертификата CA на целевую машину. Всё это создаёт неудобства, особенно в тестовой среде.

И вот теперь эта проблема решена. Можно взять виртуалку с внешним IP адресом и выпустить для него подтверждённый сертификат. Я сразу же решил проверить, как это работает.

Мне больше всего нравится certbot как клиент для взаимодействия с Let's Encrypt, хотя я пробовал и использовал все известные клиенты. К сожалению, у него пока не вышла стабильная версия с поддержкой этой новой функциональности. Проверял версию 4.0.0 из пакетов Debian 13, и самую свежую 5.2.2 из docker hub. Нет поддержки новых сертификатов. При запросе ошибка:

The Let's Encrypt certificate authority will not issue certificates for a bare IP address.

Сразу показываю рабочий вариант с использованием acme.sh. От установки, до выпуска сертификата:

# git clone https://github.com/acmesh-official/acme.sh.git
# cd ./acme.sh
# ./acme.sh --install -m zeroxzed@gmail.com
# ./acme.sh --issue -d 85.143.175.116 --standalone --server letsencrypt --certificate-profile shortlived

Получаем набор файлов для использования по назначению:

◽️ ~/.acme.sh/85.143.175.116_ecc/85.143.175.116.cer
◽️ ~/.acme.sh/85.143.175.116_ecc/85.143.175.116.key
◽️ ~/.acme.sh/85.143.175.116_ecc/fullchain.cer

Устанавливаем веб сервер, прописываем там в виде доменного имени IP адрес, подключаем этот сертификат. Пример для Angie/Nginx:

# mkdir -p /etc/nginx/tls
# ./acme.sh --install-cert -d 85.143.175.116 --key-file /etc/nginx/tls/85.143.175.116.key --fullchain-file /etc/nginx/tls/85.143.175.116.cer --reloadcmd "systemctl reload nginx"

Рисуем примерно такую конфигурацию для доступа по IP адресу:

server {
  listen 80 default_server;
  listen 443 ssl default_server;

  ssl_certificate /etc/nginx/tls/85.143.175.116.cer;
  ssl_certificate_key /etc/nginx/tls/85.143.175.116.key;

  root /var/www/html;
  index index.html index.htm index.nginx-debian.html;

  server_name _;

  location / {
    try_files $uri $uri/ =404;
  }
}

Заходим по HTTPS на IP адрес сервера и видим действительный сертификат. Никаких предупреждений.

Сертификат выдаётся менее чем на 7 дней, так что нужно внимательно следить за автоматическим обновлением. Описанных в заметке настроек достаточно для этого. Acme.sh добавил задание в cron пользователя, будет запускаться раз в сутки.

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

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#webserver #angie #nginx