Комментарии 12
Интересно, а какой тогда мониторинг является наиболее секьюрным?
Наиболее секьюрны те решения, которые первоначально задумывались для работы из облака. Те же New Relic или Appdynamics имеют очень высокую степень защиты. А New Relic, насколько мне известно, даже отвечает требованиям стандарта PCI DSS
Zabbix вполне себе секьюрнный. Он поддерживает шифрование между агентами/прокси/сервером. Просто это не включено по-умолчанию. Так что если у вас не реализована защита не уровне сети, то извольте включить соответствующие Настройки в системе мониторинга. Ну и не забывайте обновляться.
Единственное с чем соглашусь — в Windows агент стартует под системной записью, что не очень безопасно. Но это тоже решается.
Вы хотите сказать, что кто-то в здравом уме будет передавать незашифрованный траффик в открытом интернете? Это же легко настраивается в Zabbix.
К сожалению, с определенной периодичностью встречаются компании, в которых вспомогательное ПО сконфигурировано с грубыми нарушениями или работает в дефолтной поставке (то есть вопросы безопасности отданы на откуп разработчикам).
Логика говорит, что это все же не следствие кривости Заббикса, а рук компаний и их подрядчиков.
Да, есть некоторая неприятность, что без Заббикс можно и без шифрования запустить. Но резон в этом есть: вы можете хотеть, например, общаться с агентами по доверенной сети (в пределах выделенного LAN-а, например), и нет смысла в накладных расходах.
А уж что не обновляют — кто виноват?
Да, есть некоторая неприятность, что без Заббикс можно и без шифрования запустить. Но резон в этом есть: вы можете хотеть, например, общаться с агентами по доверенной сети (в пределах выделенного LAN-а, например), и нет смысла в накладных расходах.
А уж что не обновляют — кто виноват?
хорошо проверенных эксплоитов
Мне кажется Вам статью нужно было написать еще в 2009 году
Что касается API и веб интерфейса то let's encrypt всех спасёт по красоте с TLS1.3(на крайний самоподписанные сертификаты). Что касается передачи в открытом интернете данных мониторинга, то даже psk ключа на zabbix-proxy в регионе будет достаточно чтобы отпугнуть не целевые атаки.
А вот если вы достигли дзена, то смело расчехляйте ansible\chef\salt\etc и пишите настройку TLS для сервера, прокси и агентов. Одной командой куда проще защититься, чем читать такие посты. Для тех кто сам писать не хочет, может взять уже готовые материалы в интернете. Но если у вас дзен уровень зашкаливает, то вы не будете писать настройку сами, а возьмёте материалы в интернете и сделаете ревью, впоследствии внеся небольшие правки под себя.
А вот если вы достигли дзена, то смело расчехляйте ansible\chef\salt\etc и пишите настройку TLS для сервера, прокси и агентов. Одной командой куда проще защититься, чем читать такие посты. Для тех кто сам писать не хочет, может взять уже готовые материалы в интернете. Но если у вас дзен уровень зашкаливает, то вы не будете писать настройку сами, а возьмёте материалы в интернете и сделаете ревью, впоследствии внеся небольшие правки под себя.
Хорошо, вы уже скомпрометировали систему
Хороший пост. И методики интересные.
Очередная публикация ради публикации.
Статья капитана очевидности.
— Используя MITM атаки на инфраструктуру (в статье упоминается ARP spoofing) можно перехватить данные, в т.ч. логины/пароли, куки/sessiondid и т.п. секретные вещи, особенно если они не зашифрованы.
— Если вы не обновляетесь — вы можете быть уязвимы.
— Если вы не меняете дефолтные логин и пароль, то его может знать кто-то кроме вас.
— Если вы разрешили в агентах системы мониторинга удалённое исполнение команд (EnableRemoteCommands=1 для Zabbix агента), а сам агент запущен от LOCAL SYSTEM или подобного привилегированного пользователя, то компрометация системы мониторинга компрометирует всю инфраструктуру с которой работает эта система. Аналогично с параметрами, спецсимволами можно экранироваться и выполнить инъекции команд (UnsafeUserParameters=1 для Zabbix агента, Unsafe как-бы намекает). По умолчанию это отключено.
Все эти вектора имеют весьма посредственное отношение к системам мониторинга и в полной мере применимы к абсолютно любой системе с централизованным управлением с учётом описанных выше допущений.
Это может быть и AD, и любая система управления конфигурацией типа SCCM и т.п., и даже сервер администрирования антивируса, например KAV, и ещё неисчислимое множество их комбинаций.
— Используя MITM атаки на инфраструктуру (в статье упоминается ARP spoofing) можно перехватить данные, в т.ч. логины/пароли, куки/sessiondid и т.п. секретные вещи, особенно если они не зашифрованы.
— Если вы не обновляетесь — вы можете быть уязвимы.
— Если вы не меняете дефолтные логин и пароль, то его может знать кто-то кроме вас.
— Если вы разрешили в агентах системы мониторинга удалённое исполнение команд (EnableRemoteCommands=1 для Zabbix агента), а сам агент запущен от LOCAL SYSTEM или подобного привилегированного пользователя, то компрометация системы мониторинга компрометирует всю инфраструктуру с которой работает эта система. Аналогично с параметрами, спецсимволами можно экранироваться и выполнить инъекции команд (UnsafeUserParameters=1 для Zabbix агента, Unsafe как-бы намекает). По умолчанию это отключено.
Все эти вектора имеют весьма посредственное отношение к системам мониторинга и в полной мере применимы к абсолютно любой системе с централизованным управлением с учётом описанных выше допущений.
Это может быть и AD, и любая система управления конфигурацией типа SCCM и т.п., и даже сервер администрирования антивируса, например KAV, и ещё неисчислимое множество их комбинаций.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
(Не)безопасность систем мониторинга: Zabbix