Comments 29
Добавьте в ваш пост тег habracut, ну пожалуйста!
Извиняюсь, забыл ;)
В zabbix (и не только) много чего «можно». Гораздо интересней было бы если бы поделились готовыми шаблонами для мониторинга типовых событий информационной безопасности.
Пишу совершенно не туда, чтобы меня «услышало» Хабрасообщество. Кто-нибудь, напишите, пожалуйста, статью про всю эту историб с Лентачом.
да, zabbix очень гибок в плане добавления кастомных вещей, я как-то года два назад запилил простецкий мониторинг дырявых пакетов для redhat систем (на гитхабе).
Спасибо за статью!
Два момента:
1. Файлы вроде /etc/passwd проще всего мониторить на изменения через vfs.file.cksum, не нужны будут костыли в zabbix_agentd.conf
2. Логи сетевых устройств мониторить аналогично юниксовым, пересылая их на сислог сервер в иерархию вроде /var/log/cisco/$IP/log и уже оттуда читая заббиксом.
Два момента:
1. Файлы вроде /etc/passwd проще всего мониторить на изменения через vfs.file.cksum, не нужны будут костыли в zabbix_agentd.conf
2. Логи сетевых устройств мониторить аналогично юниксовым, пересылая их на сислог сервер в иерархию вроде /var/log/cisco/$IP/log и уже оттуда читая заббиксом.
Но зачем? Есть же специальные, мощные, удобные и красивые инструменты, как коммерческие, так и open-source, например OSSIM или LOGalyze.
Меня например Zabbix прежде всего подкупает своей гибкостью и возможностью приспособиться под любые капризы как отдела безопасности так и отдела технической поддержки, ну и конечно же понятно написанной документацией.
Заббикс — великолепный продукт, его достоинств никто не умаляет.
Речь о том, что нет смысла проделывать вагон ручной работы только для того, чтобы получить 10-20% от того, что предлагают другие (в том числе и открытые) продукты сразу из коробки. Инструменты призваны сократить объем ручного труда, а не увеличить его.
Речь о том, что нет смысла проделывать вагон ручной работы только для того, чтобы получить 10-20% от того, что предлагают другие (в том числе и открытые) продукты сразу из коробки. Инструменты призваны сократить объем ручного труда, а не увеличить его.
В моем случае статья о том как использовать Zabbix как систему мониторинга ИБ в дополнение к его основным задачам. Я не утверждаю что это лучший способ. Он скорее для тех кто хочет иметь единую систему. Думаю что у всех продуктов есть свои плюсы и минусы. Тут уже выбирать конечному пользователю.
Но все же хочу заметить что Zabbix можно превратить в очень мощный инструмент мониторинга ИБ. 10-20% от того что предлагают другие из коробки далеко не показатель, да и ручного труда как такогого в процессе настройки нет, один раз настроить шаблоны сильно не сказывается на трудозатратах. ;)
Но все же хочу заметить что Zabbix можно превратить в очень мощный инструмент мониторинга ИБ. 10-20% от того что предлагают другие из коробки далеко не показатель, да и ручного труда как такогого в процессе настройки нет, один раз настроить шаблоны сильно не сказывается на трудозатратах. ;)
Да благие намерения очевидны, только вот на выходе получается еще одно «кое-как», нестандартное, немасштабируемое и не развиваемое производителем в этом направлении. Обычно в профессиональных кругах такое называют словом «костыль». Костыль может быть хорошим, удобным и любимым, но не перестает от этого быть собой.
Ну вот например коды событий в логе windows меняются периодически (менялись при переходе от 2003 на 2008, потом еще менялись 2008->2012). Кто будет следить за этим в заббиксе? Правильно, никто, только тот, кто это и реализовал, если не забудет или не забьет на это через полгода. Тоже самое и с остальными источниками событий, с изменением версий ПО меняется и формат лога, меняются способы логирования и передачи логов во вне и все в таком духе. Производители специализированных решений следят за этим, коммьюнити пользователей следит за этим (если не успевает производитель), в итоге систему гораздо проще подерживать в актуальном состоянии, гораздо проще подключать новые источники событий, проще масштабировать систему, как результат — задача решается качественее с на порядки меньшими усилиями.
А вот преимуществ сабжа я не вижу вообще никаких, кроме уже озвученного «ну я так привык к заббиксу, что хочу там и мониторинг очереди в столовую сделать и корпоративный документооборот». Через некоторое время такая система либо превращается в засохшую тыкву, либо при попытках развития упирается в архитектурные ограничения. Ну и начинаем делать все заново, уже на подходящих решениях. Итог — потраченное время и усилия, но зато набиты некоторые шишки, которых, впрочем, можно и нужно было избежать.
Впрочем, это всего лишь скромное мнение человека, который последние несколько лет профессионально занимается системами сбора, анализа и корреляции событий ИБ, к этому мнению вовсе необязательно прислушиваться.
Ну вот например коды событий в логе windows меняются периодически (менялись при переходе от 2003 на 2008, потом еще менялись 2008->2012). Кто будет следить за этим в заббиксе? Правильно, никто, только тот, кто это и реализовал, если не забудет или не забьет на это через полгода. Тоже самое и с остальными источниками событий, с изменением версий ПО меняется и формат лога, меняются способы логирования и передачи логов во вне и все в таком духе. Производители специализированных решений следят за этим, коммьюнити пользователей следит за этим (если не успевает производитель), в итоге систему гораздо проще подерживать в актуальном состоянии, гораздо проще подключать новые источники событий, проще масштабировать систему, как результат — задача решается качественее с на порядки меньшими усилиями.
А вот преимуществ сабжа я не вижу вообще никаких, кроме уже озвученного «ну я так привык к заббиксу, что хочу там и мониторинг очереди в столовую сделать и корпоративный документооборот». Через некоторое время такая система либо превращается в засохшую тыкву, либо при попытках развития упирается в архитектурные ограничения. Ну и начинаем делать все заново, уже на подходящих решениях. Итог — потраченное время и усилия, но зато набиты некоторые шишки, которых, впрочем, можно и нужно было избежать.
Впрочем, это всего лишь скромное мнение человека, который последние несколько лет профессионально занимается системами сбора, анализа и корреляции событий ИБ, к этому мнению вовсе необязательно прислушиваться.
Я бы с радостью почитал статью от Вас на тему мониторинга событий ИБ, в предложенных Вами продуктах. ;)
Я бы с радостью написал. Но есть дилемма. Статья, на которую у меня хватит времени, получится очень обзорно-поверхностной и может даже быть сочтена за рекламную, да и пользы от нее не будет. Более-менее раскрыть тему можно только циклом довольно обширных статей, но на это у меня времени катастрофически не хватает. Периодически я пишу фокусные статьи в специализированные издания, но для Хабра, опять же, это не подойдет.
Косвенно мои слова подтверждаются тем, что даже смежная ИТ-ИБ статья с заббиксом вызвала лишь жалкий отлик, да и то, только среди ИТ-шников. Ни одного ИБ-шника, с которым можно построить диалог, в этой теме нет до сих пор — мой подробный комментарий с аргументами просто получил молчаливые минусы (от фанатов заббикса, видимо?) и никаких возражений или аргументов. Это также подтверждает мою мысль о том, что местная аудитория не нуждается в материале такого рода, да и не готова к нему.
Не хочу Вас разочаровывать, но на данный момент 233 человека добавили статью к себе в избранное. Соответственно посчитав данный материал полезным. Опять же замечу что статья писалась как альтернатива а не как незаменимый инструмент. Ваше мнение — это Ваше мнение, просто старайтесь его не навязывать другим. Считаю дальнейший диалог бесполезной тратой времени. Благодарю за критику.
Вопрос к автору статьи. А можно ли увеличить время жизни триггера на дашборде? А то он живет от последней неудачной попытки + 30с на обновление итема. Увеличение времени обновления итема не вариант.
Для bondbig. Да, заббикс не создан для мониторинга ИБ, но есть люди, которым гораздо приятнее когда все в кучке на 1 ресурсе, в одной программе. А не когда у тебя открыто 10 программ, каждая из которых специализируется на своей области. Для таких людей те самые костыли уместны и дискомфорта не вызывают. имхо.
Для bondbig. Да, заббикс не создан для мониторинга ИБ, но есть люди, которым гораздо приятнее когда все в кучке на 1 ресурсе, в одной программе. А не когда у тебя открыто 10 программ, каждая из которых специализируется на своей области. Для таких людей те самые костыли уместны и дискомфорта не вызывают. имхо.
Ну так о том и речь, что подобные «решения» отвечают интересам конкретного человека (в краткосрочной перспективе), но вредят интересам бизнеса (в средне и долгосрочной). Если это для кого-то не является очевидным, то я попытался объяснить. Я пытаю.сь намекнуть, что неплохо бы развивать стратегическое мышление и стараться видеть чуть дальше, чем «вот прямо сейчас».
В качестве интересной задачки для развлечения и получения некого опыта — да, можно и нужно делать такие вещи. Но интегрировать в бизнес-процессы — нет. Потом будет много боли и слез, когда придется сносить заботливо построенный руками шалашик, чтобы расчистить место для строительства здания.
В качестве интересной задачки для развлечения и получения некого опыта — да, можно и нужно делать такие вещи. Но интегрировать в бизнес-процессы — нет. Потом будет много боли и слез, когда придется сносить заботливо построенный руками шалашик, чтобы расчистить место для строительства здания.
Одно могу сказать, для госструктур не повредят =)
У нас не все так быстро развивается. И скупать каждый год вновь вышедшую винду мы не можем. Хотя в целом Вы и правы.
У нас не все так быстро развивается. И скупать каждый год вновь вышедшую винду мы не можем. Хотя в целом Вы и правы.
О каких госструктурах идет речь? Я делал множество проектов для разных (крупных) госструктур, баловством там обычно не занимаются. Если речь про какую-нибудь администрацию какого-нибудь города, то наверное. Если же про федеральные структуры — то нет.
Мало Вы знаете про госструктуры. Они разные бывают. В кого то вбухивают деньги, кто-то вынужден жить на самообеспечении и ожидать центральных закупок.
Хотя Вы скорее всего имели ввиду построение централизованных ИС. Тут да, и деньги большие и исполнение более менее на уровне (за исключением некоторых случаев, почитайте про тот же Росреестр). Но это бывает редко. Так что каждый регион сам себе король и городит что хочет.
Хотя Вы скорее всего имели ввиду построение централизованных ИС. Тут да, и деньги большие и исполнение более менее на уровне (за исключением некоторых случаев, почитайте про тот же Росреестр). Но это бывает редко. Так что каждый регион сам себе король и городит что хочет.
Забыл уточнить для какого триггера — для авторизации по SSH.
Интересный вопрос, спасибо. Честно говоря с этим не эксперементировал, но думаю теоретически возможно. Попробовать в выражении триггера использовать diff и например условие совпадения предыдущего и последнего значения. Вообщем мне этот вопрос тоже стал интересен. :) Попробую реализовать. Можете более подробно описать в чем сложность? Я так понимаю что при следующем обновлении элемента данных триггер переходит в OK, так? Можете привести пример последнего и предыдущего значения? У меня триггер без проблем живет 5 минут на дашборде как и указано в выражении.
Всё верно. После неудачной аутентификации проходит 30 секунд, которые выставлены в настройках итема.
Сам триггер такой же, только выражение разное, т.к. у меня другая система:
{proxyd:log[/var/log/auth.log,sshd,,,skip].regexp(failure)}|{proxyd:log[/var/log/auth.log,sshd,,,skip].regexp(Failed password)}&{proxyd.:log[/var/log/auth.log,sshd,,,skip].nodata(3m)}=0
Что соответствует строкам:
Mar 18 15:56:12 proxyd sshd[13954]: Failed password for root from 10.8.36.105 port 24550 ssh2
и
Mar 18 10:14:57 proxyd sshd[12551]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.8.36.105
Что имеется ввиду под примером? Выложу скрин.
Сам триггер такой же, только выражение разное, т.к. у меня другая система:
{proxyd:log[/var/log/auth.log,sshd,,,skip].regexp(failure)}|{proxyd:log[/var/log/auth.log,sshd,,,skip].regexp(Failed password)}&{proxyd.:log[/var/log/auth.log,sshd,,,skip].nodata(3m)}=0
Что соответствует строкам:
Mar 18 15:56:12 proxyd sshd[13954]: Failed password for root from 10.8.36.105 port 24550 ssh2
и
Mar 18 10:14:57 proxyd sshd[12551]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.8.36.105
Что имеется ввиду под примером? Выложу скрин.
не туда ответил =(
Любопытно, но — 2014 год, актуальнее было бы не 2003 и 2008 сервер рассматривать, а 2008 и 2012.
А как сделать триггер по количеству определенных событий (речь про Windows) — скажем, более 5 ошибок входа в систему за 5 минут — срабатывает триггер, меньше — игнорируем.
Я пытаюсь сделать выражение через count (300s,4625)>5, но что-то не работает
Я пытаюсь сделать выражение через count (300s,4625)>5, но что-то не работает
Sign up to leave a comment.
Мониторинг событий информационной безопасности с помощью ZABBIX