Freitag, 1. April 2016

SSL Inspection mit Check Point Security Gateway



Für 77.30 sollte man folgende Einstellungen verwenden, die im Expert Mode konfiguriert werden müssen.

Damit schaltet man RC4 Ciphers ab und schaltet ECDHE und ECDSA Ciphers ein.


ckp_regedit -a SOFTWARE\\CheckPoint\\FW1 CPTLS_Disable_RC4 1

ckp_regedit -a SOFTWARE\\CheckPoint\\FW1 Get_Disable_RC4 1

ckp_regedit -a SOFTWARE\\CheckPoint\\FW1 CPTLS_ACCEPT_ECDHE 1

ckp_regedit -a SOFTWARE\\CheckPoint\\FW1 CPTLS_PROPOSE_ECDHE 1
ckp_regedit -a SOFTWARE\\CheckPoint\\FW1 CPTLS_ACCEPT_ECDSA 1
ckp_regedit -a SOFTWARE\\CheckPoint\\FW1 CPTLS_PROPOSE_ECDSA 1


cpstop ; cpstart


Eventuell muss man die Werte auch nochmal zurücksetzen, um sie dann richtig zu setzen. Die bestehenden Werte werden nicht überschrieben. Also vorab ggf folgende Eingabe (-d wie delete)

ckp_regedit -d SOFTWARE\\CheckPoint\\FW1 CPTLS_Disable_RC4
ckp_regedit -d SOFTWARE\\CheckPoint\\FW1 Get_Disable_RC4 

ckp_regedit -d SOFTWARE\\CheckPoint\\FW1 CPTLS_ACCEPT_ECDHE

ckp_regedit -d SOFTWARE\\CheckPoint\\FW1 CPTLS_PROPOSE_ECDHE
ckp_regedit -d SOFTWARE\\CheckPoint\\FW1 CPTLS_ACCEPT_ECDSA

ckp_regedit -d SOFTWARE\\CheckPoint\\FW1 CPTLS_PROPOSE_ECDSA

Die gesetzten Werte kann man sich folgendermaßen anschauen:

ckp_regedit -p  SOFTWARE/CheckPoint/FW1 | grep TLS
ckp_regedit -p  SOFTWARE/CheckPoint/FW1 | grep RC4

Weitere Infos in sk104095 und sk106478

Sofern Sie weitere Informationen oder Unterstützung benötigen, finden Sie alle Kontaktdaten auf http://www.seculonia.net.

Ihr SECULONIA-Team
 

Donnerstag, 5. Juli 2012

Check Point E80.32 und neues Solid State Drive

Fragestellung

Auf einem Windows-7-Rechner ist Check Point E80.32 mit Festplattenverschlüsselung (FDE)  installiert. Nun soll eine Solid Stae Disk (SSD)-Festplatte eingebaut werden, um die Systemgeschwindigkeit zu verbessern.

Das Szenario ist vergleichbar mit dem Verlust des Rechners oder einem Festplattendefekt.


Umsetzung

Voraussetzung für die problemlose Migration ist eine vollständige Datensicherung inklusive Windows-Daten und Programmen der "alten" Festplatte. In diesem Fall wird dazu Acronis TrueImage verwendet.

Sofern ausreichend Zeit zur Verfügung steht, kann das alte Laufwerk zunächst entschlüsselt werden. Dies ist aber eigentlich nicht notwendig.

Nach Einbau des neuen Laufwerks wird die Boot-CD von Acronis dazu verwendet, sämtliche Daten des alten Laufwerks wiederherzustellen. In diesem Fall entspricht die Größe des alten Laufwerks der des neuen. Acronis ist jedoch wohl in der Lage, mit sich unterscheidenden Datenträgergrößen umzugehen.

Der erste Start mit dem neuen Laufwerk erfolgt ohne die PreBoot-Authentifizierung. Die Windows-Anmeldung sollte bereits wieder domänenintegriert sein, da sich keine Änderungen an der Domänenzugehörigkeit ergeben (SID bleibt gleich, Computer ist quasi derselbe).
Die Endpoint-Client wird nun feststellen, dass das FDE-Blade nicht ausgeführt wird. Um diesen erwarteten Status wieder zurückzusetzen, muss der Rechner im Endpoint-Management zurückgesetzt werden, wobei sämtliche im Management gespeicherten Daten verlorengehen. Das alte Laufwerk kann daher nicht mehr entschlüsselt werden.
Weiterhin sollte der Endpoint-Client nun zunächst deinstalliert und dann wieder neu installiert werden. Dies kann über die erprobten Methoden erfolgen; also entweder Initial Client oder vollständige Installation gemäß Policy aus einer MSI-Datei.

