Если у вас стоит задача собрать небольшое количество текстовых логов в одном месте, то городить современные решения типа Loki, ELK, Graylog избыточно. Это и долго, и разбираться надо, если не умеешь, и по ресурсам затратно. Предлагаю старую, простую и проверенную временем альтернативу - syslog-ng. Я этот софт давно знаю и использую по мере необходимости.

Покажу пример простой настройки, которую можно взять за основу и расширить при необходимости. Устанавливаем:

# apt install syslog-ng

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

Открываем конфигурацию /etc/syslog-ng/syslog-ng.conf и добавляем один параметр, который позволит принимать логи по сети от других устройств и систем:

source s_net { udp(ip(0.0.0.0) port(514)); };

Можно выбрать любой IP адрес сервера, порт и протокол. Я указал стандартный порт UDP 514 для протокола syslog. Никто не мешает использовать что-то другое. Например TCP 1000:

source s_net { TCP(ip(0.0.0.0) port(1000)); };

Переходим в папку /etc/syslog-ng/conf.d и создаём там конфиг для приёма логов, например, с Mikrotik:

destination d_mikrotik { file("/var/log/_remote/mikrotik.log"); };
filter f_mikrotik { netmask("10.20.1.20/255.255.255.255"); };
log { source(s_net); filter(f_mikrotik); destination(d_mikrotik); };

Файл назвал mikrotik.conf. В syslog-ng объектный принцип описания конфигурации. Этот как раз то, почему я предпочитаю для таких задач использовать именно его, а не rsyslog. У последнего не такой удобный формат конфигурации.

Я создал объект d_mikrotik, который указывает на хранение логов в файле /var/log/_remote/mikrotik.log. Далее я сделал фильтр f_mikrotik, где указал в качестве условия IP адрес роутера. Можно и всю подсеть добавить. И в завершении указал, как именно будем логировать. Берём источник s_net, то есть всё, что приходит на UDP 514, проверяем по фильтру f_mikrotik и пишем в d_mikrotik, то есть в указанный лог-файл.

С таким подходом удобно настраивать что, куда и по каким условиям писать. Можно несколько source указать с разными интерфейсами, протоколами и портами. Если у вас устройства разнесены по разным подсетям, то можно описать приём в два разных лог-файла логи от Mikrotik и от Linux систем:

destination d_mikrotik { file("/var/log/_remote/mikrotik.log"); };
filter f_mikrotik { netmask("10.20.1.0/255.255.255.0"); };
log { source(s_net); filter(f_mikrotik); destination(d_mikrotik); };

destination d_linux { file("/var/log/_remote/linux.log"); };
filter f_linux { netmask("10.30.1.0/255.255.255.0"); };
log { source(s_net); filter(f_linux); destination(d_linux); };

По умолчанию syslog-ng работает от root, что не очень разумно и в данной задаче не нужно. Запустим его от пользователя syslog. Если вас это не беспокоит, то можно запускать и под root.

# useradd syslog -s /usr/sbin/nologin
# chown syslog /var/lib/syslog-ng /var/log/_remote

Добавляем в /etc/default/syslog-ng:

SYSLOGNG_OPTS="-u syslog -g syslog"
if [ ! -e /var/lib/syslog-ng.pid ] then
  touch /var/lib/syslog-ng.pid
fi
chown syslog /var/lib/syslog-ng.pid
chmod 0664 /var/lib/syslog-ng.pid

В файле /etc/syslog-ng/syslog-ng.conf меняем пользователя в параметрах:

owner("root"); group("adm")

на

owner("syslog"); group("syslog")

Идём на конечное устройство настраивать отправку логов. В Mikrotik это делается в System ⇨ Logging ⇨ Actions. В remote указываете IP адрес сервера с syslog-ng.

В системах Linux с rsyslog достаточно в /etc/rsyslog.conf добавить параметр:

*.* @10.20.1.5

и перезапустить его.

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

Для просмотра логов через браузер можно использовать tailon, logdy, cockpit, webmin.

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

#logs #syslog

С момента первого моего упоминания сервиса axiom.co, продолжаю его использовать. Вновь пишу о нём, чтобы рассказать тем, кто не видел эту информацию. Очень простой в настройке и удобный в использовании для хранения и анализа логов веб сервера. Я пользуюсь полностью бесплатным тарифом, который не требует никаких подтверждений и персональных данных. Аутентификация через учётку на github. При этом позволяет хранить 500GB логов в месяц. Мне этого за глаза.

Про настройку и использование я уже писал ранее. По настройке с тех пор ничего не поменялось. Для отправки используется Vector (иногда падает, надо мониторить и переподнимать), у него встроенная интеграция с axiom.

