Для централизованного сбора, управления и аналитики логов существуют серьезные решения, целые стеки, такие как PLG (Promtail, Loki, Grafana) или EFK / ELK (Elasticsearch, Kibana, Fluentd / Logstash). Однако, всегда стоит вопрос в целесообразности их применения, а также действительная необходимость в такой обширной функциональности в относительно небольших проектах.

💻 Мне зачастую не хватало простого и быстрого решения для элементарного просмотра логов с нескольких совместно трудящихся сервисов. И такое решение нашлось - легковесная self-hosted система мониторинга логов из docker контейнеров - dozzle.

Одиночный контейнер с доступом к docker.sock и все логи начинают сыпаться в кучу в реальном времени с удобным представлением в едином окне веб приложения.

❗️ Стоит отметить, что возможности собирать логи из файлов нет - только из sysout syserr потоков контейнеров по аналогии с командой docker logs.
❗️ Хранилища логов тоже нет, поэтому проанализировать полную историю не получится.

🔸 Готовим пользователя
Генерируем параметры доступа для базовой аутентификации в dozzle

docker run -it --rm amir20/dozzle generate testuser --password testpassword --email test@test.test --name "Test User" > data/users.yml

Получаем в выходном файле структуру вида

users:
    testuser:
        email: test@test.test
        name: Test User
        password: $2a$11$GstVlSugO7SmT0EV/RkU2ubm2qhXfuC1lWGd8FYIrV/Lg2cjKnro.
        filter: ""

где password - bcrypt hash от пароля.

🔸 Заполняем compose
Итоговый compose будет выглядеть следующим образом

services:
  dozzle:
    image: amir20/dozzle:latest
    container_name: dozzle
    restart: always
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ${HOME}/services/dozzle/data:/data
    ports:
      - 8080:8080
    environment:
      DOZZLE_AUTH_PROVIDER: simple
      DOZZLE_ENABLE_ACTIONS: true
      DOZZLE_NO_ANALYTICS: true
    healthcheck:
      test: ["CMD", "/dozzle", "healthcheck"]
      interval: 3s
      timeout: 30s
      retries: 5
      start_period: 30s

${HOME}/services/dozzle/data - каталог с созданным ранее users.yml
DOZZLE_AUTH_PROVIDER: simple - базовая аутентификация
DOZZLE_ENABLE_ACTIONS: true - включаем кнопки управления контейнерами (старт, стоп, перезапуск) в ui
DOZZLE_NO_ANALYTICS: true - отключаем сбор и отправку аналитики, потому что

Dozzle collects anonymous user configurations using a simple beacon written in Go.
Dozzle sends anonymous data to DigitalOcean, where it is written to a flat file for processing.

🔸 Запускаем

docker compose up -d

Идем в веб приложение на 8080 и наблюдаем статистику использования ресурсов, ленту логов с поиском и даже сплит-окна.

🔎 Из дополнительных возможностей

▪️ Подключение к удаленным хостам через агентов
▪️ Группировка контейнеров с помощью labels
▪️ Фильтрация списка отслеживаемых контейнеров

#logs #tools #selfhosted

Продолжил настройку тестового сервера на базе Proxmox (подборку туториалов см. здесь). В версии 8.1 была добавлена поддержка SDN (Software Defined Networks) или программно-определяемые сети. SDN работает на программном уровне и обеспечивает централизованный контроль и управление сетью, что привносит гибкость в принятии решений при построении и обслуживании виртуальной инфраструктуры.

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

📌 Установка

🔹 Ставим сетевой пакет для поддержки SDN (по умолчанию установлен на версиях 8.1 и выше)

apt update
apt install libpve-network-perl

Проверяем наличие следующей записи в конце конфигурационного файла /etc/network/interfaces

