Check Point R80.40 – Warum sich das Update jetzt lohnt

Seit dem 01.07.2020 ist die Version R80.40 laut Hersteller „Default version widely recommended for all deployments„. Check Point hat seither auch noch eine Patchsammlung allgemein freigegeben (GA HFA). Damit hat R80.40 aus der Erfahrung heraus die meisten Kinderkrankheiten hinter sich und ist meiner – zugegebenermaßen hier eher konservativen – Meinung nach, nicht mehr nur für Testsysteme, sondern auch für produktive Systeme geeignet.

Für R80.40 gibt eine lange Liste von über 100 neuen Features, siehe Check Point R80.40. Hier meine Highlights, deren praktischer Einsatz ich bei dem ein oder anderen Setup unserer Kunden sehe. Teilweise beziehe ich auch neue Features von R80.20 und R80.30 mit ein, um die gesammelten Vorteile eines Updates von R80.10 oder R80.20 auf R80.40 darzustellen.

Und zum Update-Thema schon mal auf längere Sicht: im Mai 2021 ist R80.10 End of Support – und es ist wieder schneller Mai als man denkt…
Für alle drei Versionen R80.20, R80.30 und R80.40 gilt dann interessanterweise dasselbe End of Support Datum.

Embedded Appliances

Check Point stellt folgendes nicht so heraus, es hat aber durchaus praktische Bedeutung, da es ein Killer-Argument ist:
Die 14xx-Appliances hatten im Mai ihr End-of-Sale, die Rugged Appliance 1200R sind dann im kommenden Dezember soweit. Die Nachfolger-Modellreihe 15xx kann nur zentral gemanagt werden, wenn das Management >=R80.40 ist. Dafür läuft auf diesen neuen Embedded Appliances – lang ersehnt – ein R80, und zwar R80.20. Damit sind auch für die Embedded Appliances endlich die Vorteile u.a. der „unified policies“ (Inline Layer!) einsetzbar. Allerdings gilt dies in der Praxis eben weiterhin nur, wenn keine der alten 14xx-Appliances, oder noch ältere Modelle, über dasselbe Policy Package verwaltet werden.

HTTP/HTTPS

• Das Regelwerk der HTTPS Inspection ist jetzt auch vom alten SmartDashboard im R77-Style in die SmartConsole gewandert, was mehrere deutliche Vorteile mit sich bringt:
  •  Für Cloud-Dienste, die das SSL-Aufbrechen am Gateway nicht unterstützen, also schlicht nicht funktionieren, können die „Updatable Objects“ eingesetzt werden (Updatable Objects gibt es seit R80.20). D.h. ohne ständig die IP-Adressen und Domänen von z.B. „Skype for Business Online and Microsoft Teams Services“ pflegen zu müssen, kann man für diese Ziele das SSL-Aufbrechen abschalten:
    
  •  Die Konfiguration des HTTPS-Inspection-Regelwerks erfolgt pro Policy Package. D.h. bei größeren Installationen mit mehreren Policy Packages muss man nicht länger ein globales und damit tendenziell unübersichtliches Regelwerk pflegen.
  • Für die Script-Liebhaber unter uns und natürlich generell für eine (Teil-)Automatisierung: Check Point hat die API um die Konfigurationsmöglichkeit der HTTPS Inspection Policy erweitert.

• R80.40 unterstützt die Server Name Indication (kurz: SNI), und ermöglicht damit eine deutlich bessere Kategorisierung von HTTPS-Seiten ohne SSL-Inspection. D.h. wenn keine SSL-Inspection aktiv ist, erlaubt dies eine bessere Kategorisierung von HTTPS-Anfragen. Bei aktivierter SSL-Inspection greift es bevor die Verbindung aufgebrochen wird und erlaubt damit eine bessere Kategorisierung für Bypass-Regeln (genaue technische Details: sk163594: What’s new in HTTPS Inspection starting from R80.20) Dies gilt auch für R80.20 und R80.30 mit jeweils dem neuesten Update.
• Unterstützung von HTTP/2
• TLS 1.3 wird dagegen leider immer noch nicht unterstützt, es ist weiterhin für 2020 auf der road map.

Anti-Virus and SandBlast Threat Emulation

• R80.40 unterstützt weitere Archiv-Formate. Es erscheint zunächst nicht so wichtig, auch selten verwendete Archiv-Formate scannen zu können. Wenn man aber selbst einmal mitbekommen hat, wie über eine gute alte .scr Datei (Screensaver, kennen nur noch die Älteren unter uns, es zählt aber auch unter aktuellen Windows-Versionen nach wie vor zu den ausführbaren Datei-Typen) ein Angriff gelaufen ist, der unterschätzt die Nutzung wenig üblicher, aber von Standard-Programmen unterstützter Datei-Formate für Angriffe nicht mehr. Daher ist es eine Erwähnung wert. Man muss dann aber auch noch die Konfiguration prüfen, ob die zusätzlichen Archiv-Formate auch wirklich gescannt werden.
• SMBV3 Multi-Channel Connections: Dateien, die über diesen Weg übertragen werden, können aktuell nur von Check Point und nur mit R80.40 gescannt werden.
• FTP wird ab R80.30 unterstützt
• Email: Links in Emails auf Dateien über Bitly links (auch: shortened links) können mit R80.40 auch mit der Threat Emulation geprüft werden. Die Voraussetzung ist, wie für die Verarbeitung von Dateianhängen in Emails, dass der Message Transfer Agent (kurz: MTA) des Gateways verwendet wird. Das Gateway muss also als Mail-Server in der Email-Auslieferungskette konfiguriert sein. Außerdem erkennt R80.40 Links, die „BaseStriker“ nutzen.