Nach dem Neustart, der der Installation folgt, wird die FDE wie gewohnt starten und die SSD wieder verschlüsseln.


Fazit

Die Umstellung eines mit E80.32 und FDE abgesicherten Rechners ist im Regelfall problemlos möglich. Die Einbindung eines neuen Rechners mit denselben Einstellungen, also beispielsweise nach einem Verlust oder Defekt, ist somit ebenfalls problemlos möglich.



Sofern Sie weitere Informationen oder Unterstützung benötigen, finden Sie alle Kontaktdaten auf http://www.seculonia.net.

Ihr SECULONIA-Team

Montag, 11. Juni 2012

Check Point: Gaia+ und PPPoE

Problemstellung

Check Point hat mit dem Release des Betriebsystems "Gaia" die besten Merkmale aus Secure Platform (SPLAT) und Nokias IPSO zusammengeführt. Seit Check Points Release R75.40 kann man Gaia installieren.

Einige Features sind im ersten General-Availabilty-Wurf nicht enthalten, daher ist Ende Mai ein Feature Pack namens Gaia+ erschienen. Details und Downloads hierzu sind im sk-Artikel 75260 abrufbar.

Ein in unserer Laborumgebung erforderliches Merkmal ist die Einwahl per PPPoE, die mit Gaia+ möglich sein soll. Nach einigen Tests stellte sich heraus, dass dieses Merkmal leider noch nicht so funktionierte wie gewünscht, denn es kam keine PPP-Verbindung zustande.

Fehleranalyse

Mittels tcpdump auf der ausgehenden Netzwerkschnittstelle findet man heraus, dass die Check Point sehr wohl mit dem Access Concentrator des Providers Daten austauscht. Im LCP-Protokollablauf finden sich allerdings einige "Conf-Requests" aus Richtung Access Concentrator, die jeweils mit "Conf-NAK" von der Check Point abgewiesen werden.

Blickt man mit Wireshark oder ähnlichen Tools tiefer in die Pakete hinein, findet man heraus, dass all diese Conf-Requests die Authentifizierungsmethode "Password Authentication Protocol" (PAP, Hex 0xC023) anbieten. Die Check Point verlangt aber stattdessen stur das "Challenge Handshake Response Protocol" (CHAP, Hex 0xC227), woraufhin der Verbindungsaufbau nach einigen Versuchen vom Access Concentrator mit einem Termination Request beendet wird.

Lösung

Offenbar ist die Check Point schon so konfiguriert, dass sie bei Vorhandensein der entsprechenden Zugangsdaten sowohl CHAP als auch PAP nutzt. Daher ist die Lösung (oder möglicherweise der Workaround, siehe unten) das Eintragen der Zugangsdaten in der Datei /etc/ppp/pap-secrets. Man kann dazu die entsprechende Zeile aus der /etc/ppp/chap-secrets kopieren.

Ob dies nun tatsächlich die Lösung oder nur ein Workaround ist, wird sich in den folgenden Tagen zeigen, wenn einige Policy Installations durchgeführt wurden oder Parameter innerhalb Gaias geändert werden. Schlimmstenfalls muss die Zeile regelmäßig per Cronjob eingefügt werden...



Sofern Sie weitere Informationen oder Unterstützung benötigen, finden Sie alle Kontaktdaten auf http://www.seculonia.net.

Ihr SECULONIA-Team

Mittwoch, 13. April 2011

Check Point R75 mit SSL VPN und Client Authentication

Situation:
Bei der Check Point Firewall sind ab Version R75 weitere Funktionen hinzugekommen, die per SSL auf dem Gateway realisiert werden. Dazu zählen Captive Portal für Identity Awareness, Mobile Access Blade ,...
Bei der Nutzung von SSL VPN (SNX, Mobile Access Blade, Abra) funktioniert die Client Authentifizierung im Partial Automatic Mode nicht mehr.



Bei einem Web Request wird folgender Fehler gezeigt:
"The URL you requested Could not be found on this server"
In der URL Zeile sieht man eine URL mit "fwauthredirect"






Mit der Verfügbarkeit von R75.10 (Zur Zeit als EA) gibt es eine Möglichkeit, dieses Fehlverhalten zu korrigieren. 
Dazu muss der Kernel Parameter multi_portal_allow_redirect auf 0 gesetzt werden.


