Die meisten Angriffe auf die IT-Infrastruktur einer Firma starten mit einem einfachen Mail. Dieses beinhaltet einen bösartigen Anhang oder noch häufiger bloss einen Link. Ein Klick darauf löst den Download für die initiale Infektion aus. Auch die Steuerung der Malware (Command and Control) und die Daten-Exfiltration erfolgt oft per http, denn dies ist der einzige erlaubte Traffic aus dem internen Netz zum Internet, alles andere sollte auf der Firewall blockiert werden.

Nur schon aus diesem Grund sollte der Web-Verkehr gut kontrolliert und überwacht werden. Das Mittel der Wahl dazu ist ein Web-Proxy. Doch welcher Proxy ist geeignet für meinen Einsatzzweck?


Anforderungen an Funktionalitäten

Ein Proxy muss verschiedene Anforderungen erfüllen. Jeder gewichtet diese aber anders. Hier einige der wichtigsten Funktionen, welche ein Proxy erfüllen sollte.

URL-Filter

Ein URL-Filter teilt möglichst jeder URL eine oder mehrere Kategorien zu. So gehört unser Blog tec-bite.ch zur Kategorie „Technology/Internet“, outlook.com zu „E-Mail“. Ein guter URL-Filter kennt aber auch sicherheitsrelevante Kategorien wie „Compromised Sites“, „Malicious Sources/Malnets“ oder „Phishing“. Der Zugriff auf bekannte bösartige URLs kann so leicht unterbunden werden.

Risk Level

Ein minimal ausgeklügelterer Angriff verwendet natürlich nicht eine altbekannte URL, sondern eine frisch zu diesem Zweck registrierte Domain. Oder eine bisher unverfängliche Domain, welche plötzlich für Phishing verwendet wird. Diese sind dann noch nicht einer Kategorie des URL-Filters zugeteilt. Doch auch diese Sites lassen sich erkennen aufgrund von verschiedenen Merkmalen: Alter der Domäne, verwendete Nameserver, was war früher unter dieser IP-Adresse erreichbar, welcher Provider wird verwendet, … All diese Informationen lassen sich zu einer Risikoabschätzung nutzen, wie gefährlich der Zugriff auf eine Site ist. Je nachdem kann der Zugriff verboten werden oder man ergreift gezielt weitere Schutzmassnahmen (Sandbox, Isolation, Blockierung von Active Content, …)

TLS Inspection

Wenn der Zugriff auf eine Webseite mal grundsätzlich erlaubt ist, so will man aber dennoch analysieren, welche Daten übertragen werden. Da heute aber die allermeisten Verbindungen durch TLS verschlüsselt sind (https), ist es wichtig, dass der Proxy als vertrauenswürdige Instanz die Verbindung aufbrechen und analysieren kann. Da heute alle modernen Browser und über 40% der Webserver den Standard TLS 1.3 unterstützen, ist es wichtig, dass der Proxy diesen nicht bloss durchlässt, sondern auch aktiv unterstützt. Nur Dank TLS Inspection ist eine inhaltliche Analyse der übertragenen Daten möglich.

AV Scan

Die transferierten Daten sollten auch auf bekannte Malware untersucht werden. Doch gezielte Angriffe setzen natürlich nicht altbekannte Malware ein, sondern einmalig kodierte, welche sich nicht so leicht durch klassische Viren-Pattern erkennen lassen. Hier gibt es verschiedene Ansätze:

Blockierung von ausführbarem Code

Downloads von Programmen, Dokumenten mit Makros und Ähnliches kann man schlicht blockieren.

Sandbox

Oder man analysiert diese Programme und Dokumente in einer Sandbox. Automatisiert wird geschaut, wie sich das Objekt verhält: Wird Netzwerktraffic ausgelöst, welche Prozesse werden in der virtuellen Maschine gestartet, …

Isolation

Oder man lässt das potenziell gefährliche Objekt in der Originalform gar nicht bis zum Benutzer kommen, sondern nur eine neue Ansicht: Die Webseite mit Javascript und anderem aktivem Inhalt gelangt nicht zum Browser auf dem Endgerät, sondern wird auf dem Proxy gerendert und nur eine Art „interaktives Bild“ wird dem Benutzer angezeigt. Ein Excel wird als Tabelle im Browser angezeigt. Oder es werden aktive Inhalte und Makros aus Office-Dokumenten entfernt.

