Größter Vorteil und größte Schwäche
Der größte Vorteil der IT-Vernetzung – egal ob wir die Vernetzung in einem Gebäude oder das Internet als weltweit größten Netzverbund betrachten – ist leider gleichzeitig auch ihre größte Schwäche: die Erreichbarkeit der vernetzten Systeme untereinander. Während diese Erreichbarkeit an einigen Stellen erwünscht ist – z. B. der Zugriff auf die Position der Fahrzeuge eines Logistik-Unternehmens – so kann sie an anderer Stelle unerwünscht sein (z. B. eine uneingeschränkte Kommunikationsmöglichkeit der Systeme des Finanz- und Rechnungswesen eines Unternehmens mit den in das IT-Netz integrierten Prozesssteuerungsanlagen).

Insofern ist es klar, dass die Erreichbarkeit von vernetzten Systemen untereinander in einigen Fällen eingeschränkt oder sogar völlig unterbunden werden muss. Diese Aufgabe obliegt den Netzwerk-Firewalls, die im Gegensatz zu einer auf den Endsystemen installierten Firewall (diese wird als Desktop-Firewall oder auch Personal-Firewall bezeichnet) zwischen Netzbereichen eingesetzt werden. So wird z. B. der Übergang in das Internet – egal ob im privaten Umfeld oder in professionellen Netzwerkumgebungen – in den meisten Fällen über eine Firewall kontrolliert. Diese Abgrenzung hat verständliche Ziele:

Der Einsatz einer Firewall am Übergang zum Internet – also an der Peripherie des eigenen IT-Netzwerks – entspricht dem originären Einsatz dieser Systeme. Man spricht hier deshalb zunächst auch von einer klassischen Perimeter-Sicherheit (siehe Abbildung 1).

Mittlerweile reduziert sich das Thema Firewall natürlich nicht ausschließlich auf die Sicherheit am Perimeter. Da der Grad der Vernetzung innerhalb der eigenen IT-Netze in den letzten Jahren massiv angestiegen ist, entstehen hier innerhalb dieser Netze auch Bereiche, die nicht bedingungslos einer uneingeschränkten Erreichbarkeit ausgesetzt werden können. Die Systeme zur Gebäudesteuerung oder auch Medizinprodukte sind Beispiele dafür.

Internet der Dinge
Viele Netzwerkprotagonisten sprechen mittlerweile vom Internet der Dinge und meinen damit eine enorm ansteigende Vernetzung von Systemen, die letztlich auch sehr viele Daten produzieren und für deren Transport hin zu den entsprechenden Zielsystemen IT-Netzwerke nutzen. Es ist sicherlich einsichtig, dass hier das Jeder-mit-jedem-Potenzial der IT-Netze nur noch bedingt hilfreich ist. Ein intelligenter Stromzähler (Smart Meter) ist ein Beispiel für einen vernetzten Messpunkt (also ein Beispiel für Systeme, die den Begriff Internet der Dinge motivieren), der die protokollierten Daten an den Netzbetreiber übermittelt und diesem somit eine intelligente Netz- und Ressourcensteuerung ermöglicht. Damit entfällt z. B. auch die jährliche Zählerablesung. Zur Übertragung der Daten ist natürlich ein Netzwerk erforderlich. Es ist daher verständlich, dass hier Vorkehrungen zu treffen sind, die verhindern, dass über dieses Netz auch unberechtigte Personen Ihre Daten abholen können. Wieso? Letztlich können mit diesen Daten z. B. Verbrauchsprofile erstellt werden. Insofern muss dieses Netz vor fremden Zugriffen geschützt werden, was z. B. in den Zuständigkeitsbereich einer Firewall fallen kann. Diese Maßnahme ist alleinstehend nicht ausreichend. Im einfachsten Fall versucht ein Angreifer lokal vor Ort auf den Zähler zuzugreifen. Dies ist wieder ein Beispiel dafür, dass sich eine Security-Lösung nicht über ein einzelnes Produkt oder eine einzelne Maßnahme definiert. In dem Beispiel in Abbildung 2 stellt sich die Frage, wie der Smart Meter vor einem lokalen Zugriff auf die gespeicherten Daten geschützt wird.

Hyperkonnektivität
Aus der Hyperkonnektivität heraus resultiert eine Komplexität, die einem Angreifer natürlich auch mehr Angriffspunkte zur Verfügung stellt. Primär, aber nicht ausschließlich, sind dies die nachfolgenden Punkte:

Sicherheit beinhaltet nicht nur Technik
Eine Netzwerk-Firewall kann den Zugriff über das IT-Netzwerk von System A auf System B kontrollieren und dabei ungewünschte Zugriffe unterbinden. Im Rahmen eines Sicherheitskonzepts lassen sich mit diesem Lösungsansatz aber nicht alle Sicherheitsanforderungen adressieren. Bleibt z. B. das bei der mobilen Visite eingesetzte iPad nach der Visite versehentlich in einem öffentlich zugänglichen Bereich liegen, kann eine Firewall wohl kaum einen unberechtigten Zugriffsversuch auf die eventuell im Cache Modus lokal gehaltenen Patienteninformationen verhindern. Dieses Szenario ist auch ein gutes Beispiel, um zu verdeutlichen, dass das Thema Sicherheit nicht nur technische Komponenten (z. B. Firewall-Systeme), sondern auch organisatorische, betriebliche und rechtliche Fragestellungen beinhaltet (siehe Tabelle 1).

