Interne Firewalls

Die Aussage "Das interne Netzwerk ist vertrauenswürdig" war schon immer nicht zu halten aber viele Firmen unterscheiden weiterhin nach "Internet/DMZ/Intern". Der Hafnium: Exploit hat aber wieder mal gezeigt, dass auch "interne Server" nicht automatisch "vertrauenswürdig" sind. Diese Seite beschreibt die Möglichkeiten der erweiterten Absicherung.

Siehe dazu auch Hafnium: Exploit und Hafnium Nachbereitung und Firmen werden gehackt

Netzwerkzonen

In der klassischen "alten" Planung gab es meist folgende Bereiche, zu denen System zugeordnet wurden.

  • Intern (Grün)
    Vereinfacht sind dies alle Systeme mit einer privaten IP-Adresse. Dazu zählen Domain Controller, Member Server aber bei den meisten Firmen auch die Clients und Drucker.
  • DMZ (gelb)
    Da stellen die meisten Firmen dann ihre Reverse-Proxy-Server, mit einem Bein auch VPN-Server rein die "etwas näher" am Internet stehen und eine Brücke auf interne Dienste darstellen.
  • Internet
    Das sind dann alle externen unbekannten und nicht vertrauenswürdigen Systeme im Internet, von denen wir nichts wissen. Dazu zählen natürlich eigene Endgeräte, solange sich diese nicht z.B. per VPN o.ä. qualifiziert haben.
  • VoIP-LAN
    Wer schon eine TK-Anlage mit VoIP nutze, hat die TK-Anlage und Telefone oft in ein eigenes VLAN gesteckt, da auch die Verwaltung getrennt und Dienstleister unterschiedlich waren. Für die "Windows Administratoren" sind solche Netzwerk meist unsichtbar. Mit Skype for Business und Soft-Clients löst sich diese Trennung dergestalt, dass die Clients aus dem grünen "Intranet" nun als VoIP-Clients mit der Vermittlung sprechen müssen oder die TK-Trunks zu den VoIP-Systemen in der grünen Zone verlegt werden mussten.
  • Management LAN
    Wenn die "Netzwerker" vorsichtig sind, dann verwalten Sie ihre Switches und Router über ein eigenes "Management LAN". Der Regelfall ist es leider immer noch nicht.

Intern segmentieren

In dem Bild ist aber sehr gut zu sehen, dass de grüne "interne Zone" sehr viele Systeme enthält, die durchaus weiter untergliedert werden könnte. Bei den meisten Firmen gibt es nämlich verschiedene Systeme, die nur partiell oder gar nicht miteinander kommunizieren.

Auf der MSXFAQ beschreibe ich erst einmal die Verbindungen eines Messaging Systems mit dem Fokus auf einen Exchange Server. Ein Exchange Server greift als Domain-Mitglied primär auf das Active Directory zu, überträgt Nachrichten per SMTP und wird von Clients über HTTPS, IMAP4, POP3 etc. angesprochen. Ein ERP-System kann durchaus ein Client sein aber Exchange muss sicher nicht auf die SQL-Datenbank dieser Systeme zugreifen. Auch ein Zugriff auf einen anderen Dateiserver ist für Exchange nicht erforderlich. Aus diesem Verständnis können Sie nun Regeln der "legitimen" Verbindungen aufstellen, z.B.

Quelle Ziel Beschreibung

Exchange:Any

Infrastruktur

Als Domainmitglied muss Exchange Umfangreich zumindest mit den Domain-Controllern in seiner Site kommunizieren. Dazu gehören DNS, LDAP, Kerberos aber auch SMB auf NETLOGN/SYSVOL, Gruppenrichtlinien u.a.  Weitere Dienst wie Monitoring, Backup etc. würde ich nicht hier sondern bei diesen Diensten definieren

Exchange: Highport

 Mailrelay:25
andere Mailserver:25

Ausgehende Mails Richtung Internet und nachgeordnete Server
Mailrelay:25
andere Mailserver:25

Exchange: 25

Eingehende Mails aus dem Internet über den Spamfilter in der DMZ und ausgewählte interne Quellen.

Client Zugriff

 Exchange:80
Exchange:443
Exchange:995
Exchange:993
Exchange:587

Outlook-Clients, Smartphones aber auch automatische Prozesse müssen natürlich mit Exchange arbeiten.

