MuutechDegradados_Web-256X60MuutechDegradados_Web-256X60MuutechDegradados_Web-256X60
  • Monitorización IT
  • Monitorización Industrial
  • Nosotros
  • Blog
  • .Unión Europea
Languages
  • Español
  • English
DEMO
Azure
Monitorización Multicloud, un ejemplo con AWS y Azure
junio 12, 2019
hm19
Muutech en la Hannover Messe 2019
junio 25, 2019
junio 19, 2019
Private

 

Monitoriza tus certificados HTTPS con Zabbix

 

 
Hoy en día es muy sencillo hacer que nuestro servicio o portal web disponga de un certificado HTTPS actualizado, lo cual impactará beneficiosamente en nuestro SEO, en la confianza hacia nuestros clientes y en la seguridad de las comunicaciones en general. Soluciones como la iniciativa Let’s Encrypt, impulsada por gigantes de Internet como Cisco, Akamai o RedHat, nos permiten tener certificados gratuitos, pero que caducan cada tres meses. En este caso, el automatizar su renovación es bastante sencillo utilizando el “certbot” desarrollado por ellos. Pero claro, en el mundo de los sistemas, todo puede fallar, y no es raro que por algún motivo este certbot falle. Hace unos meses, por ejemplo, dejaron de dar soporte a un cierto tipo de autenticación y esto provocó que los certbot no fueran capaces de renovar el certificado.

¿Qué opciones tenemos entonces? Una buena manera, si usamos certbot, es redirigir la salida del comando “certbot renew” si lo metemos en cron a nuestro email o a un log que leamos con el agente de Zabbix, o, siendo creativos: meter este comando como un ítem tipo “texto” de Zabbix y hacer que se ejecute cada 24 horas, devolviendo en una variable a la que podemos poner un trigger que busque “error” o “fail” en el texto devuelto. Si queréis hacerlo así, tened en cuenta los parámetros Timeout y los permisos del agente de Zabbix. Esto último podéis probarlo con:
 

 
sudo -u zabbix /usr/bin/certbot renew
 

 
Esto está muy bien, si tenemos nuestros certificados con Let’s Encrypt y además tenemos acceso al sistema. En muchos casos esto no es así, bien porque hemos comprado el certificado a una entidad certificadora como Thawte, Symantec, GeoTrust o Rapid SSL, o bien porque lo tenemos en un hosting externo o con permisos limitados (y queremos vigilar que no tengamos problemas por un error del hosting en la gestión de este certificado).

Nuevamente, Zabbix nos puede echar una mano. Si realizamos una búsqueda rápida, vemos que hay múltiples soluciones para esto, aunque ninguna integrada en el propio Zabbix. Aquí utilizaremos la más sencilla y la que está pensada para monitorizar servidores en los que no tienes acceso. En este caso: https://share.zabbix.com/cat-app/web-servers/ssl-certificates-check

Para ello, la idea es sencilla: incluir un script en “external scripts” de Zabbix, un tipo de ítem que nos permite utilizar un script en cualquier en lenguaje para rellenar valores de una métrica.

Entramos en nuestro Zabbix y configuramos:
 

 
cd /usr/lib/zabbix/externalscripts
wget https://www.zabbix.org/mw/images/7/71/Zext_ssl_cert.sh
mv Zext_ssl_cert.sh zext_ssl_cert.sh

 

 
Podemos echar un vistazo rápido al script, algo siempre recomendable ya que nunca sabemos de dónde podemos estarnos bajando una puerta trasera o código malicioso. Como veréis, es bastante sencillo, esencialmente permite extraer el tiempo que resta para caducar, así como el “issuer” o entidad certificadora (si de pronto cambia, puede ser que nos estén intentando atacar o nuestra DNS se haya visto comprometida, así que es un buen chequeo):
 

 
#! /bin/sh
#------------------------------------------------------------
# zext_ssl_cert.sh
# Script checks for number of days until certificate expires or the issuing authority
# depending on switch passed on command line.
#
#Based on script from aperto.fr (http://aperto.fr/cms/en/blog/15-blog-en/15-ssl-certificate-expiration-monitoring-with-zabbix.html)
#with additions by racooper@tamu.edu
#------------------------------------------------------------

DEBUG=0
if [ $DEBUG -gt 0 ]
then
    exec 2>>/tmp/my.log
    set -x
fi

f=$1
host=$2
port=$3
sni=$4
proto=$5

