Securepoint: Webinterface startet nicht

Wenn bei der Securepoint Firewall das Webinterface beim Start hängt, liegt die oft an einem schrägen Sonderzeichen, dass nicht gelesen werden kann. In diesem Fall kann man mit dem Befehlt

config convert

die Konfiguration bereinigen. Hinterher sollte das Webinterface wieder starten.

Securepoint Firewall: Konfiguration der XFRM-Schnittstelle

Die Securepoint Firewall verwendet die XFRM-Schnittstelle des Linux-Kernels, um IP-Sec-Verbindungen aufzubauen. Wenn man genauere Informationen über die Tunnel angezeigt bekommen möchte, kann man sich im CLI (Command Line Interface) mit dem Befehlt

ip xfrm policy | more

die genaue Konfigaration der XFRM-Schnittstelle anzeigen lassen.

Älteren Securepoint Firewalls Open-VPN beibringen

Bei Securepoint Firewalls die mit einem älteren Installationsmedium installiert wurden funktioniert die Anleitung für die Einrichtung von Open-VPN von Securepoint nicht, da es keine Zone vpn-openvpn und kein Interface tun0 gibt. Betroffen sind alle Firewalls die mit einem Installationsmedium installiert wurden, das älter als Version 2007r3 ist.

Wenn man Open-VPN auf solchen Firewalls verwenden möchte muss man die Zone und das Interface zuvor anlegen. Dies kann man am einfachsten über die CLI (Comman Line Interface) mit den folgenden Befehlen.

add zone vpn-openvpn
add interface tun0 10.10.14.1/24 0 1500 0 vpn-openvpn 0 10MBIT_HALF_DUPLEX

Danach muss man die Konfiguration mit dem Befehl config save speichern. Wenn man den Konfigurationsname nicht kennt, kann man diesen zuvor mit dem Befehl config list abfragen. Dieser Befehl gibt eine Liste mit allen vorhandenen Konfigurationen aus. In dieser Liste ist die aktuelle Startkonfiguration mit einem * gekennzeichnet.

Zum Schluss muss die Konfiguration dann noch aktiviert werden. Dies geschieht mit dem Befehl update interface. Dabei sollte man jedoch beachten, dass alle Interfaces neu gestartet werden. Das kann natürlich bestehende VPN- oder Netzwerk-Verbindungen kurzzeitig unterbrechen.

Die IP-Adresse einer Securepoint V2007nx Firewall per CLI ändern

Nach einer neuen Installation einer Securepoint V2007nx Firewall kann diese normaler Weise mit dem Securepoint Security Manager V2007nx über die IP-Adresse 192.168.175.1/24 konfiguriert werden. Oft ist für die Konfiguration jedoch eine andere interne oder externe IP-Adresse nötig. Z.B. wenn man innerhalb eines Netzwerkes durch Firewall oder VLANs auf bestimmte IP-Adress-Bereiche angewiesen ist. In diesem Fall kann man die IP-Adresse über das CLI (Comman Line Interface) ändern. In dieses gelangt man über die lokale Konsole (lokaler Monitor und Tastatur) oder per SSH. Der Standardbenutzer ist admin und das Standardkennwort ist unsecure.

In der CLI muss zunächst mit dem Befehl change ip die IP-Adresse geändert werden. Dies könnte das z.B. wie folgt aussehnen:

change ip eth1 192.168.175.1/24 10.1.2.1/24

Danach muss diese aktiviert werden:

update interface

Danach sollte man die Firewall über die neue IP-Adresse erreichen können.

IPSec VPN zwischen FRITZ!Box und Securepoint V2007nx Firewall

Bei einer FRITZ!Box wird das VPN mit einer Konfigurationsdatei eingerichtet, die über das Webinterface eingespielt wird (Achtung das einspielen löst einen Neustart der FRITZ!Box aus). Nähere Informationen zu dem Thema FRITZ!Box und VPN können im AVM VPN Service-Portal gefunden werden.

Das Windows Programm zum erstellen der Konfigurationsdatei ist sehr puritanisch und lässt eine Einrichtung er VPN-Verbindung zu einer Securepoint V2007nx Firewall leider nicht zu. Allerdings kann man die Konfigurationsdatei hinterher mit einem Editor bearbeiten und es gibt im AVM VPN Service-Portal einige Beispielkonfigurationen. Leider hat in meinem Fall aber keine dieser Beispielkonfigurationen funktioniert. Also habe ich die Einstellungen der unterschiedlichen Beispielkonfigurationen mit einander kombiniert und schließlich die folgende Konfigurationsdatei mit einer Securepoint V2007nx Firewall (3DES/SHA in beiden Phasen und PFS) zum laufen bekommen:

