На днях проскочила новость о том, что 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

Одним из ключевых сервисов в инфраструктуре является DNS. Он же и наиболее простой в настройке, особенно если речь идёт о локальном кэширующем и рекурсивном DNS сервере. При этом его отказ может в один момент парализовать всю работу.

Мне один раз досталась в наследство компания, где периодически падал локальный DNS сервер. Когда это случилось первый раз, было стрёмно. Я ещё только изучал инфраструктуру. Там и кластер виртуализации был, и DRBD диски, и домен на Samba. Разом всё сломалось, мониторинг спамит, пользователи жалуются техподдержке, она теребит меня. Быстро догадался зайти по IP на сервер и перезапустить тогда ещё использовавшийся Bind, если не ошибаюсь. Потом уже всё перенастроил, но Bind успел упасть ещё пару раз. На серваке, где он работал, как потом выяснилось, банально кончалась память.

Сам я потом тоже использовал какое-то время Bind, потом перешёл на DNSmasq, если в инфре была винда, то использовал её DNS сервер, если есть железный роутер, то DNS сервер обычно на нём. На базе DNSmasq собран небезызвестный Pi-hole. Я немного пользовался им, даже запускал его в контейнере на Mikrotik. В итоге отказался, так как всё это ненадёжно работало на моём железе.

Длинная подводка получилась. Рассказать хотел о новом для меня DNS сервере - Technitium DNS. Впервые увидел его в недавнем обзоре. По описанию понравилось, поэтому решил попробовать. Особенно привлекла простая возможность собрать полноценный (но однонаправленный) кластер. Я всё это развернул у себя, в том числе и кластер, и протестировал. DNS сервер понравился. Думаю, что при необходимости буду использовать именно его, если нужен будет сервер с веб панелью управления, статистикой, разграничением доступа, блокировками по готовым спискам и т.д.

Technitium DNS - современный сервер, который поддерживает всевозможные технологии и настройки:

▪️DNS-over-TLS, DNS-over-HTTPS, and DNS-over-QUIC, DNSSEC.
▪️Блокировки по готовым спискам доменов.
▪️Быстрый запуск через готовый Docker контейнер (есть и другие способы).
▪️Расширение функциональности через встроенный магазин приложений (может, к примеру, логи запросов писать в MySQL).
▪️Встроенный DHCP сервер.
▪️Управление доступом на основе ролей (RBAC).
▪️API с доступом по токенам.
▪️Поддержка работы через HTTP и SOCKS5 прокси.

В этом сервере есть всё, что можно только придумать и желать от современного программного продукта. Я пробежался по огромному списку возможностей и не придумал, чего там не хватает.

При этом, всё это настраивается очень просто, особенно в базовой функциональности. Я развернул на двух нодах и собрал сервер в кластер. Использовал следующий docker-compose.yml, изменив только имя хостов:

services:
 dns-server:
  container_name: technitium-01
  hostname: technitium-01
  image: technitium/dns-server:latest
  ports:
   - "5380:5380/tcp" # Web console (HTTP)
   - "53:53/udp"   # DNS service
   - "53:53/tcp"   # DNS service
   - "53443:53443/tcp" # Web console (HTTPS)
   # - "853:853/udp"   # DNS-over-QUIC
   # - "853:853/tcp"   # DNS-over-TLS
   # - "443:443/udp"   # DNS-over-HTTPS (HTTP/3)
   # - "443:443/tcp"   # DNS-over-HTTPS (HTTP/1.1, HTTP/2)
   # - "67:67/udp"    # DHCP service
  environment:
   - DNS_SERVER_DOMAIN=home.local
   - DNS_SERVER_ADMIN_PASSWORD=your_password
   - DNS_SERVER_PREFER_IPV6=false
   - DNS_SERVER_RECURSION=AllowOnlyForPrivateNetworks
   - DNS_SERVER_FORWARDERS=62.76.76.62,77.88.8.1,62.76.62.76,77.88.8.8
  volumes:
   - ./config:/etc/dns
  restart: unless-stopped
  sysctls:
   - net.ipv4.ip_local_port_range=1024 65000

Запустил, зашёл на веб интерфейс http://server-ip:5380/, собрал в кластер, настроил списки блокировки и другие настройки. Подключил нескольким пользователям. Проверил - отлично работает, никаких проблем не возникло. Выключил одну ноду, кластер продолжил работать на второй, запросы резолвил.

Продукт однозначно хорош. Я не знаю, что сейчас есть лучше для рекурсивного кэширующего DNS сервера. Если знаете - подскажите.

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

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

#dns

