HTTP-Proxy und Securepoint Antivirus

Aus Securepoint Wiki
Version vom 28. Juni 2018, 09:34 Uhr von Pascalm (Diskussion | Beiträge) (Informationen)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Wechseln zu:Navigation, Suche

Informationen

Letze Anpassung: 29.06.2018
Bemerkung:
Vorherige Versionen:


Einleitung

Unser Securepoint Antivirus Pro prüft regelmäßig, ob neue Updates vorhanden sind. Dabei wird dies auf einem Updateserver geprüft und dann von Update-Mirrors heruntergeladen. Ist ein Windows-Client direkt mit dem Internet verbunden stellt dieses kein Problem dar, da es keine Regeln gibt, die Webseitenaufrufe reglementieren.

In einer Netzwerkumgebung können diese fehlenden Regeln aber schnell negative Auswirkungen haben, so dass es ratsam ist, den Datenverkehr über den Portfilter und die Proxys zu filtern, so Schadsoftware so wenig Angriffsfläche wie möglich zu bieten und sich auszubreiten.

Eine gute Firewallkonfiguration zeichnet sich dadurch aus, dass jeder Client nur die Freigaben bekommt, die er auch wirklich benötigt. Das bedeutet für die meisten Benutzer, die auf Webseiten im Internet zugreifen, dass dieser Zugriff über den HTTP-Proxy geschiet, so dass Webseitenaufrufe über den Webfilter geregelt und die Datenpakete auf Viren gescannt werden.

In der folgenden Dokumentation stellen wir drei Szenarien dar, die das Antivirus Pro Update über den HTTP-Proxy und den Webfilter zulassen, wenn in den Client Einstellungen die UTM als Proxy eingetragen wird, diese also nicht als transparenter Proxy dazwischen steht.

Szenario 1: Standard Proxy ohne Authentifizierung

Webfilter

In diesem Fall wird der HTTP-Proxy im transparenten Modus für die Systemkonten der Clients genutzt, in dem im Webfilter nur die für die Kommunikation benötigten Webseiten freigegeben werden. Diese werden folgendermaßen in einer Webfilterregel eingetragen:

*.ikarus.at/*
*.mailsecurity.at/*

Die Sterne vor und nach den URLs sind Wildcards.

Nachdem diese URLs über das URL Feld des Regelsatzes hinzugefügt wurden, werden diese auf ‘‘zulassen‘‘ geschaltet.

Dieser Regelsatz wird abgespeichert und in unserem Beispiel dem Profil der Netzwerkgruppe internal-networks hinzugefügt. Der Regelsatz ‘‘security‘‘ kann in diesem Profil entfernt werden, da alle anderen URLs ja durch diesem Regelsatz ohnehin nicht zugelassen werden.

Das Menü für den Webfilter befindet sich unter dem Menüpunkt Anwendungen.
Ebenfalls unter Anwendungen wird das Menü HTTP-Proxy aufgerufen.

Hier muss zunächst überprüft werden ob der Transparente Modus aktiviert ist und es eine Regel gibt, mit der Datenpakete, die von der Quelle internal-network, mit dem Ziel internet und dem Protokoll HTTP über den Proxy leiten soll.

Virenscanner

Der Virenscanner vom HTTP-Proxy überprüft die Pakete, welche über den Proxy gehen.

Damit der Download von Updates ohne Probleme funktioniert, müssen Ausnahmen im Virenscanner erstellt werden. Zu beachten ist an dieser Stelle, dass es sich hierbei um reguläre Ausdrücke, sogenannte Regular Expressions, handelt, bei der einige Zeichen zusätzliche Bedeutungen haben. Diese Sonderbedeutungen werden mit einem Backslash \ vor dem Zeichen entfernt. Zum Beispiel kann ein Punkt ein Platzhalter für jedes beliebige Zeichen sein.
Die regulären Ausdrücke für die URLs im Virenscanner lauten folgendermaßen:

^[^:]*://[^\.]*\.ikarus\.at/
^[^:]*://[^\.]*\.mailsecurity\.at/

Szenario 2: Standard Proxy mit Authentifizierung

Authentifizierungsausnahme

Der Webfilter und Virenscanner wird hierbei genauso konfiguriert wie im Szenario 1, zusätzlich werden aber Authentifizierungsausnahmen benötigt, da sich der Securepoint Antivirus Client gegenüber dem Proxy nicht mit NTLM authentifizieren kann. Daher müssen die aufgerufenen URLs auch hier wieder definiert werden. Auch das geschieht wieder mit regulären Ausdrücken:

.*\.ikarus\.at
.*\.mailsecurity\.at

Da an dieser Stelle das Protokoll HTTP oder HTTPS nicht relevant ist, fallen diese Ausdrücke etwas kürzer aus als beim Virenscanner.

Szenario 3: Standard Proxy mit Authentifizierung über NTLM und Einsatz der SSL-Interception

SSL-Interception

Wenn die SSL-Interception zum Einsatz kommt, um auch die verschlüsselten Datenpakete auf Schadsoftware zu überprüfen, müssen auch hier die Server als Ausnahmen für SSL-Interception hinterlegt werden.
Dazu werden die selben Ausdrücke wie auch schon bei der Authentifizierungsausnahme verwendet.

.*\.ikarus\.at
.*\.mailsecurity\.at

Der Webfilter, Virenscanner und die Authentifizierungsausnahme wird hier genauso eingerichtet wie auch schon in den Szenarien 1 und 2.

Transparente SSL-Interception

Wenn die Transparente SSL-Interception zum Einsatz kommt, um auch die verschlüsselten Datenpakete auf Schadsoftware zu überprüfen, müssen hier die IP-Adressen der Server als Ausnahmen für SSL-Interception hinterlegt werden. Dazu wird das gesamte Netzwerk freigegeben.

.*91\.212\.136\..*