Monitorización de certificados digitales
Monitorizar los certificados digitales instalados en los servidores WEB de una organización es una necesidad básica para poder administrarlos correctamente.
CNM permite monitorizar la caducidad de los certificados digitales y planificar tareas para obtener la información relevante de los mismos de forma automatizada. También proporciona herramientas de descubrimiento sobre rangos de direcciones IP.
Para monitorizar la caducidad del certificado existen métricas ya incluidas en el sistema que obtienen el dato directamente de la información contenida en el propio certificado. Esto permite obtener los datos de caducidad en tiempo real y generar alertas en base a los criterios de tiempo que se estimen oportunos.
Al margen la monitorización activa por parte de CNM, también se incluyen de base alertas remotas basadas en los traps generados por fabricantes de balanceadores, aceleradores SSL u otros equipos similares como F5 Networks o Net Scaler. En este caso es el equipo remoto el que informa sobre la caducidad de sus certificados digitales.
CNM también incluye aplicaciones que permiten obtener la información relevante contenida en el certificado digital. Esto permite definir tareas periódicas de supervisión para que el administrador pueda hacer el análisis pertinente.
CADUCIDAD
CNM incluye métricas basadas en script que miden el tiempo que falta para que caduque un certificado SSL en horas y segundos
Están disponibles desde la rama de métricas de tipo proxy y son fácilmente localizables, ya sea filtrando por nombre o por grupo tecnológico (IPSERV.WWW).
Ambas métricas utilizan el script: linux_metric_ssl_certs.pl que también se incluye de base en el sistema.
Una vez aplicadas sobre el dispositivo, veremos una gráfica cómo la de la figura:
Sobre éstas métricas se pueden aplicar monitores que generen alertas en función del tiempo que falte para que caduquen y con la antelación que defina el administrador.
Un ejemplo puede ser un monitor aplicado sobre la métrica de la figura que se llame "REVISAR CADUCIDAD CERTIFICADO DIGITAL " y que tenga tres severidades:
-
- Amarillo: Falta un mes para que caduque (v1<720).
- Naranja: Falta una semana para que caduque (v1<168).
- Rojo: Certificado caducado (v1<=0).
Mediante una vista se pueden agrupar todas las métricas de este tipo para tener una visión de conjunto tanto a nivel gráfico como de alertas.
Esto además tiene la ventaja de permitir que otros usuarios accedan exclusivamente a esta información sin necesidad de acceder al total de elementos monitorizados.
Por otra parte, a partir de las alertas producidas por los monitores definidos, se puede generar un informe de disponibilidad que nos muestre sobre un periodo de tiempo el impacto que han tenido estas alertas sobre nuestra infraestructura.
OBTENCIÓN DE INFORMACIÓN
Además de la monitorización basada en métricas de caducidad o alertas enviadas por los equipos remotos cuando sus certificados digitales hayan caducado o están próximos a caducar, CNM incluye varias aplicaciones para obtener los datos relevantes del certificado digital.
La primera proporciona información sobre los certificados digitales de los equipos seleccionados por el administrador de entre los dados de alta en el sistema.
La segunda permite buscar los certificados digitales presentes en un rango de direcciones IP especificado por el administrador.
Ambas se basan en el script: linux_app_ssl_certs.pl ya incluido en el appliance y se pueden planificar de forma periódica configurando una tarea sobre dichas aplicaciones.
Los datos proporcionados por cada una de ellas son:
- IP del equipo consultado.
- Versión del certificado.
- Número de Serie del certificado.
- Algoritmo de Firma del certificado.
- Emisor del certificado.
- Sujeto del certificado.
- Fecha de inicio de validez del certificado.
- Fecha de caducidad del certificado.
- Algoritmo de clave pública utilizado.
- Longitud en bits de la clave.
- Certificado en formato PEM.
Servidores Gestionados
En general, las entidades gestionadas por CNM son dispositivos, definidos de forma unívoca por su dirección IP, que no es duplicable en el sistema. Para abordar situaciones como ésta, el sistema permite definir un servivio web como si de un dispositivo se tratara. En este caso, diferentes elementos identificados por su nombre pueden existir aunque compartan una misma dirección IP.
Desde el punto de vista de inventario y gestión de nuestros activos de TI, definir un servicio web como parte del inventario permite sacar el máximo provecho a los campos de información definidos por el usuario.
Por otra parte, el sistema permite al administrador definir una tarea periódica para obtener la información de los certificados digitales correspondientes a los servicios web dados de alta en el sistema de forma automatizada.
Esta tabla dimámica de resultados le permitirán evaluar temas críticos a la hora de gestionar la calidad los certificados SSL de su organización como son:
-
Los datos propios del certificado y los relativos al DNS.
-
Si el certificado corresponde a la máquina en cuestión, validando si el hostname coincide con el "common name".
-
Revisar la cadena de certificación.
-
Comprobar si es un certificado autofirmado o si la CA es confiable.
-
Validar la fuerza del cifrado de la clave privada.
-
Evaluar la robustez del algoritmo de firma utilizado.
-
Comprobar si dispone de validación extendida (EV).
Auto-Descubrimiento
EL sistema incluye una de aplicación descubrimiento automático que examina rangos de direcciones IP en busca de los certificados digitales que puedan existir en los servidores encontrados.
El administrador debe duplicar la aplicación que se incluye por defecto y parametrizarla para los rangos que desee y a partir de ahí planificarla como una tarea periódica o ejecutarla a voluntad.
Renovación de certificados
Otras posibles aplicaciones que complementan estas funcionalidades y que está previsto incluirlas en la plataforma, son aquellas que permitan automatizar al máximo el proceso de renovación de los certificados digitales y gestión y validación de los CSR.
Monitorizar equipos con dos líneas de comunicaciones
Es habitual que existan equipos de comunicaciones (routers, firewalls etc ...) ubicados en sedes remotas y que posean dos lineas de comunicaciones independientes para acceder a los sistemas centrales de la organización ya que este tipo de configuración proporciona una mayor redundancia ante fallos, especialmente si las líneas son de operadoras diferentes.
En estos casos es fundamental monitorizar que ambas líneas estén operativas. No tiene sentido hacer una inversión de este tipo y detectar la caida del interfaz secundario cuando realmente se necesita que funcione. Si no lo hacemos así, o estamos desaprovechando ancho de banda o en caso de caida del principal tendremos un problema serio de conectividad.
Para abordar este problema, CNM incluye una métrica de tipo proxy basada en el script linux_metric_icmp_dual.pl.
Su funcionamiento es el siguiente:
El script hace un ping a las direcciones IP de los dos interfaces y en función de los diferentes posibles resultados, especificados en la siguiente tabla, proporciona un valor de estado.
| Acceso a IP1 | Acceso a IP2 | Resultado |
|---|---|---|
| OK | OK | 0 => Se accede a ambas IPs. |
| OK | ERROR | 1 => Se accede a IP1 pero no a IP2. |
| ERROR | OK | 2 => No se accede a IP1 pero sí a IP2. |
| ERROR | ERROR | 3 => No se accede a ninguna de las dos IPs. |
Para especificar la dirección IP secundaria asociada al dispositivo, se debe definir en el sistema un campo de usuario, cuyo nombre será un parámetro del script que se debe definir en la métrica.
En resumen, los pasos a seguir serían:
| Núm | Tarea | Observaciones |
|---|---|---|
| 1 | Definir campo de usuario | Desde la rama de Configuración en la solapa de Personalización,se accede a Dispositivos -> Campos de Usuario |
| 2 | Rellenar el valor de dicho campo de usuario en aquellos dispositivos que sea necesario | Se puede hacer de forma manual apartir de datos obtenidos del dispositivo o mediante un script que utilice el API para actualizar dicho campo de usuario de forma automática. |
| 3 | Crear una métrica a partir de la proporcionada en orígen. | Se duplica lamétrica "DISPONIBILIDAD ICMP DUAL (sample)" y en la nueva métrica se especifica el parámetro "-s" con el nombre que se le ha dado al campo de usuario. |
| 4 | Asociar monitor. | Si se desea se puede asociar el monitor "ERROR EN ACCESO ICMP DUAL" o crear otro a la medida. |
| 5 | Asociar la métrica/monitor a los dispositivos que sea necesario. | Desde la rama de métricas proxy y monitores. |
Uso del ancho de banda utilizado en los enlaces de comunicaciones
La revisión 03.07.02 de CNM permite definir niveles sobre las métricas. Esta funcionalidad, además de ser una ayuda a la hora de visualizar las métricas permite que dichos niveles se puedan utilizar en la definición de monitores.
En este artículo vamos a desarrollar cómo generar alertas cuando los interfaces de red superen un tanto por ciento de uso aunque la métrica no proporcione directamente ese dato.
El primer paso consiste en definir los niveles de aquellas métricas que nos interese. En este caso, serán métricas de tráfico de determinados equipos e interfaces.
Esto se hace desde la rama de Configuración -> Personalización -> Métricas -> Umbrales, como se puede apreciar en la siguiente figura.
Una vez seleccionada la métrica, se definen los valores LEVEL1 y LEVEL2 y se pulsa el botón Guardar.
En este punto, si vemos la gráfica de la métrica aparecen dos nuevos elementos, LEVEL1 y LEVEL2 que son siempre constantes y representan los niveles que acabamos de definir. No es relevante si LEVEL1 es mayor o menor que LEVEL2 porque son referencias para uso del usuario.
El siguiente paso, es crear un monitor para el tipo de métrica seleccionada. En este caso, se trata de la métrica de tráfico de interfaz, por lo que debemos ir a la rama de métricas SNMP, seleccionarla y pulsar la solapa Monitor.
Los niveles LEVEL1 y LEVEL2 pueden formar parte de la expresión del monitor si aparecen entre corchetes como se muestra a continución:
-
[LEVEL1]
-
[LEVEL2]
En este punto, veamos un jemplo. Supongamos que queremos generar una alerta amarilla cuando el uso de una interfaz de red que tiene un ancho de banda de 10 Mbps supera el 40% y una alerta roja cuando supera el 80%.
Lo primero sería definir el ancho de banda de la línea de comunicaciones monitorizada. Para ello utilizamos el nivel LEVEL1 y almacenamos el valor 10000000, ya que la unidad de la métrica es bits/seg.
El siguiente paso es definir el monitor correspondiente cuya EXPR será:
-
En la severidad roja: (V1/[LEVEL1])>0.4 || (V2/[LEVEL1])>0.4
-
En la severidad amarilla: (V1/[LEVEL1])>0.8 || (V2/[LEVEL1])>0.8
El uso de LEVEL1 y LEVEL2 permite tener un único monitor para unos porcentajes determinados. Si el ancho de banda de la línea fuera de 1 Gps, bastaría con definir el valor de LEVEL1 con 1000000000 y utilizar el mismo monitor.De igual forma, si se ampliase ese ancho de banda bastaría con hacer esta misma operación.
Notar, que en este ejemplo se ha considerado una interfaz de red con ancho de banda simétrico. En caso de ser asimétrica debemos aplicar los valores correspondientes a LEVEL1 y a LEVEL2.
Correlación interna
A partir de la revisión 03.07.02 de CNM se permite la correlación interna entre las alertas de un dispositivo. Esto permite reducir el número de alertas del equipo cuando está caido o incomunicado y así simplificar las tareas de operación.
Para ello, se han definido las siguientes reglas correlación interna:
-
ICMP correla TCP/IP: Si el dispositivo está incomunicado, es decir tiene una alerta de DISPOSITIVO INCOMUNICADO (ICMP), las alertas originadas por métricas de tipo TCP/IP no van a aparecer.
-
ICMP correla TCP/IP, SNMP y PROXY: Si el dispositivo está incomunicado, es decir tiene una alerta de DISPOSITIVO INCOMUNICADO (ICMP), las alertas originadas por métricas de tipo TCP/IP, SNMP y PROXY no van a aparecer.
-
ICMP correla TCP/IP, SNMP, PROXY y ALERTA REMOTA: Si el dispositivo está incomunicado, es decir tiene una alerta de DISPOSITIVO INCOMUNICADO (ICMP), no aparece ninguna alerta más. Equivale al caso anterior, incluyendo las alertas remotas.
- Comportamiento estandar: No se aplica ninguna regla de correlación interna, por lo que aparecerán todas las alertas del dispositivo.
La configuración de la correlación interna se realiza desde la rama de Configuración, en la solapa de Correlación Interna, como se aprecia en lasiguiente imágen.
En esta ventana, en la parte superior encontramos las diferentes reglas de correlación que hemoscomentado y en la parte inferior los dispositivos que tiene asociados cada regla.
Un dispositivo sólo puede tiene asociada una regla de correlación, que se modifica seleccionando la regla y asociándosela al equipo.
Es decir, si queremos que un dispositivo incomunicado sólo muestre dicha alerta y ninguna más, hay que hacer lo siguiente:
-
Lo primero sería ir a Configuración > Correlación Interna.
-
Seleccionar la regla de correlación ICMP correla TCP/IP, SNMP, PROXY y ALERTA REMOTA.
-
Buscar el dispositivo en la parte inferior de la ventana, marcarlo y pulsar en el botón Asociar.
Correlación externa
En la revisión 03.07.02 de CNM se incluye la funcionalidad de correlación externa, es decir entre alertas de diferentes dispositivos. Esto permite reducir el número de alertas presentes en el sistema ocultando aquellas que son consecuencia de alertas producidas en dispositivos relacionados. Un ejemplo puede ser el caso de una delegación remota que se queda incomunicada por un problema con sus comunicaciones (router, operadora, etc ...). En esta situación, la causa orígen de fallo es la caida del equipo de comunicaciones y las alertas de los otros equipos de la delegación son consecuencia de ésta.
En la revisión 03.07.02 de CNM se incluye la funcionalidad de correlación externa, es decir entre alertas de diferentes dispositivos. Esto permite reducir el número de alertas presentes en el sistema ocultando aquellas que son consecuencia de alertas producidas en dispositivos relacionados. Un ejemplo puede ser el caso de una delegación remota que se queda incomunicada por un problema con sus comunicaciones (router, operadora, etc ...). En esta situación, la causa orígen de fallo es la caida del equipo de comunicaciones y las alertas de los otros equipos de la delegación son consecuencia de ésta.
En la correlación externa debemos entender dos conceptos:
-
-
Dispositivo/Alerta correladora: Alerta que al producirse sobre un determinado dispositivo, permite ocultar las alertas de otros dispositivos (alertas correladas).
-
Dispositivos correlados: Dispositivos con las alertas inhibidas por una alerta correladora.
-
Para configurar la correlación externa en el sistema, lo primero es identificar cual es el dispositivo que puede correlar a otros e identificar la alerta correladora. Esto se hace desde la solapa de Métricas en curso del propio dispositivo, seleccionando una métrica TCP/IP o una métrica con monitor y pulsando sobre el botón de Acciones -> Correlar.
A partir de éste momento, la alerta correladora se puede identificar en la lista de métricas en curso porque aparece con una estrella en el nombre como se puede apreciar en la siguiente imágen:
Una vez definida la alerta correladora del dispositivo, hay que asociar los dispositivos dependientes. Esto se hace desde la rama de Configuración, en la solapa de Correlación Externa.
En la parte superior aparecerá la lista de dispositivos que tienen definida una alerta correladora y en la parte inferior una tabla con los dispositivos presentes en el sistema para asociar/desasociar a cada una de las alertas correladoras de la mitad superior.
Lo habitual es que la alerta correladora sea la de dispositivo incomunicado, pero para ver otras posibilidades, en este ejemplo hemos utilizado un monitor basado en una métrica de tipo proxy que detecta si hay correos de SPAM en una cuenta de correo. Al producirse la alerta, el dispositivo correlado es el equipo windows7.s30labsi.com.
En la correlación externa, las alertas de los dispositivos correlados aparecen con la severidad gris como se puede observar en la siguiente imágen.
Si no se hubiera definido la correlación externa entre estos dispositivos, las alertas generadas serían las de la siguiente imágen.