Я часто упоминал в различных заметках систему по сбору логов Loki. Например, вот в этой подборке подобных систем (там сразу можете посмотреть аналоги). При этом у меня нет ни одной заметки на тему того, как её быстро развернуть. Решил написать краткое руководство по этой теме.

Проект относительно новый, стартовал в 2018 году в противовес стеку ELK. Grafana решила сделать более простой и легковесный вариант хранения логов немного с другой моделью анализа, без полной индексации текстов логов, используя вместо этого метки для потоков. На деле получился хороший продукт, интегрированный в стек Grafana + Prometheus с похожей идеологией хранения и поиска (язык запросов LogQL по аналогии с PromQL).

Для начала выполню базовые действия для запуска Loki и Grafana и настрою отправку логов в Loki от различных Docker контейнеров. Большее в одну заметку не уместить. Думаю, что далее я эту тему разовью.

Я не буду запускать Loki и Grafana в одном Docker Compose файле, так как им не обязательно быть установленными вместе. Grafana поддерживает весь стек своих продуктов, так что нет особого смысла поднимать её рядом со сборщиком логов.

Сначала запустим Loki. Готовим для него compose.yaml и конфигурацию в config.yaml. Не буду приводить здесь содержимое. Оно будет отправлено следующим сообщением в архиве со всеми остальными конфигурациями. Для удобства скопировал её же в gitflic.

# curl https://get.docker.com | bash -
# git clone https://gitflic.ru/project/serveradmin/grafana-loki.git
# cd grafana-loki/loki/

В файле compose.yaml укажите актуальную версию image на момент установки. Запускаем проект:

# docker compose up -d

Проверим, что сервис стартовал:

# curl http://192.168.137.29:3100
404 page not found

Это нормальный ответ. 404 нам ответил Loki. Запустим теперь Grafana:

# cd ../grafana

Указываем нужную версию в compose.yaml и запускаем:

# docker compose up -d

Идём браузером по IP сервера, где запущена Grafana на порт 3000. Учётка по умолчанию - admin / admin. Заходим в Grafana, идём в раздел Connections ⇨ Data sources ⇨ Add data source. Выбираем Loki. В качестве настроек достаточно указать только url. В моём случае это http://192.168.137.30:3100/. Мотаем страничку в самый низ и нажимаем Save & Test. Ошибок быть не должно.

Стек поднят и готов к приёму логов. Отправим туда логи контейнеров Docker. Для этого у Docker существует драйвер. Его необходимо установить на хосте:

# docker plugin install grafana/loki-docker-driver:3.6.0-amd64 --alias loki --grant-all-permissions

Проверяем, что он установился:

# docker plugin ls
018395707e37  loki:latest  Loki Logging Driver  true

Всё в порядке. Теперь мы можем в самом демоне Docker настроить отправку всех логов в Loki через правку его конфигурации в /etc/docker/daemon.json. Для этого туда надо добавить:

{
  "debug": true,
  "log-driver": "loki",
  "log-opts": {
    "loki-url": "http://192.168.137.30:3100//loki/api/v1/push",
    "loki-batch-size": "400"
  }
}

Это не очень удобно, если у нас нет желания собирать логи абсолютно всех контейнеров. Удобнее управлять этим для каждого контейнера отдельно. Для этого в compose файл достаточно добавить ещё одну секцию logging. Покажу сразу итоговый пример для запуска Grafana из этой публикации:

services:
 grafana:
  image: docker.io/grafana/grafana-oss:12.3.1
  container_name: grafana
  logging:
   driver: loki
   options:
    loki-url: "http://192.168.137.30:3100/loki/api/v1/push"
    loki-retries: 2
    loki-max-backoff: 800ms
    loki-timeout: 1s
    keep-file: "true"
    mode: "non-blocking"
  ports:
   - "3000:3000"
  volumes:
   - grafana-data:/var/lib/grafana
  restart: unless-stopped
volumes:
 grafana-data:
  driver: local

Перезапускаем проект:

# docker compose stop
# docker compose up -d

Идём в Grafana, раздел Drilldown ⇨ Logs. Выбираем в выпадающем списке service имя контейнера и смотрим его логи.

Настройка простая и быстрая, легко автоматизируется. Далее я разовью эту тему и добавлю логи из других систем.

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

#loki #logs #devops

Я думал, что из Windows 11 старый Internet Explorer выпилили окончательно. И тут мне в ВК прилетает уведомление о комментарии к заметке 2023 года, где я рассказываю, как можно зайти в старое оборудование, интерфейс которого работает только в IE. Я там речь веду про расширение IE Tab.

А в комментариях человек предложил более простое решение. Создаём файл с расширением .vbs следующего содержания:

Set objIE = CreateObject("InternetExplorer.Application")
objIE.Visible = 1