Die Liste wird durch "vererbte" Zugriffe wie eben Backup, Antivirus etc.) noch länger. Sie können die Ergebnisliste dann "Allowlist" nicht nur an den verschiedenen Filtern zulassen, sondern auch alle anderen Verbindungen zuerst einmal als "suspekt" kennzeichnen oder komplett sperren.

Genau solche "Verbindungsübersichten" können Sie für alle Dienste in ihrem Netzwerk aufstellen. Ich spreche absichtlich nicht von individuellen Servern sondern von Dienste. Natürlich könnten Sie nun pro Server eine Liste erstellen aber dann müsste ein Exchange Server auch die Informationen über "Backup", "Virenscanner-Update", "Monitoring", "Matchmanagement". "Zugriff per RDP", CRL-Check etc enthalten. Diese regeln gelten aber auch für andere Server. Daher immer den Blick auf den Dienst richten.

Sonderfall ICMP

Einen Sonderfall nimmt ICMP ein. Dahinter verbirgt sich nicht nur ein schnödes "PING" um die Erreichbarkeit zu prüfen sondern auch Netzwerkstatusmeldungen wie "Port not Reachable", oder "TTL Exceeded" bei einer Schleife werden ebenso gemeldet wie "Fragmentation needed" bei WAN-Verbindungen mit kleinerer MTU-Size. Bei IPv6 ist die Blockade von ICMP gar nicht mehr möglich, das in IPv6 eine Fragmentierung von Paketen nicht mehr vorgesehen ist. Allerdings kann dies auch einen Client verwirren, der z.B. per ICMP-Ping zu einem Domaincontroller die Erreichbarkeit und Laufzeit misst. Schon daher ist ICMP im internen Netzwerk notwendig. Als Werkzeug zur Fehlersuche durch einen Administrator ist ICMP natürlich auch wünschenswert

Wenn sie ihr Netzwerk nicht segmentiert haben, dann ist ICMP natürlich möglich. Warum sollten sie dies in einem segmentieren Netzwerk unterbinden?

Welche "Firewall" filtert?

Mit dem Wissen um die erlaubten Verbindungen stellt sich nun die Frage, wer diese Richtlinien durchsetzt. Es gibt durchaus mehrere Ansätze, die auch kombiniert werden können.

  • Applikationsfirewall / Einstellungen
    Exchange kann mit "Remote-IPs" beim Receive-Connector steuern, welcher Client mit welcher Konfiguration bedient wird. Solche Einschränkungen können Sie auch im IIS umsetzen und viele andere Produkte erlauben schon in der Anwendung die Steuerung der Erreichbarkeit. Das funktioniert natürlich primär für eingehende Verbindungen.
    In Exchange können Sie z.B. auch steuern, welche Domain Controller genutzt werden sollen, um die "Ziele" zu reduzieren. Es gibt durchaus Firmen, die bei größeren Exchange-Installationen eine eigene AD-Site mit privaten Domain-Controllern für Exchange vorsehen und damit auch "böse Clients" diese DCs nicht ansprechen dürfen.
  • Firewall des Betriebssystems
    Auch Windows und Unix haben eingebaute "Firewalls", die zumindest über Prozesse, IP-Adressen und Port die Kommunikation kontrollieren können. Bei Windows müssten Dienste sogar eingehende Verbindungen explizit eintragen. Das kann eine Malware natürlich auch und ausgehende Verbindungen sind meist "per Default" erlaubt.
  • IPSec
    Eine Sonderfunktion der Windows Firewall ist die Möglichkeit mit IPSec "authentifizierte Verbindungen" zwischen Gegenstellen zu konfigurieren. Die Verbindungen müssen nicht zwingend "verschlüsselt" sein aber sie können anonyme Verbindungen blockieren. Das hilft allerdings nichts, wenn der Angreifer wie z-B- beim Hafnium: Exploit schon auf dem Server ist.
  • Netzwerk-Firewall
    Die unabhängigste Filterinstanz ist eine Firewall, die zwischen den Systemen stehen und alle Verbindungen kontrolliert. Das bedeutet natürlich einen umfangreichen Netzwerkumbau, da Sie im Extremfall jedem Server ein Subnetz spendieren müssten oder zumindest "Gruppen von Servern" in Subnetze verschieben und per IP-Routing verbinden müssen. Mit IPv6 ist ein Subnetz pro Server viel einfacher möglich.
    Die Firewall muss dann natürlich nicht nur hochverfügbar sondern vor allem schnell angebunden sein. Daher wird man hier mit Abstrichen leben und viele Verbindungen z.B. einfach nur mit Access-Listen Routen und nur sensiblere Verbindungen über eine Stateful-Inspection-Firewall leiten.
    Die Funktion "IP-Routing mit Adresse-Port-Filter" ist mittlerweile schon in Switches der Billigklasse (siehe z.B. TP-Link T2600G-28TS (TL-SG3424)) enthalten. Allerdings gibt es schon noch die so erreichbare Leistung in Form von Bandbreite und Pakete/Sek zu beachten und auch die Konfiguration und das Logging muss natürlich "tauglich" sein.

