Zabbix: логировать stdout+stderr zabbix_sender; успех при failed: 0 в ответе

Made-with: Cursor

README.md

@@ -1,25 +1,30 @@
 # ssh-monitor
 
-Bash-скрипт мониторинга SSH/SUDO с уведомлениями в Telegram, опциональным резервным webhook, авто-блокировкой IP (IPv4 через `iptables`, IPv6 через `ip6tables` при наличии) и ежедневным отчётом.
+Bash-скрипт мониторинга **SSH**, **SUDO** и событий **`systemd-logind`** (локальные/графические сессии и др.) с уведомлениями в Telegram, опциональным резервным webhook, авто-блокировкой IP (IPv4 через `iptables`, IPv6 через `ip6tables` при наличии) и ежедневным отчётом.
 
 ## Конфигурация
 
 Скрипт читает параметры из `/etc/ssh-monitor.conf` в формате `KEY="value"`.
 
 1. Скопируйте пример:
-   - `sudo cp ./ssh-monitor.conf.example /etc/ssh-monitor.conf`
+ - `sudo cp ./ssh-monitor.conf.example /etc/ssh-monitor.conf`
 2. Ограничьте доступ:
-   - `sudo chmod 600 /etc/ssh-monitor.conf`
-3. Заполните минимум:
-   - `TELEGRAM_BOT_TOKEN`
-   - `TELEGRAM_CHAT_ID`
+ - `sudo chmod 600 /etc/ssh-monitor.conf`
+3. Заполните минимум — **хотя бы один канал доставки оповещений** (иначе скрипт сразу завершится с ошибкой; см. абзац **«Обязательное условие»** ниже и раздел **«Каналы оповещений и пустой NOTIFY_CHAIN»**):
+ - для **Telegram**: `TELEGRAM_BOT_TOKEN` и `TELEGRAM_CHAT_ID`;
+ - или настройте **Zabbix** / **почту** по переменным ниже при `NOTIFY_ORDER=""` (автовыбор каналов).
+
+**Обязательное условие:** после загрузки конфигурации в цепочке **`NOTIFY_CHAIN`** должен быть **минимум один** канал (`telegram`, `zabbix` или `email`). Если каналов **нет** (пустой `NOTIFY_ORDER` и ни Telegram, ни Zabbix, ни SMTP не удовлетворяют критериям «настроен», либо в `NOTIFY_ORDER` остались только неизвестные имена), скрипт **не входит** в основной цикл и завершается с кодом **1**, в stderr: **`Не настроен ни один канал отправки оповещений`**. Это же правило действует для **`--check-config`** и **`--dry-run`**. Резервный **`BACKUP_WEBHOOK_URL`** в эту проверку **не входит** — он используется только если **ни один** канал из **`NOTIFY_CHAIN`** не смог доставить сообщение.
 
 Поддерживаемые параметры:
 
 - `TELEGRAM_BOT_TOKEN`, `TELEGRAM_CHAT_ID`
