Est-il raisonnable d'utiliser Nagios pour vérifier qu'un service n'est PAS disponible?

Supposons que j'ai un serveur avec une interface privée et une interface publique. Le public peut avoir des choses comme les serveurs HTTP (S), le privé peut avoir MySQL et SSH.

Évidemment, Nagios est utile pour vérifier que les services fonctionnent sur leurs interfaces respectives. Mais est-ce une bonne idée de construire des contrôles qui testent explicitement que les ports MySQL et SSH ne sont pas ouverts sur l'interface publique? L'idée est de détecter les erreurs de configuration par inadvertance qui ont ouvert des services qui devraient être privés et d'alerter de manière appropriée.

Une partie de moi a l'idée que cela ne se développerait pas très bien - imaginez qu'il existe une règle DROP iptables, par exemple, la vérification devrait attendre que le délai de vérification soit dépassé avant de pouvoir se terminer et passer à autre chose. Mais ce délai devrait être suffisamment élevé pour pouvoir différencier un service bloqué d'un service ouvert qui est vraiment enlisé.

Est-ce une idée pratique? Nagios est-il le bon outil? Je n'ai même pas examiné la possibilité de nier le résultat des plugins de vérification TCP, mais je suis sûr que c'est faisable ...

Oui bien sûr. Le rôle d'un système de surveillance est de s'assurer que les exigences commerciales sont actuellement satisfaites par l'infrastructure informatique, quelles que soient ces exigences.

Mon intuition est qu'il n'y a pas de limite facile (enfin 65535) au nombre de ports que vous surveillez pour vous assurer qu'ils ne s'ouvrent pas soudainement et que la meilleure façon d'obtenir ce contrôle est un contrôle de source serré plus fort, surveillance agressive du système de fichiers (par exemple, tripwire) sur le serveur.

Mais s'il y a certains ports qui sont absolument critiques pour l'entreprise, ils ne sont jamais exposés, alors oui, assurez-vous par tous les moyens de vérifier cela. Vous voudrez peut-être examiner le negateplugin NAGIOS , qui est livré avec la plupart des distributions majeures, et qui est utilisé pour faire exactement ce que vous suggérez.

Vous pouvez combiner n'importe quelle vérification avec le negateplugin pour inverser la logique de vérification. Vous pouvez redéfinir CRIT, WARN, UNKNOWN et OK dans d'autres états, par exemple. Voir la sortie --help pour plus d'informations .

Si vous craignez que les politiques DROP n'augmentent le temps de vérification, vous pouvez simplement raccourcir le délai. Pour un contrôle comme celui-ci, vous n'avez probablement pas besoin de vérifier toutes les 5 minutes non plus. Nous avons des contrôles similaires qui ont lieu toutes les heures.