ServerAdmin.ru
26.9K subscribers
189 photos
27 videos
8 files
2.49K links
Авторская информация о системном администрировании.

Информация о рекламе: @srv_admin_reklama_bot
Автор: @zeroxzed

Второй канал: @srv_admin_live
Сайт: serveradmin.ru
Download Telegram
​​На днях реализовал мониторинг безопасности Linux сервера с помощью Lynis и Zabbix. Я давно планировал реализовать что-то подобное, но всё руки не доходили. Lynis делает неплохие проверки, которые легко читаются и понимаются. В нём есть хорошая база, на которую удобно ориентироваться.

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

Основная идея мониторинга — получать оповещения от Zabbix на тему безопасности. В первую очередь интересуют пакеты с уязвимостями, во вторую — права доступа на системные бинари и директории. Ну и всё остальное тоже не будет лишним. Lynis в этом плане хорош, так как закрывает базу. Про его возможности читайте отдельно, не буду сейчас останавливаться.

Основная проблема данной задачи — длительность проверки Lynis. Она может длиться минуту-две. Из-за этого неудобно запускать проверку через Zabbix, ждать вывода и потом его парсить. Нужны очень большие таймауты. К тому же вывод у Lynis очень длинный. Пришлось идти другим путём, менее удобным и гибким — писать bash скрипт, запускать его по таймеру и анализировать вывод.

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

В итоге написал скрипт, результат его работы вывел в 2 текстовых файла:
lynis-exitcode.txt — в Lynis есть отличный параметр error-on-warnings=yes. Если его активировать, то статус выхода lynis после проверки будет ненулевым, если есть какие-то замечания по безопасности. Скрипт выводит exit code команды в этот файл.
lynis-warnings.txt — в этот файл через парсинг лога Lynis я вывожу все его замечания и список пакетов с уязвимостями.

Сам скрипт выложил на pastebin. Я положил его в /etc/zabbix/scripts, туда же кладу логи. Настройте выполнение скрипта через systemd.timers. Мне кажется, достаточно раз в час выполнять или даже реже, пару раз в день.

Далее сделал простой шаблон под Zabbix 6.0 с двумя айтемами типа лог, которые забирают значения из lynis-exitcode.txt и lynis-warnings.txt. И там же один триггер, который срабатывает, если в файле lynis-warnings.txt нет строки All is OK, которую туда пишет скрипт, если exit code после работы Lynis равен 0 (т.е. всё в порядке). Когда срабатывает триггер, на почту прилетает оповещение, в тексте которого есть информация из lynis-warnings.txt, куда записаны предупреждения и список проблемных пакетов.

Для того, чтобы отключить ту или иную проверку на хосте, надо в файл конфигурации Lynis, который живёт по адресу /etc/lynis/default.prf добавить исключения по одному в каждой строке:
skip-test=CRYP-7902
skip-test=PKGS-7392
skip-test=MAIL-8818

Отладка работы примерно так и выглядит. Запускаете скрипт, смотрите результат. Будут какие-то замечания. Сделайте для них исключение и снова запустите скрипт. Так и проверяйте всю последовательность действий вплоть до оповещений. Потом, соответственно, так же на хосте настраиваются исключения, если какие-то проверки для него неактуальны. Например, тест tls сертификатов. Он по какой-то причине очень долго идёт. Я его отключил.

Заметка получилась немного сумбурная. Тема не для новичков, а для тех, кто умеет работать с Zabbix и bash. В коротком очерке её не раскрыть. Надеюсь, получится написать статью. Там уже подробно всё распишу.

Мне понравился результат. Удобно сразу получить информацию о проблеме на почту. Подробную информацию по коду ошибки можно получить либо в полном логе Lynis на самом сервере в файлах /var/log/lynis.log и /var/log/lynis-report.dat или на сайте https://cisofy.com/lynis/controls/ в разделе с описанием проверок.

#zabbix
Написал запланированную статью по настройке интеграции Lynis и Zabbix для оповещения о результатах аудита безопасности системы:

Мониторинг безопасности сервера с помощью Lynis и Zabbix
⇨ https://serveradmin.ru/monitoring-bezopasnosti-servera-s-pomoshhyu-lynis-i-zabbix

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

Решение получилось немного корявое, так как неудобно делать раскатку на много хостов. Приходится добавлять скрипты, настраивать таймер, собирать логи. Плюс, настройки самого Lynis могут быть разные на разных хостах. Менять приходится вручную.

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

#zabbix #security
​​Рассказываю про отличный сервис, который позволит выводить уведомления, к примеру, от системы мониторинга в пуши смартфона или приложение на десктопе. При этом всё бесплатно и можно поднять у себя.