-- `BACKUP_WEBHOOK_URL` — резервная доставка JSON `{"text":"..."}` (например Slack Incoming Webhook), если Telegram недоступен или вернул ошибку
-- `LOG_FILE`, `LAST_HEARTBEAT_FILE`, `LAST_REPORT_FILE`, `LAST_SSH_CHECK_FILE`, `LAST_SUDO_CHECK_FILE`, `LAST_SECURITY_EVENTS_FILE`, `BAN_LIST_FILE`
-- `DAILY_REPORT_HOUR` (0..23), `DAILY_REPORT_TZ` (опционально), `DAILY_REPORT_TOP_IPS`
+- `NOTIFY_ORDER` — список каналов (`telegram`, `zabbix`, `email` и сокращения **tg**, **zbx**, **mail**); при каждом оповещении скрипт **пытается отправить во все перечисленные** каналы по порядку (не «первый успешный — и стоп»). Пусто = в цепочку попадают только настроенные каналы (порядок по умолчанию см. в `ssh-monitor.conf.example`). Если итоговая цепочка пуста — скрипт не стартует (см. раздел **«Каналы оповещений и пустой NOTIFY_CHAIN»**).
+- `ZABBIX_SERVER`, `ZABBIX_HOST_NAME`, `ZABBIX_ALERT_KEY`, `ZABBIX_SEQ_KEY` — отправка в Zabbix через `zabbix_sender`; подробнее — раздел **«Zabbix (`zabbix_sender`)»** ниже
+- `BACKUP_WEBHOOK_URL` — резервная доставка JSON `{"text":"..."}` (например Slack Incoming Webhook), если **все** каналы из **`NOTIFY_CHAIN`** не смогли доставить сообщение; **не заменяет** обязательность хотя бы одного основного канала (см. шаг 3)
+- `LOG_FILE`, `LAST_HEARTBEAT_FILE`, `LAST_REPORT_FILE`, `LAST_SSH_CHECK_FILE`, `LAST_SUDO_CHECK_FILE`, `LAST_SECURITY_EVENTS_FILE`, `LAST_LOGIND_CHECK_FILE`, `BAN_LIST_FILE`
+- `ENABLE_LOGIND_MONITOR`, `LOGIND_NOTIFY_NEW`, `LOGIND_NOTIFY_REMOVED`, `LOGIND_NOTIFY_FAILED`, `LOGIND_SKIP_REMOTE` — см. раздел «Мониторинг systemd-logind» ниже
+- `DAILY_REPORT_HOUR` (0..23), `DAILY_REPORT_TZ` (опционально), `NOTIFY_TZ` (опционально), `SSH_ACCEPT_NOTIFY_DEDUP_SEC`, `DAILY_REPORT_TOP_IPS`
 - `BRUTE_WINDOW_SEC`, `BRUTE_MIN_FAILS`, `BRUTE_NOTIFY_COOLDOWN_SEC`
 - `PROMETHEUS_TEXTFILE_DIR` — каталог для `ssh_monitor.prom` (совместимость с node_exporter textfile collector)
 - `HEALTHCHECK_STATUS_FILE` — путь к JSON-файлу с меткой последней итерации цикла
@@ -33,16 +38,29 @@ Bash-скрипт мониторинга SSH/SUDO с уведомлениями
 
 - `TELEGRAM_BOT_TOKEN` — токен Telegram-бота для отправки уведомлений.
 - `TELEGRAM_CHAT_ID` — ID чата/пользователя, куда отправляются уведомления.
-- `BACKUP_WEBHOOK_URL` — URL для резервной отправки (тело JSON `{"text":"..."}`).
+- `NOTIFY_ORDER` — CSV имён каналов (`telegram`, `zabbix`, `email` или `tg`, `zbx`, `mail`). Для **каждого** оповещения выполняется попытка доставки **во все** перечисленные каналы (при ошибке одного остальные всё равно пробуются; неудачи пишутся в **`LOG_FILE`**). Пустая строка: автоматически собирается цепочка только из реально настроенных каналов (по умолчанию порядок telegram → zabbix → email; критерии «настроен» — **таблица** в разделе **«Каналы оповещений и пустой NOTIFY_CHAIN»**). Если после сборки цепочки **нет ни одного** канала, скрипт **сразу завершается** с ошибкой: **«Не настроен ни один канал отправки оповещений»** (в том числе режим `--check-config` и `--dry-run`).
+- `ZABBIX_SERVER` — имя или IP сервера Zabbix для `zabbix_sender -z` (пусто = канал Zabbix отключён).
+- `ZABBIX_HOST_NAME` — имя **хоста в Zabbix**, как в конфигурации агента/шаблона (`-s` у `zabbix_sender`); должно совпадать с тем, для какого хоста созданы trapper-элементы.
+- `ZABBIX_ALERT_KEY` — ключ **первого** trapper-элемента: в него уходит **текст** оповещения (одна строка, переводы строк заменены пробелами).
+- `ZABBIX_SEQ_KEY` — ключ **второго** trapper-элемента: в него при каждой отправке пишется **монотонно растущий счётчик** (1, 2, 3, … за время работы процесса скрипта). Значение по умолчанию — `ssh.monitor.seq`. Назначение: чтобы Zabbix и триггеры видели **новое значение** даже при **одинаковом** тексте алерта (иначе повтор с тем же текстом может плохо отражаться на логике «изменилось ли значение»); также по счётчику удобнее отслеживать порядок событий. В шаблоне Zabbix нужны **два** элемента типа **Zabbix trapper** с ключами, совпадающими с `ZABBIX_ALERT_KEY` и `ZABBIX_SEQ_KEY` (второй — обычно **числовой**).
+- `BACKUP_WEBHOOK_URL` — URL для резервной отправки (тело JSON `{"text":"..."}`); только fallback при сбое основных каналов, **не засчитывается** как «настроенный канал» (см. шаг 3).
 - `LOG_FILE` — путь к основному лог-файлу скрипта.
 - `LAST_HEARTBEAT_FILE` — файл с timestamp последнего heartbeat-сообщения.
 - `LAST_REPORT_FILE` — дата последнего ежедневного отчёта в формате `YYYY-MM-DD` (старый формат Unix-времени при первом запуске будет автоматически интерпретирован).
 - `LAST_SSH_CHECK_FILE` — файл с меткой времени последней проверки SSH-событий.
 - `LAST_SUDO_CHECK_FILE` — файл с меткой времени последней проверки sudo-событий.
 - `LAST_SECURITY_EVENTS_FILE` — метка последней проверки «тяжёлых» событий безопасности в журнале.
