Die Sophos UTM bietet unter “Network Protection” –> “Advanced Threat Protection” eine Funktion an, mit der man das Netzwerk nach Malware überwachen kann. Dabei wird ausgenutzt, dass viele Malware eine Verbindung mit sogenannten “Command and Control” Servern aufnimmt, um Daten zu übermitteln oder neue Befehle entgegen zu nehmen. Wenn ein Computer versucht, eine Verbindung mit einem bekannten “Command and Control” Server aufzunehmen, wird die Verbindung geblockt und ein Alarm angezeigt (und per Mail verschickt).

Dies bietet neben einem lokal installierten Virenschutz auf den Clients eine weitere Barriere gegen Malware in einem Netzwerk. Genauere Informationen über den Vorfall erhält man, wenn man unter “Logging & Reporting” –> “View Log Files” –> “Advanced Threat Protection” –> “View” auswählt.

In dieser Datei wird angezeigt, welcher Client mit welchem Server Kontakt aufnehmen wollte. Dummerweise wird hier der DNS Server angezeigt.

Wenn die Malware eine Verbindung zu ihrem “Command and Control” Server über einen Domänennamen und nicht über eine fixe IP Adresse herstellen will, stellt der Computer zuerst eine DNS Anfrage an den DNS Server. Wenn dieser den Eintrag nicht selber liefern kann, stellt dieser eine weitere Anfrage an den externen DNS Server (häufig derjenige des Providers), um die entsprechende IP Adresse zu erhalten. Dies bedeutet also, dass auf der Firewall der DNS Server der erste ist, der eine Anfrage nach dem betroffenen DNS Namen resp. der IP auslöst. Dies ist meiner Meinung nach ein Fehlverhalten der UTM. Besser wäre es, wenn die DNS Abfrage zugelassen wäre (dies ist ja nur Verkehr mit dem vorgelagerten DNS Server) und erst der direkte Kontakt des Clients mit dem entsprechenden Server unterbunden würde. Dann könnte man im Logfile auch den Client identifizieren. Da ich nicht ganz sicher bin, habe ich eine Anfrage im Forum gestellt).

Da ich schon einmal so einen Vorfall hatte und wissen wollte, welches der betroffene Client ist, habe ich auf dem DNS Server Logging aktiviert. Weil das viel Last auf dem Server generiert, sollte man das nur zu Testzwecken aktivieren. Habe nun aber gesehen, dass es eine andere Möglichkeit gibt, die nicht so viel Last erzeugen sollte.

Auf jeden Fall findet man in den DNS Logs dann den Client, der die Anfrage ausgelöst hat, wenn man z.B. nach dem Domänennamen sucht (in meinem Fall cwporter).

Nun kann man diesen Client weiter überprüfen. Die beste ist wohl, den Client neu aufzusetzen, die zweitbeste, den Computer mit mehreren Virenscannern aus einer verlässlichen Umgebung zu testen und am Schluss kann man noch mit dem im Betriebssystem installierten Virenscanner einen Vollscan auslösen, was die unsicherste Methode ist.

Die Seite cwporter hat mit dem zweiten Weltkrieg zu tun.

Es ist also gut möglich, dass eine Lehrperson nur durch eine Internetrecherche auf diese Seite gekommen ist. Auch wenn auf dieser Seite ein “Command and Control” Server aktiv wäre (z.B. weil der Webserver gehackt wurde) wird der Alarm von der Sophos UTM reproduzierbar wieder ausgelöst, wenn man versucht, in einem Browser die Seite aufzurufen. Die UTM kann ja nicht entscheiden, ob eine Malware diesen Aufruf ausgelöst hat, oder ein Benutzer durch eine Internetrecherche. Es kann sich also genauso gut um eine sogenannte “false positive” Meldung handeln.

Auf jeden Fall handelt es sich bei Advanced Threat Protection um eine weitere sinnvolle Möglichkeit, sein Netzwerk gegen Malware zu schützen.

In diesem Beitrag habe ich beschrieben, dass wir neu auch https Verkehr scannen.