Bei einem Vorfall soll nachvollziehbar sein, welche Daten wohin übertragen wurden.

Logging

Dazu ist ein Logging der Proxy-Zugriffe nötig. Wenn möglich zentral zugreifbar und korrelierbar mit anderen Daten wie DNS-, Firewall-, Netflow- und Endpoint-Logs.

Authentication

Aus Datenschutzgründen ist es heikel aufzuzeichnen, welcher Benutzer welche Web-Zugriffe ausgelöst hat. Für die Incident Response, aber auch zur normalen Fehleranalyse sind solche Informationen aber sehr hilfreich, wenn nicht gar zwingend. Daher muss sichergestellt werden, dass das Userverhalten nicht überwacht wird und nur bei einem Incident rechtmässig zugreifbar ist.

Authentisierungsinformationen sind aber auch wichtig für die Zugriffssteuerung: Während eine Person grundsätzlich surfen darf, sollten Web-Zugriffe durch privilegierte Admin-Accounts, Service-Accounts, Server und andere Systeme grundsätzlich unterbunden werden und nur zu bestimmten Zielen erlaubt sein.

Die Kommunikation einer Malware mit dem Angreifer oder das Ausschleusen von gesammelten Daten erfolgt heute oft via Proxy, da andere Zugriffe verboten sind und diese Web-Requests in der Masse des normalen Surf-Traffics unterzugehen drohen.

Protokollerkennung, TLS Inspection

Im einfachsten Fall werden diese Verbindungen einfach durch TLS oder http getunnelt. Darum ist es wichtig, dass der Proxy diese Protokolle versteht und nicht einfach alles durchlässt, was entfernt nach http aussieht.

IPv6

Während viele Firmennetzwerke noch mit dem legacy Protokoll IPv4 arbeiten, verwenden viele Mitarbeiter zu Hause Internet-Anschlüsse mit IPv6. Dabei geht oft vergessen, dass die Notebooks im Homeoffice oder unterwegs auch über IPv6 geschützt werden müssen und die lokale Firewall oder die Proxy-Anbindung auch mit IPv6 umgehen können müssen.

DLP

Ein Data Loss Prevention System hilft gegen unabsichtliches oder unberechtigtes Teilen von Firmen- und Kundendaten z.B. via OneDrive. Bei der bösartigen Data-Exfiltration werden die internen Daten aber vorher verpackt, verschlüsselt oder sonst wie umgewandelt, so dass ein DLP System diese nicht mehr erkennen kann. Ein DLP hilft also in den meisten Fällen nicht gegen das absichtliche Ausschleusen von Daten.

Wenn verhindert werden soll, dass die Mitarbeitenden auf dem Büro-Arbeitsplatz oder zu Arbeitszeiten bestimmte Webseiten aufrufen, so kommt wieder der URL-Filter zum Einsatz. So kann beim Aufruf von Webseiten der Kategorie „Travel“ daran erinnert werden, dass Geschäftsreisen nicht selbständig gebucht werden sollen, sondern dass dazu der firmeneigenen Buchungs-Dienst genutzt werden kann.

Früher waren die zur Verfügung stehenden Bandbreiten noch sehr beschränkt und wir waren froh um jedes Byte, welches nicht transferiert werden musste (1200/75 baud anyone?). Mittels Caching konnte man verhindern, dass eine Webseite x-fach heruntergeladen werden musste.

Die Bandbreiten wurden zumindest bei uns immer grösser und erschwinglicher. Andererseits wurden die Webseiten immer dynamischer, so dass immer weniger auf einem Proxy gecachet werden kann und muss. Trotzdem beträgt auch heute die Caching Rate noch immer 20% und mehr, da kommen schnell mal ein paar GB zusammen…

Heute zeigt sich ein gespaltenes Bild: Zum einen verwenden wir immer mehr interaktive Webservices, welche nur schlecht cachebar sind. Andererseits arbeiten viele täglich mit grossen Daten, welche z.B. auf SharePoint Online abgelegt sind. Da macht es wenig Sinn, diese für tausende von Anwendern immer wieder herunterladen zu müssen.


