Нужен ли SIEM для небольшого VPS: Wazuh или journald

Нужен ли SIEM небольшому VPS?

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

Решение сводится к двум вопросам. Первый: достаточно ли у вас хостов, чтобы событие на одном нужно было связывать с событием на другом? Второй: будет ли кто-то открывать консоль, настраивать правила и реагировать на увиденное? Если оба ответа «да», SIEM стоит оценить. Если хотя бы один «нет», начните с лёгкой схемы ниже: она же становится основой данных, которая понадобится любому SIEM позже. Что искать внутри самих логов, смотрите в нашем руководстве по мониторингу сервера и анализу логов. Эта статья только о выборе инструмента.

Что такое SIEM и что он делает

SIEM расшифровывается как Security Information and Event Management. Глоссарий NIST со ссылкой на SP 800-92 определяет его как программу, обеспечивающую централизованное ведение журналов для самых разных типов логов. Вторая запись NIST, из SP 800-128, описывает инструмент SIEM как приложение, которое собирает данные безопасности с компонентов системы и представляет их как пригодную для действий информацию через единый интерфейс. Его же ищут как «SIEM система», «SIEM сервер» или с типичной опечаткой «SEIM». «SIEM сервер» это просто центральная машина, принимающая данные, а не отдельный вид продукта.

На практике SIEM решает пять задач: собирает логи с агентов или через syslog, хранит их централизованно, применяет правила обнаружения, сопоставляет события из разных источников и поднимает оповещения, на которые можно реагировать. NIST SP 800-92 добавляет два полезных замечания: стандартов именно для SIEM нет, поэтому каждый продукт хранит данные в своём формате, а трафик между агентом и сервером в таких продуктах обычно шифруется поверх TCP. Краткое определение смотрите в статье глоссария про SIEM.

Когда SIEM избыточен

SIEM окупается за счёт корреляции и ежедневной работы. Вот ситуации, где этой ценности нет:

• Мало хостов. Корреляция связывает события между системами. С одним сервером связывать нечего, а при двух-пяти те же логи часто можно читать в одном центральном месте.
• Оповещения никто не читает. Панель, которую никто не открывает, ничего не обнаруживает. Письмо с оповещением, которое обработали, полезнее простаивающей платформы.
• Платформа тяжелее нагрузки. В кратком руководстве Wazuh для конфигурации до 25 агентов указаны 4 vCPU, 8 GiB ОЗУ и 50 ГБ диска на 90 дней данных. Это, вероятно, больше, чем небольшой VPS, за которым вы хотите следить.
• Нет времени на настройку. Правила обнаружения нужно подгонять под ваш трафик, иначе они создают шум, а шум игнорируют.
• Нет требований соответствия. Если договор или закон не требует поиска по хранимым логам и документированных оповещений, достаточно лёгкого пути.

SIEM также не заменяет узкие инструменты. fail2ban по-прежнему блокирует перебор паролей, описанный в нашем руководстве по защите от перебора SSH, а уровень предотвращения вторжений по-прежнему действует до того, как логи вообще прочитаны.

Лёгкая альтернатива: journald и логи вне сервера

Суть идеи SIEM доступна на любом VPS: храните логи, которые переживут инцидент, и держите копию там, куда злоумышленник не дотянется. Тот, у кого есть root на скомпрометированном хосте, может править и удалять локальные логи, поэтому именно копия вне сервера делает след заслуживающим доверия.

Шаг 1: сделайте журнал постоянным. Согласно руководству journald.conf(5), значение Storage= по умолчанию определяется при сборке systemd, а режим auto пишет на диск, только если существует каталог /var/log/journal. Явное значение снимает неоднозначность. Файлы-дополнения читаются из /etc/systemd/journald.conf.d/, а все параметры находятся в секции [Journal]:

[Journal]
Storage=persistent
SystemMaxUse=500M

Сохраните это как /etc/systemd/journald.conf.d/persistent.conf и выполните sudo systemctl restart systemd-journald. По руководству, SystemMaxUse= по умолчанию равен 10% файловой системы с ограничением в 4G и принимает суффиксы вроде M и G, так что выберите размер под ваш диск. Результат проверяется параметрами из journalctl(1). Основы смотрите в статье глоссария про journalctl:

journalctl --list-boots
journalctl --disk-usage
journalctl -u ssh --since yesterday -p warning