Eine allgemein gültige Empfehlung gibt es hier nicht. Sie werden immer einen Kompromiss zwischen Kosten, Betrieb und Sicherheit finden müssen.

Exchange und interne Firewalls

Auf der anderen gibt es dann wieder das "Support-Statement" der Hersteller zu ihren Produkten. Zwischen denn allseits bekannten "erforderlichen" und "nicht benötigten" Verbindungen gibt es einen großen Graubereich. Nicht alle Hersteller dokumentieren die verwendeten Protokolle sauber und oftmals gibt es schwammige Aussagen zu dynamischen Ports. Dazu zählt insbesondere die RPC-Kommunikation, die gerne zusätzliche Verbindungen aufbaut. Das "klassische FTP" hat auch Port 21 für die Steuerung genutzt und dynamisch Port 20 im Rückkanal verwendet. Das funktioniert aber nicht bei NAT, so dass FTP sehr schnell gelernt hat, den Port 21 im "Passiv"-Mode auch für die Übertragung zu nutzen.

Bei Exchange ist die Situation etwas kniffliger, da die Exchange Dienste sehr intensiv auch mit dem Active Directory und verbundenen Diensten arbeiten. Selbst Outlook hat bis Exchange 2010 per "MAPI/TCP" mit dem Server kommuniziert. In der Cloud geht das aber nicht und seit Exchange 2013 mussten die Clients "RPC/HTTP" oder mittlerweile MAPI/HTTP nutzen.

Wir sprechen aber auch über die Exchange Server in der grünen "internen" Zone und hier habe ich von Microsoft zwei Quellen gefunden:

Starting with Exchange Server 2007 and current as of Exchange Server 2013, having network devices blocking ports/protocols between Exchange servers within a single organization or between Exchange servers and domain controllers in an organization is not supported. A network device may sit in the communication path between the servers, but a rule allowing “ANY/ANY” port and protocol communication must be in place allowing free communication between Exchange servers as well as between Exchange servers and domain controllers.
Quelle: Exchange, Firewalls, and Support… Oh, my!
https://techcommunity.microsoft.com/t5/exchange-team-blog/exchange-firewalls-and-support-8230-oh-my/ba-p/595710

Eine weitere Quelle beschreibt für Exchange 2010:

The installation of a firewall between Exchange servers or between an Exchange 2010 Mailbox or Client Access server and Active Directory isn’t supported. However, you can install a network device if traffic isn’t restricted and all available ports are open between the various Exchange servers and Active Directory.”
Quelle: http://technet.microsoft.com/en-us/library/bb331973(v=EXCHG.141).aspx

Leider habe ich noch keine Aussagen zu Exchange 2016 oder Exchange 2019 gefunden aber da sich die Grundfunktion von Exchange nicht geändert hat, dürften die Aussagen immer noch gütig sein. Interessanterweise gibt es von Microsoft auch eine Referenz, welche Eintragungen das Setup in der Windows Firewall macht. Das sind aber eingehende Verbindungen

Die Zitate beschreiben, dass Sie eine Firewall mit Exchange einsetzen können, wenn Sie keine Verbindungen blockieren. Ist eine Firewall dann sinnvoll?.

Ja. denn das erste Zitat bezieht sich explizit auf die Kommunikation zwischen...

  • ... Exchange Servern
    Mit der Einschränkung kann ich leben, dass Exchange Server miteinander kommunizieren müssen.
  • ... Exchange und Domain Controllern
    Diese Herausforderungen haben wir nicht nur mit Exchange. Quasi jedes "Domainmitglied" braucht

Damit sollte mich aber niemand daran hindern, wenn ich Verbindungen von "anderen" Systemen zu Exchange oder Exchange zu anderen Systemen erst einmal unterbinde. Ein korrumpierter Exchange Server kann dann nur Schaden in seiner Umgebung oder natürlich dem Domain Controller anrichten. Das ist schon ziemlich viel und über das "Sprungbrett Domain Controller" komme ich dann doch an die anderen Server. Aber auch die Protokollierung der Firewall hilft das Verhalten des Trojaners besser zu verstehen.

