Андрей

Здравствуйте.
Технологий взлома уйма.
В зависимости от того, какие привелегии получил "хакер" при вломе вашей БД - зависит очень много.
Если он получил доступ только на чтение, то захешированные в MD5 пароли ему мало чем помогут, т.к. MD5 не имеет алгоритма обратной расшифровки и хэширование спасёт тем, что взломщик получивший доступ на чтение паролей - самих паролей не получит (есть конечно словарь MD5 хешей, то это другая история).
Вообще для защиты любой БД есть несколько золотых правил:
0. Переименовать дефолтного админа и защитить его сложным паролем.
1. Для каждой БД должен создаваться свой владелец и несколько пользователей с разными наборами привелегий.
2. Ни у одного из пользователей, созданных в п.1 не должно быть прав на изменение таблиц в соседней БД.
Если есть необходимость обновлять соседние БД - делайте это триггером в соседней БД.
3. Каждый внешний веб-сервис должен ходить в БД только с тем набором прав, которых ему достаточно для работы. Т.е. не нужно везде прописывать root и надеяться на лучшее.
В этом случае, если взломщик получит привелегии этого пользователя, то сможет сделать только то, что разрешено этому пользователю. Тогда не выйдет "удалить все и сразу".
Например, для наполнения католога товаров в интернет-магазине может быть отдельный пользователь, с правами на SELECT, INSERT, UPDATE, DELETE в таблице SHOP_PRODUCTS, например. И ничего более.
А пользователи, приходящие в магазин за покупками могут делать SELECT, INSERT, UPDATE, DELETE только в таблицу CUSTOMER_CART. В коде веб-сервиса, естественно должна быть проверка, что покупатель редактирует СВОЮ корзину.
Для показа каталога товаров - отдельный пользователь, имеющий право только на SELECT из таблицы SHOP_PRODUCTS.
А продажу товара может делать отдельный пользователь, с правом только на UPDATE колонки AMOUNT в таблице SHOP_PRODUCTS. Пример:

GRANT SELECT ON shopdb.SHOP_PRODUCTS TO 'trader_bot'@'shophost';
GRANT UPDATE (AMOUNT) ON shopdb.SHOP_PRODUCTS TO 'trader_bot'@'shophost';

И т.п. По принципу "Разделяй и властвуй."
4. Писать запросы с использованием placeholder'ов (подстановку данных), что убережёт от SQL-инъекций.
Пример:

$DB->select('SELECT * FROM tbl WHERE a=? AND b=?', $a, $b);

5. Если и БД и приложение, используещее БД установлены на одном сервере - отключить удалённый доступ к БД и работать через сокеты.
6. Последний, но самый важный - БЕКАПЫ. При удалении всего и вся - нужно откуда-то восстановиться. Делайте бекапы и храните на отдельном сервере (не выставленном наружу).

Зравствуйте.

Что я сделал не так?

Не прочли/прочли не внимательно документацию по API.
У метода item.get нет параметра hosts.
Так же обратите внимание на столбец "Тип", в котором указано - какой тип может принимать тот или иной параметр.
Например, hostids может принимать массив или строку, а host только строку.

как решить эту проблему?

Путей решения несколько.
1. Использовать массив hostids в params (как в вашем первом примере).
2. Использовать в params фильтр с массивом host-элементов:

"params": {
	"filter": {
		"host": ["server01",
		"server02"],
		"key_": "vfs.fs.size"
	}
}

Здравствуйте.
В соседнем ответе на ваш вопрос я затронул эту тему.
Для точных значений следует использовать filter вместо search.

Зравствуйте.
Для поиска нескольких точных значений попробуйте использовать filter (работает как item.key = '...' в БД).
Для поиска нескольких шаблонных значенией (с использованием wildcard) используйте search (работает как item.key LIKE '%...%' в БД).
Для поиска нескольких значений используйте массив, составленный по правилам JSON:

zabbix_get= \
        {
            "jsonrpc": "2.0",
            "method": "item.get",
            "params": {
                "output": "extend",
                "host": 'server01',
                "filter": {
                    "key_": [
                        "vfs.fs.size[/data,free]",
                        "system.cpu.util.usage"
                    ]
                },
                "sortfield": "name"
            },
            "auth": authToken.get("result"),
            "id": authToken.get("id")
        }

/var/log/secure пишется демоном /sbin/syslogd . И пишет он туда не входы, а именно авторизации, в т.ч. sudo, sudo su, su и т.д.
Настройки syslogd можно посмотреть в /etc/syslog.conf, конкретно строчка "authpriv.*" означает "записывать в лог все сообщения, полученные от ядра, которые начинаются на authpriv."
Вывод команды last - это результат чтения бинарного лога /var/log/wtmp (man wtmp), в который записываются удачные входы (не рекомендую открывать лог cat'ом, tail'ом и т.п.). Логи (wtmp, utmp, btmp), в свою очередь, пишут /bin/login и его функция logout.
Т.е. отвечая на ваш вопрос:
1. Нельзя заставить /bin/login записать в лог авторизацию, т.к. он пишет входы;
2. Нельзя заставить /bin/login записать в лог вход, если входа не произошло;
3. Нельзя заставить last показывать то, что не записано в логи.

ts_block существует.

Через Yandex.API, например.

Некропостинг, конечно, но нашёл этот пост, когда искал решение данного вопроса.
Тем, кто в будущем наткнётся - решение:
В zabbix для Windows есть Zabbix agent-проверки:
"proc_info" - для получения информации о процессе.
"proc.num" - для подсчёта кол-ва процессов, на сервере.
Подробно расписаны в мануале:
proc_info
proc.num
Для большинства unix-систем вместо proc_info используется проверка proc.mem.
Для того, чтобы узнать - поддерживается ли в вашей системе тот или иной элемент данных - сверяйтесь с таблицей в мануале.

В случае автора ключ элемента данных должен выглядеть так:
proc_info[process.exe,wkset,sum]
Данный элемент данных выводит кол-во потребляемой памяти в КБ.
Неудобно? Ставим в настройках элемента данных:
Units (Единица измерения) - B
Use custom multiplier (Пользовательский множитель) - 1024