Предположим, у меня есть сервер с закрытым интерфейсом и открытым интерфейсом. Public может иметь такие вещи, как HTTP (S) серверы, private может иметь MySQL и SSH.
Очевидно, что Nagios полезен для проверки того, что службы работают на своих соответствующих интерфейсах. Но стоит ли создавать проверки, которые явно проверяют, что порты MySQL и SSH не открыты в открытом интерфейсе? Идея состоит в том, чтобы поймать непреднамеренные неправильные конфигурации, которые открыли сервисы, которые должны быть частными, и предупреждать соответственно.
У некоторых из меня есть идея, что это не очень хорошо масштабируется - представьте, что есть правило DROP iptables, например, проверка должна ждать до истечения времени ожидания проверки, прежде чем она сможет завершиться и двигаться дальше. Но этот тайм-аут должен быть достаточно большим, чтобы можно было отличить заблокированный сервис от открытого, который действительно застрял.
Это практическая идея? Является ли Nagios правильным инструментом? Я даже не рассматривал возможность отрицания результата от проверочных плагинов TCP, но я уверен, что это выполнимо ...
источник
DROPне является подходящей целью для такой цели, использование-j REJECT --reject-with tcp-resetпозволит решить эту конкретную проблему. Для меня ваш вопрос звучит как еще одна причина, чтобы использовать,REJECTа неDROP.Ответы:
Ну конечно; естественно. Задача системы мониторинга состоит в том, чтобы гарантировать, что бизнес-требования в настоящее время удовлетворяются ИТ-инфраструктурой, какими бы ни были эти требования.
Я чувствую, что нет никакого легкого ограничения (ну, 65535) на количество портов, которые вы контролируете, чтобы гарантировать, что они внезапно не станут открытыми, и что лучший способ добиться этого контроля - жесткий контроль источника плюс сильный, агрессивный мониторинг файловой системы (например, tripwire) на сервере.
Но если есть определенные порты, которые абсолютно критичны для бизнеса, они никогда не открываются, тогда да, во что бы то ни стало, установите для этого определенную проверку. Возможно, вы захотите взглянуть на
negateплагин NAGIOS , который поставляется с большинством основных дистрибутивов и используется именно для того, что вы предлагаете.источник
Вы можете объединить любую проверку с
negateплагином, чтобы инвертировать логику проверки. Например, вы можете переопределить CRIT, WARN, UNKNOWN и OK для других состояний. Смотрите вывод --help для получения дополнительной информации .Если вас беспокоит политика DROP, увеличивающая время проверки, вы можете просто сократить время ожидания. Для такой проверки вам, вероятно, не нужно проверять каждые 5 минут. У нас есть несколько подобных проверок, которые проводятся ежечасно.
источник