Verbindungen erfassen

Wer Systeme mit Verbindungsfiltern voneinander segmentiert, sollte genau wissen, was er tut. Eine essentielle Komponente ist die Protokollierung der Zugriffe und insbesondere der unterbundenen Verbindungen. Zuerst würde ich alle Blockaden immer derart konfigurieren, dass die Verbindungen aktiv abgelehnt und nicht einfach "gedroppt" werden. In dem Fall kann ein Administrator auf dem Server z.B. mit Wireshark sehr einfach die "Ablehnungen" in Form eines TCP-Reset beim Handshake erkennen. Er weiß dann zumindest dass die Verbindung aktiv abgelehnt wurde und muss nicht lange nach "Timeout"-Meldungen suchen. Auch für die Applikation selbst ist es einfacher in dem Fall einen Fehler zu generieren und die reagiert meist schneller.

Die Verfassung der Verbindungen liefert natürlich noch weitere Daten:

  • Wer spricht mit wem
    Dies hilft z.B. bei der Analyse von Clientzugriffen aber auch der Volumenabschätzung im WAN. Mit entsprechenden Regel lassen sich sogar "übermäßige" Datenmengen erkennen, die den Verdacht eines unerlaubten "Exports" begründen können. So wurde angeblich auch der Hafnium: Exploit im Jan 2021 von der Firma Volexity bei einem Kunden erkannt.
  • Wer versucht mit wem zu sprechen
    Eine gängige Blocklist sind Ports wie 25/TCP von Mailservern. Ein Portscan nach "offenen Relays" ist ein gutes Zeichen auf bösartige Dienst. Ein einziger Zugriff auf immer die falsche Adresse kann auch ein Hinweis auf eine falsche Konfiguration sein, z.B. Tippfehler.
  • Analyse von Diensten
    Natürlich ist eine Erfassung der Verbindungen über eine gewisse Zeit eine gute Basis, um nicht ausreichend dokumentierte Dienste auf Servern für einige Zeit zu analysieren und basierend darauf dann strengere Regeln aufzustellen. Passen Sie aber auf, dass in der Zeit nicht gerade eine Malware ihr Unwesen treibt.

Damit stellt sich die Frage, wie Sie die Verbindungsdaten aufzeichnen können. Die Administratoren kennen Wireshark oder NetMon 3.4 aber beide Werkzeuge sind für den Zweck gänzlich ungeeignet. Sie erfassen nicht nur die Verbindungen sondern schneiden auch die Inhalte mit. Das ist keine Dauerlösung. Wir brauchen ja erst einmal nur die Endpunkte der Verbindung, vielleicht mit der Uhrzeit und der Datenmenge. Dafür gibt es bessere Lösungen.

  • Firewall-Logs
    Wenn Sie schon eine Firewall "eingebaut" haben, dann ist dies natürlich eine primäre Quelle zur Erkennung der genutzten Verbindungen und des angefallenen Volumens. Wenn die Firewall schon "scharf" ist, dann sollten Sie unterbundene Verbindungen möglichst schnell melden und analysieren. Entweder sie haben bei der Freischaltung eine Paarung übersehen oder eine "unwichtige" Verbindung, die nicht erlaubt sein soll. Es könnte aber auch schon unerwünscht sein.
  • Netzwerk-Komponenten mit NetFlow/sFlow/IPFix/cFlow
    Auch Switches und Router können heute schon Verbindungen erkennen und protokollieren. Allerdings ist es ohne 3rd Party Produkte nicht immer einfach, die Daten einzusammeln und entsprechend aufzubereiten.
  • Sysinternals Sysmon (https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon)
    Diese kleine Programm kann "ungewöhnliche" Aktivitäten erkennen, z.B. den Start und das Ende von Prozessen aber auch Änderungen des "FileCreate"-Datums, wodurch sich Schadsoftware gerne mal verrät. Auch ein "Dump" eines Prozess kann erkannt und gemeldet werden. Mit der passenden Konfiguration werden auch Netzwerk-Verbindungen protokolliert. Allerdings müssen Sie sich um die Sammlung der Events selbst kümmern.
  • Packetbeat
    Eine Komponente des Elastic Stack (ELK) ist das Module Packetbeat, welches alle Pakete mitschneidet und die Metadaten erfasst. Die Ergebnisse können zu ElasticSearch, Logstash, die Konsole oder eine Datei für eine weitere Auswertung gesendet werden.

