¿Es razonable usar Nagios para verificar que un servicio NO esté disponible?

Supongamos que tengo un servidor con una interfaz privada y una interfaz pública. Público podría tener servidores HTTP (S), privado podría tener MySQL y SSH.

Obviamente, Nagios es útil para verificar que los servicios se ejecutan en sus respectivas interfaces. ¿Pero es una buena idea construir controles que prueben explícitamente que los puertos MySQL y SSH no están abiertos en la interfaz pública? La idea es detectar configuraciones erróneas involuntarias que han abierto servicios que deberían ser privados y alertar adecuadamente.

Una parte de mí tiene la idea de que esto no se escalaría terriblemente bien; imagine que hay una regla DROP de iptables, por ejemplo, la verificación tendría que esperar hasta que el tiempo de espera excediera antes de que pueda completarse y continuar. Pero ese tiempo de espera tendría que ser lo suficientemente alto como para poder diferenciar un servicio bloqueado de uno abierto que realmente está empantanado.

¿Es esta una idea práctica? ¿Es Nagios la herramienta correcta? Ni siquiera he estudiado la posibilidad de negar el resultado de los complementos de verificación de TCP, pero estoy seguro de que es factible ...

Sí, por supuesto. El trabajo de un sistema de monitoreo es garantizar que la infraestructura de TI cumpla actualmente con los requisitos comerciales, sean cuales sean esos requisitos.

Mi intuición es que no hay un límite fácil (bueno, 65535) para la cantidad de puertos que está monitoreando para garantizar que no se abran repentinamente, y que la mejor manera de lograr este control es un control de fuente estricto más fuerte, monitoreo agresivo del sistema de archivos (por ejemplo, tripwire) en el servidor.

Pero si hay ciertos puertos que son absolutamente críticos para el negocio nunca están expuestos, entonces sí, por supuesto, haga una verificación específica para eso. Es posible que desee consultar el negatecomplemento NAGIOS , que se distribuye con la mayoría de las distribuciones principales, y se utiliza para hacer exactamente lo que sugiere.

Puede combinar cualquier verificación con el negatecomplemento para invertir la lógica de verificación. Puede redefinir CRIT, WARN, UNKNOWN y OK a otros estados, por ejemplo. Vea la salida --help para más información .

Si le preocupa que las políticas DROP aumenten el tiempo de verificación, puede acortar el tiempo de espera. Para una verificación como esta, probablemente tampoco necesite verificar cada 5 minutos. Tenemos algunos controles similares que se ejecutan cada hora.