Anforderungen an Deployment / Platzierung

Während obige Funktionalitäts-Anforderungen grundsätzlich von jeder Art von Web Proxy erfüllt werden kann, so gibt es doch zwei prinzipiell unterschiedliche Arten von Platzierungsmöglichkeiten eines Web Proxys. Entweder betreibe ich den Proxy selber bei mir in der Firma oder ich verwende einen Cloud Service.

On-premises

Ich kann meine Proxys in meiner Firma betreiben. Heutzutage meist als Hardware-Appliance oder als virtuelle Appliance auf einem Virtualisierungssystem. Dabei ist es wichtig, dass die Proxys mit den heutigen Bandbreitenanforderungen zurechtkommen, ohne dass zur Lastverteilung x-Proxy-Systeme installiert werden müssen und viel Strom und Platz im Rack beansprucht wird.
Wenn ich nicht allen Surf-Traffic via die Firmenzentrale leiten will, so muss ich auch in Aussenstellen entsprechende Proxy-Infrastruktur zur Verfügung stellen. Damit dies nicht in zu viel Arbeit für die Administratoren ausartet, ist es wichtig, dass die Proxies zentral gesteuert werden können: Regelwerk installieren, Backup oder Upgrade sollte einfach und ohne viel Aufwand gemacht werden können.

Cloud

Wenn ich aber sehr viele kleine Aussenstellen habe, meine Benutzer oft unterwegs sind oder aus dem Home Office arbeiten und nicht aller Traffic via VPN auf zentrale Proxys geleitet werden soll, so bietet sich ein Proxy Service in der Cloud an. Jeder Client verwendet automatisch den gerade am schnellsten erreichbaren Cloud-Proxy.
Dasselbe gilt natürlich auch, wenn ich gar keine eigenen Proxies mehr betreiben will und allgemein einen Service verwenden möchte.

Hybrid

Manchmal braucht man aber auch eine Mischform: Je nach Anwendungszweck und -Ort möchte ich mal die Cloud oder den eigenen Proxy benutzen. Oder ich kann die Migration von dutzenden von Aussenstellen nicht von heute auf morgen durchführen, sondern weiss, dass der Weg in die Cloud noch Jahre dauern wird. Dann bin ich froh, wenn ich eine Proxy-Lösung einsetze, welche sowohl on-premises wie auch in der Cloud verfügbar ist und ein und dasselbe Proxy-Regelwerk für alle Benutzer umsetzt, egal wo sich diese gerade befinden.


Welcher Proxy passt zu meinen Anforderungen

Natürlich lässt sich diese Frage nicht generell beantworten, jeder hat seine spezifischen Anforderungen und jedes Produkt hat seine Vor- und Nachteile.

Wenn ich in 2 Minuten einem Kollegen empfehlen müsste, welche Proxy-Produkte er für seinen Einsatzzweck genauer anschauen soll, so würde Folgendes herauskommen:

    • Alles in der Cloud, viele Aussenstellen und remote worker? ⇒ Zscaler ZIA
    • Cloud keine Option (aus Policy Gründen, Bank, …), es soll detailliert gesteuert werden, wer oder welcher Server worauf Zugriff hat, welche TLS Zertifikate unter welchen Umständen akzeptiert werden sollen, welche Zugriff irgendwohin umgeleitet werden sollen? ⇒ Symantec ProxySG
    • Cloud keine Option, ich brauche aber „nur“ Security und keine so genaueren Steuerungsmöglichkeiten? ⇒ Cisco WSA
    • Ich brauche beides: Cloud und einen eigenen Proxy: ⇒ Symantec ProxySG on-premises mit Symantec WSS (Web Security Service) in der Cloud

Allerdings ist die Welt und somit die Entscheidungsfindung in 90% der Fälle wesentlich komplizierter. Wir haben versucht, die drei oben erwähnten Lösungen in einem Webinar grob zu vergleichen. Wir unterstützen Sie aber gerne persönlich dabei, die für Sie passende Proxy Lösung zu finden.