Wörtlich übersetzt ist eine Firewall eine Brandschutzmauer. Durchaus angebracht ist aber auch das Bild einer Pforte mit Personenkontrolle: Hier werden an dedizierter Stelle alle Personen kontrolliert, die das Gebäude betreten oder verlassen. Gegebenenfalls wird der Durchgang verwehrt. Natürlich wird über eine Firewall keine physische Zutrittskontrolle umgesetzt. Vielmehr wird über das Regelwerk dieser Systeme festgelegt, welche Kommunikationsbeziehungen erlaubt sind.

Die Abbildung 3 ist im Rahmen einer Einführung in das Thema Firewall als Klassiker zu bezeichnen. Die Firewall wird hier am Rande des Netzwerks (Perimeter) eingesetzt und kontrolliert die folgenden Kommunikationsmöglichkeiten:

Demilitarized Zones (DMZ)
Die Kommunikationsmöglichkeit 2 ist in der Regel so ausgelegt, dass direkte Zugriffe aus dem Internet auf Systeme im internen Netz nicht gestattet sind. Dies ist dadurch zu begründen, dass ein erfolgreicher Angriff auf ein internes System dem Angreifer eine sehr gute Ausgangsbasis für weitere Angriffe bietet, da die nun vom eingenommenen internen System ausgehenden Aktivitäten nicht mehr von der Firewall kontrolliert werden können. Diese Vorkehrung motiviert gleichzeitig die Existenz einer oder mehrerer sogenannter Demilitarized Zones (DMZ).

Eine DMZ beherbergt Systeme, die aus dem Internet heraus erreichbar sein müssen. Beispiele dafür sind Webserver, Mailserver oder auch Nameserver. Wird ein solches System erfolgreich angegriffen, können die nun vom diesem System ausgehenden Aktivitäten immer noch von der Firewall kontrolliert werden.

Mögliches Sicherheitsniveau
Das zu ermöglichende Sicherheitsniveau für die in unserer DMZ angesiedelten Systeme kann nicht von gleicher Qualität sein, wie das für die internen Systeme. Dies ist damit zu begründen, dass auf die Systeme in unserer DMZ ein externer Zugriff möglich ist. Das heißt, ein Zugriff ausgehend von einem potenziell als sehr unsicher einzustufendem Netz.

Definition DMZ
Diese Betrachtungsweise führt uns zu einer etwas allgemeineren Definition des Begriffs DMZ: Systeme mit unterschiedlichen Sicherheitsanforderungen sollten auf unterschiedliche DMZ aufgeteilt werden. Dabei ist eine DMZ ein Netzbereich, dessen externe Kommunikationsbeziehungen über eine Firewall geführt und von dieser kontrolliert werden.

Barrierefreie Kommunikation
Wie bereits erwähnt, spielt die Einschränkung einer sonst barrierefreien Kommunikation nicht nur am klassischen Perimeter eine Rolle. Ein Netzwerk kann heute durchaus in funktionale Bereiche unterteilt sein, zwischen denen eine eingeschränkte Kommunikation möglich sein muss bzw. die auch völlig autark zu sehen sind und deshalb Übergänge in andere Netzbereiche nicht erforderlich sind. Die Abbildung 4 zeigt Beispiele für solche Bereiche auf.

Sicherheitsanforderungen formulieren
Wird der Einsatz einer Firewall angestrebt, dann müssen die relevanten Bereiche identifiziert und für jeden dieser Bereiche die Sicherheitsanforderungen formuliert werden:

Notwendigkeit, Bereiche durch Firewall zu trennen
Die Feststellung der Notwendigkeit, Bereiche durch eine Firewall voneinander zu trennen, ist natürlich erst einmal eine sehr grobe Feststellung. Für die Konfiguration des Regelwerks der Firewall sind detaillierte Informationen zum Kommunikationsbedarf der Systeme erforderlich. Dies stellt sich in der Praxis oft als eine Herausforderung dar, da die Kommunikationsanforderungen der Systeme nicht immer bekannt sind – weder dem Firewall-Administrator, noch der Fachabteilung.

Netzwerkvirtualisierung
Es sollte – um auch netzwerkaffinen Lesern gerecht zu werden – nicht unerwähnt bleiben, dass die verschiedenen Bereiche natürlich auch als Mandanten verstanden und auf der gleichen physischen Infrastruktur abgebildet werden können. Das heißt, über die Netzwerkinfrastruktur bereitgestellte Möglichkeiten der Netzwerkvirtualisierung (z. B. VLANs: Virtual LANs) sorgen dafür, dass die einzelnen Bereiche auf der logischen Ebene klar voneinander isoliert sind und die Möglichkeit der Kommunikation zwischen den einzelnen Bereichen explizit über z. B. Firewall-Systeme ermöglicht werden muss.

Proxy
Neben den Firewall-Systemen existiert mit dem Proxy eine weitere Komponente, die primär die von den zu schützenden Systemen ausgehenden Kommunikationsbeziehungen überwacht. Auf den ersten Blick verfolgen Firewall- und Proxy-Systeme das gleiche Ziel, unterscheiden sich aber maßgeblich auf der technischen Ebene, sodass die beiden Lösungen letztlich auch unterschiedlichen Anforderungen entsprechen.

Man-in-the-Middle
In der Abbildung 11 sind die beiden Verbindungsetappen zu sehen.

