![](\"\/blog\/wp-content\/uploads\/2007\/09\/cpfw-netzwerk.gif\")
<\/p>\nManchmal bin ich selbst \u00fcberrascht, wenn sich eine Firewall anders verh\u00e4lt, als ich das seit geraumer Zeit angenommen aber eben nie wirklich getestet habe. Gleichzeitig ist das ein Musterbeispiel wie die optische Wahrnehmung die Vorstellung \u00fcber eine Funktion beeinflussen kann. Heute: Check Point FireWall-1 Implied Rules und Site-to-Site VPN.<\/p>\n
Folgendes Szenario:<\/p>\n
<\/p>\n
Ein VPN Remote Access User m\u00f6chte sich \u00fcber 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\u00dfend eine LDAP Account Unit konfigurieren und testen. Anschlie\u00dfend Konfiguration des Remote Access VPNs und der LDAP-Gruppe und Installation der Policy. Der folgende Screenshot zeigt die Konfiguration:<\/p>\n
![](\"\/blog\/wp-content\/uploads\/2007\/09\/cpfw-policy.gif\")
<\/p>\n
Sobald die Policy installiert ist, passiert folgendes: Die Anfragen an den LDAP-Server in der Zentrale werden nicht mehr verschl\u00fcsselt im VPN-Tunnel sondern pl\u00f6tzlich im Klartext am VPN-Tunnel vorbei \u00fcbertragen. Sehr seltsam. Wenn man sich die impliziten VPN-Regeln und die regul\u00e4ren Implied Rules anschaut sieht man, dass oben eine implizite VPN-Regel existiert mit der Action „Encrypt & Continue“ und weiter unten eine implizite Regel f\u00fcr ldap zur Kommunikation mit dem LDAP-Server existiert. Die relevanten Regeln sind farbig hervorgehoben:<\/p>\n
![](\"\/blog\/wp-content\/uploads\/2007\/09\/cpfw-modified.gif\")
<\/p>\n
Die stillschweigende Annahme dieser Darstellung ist, dass wenn zuerst verschl\u00fcsselt wird und anschlie\u00dfend ldap erlaubt wird, die LDAP-Anfrage ebenfalls verschl\u00fcsselt wird. Das ist leider falsch. In der Check Point SecureKnowledgeBase gibt es dazu einen Artikel #sk26059<\/em>, der sich mit der Thematik besch\u00e4ftigt:<\/p>\n Dazu muss auf dem Management Server die Datei $FWDIR\\lib\\implied_rules.def<\/em> editiert werden. Die Zeilen<\/p>\n m\u00fcssen zu<\/p>\n ge\u00e4ndert werden. Danach wird LDAP nicht mehr in den impliziten Regeln ber\u00fccksichtigt und die Verschl\u00fcsselung des VPN-Tunnels greift wieder.<\/p>\n Die Alternative zum Editieren von def-Dateien ist in #sk15983<\/em> beschrieben. Hier wird empfohlen, die Control Connections statt „first“ als „before last“ bearbeiten zu lassen. Das ist in NGX leider nicht mehr m\u00f6glich und hat auch den Nachteil, dass dann keine brauchbare Stealth Rule zum Schutz der Firewall mehr konfiguriert werden kann. Also eigentlich auch keine Alternative.<\/p>\n Was ich mir w\u00fcnschen w\u00fcrde, ist eine Konfigurationsseite in der man ausw\u00e4hlen 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.<\/p>\n Und warum f\u00e4llt 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\u00fcsselt mit LDAP \u00fcber SSL durchzuf\u00fchren. Bei Active Directory, das die meisten mittelst\u00e4ndischen Firmen einsetzen, ist das recht einfach zu l\u00f6sen. LDAP \u00fcber 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 \u00fcber SSL.<\/p>\n Mit speziellem Dank an Christian B., der mich durch seine unabl\u00e4ssigen Fragen \u00fcberhaupt erst dazu gebracht hat, das auch mal zu testen.<\/p>\n","protected":false},"excerpt":{"rendered":" Manchmal bin ich selbst \u00fcberrascht, wenn sich eine Firewall anders verh\u00e4lt, als ich das seit geraumer Zeit angenommen aber eben nie wirklich getestet habe. Gleichzeitig ist das ein Musterbeispiel wie die optische Wahrnehmung die Vorstellung \u00fcber eine Funktion beeinflussen kann. Heute: Check Point FireWall-1 Implied Rules und Site-to-Site VPN. Folgendes Szenario: Ein VPN Remote Access […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[5,15],"tags":[],"_links":{"self":[{"href":"https:\/\/www.mitternachtshacking.de\/blog\/wp-json\/wp\/v2\/posts\/250"}],"collection":[{"href":"https:\/\/www.mitternachtshacking.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.mitternachtshacking.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.mitternachtshacking.de\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.mitternachtshacking.de\/blog\/wp-json\/wp\/v2\/comments?post=250"}],"version-history":[{"count":0,"href":"https:\/\/www.mitternachtshacking.de\/blog\/wp-json\/wp\/v2\/posts\/250\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.mitternachtshacking.de\/blog\/wp-json\/wp\/v2\/media?parent=250"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.mitternachtshacking.de\/blog\/wp-json\/wp\/v2\/categories?post=250"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.mitternachtshacking.de\/blog\/wp-json\/wp\/v2\/tags?post=250"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}} Solution: Remove all LDAP queries from the Control Connections and manually define these connections in the Rule Base as encrypted.<\/ul>\n
#define enable_ldap_queries { \\
\nall@all accept \\
\nsrc in firewalled_list, \\
\n<dst,dport> in ldap_servers_list, \\
\nset sr3 0, RECORD_CONN(0xffffff0b); \\
\n}
\n<\/code><\/p>\n#define enable_ldap_queries 0
\n<\/code><\/p>\n