PaloAlto Firewall – Its a Bug, not a feature

Bereits seit 3 Jahren setzen wir auf PaloAlto bei den Firewalls in der Firma. Bisher war ich mit der Leistung, vor allem aber mit den umfangreichen Konfigurationsmöglichkeiten der bei uns eingesetzten Firewall PA-500 sehr zufrieden. Insbesondere die Möglichkeiten, die eine Anbindung von Remote-Clients per VPN und  zur LAN-LAN-Kopplung fanden und finden in unseren Umgebung breite Anwendung. Besonders hier stellt Palo Alto seine Fähigkeiten unter Beweis. Die Sicherheitsfeatures, neben SSL-VPN u.a. Antivirus, Anti-Malware und applikationsbasierte Zugriffssteuerung, arbeiten zuverlässig und effizient.

Der Zugriff per VPN erfolgt für Windows und iOS über einen separaten Client, der auf die Komponenten der Firewall zugreift. Auf der Firewall selbst werden die Sicherheitsfeatures für das VPN konfiguriert und hier gibt es alles was das Adminherz begehrt: SSL, TLS, verschiedene Protokolle von OpenVPN bis IPSec, Verzeichnisintegration (LDAP und AD), verschiedene Authentifizierungsmöglichkeiten usw. usf. Die Anbindung von Linux- und Android-Clienten stellt(e) ebenfalls kein Problem dar: auf meinen Linuxbüchsen nutze ich den Cisico-basierten Client (VPNC), auf den Androiden habe ich mit VPNCilla sehr gute Erfahrungen gemacht.

Die Anbindung funktionierte tadellos bis, ja bis Dezember letzten Jahres. Nach einem Update der PANOS genannten Firmware der Firewall war der Aufbau eines VPNs von den Clients aus nicht mehr möglich, die LAN-LAN-Kopplung hingegen werkelte weiter ohne Probleme vor sich hin. Für die Windows-Clients erledigte sich das Problem relativ schnell: eine neue Version der GlobalProtect genannten Clientsoftware wurde bereit gestellt und alles war wieder in Butter. Nur ich selbst – der ich mich immer noch ohne Windows in der digitalen Welt bewege – konnte ums Verrecken keine Verbindung mehr zu „meinem“ Netzwerk herstellen. Natürlich suchte ich die Ursache in der Konfiguration der Clients, aber es gelang mir nicht, den Fehler einzukreisen.

Gestern stiess ich nun auf den lapidaren Kommentar zu einem Artikel über die Anbindung von Android-Clients per IPSec an die PaloAlto:

If you upgrade from some lower version to 7.x there is a bug which can be fixed by removing the gateway config and configuring to again or by changing a keyword from „any“ to Any.

Also wer ein ähnliches Problem hat: es reicht tatsächlich, die Gatewaykonfiguration zu löschen und sie mit genau denselben Einstellungen neu zu erstellen (achtet darauf das eure Dokumentation aktuell ist 😉 ). Diese Einstellungen dann auf die Firewall übertragen, fertig! Der Zugriff sowohl vom Androiden als auch den Linuxrechnern ist wieder ohne Probleme möglich.

Microsoft und die Sicherheit

Ich bin ja sehr für Sicherheit, auch und gerade am Rechner. U.a. deshalb setze ich privat kein OS aus Redmond ein. Nun gehöre ich nicht zu den Religionskriegern – auch nicht was Betriebssysteme betrifft – aber so manches „Feature“ von Windows, MS-Office usw. läßt mich doch am gesunden Menschenverstand der Programmierer und/oder Verantwortlichen bei Microsoft zweifeln.

Heute wurde ich in der Firma mit einer solchen Glanzleistung konfrontiert. Als Office-Programm setzen wir MS-Office 365 ein. Neben der leidigen „Online-Featuritis“ (die umgehbar ist) und dem ebenso umgehbaren Zwang alle Komponenten des Paketes zu installieren, überwiegen tatsächlich die Vorteile dieser Variante. Vor allem preislich auch wegen der erworbenen Upgraderechte eine interessante Option.