Речь пойдёт про сервис ntfy.sh. Сразу покажу, как им пользоваться, чтобы было понятно, о чём идёт речь. Идёте по ссылке в веб приложение: https://ntfy.sh/app. Разрешаете ему отправлять уведомления. Подписываетесь на новую тему. После этого получаете ссылку вида: ntfy.sh/Stkclnoid6pLCpqU

Теперь идёте в любую консоль и отправляете с помощью curl себе уведомление:

# curl -d "Test Message" ntfy.sh/Stkclnoid6pLCpqU

Получаете оповещение от веб приложения. То же самое можно сделать, установив на смартфон приложение. Сервис бесплатный. При этом серверная часть open source. Вы можете развернуть сервер у себя и отправлять уведомления через него. Есть репозитории под все популярные системы. Инструкция прилагается.

Таким образом любой сервис, умеющий выполнять вебхуки, может без проблем отправлять уведомления вам на смартфон или десктоп. Например, в Zabbix достаточно в способах оповещений добавить новый с типом Webhook, в качестве скрипта использовать примерно следующее:

var response,
  payload,
  params = JSON.parse(value),
  wurl = params.URL,
  msg = params.Message,
  request = new CurlHttpRequest();
  request.AddHeader('Content-Type: text/plain');
  response = request.Post(wurl, msg);

В качестве URL укажите свою подписку в ntfy. Теперь это оповещение можно добавлять пользователям. Им будет приходить уведомление с текстом, который передаёт макрос {ALERT.MESSAGE}.

Либо совсем простой пример для какой-то операции в консоли:

# rsync -a /mnt/data user_backup@10.20.1.1:/backups/srv01 \
 && curl -H prio:low -d "SRV01 backup succeeded" ntfy.sh/Stkclnoid \
 || curl -H tags:warning -H prio:high -d "SRV01 backup failed" ntfy.sh/Stkclnoid

Если бэкап успешен, отправляем одно уведомление, если нет, то другое.

Такой вот простой и удобный сервис.

⇨ Сайт / Исходники

#мониоринг #zabbix #devops
​​У Zabbix вчера была рассылка с новостями. Давно ничего не писал про него, потому что новостей особо не было. Буднично проходили новости об очередных обновлениях и конференциях в разных странах. А в этот раз они немного подробностей дали по поводу новой версии 7.0, у которой уже 3-я альфа вышла. Так что работа идёт и релиз всё ближе.

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

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

Из тех обновлений, что точно будут в 7.0, отмечу:
увеличится поддержка версий до MySQL 8.1 MariaDB 11
появится шаблон для мониторинга за PostgreSQL через ODBC
появится шаблон для Cisco SD-WAN
появится возможность выполнения удалённых команд при активных проверках
некоторые настройки переедут в модальные окна (способы оповещений, скрипты и т.д.)
увеличат возможности обработки в aggregation functions

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

#zabbix
​​Много раз в заметках упоминал про сервис по рисованию различных схем draw.io. Судя по отзывам, большая часть использует именно его в своей работе. Схемы из draw.io относительно легко можно наложить на мониторинг на базе Grafana. Если вы с ней работаете, то особых проблем не должно возникнуть. Если нет, то не скажу, что настройка будет простой. Но в целом, ничего особенного. Мне когда надо было, освоил Grafana за пару дней для простого мониторинга.

Речь пойдёт про плагин к Графане — flowcharting. Он есть в официальном списке плагинов на сайте, так что с его установкой вопросов не должно возникнуть. Сразу скажу, что с помощью этого плагина можно нарисовать схему и связать через через Графану его с мониторингом на Zabbix.

Последовательность настройки схемы с помощью плагина следующая:

1️⃣ Вы берёте схему в draw.io и выгружаете её в xml формате.
2️⃣ Создаёте dashboard в Grafana и добавляете туда панель flowcharting.
3️⃣ Загружаете xml код схемы в эту панель и получаете визуализацию.
4️⃣ Сопоставляете объекты на схеме с объектами в Графане, сразу переименовывая их так, чтобы было удобно.
5️⃣ Дальше к объектам можно добавлять метрики, как это обычно делается в Grafana. Соответственно, в качестве Data Source можно использовать тот же Zabbix.

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

Страница плагина в Grafana
Инструкция по настройке
▶️ Плейлист Flowcharting Grafana (29 видео)

Все видео в плейлисте на португальском языке. Можно включить перевод субтитров на русский. В целом, там важно смотреть, как и что он делает. А что говорит, не так важно. В плейлисте полностью раскрыта тема построения мониторинга с помощью этого плагина. В том числе и в связке с Zabbix (26-й ролик).

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