/*
 
 * C:\Dokumente und Einstellungen\kristian\Anwendungsdaten\AVM\FRITZ!Fernzugang\hostname_dnsalias_net\fritzbox_hostname_dnsalias_net.cfg
 * Wed Apr 29 13:05:41 2009
 */
 
vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_lan;
                name = "Name der VPN-Verbindung";
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 123.123.123.123;
                remote_virtualip = 0.0.0.0;
                localid {
                        fqdn = "hostname.dnsalias.net";
                }
                remoteid {
                        ipadr = 123.123.123.123;
                }
                mode = phase1_mode_idp;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "geheim";
                cert_do_server_auth = no;
                use_nat_t = no;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.31.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.1.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-3des-sha/ah-no/comp-no/pfs";
                accesslist = "permit ip any 192.168.1.0 255.255.255.0";
        }
        ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500", 
                            "udp 0.0.0.0:4500 0.0.0.0:4500";
}
 
 
// EOF

Der Vollständigkeit halber hier die Konfiguration der beiden IPSec Phasen auf der Securepoint V2007nx Firewall:

IPSec Phase 1
IPSec Phase 1

IPSec Phase 2
IPSec Phase 2

Fehlerdiagnose auf einer Securepoint V2007nx Firewall mit Hilfe von tcpdump

Um Fehler im Regelwerk einer Securepoint V2007nx Firewall zu finden kann der Befehl tcpdump sehr nützlich sein. tcpdump ist zwar grundsätzlich installiert, kann jedoch nur in der root-shell benutzt werden. Um auf die root-shell zu gelangen muss zuvor der Benutzer root angelegt werden. Wie dies geht kann in dem Artikel root auf einer Securepoint V2007nx Firewall anlegen nachgelesen werden.

Wenn man in einer root-shell z.B. tcpdump icmp eingibt werden alle ICMP-Pakete angezeigt, welche die Netzwerkkarte der Firewall erreichen. Wenn man nun Pings durch die Firewall laufen lässt sieht dies etwa wie folgt aus:

17:56:57.357001 IP 172.30.5.3 > 192.168.1.2: icmp 1480: echo request seq 57072
17:56:57.547443 IP 172.30.5.3 > 192.168.1.2: icmp 1480: echo request seq 57072
17:57:33.336344 IP 172.30.18.155 > 192.168.1.26: icmp 40: echo request seq 23552
17:57:41.512609 IP blubber.blubbertest.de > mail.blubbertest.de: icmp 68: mail.ohl.de tcp port 113 unreachable
17:57:49.473517 IP 192.168.1.237 > 172.30.3.1: icmp 40: echo request seq 57286
17:57:49.986709 IP blubber.blubbertest.de > mail.blubbertest.be: icmp 68: mail.blubbertest.de tcp port 113 unreachable
17:57:51.785764 IP 192.168.1.237 > 172.30.3.1: icmp 40: echo request seq 57542
17:58:41.619018 IP blubber.blubbertest.de > mail.blubbertest.be: icmp 68: mail.blubbertest.de tcp port 113 unreachable
17:58:49.474053 IP 192.168.1.237 > 172.30.3.1: icmp 40: echo request seq 57798
17:58:51.866193 IP 192.168.1.237 > 172.30.3.1: icmp 40: echo request seq 58054
17:58:54.942763 IP 172.30.2.26 > 192.168.1.22: icmp 40: echo reply seq 48118
17:58:55.423427 IP 172.30.4.31 > 192.168.1.22: icmp 40: echo reply seq 48374
17:58:55.438019 IP 172.30.4.31 > 192.168.1.22: icmp 40: echo reply seq 48630
17:58:55.905084 IP 172.30.4.26 > 192.168.1.22: icmp 40: echo reply seq 48886
17:58:55.919020 IP 172.30.4.26 > 192.168.1.22: icmp 40: echo reply seq 49142
17:58:56.230197 IP 172.30.4.25 > 192.168.1.22: icmp 40: echo reply seq 49398
17:58:56.244292 IP 172.30.4.25 > 192.168.1.22: icmp 40: echo reply seq 49654