source /etc/network/interfaces.d/*

🔹 Для поддержки DHCP в SDN proxmox использует dnsmasq. Устанавливаем и отключаем сервис по умолчанию.

apt install dnsmasq
systemctl disable --now dnsmasq

🔹 Перезагружаемся. Проверяем наличие раздела SDN в параметрах дата-центра proxmox.

📌 Создание виртуальной сети
Для рассматриваемого случая мне достаточно было настроить самый простой вариант сети на базе изолированного моста.

🔹 Идем в раздел SDN - Zones и добавляем новую зону типа Simple.
▪️ В advanced не забываем проставить галочку automatic DHCP, если ожидаем работу DHCP-сервера в заданной сетевой зоне.

🔹 В разделе SDN - VNets добавляем новую сеть в созданную ранее зону.
▪️ Тут же станет доступной опция создания подсети в соседнем окне. Задаем адрес сети и шлюз (в моем случае 192.168.50.1/24 и 192.168.50.1).
▪️ Для того, чтобы хосты подсети имели доступ в интернет, включаем SNAT (Source-NAT).
▪️ На вкладке DHCP Ranges можно настроить диапазон назначаемых адресов.

🔹 В разделе SDN применяем все внесенные изменения (Apply). Новая зона появится в списке SDN сетей, а для подключения к виртуальной сети в списке устройств станет доступен новый мост с именем этой сети.

📚 Дополнительные материалы по теме

▪️ Официальный туториал от разработчиков Proxmox
▪️ Большая статья по настройке Proxmox кластера на VDS, в том числе с конфигурацией зоны SDN VLAN

P. S. В качестве альтернативы для такой простой задачи можно было использовать логическую сегментацию с помощью VLAN. Достаточно добавить vlan теги в параметрах своего роутера, включить vlan aware и указать теги vlan в параметрах сетевого оборудования виртуалок, что позволит быстро и просто разграничить доступ.

#proxmox

Первая часть про Nuclei

В качестве основной системы буду использовать Kali Linux.
Для проверки работы сканера поднял несколько специальных docker контейнеров, содержащих уязвимости.

🔹 web-dvwa

docker run -d -p 127.0.0.1:4380:80 vulnerables/web-dvwa

🔹 juice-shop

docker run -d -p 127.0.0.1:4480:3000 bkimminich/juice-shop

📚 Еще примеры образов и контейнеров с преднамеренными уязвимостями для обучения и тестирования:
▪️ vulnhub.com - виртуальные машины и образы
▪️ vulnhub github - уязвимые контейнеры с популярными инструментами
▪️ metasploitable-2 - специализированная машина для практики поиска и эксплуатации уязвимостей

🔨 Устанавливаем сканер

sudo apt install nuclei

🔎 Справка по основным параметрам запуска

-u        Указать домен
-l        Список доменов
-t        Указать шаблон
-j        Вывод в формате JSON
-o        Файл для вывода результатов
-irr      Включить пары запрос/ответ в выходной отчет
-rl       Ограничение скорости, макс количество запросов в секунду
-retries  Количество попыток повторения неудачного запроса
-validate Проверка переданных шаблонов для Nuclei
-silent   Отображать только результаты сканирования
-vv       Показать загруженные шаблоны для сканирования
-H        Добавить пользовательский агент
-tags     Сканирование с шаблонами, помеченными определённым тегом
-itags    Включить шаблоны по тегам (переопределяет настройки по умолчанию)
-etags    Исключить шаблоны по тегам
-author   Сканирование с шаблонами от определённого автора
-severity Сканирование с шаблонами определённой степени серьёзности (info, low, medium, high, critical)
-pt       Фильтр по типу протокола

🚀 Выполним простое сканирования одиночных хостов с помощью Nuclei

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

🥷 Сканируем web-dvwa с экспортом отчета в формате markdown

mkdir report_dvwa
nuclei -u 127.0.0.1:4380 -irr -markdown-export ./report_dvwa

[dvwa-default-login] [http] [critical] http://127.0.0.1:4380/index.php [password="password",username="admin"]
[cookies-without-secure] [javascript] [info] 127.0.0.1:4380 ["security","PHPSESSID"]
[exposed-gitignore] [http] [info] http://127.0.0.1:4380/.gitignore
[configuration-listing] [http] [medium] http://127.0.0.1:4380/config/
...

Получаем каждую уязвимость в отдельном markdown-файле с детальной информацией внутри (см. примеры из отчета на скринах).

🥷 Для второго хоста выполняем такое же сканирование, но с отчетом в json

nuclei -u 127.0.0.1:4480 -j -o ./report_juice.json

Ожидал увидеть больше уязвимостей, однако нашлась всего парочка уровня info. Повторил процесс - сканирование завершилось, не успев начаться. Оказывается контейнер отвалился после первого запуска, а причиной тому стало переполнение памяти. 😐 В логах контейнера следующая информация:

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

💡 Попробовал снизить нагрузку на хост во время сканирования корректировкой параметров запуска
▫️Ограничиваем количество шаблонов для запуска (например, ищем только самые важные уязвимости)

nuclei -u 127.0.0.1:4480 -severity high,critical -j -o ./report_juice.json

▫️Снижаем скорость сканирования (флаг -rl - ограничение количества запросов в секунду)

nuclei -u 127.0.0.1:4480 -severity info,low,medium -rl 10 -j -o ./report_juice.json

Процесс отработал полностью в обоих случаях. Критических уязвимостей найдено не было. За счет снижения скорости сканер трудился значительно дольше, однако собрал довольно полную информацию, в том числе обнаружил одну medium уязвимость (см. примеры из отчета на скринах).

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

#security #scan #nuclei