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