Insbesondere Fehler in einem Regelwerke für NAT (Network Address Translation) oder VPN (Virtual Privat Network) sind mit Hilfe von tcpdump wesentlich leichter zu finden, als wenn man nur den „log client“ von Securepoint verwendet.

Alle Zertifikate bei einer Securepoint V2007nx Firewall löschen

Das GUI (Graphical User Interface) von der Securepoint-Firewall lässt das löschen von Zertifikaten nicht zu. Über das CLI (Command Line Interface) kann man aber alle Zertifikate per Hand aus der SQLite-Datenbank löschen. Dazu muss man sich per SSH als root auf dem CLI einloggen und die folgenden Befehle eingeben:

sqlite3 /tmp/running.db
delete from x509;
delete from crls;
.quit

Bei einer Standardinstallation muss der Benutzer root jedoch zuvor angelegt werden. Siehe hierzu root auf einer Securepoint V2007nx Firewall anlegen.

root auf einer Securepoint V2007nx Firewall anlegen

Bei der Securepoint Firewall existiert bei einer Standardinstallation der Version V2007nx der Benutzer root nicht. Da der Standardbenutzer admin aber bei einer SSH-Verbindung immer direkt in dem CLI (Command Line Interface) landet, kann es sinnvoll sein einen Benutzer root anzulegen, der eine normale Shell hat. Um diesen anzulegen braucht man nur als Benutzer admin auf dem CLI den folgenden Befehl eingeben:

add user root root root <password> 1

Kernel Panic auf der Firewall

SP Kernel Panic Ich habe jetzt eine Woche lang mit einer Securepoint 2007nx R3 Firewall gekämpft, da diese immer wieder mit einer Kernel Panic stehen blieb. Da wir der einzige Kunde von Securepoint mit dieses Problem waren, gestaltete sich die Fehlersuche sehr schwierig. Komischer Weise waren die letzten Updates und Regeländerungen fast einen Monat her, bevor das Problem plötzlich mehrfach täglich auftrat.

AuslastungAuch der Trafik war zum Zeitpunkt des Fehlers nicht sonderlich hoch. Er lag bei ca. 2 MBit von möglichen 34 MBit. Der Fehler trat jedoch nur Tags auf, was dafür sprach das er nur unter etwas höherer Belastung auftritt.

Inzwischen habe ich mehrfach die Hardware getauscht und die Firewall in einem neuen Schrank, mit neuen Kabeln, einem neuen Switch und einer neuen USV verbaut. Da das Problem danach noch auftrat konnte es eigentlich nur noch an der Software liegen. Die Kernel Panic ließ vermuten, dass der Fehler im Linux Kernel selber zu suchen ist.

Der wie gewohnt schnelle und unkomplizierte Support von Securepoint hat deshalb bei git.kernel.org gestöbert und einen Fehler entdeckt, der bei IPSec-Verbindungen mit Cisco Geräten auftreten kann. Also habe ich den Kernel mit einem Update von Securepoint von Version 2.6.25.4 auf 2.6.25.5 aktualisiert.

Leider trat der Fehler danach aber wieder auf. Deshalb hat Securepoint weiter gesucht und einen Fehler im IP-Stack (skb) entdeckt, der als Ursache in Frage kommt. Daraufhin hat der Kernel-Spezialist von Securepoint den Kernel selber auf die gerade eine Woche alte Version 2.6.25.10 aktualisiert. Seit dem tritt der Fehler nicht mehr auf.

Ohne die schnelle und fachlich gute Leistung des Supports von Securepoint hätte mich dieser Fehler sicherlich noch einige Tage beschäftigt. Danke für die Hilfe!

Proxy-Benutzer mit unterschiedlichen Rechten bei einer Securepoint V2007nx

Der integrierte Squid-Proxy der Securepoint V2007nx Software kennt normaler Weise nur Benutzer, die Internetzugriff haben. Darüber hinaus gibt es nur noch die Möglichkeit bestimmte Seiten für diese Benutzer zu sperren oder zu erlauben. Es kann jedoch sinnvoll sein unterschiedliche Gruppen von Benutzern einzurichten und diesen unterschiedliche Internetseiten zu erlauben.

Ich benötige z.B. immer wieder eine Gruppe von Benutzern die alle und eine die nur bestimmte Webseiten aufrufen darf. Zusätzlich sollen alle auf bestimmte Webseiten ohne Benutzerauthentifizierung zugreifen können und bestimmte Webseiten sollen generell gesperrt werden. Da man diese speziellen Berechtigungen leider nicht über den Securepoint Security Manager einstellen kann, muss man die Änderungen über das CLI (Command line interface) direkt auf der Firewall konfigurieren.