Um die https Filterung zu aktivieren, entfernt man unter “Web Protection” –> “Web Filtering” –> Registerkarte “HTTPS” das Häklein bei “Do not proxy HTTPS traffic in Transparent Mode” und wählt “Decrypt and scan”.

Damit wird nun der SSL Verkehr aufgebrochen und gescannt. Nun kann kann die SafeSearch Einstellungen der einzelnen Suchdienste erzwingen, indem man unter “Web Protection” –> “Web Filtering” –> Registerkarte “Policies” –> “Additional Options” die entsprechenden Häklein auswählt.

Damit wäre nun das Ziel erreicht. Eine entsprechende Bildersuche auf Google läuft nun dank SafeSearch ins Leere.

Wie in diesem Dokument beschrieben, reklamieren die Browser, dass das verwendete Zertifikat nicht von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt wurde.

Das Zertifikat findet sich unter “Web Protection” –> “Filtering Options” –> Registerkarte “HTTPS CAs” –> “Download”.

Das Zertifikat ohne privaten Schlüssel (.cer) kann nun über eine Gruppenrichtlinie auf alle Computer verteilt werden. Dazu importiert man das Zertifikat unter “Computerkonfiguration” –> “Richtlinien” –> “Windows-Einstellungen” –> “Sicherheitseinstellungen” –> “Richtlinien für öffentliche Schlüssel” –> “Vertrauenswürdige Stammzertifizierungsstellen”.

Danach funktioniert der Aufruf von https Seiten ohne Warnhinweis, da dem Zertifikat vertraut wird. Wenn man aber auf das Schloss in der Adresszeile klickt, sieht man, dass der Herausgeber des Zertifikats durch “Schule Altstaetten Proxy CA” ersetzt wurde.

Für die internen Computer ist also alles wie gewünscht umgesetzt. Ein Problem bleibt aber. Die privaten Geräte von Lehrpersonen und Schüler/-innen müssen das Zertifikat manuell auch installieren, wenn die Fehlermeldung nicht mehr kommen soll.

Sophos hat dafür die Domain fw-notify.net registriert, auf der aber nichts veröffentlicht ist. Die Sophos UTM besitzt aber diesen DNS Eintrag, der auf die UTM selber zeigt. Das Zertifikat ist so unter http://passthrough.fw-notify.net/cacert.pem erreichbar.

Da diese Seite nicht einfach zu merken ist, habe ich sie auf unserer Homepage verlinkt. Ausserdem habe ich den Hotspot so angepasst, dass man nach erfolgreicher Eingabe des Tagespassworts direkt auf diese Seite weitergeleitet wird.

Damit ist auch sichergestellt, dass alle, die unser WLAN benutzen, darauf hingewiesen wurden, dass SSL aufgebrochen wird.

Nachtrag
Das Zertifikat, das unter http://passthrough.fw-notify.net/cacert.pem erreichbar ist, kann unter Android nicht installiert werden. Daher muss für Android das Zertifikat anders abgespeichert werden. Dazu kann man das importierte Zertifikat unter Windows exportieren.

Das Zertifikat für Android muss man dann noch von .cer auf .crt umbenennen. So musste ich also zwei Zertifikate veröffentlichen, eines für Windows und iOS und ein anderes für Android.

Eine Anleitung für die verschiedenen Geräte findet sich hier.

Nachtrag 2
Der AppStore auf iPads funktioniert nach der Umstellung nicht mehr richtig. Ich habe unter “Filtering Options” –> “Exceptions” eine Ausnahme für “URL Filter” und “SSL scanning” für die Seiten von Apple und mzstatic (gehört zu Apple) erstellt. Danach funktioniert auch der AppStore wieder.

Drei unserer Kindergärten haben einen eigenen Internetzugang und sind von dort über eine VPN Verbindung mit dem grossen Schulnetzwerk verbunden.

Neu binden wir diese nicht mehr mit einem IPSec Tunnel ein, sondern mit einer zu unserer Firewall passenden RED.

Weiterlesen →