Der Proxy arbeitet quasi als Man-in-the-Middle und kann in dieser Rolle nun natürlich auch die Kommunikation (im Bild: HTTP) von Client und Server etwas genauer unter die Lupe nehmen und daraus in Abhängigkeit von den hinterlegten Policies Aktionen ableiten:

Die Abbildung 12 zeigt, wo z. B. im Internet Explorer von Microsoft die Proxy-Einstellungen konfiguriert werden. D. h. hier wird das System auf die Kommunikation mit einem expliziten Proxy vorbereitet.

Vor- und Nachteile
Ob ein Proxy oder eine Firewall die bessere Lösung zur Trennung von Netzbereichen ist, hängt von den konkreten Anforderungen ab. So punktet ein Proxy z. B. aufgrund der Tatsache, dass ein internes System niemals direkt mit einem externen System kommuniziert (der Proxy kommuniziert mit dem externen System) und er im Store-and-Forward-Modus arbeitet. Dafür sind die von ihm unterstützten Dienste sehr eingeschränkt. Beide Systeme können – wie die Abbildung 13 zeigt – allerdings durchaus auch gemeinsam eingesetzt werden:

Paradigma
Im Rahmen der Erklärungen zum Thema Verbindungen wurde schon erwähnt, dass auf einem Zielsystem die Anwendungen (Dienste) über sogenannte Portnummern (z. B. 80 für HTTP) angesprochen werden. Das Paradigma, dass eine Portnummer fest einer Anwendung zugeordnet ist und an dem wir später etwas rütteln möchten, hatte sehr lange Gültigkeit. Auf Basis dieses Paradigmas soll nun die nachfolgende, einfache Firewall-Regel analysiert und das daraus resultierende Risiko bewertet werden (s. Tabelle 5).

Zugriff von beliebigen Rechnern
Die Regel erlaubt den Zugriff ausgehend von beliebigen Rechnern im Internet auf beliebige Systeme in der DMZ. Allerdings kann auf diesen Systemen nur der Webserver angesprochen werden: Port 80 entspricht http. D. h. es können Webseiten aufgerufen werden. Allerdings wird Ihnen die Abbildung 14 zeigen, dass Sie die Regel zwar verstanden haben, das Ergebnis aber leider nicht Ihrer Erwartung entsprechen wird (gut gemeint ist nicht immer gut gemacht).

HTTP-Protokoll
Der Report entstammt einer Firewall, die aufzeigen kann, welche Anwendungen über sie transportiert werden. Sie belegt, dass sich heute viele Anwendungen des HTTP-Protokolls bedienen, um die Daten zwischen z. B. dem Client und der Anwendung auszutauschen. HTTP transportiert heute nicht mehr zwangsläufig Format und Inhalt einer Webseite zu Ihrem Explorer. Es kann vielmehr auch sein, dass darüber ein Radiosender aus der Cloud zur Radio-App auf Ihrem iPhone übertragen, oder aber auch eine Datei auf Ihren Rechner transferiert wird. Was erlaubt also der Firewall-Administrator, wenn er – wie in unserem Beispiel – den Zugriff auf Port 80 freigibt?

Deep Packet Inspection
Das alte Paradigma (Port gleich Anwendung) hat heute folglich nur noch bedingt Bestand. Wenn man über eine Firewall den Port 80 erlaubt oder verbietet, dann ist das zu unspezifisch. Vielmehr muss die Kontrolle durch die zusätzliche Angabe der Anwendung erfolgen, z. B. Web-Browsing (Port 80) ist erlaubt, aber http-Video (Port 80) ist verboten. Damit das aber gelingt, muss sich eine Firewall die von den Kommunikationspartnern erzeugten Datencontainer wesentlich intensiver anschauen. Das heißt, sie kann sich nicht auf die bereits vorgestellten Sektionen Internet Protocol, User Datagram Protocol und Transmission Control Protocol beschränken, sondern sie muss sich auch die in den Datencontainern enthaltenen Daten der eigentlichen Anwendung anschauen, um so Rückschlüsse auf die Anwendung selbst zu erhalten. Dies wird von den Herstellern oft als Deep Packet Inspection bezeichnet (s. Abbildung 15).

Welche Mechanismen eine Firewall nutzt, um nicht nur Kommunikationsbeziehungen, sondern auch die Anwendungen zu erkennen, soll nicht weiter diskutiert werden. Oft kennen auch nur die Hersteller die entsprechenden Details und überbieten sich gegenseitig bei der Angabe, wie viele Anwendungen ihr System aktuell detektieren kann.

Intensive Analyse
Aufgrund der intensiven Analyse der einzelnen Datencontainer können solche Firewall-Systeme natürlich auch mehr als die klassischen Firewall-Systeme sehen:

Grundlage für Kontrolle
Die so gewonnene Sichtbarkeit ist die Grundlage für eine entsprechende Kontrolle. So darf z. B. Anwender Mayer Facebook nutzen und Informationen posten, während Anwender Müller Facebook zwar aufrufen, aber keine „Features” wie z. B. Posts, News Feeds oder Spiele nutzen darf.