Axiom условно можно назвать аналогом ELK, только сильно урезанным в плане функциональности. Из-за этого его особо не надо изучать. Отправляешь туда логи, заходишь и мышкой создаёшь нужные дашборды, запросы, отчёты. С ELK так не получится. В новых версиях даже заходить не хочется в виджеты и дашборды. Каждый раз, как первый раз, приходится вспоминать, как тут что-то сделать и построить нужную визуализацию.

Например, я позавчера включил на сайте протокол HTTPv3. Решил сходить посмотреть, сколько запросов по этому протоколу выполняется. Сбор логов настроен по указанной выше ссылке. В веб интерфейсе axiom иду в раздел Query и мышкой в конструкторе строю запрос: Dataset = serveradmin.ru, Where != http_version, Summarize count(), group by http_version.

['serveradmin.ru']
| where isnotempty(http_version)
| summarize count() by bin_auto(_time), http_version

И получил график растущего использования HTTPv3. Протокол используется.

Или вот ещё пример. Посмотрим, по каким url на запросы выходят 404 коды ответов. Dataset = serveradmin.ru, Where status =~ "404", Summarize count(), group by url.

['serveradmin.ru']
| where status =~ "404"
| summarize count() by bin_auto(_time), url

Думаю, идея понятна. В сервисе ничего такого особенного нет, чего нельзя было бы сделать где-то в другом месте. То же самое можно сделать в ELK, Graylog, Loki, Goaccess. Но тут всё бесплатно, ничего настраивать не надо. Просто оправляем логи и пользуемся. Разумеется, если у вас там ничего секретного нет. А то уже предвижу комментарии на тему того, что я свои секретные логи веб сервера никому показывать не могу. Если не можете, то не используйте облачные сервисы. Тут всё очевидно. Наверняка они эти данные как-то используют, иначе откуда такая щедрость.

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

#logs #webserver

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

Отдельно перечислю особенности VictoriaLogs:

▪️По своей сути это одиночный бинарник, который можно сконфигурировать ключами запуска, не нужен даже конфигурационный файл.
▪️В бинарнике есть всё, что надо для сбора и просмотра логов: веб интерфейс, метрики для мониторинга за системой, все типы приёмников логов.
▪️Для бэкапа достаточно скопировать директорию с данными, например, с помощью rsync. То есть вообще никаких проблем и заморочек с бэкапом.
▪️Есть плагин для datasource в Grafana, чтобы делать оттуда запросы к логам, а также готовый дашборд для визуализации метрик хранилища.
▪️Простая, короткая документация, где есть всё необходимое для запуска и настройки.

Покажу примеры сбора логов в VictoriaLogs от Journald, Syslog и Vector. Для этого подготовил небольшой docker-compose.yml с некоторыми параметрами:

services:
  victoria-logs:
    image: victoriametrics/victoria-logs:latest
    volumes:
      - ./victoria-logs-data:/victoria-logs-data
    command:
      - --storageDataPath=/victoria-logs-data
      - --retentionPeriod=90d
      - --syslog.listenAddr.tcp=:514
    ports:
      - 9428:9428
      - 514:514
    restart: always

Запускаем проект, переходим на порт 9428, чтобы убедиться в том, что всё запустилось. По умолчанию открывается страница с некоторыми ссылками на Web UI, Метрики и ключи запуска.

Отправим в VictoriaLogs логи от systemd от любого сервера, локального или внешнего. Для этого понадобится служба systemd-journal-remote. Ставим её:

# apt install systemd-journal-remote

Редактируем конфиг /etc/systemd/journal-upload.conf, добавляя один параметр:

[Upload]
URL=http://localhost:9428/insert/journald

URL, соответственно, измените, если у вас сбор логов не с локального сервера, а удалённого. Запускаем службу и проверяем, что она успешно начала отправку логов:

# systemctl start systemd-journal-upload
# systemctl status systemd-journal-upload

Идём в веб интерфейс VictoriaLogs - http://212.193.59.87:9428/select/vmui и смотрим там логи.

Переходим к Syslog. Я уже добавил параметр syslog.listenAddr.tcp=:514. Убедитесь, что указанный порт прослушивается:

# ss -tulnp | grep 514

Если у вас этот порт уже занят syslog сервером, то измените порт для VictoriaLogs. В общем-то настраивать больше ничего не надо. Теперь в любом софте, который умеет отправлять данные в формате syslog, укажите в качестве сервера IP вашего VictoriaLogs. Например, в том же Микротике: System ⇨ Logging ⇨ Actions ⇨ Add Type Remote.