Ich vermeide es aber grundsätzlich die von Microsoft vorgeschlagenen Standardeinstellungen zu übernehmen, zu leidvoll meine Erfahrungen mit den „Features“ diverser Programme von Microsoft in der Vergangenheit. Einer meine User, nein einer meiner „Poweruser“ teilt allerdings weder meine Abneigung gegen die Politik der Redmonder Firma noch meine Vorsicht im Umgang mit den Programmen derselben. Das Ergebnis war mal wieder niederschmetternd.

Von einem Tag auf den anderen ließen sich Dateien auf Netzlaufwerken nicht mehr öffnen. Lapidarer Kommentar von Word, Excel und Co.: „Die Datei x.x ließ sich leider nicht öffen.“. Die Auswertung der Ereignismeldungen führte nicht zu Lösung, da ähnlichen Informationsgehalts.

Nach einigem Stöbern im Internet kam die Ursache für dieses Verhalten schließlich ans Licht: seit Office 2013 setzt Microsoft wohl wieder einmal auf mehr „Sicherheit“. Über das in Office implementierte „Trustcenter“ werden sichere Speicherorte definiert und nur dort abgelegte Dateien lassen sich öffnen. Netzlaufwerke gehören grundsätzlich nicht dazu. Diesen Fakt musste ich erst einmal verarbeiten.

Ich schätze das ca. 90% aller MS-Office-Lizensen von Firmen erworben werden und die wiederum speichern geschätzte 99% ihrer Dateien auf Netzlaufwerken! Da für Windows auch Cloudspeicher nichts anderes als Netzlaufwerke sind, wird der Wahnsinn noch offenkundiger. Ich vermute allerdings, dass Microsofts Onedrive von diesem Misstrauen ausgenommen ist (wir setzen es nicht ein). Zumindest wäre das für mich die einzige halbwegs plausible Erklärung dieses hirnrissigen „Features“.

In dem geschilderten Fall half allerdings weder die Definition der Netzlaufwerke als „sicher“ noch die Neuinstallation von Office 365 – die auf ihnen abgelegten Office-Dateien liessen sich nicht öffnen. Erst eine komplette Neuinstallation der Arbeitsstation lösten das Problem.

Unfassbar auf welche Art und Weise „Product Placement“ durch Microsoft betrieben wird! An Fehler oder Dummheit der Programmierer und/oder Entscheider will ich nicht glauben. Das wäre allerdings noch desaströser …

Windows Server – Zeitquelle einstellen

In unserer IT spielt im Bereich Server Windows ja eher eine untergeordnete Rolle. Lediglich das ERP-System setzt Windows Server 2012 voraus. In letzter Zeit gab es hier einige Probleme bei der Anmeldung von Nutzern: der Server lehnte eine Anmeldung aus Sicherheitsgründen ab. Der Grund hierfür war relativ simpel: unterscheidet sich die Zeit auf Server und Client um mehr als 5 Minuten, erkennt der Server die Verbindung nicht an, weil das vewendete Kerberos-Zertifikat abgelaufen ist.

Die Lösung: am Windows-Server eine externe Zeitquelle einstellen, im Idealfall einen NTP-Server. Da im Netz ein solcher NTP-Server existiert, der sich wiederum mit einer externen Zeitquelle synchronisiert, bietet es sich an, diesen zu verwenden.

Als Administrator eine Konsole öffnen (Windows Powershell genannt) und zuerst den Zeitgeberdienst beenden:

net stop w32time

Einstellen der Zeitquelle:

w32tm /config /syncfromflags:manual /manualpeerlist:IP-Adresse des NTP-Servers

Start des Zeitgeberdienstes:

net start w32time

Innerhalb weniger Augenblicke synchronisiert sich der Windows-Server mit dem vorgegebenen NTP-Server und das Problem gehört der Vergangenheit an …