Application Layer Gateway (ALG)
Dass eine Firewall nicht nur die Kommunikationen, sondern auch die jeweiligen Anwendungen überwacht, ist eigentlich kein neuer Ansatz. Ein sogenanntes Application Layer Gateway (ALG) hat genau diesen Anspruch. Da bei dieser Lösung das Application Layer Gateway aber stellvertretend für die zu schützenden Endgeräte die Verbindungen hin zu den Zielsystemen aufbaut und damit zwischen den Endgeräten und den Zielsystemen vermittelt, spricht man hier wieder von einem Proxy. Das heißt, auch z. B. klassische Web-Proxy-Lösungen haben sich im Laufe der Zeit weiterentwickelt und sind sich der Tatsache bewusst, dass über die von ihnen verwalteten Verbindungen nicht mehr nur Inhalte und Formate von Webseiten übertragen werden. Vielmehr muss der Proxy für die von ihm unterstützen Träger der Kommunikation (z. B. HTTP) auch eine Differenzierung der Anwendungen unterstützen.

Unzählige Regeln
Der Autor möchte den Leser nicht mit unzähligen Firewall-Regeln langweilen, aber wenn Sie zumindest noch ein letztes Mal der folgenden Firewall-Regel (s. Tabelle 6) Ihre Aufmerksamkeit widmen, dann erwartet Sie sicherlich ein weiteres Aha-Erlebnis.

HTTPS
Wenngleich sicher nur netzwerkaffine Leser sofort wissen, was mit HTTPS (Port 443) gemeint ist, dürfte aber jeder Leser diese Anwendung kennen. Das heißt, die Eingabe von https:// in Ihrem Browser wird Ihnen nicht fremd sein und sicher auch nicht die gelegentliche Meckerei des Browsers, wenn er die Identität des Zielsystems nicht validieren kann. Letztgenanntes ist ein Problem des Zertifikats des Zielsystems und dessen Validierung durch Ihren Rechner. Ein Thema, dessen Details wir an dieser Stelle aber ausblenden wollen.

Der Hintergrund zur Frage nach der Interpretation der vorangegangenen Regel muss bestimmt nicht mehr motiviert werden und leitet sich aus den beim Thema HTTP (Port 80) gewonnenen Kenntnissen ab: Viele Anwendungen bedienen sich dem HTTPS-Protokoll, um die Daten zwischen z. B. dem Client und der Anwendung auszutauschen. Das heißt, HTTPS transportiert nicht mehr zwangsläufig Format und Inhalt einer Webseite zu Ihrem Explorer (siehe S. Abbildung 16).

Auch für Firewall nicht lesbar
Im Vergleich zu http gibt es hier aber einen wichtigen Unterschied: Bei HTTPS werden die Daten verschlüsselt übertragen und sind damit – auch für eine Firewall – nicht lesbar. Die Abbildung 17 zeigt grob, wie Sie sich den Aufbau einer solchen verschlüsselten Verbindung vorstellen müssen. Der Client fordert beim Server eine Verbindung auf Port 443 an. Beide verhandeln über diese Verbindung zunächst die kryptografischen Algorithmen und das zur Verschlüsselung der Verbindung erforderliche Schlüsselmaterial, bevor dann die weitere Kommunikation für die Augen von Dritten verschleiert wird.

Firewall erkennt keine Anwendungen
Das Problem liegt auf der Hand: Die Firewall kann keine Anwendungen erkennen und wird damit wieder rein auf eine Kontrolle der Kommunikationsbeziehungen reduziert. Um dem Veto der technisch visierten Leser gleich vorzubeugen: Ja, ein paar Anwendungen können auch erkannt werden, obwohl die eigentlichen Daten der Anwendung verschlüsselt übertragen werden. Die Diskussion der entsprechenden Abhängigkeiten sowie die dafür relevanten Informationen, die während der unverschlüsselten Phase der Kommunikation (s. Abbildung 17) ausgetauscht werden (ein Beispiel dafür ist das Zertifikat des Servers), dürften die meisten Leser aber langweilen. Dafür hätte der Autor sogar vollstes Verständnis.