Для сбора логов от всех популярных агентов, типа Filebeat, Fluentd, Vector и т.д. тоже ничего специально настраивать не надо. Делаете всё точно так же, как для отправки логов в Elasticsearch, только в качестве endpoint указываете URL от вашего сервера VictoriaLogs. Вот пример для Vector:

sinks:
  vlogs:
    inputs:
      - nginx_access_logs
    type: elasticsearch
    endpoints:
      - http://212.193.59.87:9428/insert/elasticsearch/
    api_version: v8
    compression: gzip

Решение очень понравилось своей простотой, универсальностью и скоростью настройки. Буквально за час со всем разобрался и настроил. Никаких затруднений. Отдельно нужно решать вопрос доступа к приёмнику логов и веб интерфейсу. С уровня приложения никаких решений нет. Нужно либо firewall, либо proxy использовать.

Отдельно отмечу, что те же логи syslog и journald сразу парсятся по основным полям, типа hostname, time, cmdline и т.д. Ничего для этого настраивать не надо. Сразу в веб интерфейсе можно поиск и группировку по ним делать. Получается очень функциональное решение по простоте и скорости настройки на уровне обычного syslog сервера, но с гораздо большими возможностями.

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

#logs #devops

Недавно из комментариев узнал про систему RuSIEM. Она относится к классу продуктов SIEM (Security Information and Event Management). Я в целом далёк от темы безопасности и связанным с этим софтом, так как это отдельное направление в IT. Эта система привлекла меня тем, что у неё есть полностью бесплатная версия RvSIEM, которая занимается только сбором и обработкой логов, анализируя их на наличие содержимого, связанного с защитой и безопасностью.

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

RvSIEM умеет принимать логи из различных систем: веб сервера, операционные системы (в том числе Windows), СУБД, почтовые сервера, шлюзы, сетевые устройства и т.д. Она их автоматически парсит, если используются стандартные шаблоны логов этих приложений и собирает по ним аналитику. Например, вычленяет из них IP адреса источников, информацию об учётных данных, если речь идёт о логине, статусы и критичности событий из логов приложений и т.д.

Всё это стекается в общее хранилище на базе Elasticsearch и ClickHouse, там анализируется и строятся отчёты. Например, можно вывести сквозной список всех IP адресов, с которых были подключения, которые не относятся к IP адресам РФ. Можно сделать отдельный отчёт по логинам RDP или в админку самой RvSIEM. Причём отчёты можно выгружать в различных форматах: PDF, DOCX, XSLX, CSV.

Есть стандартные преднастроенные фильтры и отчёты. Можно писать свои. То же самое и к парсерам относится. Используются grok фильтры для парсинга, как в Logstash. С ними нетрудно разобраться и распарсить свой формат логов. Я в своё время это освоил, когда надо было. Управление всё через веб интерфейс, в консоль ходить не обязательно.

Рассказываю, как я всё это установил. Пошёл на сайт и в разделе скачать оставил заявку. На следующий день мне прислали на почту мою учётную запись в ЛК с документацией всей системы RuSIEM. Там есть все ссылки и инструкции на загрузку. Используется общий установщик, а конкретно установку RvSIEM выбираешь при его запуске.

С установкой проблем не возникло, там всё просто. Инструкция на русском, сделал по ней. Хотя по сути там нужно просто скачать скрипт и запустить его. Дальше установщик всё делает сам. Он работает на базе ролей Ansible. Никаких лицензий потом получать не надо.

Дам одну существенную рекомендацию по настройкам Elasticsearch. Он по умолчанию съедает всю оперативную память и его прибивает OOM Killer. У меня было 4GB памяти, сделал 8GB, не помогло, сделал 12GB - тоже не помогло. Elasticsearch регулярно падал, хотя в тестовой системе нагрузки никакой не было. Мне это надоело и я в файл /etc/elasticsearch/jvm.options.d/rusiem.jvm.options добавил настройки:

-Xms4g
-Xmx4g

Они ограничивают потребление в 4GB, что для небольшой нагрузки достаточно. После этого система стала стабильно работать.

RvSIEM умеет собирать логи разными способами. В основном это syslog, NetFlow и свой агент, в том числе для Windows. То есть настройка простая. Например, в Angie можно напрямую отправить логи в RvSIEM в формате syslog:

access_log syslog:server=10.20.1.9:5014,facility=local7,tag=angie,severity=info
error_log syslog:server=10.20.1.9:5014,facility=local7,tag=angie,severity=info

Основное ограничение бесплатной версии - 500 EPS (events per second). Не знаю, что тут конкретно имеется ввиду. Наверное, суммарное количество строк логов в секунду.

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

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

#logs #security #отечественное