#мониторинг #zabbix #grafana
​​После публикации про мониторинг Newrelic, где можно наблюдать за каждым процессом в системе в отдельности, решил прикинуть, а как подобное реализовать в Zabbix. Итоговое решение по всем метрикам пока не созрело, но контроль использования памяти уже реализовал. Решил поделиться своими наработками. Может кто-то подскажет другие пути решения задачи.

Прикинул, как снимать метрики. Тут особо не пришлось ломать голову, так как сразу родилась идея с утилитами jc и jq, которые я давно знаю. Взял вывод ps, обернул его в json с помощью jc, отсортировал по метрике rss и вывел top 10:

# ps axu | jc --ps -p | jq 'sort_by(.rss)' | jq .[-10:]
..................................
]
 {
  "user": "servera+",
  "pid": 1584266,
  "vsz": 348632,
  "rss": 109488,
  "tty": null,
  "stat": "S",
  "start": "19:41",
  "time": "0:28",
  "command": "php-fpm: pool serveradmin.ru",
  "cpu_percent": 0.5,
  "mem_percent": 2.7
 },
 {
  "user": "mysql",
  "pid": 853,
  "vsz": 2400700,
  "rss": 782060,
  "tty": null,
  "stat": "Ssl",
  "start": "Aug28",
  "time": "365:40",
  "command": "/usr/sbin/mariadbd",
  "cpu_percent": 1.8,
  "mem_percent": 19.4
 }
]
..........................................

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

Напомню, что у Zabbix свой определённый формат, иерархия и логика работы правил автообнаружения. Чтобы автоматически создавать айтемы, нужно подать на вход json следующего содержания:

[{"{#COMMAND}":"php-fpm7.4"},{"{#COMMAND}":"mariadbd"}.........,{"{#COMMAND}":"smtpd"}]

Такую строку он сможет взять, на основе переданных значений {#COMMAND} создать айтемы. Как мою json от ps приспособить под эти задачи, я не знал. Для этого можно было бы сделать обработку на javascript прямо в айтеме, но мне показалось это слишком сложным для меня путём. Решил всё сделать по старинке на bash.

Взял вот такую конструкцию, которая анализирует вывод ps, формирует удобный список, который можно отсортировать с помощью sort и взять top 10 самых нагруженных по памяти процессов и в итоге вывести только их имена:

# ps axo rss,comm | awk '{ proc_list[$2] += $1; } END { for (proc in proc_list) { printf("%d\t%s\n", proc_list[proc],proc); }}' | sort -n | tail -n 10 | sort -rn | awk '{print $2}'

Далее обернул её в скрипт для формирования json для автообнаружения в Zabbix.

top_mem.discovery.sh:

#!/bin/bash

TOPPROC=`ps axo rss,comm | awk '{ proc_list[$2] += $1; } END { for (proc in proc_list) { printf("%d\t%s\n", proc_list[proc],proc); }}' | sort -n | tail -n 10 | sort -rn | awk '{print $2}'`

JSON=$(for i in ${TOPPROC[@]}; do printf "{\"{#COMMAND}\":\"$i\"},"; done | sed 's/^\(.*\).$/\1/')
printf "["
printf "$JSON"
printf "]"

На выходе получаем то, что нам надо:

[{"{#COMMAND}":"php-fpm7.4"},........{"{#COMMAND}":"smtpd"}]

Сразу же готовим второй скрипт, который будет принимать в качестве параметра имя процесса и отдавать его память (rss).

top_mem.sh:

#!/bin/bash

ps axo rss,comm | awk '{ proc_list[$2] += $1; } END { for (proc in proc_list) { printf("%d\t%s\n", proc_list[proc],proc); }}' | sort -n | tail -n 10 | sort -rn | grep $1 | awk '{print $1}'

Проверяем:
# ./top_mem.sh mariadbd
780840

Добавляем в конфиг zabbix-agent:
UserParameter=top.mem.discovery, /bin/bash /etc/zabbix/scripts/top_mem.discovery.sh
UserParameter=top.mem[*], /bin/bash /etc/zabbix/scripts/top_mem.sh $1

Теперь идём на сервер, создаём шаблон, правило автообнаружения, прототип айтема, графика и сразу делаем панель.

Получилось удобно и функционально. Все нюансы не смог описать, так как лимит на длину поста. Нерешённый момент - особенности реализации LLD не позволяют автоматом закидывать все процессы на один график. Без API не знаю, как это сделать. Текущее решение придумал и опробовал за пару часов.

#zabbix