Threat Extraction

Threat Extraction entfernt aktive Inhalte aus Office-Dokumenten. Bisher wurde die Engine auf den Gateways nur über Updates das gesamten Gateways (HFAs) oder Upgrades aktualisiert. Ab R80.40 kann davon unabhängig die Engine separat und automatisch aktualisiert werden.

Management / SmartConsole

Eine Funktion, die so mancher Admin in R80 schmerzlich vermisst hat, da sie bis R77.30 verfügbar war, ist zurück: Revert to Revision. Unter R80 wird zwar immer automatisch bei jedem Publish eine neue Revision angelegt, aber bis einschließlich R80.30 kann man sie später nur Read-Only laden. Damit ist auch kein Policy Install dieser Vorgänger-Revision möglich. Nach Änderungen gibt es daher kein einfaches „zurück“, sondern man muss alles wieder händisch nachbauen, was man geändert hat. Passwörter, pre-shared keys gelöschte Objekte u.a. sind in dem Fall natürlich verloren.
Aber mit R80.40 wieder:

Klein aber fein: die Objektsuche unterstützt jetzt wildcards. Das hört sich unspektakulär an, aber im Daily-Doing wird das sicher enorm hilfreich.

Remote Access VPN

R80.40 unterstützt als erste Version Maschinen-Zertifikate, um nicht nur den Benutzer, sondern auch das Gerät zu authentifizieren.

Die Voraussetzungen sind: Check Point VPN Client >= E80.72, das Gerät muss im AD angelegt sein und es werden Access Roles verwendet. (Dies gilt nicht für Embedded Appliances, vermutlich da sie derzeit nur mit max. R80.20 laufen.)

Benutzerbasiertes Regelwerk (Identity Awareness)

• Das Captive Portal unterstützt jetzt SAML 2.0
• Der Identity Broker kann eingesetzt werden. Dieser ermöglicht den besseren d.h. gefilterten Austausch von Identities zwischen Gateways. Dieser Austausch von Identities ist mit dem Identity Broker sogar zwischen Gateways möglich, die von unterschiedlichen Management-Servern kontrolliert werden.

Clustering (Gateway)

• Das neue Multi-Version Clustering (kurz: MVC) erlaubt es, während des Upgrades eine gewisse Zeit lang einen Cluster mit Maschinen unterschiedlicher Versionen zu fahren. Damit wird ein längerer Testzeitraum der neuen Version möglich, während dem ein Knoten bereits aktualisiert ist, und ein Knoten noch mit der älteren, bekannt funktionierenden Version läuft. Sollte es mit etwas Verzögerung Probleme mit der neuen Version geben, kann einfach auf den Knoten mit der alten Version zurückgeschwenkt werden. Während dieses Testzeitraums sollte man aber z.B. über die SmartConsole keine Topologie-Änderungen des Clusters vornehmen. (Das wird ausdrücklich erwähnt. Auf die Idee wäre ich gar nicht gekommen, ich wäre automatisch davon ausgegangen, dass das nicht funktioniert.) Das Multi-Version Clustering ersetzt damit auch das „Full Connectivity Update“.
• R80 hat bisher Active-Active Cluster nicht mehr unterstützt, mit R80.40 gibt es diesen Cluster-Modus wieder. Die Nachteile dieses Cluster-Modus dürften sich aber gegenüber R77 nicht geändert haben, auch wenn es Szenarien gibt, in denen Active-Active ganz spezielle Probleme löst.

IoT

Das für R80.40 groß beworbene IoT-Thema ist vom Grundsatz her wichtig, sehr wichtig, darf nicht mehr einfach ausgeblendet werden. Aber beim genauerem Hinsehen setzt das neue Feature unter R80.40 hier ein „IoT Discovery Service” voraus. Dies ist eine “3rd party source that provides the necessary device attributes for each IoT device to the firewall”. Dieses Gerät muss selbstverständlich für eine reibungslose Zusammenarbeit von Check Point zertifiziert sein. Im aktuellen Admin Guide sind sechs entsprechende Hersteller aus dem Industrie-Bereich und drei aus dem Medizin-Bereich aufgelistet.

Es wird z. T. automatisiert ein separates IoT Policy Layer mit entsprechendem Regelwerk aufgebaut. Weiter werden über die übliche Application Control und speziell für IoT-Devices bereitgestellte IPS-Erkennungen die Devices bzw. das restliche Netz vor diesen Devices geschützt.

IoT-Devices besser abzusichern ist sicher ein sich lohnendes Feld. Aber „einfach“ ist es nach wie vor nicht zu haben. Ohne detaillierte Planung und Sorgfalt beim Aufbau der Regelwerke nutzt einem der schönste „IoT Discovery Service” nichts.

(Quelle: Check Point SECURITY MANAGEMENT R80.40 AdministrationGuide)

API

• Es gibt viele kleine und große Erweiterungen der Management API und damit teilweise verbunden der SmartTasks.
• R80.40 bringt eine neue REST API für Gaia mit.
• CloudGuard IaaS: die Azure- und AWS-Schnittstellen für tags und dynamische Objekte von IP-Adressen, Netzen oder Load-Balancern können angebunden werden.

Zero-Touch

Zero-Touch wurde das erste Mal ab R80.20 unterstützt. „A simple Plug & Play setup process“. Für den Aufbau an weit entfernten Standorten oder Ausrollen vieler Gateways sicher einen genaueren Blick wert…

Weitere Informationen zu den neuen Funktionen sowie technische Details finden Sie im Support Center von Check Point.