Server Admin Авторский блог системного администратора
Давно была идея реализовать простую и быструю проверку базовых параметров безопасности сервера с помощью 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
Конфигурационный файл лежит в директории /etc/lynis. Если говорить в терминологии программы, то это будут настройки профиля. Хранятся они в файле default.prf. Вы можете сделать несколько разных профилей и выбирать их с помощью ключей при запуске программы. Без указания профиля, загружается default.prf.
Запуск проверки безопасности сервера с помощью Lynis выполняется следующим образом:
# lynis audit system
Он будет продолжаться значительное время. В конце вы увидите обширный список рекомендаций. Все их проверять не имеет большого смысла. Реальную пользую представляют замечания в статусе Warnings. Обратите внимание именно на них.
В моём примере я получил 2 предупреждения:
- KRNL-5830. Суть его в том, что у меня установлены обновления ядра, но я не перезагрузил систему, чтобы их применить.
- 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
Если в проверке были 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
У нас всё готово для настройки мониторинга. Перемещаемся в веб интерфейс Zabbix Server.
Настройка мониторинга безопасности в Zabbix
На самом сервере мониторинга нам потребуется минимум настроек. Надо создать шаблон, создать в нём два элемента данных, которые будут собирать информацию из текстовых файлов. И сделать один триггер, которые будет срабатывать, если увидит Warnings в текстовом файле. Причём элемент данных со статусом выхода Lynis не обязателен. Можно обойтись и без него. Я добавил на всякий случай для сбора дополнительной информации. Мало ли, пригодится.
Добавляем новый шаблон, создаём айтем.
Сколько хранить историю и как часто проверять, смотрите сами. На картинке 5 минут сделано для отладки. В обычной работе можно реже, например, раз в час. Для этого же айтема в предобработке я добавил шаг Отбрасывать не изменившееся. Это существенно уменьшает занимаемое место в базе данных. Нет смысла сохранять одно и то же содержимое.
В шаблон добавлен макрос {$SCRIPT_DIR}, он же используется в ключе. Если у вас директория отличается от /etc/zabbix/scripts, то поменяйте макрос в моём шаблоне, который будет ниже. Второй элемент данных для кода выхода приложения аналогичен.
Далее сделан один триггер:
Если нет строки All is OK, триггер срабатывает. На почту приходит уведомление, где в тексте перечислены все предупреждения и уязвимые пакеты. Очень удобно сразу увидеть всю полезную информацию.
Можете загрузить мой готовый шаблон: Lynis_Security_Check.yaml Он выгружен с версии сервера 6.0.
На этом у меня всё. Настроили связку локальной утилиты Lynis и сервера мониторинга Zabbix. Теперь если на сервере что-то пойдёт не так с точки зрения Lynis, получите уведомление.
Заключение
Если у вас есть идеи, как подобную функциональность оформить более красиво, поделитесь в комментариях. Также было бы интересно узнать, как похожие проверки реализовать с помощью Zabbix, но с использованием других бесплатных средств. Я ничего лучше не придумал, хотя давно в голове крутятся идеи по реализации подобных проверок.
На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.
У меня были проблемы в 16 строке и выводе даты. Поправил немного скрипт:
#!/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
echo $exitcode > "$pwd"/lynis-exitcode.txt
{
grep "warning" < /var/log/lynis-report.dat
grep "Found vulnerable package" > "$pwd"/lynis-warnings.txt
else
echo $exitcode > "$pwd"/lynis-exitcode.txt
{
echo "All is OK"
echo -n "Check ended "
/usr/bin/date +"%Y-%m-%d %H:%M:%S"
} >> "$pwd"/lynis-warnings.txt
fi
Так этот скрипт проверяет сам сервер на котором крутится Zabbix или проверяет все хосты которые Zabbix мониторит?
Он проверяет те хосты, где настроен скрипт и где подключен шаблон на сервере.
Здравствуйте! Вопрос не по теме но если сможете помочь, буду счастлив. Срабатывает триггер на заполненность диска - 89-90% и так каждую минуту. Можно как то прописать чтоб тригер срабатывал не сразу же, а допустим, через пол часа если реально больше 90%. инфу не нашел по этой теме или не правильно искал. Спасибо.
Можно настроить отложенные оповещения. У меня есть статья на эту тему: https://serveradmin.ru/nastroyka-otlozhennyih-uvedomleniy-v-zabbix/
Но тут лучше с триггером что-то сделать и настроить его так, чтобы было удобно. Он может быть с набором разных условий, что и приводит к спаму.
Надо скрипт, который в конце вызывает 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, если в момент отправки были проблемы со связью. С учётом того, что проверки выполняются не так часто, можно очень поздно получить информацию о каких-то проблемах, если сервер скомпрометирован. С логом более надёжно получается.
А если использовать 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. Посчитал это более надёжным и стабильным вариантом.