+- `LAST_LOGIND_CHECK_FILE` — метка последней обработки журнала `systemd-logind` (unix-время); при первом запуске подтягивается около 30 минут истории.
 - `BAN_LIST_FILE` — файл состояния банов (IP, время окончания бана и метаданные).
+- `ENABLE_LOGIND_MONITOR` — `1` включает опрос `journalctl -u systemd-logind`, `0` полностью отключает этот блок.
+- `LOGIND_NOTIFY_NEW` — `1` отправлять Telegram при появлении новой сессии в logind (строки вида *New session … of user …*).
+- `LOGIND_NOTIFY_REMOVED` — `1` отправлять Telegram при завершении сессии (*Removed session …*); по умолчанию `0` (только запись в `LOG_FILE`, чтобы не заспамить канал).
+- `LOGIND_NOTIFY_FAILED` — `1` отправлять Telegram по строкам logind, содержащим *failed* (широкий фильтр; при необходимости отключите).
+- `LOGIND_SKIP_REMOTE` — `1` (по умолчанию): для новой сессии logind, если доступен `loginctl`, не отправляется второе Telegram, если сессия уже учтена в **`monitor_ssh`**: при **`Type=ssh`** или если **`Service`** указывает на **sshd** (часто **`Type=tty` + `Service=sshd`**); при пустом ответе `loginctl` делаются короткие повторы. Поставьте `0`, если нужны отдельные алерты logind и для SSH-сессий.
 - `DAILY_REPORT_HOUR` — час (0..23), после наступления которого в **текущих календарных сутках** (в выбранной ниже зоне) отправляется не более одного ежедневного отчёта.
 - `DAILY_REPORT_TZ` — необязательная **IANA**-зона (`Europe/Moscow`, `Asia/Yekaterinburg`, …). Если **пусто**, для отчёта используется та же зона, что и у команды `date` у процесса монитора (как правило, совпадает с `timedatectl` / `/etc/localtime` на сервере). Если сервис запускается с `TZ=UTC` в unit-файле, без `DAILY_REPORT_TZ` отчёт ориентируется на **UTC** — тогда задайте явную зону в конфиге.
+- `NOTIFY_TZ` — **IANA**-зона для строк **«🕐 Время»** в Telegram/Zabbix/email (и аналогичных текстах). **Пусто** — используется **`DAILY_REPORT_TZ`**, если она задана, иначе зона процесса. Частая причина «время в теле сообщения UTC, а в заголовке чата локальное»: в **`ssh-monitor.service`** задано **`Environment=TZ=UTC`** — тогда задайте **`NOTIFY_TZ`** (или **`DAILY_REPORT_TZ`**) на вашу локаль, например `Asia/Vladivostok`.
+- `SSH_ACCEPT_NOTIFY_DEDUP_SEC` — не чаще одного Telegram по **успешному SSH (`Accepted`)** на одну пару **пользователь + IP** за указанное число **секунд** (по умолчанию **5**). Снимает дубли, когда в journal две строки с **разными портами клиента** за один вход. **`0`** — отключить этот антидубль (останется только дедупликация внутри одного прохода `monitor_ssh` по `user|ip|port`).
 - `DAILY_REPORT_TOP_IPS` — сколько IP показывать в топе неудачных попыток за 24 часа.
 - `BRUTE_WINDOW_SEC` — окно (секунды) для оценки «массового» брутфорса по `journalctl`.
 - `BRUTE_MIN_FAILS` — минимум неудачных попыток за окно для тревоги.
