Monitorización Multicloud, un ejemplo con AWS y Azure
junio 12, 2019Muutech en la Hannover Messe 2019
junio 25, 2019
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:
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:
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).
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):
¡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:
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!