Check Point: HTTPS-Inspection und Letsencrypt

Innerhalb des Unternehmensnetzwerkes ist eine ausgehende HTTPS-Inspection/-Interception mittlerweile „State-of-the-Art“ und kann mithilfe einer Enterprise PKI kinderleicht durchgeführt werden. Da jedoch eine eingehende HTTPS-Inspection massive Vorteile bei der Erkennung von Angriffen bietet, sollte das Thema nicht vernachlässigt werden. Denn ohne einen Aufbruch der verschlüsselten Verbindung kann eine NGFW ihre Stärken (IPS & Co) hier nicht vollständig ausspielen.

Wenn nun ein offizielles SSL-Zertifikat käuflich erworben wird, ist es meist ebenso leicht, dies innerhalb der Check Point Firewall zu hinterlegen und für die notwendigen Verbindungen zu aktivieren. Die Laufzeit beträgt meistens 1 Jahr, sodass der Wartungsaufwand für den Wechsel des Zertifikates im Rahmen bleibt. Was aber, wenn nun anstatt eines solchen Zertifikates, ein Letsencrypt Zertifikat verwendet werden soll?

Mithilfe der nachgestellten Lösung, versuche ich nur einen automatisierten Weg aufzuzeigen, dass auch hier der manuelle Eingriff und Aufwand minimalisiert wird.

Vorraussetzungen für das nachfolgende Skript sind:

• Webserver mit einem Letsencrypt Zertifikat (ggf. auch mit dem Certbot für die automatische Verlängerung)
• Check Point Firewall als Schutz des Webservers
• Bereits konfiguriertes HTTPS-Inspection auf der Check Point für den jeweiligen Webserver
• Bereits vorhandenes Server Zertifikat im Check Point Management für die Verbindung (notfalls einmal initial manuell importieren)
• Konfigurierte SSH-Key Authentifizierung vom Check Point Management auf den Ziel Webserver

#!/bin/bash
source /etc/profile.d/CP.sh

CERTIFICATES=( "<srv1>;<cert1>" "<srv2>;<cert2>" )
LOCAL_PATH=/opt/letsencrypt
REMOTE_PATH=/etc/letsencrypt/live
PASSWORD=itfeed4p12

for key in "${CERTIFICATES[@]}"; do
   cd $LOCAL_PATH
   C_HOST=`echo $key | cut -d ";" -f 1`
   C_NAME=`echo $key | cut -d ";" -f 2`
   echo "Checking Host $C_HOST with Certificate $C_NAME ..."
   mkdir -p $C_NAME
   cd $C_NAME
   if [ ! -f local.timestamp ]; then
      touch local.timestamp
   fi
   ssh root@$C_HOST "stat $REMOTE_PATH/$C_NAME/cert.pem" | grep Mod > remote.timestamp
   COUNT=`diff local.timestamp remote.timestamp | wc -l`
   if [ $COUNT -gt 0 ]; then
      echo "Certificate has changed, downloading new content from Webserver $C_HOST ..."
      cp remote.timestamp local.timestamp
      scp root@$C_HOST:$REMOTE_PATH/$C_NAME/*.pem .
      echo "Converting PEM to P12 file..."
      cpopenssl pkcs12 -export -out $C_NAME.p12 -in fullchain.pem -inkey privkey.pem -passout pass:$PASSWORD
      echo "Pushing new file to Check Point Web API ..."
      ENDDATE=`cpopenssl x509 -enddate -noout -in cert.pem | cut -d "=" -f2`
      mgmt_cli -r true set server-certificate name "$C_NAME" base64-certificate "`cat $C_NAME.p12 | base64 | tr -d "\n"`" base64-password "`echo -n $PASSWORD| base64`" comments "Valid until $ENDDATE"
      echo "Pushing policy to gateway ..."
      mgmt_cli -r true install-policy policy-package "Standard"
   fi
done

Das Script verbindet sich per SSH zu einem, oder mehreren, Webserver(n) und prüft dort das vorliegende Letsencrypt Zertifikat auf den Zeitstempel der letzen Veränderung.

Hinweis:
Es kann, je nach Webserver und Konfiguration, sein, dass der Pfad unter der Variable REMOTE_PATH für die vorliegende Letsencrypt Installation angepasst werden muss.

Sollte nun das Letsencrypt Zertifikat neuer sein, als der vorhergehende Zeitstempel (lokal auf dem Management gespeichert), werden die Zertifikatsdateien per SCP vom Webserver auf das Check Point Management übertragen und in eine P12 Datei extrahiert. Die P12 Datei wird dann mit dem Passwort unter der Variable „PASSWORD“ geschützt.

Anschließend wird über die Check Point Management API (mgmt_cli lokal auf dem Management) das neue Zertifikat im passenden Format hochgeladen und ein Policy Push durchgeführt.

Hinweis:
Je nach Umgebung muss hier der Name vom Policy Package angepasst werden.

So wird sichergestellt, dass nach einer Verlängerung vom Certbot auch das jeweilige Zertifikat automatisiert in die Check Point importiert wird und auch die eingehende HTTPS-Inspection funktioniert.

Um mit dem Script zugleich mehrere Systeme (Webserver) bedienen zu können, sind in der Variable CERTIFICATES die dafür notwendigen Informationen hinterlegt. Format ist hier „<Server Name/IP>;<Zertifikatsname>“. In dem Linux Bash Array können daher beliebig viele Webserver angegeben werden, welche der Reihe nach geprüft und im Notfall aktualisiert werden.

Das Script lässt sich anschließend mittels GAiA Cronjob zyklisch ausführen, sodass man (hoffentlich) kein weiteres Gedankengut in diese Thematik investieren muss ;-)