Home » Мониторинг » Zabbix » Мониторинг безопасности сервера с помощью Lynis и Zabbix

Мониторинг безопасности сервера с помощью Lynis и Zabbix

Давно была идея реализовать простую и быструю проверку базовых параметров безопасности сервера с помощью Zabbix. В итоге придумал реализацию с помощью бесплатной утилиты Lynis, которая выполняет базовую проверку безопасности Linux сервера по списку управляемых проверок. К сожалению, не получилось организовать всё максимально удобно и автоматизированно. Сделал по старинке на скриптах, что в наши дни, конечно, уже не очень смотрится.

Онлайн-курс по устройству компьютерных сетей

На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.

Введение

Основная проблема реализации решения в том, что проверка Lynis выполняется относительно долго (30-90 секунд, может дольше), поэтому неудобно выполнять проверку средствами Zabbix. Нужно выставлять очень большие таймауты, что неудобно и создаёт лишнюю нагрузку. Пришлось проверки выполнять на хостах по расписанию, результат записывать в лог и уже его анализировать в Zabbix. Гораздо удобнее было бы запустить проверку с помощью Zabbix, сразу же распарсить вывод и забрать только нужное. Но у меня так не получилось. Расскажу обо всём по порядку.

Как я уже сказал, использовать буду Lynis — https://github.com/CISOfy/lynis. Open Source проект, есть в базовых репозиториях большинства популярных дистрибутивов. Начнём с его установки и знакомства с возможностями. Все настройки я буду выполнять на Debian 11 и Zabbix 6.0, но принципиальной привязки к системе и версии Zabbix нет. Повторить можно на любой другой системе. Принцип один и тот же.

Установка Lynis на Debian

Установить Lynis на Debian можно через пакетный менеджер:

# apt install lynis

Установка Lynis на Debian

Конфигурационный файл лежит в директории /etc/lynis. Если говорить в терминологии программы, то это будут настройки профиля. Хранятся они в файле default.prf.  Вы можете сделать несколько разных профилей и выбирать их с помощью ключей при запуске программы. Без указания профиля, загружается default.prf.

Запуск проверки безопасности сервера с помощью Lynis выполняется следующим образом:

# lynis audit system

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

Проверка системы с помощью Lynis

В моём примере я получил 2 предупреждения:

  1. KRNL-5830. Суть его в том, что у меня установлены обновления ядра, но я не перезагрузил систему, чтобы их применить.
  2. NETW-2705. В сетевых настройках у меня указан только один DNS сервер, что по мнению стандартной политики безопасности Lynis недостаточно. Рекомендуется установить два.

Если вы считаете, что какие-то предупреждения неактуальны для вас и вы не собираетесь их исправлять, то можете отменить проверки по ним. Для этого в настройки профиля default.prf можно добавить исключения:

skip-test=KRNL-5830
skip-test=NETW-2705

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

  • /var/log/lynis.log - лог проверки с максимально подробной информацией;
  • /var/log/lynis-report.dat - итоговый результат проверки, во многом похожий на вывод в консоль.

Нам понадобится ещё один параметр для интеграции проверок в Zabbix. Lynis умеет менять код завершения работы в зависимости от того, есть у него предупреждения или нет. Если предупреждений нет, код выхода будет 0, если есть, то отличный от нуля. Для этого укажите параметр:

# Show non-zero exit code when warnings are found
error-on-warnings=yes

Теперь можете проверить, как это работает. Запустите тест и по его завершению проверьте код выхода программы с помощью стандартной возможности оболочки bash:

# lynis audit system
# echo $?
78

Exit Code Lynis

Если в проверке были Warnings, то код выхода будет 78. Текущих параметров нам достаточно для интеграции с системой мониторинга Zabbix.

Интеграция Lynis и Zabbix

В Zabbix я бы хотел видеть информацию о Warnings, а также список пакетов с уязвимостями. В Lynis есть отдельная проверка на этот счёт. На основании этого я придумал следующую схему. Выполняется стандартный аудит системы. Если код выхода не 0, то мы проверяем лог файл и отчёт, и забираем оттуда информацию о предупреждениях и уязвимых пакетах.

Для этого я написал простой bash скрипт lynis.sh:

#!/bin/bash

pwd=/etc/zabbix/scripts
/usr/bin/echo -n "Start check " > "$pwd"/lynis-warnings.txt
/usr/bin/date +"%Y-%m-%d %H:%M:%S" >> "$pwd"/lynis-warnings.txt
/usr/sbin/lynis audit system -q

exitcode=$?

if [[ $exitcode != 0 ]]; then
    /usr/bin/echo $exitcode > "$pwd"/lynis-exitcode.txt
    {
     /usr/bin/grep "warning" < /var/log/lynis-report.dat
     /usr/bin/grep "Found vulnerable package" < /var/log/lynis.log /usr/bin/echo -n "Check ended " /usr/bin/date +"%Y-%m-%d %H:%M:%S" } >> "$pwd"/lynis-warnings.txt

else
    /usr/bin/echo $exitcode > "$pwd"/lynis-exitcode.txt
    {
     /usr/bin/echo "All is OK"
     /usr/bin/echo -n "Check ended "
     /usr/bin/date +"%Y-%m-%d %H:%M:%S"
    } >> "$pwd"/lynis-warnings.txt
fi

Скрипт создаёт 2 текстовых файла: lynis-exitcode.txt и lynis-warnings.txt. В первый записывается код выхода программы, во второй — предупреждения или All is OK, если предупреждений нет. Запись All is OK будет проверять триггер в Zabbix. Если её не найдёт, то будет срабатывать.