Es gibt sicher noch weitere Produkte und Tools, die auf einem Server die Verbindungen mit protokollieren, und hier nicht weiter beschrieben sind. Ich denke da an NTOP, SNORT, Suricata und viele Derivate, die auf Basis von WINPCAP oder NPCAP einfach auf dem Netzwerk-Interface die Pakete erfassen und irgendwo ablegen.

Einschätzung

Wir haben nun das Jahr 2021 und ca. 18 Tage nach Hafnium: Exploit, bei dem vermutlich die meisten Windows und Exchange Administratoren zumindest unruhige Nächte gehabt haben. Der ein oder andere Administrator und Administratorin dürften auch noch mit Nacharbeiten beschäftigt sein. Noch mehr sollten aber darüber nachgedacht haben, wie Sie die Auswirkungen der nächsten Lücke in einem lokalen System besser kontrollieren können, d.h.

  • Schaden minimieren
    Es gab vor Hafnium schon andere schwere Lücken und auch in der Zukunft wird es immer Lücken in Systemen geben. Exchange ist das nicht alleine. Router, Switches, Firewall, Virenscanner, Monitoring-Software, Anwender u.a. sind mögliche Einfallstore. Gehen Sie davon aus, dass Sie immer im Risiko stehen und vielleicht schon ferngesteuert sind. Eine geeignete Abschottung kann den schaden eingrenzen
  • Schaden nachvollziehen
    Wenn es aber passiert ist, dann könnten ihnen die Protokolle helfen, die Tragweite besser zu erkennen. Sie können in den Logs des Servers aber auch der Gegenstellen sehen, wann welche Verbindungen versucht und welche Datenmengen übertragen wurden.
  • Anzeichen erkennen
    Über mehrere Wochen hinweg entwickeln sich "Datenströme" und eine Auswertung kann diese klassifizieren. Wenn plötzlich neue Verbindungen auftauchen oder Datenmengen ansteigen, dann kann dies ein Zeichen für einen Missbrauch sein. Es muss ja nicht gleich eine Malware sein. Auch ein unerlaubter Export von Daten durch Mitarbeiter fallen so auf. Wobei hier weniger das Netzwerk gefordert ist als die Protokollfähigkeit des Servers
  • Konfiguration optimieren.
    Mit dem Wissen um den Kommunikationsbedarf können sie ihre Firewall "enger" einstellen, verstehen die Produkte besser und erkennen sogar Fehlkonfigurationen. Wenn etwas eine Verbindung auf Port 25/TCP eines "nicht Mai-Servers" versucht, kann das ein Angriff, ein Probing, Portscan oder auch nur ein falsch konfigurierter Client sein.

Leider erfordern all diese Mehrwerte eine entsprechende Protokollierung, passende Vorfilterung und die Zusammenführung in einem zentrales Log-System. Einfache Systeme gibt es sogar kostenfrei aber die Plattform als VM, Docker-Container o.ä. müssen Sie schon selbst betreiben oder als Cloud-Service einkaufen. Danach gilt es die Filter und Regeln zu tunen, damit Sie nicht von Logs überschwemmt werden aber dennoch die relevanten Informationen erhalten. Das sind alles Kosten, die größere Firmen auf mehrere Anwender umlegen können. Je kleiner eine Firma ist, desto unwahrscheinlicher ist eine Umsetzung, speziell wenn der Administrator auch noch ganz viele andere Dinge zu tun hat.

Hier ist dann der Moment, dass "Auslagern" von Diensten wieder interessant wird. Natürlich ist ein POP3/IMAP4-Postfach bei einem Provider nicht mit Exchange Online und Outlook zu vergleichen aber auch dazwischen gibt es Hoster mit Alternativen.

Ich denke, dass die Zeit des "Small Business Servers" oder lokaler einzelner Exchange Server vorbei ist. Wer neben dem Mailserver nicht auch die Verfügbarkeit (Cluster + DAG), die Sicherheit (Revery Proxy, Patching, Inventory, Erkennung), 24h Admin-Verfügbarkeit u.a. gewährleisten kann, sollte ernsthaft über Dienste aus der Cloud nachdenken

Allen anderen hoffen ich einen Denkanstoß für eine bessere Überwachung und die Planung einer Netzwerksegmentierung gegeben zu haben.

Weitere Links