Юнит называется ssh в Debian и Ubuntu и sshd в семействе RHEL. Параметр -p warning показывает этот уровень и все более важные.

Шаг 2: пересылайте копию на другую машину. Документация omfwd говорит, что TCP часто используют для надёжной доставки, для современных развёртываний рекомендует TCP с TLS и предупреждает, что обычный TCP не всегда может определить, какие сообщения дошли при обрыве соединения. Для гарантированной доставки предлагается протокол RELP через модуль omrelp. Пересылка по TLS из примеров omfwd выглядит так:

action(
    type="omfwd"
    target="logs.example.com"
    port="6514"
    protocol="tcp"
    StreamDriver="ossl"
    StreamDriverMode="1"
    StreamDriverAuthMode="x509/name"
    StreamDriverPermittedPeers="logs.example.com"
)

На приёмнике нужна соответствующая настройка TLS. Руководство rsyslog по TLS использует анонимную аутентификацию только для быстрого старта и указывает, что входящие в комплект тестовые сертификаты не предназначены для продакшена, поэтому создайте собственный центр сертификации и сертификаты. Принимающий хост должен принимать соединения только от ваших серверов. Затем проверьте весь путь командой logger и найдите строку на приёмнике. Сам демон описан в статье глоссария про rsyslog. Учтите, что journald передаёт сообщения демону syslog через ForwardToSyslog=, и по руководству по умолчанию включена только пересылка в wall, поэтому проверка через logger это ваше доказательство того, что сообщения действительно доходят.

Простые оповещения без SIEM

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

• Уведомления fail2ban. Действие action по умолчанию в jail.conf только блокирует. В файле также определено action_mwl: оно блокирует, отправляет письмо с отчётом whois и включает подходящие строки лога. Значение mta по умолчанию равно sendmail, поэтому нужна рабочая почтовая настройка. Стандартные значения: maxretry = 5 за findtime = 10m, а джейл sshd отключён, пока вы его не включите. В jail.local:

  [DEFAULT]
  action = %(action_mwl)s
  
  [sshd]
  enabled = true

  Укажите свои значения destemail и sender в том же файле. Настройка разобрана в нашем руководстве по fail2ban.
• Сводки Logwatch. Его руководство называет его настраиваемой модульной системой мониторинга логов. Он поддерживает --detail с уровнями low, med и high, --range, например Yesterday, --output со значениями stdout, mail или file и --mailto. Ежедневной сводки о произошедшем часто хватает владельцу одного сервера.
• Проверки целостности файлов. Мониторинг целостности файлов через AIDE сообщает, когда меняются системные бинарные файлы или конфигурация. Отправляйте его отчёт за пределы сервера, иначе злоумышленник сможет его отредактировать.

Для более глубоких данных о том, кто и что запускал, следующим источником стоит добавить демон аудита Linux; см. статью глоссария про auditd. Держите оповещения редкими и конкретными, как описано в нашем руководстве по мониторингу, чтобы каждое прочитывалось.

Когда переходить на Wazuh

Wazuh это бесплатная платформа с открытым исходным кодом, которая, по словам её собственной документации, объединяет возможности XDR и SIEM. Так что да, он считается SIEM, а также включает мониторинг целостности файлов, анализ данных логов, обнаружение уязвимостей и оценку конфигурации. Цена вопроса в том, что вам придётся самим эксплуатировать небольшую платформу.

Страница об архитектуре описывает четыре компонента:

• Агент работает на каждой отслеживаемой конечной точке и передаёт данные безопасности на сервер. Страница об агенте указывает в среднем около 35 МБ ОЗУ и что версия менеджера должна быть равна версии агента или новее.
• Сервер декодирует события и сопоставляет их с правилами.
• Индексатор хранит проанализированные данные.
• Панель даёт оповещения и визуализацию.

Агенты по умолчанию подключаются к серверу по TCP 1514 и регистрируются по TCP 1515, а сообщения по умолчанию шифруются с помощью AES. Сервер отправляет данные в индексатор на порт 9200, а панель обращается к API сервера по TCP 55000. Все компоненты можно разместить на одном хосте (all-in-one), по одному на хост (single-node) или собрать в кластер (multi-node).