@@ -60,6 +78,39 @@ Bash-скрипт мониторинга SSH/SUDO с уведомлениями
 - `WATCHDOG_SERVICE_NAME` — имя systemd-сервиса, который контролирует watchdog (по умолчанию `ssh-monitor.service`).
 - `WATCHDOG_NOTIFY_ON_RECOVERY` — `1` включает служебные сообщения watchdog при штатном состоянии, `0` отключает.
 
+### Каналы оповещений и пустой NOTIFY_CHAIN
+
+Кратко, что считается **настроенным** каналом (только такие попадают в автоматическую цепочку при **`NOTIFY_ORDER=""`**):
+
+| Канал | Условие «настроен» |
+|--------|-------------------|
+| `telegram` | заданы **`TELEGRAM_BOT_TOKEN`** и **`TELEGRAM_CHAT_ID`** |
+| `zabbix` | непустые **`ZABBIX_SERVER`**, **`ZABBIX_HOST_NAME`**, в PATH есть **`zabbix_sender`** |
+| `email` | непустые **`MAIL_SMTP_HOST`**, **`MAIL_FROM`**, **`MAIL_TO`**, в PATH есть **`python3`** |
+
+Если итоговый **`NOTIFY_CHAIN` пуст**, скрипт завершается с сообщением **`Не настроен ни один канал отправки оповещений`** (см. шаг 3 в разделе «Конфигурация» выше).
+
+### Zabbix (`zabbix_sender`)
+
+Канал активен, если в **`NOTIFY_CHAIN`** есть `zabbix`, заданы **`ZABBIX_SERVER`** и **`ZABBIX_HOST_NAME`**, в PATH есть **`zabbix_sender`**.
+
+При отправке формируется временный файл с **двумя** строками в формате `ключ<TAB>значение`:
+
+1. **`ZABBIX_ALERT_KEY`** (по умолчанию `ssh.monitor.alert`) — текст сообщения.
+2. **`ZABBIX_SEQ_KEY`** (по умолчанию `ssh.monitor.seq`) — целое **число-счётчик**, увеличивается на 1 при каждой отправке в Zabbix.
+
+Имеет смысл завести в Zabbix на соответствующем хосте **два trapper-элемента** с этими ключами. Ключ **`ZABBIX_SEQ_KEY`** можно переименовать в конфиге, если в вашем шаблоне приняты другие имена; смысл остаётся тем же: отдельный item под **последовательность**, а не под человекочитаемый текст.
+
+### Мониторинг systemd-logind
+
+- Собираются сообщения юнита **`systemd-logind`** через **`journalctl`** (`-o cat`): новые и завершённые сессии, а также строки с подстрокой *failed* (если включено).
+- Без **`journalctl`** на хосте этот блок **не работает** (как и часть других функций, завязанных на journal).
+- Для разбора «новой сессии» используются типичные англоязычные форматы (`New session … of user …`). При несовпадении формата строка всё равно попадёт в лог с пометкой о неудачном разборе.
+- **`loginctl`** нужен для **`LOGIND_SKIP_REMOTE`**: по `Type` и **`Service`** решается, не дублировать ли Telegram с **`monitor_ssh`** (см. описание `LOGIND_SKIP_REMOTE` выше).
+- **`monitor_ssh`**: события **sshd** читаются из journal преимущественно как **`journalctl _COMM=sshd`** (запасные варианты — юниты `sshd` / `ssh`), строки **`sort -u`**, для **`Accepted`** в одном проходе — дедуп по **пользователь|IP|порт**; между проходами цикла — пауза **`SSH_ACCEPT_NOTIFY_DEDUP_SEC`** для той же пары **пользователь|IP** (см. переменную в конфиге).
+
+Команда **`ssh-monitor --check-config`** выводит актуальные значения, в том числе параметры logind.
+
 ## Режимы запуска
 
 Обычный запуск (root):