if [ -z "$sni" ]
then
    servername=$host
else
    servername=$sni
fi

if [ -n "$proto" ]
then
    starttls="-starttls $proto"
fi

case $f in
-d)
end_date=`openssl s_client -servername $servername -host $host -port $port -showcerts $starttls -prexit 2>/dev/null |
          sed -n '/BEGIN CERTIFICATE/,/END CERT/p' |
          openssl x509 -text 2>/dev/null |
          sed -n 's/ *Not After : *//p'`

if [ -n "$end_date" ]
then
    end_date_seconds=`date '+%s' --date "$end_date"`
    now_seconds=`date '+%s'`
    echo "($end_date_seconds-$now_seconds)/24/3600" | bc
fi
;;

-i)
issue_dn=`openssl s_client -servername $servername -host $host -port $port -showcerts $starttls -prexit 2>/dev/null |
          sed -n '/BEGIN CERTIFICATE/,/END CERT/p' |
          openssl x509 -text 2>/dev/null |
          sed -n 's/ *Issuer: *//p'`

if [ -n "$issue_dn" ]
then
    issuer=`echo $issue_dn | sed -n 's/.*CN=*//p'`
    echo $issuer
fi
;;
*)
echo "usage: $0 [-i|-d] hostname port sni"
echo "    -i Show Issuer"
echo "    -d Show valid days remaining"
;;
esac
 

 
Para probarlo, lo ejecutamos para nuestra web (es probable que tengas que instalar la herramienta “bc”, “yum install bc” en CentOS, por ejemplo):
 

 
[root@zocker0 externalscripts]# ./zext_ssl_cert.sh -d www.muutech.com 443
69
[root@zocker0 externalscripts]# ./zext_ssl_cert.sh -i www.muutech.com 443
Let's Encrypt Authority X3

 

 
Lo cual, es cierto, si lo vemos en el navegador:
 

 
certificado
 

 
Por tanto, solo nos queda configurarlo en el servidor Zabbix y para ello importamos la siguiente plantilla, en Templates->Import:

https://www.zabbix.org/mw/images/7/76/Zbx_export_templates.xml

Una vez importada, y para evitar los problemas que les da a mucha gente, hay que configurar como MACRO del template {$SNI} a cadena vacía. De este modo, solo en aquellos casos en los que el dominio o dominios a revisar sean diferentes al del nombre de host, deberemos rellenarlo.

Después la añadimos a nuestro host, en nuestro caso nuestra propia web:
 

 
extern
 

 
Para aquellos que queráis integrar esto en un Docker con imagen Alpine, este deberá incluir openssl, bc y coreutils para que este script pueda funcionar.

Como nota, debemos configurar al menos una interfaz de monitorización (aunque no se utilice) con el hostname (en nuestro caso www.muutech.com).
 

 
monitoring
 

 
Accediendo a Monitoring->Latest Data, podemos ver el resultado, una vez se realice el primer chequeo (podemos usar el botón “Check now” de las últimas versiones para forzarlo):
 

 
encript
 

 
¡Genial! Ahora el sistema, cual contador de la muerte nos avisará cuando falten menos de 90 días, 60, 30, 15 y 7, así como cuando expire. Nuestro certificado es de Let’s encrypt, por lo que nada más poner el template ha saltado un aviso:
 

 
web
 

 
No hay problema, deshabilitamos para este host los avisos de 90, 60 y 30 días. Lo más importante es que las alarmas, sean eso, alarmas y como veis, es importante trabajar las plantillas revisando los scripts y ajustándolas a nuestra casuística, aunque nos las descarguemos de internet. Podéis echar un vistazo al resultado en nuestra demo: http://demo.muutech.com ¡Feliz monitorización!
 
Share

Deja una respuesta Cancelar la respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Suscríbete a nuestra Newsletter

Muutech
Monitoring Solutions S.L.

Ed. Consorcio Zona Franca OF1 - Oficina C2
Área Portuaria de Bouzas s/n
36208 Vigo (Pontevedra) - ESPAÑA

Móvil: +34 886 311 711
info@muutech.com

¡Síguenos por las redes!


El proyecto “Inteligencia Artificial basada en Machine Learning Supervisado y Procesamiento de Lenguaje Natural para la identificación de causas de parada en procesos industriales” ha sido subvencionado por el CDTI
© 2017 - 2023 Muutech Legal Advice
    By continuing to browse the site you are agreeing to our use of cookies.