Запуск zabbix-agent`a от root в его конфиге /etc/zabbix/zabbix_agentd.conf  сделал (AllowRoot=1) - не помогает. Может не так? А как дать ему права на запуск iptables через sudoers? Подскажите пож-та команду или .config какой это делается?

От: @dyuk

Запуск zabbix-agent`a от root в его конфиге /etc/zabbix/zabbix_agentd.conf  сделал (AllowRoot=1) - не помогает. Может не так? А как дать ему права на запуск iptables через sudoers? Подскажите пож-та команду или .config какой это делается?

Агент перезапустили после этого? Проверьте через top от какого пользователя он работает. Эта настройка должна действовать. С ней нет проблем.

вывод top: ...

Вопрос решён запуском zabbix-agent от root. Только  начиная с версии 4.0.15 файл сервиса systemd для Zabbix агента в официальных пакетах был обновлен и теперь явно включает директивы для User и Group. Обе директивы заданы значением zabbix.
Это означает, что старая функциональность настройки из под какого пользователя Zabbix агент запускается через zabbix_agentd.conf файл замещена и агент будет запускаться всегда из под пользователя, который указывается в файле сервиса systemd.

Чтобы переопределить это новое поведение, необходимо создать файл /etc/systemd/system/zabbix-agent.service.d/override.conf со следующим содержимым:
[Service]
User=root
Group=root
после чего перезагружаем демонов и сервис zabbix-agent
systemctl daemon-reload
systemctl restart zabbix-agent
И всё начинает работать!

Спасибо за информацию, не знал об этом.

Да, контролировать наличие цепочек fail2ban в iptables конечно оч.хорошо, но интереснее было бы видеть кол-во записей в этих цепочках, ну или общее кол-во записей без разделения. Возможно это прикрутить?, ну как кол-во звонков например...
Удаляешь заблокированного пользователя, а цепочка то остаётся (Chain f2b-VSFTPD в моём примере на скрине)!

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

Ну и  последняя проблема по данному мониторингу:
Не правильно работает мониторинг транков, т.е. вообще не работает - на все запросы выдаёт:
All trunks are online.
В шаблоне всё ок, в триггерах тоже. Скрипт запускается и выполняется, но вывод один и тот же. В чём подвох?

Надо смотреть выражение в скрипте, которое парсит вывод астериска и разбираться, что с ним не так. Он сильно привязан к конкретному выводу в консоль. Возможно у тебя он немного видоизменен, поэтому не срабатывает.

С мониторингом транков разобрался и сразу "нарисовалось" ещё два вопроса:
1. Как сымитировать  перечисленные в статье состояния недоступности транка для проверки работы? Если вводить неправильный пароль, триггер срабатывает правильно, но сразу начинается блокировка аккаунта со стороны провайдера (zadarma), пробовал внести изменения в имя хоста транка, триггер тоже срабатывает, но вывод идёт такой: см.скрин... , т.е. первая запись идёт с именем транка, а дальше просто tranks offline и в сообщение на почту именно это и приходит, а надо имя транка. В случае с неправильным паролем - все сообщения несут имя транка.
Как ещё можно проверить срабатывание по событиям?:

• Request Sent
• No Authentication
• Auth. Sent
• Rejected                                                                                                                                                                  И второй вопрос: Для этого оповещения лучше создать новое "Действие" в настройках или менять шаблон по умолчанию, но ведь тогда и остальные события будут идти по этому шаблону оповещения. И пользователя тогда надо создавать для этого действия... Я правильно понимаю?

1. Для проверки можно еще на фаерволе заблокировать доступ к провайдеру.

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

На iptables не получается - по ip адресу регистрация на zadarma почему то не блокируется, а если блокирую порт 5060 - то триггер не срабатывает, для срабатывания ему надо, как я понимаю, получить изменившийся статус регистрации, а его вообще нет при блокировке порта...