Mitternachtshacking

Manchmal bin ich selbst überrascht, wenn sich eine Firewall anders verhält, als ich das seit geraumer Zeit angenommen aber eben nie wirklich getestet habe. Gleichzeitig ist das ein Musterbeispiel wie die optische Wahrnehmung die Vorstellung über eine Funktion beeinflussen kann. Heute: Check Point FireWall-1 Implied Rules und Site-to-Site VPN.

Folgendes Szenario:

Ein VPN Remote Access User möchte sich über die linke Firewall mit einem Server im Netz der Filialniederlassung verbinden. Der VPN-User wird von der linken Firewall mit Hilfe eines LDAP-Servers in der Zentrale authentisiert. Zwischen Filiale und Zentrale gibt es ein VPN. Die Konfiguration ist relativ einfach. Zuerst das Site-to-Site VPN von Filiale zu Zentrale einrichten, wahlweise als Simplified oder Tradional VPN. Anschließend eine LDAP Account Unit konfigurieren und testen. Anschließend Konfiguration des Remote Access VPNs und der LDAP-Gruppe und Installation der Policy. Der folgende Screenshot zeigt die Konfiguration:

Sobald die Policy installiert ist, passiert folgendes: Die Anfragen an den LDAP-Server in der Zentrale werden nicht mehr verschlüsselt im VPN-Tunnel sondern plötzlich im Klartext am VPN-Tunnel vorbei übertragen. Sehr seltsam. Wenn man sich die impliziten VPN-Regeln und die regulären Implied Rules anschaut sieht man, dass oben eine implizite VPN-Regel existiert mit der Action „Encrypt & Continue“ und weiter unten eine implizite Regel für ldap zur Kommunikation mit dem LDAP-Server existiert. Die relevanten Regeln sind farbig hervorgehoben:

Die stillschweigende Annahme dieser Darstellung ist, dass wenn zuerst verschlüsselt wird und anschließend ldap erlaubt wird, die LDAP-Anfrage ebenfalls verschlüsselt wird. Das ist leider falsch. In der Check Point SecureKnowledgeBase gibt es dazu einen Artikel #sk26059, der sich mit der Thematik beschäftigt:

Solution: Remove all LDAP queries from the Control Connections and manually define these connections in the Rule Base as encrypted.

Dazu muss auf dem Management Server die Datei $FWDIR\lib\implied_rules.def editiert werden. Die Zeilen

#define enable_ldap_queries { \
all@all accept \
src in firewalled_list, \
<dst,dport> in ldap_servers_list, \
set sr3 0, RECORD_CONN(0xffffff0b); \
}


müssen zu

#define enable_ldap_queries 0


geändert werden. Danach wird LDAP nicht mehr in den impliziten Regeln berücksichtigt und die Verschlüsselung des VPN-Tunnels greift wieder.

Die Alternative zum Editieren von def-Dateien ist in #sk15983 beschrieben. Hier wird empfohlen, die Control Connections statt „first“ als „before last“ bearbeiten zu lassen. Das ist in NGX leider nicht mehr möglich und hat auch den Nachteil, dass dann keine brauchbare Stealth Rule zum Schutz der Firewall mehr konfiguriert werden kann. Also eigentlich auch keine Alternative.

Was ich mir wünschen würde, ist eine Konfigurationsseite in der man auswählen kann, welche Dienste denn in den Implied Rules enthalten sein sollen. So ist das ganz schon ein wenig intransparent, wenn man die Programmdateien von Check Point nicht lesen will.

Und warum fällt mir so etwas in der Praxis eigentlich nicht eher auf? Ganz einfach, wir empfehlen allen Kunden sehr dringend, solche Anfragen an einen LDAP-Server nicht im Klartext mittels ldap sondern verschlüsselt mit LDAP über SSL durchzuführen. Bei Active Directory, das die meisten mittelständischen Firmen einsetzen, ist das recht einfach zu lösen. LDAP über SSL ist von Haus aus eingebaut und muss nur mit passenden Zertifikaten eingerichtet werden. Und wenn man die Implied Rules genau anschaut dann sieht man, dass nur ldap in der impliziten Regel enthalten ist, nicht jedoch LDAP über SSL.

Mit speziellem Dank an Christian B., der mich durch seine unablässigen Fragen überhaupt erst dazu gebracht hat, das auch mal zu testen.