Die Securepoint V2007nx Software speichert die gesamte Konfiguration in sogenannten Templates in einer SQLite-Datenbank. Beim Booten werden aus den Templates die eigentlichen Konfigurationsdateien erstellt. Deshalb ist es nicht sinnvoll direkt die Konfigurationsdateien anzupassen. Beim nächsten Neustart würden diese Änderungen ansonsten wieder überschrieben. Es ist stattdessen notwendig, die Templates zu ändern.

Die Templates können nicht angepasst sondern nur komplett überschrieben werden. Deshalb sollte man sich zuerst das alte Template anzeigen lassen, um dies mit Copy & Paste in einen Editor seiner Wahl zu kopieren. Danach kann man es anpassen und hinterher mit der geänderten Version das alte Template ersetzten.

Mit show extc_template /etc/squid/squid.conf kann man das Template für die zentrale Konfigurationsdatei von Squid anzeigen. Nachdem man es geändert hat kann man es mit change extc_template /etc/squid/squid.conf ersetzen.

Für meine Zwecke habe ich das Template wie folgt angepasst (die roten Zeilen habe ich geändert bzw. eingefügt):

#$Id: squid.conf 4902 2007-09-19 11:32:23Z basti $
http_port           127.0.0.1:49221 transparent
 
# Kaskadierung
#IF ${ENABLE_FORWARD}=1
cache_peer ${FORWARD_PROXY_IP} parent ${FORWARD_PROXY_PORT} 0 default no-query
#ENDIF
icp_port 0
acl QUERY urlpath_regex cgi-bin \?
acl all src 0.0.0.0/0.0.0.0
no_cache deny all
cache_mem  16 MB
cache_swap_low  70
cache_swap_high 75
maximum_object_size 4096 KB
ipcache_size 1024
ipcache_low  70
ipcache_high 75
fqdncache_size 1024
#cache_dir ufs  /var/spool/squid 1000 16 256
cache_dir null /dev/null
#cache_access_log /var/log/squid/access.log
cache_access_log /dev/null
#cache_log /var/log/squid/cache.log
cache_log /dev/null
#cache_store_log /var/log/squid/store.log
cache_store_log /dev/null
emulate_httpd_log off
mime_table /etc/squid/mime.conf
log_mime_hdrs off
pid_filename /var/run/squid.pid
debug_options ALL,1
log_fqdn off
ftp_user anonymous@foo
unlinkd_program /usr/libexec/unlinkd
 
# Authentisierung mit lokaler Datenbank
#IF ${ENABLE_AUTH_LOCAL}=1
auth_param basic program /usr/libexec/ncsa_auth /etc/squid/squid_user.dat
#ENDIF
 
# Authentisierung mit Radius
#IF ${ENABLE_AUTH_RADIUS}=1
auth_param basic program /usr/bin/squid_radius_auth -f /etc/squid_radius_auth.conf
#ENDIF
 
# Authentisierung mit LDAP oder AD
#IF ${ENABLE_AUTH_LDAP}=1
auth_param basic program /usr/libexec/squid_spldap_auth -h ${GLOB_LDAP_URI} -d ${GLOB_AD_DOMAIN}
#ENDIF
 
auth_param basic realm Securepoint Firewall
auth_param basic children 32
auth_param basic credentialsttl 2 hours
refresh_pattern         ^ftp:           1440    20%     10080
refresh_pattern         ^gopher:        1440    0%      1440
refresh_pattern         .               0       20%     4320
quick_abort_min 16 KB
quick_abort_max 16 KB
quick_abort_pct 95
negative_ttl 5 minutes
positive_dns_ttl 6 hours
negative_dns_ttl 5 minutes
range_offset_limit 0 KB
connect_timeout 120 seconds
read_timeout 15 minutes
request_timeout 30 seconds
client_lifetime 1 day
half_closed_clients on
pconn_timeout 120 seconds
shutdown_lifetime 30 seconds
 
# Authentisierunf erforderlich
 
#IF ${ENABLE_AUTH_LOCAL}=1
acl authentication proxy_auth REQUIRED
#ENDIF
 
#IF ${ENABLE_AUTH_RADIUS}=1
acl authentication proxy_auth REQUIRED
#ENDIF
 
