SIEM Use Cases Teil 4: Proxy Kommunikation
Ein Web-Filter auf Basis von Kategorien gehört heute zur Standard-Ausstattung jedes Unternehmens. In Zeiten, in denen über 95 % des Business-Webs verschlüsselt sind, wird der Proxy mit seinem ursprünglichen Ansatz des Cachings und der Reduktion von Datentransfers oft infrage gestellt. Als Sicherheits-Komponente kann er aber sehr wohl seine Aufgabe weiterhin erfüllen.
Verschlüsselung mit HTTPS
Wichtigste Eigenschaft in einem fast vollständig verschlüsselten Web ist das Aufbrechen der SSL-Verschlüsselung. Hier kann sich der Proxy zwischen die Website und den Client so einklinken, dass er alle Daten mitlesen kann und darf. Dann findet er schon im Download infizierte EXE Dateien oder andere böswillige Inhalte und kann die Kommunikation unterbrechen. In der Praxis erfordert die sogenannte SSL-Decryption oder SSL-Inspection einen sehr hohen organisatorischen Aufwand, weil beispielsweise die Zustimmung des Betriebsrates eingeholt werden muss.
Verschlüsselte Kommunikation
Kann ein Proxy nur auf Basis von verschlüsselten Verbindungen filtern, muss er hierfür die Metadaten heranziehen. Er sieht in diesem Fall nur den DNS-Namen des Kommunikations-Partners und die Kategorie, in der dieser DNS-Name einsortiert ist sowie die aus dem Namen resultierende IP-Adresse. Sind irgendwelche dieser Parameter einer unerlaubten Kategorie zugeordnet oder mit einer als riskant definierten IP verbunden, wird die Verbindung nicht aufgebaut. Vom Anwender sieht er die IP-Adresse des Arbeitsplatzes und wenn eine Anmeldung am Proxy notwendig ist, auch den Benutzernamen.
Alle diese Informationen loggt ein Proxy in der Regel in seinem Logfile: Uhrzeit, DNS-Name, zugreifender Client, Kategorien, Ergebnis, Dauer, übertragenes Volumen ein- und ausgehend. Es fehlt normalerweise eine Information, die essenziell sein kann: die IP-Adresse im Internet, zu dem die Verbindung aufgebaut wurde. Warum kann das essenziell sein?
Die Übersetzung eines DNS-Namens in eine IP erfolgt in der Regel bei jedem Aufruf des DNS-Namens. Im DNS-Service sind an verschiedenen Stellen Caching-Mechanismen implementiert, aber grundsätzlich sind diese Daten flüchtig. Diese DNS-Schicht kann ein Angreifer dazu verwenden, in verschiedenen Szenarien zu bestimmten Zeiten oder für bestimmte Anfragen spezielle Auflösungen für den DNS-Namen zu präsentieren. Wenn dann festgestellt werden soll, ob der Proxy eine Verbindung zu einer bestimmten IP aufgebaut hatte, kann es sein, das nur anhand der protokollierten DNS-Namen nicht nachvollzogen werden kann, ob mit einer bestimmten IP kommuniziert wurde.
Aber ein SIEM kann doch korrelieren?
Wenn das SIEM jetzt auch die Firewall-Logs aufnimmt, hat es doch die Proxy-Logs, der Proxy kommuniziert über die Firewall und dann kann das SIEM das doch ermitteln? Bedingt ist das korrekt, denn in der Regel ist die einzig mögliche Korrelations-Mechanik in einem solchen Fall der Zeitstempel. Dieser Zeitstempel ist aber, trotz einer möglichen Synchronisation zwischen den Systemen, kein guter Wert zum Korrelieren, denn er ist nicht eineindeutig. Selbst in einer Millisekunden-Auflösung braucht es möglicherweise andere Parameter und Annahmen, um einen Verbindungsaufbau des Web-Proxy zu den Servern über die Firewall eindeutig zu identifizieren.
Vollständig protokollieren
Darum empfehlen wir grundsätzlich – in der Praxis ist das leider nicht immer der Fall – die Logfiles der Proxy-Systeme um die konkret zugegriffene Ziel-IP-Adresse zu erweitern. Dann ist eindeutig festgelegt, welche Adresse wirklich kontaktiert wurde und es muss nicht nachträglich erneut ermittelt werden.
Die nachträgliche Ermittlung einer IP-Adresse zu einem Domain-Namen ist ebenfalls fehlerbehaftet. Die IP-Adressen zu einem DNS-Namen lassen sich ändern, über Indirektionen abbilden und könnten geolokalisiert sein oder nach einem Round-Robin-Verfahren ausgeliefert werden. Eventuell haben sie auch nur für wenige Stunden auf einen gefährlichen Server gezeigt. Das würde ohne protokollierte IP-Adresse möglicherweise völlig unentdeckt bleiben.
Der Proxy als Weg ins Internet
In der Regel liefert der Proxy deutlich mehr Informationen als die einfache Firewall über die Metadaten der Verbindung. Auch hier können URLs und IP-Adressen mit den Threat Intelligence Daten abgeglichen werden. Jetzt fallen nicht nur verdächtige IPs in den Logs auf, sondern zusätzlich auch noch verdächtige URLs. Hier sollte jetzt speziell eine Auswertung auf die Kategorien, die ein Risiko klassifizieren, erfolgen. Oftmals ist nämlich nicht der Mitarbeiter selbst bewusst dahin gesurft, sondern er wurde möglicherweise durch eine Werbeeinblendung oder von einer anderen Seite auf die risikobehaftete Seite umgeleitet.
Im schlechtesten Fall versucht eine Stufe 1 Malware, ihren eigentlichen Code nachzuladen, um voll funktionstüchtig zu werden. Hier gilt wie bei den Firewall-Anfragen: üblicherweise probieren ausgereiftere Malware-Systeme auch über den System-Proxy zu kommunizieren. Auch hier gilt: Verbindungen von innen auch außen sind entsprechend kritisch zu betrachten, hier sollte zügig gehandelt werden und eine Analyse der geblockten Verbindungen durchgeführt werden.
Firewalls als HTTP(S)-Filter
Moderne Firewall-Systeme wie die aktuellen Systeme von Check Point oder Fortinet können auch transparent die Verbindungen zu Webservern kontrollieren und filtern, ohne dass ein expliziter Proxy eingestellt ist. Dies führt zu einem einheitlichen Regelwerk, denn man kann zu den Systemen oder Benutzern die Zugriffe ins Internet an einer Stelle regulieren. Bei der Firewall sind in der Regel die Informationen in einem Protokoll-Eintrag vorhanden, weil eine Firewall schon immer mit IP-Adressen funktioniert und DNS nur unterstützten wirkte.
Organisatorische Verbote
Auch der Zugriff auf organisatorisch aber nicht technisch verbotene URLs können hier explizit ausgewertet werden. Es könnte sein, dass in der Policy des Unternehmens die aktive Verwendung von Cloud-Speicherdiensten untersagt ist. Jetzt wäre es aber denkbar, dass Partner diese Dienste nutzen und somit auch der Mitarbeiter notwendigerweise diesen Dienst nutzt. Hier wäre ein technisch durchgesetztes Verbot mit zusätzlichem Support-Aufwand verbunden, um für spezielle Fachbereiche oder Projekte das technische Verbot aufzuweichen.
Mit einem SIEM ist man in der Lage, eine auf Vertrauen basierende Lösung aufzubauen und zu kontrollieren. Wird ein Cloud-Speicherdienst genutzt, dann ist eine Klärung der ursächlichen Nutzung möglich. Die Alternative wäre, dass der Mitarbeiter in das Gäste-Netz wechselt, dort den Download tätigt und sich dann wieder mit dem Unternehmensnetz verbindet.
Die Komplexität eines möglichen Spionage-Angriffs und dem damit verbundenen Abfluss von Daten in großem Umfang werden wir in einem eigenen Use Case in einem späteren Artikel beleuchten.
Webinar Fortinet für Anwender: Anforderungen schnell & einfach umsetzen!
Im kostenlosen Webinar zeigen Ihnen Experten in praxisnahen Demo-Beispielen, wie Sie mit Fortinet den Administrationsalltag erheblich erleichtern können. Erfahren Sie, wie schnell und einfach Sie ein VPN Enrollment aufsetzen, Applikationen extern verfügbar machen und eine starke Zwei-Faktor-Authentifizierung einrichten.
Sie haben an den Terminen keine Zeit? Kein Problem! Registrieren Sie sich trotzdem. Sie bekommen dann nach dem Live-Webinar die Aufzeichnung zur Verfügung gestellt.
