Home » Zabbix » Мониторинг ssh логинов в zabbix

Мониторинг ssh логинов в zabbix

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

Введение

Все будет сделано очень просто. Я буду мониторить системный log файл, который содержит информацию о ssh подключениях. В rpm дистрибутивах, в частности, в Centos это /var/log/secure. В deb дистрибутивах Debian/Ubuntu это /var/log/auth.log.

Вначале у меня была идея хранить полностью этот лог в zabbix для разбора каких-то инцидентов на сервере. Это может быть актуально, если у вас нет централизованного сбора логов в каком-то отдельном месте. Потом передумал, так как если у вас используется стандартный ssh порт 22, то лог подключений по ssh будет огромного размера. Хранить его полностью в zabbix — забивать понапрасну базу данных. В итоге решил хранить только информацию об успешных авторизациях.

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

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

# chgrp zabbix /var/log/secure
# chmod 640 /var/log/secure

и то же самое делаем в Debian/Ubuntu

# chgrp zabbix /var/log/auth.log
# chmod 640 /var/log/auth.log

На хосте все готово. Все остальное делаем на сервере мониторинга.

Если у вас еще нет своего сервера для мониторинга, то рекомендую материалы на эту тему. Для тех, кто предпочитает систему CentOS:

  1. Установка CentOS 7.
  2. Настройка CentOS 7.
  3. Установка и настройка zabbix сервера.

То же самое на Debian 9, если предпочитаете его:

  1. Установка Debian 9.
  2. Базовая настройка Debian 9.
  3. Установка и настройка zabbix на debian.

Шаблон для мониторинга за SSH подключениями