Для оценки размеров краткое руководство даёт требования для all-in-one: 4 vCPU, 8 GiB ОЗУ и 50 ГБ для конфигурации до 25 агентов с данными за 90 дней; 8 vCPU, 8 GiB и 100 ГБ для конфигурации от 26 до 50 агентов; 8 vCPU, 8 GiB и 200 ГБ для конфигурации от 51 до 100 агентов. Для центральных компонентов перечислены Ubuntu с 16.04 по 24.04, RHEL с 7 по 10, Amazon Linux 2 и 2023 и CentOS Stream 10. Для пяти серверов это стоит запускать на отдельном хосте, а не на одном из наблюдаемых.

Его модуль FIM выполняет базовое сканирование, а затем сообщает о несовпадении контрольных сумм или атрибутов. По документации Wazuh, сканирование по умолчанию выполняется каждые 12 часов (43200 секунд), а мониторинг в реальном времени включается для каталога отдельно:

<syscheck>
  <directories realtime="yes">/etc</directories>
</syscheck>

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

Хранение логов и защита от подмены

Хранение. Совместное предупреждение CISA AA22-131A рекомендует всем организациям хранить самые важные логи не менее шести месяцев, отмечая, что обнаружение инцидентов может занять месяцы. Там же рекомендуется обособленный контур логирования. NIST SP 800-92 оставляет точные сроки на усмотрение вашей политики и законодательных требований. Считайте шесть месяцев важных логов (аутентификация, sudo, веб-сервер, межсетевой экран) целевым объёмом и включайте архив в план резервного копирования 3-2-1.

Защита от подмены. Выстраивайте защиту слоями:

• Копия вне сервера. Это главный контроль. Исходный стандарт syslog не имеет средств защиты конфиденциальности и целостности, как отмечено в SP 800-92, поэтому используйте TLS или RELP и закрытый приёмник.
• Запечатывание журнала. Команда journalctl --setup-keys создаёт пару ключей Forward Secure Sealing. Ключ запечатывания остаётся на хосте, а ключ проверки следует хранить снаружи. Затем journalctl --verify --verify-key=KEY проверяет подлинность. Запечатывание нацелено на обнаружение изменений и не даёт второй копии.
• Контрольные суммы архивов. SP 800-92 описывает безопасное хранение дайджеста архивных файлов логов, чтобы последующие изменения были замечены.
• Отдельные учётные данные. У приёмника логов не должно быть общих административных ключей с серверами, с которых он собирает данные.

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

Список для выбора: что подойдёт вам

• Один-два сервера, логи читаете сами: постоянный журнал, копия вне сервера, fail2ban с уведомлениями и плановая проверка AIDE. SIEM не нужен.
• Три-пять серверов, один администратор: то же самое плюс центральный хост логов, куда пересылаются записи, и ежедневная сводка Logwatch. Wazuh пробуйте на свободной машине, только если вам нужны его правила и панель.
• Несколько серверов и один человек, отвечающий за обнаружение: Wazuh на отдельном хосте это разумный выбор. Заложите ресурсы по описанным выше данным, время на настройку правил и обновление агентов.
• Договор или закон требует поиска по хранимым логам и документированных оповещений: SIEM, свой или управляемый, потому что вы обязаны предъявить доказательства.
• Ни у кого нет времени читать оповещения: не покупайте больше инструментов. Сравните самостоятельную работу с передачей её другим в нашем сравнении управляемой безопасности и самостоятельной.

Чек-лист безопасности VPS показывает, где логирование стоит рядом с межсетевым экраном, SSH и обновлениями, что обычно важнее любой платформы.

План внедрения в шесть шагов

1. Сделайте журнал постоянным и подтвердите это командой journalctl --list-boots после следующей перезагрузки.
2. Пересылайте логи вне сервера по TLS, затем докажите доставку через logger и поиск на приёмнике.
3. Добавьте оповещения: уведомления fail2ban, сводку Logwatch и плановую проверку целостности, отчёт которой уходит с сервера.
4. Задайте срок хранения в шесть месяцев для важных логов и рассчитайте под него диск приёмника.
5. Опробуйте Wazuh на временном хосте с одним-двумя агентами по кратком руководству. Проверьте, что получаемые оповещения такие, на которые вы бы реагировали.
6. Решайте по списку выше. Если оставляете Wazuh, открывайте только порты, перечисленные на странице об архитектуре, и только для тех хостов, которым они нужны.

Не уверены, что сейчас открыто на ваших серверах? Аудит только для чтения покажет текущее состояние, ничего не меняя.