Comments 15
Я уже проник в сеть предприятия, попал во влан с такчкой админа, проспуфил и перехватил трафик админа, да так что ни одна система мониторинга, ids/ips не всколыхнулась. Но самое уязвимое местотна предприятии это конечно же zabbix.
Нету главного совета: использовать «https»
Слишком много «если». Не стоит пренебрегать базовыми шагами по обеспечению безопасности. Используйте HTPPS (скоро каждый сайт в интернете будет его использовать). Отключайте выполнение удаленных команд, если оно вам не нужно (оно так и есть в конфигурации по умолчанию). Не используйте привилегированного пользователя для запуска агента.
Также Zabbix давно поддерживает шифрование данных между агентом/сервером/прокси.
Я встречал системы с куда бОльшими проблемами: агент запускается от root (ибо многие проверки просторней заработают), данные передаются в незашифрованном текстовом виде...
В случае, если агент работает из под рута в ситуации, описанной в посте — это не проблема. Почему?
Тот способ, которым реализуется получение доступа (сниффить) реализуется при:
1) полном доступе к сетевому оборудованию, поскольку бродкастами сообщения давным давно не рассылаются — значит есть доступ к управлению и/или к оборудованию непосредственно.
2) наличии админских/рут прав — поскольку чтобы сниффингом нормально заниматься нужно в promiscuous mode уйти, а это, в любом случае, уже наличие на машине-жертве или подконтрольного злоумышленнику софта с админ/рут правами, либо наличие доступа с учётки с админ/рут правами. Агент заббикса под рутом тут уже роли не играет. Только если эта конкретная машина-жертва не является звеном в более сложной цепочке атаки с использованием заббикса. Но даже в таком случае слишком много вопросов. Если это целая инфраструктура и злоумышленник может получать админ/рут права, то, с немалой долей вероятности, он может проделать то же самое с другими целями того же типа.
Уважаемый bykvaadm выше всё достаточно кратко и полно описал.
Тот способ, которым реализуется получение доступа (сниффить) реализуется при:
1) полном доступе к сетевому оборудованию, поскольку бродкастами сообщения давным давно не рассылаются — значит есть доступ к управлению и/или к оборудованию непосредственно.
2) наличии админских/рут прав — поскольку чтобы сниффингом нормально заниматься нужно в promiscuous mode уйти, а это, в любом случае, уже наличие на машине-жертве или подконтрольного злоумышленнику софта с админ/рут правами, либо наличие доступа с учётки с админ/рут правами. Агент заббикса под рутом тут уже роли не играет. Только если эта конкретная машина-жертва не является звеном в более сложной цепочке атаки с использованием заббикса. Но даже в таком случае слишком много вопросов. Если это целая инфраструктура и злоумышленник может получать админ/рут права, то, с немалой долей вероятности, он может проделать то же самое с другими целями того же типа.
Уважаемый bykvaadm выше всё достаточно кратко и полно описал.
например, свитчей по ipmiС каких пор в свитчах появился ipmi? Судя по статье это не опечатка, а некомпетентность.
Первое, что надо включить на фронтенде заббикса, это HTTPS, как в комментариях тут написали, и если не можете какой нибудь let's encrypt заюзать, самоподписанного сертификата тоже будет достаточно.
Менять стандартные порты это глупость, никогда так не делайте без чёткого понимания зачем оно вам надо. Последующая поддержка этого добра сведёт на нет заботу о безопасности.
Включать удалённое выполнение команд надо ТОЛЬКО после настройки шифрования между агентом и сервером\прокси.
ВСЕГДА ВКЛЮЧАЙТЕ ШИФРОВАНИЕ МЕЖДУ ЗАББИКС СЕРВЕРОМ И ЗАББИКС ПРОКСИ! Подделать отправку данных на прокси чтобы он задосил вас никаких проблем не вызывает, даже этой статьи будет достаточно.
И главный вопрос, где блин ваш фаервол, если кто то может открыть слушать любой порт? На винде если вам надо мониторить пару машин, можно и рискнуть оставить агент как есть из коробки. Но если у вас огромное количество виндовых машин, соберите свой msi пакет с установкой службы и её настройкой, чтобы работало не от системного юзера.
Вся статья уровня скрипт-киди, от таких потуг даже не зачешется.
Вы совершенно не поняли о чем эта статья.
Здесь речь не про то, как нужно заббикс настроить, а про кейсы из реальной жизни, которые встречаются при пентестах. Она о том что цепочка ошибок в конфигурации может привести к довольно печальным последствиям. Например, получение rce на тех хостах, куда по другому доступ не получить, ибо все дырки закрыты и обновления установлены. Зачастую системы мониторинга стоят нетронутыми лет по 5, с тех времен, когда о шифровании трафика внутри сети не особо задумывались.
По поводу Ваших претензий, я бы не сказал что ни довольно объективные. Зачем комуто включать выполнение комманд через заббикс, что за маразм? При этом такое встречается. Фаервол между сегментами сети? Отличная идея! Но несмотря на то что ей уже 100 лет в обед, по прежнему попадаются абсолютно «плоские» сети. В интернете тысячи статей, как сделать все безопасно. Другое вопрос в том что все уверены в «безобидности» систем мониторинга, и совершенно не обращают на них внимания, когда задумываются о безопасности.
Здесь речь не про то, как нужно заббикс настроить, а про кейсы из реальной жизни, которые встречаются при пентестах. Она о том что цепочка ошибок в конфигурации может привести к довольно печальным последствиям. Например, получение rce на тех хостах, куда по другому доступ не получить, ибо все дырки закрыты и обновления установлены. Зачастую системы мониторинга стоят нетронутыми лет по 5, с тех времен, когда о шифровании трафика внутри сети не особо задумывались.
По поводу Ваших претензий, я бы не сказал что ни довольно объективные. Зачем комуто включать выполнение комманд через заббикс, что за маразм? При этом такое встречается. Фаервол между сегментами сети? Отличная идея! Но несмотря на то что ей уже 100 лет в обед, по прежнему попадаются абсолютно «плоские» сети. В интернете тысячи статей, как сделать все безопасно. Другое вопрос в том что все уверены в «безобидности» систем мониторинга, и совершенно не обращают на них внимания, когда задумываются о безопасности.
Я не так давно начал разбирать популярные шаблоны заббикса для ухода от кастомных скриптов мониторинга(userparametr'ов) на хостах. С появлением препроцессинга в заббиксе 90% всех задач может выполнятся благодаря удалённому выполнению команд и последующим препроцессингом(обработкой регулярками, или выдёргивание из xml или json) данных на стороне сервера. Не думаю что это маразм, когда мониторинг достаточно настроить только на самом сервере мониторинга и к хостам только обращаться для забора данных. Это конечно только описание цели, а не текущей реальности, но почему нет?
По опыту, даже с настроенным https Заббикс может ходить в Active Directory по незащищенному порту, пересылая пароль plaintext. И часто многим лень настраивать хождение по защищенному. Поэтому можно посниферить и подождать когда кто-нибудь из админов залогинится.
Далее — если включен remote-command и уровень привилегий у пользователя от которого запущен сервис высокий (что часто делается для автоматизации очистки диска/перезапуска сервисов и прочего) — то доступ получаем хороший.
Это более реальный кейс, чем видеть Заббикс без https :)
Буду благодарен за инструкцию о том, как запустить Zabbix Agent на Windows не под Local System и чтобы при этом работали хотя бы базовые проверки плюс performance counters.
Поддержку все комментарии на общую тематику «слишком много если». Zabbix без https — если честно, по моему субъективному мнению, встречается уже крайне редко, а если и встречается — то это всего лишь говорит о лени администратора или халатности интегратора.
Необходимо отметить, что параметр EnableRemoteCommands по умолчанию закомментирован (про другие параметры, кстати, явно указано, какое состояние по умолчанию) и находится в состоянии disabled. И очень у многих, опять же из своих наблюдений, он и находится в таком состоянии. Все таки, речь о системе мониторинга, а не о системе управлении конфигурациями итп. Чтобы изменить этот параметр нужно уже использовать уязвимости соответствующие на ОС где установлены агенты.
Подобным образом можно и дальше искать изъяны по тексту статьи.
В общем, за статью огромное спасибо — основной посыл ясен, статья полезна последним разделом о том, что делать чтобы было безопасней. Но все что выше — напоминает «статью ради статьи». В той же статье про безопасность Nagios не было так много за уши притянутых если.
Все таки, любые системы типа Ansible/Puppet/Chef несут, при подобном подходе, сильно большую угрозу для инфраструктуры, чем система мониторинга.
Так же, в защиту Zabbix — не могу промолчать и не отметить, что ребята очень плотно задумываются о безопасности и с каждой новой версией прикручивают все больше и больше плюшек, повышающих общей уровень безопасности их продукта (аутентификация с помощью доменных учеток и взаимодействие с каталогом по LDAPs, шифрование между агентом и сервером (при том предлагают использовать на выбор несколько библиотек, дабы не замыкаться на одной в случае обнаружения в ней каких либо уязвимостей), SNMPv3 с полным фаршем в виде аутентификации и шифрования, возможность аудита действий пользователя итд итп. + не стоит забывать все таки про прямые руки админа, который грамотно использует возможности SELinux на сервере и *nix агентах, настраивает на вебсервере https, просматривает аудит действий пользователя или же прикручивает к системе мониторинга какую либо SIEM систему итд.)
Но, еще раз, благодарю за статью.
Необходимо отметить, что параметр EnableRemoteCommands по умолчанию закомментирован (про другие параметры, кстати, явно указано, какое состояние по умолчанию) и находится в состоянии disabled. И очень у многих, опять же из своих наблюдений, он и находится в таком состоянии. Все таки, речь о системе мониторинга, а не о системе управлении конфигурациями итп. Чтобы изменить этот параметр нужно уже использовать уязвимости соответствующие на ОС где установлены агенты.
Подобным образом можно и дальше искать изъяны по тексту статьи.
В общем, за статью огромное спасибо — основной посыл ясен, статья полезна последним разделом о том, что делать чтобы было безопасней. Но все что выше — напоминает «статью ради статьи». В той же статье про безопасность Nagios не было так много за уши притянутых если.
Все таки, любые системы типа Ansible/Puppet/Chef несут, при подобном подходе, сильно большую угрозу для инфраструктуры, чем система мониторинга.
Так же, в защиту Zabbix — не могу промолчать и не отметить, что ребята очень плотно задумываются о безопасности и с каждой новой версией прикручивают все больше и больше плюшек, повышающих общей уровень безопасности их продукта (аутентификация с помощью доменных учеток и взаимодействие с каталогом по LDAPs, шифрование между агентом и сервером (при том предлагают использовать на выбор несколько библиотек, дабы не замыкаться на одной в случае обнаружения в ней каких либо уязвимостей), SNMPv3 с полным фаршем в виде аутентификации и шифрования, возможность аудита действий пользователя итд итп. + не стоит забывать все таки про прямые руки админа, который грамотно использует возможности SELinux на сервере и *nix агентах, настраивает на вебсервере https, просматривает аудит действий пользователя или же прикручивает к системе мониторинга какую либо SIEM систему итд.)
Но, еще раз, благодарю за статью.
Скорее всего, это и есть сервер. Но это не точно :)
Конечно не точно, это может быть Zabbix прокси.
Не зная логина и пароля, это можно сделать, отпарсив исходный код страницы 192.168.56.102/zabbix/index.php
Не зная логина и пароля можно по линку 192.168.56.102/zabbix/api_jsonrpc.php отправить POST-запрос:
{
"jsonrpc": "2.0",
"method": "apiinfo.version",
"params": [],
"id": 1
}
просто дописав строку Timeout=30 в конец файла zabbix_agentd.conf
после этих манипуляций надо агента перезапустить. После перезапуска придет оповещение, если конечно все оповещения не будут отключены.
На инсталляциях с использованием Zabbix прокси, можно у Zabbix сервера запросить конфигурацию прокси и он отдаст ее любому запросившему, независимо от того с какого компьютера был отправлен запрос. В ответе будет абсолютно все, что мониторится через эту проксю, а так же все локальные (специфичные для конкретного хоста) и глобальные макросы, в которые часто прописывают логины/пароли.
Использование https не спасет от прослушивания трафика между сервером, прокси и агентом. Здесь спасет RSA или PSK, но управление сертификатами для агентов и прокси это еще то удовольствие. Использование CRL в Zabbix убивает все желание использовать RSA из-за необходимости перезапуска сервера/прокси/агента для того, что бы они перечитали список отозванных сертификатов. PSK в открытом виде можно посмотреть в web-интерфейсе.
Так что сделать Zabbix «не дырявым», в случае большой инфраструктуры, это титаническая работа.
Использование SELinux накладывает множество ограничений и под каждый UserParameters необходимо пилить свои правила. Так что если у Вас 10 серверов, то реально, а вот если 1000 или 15000, или еще больше, не вариант.
так ли Вам нужен запуск удаленных команд с помощью Zabbix? Если нет — то отключите эту возможность.
Она и так выключена по умолчанию. Если уж админ её включает (и заббикс торчит в интернет) — не позаботиться при этом о шифровании совсем уж странно.
Sign up to leave a comment.
Система мониторинга как точка проникновения на компьютеры предприятия