Der sich aufgrund der Zunahme von HTTPS einstellende Blindflug (Google bietet mittlerweile sogar an Suchanfragen über HTTPS, also https://www.google.com, abzusetzen) hat ernstzunehmende Konsequenzen, da – wie in Abbildung 18 zu sehen – potenzielle Sicherheitslücken entstehen.

Verbotene File-Typen
Sie erinnern sich daran, dass eine Kommunikationsbeziehung immer bidirektional ist? Eine banale Erkenntnis, die nun aber die vollständige Tragik offenlegt. Selbst wenn ein Rechner im Internet aufgrund der Firewall-Regeln aus dem Internet heraus keine Kommunikationsbeziehung zu einem internen Rechner aufbauen darf, so dürfen aus den internen Netzen heraus in den meisten Fällen verschlüsselte Kommunikationsbeziehungen zu Rechnern im Internet hergestellt werden. Die Firewall schaltet dann bei diesen Verbindungen quasi auf „freie Fahrt” und kann nicht erkennen, dass über die verschlüsselte Verbindung z. B. schadhafte Software in Richtung internes Netz transferiert wird. Auch ein Transfer von eigentlich verbotenen File-Typen (z. B. PDF, DOCX) aus dem internen Netz in Richtung Internet ist ungesehen möglich. In der Konsequenz bedeutet dies, dass für verschlüsselte Verbindungen nicht die gleichen Sicherheitsanforderungen wie für nicht verschlüsselte Verbindungen durchgesetzt werden können und damit das Sicherheitsniveau allgemein reduziert wird.

Mangelnde Performance
Der folgende Vorfall soll Ihnen das verdeutlichen. Die Anwender beklagen eine mangelnde Performance beim Surfen im Internet. Für den Administrator ein erstaunliches Feedback, zumal dieses Problem quasi ad hoc aufgetreten ist und der Internetanschluss mit Blick auf die Bandbreite ausreichend dimensioniert sein sollte. Ein Blick auf die Statistiken der Firewall offenbart das Problem und enttarnt den ungebetenen Gast (s. Abbildung 19).

Malware
Das über die Mailkommunikation transferierte Datenvolumen ist ungewöhnlich hoch. Dieses Volumen wird von zwei Servern generiert: dem Exchange Server (Mailserver) und einem zweiten Server, der eigentlich keine Mails versenden sollte. Auf diesem Server wurde eine Malware installiert, die das Internet nach Mailadressen absucht und an diese dann Spam-Mails schickt. Die Nachforschung bestätigte, dass diese Malware über eine verschlüsselte Verbindung auf das Zielsystem übertragen wurde, denn die Firewall hätte den Transfer dieser Malware über eine unverschlüsselte Verbindung geblockt.

Fachkundigen Lesern ist sicher klar, dass hier mehrere Sicherheitsfunktionen versagt haben oder schlicht und ergreifend einfach nicht existierten.

Verschlüsselte Verbindungen können aufgebrochen werden
Es ist technisch möglich, dass verschlüsselte Verbindungen von der Firewall (oder einem Proxy) aufgebrochen werden können und somit wieder der Inhalt der einzelnen Datencontainer analysiert werden kann. Diese Lösung soll aber technisch nicht weiter vertieft werden. Der Autor möchte Ihnen zu diesem Thema lediglich die folgenden Anmerkungen mit auf den Weg geben:

Verständnis für Problematik schärfen
Um das Verständnis für die Problematik weiter zu schärfen und um noch einmal aufzuzeigen, dass Sicherheit nicht ausschließlich eine Frage der eingesetzten technischen Maßnahmen ist, sollten Sie überlegen, wie Sie mit der folgenden Anforderung umgehen würden:

Ein Mitarbeiter hat von seinem Rechner über das Netzwerk Zugriff auf sensible Daten. Gleichzeitig benötigt er einen Zugriff auf das Internet, da er im Rahmen seiner Arbeitsaufgabe auch auf Informationen aus dem Netz angewiesen ist. Es ist davon auszugehen, dass der Zugriff in das Internet nicht ausschließlich nur über HTTP, sondern auch über HTTPS erfolgt und damit natürlich potenziell die Gefahr besteht, dass der Rechner des Mitarbeiters durch z. B. Malware infiziert wird.

Mobilität stellt vor neue Herausforderungen
Die in der Vergangenheit zunehmend gewünschte und auch erforderliche Mobilität der Anwender stellt die klassische Absicherung des Perimeters durch den Einsatz von Firewall-Systemen ebenfalls vor neue Herausforderungen. Hierzu ein einfaches Beispiel: Ein Anwender überbrückt die Wartezeit am Flughafen und aktualisiert in einem CRM-System den Datensatz seines Kunden. Das Unternehmen bezieht die CRM-Lösung über eine externe Cloud, d. h., sie wird als Software-as-a-Service(SaaS)-Produkt über das Internet genutzt.

Software-as-a-Service (SaaS)
In unserem einfachen Beispiel spielt die Perimeter-Firewall des Unternehmens keine Rolle, da sie nicht in den Kommunikationsfluss eingebunden ist. Wir wollen dieses Thema und mögliche Lösungen hier nicht weiter vertiefen. Die kurze Vorstellung soll lediglich aufzeigen, dass aufgrund von neuen Anforderungen die Netzgrenzen in der Definition des klassischen Perimeters heute nicht mehr existieren. Wir konsumieren nicht nur Anwendungen, die innerhalb unseres Unternehmens zur Verfügung gestellt werden, sondern auch Anwendungen in der Cloud. Wenn wir beim Zugriff auf diese externen Anwendungen nicht mit dem Netzwerk unseres Unternehmens verbunden sind, dann bieten uns die traditionellen Grenzmauern unserer Festung keinen Schutz mehr.

Firewall als virtuelle Maschine
Durch die zunehmende Konsolidierung von Anwendungen und Diensten in einem Rechenzentrum werden auch die Kommunikationsströme in Richtung eines Rechenzentrums konsolidiert, sodass die Absicherung der netzseitigen Übergänge in das Rechenzentrum über Firewalls nicht unberücksichtigt bleiben darf. Abgesehen davon, dass sich hier aufgrund der Virtualisierung auch dedizierte Anforderungen ableiten (z. B. Firewalls als virtuelle Maschine), sind die an diesen Übergängen eingesetzten Firewalls mit Blick auf die angebotenen Security Features nicht unbedingt von den an anderen Grenzübergängen eingesetzten Systemen zu unterscheiden. Allerdings stehen bei der Planung dieser Systeme z. B. die Themen Verfügbarkeit und Durchsatz oft wesentlich stärker im Fokus als bei Systemen, die nicht für den Einsatz in einem Rechenzentrum vorgesehen sind. Diese Firewall-Systeme können dann auch sehr schnell zu einer finanziellen Herausforderung werden.

Eine Firewall kann prinzipiell zunächst nicht wissen, welche Anwender auf welche Dienste und Anwendungen zugreifen. Das ist darauf zurückzuführen, dass die Datencontainer als Information zu ihrer Quelle die IP-Adresse des sendenden Systems, aber nicht den Namen des jeweiligen Anwenders enthalten, der mit diesem System (Desktop-PC, Laptop etc.) arbeitet. Zudem können sich die IP-Adressen dieser Systeme ändern, sodass kein belastbarer Zusammenhang zwischen dem Namen des Anwenders und der Absenderadresse in den Datencontainern gegeben sein muss.

Kritisches Informationsdefizit?
Ob dieses Informationsdefizit kritisch ist, hängt von den Anforderungen ab. Gehen die Verbindungen von autark arbeitenden Maschinen (z. B. Monitor) aus, dann existiert in diesem Fall kein klassischer Anwender. Werden dagegen die Verbindungen der Arbeitsplatzrechner in Richtung Internet über die Firewall geführt, dann kann der Zusammenhang zwischen IP-Adresse und Benutzername durchaus interessant sein. Damit ist es dann z. B. möglich, eine Regel zu schreiben, die dem Auszubildenden Pfeiffer den Aufruf von fragwürdigen Webseiten verbietet. Das ist mit Blick auf die Verantwortung, die Sie gegenüber den Auszubildenden haben, keine uninteressante technische Maßnahme, da sich Pfeiffer bekanntlich nicht an formale Spielregeln hält.

Applications und URLs
Die Abbildung 20 zeigt eine entsprechende Firewall-Regel. Sie können nicht sehen, welche Anwendungen Hans Pfeiffer nicht verwenden darf oder welche Webseiten er nicht aufrufen kann. Diese Einstellungen verbergen sich in den Registerkarten Applications und URLs. Es ist aber zu sehen, dass diese Regel für Hans Pfeiffer geschrieben wurde. In der Praxis ist es allerdings eher unüblich, dass personenbezogene Firewall-Regeln existieren. In unserem Beispiel würde man die Gruppe Auszubildende wählen, der Hans Pfeiffer zugehörig ist.

Wenn die Datencontainer (IP-Pakete) aber IP-Adressen und keine Namen enthalten, woher weiß die Firewall dann, dass ein Datencontainer von einem Rechner auf die Reise geschickt wurde, an dem Hans Pfeiffer angemeldet ist? Da die technischen Details an dieser Stelle wieder einmal nicht zielführend sind, beschränken wir uns auf eine einfache Erklärung: Die Firewall fragt ein zentrales Verzeichnis (z. B. ein Microsoft Active Directory), welche Anwender aktuell an den Rechnern im Netz angemeldet sind, und erfährt darüber auch die aktuelle IP-Adresse dieser Rechner. Über den Namen des Anwenders kann sich die Firewall auch über selbiges Directory Auskunft darüber geben lassen, welcher Gruppe ein Anwender zugehörig ist.

Uniform Resource Locator (URL)
Das Thema URL Filtering (URL: Uniform Resource Locator) ist sicherlich leichte technische Kost. Die Firewall prüft hier die von den Anwendern aufgerufenen Webseiten. Verstößt der Aufruf einer Webseite gegen die Vorgaben, dann wird er unterbunden und der Anwender erhält in der Regel eine entsprechende Information. Die einzelnen Webseiten werden von den Herstellern mithilfe von Kategorien (s. Abbildung 21 z. B. Business and Economy) klassifiziert, wobei eine bestimmte Kategorie (und damit alle Webseiten dieser Kategorie) oder auch individuelle Webseiten durch die Firewall für einen Zugriff gesperrt werden können. URL Filtering wird allerdings nicht nur von Firewall-Systemen angeboten. Vielmehr ist dies auch eine Kernfunktion der Web-Proxies.

Die Abbildung 22 ist ein Beispiel für eine Meldung, die ein Anwender beim Aufruf einer Seite erhält, wenn der Aufruf dieser Seite verboten ist und von der Firewall blockiert wird.

Cloud-Unterstützung
Sie können sich sicherlich vorstellen, dass es kaum möglich ist, alle Webseiten im Internet zu klassifizieren, zumal täglich neue Webseiten hinzukommen. Unabhängig von dieser Erkenntnis ist sicherlich auch klar, dass die Datenbank mit allen klassifizierten Webseiten extrem groß sein muss. Das führt dazu, dass die Firewall-Systeme oft z. B. durch die Cloud des Herstellers unterstützt werden. Das heißt, sobald die Firewall eine Webseite nicht über ihre lokale Datenbank klassifizieren kann, fragt sie im externen Rechenzentrum (in der Cloud) nach, ob diese Webseite bekannt und welcher Kategorie sie zugehörig ist. Die lokale Datenbank enthält in der Regel immer nur einen Auszug der Datenbank im Rechenzentrum. Sollte die Kategorie letztendlich nicht ermittelt werden können, so ist im Regelwerk eine Regel vorzusehen, die festlegt, was beim Aufruf von unbekannten Webseiten passieren soll.

URL-Filter
Wie auch schon die Ermittlung des Namens und der Gruppenzugehörigkeit eines Anwenders, so ist auch ein URL-Filter keine Funktion, die zur Kontrolle aller Verbindungen erforderlich ist, die über eine Firewall führen. So spielen solche Filter sicherlich eine große Rolle, wenn die Kommunikation der Anwender in Richtung Internet gewissen Vorgaben unterstellt werden soll. Dahingegen spielen sie z. B. am Übergang zwischen dem Leitstand und den im Netzwerk verteilten Komponenten der Gebäudesteuerung und der Gebäudeautomation eine – wenn überhaupt – untergeordnete Rolle.

Anomalien
Ein Intrusion Detection System (IDS) bzw. Intrusion Prevention System (IPS) überprüft die einzelnen Datencontainer auf Anomalien (d. h. Abweichungen vom üblichen Inhalt) und kann auch Unstimmigkeiten in der Kommunikation selbst – über mehrere zwischen Absender und Empfänger ausgetauschte Datencontainer hinweg – erkennen. Der Unterschied zwischen IDS und IPS ist wie folgt definiert:

Für einen Netzwerklaien ist, vor dem Kontext von Datencontainern, der Begriff Anomalie sicherlich schwer zu verstehen. Zwei einfache Beispiele unterschiedlicher Qualität sollen hier helfen eine Brücke zu bauen.

Signaturen
Der Autor möchte Ihnen nicht die Illusion nehmen, dass Sie das Thema damit vollständig verstanden haben, aber heutige Angriffe sind oft weitaus komplexer. Um Angriffsmuster zu erkennen, werden sogenannte Signaturen eingesetzt. Diese werden vom Hersteller bereitgestellt und ständig aktualisiert und erweitert. Heutige IDS/IPS-Systeme verfügen über mehrere Tausend Signaturen, was durchaus einen Beitrag zur der mit diesen Systemen einhergehenden Komplexität leistet. Insbesondere dann, wenn man solche Signaturen auch selbst schreibt.

False Positive
Eine große Herausforderung beim Thema IDS/IPS ist die Anpassung des Systems an die jeweilige Einsatzumgebung. In unserem obigen Beispiel kann es ja sein, dass ein Managementsystem in kurzen Abständen prüft, ob die von ihm verwalteten Komponenten noch erreichbar sind. Ein IDS/IPS-System kennt solche Zusammenhänge nicht und generiert deshalb eventuell einen Alarm. Da dieser vor dem beschriebenen Kontext aber kein wichtiges Ereignis meldet, wird die entsprechende Meldung als False Positive klassifiziert. Generiert ein IDS/IPS-System eine hohe Anzahl an solchen False-Positiv-Meldungen, dann leitet sich daraus ein sehr hoher Aufwand ab, denn prinzipiell muss jede Meldung analysiert werden. In der Praxis führt das dazu, dass IDS/IPS-Systeme in vielen Fällen nicht in einen Incident-Management Prozess eingebunden sind (zu viele nervende Alarme) oder ein Unternehmen dieses Thema im Rahmen der möglichen Sicherheitsmaßnahmen nicht berücksichtigt.

Angriff erschweren
Moderne IDS/IPS-Systeme können bei der Anpassung an die jeweilige Umgebung behilflich sein. Das heißt, sie lernen automatisch die Betriebssysteme der einzelnen Systeme im Netz, sowie auch die von diesen Systemen angebotenen Dienste und können auch Informationen zu Patch und Release Ständen manuell oder automatisch zugeführt bekommen. Mithilfe dieser Informationen können IDS/IPS-Systeme eigenständig entscheiden, ob ein erkanntes Angriffsmuster wirklich einen Alarm von hoher Priorität auslösen muss. Das heißt, das System kann den Angriff vor dem Kontext der zum angegriffenen System gesammelten Informationen bewerten. So kann z. B. ein Angriffsmuster für einen Microsoft Webserver erkannt werden. Der Angriff ist real und muss deshalb gemeldet werden. Die Meldung muss aber keine sehr hohe Priorität haben, wenn es sich bei den angegriffenen Systemen um Webserver auf der Basis von Linux handelt.

Aufbau Signatur
Was versteht man nun aber unter einer Signatur? Eine Signatur ist eine Regel, die eine ganz bestimmte Zeichenfolge in einem Datenstrom sucht, auf ganz bestimmte Steuerbefehle achtet oder bestimmte IP-Adressen berücksichtigt. Letztlich kann eine Signatur auch aus einer Kombination von solchen Kriterien bestehen. Der Autor möchte bewusst auf weitere Details zum Thema Signaturen verzichten. Wenn es ein interessierter Leser aber auf den Punkt gebracht haben möchte, dann kann er sich in Abbildung 23 den Aufbau einer einfachen Signatur anschauen.

Eindeutige Kennung
Jede Signatur hat eine eindeutige Kennung (ID: Identification). Im Bild ist die Signatur mit der Kennung 4060 zu sehen. Das für diesen Screenshot verwendete IDS/IPS-System verwendet Regeln auf der Basis der Snort Syntax. Snort ist eine weit verbreitete Open-Source-IPS-Lösung (www.snort.org). Die Snort-Regel mit der SID (SID: Snort ID 4060) sucht in einem Datencontainer die nachfolgenden Informationen. Sind diese enthalten, dann generiert die Regel einen Alarm.

Mehrwert generieren
Prinzipiell ist der Schutz durch ein IDS/IPS-Regelwerk nicht so situationsgebunden wie z. B. ein URL-Filter. Selbst wenn die Firewall die Kommunikation von Systemen untereinander überwacht, die aus Sicht des Betreibers zu einer geschlossenen Systemlösung gehören (z. B. eine Patientenmonitoring-Lösung), kann eine solche Sicherheitsmaßnahme Mehrwerte generieren. Wird z. B. ein System innerhalb dieser Lösung mit Malware infiziert – erst einmal ungeachtet der Frage, wie das passieren kann –, dann wird dies eventuell (es gibt natürlich keine Garantie) erkannt. Abhängig von der Kritikalität der betrachteten Lösung ist eine daraus resultierende Unterbindung der Kommunikation eventuell nicht erwünscht, da letztendlich False-Positive-Ereignisse nicht ausgeschlossen werden können. Insofern wird die Firewall in diesem Fall so konfiguriert, dass nur Alarme generiert werden.

Komplexe Lösungen
Letztlich ist anzumerken, dass IDS/IPS-Lösungen komplexe Lösungen sind, die betriebsseitig eine entsprechende Aufmerksamkeit benötigen. Das heißt, die Systeme müssen in agilen Umgebungen ständig an veränderte Anforderungen (z. B. den Einsatz einer neuen Anwendung, auf den Systemen eingespielte Updates etc.) angepasst werden. Dies ist leider nicht völlig automatisiert möglich. Lässt die erforderliche Aufmerksamkeit und Pflege nach, dann ist der Mehrwert der Alarmierung durch ein IDS/IPS-System durchaus infrage zu stellen. Dies gilt auch dann, wenn kein festgelegter Incident-Management und Eskalationsprozess existiert, bzw. dieser darin besteht, dass der Firewall-Administrator (der nicht zwingend auch das Know-how eines Security-Analysten hat) jeden Freitagnachmittag den z. B. in einer Mailbox aufgelaufenen Alarmen seine in Sekunden zu beziffernde Aufmerksamkeit widmet und dann die selbst definierte Handlungsanweisung „Markieren und Löschen” ausführt.

Advanced Persistent Threats
Malware – d. h. schadhafte Software – ist ein heute sehr aktuelles Thema, da diese in der Regel sehr kleinen Programme im Rahmen der Cyberkriminalität oft die Aktivitäten einleiten, die dem Angreifer zu einem meist dauerhaft unbemerkten Zugang zu den Daten eines Unternehmens verhelfen. In der Praxis spricht man in solchen Fällen von Advanced Persistent Threats. Aber selbst wenn weniger professionell programmierte und weniger gezielt eingesetzte Malware den Weg in ein Unternehmen findet, so kann dies unter Umständen zum Ausfall von Systemen führen oder einfach „nur” die Ressourcen der IT-Abteilung binden, da der Störenfried wieder von den Systemen entfernt werden muss. Insofern ist es nicht verwunderlich, dass eine Firewall auch mit Blick auf das Thema Malware Schutzmechanismen bieten muss. Denn letztlich kontrolliert die Firewall die Kommunikationen zwischen unterschiedlichen Bereichen und ist für eine zulässige Verbindung so natürlich auch eine Schleuse zwischen zwei Bereichen, die beide Kommunikationspartner im Rahmen einer bestehenden Verbindung für den Transport von Daten (d. h. auch Malware) nutzen können.

Security Cloud
Einige Hersteller von Firewall-Lösungen verzichten zugunsten von Performance und Durchsatz auf die lokale Überprüfung der über die Firewall transferierten Files auf Malware. Zudem geht man heute davon aus, dass die für eine intelligente Untersuchung erforderlichen Verfahren und Telemetrie-Daten nicht mehr lokal auf dem System vorgehalten werden können und die Malware-Analyse deshalb in eine von ihnen betriebene Security Cloud ausgelagert werden muss. Das heißt, die Firewall analysiert die über sie transferierten Files nicht selbst, sondern fragt die Security Cloud des Herstellers, ob es sich bei diesen Files um Malware handelt. Bei einem positiven Bescheid wird die Malware nicht ausgeliefert. Die Firewall muss die Files dafür nicht zwingend in die Cloud hochladen. Vielmehr wird eine einfache Anfrage an die Cloud geschickt, die lediglich eine eindeutige Identifizierung des Files, nicht aber das File selbst beinhalten muss. (Anmerkung: Hier unterscheiden sich allerdings die Lösungen der einzelnen Hersteller.) Die Cloud kann diese Frage – wenn ihre Datenbank das Thema Big Data und damit auch das Thema Suchanfragen professionell bedient – sehr schnell beantworten, sodass dieser Prozess keinen zu großen Einfluss auf den Durchsatz der Firewall hat.

Prozesse und Tool planen
Der Leser stellt sich sicherlich die Frage, was mit einem File passiert, wenn die Security Cloud das File noch nicht kennt und somit nicht sofort sagen kann, ob es sich bei diesem File um Malware oder nicht um Malware handelt? Da eine Firewall kein Speichersystem für Files ist, wird sie solche Files ausliefern. Zum Zeitpunkt zu dem sie eine (schnelle) Entscheidung treffen musste, konnte das File noch nicht als Malware klassifiziert werden. Es ist nicht auszuschließen, dass das entsprechende File nach der Zustellung irgendwann (Minuten, Stunden, Tage etc.) auch der Cloud bekannt ist und als Malware klassifiziert wird. Mit diesem Risiko muss man wohl leben. Vor einem professionellen Kontext bedeutet dies, dass man das Risiko der Zustellung von Malware berücksichtigen und die für diesen Fall notwendigen Prozesse und Tools planen muss.