Я подготовил простой шаблон, который состоит из:

  1. Элемента данных SSH auth, с ключом log[/var/log/secure,»^.*sshd.*(Accepted|closed).*»,,,,,] и типом данных — Журнал (лог) Итем для парсинга лога ssh
  2. Триггера с условием {SSH Auth:log[/var/log/secure,»^.*sshd.*(Accepted|closed).*»,,,,,].str(Accepted,#1)}=1, который ищет в элементе данных строку Accepted и срабатывает, если ее находит. Триггер для отправки уведомлений о ssh подключении
Не забудьте проверить, где у вас в системе находится лог с информацией о ssh авторизациях, и заменить этот путь в элементе данных.

На практике это все выглядит так. Когда вы подключаетесь по ssh на сервер, в zabbix приходит следующая информация.

Мониторинг за лог файлом ssh подключений

Если включен триггер, то на почту получите уведомление, где сразу в тексте уведомления будет видно пользователя и адрес, с которого он подключился к серверу. Это удобно.

Оповещение о подключении к серверу

После того, как пользователь завершит свой сеанс, получите еще одно уведомление.

Уведомление об отключении от сервера

Данный шаблон просто небольшая заготовка. Условия триггеров, собираемые элементы лога вы можете сами настраивать так, как вам хочется. Можно по аналогии мониторить другие логи.

Скачиваем шаблон для версии 3.4 тут ssh-auth.xml. С другими версиями не проверял.

Заключение

Не понравилась статья и хочешь научить меня администрировать? Пожалуйста, я люблю учиться. Комментарии в твоем распоряжении. Расскажи, как сделать правильно!

Пару слов о мониторинге логов. Для парсинга лога используется регулярное выражение. В данном случае такое: ^.*sshd.*(Accepted|closed).* В это условие попадают все строки, где присутствует слово sshd и обязательно одно из Aceepted или closed. Если будете менять условия парсинга, или возьмете вообще другой лог, то нужно будет подготовить другое регулярное выражение.

Помогла статья? Есть возможность отблагодарить автора

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

  1. Есть еще один путь, это используя файл в самой ssh sshrc, в нём указываешь скрипт который будет запускаться во время логина юзера по ssh. У меня например используется ссылка на скрипт баша /etc/ssh/scripts/ssh_notif в котором идёт разборка.
    »
    #!/bin/bash
    usr=$USER
    ip_con=»$SSH_CONNECTION»
    ip_con_it=»sed ‘s/\(.*\) \(.*\) \(.*\) \(.*\)’ $ip_con»
    echo «$usr»
    echo «$ip_con_it»
    «

    • Не очень понял, как все это работает? Скрипт запускается во время логина пользователя, а дальше что?

      • Дмитрий

        ну это не тот скрипт который в работе тот который в работе отправляет смс на админов о подключении.

  2. Аноним

    Спалил свой ssh порт для брутфорса 😀

    • Вообще, он у меня везде разный. Тут в логе не тот порт, что нужен. Это локальный у исходящего подключения.

  3. Андрей

    Добрый день. Сделал как вы описали. Мне пишет в Zabbix: Not supported by Zabbix Agent Что я могу пропустить или сделать не правильно? Я экспортировал ваш файлик с настройками, результат тот же.

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

      • Андрей

        Это все что мне показывают логи
        1296:20180822:094445.315 item «router:log[/var/log/auth.log,»^.*sshd.*(Accepted|closed).*»,,,,,]» became not supported: Not supported by Zabbix Agent
        1297:20180822:094446.318 item «router_kharkov:log[/var/log/auth.log,»^.*sshd.*(Accepted|closed).*»,,,,,]» became not supported: Not supported by Zabbix Agent
        1295:20180822:100852.237 item «router:log[/var/log/auth.log,»^.*sshd.*(Accepted|closed).*»,,,,,]» became not supported: Not supported by Zabbix Agent
        1297:20180822:100854.239 item «router_kharkov:log[/var/log/auth.log,»^.*sshd.*(Accepted|closed).*»,,,,,]» became not supported: Not supported by Zabbix Agent

        • А через web интерфейс, если нажать в списке итемов на сообщение с ошибкой, показано описание ошибки. Я сталкивался с ошибкой «too many arguments». В этом случае я просто убирал все запятые после регулярного выражения в ключе итема. Он становился таким:
          log[/var/log/secure,»^.*sshd.*(Accepted|closed).*»]

          • Андрей

            Нет, описания нет. Пишет только: «Not supported by Zabbix Agent».Интересно то, что на zabbix сервере все работает. Непонятно толь потому что там Centos а на другом сервере Debian, толи потому что zabbix сам себя мониторит.

          • Привет! У меня точно такая же проблема «too many arguments» , Я заново редактировал все свои шаблоны, у меня Ubuntu редактировал вот так » log[/var/log/auth.log,»^.*sshd.*(Accepted|closed).*»] » . а дальше ни какой информация не собирается, хотя ошибка «too many arguments» исчезнет.

            Может быть покажете свой изменённый шаблон 🙂

            • А это все изменения и есть. Буквально на днях настраивал на пачке серверов мониторинг ssh. Залил свой шаблон и на половине серверов увидел как раз такую же ошибку. Не стал разбираться, с чем связано, просто убрал все запятые в настройке итема. Стало вот так:

              log[/var/log/secure,"^.*sshd.*(Accepted|closed).*"]

              После этого все заработало.

              • Да 🙂 из-за кавычек не работало, всё решил! Спасибо.

                Я потом настроил телеграмм «смс», в котором приходит в основном, информация о том, что:

                Subj: Problem: SSH authentication on OpenVPN-srv
                Message:Problem started at 11:54:09 on 2018.10.03
                Problem name: SSH authentication on OpenVPN-srv
                Host: OpenVPN-srv
                Severity: Information

                тут же не плохо было бы сделать так, чтобы на телеграмм пришла ещё и имя user, который вошёл в систему, ну конечно эта в самом Zabbix есть, но в телеграмм….

  4. Аноним

    Не хотели бы дополнить статью мониторингом логов из journalctl? Раньше аналогично вашей статье мониторил логи на центосе, сейчас перешли на дистрибутив где логи хранятся в journalctl — было бы интересно почитать как там это организовать.

  5. Привет! есть проблема, после выхода система видимо пишет в файл и меняет права на root/root и снова нет прав на файл, есть идеи как решить проблему?

  6. Добрый день, А Вы тестировали данный функционал на Zabbix 4? У меня Zabbix 4.0.1 и клиент и сервер. xml скачан и установлен. Но в логе постоянно вот такая ошибка:

    18258:20181109:124233.094 active check "log[/var/log/secure,"^.*sshd.*(Accepted|closed).*"]" is not supported: Cannot open file "/var/log/secure": [13] Permission denied
     18258:20181109:125633.345 active check "log[/var/log/secure,"^.*sshd.*(Accepted|closed).*"]" is not supported: Cannot open file "/var/log/secure": [13] Permission denied
     18258:20181109:131033.594 active check "log[/var/log/secure,"^.*sshd.*(Accepted|closed).*"]" is not supported: Cannot open file "/var/log/secure": [13] Permission denied
     18258:20181109:132433.844 active check "log[/var/log/secure,"^.*sshd.*(Accepted|closed).*"]" is not supported: Cannot open file "/var/log/secure": [13] Permission denied
     18258:20181109:133833.101 active check "log[/var/log/secure,"^.*sshd.*(Accepted|closed).*"]" is not supported: Cannot open file "/var/log/secure": [13] Permission denied
     18258:20181109:135233.360 active check "log[/var/log/secure,"^.*sshd.*(Accepted|closed).*"]" is not supported: Cannot open file "/var/log/secure": [13] Permission denied
    Группа Zabbix, права 640, хотя уже пробовал и 644 - ничего не изменилось! (-rw-r-----. 1 root   zabbix    27554 ноя  9 13:59 secure)

    Есть идеи?

    • В логе четко написано, что у zabbix агента не хватает прав на чтение файла. Надо разбираться, почему.

      • В debug = 5 лог следующий:
        9712:20181110:143247.865 __zbx_zbx_setproctitle() title:’active checks #1 [getting list of active checks]’
        9712:20181110:143247.865 In refresh_active_checks() host:’127.0.0.1′ port:10051
        9712:20181110:143247.867 sending [{«request»:»active checks»,»host»:»srv»}]
        9712:20181110:143247.868 before read
        9712:20181110:143247.878 got [{«response»:»success»,»data»:[{«key»:»log[/var/log/secure,\»^.*sshd.*(Accepted|closed).*\»]»,»delay»:60,»lastlogsize»:0,»mtime»:0}]}]
        9712:20181110:143247.878 In parse_list_of_checks()
        9712:20181110:143247.879 In add_check() key:’log[/var/log/secure,»^.*sshd.*(Accepted|closed).*»]’ refresh:60 lastlogsize:0 mtime:0
        9712:20181110:143247.879 End of add_check()
        9712:20181110:143247.879 End of parse_list_of_checks():SUCCEED
        9712:20181110:143247.880 End of refresh_active_checks():SUCCEED
        9712:20181110:143247.880 __zbx_zbx_setproctitle() title:’active checks #1 [processing active checks]’
        9712:20181110:143247.880 In process_active_checks() server:’127.0.0.1′ port:10051
        9712:20181110:143247.881 In process_logrt() flags:0x06 filename:’/var/log/secure’ lastlogsize:0 mtime:0
        9712:20181110:143247.881 In add_logfile() filename:’/var/log/secure’ mtime:1541849429 size:35450
        9712:20181110:143247.881 add_logfile() logfiles:0x55bebcc45b00 logfiles_alloc:64
        9712:20181110:143247.881 End of add_logfile()
        9712:20181110:143247.882 End of process_logrt():FAIL
        9712:20181110:143247.882 active check «log[/var/log/secure,»^.*sshd.*(Accepted|closed).*»]» is not supported: Cannot open file «/var/log/secure»: [13] Permission denied
        9712:20181110:143247.882 In process_value() key:’srv:log[/var/log/secure,»^.*sshd.*(Accepted|closed).*»]’ value:’Cannot open file «/var/log/secure»: [13] Permission denied’
        9712:20181110:143247.883 In send_buffer() host:’127.0.0.1′ port:10051 entries:0/100
        9712:20181110:143247.883 End of send_buffer():SUCCEED
        9712:20181110:143247.883 buffer: new element 0
        9712:20181110:143247.884 End of process_value():SUCCEED
        9712:20181110:143247.884 End of process_active_checks()
        9712:20181110:143247.884 In get_min_nextcheck()
        9712:20181110:143247.884 End of get_min_nextcheck():-1
        9712:20181110:143247.885 __zbx_zbx_setproctitle() title:’active checks #1 [idle 1 sec]’
        9708:20181110:143248.138 __zbx_zbx_setproctitle() title:’collector [processing data]’
        9708:20181110:143248.139 In update_cpustats()
        9708:20181110:143248.139 End of update_cpustats()
        9708:20181110:143248.140 __zbx_zbx_setproctitle() title:’collector [idle 1 sec]’
        9709:20181110:143248.230 __zbx_zbx_setproctitle() title:’listener #1 [processing request]’
        9709:20181110:143248.231 Requested [vfs.fs.size[/boot,used]]
        9709:20181110:143248.231 In zbx_execute_threaded_metric() key:’vfs.fs.size’
        12197:20181110:143248.234 executing in data process for key:’vfs.fs.size’
        9709:20181110:143248.240 End of zbx_execute_threaded_metric():SYSINFO_SUCCEED »
        9709:20181110:143248.240 Sending back [258117632]
        9709:20181110:143248.240 __zbx_zbx_setproctitle() title:’listener #1 [waiting for connection]’
        9712:20181110:143248.885 In send_buffer() host:’127.0.0.1′ port:10051 entries:1/100
        9712:20181110:143248.886 JSON before sending [{«request»:»agent data»,»session»:»e5652652057c9fb7810286f25e91ca49″,»data»:[{«host»:»srv»,»key»:»log[/var/log/secure,\»^.*sshd.*(Accepted|closed).
        *\»]»,»value»:»Cannot open file \»/var/log/secure\»: [13] Permission denied»,»state»:1,»id»:2,»clock»:1541849567,»ns»:883980887}],»clock»:1541849568,»ns»:886882096}]
        9712:20181110:143248.888 JSON back [{«response»:»success»,»info»:»processed: 1; failed: 0; total: 1; seconds spent: 0.000418″}]
        9712:20181110:143248.888 In check_response() response:'{«response»:»success»,»info»:»processed: 1; failed: 0; total: 1; seconds spent: 0.000418″}’
        9712:20181110:143248.889 info from server: ‘processed: 1; failed: 0; total: 1; seconds spent: 0.000418’

        Может SeLinux всему виной?

        • Проблема была в SeLinux, вылечилось так:
          # cat /var/log/audit/audit.log | grep zabbix_agentd | grep denied | audit2allow -M zabbix_agent_secure
          # semodule -i zabbix_agent_secure.pp
          # systemctl restart zabbix-agent.service

          После этого письма приходят. Все работает. Только почему-то не такие как у Вас:

          Problem started at 21:36:27 on 2018.11.10
          Problem name: SSH authentication on server
          Host: server
          Severity: Information

          Original problem ID: 546

          Problem has been resolved at 21:37:27 on 2018.11.10
          Problem name: SSH authentication on server
          Host: server
          Severity: Information

          Original problem ID: 546

          Подскажите, что-то может не так настроил в скрипте или в Zabbix?

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

Ваш e-mail не будет опубликован.

Нажимая кнопку "Отправить комментарий" Я даю согласие на обработку персональных данных.