Запускаем его и получаем старый добрый Internet Explorer. От нечего делать проверил у себя на самой свежей Windows 11. Просто любопытно стало, заработает или нет. До сих пор работает, к камерам можно подключиться.

Если надо, используйте. Способ рабочий. Несмотря на то, что он давно известен, я как-то мимо ушей его пропускал и ни разу не пробовал. Какие-то другие варианты искал. Хотя это решение максимально простое. Думаю, тут сейчас найдётся немало людей, кто напишет или подумает, мол автор, ты чего, такую банальщину не знаешь. На самом деле не знал, не придумываю.

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

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

#windows

Подписчик поделился интересной реализацией OTP (One Time Password) для подключений по RDP. При подключении пользователь сначала вводит свой основной пароль от учётной записи, а потом одноразовый через приложение на смартфоне. Это неплохо страхует сервер, доступный из интернета. Способ отлично подойдёт в том случае, когда по какой-то причине доступ по RDP нельзя убрать из прямого доступа через интернет.

Ничего особенного в этом нет, подобных систем много. Но обычно это отдельный сервис, который надо разворачивать, настраивать, и это не всегда просто и быстро сделать. А описанный ниже способ очень простой. Всё устанавливается локально на ОС Windows как серверных, так и десктопных редакций. Разницы в настройке нет.

Для реализации 2FA через OTP на Windows нам понадобится open source продукт под названием multiOTP, а точнее его отдельный компонент multiOTPCredentialProvider. Покажу сразу полную настройку. Я у себя всё проверил. Долго провозился, потому что разбирался, как всё это работает, собирал нужные команды, читал help. Повторить можно будет намного быстрее. ИИ не помог, тупо выдумал все команды. Вообще все.

Со страницы загрузки скачиваете свежую версию multiOTP Credential Provider. Это обычный .msi пакет. Устанавливаете в системе. Во время установки ставите галочку, что не используете никакой сервис, а только локальную версию. Не запомнил, как точно настройка называлась. А на втором экране отмечаете галочками, для каких процессов будет запрашиваться одноразовый пароль. Это могут быть:

- локальные и удалённые входы
- локальные или удалённые разблокировки сеансов
- локальный или удалённый запуск приложений в режиме "Запустить от администратора (Run as Administrator)"

Я выбрал только один случай - remote logon, то есть удалённое подключение, в данном случае по RDP.

После установки запускаем cmd от администратора и переходим в каталог с программой:

> cd C:\Program Files\multiOTP

Выбираем любого системного пользователя и задаём ему вход через TOTP:

> multiotp.exe -debug -display-log -create totp_user TOTP 34443E4948A3C06A1CFB 6

◽️totp_user - имя пользователя
◽️34443E4948A3C06A1CFB - любой 160 битный ключ (Hexadecimal, Шестнадцатеричный ключ, 20 символов), можно создать в онлайн генераторе.
◽️6 - количество символов в одноразовом пароле

И сразу же создадим пользователю qr код для добавления в аутентификатор:

> multiotp.exe -qrcode totp_user c:\multiotp\totp_user.png

❗️Теперь важный момент. После установки multiOTP Credential Provider для всех удалённых подключений будет требоваться TOTP, даже если вы их не добавили в базу multiotp. Я попался на этом. Пришлось подключаться локально и добавлять TOTP для остальных учёток.

Только после того, как вы выполнили создание пользователя через multiotp, вы сможете отключить для отдельных пользователей использование TOTP:

> multiotp -iswithout2fa zerox

Для пользователя zerox отключили одноразовые пароли. Он заходит как обычно.

Собственно, на этом настройка и окончена. Приведу список команд, которыми пользовался во время настройки.

Список пользователей в базе multiotp:
> multiotp -userslist

Информация о пользователе:
> multiotp -user-info totp_user

Настроить длину пароля по умолчанию:
> multiotp -config default-2fa-digits 6

Выпустить список одноразовых паролей. Могут пригодиться, если пользователь потерял смартфон или не может воспользоваться аутентификатором:
> multiotp.exe -scratchlist totp_user

Я проверил одноразовые пароли. По ним нормально заходит.

Пользователю нужно установить на смартфон или компьютер какой-то аутентификатор. Их очень много. Я проверял Google Authenticator и FreeOTP. Последний можно через RuStore установить.

В самой программе достаточно отсканировать qr код пользователя и генератор одноразовых паролей для multiotp будет добавлен. Если нет возможности отсканировать qr код, то можно hexadecimal ключ сконвертировать в base32 и добавить вручную.

multiOTP - масштабный сервис. Может быть развёрнут в связке с AD, или по аналогии настроен в Linux для SSH.

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

#windows #security