@@ -89,10 +140,10 @@ bash -n ./ssh-monitor
 ## Автозапуск через systemd
 
 1. Скопируйте скрипт в постоянное место:
-   - `sudo install -m 750 ./ssh-monitor /usr/local/bin/ssh-monitor`
+ - `sudo install -m 750 ./ssh-monitor /usr/local/bin/ssh-monitor`
 2. Убедитесь, что конфиг есть:
-   - `sudo cp ./ssh-monitor.conf.example /etc/ssh-monitor.conf` (если еще не создан)
-   - `sudo chmod 600 /etc/ssh-monitor.conf`
+ - `sudo cp ./ssh-monitor.conf.example /etc/ssh-monitor.conf` (если еще не создан)
+ - `sudo chmod 600 /etc/ssh-monitor.conf`
 3. Создайте unit-файл `/etc/systemd/system/ssh-monitor.service`:
 
 ```ini
@@ -129,12 +180,14 @@ sudo journalctl -u ssh-monitor -f
 
 ## Ротация логов
 
-Пример для `logrotate` лежит в репозитории: `contrib/logrotate.d/ssh-monitor`. Скопируйте файл в `/etc/logrotate.d/` и при необходимости поправьте пути под ваши `LOG_FILE` / `WATCHDOG_LOG_FILE`.
+Пример для `logrotate` лежит в репозитории: `contrib/logrotate.d/ssh-monitor`. Скопируйте файл в `/etc/logrotate.d/` и при необходимости поправьте пути под ваши `LOG_FILE` / `WATCHDOG_LOG_FILE` и другие файлы состояния в `/var/log/` (в т.ч. `LAST_*`, если решите их ротировать отдельно).
 
 ## Статистика без systemd (`journalctl`)
 
 Для корректного подсчёта событий за последние 24 часа по файлам `/var/log/auth.log*` рекомендуется наличие **Python 3** на сервере. При его отсутствии счётчики в ежедневном отчёте для «классического» syslog могут быть занижены (используется безопасный fallback).
 
+**Мониторинг `systemd-logind`** и другие части, использующие **`journalctl`**, на таких системах **не выполняются** или дают неполные данные — ориентируйтесь на окружение с **systemd** и доступным журналом.
+
 ## Watchdog (автоматическое восстановление)
 
 Watchdog проверяет:
@@ -147,10 +200,10 @@ Watchdog проверяет:
 ### Установка watchdog
 
 1. Установите watchdog-скрипт:
-   - `sudo install -m 750 ./ssh-monitor-watchdog /usr/local/bin/ssh-monitor-watchdog`
+ - `sudo install -m 750 ./ssh-monitor-watchdog /usr/local/bin/ssh-monitor-watchdog`
 2. Создайте unit и timer из примеров:
-   - `sudo cp ./ssh-monitor-watchdog.service.example /etc/systemd/system/ssh-monitor-watchdog.service`
-   - `sudo cp ./ssh-monitor-watchdog.timer.example /etc/systemd/system/ssh-monitor-watchdog.timer`
+ - `sudo cp ./ssh-monitor-watchdog.service.example /etc/systemd/system/ssh-monitor-watchdog.service`
+ - `sudo cp ./ssh-monitor-watchdog.timer.example /etc/systemd/system/ssh-monitor-watchdog.timer`
 3. Примените и запустите timer:
 
 ```bash

ssh-monitor.conf.example

@@ -1,21 +1,72 @@
 TELEGRAM_BOT_TOKEN="replace_with_telegram_bot_token"
 TELEGRAM_CHAT_ID="replace_with_telegram_chat_id"
 
-# Резервный webhook при недоступности Telegram (JSON {"text":"..."}, совместимо со Slack Incoming Webhook)
+# Резервный webhook, если ВСЕ каналы из NOTIFY_CHAIN не смогли доставить сообщение (JSON {"text":"..."}).
+# ВАЖНО: BACKUP_WEBHOOK_URL НЕ заменяет основной канал — без хотя бы одного из telegram/zabbix/email
+# скрипт сразу завершится с ошибкой в stderr: «Не настроен ни один канал отправки оповещений» (код 1),
+# в том числе при --check-config и --dry-run. Сначала настройте Telegram, Zabbix или SMTP ниже.
 BACKUP_WEBHOOK_URL=""
 
