Чи розумно використовувати Nagios, щоб перевірити, чи послуга НЕ доступна?

9

Припустимо, у мене є сервер із приватним та загальнодоступним інтерфейсом. У загальнодоступних можуть бути такі речі, як сервери HTTP (S), приватні можуть мати MySQL та SSH.

Очевидно, що Nagios корисно перевірити, чи працюють служби на відповідних інтерфейсах. Але чи гарна ідея побудувати чеки, які явно перевіряють, чи порти MySQL та SSH не відкриті на загальнодоступному інтерфейсі? Ідея полягає в тому, щоб зафіксувати ненавмисні неправильні конфігурації, які відкрили служби, які повинні бути приватними та відповідати належним чином.

Частина мене має думку про те, що це не буде дуже масштабним - уявіть, що існує правило DROP для iptables, наприклад, чек повинен зачекати, поки час закінчення перевірки буде перевищений, перш ніж він може закінчитися і рухатися далі. Але цей час очікування повинен бути достатньо високим, щоб можна було диференціювати заблоковану послугу від відкритої, яка справді забилася.

Це практична ідея? Чи є Nagios правильним інструментом? Я навіть не розглядав можливість заперечення результату плагінів перевірки TCP, але впевнений, що це можливо ...

— smitelli
джерело

2

Я давно переконаний, що DROPце не є правильною ціллю для такої мети, використання -j REJECT --reject-with tcp-resetвирішило б саме цю проблему. Для мене ваше запитання звучить як просто ще одна причина використання, REJECTа не DROP.

— kasperd

4

check_nmap FTW.

— dmourati

11

Так, звісно. Завдання системи моніторингу полягає в тому, щоб забезпечити, що бізнес-вимогам в даний час відповідає ІТ-інфраструктура, незалежно від цих вимог.

Я відчуваю, що немає простого обмеження (ну, 65535) кількості портів, які ви відстежуєте, щоб вони не раптом стали відкритими, і що найкращий спосіб досягти цього контролю - жорсткий контроль над джерелами плюс сильний, агресивний моніторинг файлової системи (наприклад, тривимірний провід) на сервері.

Але якщо є певні порти, які є абсолютно критичними для бізнесу , ніколи не піддаються впливу, то так, це, безумовно, замінить певну перевірку на це. Ви можете заглянути в negateплагін NAGIOS , який постачається з більшістю основних дистрибутивів, і використовується для того, щоб робити саме те, що ви пропонуєте.

— MadHatter
джерело

3

Ви можете комбінувати будь-який чек із negateплагіном, щоб інвертувати логіку перевірки. Ви можете перезначити CRIT, WARN, UNKNOWN і OK для інших станів, наприклад. Для отримання додаткової інформації див .

Якщо ви стурбовані тим, що політика DROP збільшує час перевірки, ви можете просто скоротити час. Для такої перевірки вам, ймовірно, не потрібно перевіряти кожні 5 хвилин. У нас є кілька подібних перевірок, які працюють щогодини.

— Кіт
джерело