#IF ${ENABLE_AUTH_LDAP}=1
acl authentication proxy_auth REQUIRED
#ENDIF
 
# Webseiten filtern
acl porn url_regex "/etc/squid/denied.txt"
acl noporn url_regex "/etc/squid/nodenied.txt"
 
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl SSL_ports port 443
acl Safe_ports port 20 21 80 81 443 1025-65535
acl CONNECT method CONNECT
 
acl usergroup1 proxy_auth other
acl usergroup2 proxy_auth "/etc/squid/unpriviligiert.txt"
acl usergroup3 proxy_auth "/etc/squid/priviligiert.txt"
 
# Download Grösse beschränken
#IF ${ENABLE_SIZE_LIMIT}=1
reply_body_max_size ${REPLY_BODY_MAX_SIZE} allow all
#ELSE
reply_body_max_size 0 allow all
#ENDIF
 
# Kaskadierung
#IF ${ENABLE_FORWARD}=1
never_direct allow all
#ENDIF
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
 
# Zugriff erlaubt mit oder ohne Authentisierung
#IF ${ENABLE_EXCEPTION_URL_LIST}=1
acl alle dstdomain .ohl.de .ups.com .ups.de .dpd.net .dpd.de
http_access allow alle all
#ENDIF
 
# http_access allow noporn authentication
#IF ${ENABLE_BANNED_URL_LIST}=1
http_access allow noporn authentication usergroup1
http_access deny porn authentication usergroup2
http_access allow authentication usergroup3
#ENDIF
 
#IF ${ENABLE_AUTH_LOCAL}=1
http_access allow authentication all
#ENDIF
 
#IF ${ENABLE_AUTH_RADIUS}=1
http_access allow authentication all
#ENDIF
 
#IF ${ENABLE_AUTH_LDAP}=1
http_access allow authentication all
#ENDIF
 
icp_access deny all
miss_access allow all
ident_lookup_access deny all
cache_mgr admin@somewhere
cache_effective_user nobody
cache_effective_group nogroup
visible_hostname localhost
unique_hostname localhost
logfile_rotate 0
tcp_recv_bufsize 0 bytes
memory_pools off
forwarded_for off
log_icp_queries off
icp_hit_stale off
minimum_direct_hops 4
cachemgr_passwd disable all
store_avg_object_size 13 KB
store_objects_per_bucket 50
client_db off
query_icmp off
test_reachability off
buffered_logs off
reload_into_ims off
error_directory /etc/squid/errors
maximum_single_addr_tries 3
uri_whitespace deny
prefer_direct on
strip_query_terms on
**

Durch die Änderungen in der Konfiguration von Squid gibt es die drei Benutzergruppen usergroup1, usergroup2 und usergroup3. Die Benutzer der usergroup3 stehen in der Datei „/etc/squid/priviligiert.txt“ und dürfen alle Intenetseiten aufrufen. Die Benutzer der usergroup2 sind in der Datei „/etc/squid/unpriviligiert.txt“ zu finden und dürfen nur die Internetseiten der No-Blocking-Liste aufrufen, die man über den Securepoint Security Manager einstellen kann. Alle anderen Benutzer sind in der usergroup1 und dürfen nur die Internetadressen aufrufen, die unter den Domänen „.ohl.de .ups.com .ups.de .dpd.net .dpd.de“ zu finden sind.

Danach habe ich noch die beiden von mir eingebauten Konfigurationsdateien mit add extc_template http_proxy /etc/squid/unpriviligiert.txt bzw. add extc_template http_proxy /etc/squid/priviligiert.txt als Template angelegt. Sie sollten die Namen der jeweiligen Proxy-Benutzer enthalten. Wenn die Benutzer kristian, michael und oliver alle Webseiten anschauen dürfen sollte das Template /etc/squid/priviligiert.txt wie folgt aussehen:

kristian
michael
oliver
**

Wenn des weiteren die Benutzer tester und heinrich nur die eingeschränkten Webseiten anschauen dürfen sollte das Template /etc/squid/unpriviligiert.txt wie folgt aussehen:

tester
heinrich
**

Zum Schluss müssen die Benutzer über den Securepoint Security Manager noch angelegt, der Gruppe HTTP-Proxy-Benutzer zugeordnet und der HTTP-Proxy neu gestartet werden. Danach sollten die unterschiedlichen Rechte für die Proxy-Benutzer funktionieren.