Данный скрипт необходимо настроить на регулярное исполнение. Интервал выбирайте сами по своим потребностям. Я считаю, что часто делать такие проверки не имеет большого смысла. В своей инфраструктуре я их выполняю каждые 3 часа. Для запуска можно использовать cron или systemd timers. Я использую таймеры. Постепенно отказываюсь от cron, хотя конкретно в этой ситуации проще воспользоваться cron.

Создаём службу lynis-check.service для запуска скрипта, который я положил в директорию /etc/zabbix/scripts.

# systemctl edit --force --full lynis-check.service
[Unit]
Description=Start Lynis check system
Wants=lynis-check.service

[Service]
Type=oneshot
ExecStart=/etc/zabbix/scripts/lynis.sh

[Install]
WantedBy=multi-user.target

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

# systemctl start lynis-check.service

Если всё в порядке, то создаём для службы таймер.

# systemctl edit --force --full lynis-check.timer
[Unit]
Description=Start Lynis check every 3 hours
Requires=lynis-check.service

[Timer]
Unit=lynis-check.service
OnCalendar=00/3:30
RandomizedDelaySec=5m

[Install]
WantedBy=timers.target

Запускаем таймер и добавляем в автозагрузку:

# systemctl start lynis-check.timer
# systemctl enable lynis-check.timer

Регулярная проверка Lynis по расписанию

У нас всё готово для настройки мониторинга. Перемещаемся в веб интерфейс Zabbix Server.

Настройка мониторинга безопасности в Zabbix

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

Добавляем новый шаблон, создаём айтем.

Интеграция Lynis и Zabbix

Сколько хранить историю и как часто проверять, смотрите сами. На картинке 5 минут сделано для отладки. В обычной работе можно реже, например, раз в час. Для этого же айтема в предобработке я добавил шаг Отбрасывать не изменившееся. Это существенно уменьшает занимаемое место в базе данных. Нет смысла сохранять одно и то же содержимое.

Настройка айтема

В шаблон добавлен макрос {$SCRIPT_DIR}, он же используется в ключе. Если у вас директория отличается от /etc/zabbix/scripts, то поменяйте макрос в моём шаблоне, который будет ниже. Второй элемент данных для кода выхода приложения аналогичен.

Далее сделан один триггер:

Триггер для проверок Lynis

Если нет строки All is OK, триггер срабатывает. На почту приходит уведомление, где в тексте перечислены все предупреждения и уязвимые пакеты. Очень удобно сразу увидеть всю полезную информацию.

Оповещение на почту от Zabbix об уязвимых пакетах

Можете загрузить мой готовый шаблон: Lynis_Security_Check.yaml Он выгружен с версии сервера 6.0.

На этом у меня всё. Настроили связку локальной утилиты Lynis и сервера мониторинга Zabbix. Теперь если на сервере что-то пойдёт не так с точки зрения Lynis, получите уведомление.

Заключение

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

Онлайн-курс по устройству компьютерных сетей.

На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.

Помогла статья? Подписывайся на telegram канал автора

Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.

Автор Zerox

Владимир, системный администратор, автор сайта. Люблю настраивать сервера, изучать что-то новое, делиться знаниями, писать интересные и полезные статьи. Открыт к диалогу и сотрудничеству. Если вам интересно узнать обо мне побольше, то можете послушать интервью. Запись на моем канале - https://t.me/srv_admin/425 или на сайте в контактах.

8 комментариев

  1. Здравствуйте! Вопрос не по теме но если сможете помочь, буду счастлив. Срабатывает триггер на заполненность диска - 89-90% и так каждую минуту. Можно как то прописать чтоб тригер срабатывал не сразу же, а допустим, через пол часа если реально больше 90%. инфу не нашел по этой теме или не правильно искал. Спасибо.

  2. Антоне

    Надо скрипт, который в конце вызывает zabbix_Sender и через него необходимые данные отсылает

    https://anykey.road-of-life.ru/%d0%bc%d0%be%d0%bd%d0%b8%d1%82%d0%be%d1%80%d0%b8%d0%bd%d0%b3-%d0%b4%d0%be%d0%bb%d0%b3%d0%be%d0%b8%d0%b3%d1%80%d0%b0%d1%8e%d1%89%d0%b8%d1%85-%d0%bf%d1%80%d0%be%d1%86%d0%b5%d1%81%d1%81%d0%be%d0%b2/

    • Это первое, что мне пришло в голову. Но я не знаю, как отрабатывает sender, если в момент отправки были проблемы со связью. С учётом того, что проверки выполняются не так часто, можно очень поздно получить информацию о каких-то проблемах, если сервер скомпрометирован. С логом более надёжно получается.

  3. Владимир

    А если использовать zabbix agent (Активный) и передавать информацию в zabbix после выполнения скрипта?

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

    • А как это поможет, если агент будет активный? Если планировщик остановится, то агент так же будет отправлять старые данные из логов.

      • Владимир

        Сделал у себя так

        #!/bin/bash
        /usr/sbin/lynis audit system -q
        exitcode=$?
        result="0"
        if [ $exitcode != 0 ];then
        result=$(/usr/bin/grep 'Warning:' /var/log/lynis.log)
        else
        result="All is OK"
        zabbix_sender -vv -c /etc/zabbix/zabbix_agentd.conf -s "zabbix_item" -k "lynis" -o "$result"?
        fi

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Нажимая кнопку "Отправить комментарий" Я даю согласие на обработку персональных данных.
Используешь Telegram? Подпишись на канал автора →
This is default text for notification bar