+# --- Очередь оповещений (NOTIFY_ORDER) ---
+# CSV: telegram, zabbix, email (или сокращения tg, zbx, mail).
+# При каждом событии скрипт ПЫТАЕТСЯ ОТПРАВИТЬ ВО ВСЕ перечисленные каналы по порядку (не только в первый успешный).
+# Неудача одного канала не отменяет отправку в остальные; подробности — в LOG_FILE (WARN по каналам).
+#
+# Пустая строка NOTIFY_ORDER="" = авто: в цепочку NOTIFY_CHAIN попадают ТОЛЬКО реально настроенные каналы,
+# порядок по умолчанию: telegram → zabbix → email (см. критерии «настроен» в README, раздел про каналы).
+#
+# Если после сборки цепочки каналов список ПУСТ (ни один канал не настроен, либо в NOTIFY_ORDER только
+# неизвестные токены), скрипт НЕ запускает мониторинг и выходит с ошибкой:
+#   Не настроен ни один канал отправки оповещений
+#
+# Примеры явной очереди:
+# NOTIFY_ORDER="telegram,zabbix,email"
+# NOTIFY_ORDER="telegram"
+# NOTIFY_ORDER="zabbix"
+# NOTIFY_ORDER="email"
+NOTIFY_ORDER=""
+
+# Zabbix trapper (zabbix_sender). Нужны ZABBIX_SERVER и ZABBIX_HOST_NAME.
+ZABBIX_SERVER=""
+ZABBIX_HOST_NAME=""
+ZABBIX_ALERT_KEY="ssh.monitor.alert"
+ZABBIX_SEQ_KEY="ssh.monitor.seq"
+
+# SMTP (python3). Для авто-режима почты нужны MAIL_SMTP_HOST, MAIL_FROM, MAIL_TO.
+MAIL_SMTP_HOST=""
+MAIL_SMTP_PORT="587"
+MAIL_SMTP_USER=""
+MAIL_SMTP_PASSWORD=""
+MAIL_FROM=""
+MAIL_TO=""
+MAIL_SMTP_STARTTLS="1"
+MAIL_SMTP_SSL="0"
+
 LOG_FILE="/var/log/ssh_monitor.log"
 LAST_HEARTBEAT_FILE="/var/log/last_heartbeat.txt"
 LAST_REPORT_FILE="/var/log/last_daily_report.txt"
 LAST_SSH_CHECK_FILE="/var/log/last_ssh_check"
 LAST_SUDO_CHECK_FILE="/var/log/last_sudo_check"
 LAST_SECURITY_EVENTS_FILE="/var/log/last_security_events_check"
+LAST_LOGIND_CHECK_FILE="/var/log/last_logind_check"
 BAN_LIST_FILE="/var/log/ssh_bans.txt"
 
+# systemd-logind: 1 = включено, 0 = выключено
+ENABLE_LOGIND_MONITOR="1"
+LOGIND_NOTIFY_NEW="1"
+LOGIND_NOTIFY_REMOVED="0"
+LOGIND_NOTIFY_FAILED="1"
+# 1 = не дублировать Telegram для SSH-сессий logind (Type=ssh или Service=*sshd*; см. README)
+LOGIND_SKIP_REMOTE="1"
+
 DAILY_REPORT_HOUR="9"
 # IANA-зона для «9:00» и календарной даты отчёта; пусто = как у команды date (обычно локаль сервера, см. timedatectl)
 DAILY_REPORT_TZ=""
 DAILY_REPORT_TOP_IPS="5"
+# IANA-зона для «🕐 Время» в Telegram/Zabbix/email. Пусто = как DAILY_REPORT_TZ, иначе зона процесса (часто UTC в systemd — см. README).
+NOTIFY_TZ=""
+# Не чаще 1 успешного SSH (Accepted) в Telegram на пару user+IP за N секунд (разные port в журнале). 0 = только дедуп внутри одного прохода.
+SSH_ACCEPT_NOTIFY_DEDUP_SEC="5"
 
 BAN_TIME="3600"
 MAX_ATTEMPTS="3"