[Expert@cp01]# fw ctl get int multi_portal_allow_redirect
Als Ergebnis sollte hier vorher eine 1 stehen.


Mit folgendem Kommando wird der Parameter zur Laufzeit gesetzt:
[Expert@cp01]# fw ctl set int multi_portal_allow_redirect 0


[Expert@cp01]# fw ctl get int multi_portal_allow_redirect
Als Ergebnis sollte hier nun eine 0 stehen.

Um das dauerhaft einzurichten, muss der Parameter folgendermaßen in die Datei
$FWDIR/boot/modules/fwkern.conf eingetragen werden, die standardmäßig nicht existiert.
multi_portal_allow_redirect=0

Unterstützung zu Check Point und weiteren interessanten Themen gibt es bei uns unter http://www.seculonia.net
Kontaktieren Sie uns auch gerne persönlich.

Ihr SECULONIA Team

Sonntag, 13. März 2011

Automatisierte Ironport Backups per SSH

Auf den Cisco Ironport Systemen ist keine Funktion zum regelmäßigen Backup der Konfiguration vorhanden.  Eine solche Funktion kann allerdings mit einem einfachen SSH Script auf einem Linux System realisiert werden.
Idealerweise arbeitet man in dem Fall mit SSH Authentifizierung mittels Public/Private Keys, um keine Passwörter in den Scripten verwenden zu müssen.
Den Tipp haben wir vor einiger Zeit von Dirk Beste (Cisco Ironport) bekommen. 

Der Benutzer auf dem Linux Host, der das Backup Script ausführen soll, benötigt ein SSH Schlüsselpaar. Falls dieses nicht existiert kann es mit dem Befehl ssh-keygen angelegt werden. Bei dem Schlüsselpaar sollte kein Passphrase vergeben werden, um den Ablauf des Scripts zu vereinfachen. Das ist natürlich nur sinnvoll, wenn der Private Key auf einer gesicherten Maschine im internen Netz liegt.


Auf dem Linux System:

user@linux 99:~$  ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in/home/user/.ssh/id_rsa.
Your public key has been saved in/home/user/.ssh/id_rsa.pub.
The key fingerprint is:
5f:65:72:d0:00:88:7b:aa:af:2d:8a:ce:47:2f:42:15

user@linux 99:~$  cat /home/user/.ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubRWZiRhItCYELRbFevN33LNvXE+Uj02J6………

Der Public Key ist eine Zeile - beim editieren/kopieren darauf achten, dass keine Return dazukommen.


Auf dem Cisco Ironport System (per ssh):

mail.seculonia.local> sshconfig

Currently installed keys for admin:

Choose the operation you want to perform:
- NEW - Add a new key.
- USER - Switch to a different user to edit.
- SETUP - Configure general settings.
[]> new

Please enter the public SSH key for authorization.
Press enter on a blank line to finish.
ssh-rsa ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubRWZiRhItCYELRbFevN33LNvXE+Uj02J6………

Currently installed keys for admin:
1. ssh-rsa AAAAB3NzaC1yc2EAA...YK9uGLjQ== (user@linux99)

Script auf dem Linux System

Das Script auf dem Linux System kann nach Belieben abgelegt werden und per CRON regelmäßig gestartet werden. Die XML Dateien der Datensicherung sind nicht sehr groß. Das unten stehende Script sichert ein ESA und ein WSA System von Cisco Ironport.

#! /bin/bash
# Backup Script for Ironport Systeme
MAIL1=mail.seculonia.local
PROXY1=proxy.seculonia.local

USERNAME=admin
DATE=`/bin/date +%Y_%m_%d`
FILE1=`ssh $USERNAME@$MAIL1 "saveconfig yes" | grep xml | cut -f 3 -d " "`
FILE2=`ssh $USERNAME@$PROXY1 "saveconfig yes" | grep xml | cut -f 3 -d " "`
scp $USERNAME@$MAIL1:./configuration/$FILE1 /data/backup/ironport/smtp1_$DATE.xml
scp $USERNAME@$PROXY1:./configuration/$FILE2 /data/backup/ironport/proxy1_$DATE.xml


Viel Erfolg beim Sichern der Cisco Ironport Konfigurationen. Weitere Unterstützung zu Cisco Ironport und weiteren interessanten Themen gibt es bei uns unter http://www.seculonia.net
Kontaktieren Sie uns auch gerne persönlich.


Ihr SECULONIA Team