Content: Blog

Dein Freund die Zone

← zurück zum Blog

Thomas Bader

Thomas Bader
04.11.2013

«Wer sichere Schritte tun will, muss sie langsam tun» sagte Göthe. IT-Verantwortliche sollten genau so handeln. Eine Firewall ist kein Werkzeug, dass schnell installiert und anschliessend sich selber überlassen wird. Ohne einen durchdachten Plan verkommt eine Firewall schnell zum Placebo. Je besser das Konzept, je höher der Nutzen. Insbesondere muss man das eigene Netz genau kennen, ja sich sogar in einen Angreifer hinein versetzen und Schwachstellen explizit suchen.

In einem Netz existieren explizite und implizite Abhängigkeiten zwischen Systemen und Personen. Ist ein Angreifer erst einmal auf ein System gelangt, kann er aufgrund von diesen Dependenzen weiter in das Netz hinein vordringen. Ein System ist immer abhängig vom Team, welches das System betreut, was eine organisatorische Abhängigkeit ergibt. Die auf einem System gespeicherten Informationen weisen eine bestimmte Schutzbedürftigkeit auf. Die Testdaten auf einem Entwicklungsrechner unterscheiden sich von Daten auf einem produktiven System, insbesondere wenn dort auch vertrauliche Kundendaten verarbeitet werden. Sehr kritisch wird es dann, wenn auf einen schlecht geschützten Entwicklungsrechner für Tests produktive Daten kopiert werden. Ein erfolgreicher Angriff kann in einem minimalen Schaden oder in einem kompletten Loss of Business enden. Um dem Rechnung zu tragen werden bei Firewalls unterschiedliche Zonen gebaut. Systeme werden damit voneinander separiert. Dies stellt sicher, dass keine unerwünschte Kommunikation stattfinden kann.

Um den Sinn einer Zonierung zu prüfen und kritisch zu hinterfragen hilft die Erfassung der möglichen Angriffsvektoren. Als Beispiel in diesem Artikel dient ein einfaches Netz, bestehend aus einer Internetanbindung, einem im Internet erreichbaren Webserver sowie einem Datenbankserver. Auf den ersten Blick fokussieren sich viele Administratoren auf die Angriffe vom Internet auf den Webserver. Denn dieser steht im Internet und ist damit möglichen Attacken ausgesetzt.

Zone1.jpg

Es bestehen daneben aber noch drei weitere Attackvektoren. So kann  auch der Datenbankserver vom Internet her angreifbar sein, selbst dann wenn er im Internet nicht bekannt ist. Mit den passenden Werkzeugen findet man auch Rechner, die nicht im DNS registriert sind. Es ist denkbar, dass dies bei den Firewall Regeln vergessen oder ein Flüchtigkeitsfehler gemacht wurde. Ebenso können sich der Web- und Datenbankserver gegenseitig angreifen. Dies tönt zwar erstmals abwegig, jedoch mussten schon viele Administratoren genau diese Erfahrung machen. Schafft es jemand auf den Webserver einzudringen, dann kann derjenige von dort aus weitere Angriffe starten. Wenn Firewall Regeln nur zwischen dem Internet und dem eigenen Netzwerk implementiert sind, macht man es einem Angreifer einfach: es wird der am schlechtesten gesicherte Server gesucht, idealerweise der welcher noch nicht alle Sicherheitsupdates eingespielt hat. Ist der Angreifer dann erstmals erfolgreich eingebrochen, lassen sich weitere Angriffe starten - was ziemlich bequem ist, dann schliesslich muss der Angreifer dann nicht mehr mit Firewall Regeln kämpfen.

Zone2.jpg

Vier Vektoren tönt zwar nach viel, es sind jedoch noch nicht alle. Es gibt noch einen fünften und sechsten Vektor. Die Server können auch Angriffe in Richtung Internet starten. Wenn ein Angreifer eingebrochen ist, kann dieser vom kompromittierten System auch Dritte angreifen. Zusätzlich wird seine Identität verschleiert, da er ein fremdes System und nicht sein eigenes nutzt. Ein weiteres Stichwort in dem Zusammenhang sind Botnetze. Ein Angreifer kann einen Trojaner auf dem Server platzieren, welcher sich dann autonom mit einem Command & Control Server im Internet verbindet. Dabei handelt es sich um einen spezialisierten Server, der von Betreibern von Botnetzen zur Verfügung gestellt wird. Die überall installierte Schadsoftware ist programmiert, auf diesen C&C Server zu verbinden und von diesem Befehle entgegen zu nehmen. So kann der C&C Server andere Rechner anweisen, z.B. neue Angriffe gegen Systeme von Dritten zu starten. Mit den richtigen Regeln in der Firewall kann so etwas unterbunden werden.

Zone3.jpg

Besonders interessant ist hierbei die rechtliche Fragestellung, die sich daraus ergibt. Wenn das eigene System kompromittiert ist und der Angreifer von diesem aus Angriffe startet könnte man im Prinzip mitverantwortlich sein und im Sinne einer Störerhaftung zum Mitstörer werden. Sind alle notwendigen Informationen erst einmal gesammelt, kann damit ein Konzept für die Zonen erstellt werden. Die nächste Grafik zeigt ein Beispiel: Die öffentlichen Server und die Datenbank werden explizit voneinander getrennt. Eingezeichnet sind weitere drei leere Zonen. Diese stehen als Platzhalter da; in der Praxis würde man eigenen Zonen bauen für:

-    Entwicklungsserver
-    Management-Netze
-    Storage-Netze
-    Büro-Netze
-    Wireless-Netze

Wichtig bei der Trennung ist zu berücksichtigen, dass Systeme mit unterschiedlichem Zweck und unterschiedlichen Nutzern nicht in derselben Zone stehen. Es macht keinen Sinn, Workstations zusammen mit Servern in der gleichen Zone zu betreiben. Auch ist es ungünstig, wenn man Systeme mit öffentlich genutzten Diensten in die gleiche Zone platziert in der auch interne Dienste betrieben werden.
So wird eine saubere Trennung von Diensten im Netzwerk erreicht. Angriffe auf das Netz werden erschwert und die Fehlertoleranz insgesamt steigt. Wer noch einen Schritt weiter gehen will installiert zusätzlich auf jedem System noch eine Host-Based Firewall und schottet das System damit zusätzlich ab. Wer den Aufwand nicht betreiben will, sollte wenigstens alle Management-Zugänge (z.B. SSH-Logins oder SNMP-Zugänge) mit einer Access Control List (ACL) schützen.

Zone4.jpg

Die Regeln einer Firewall können, wenn das Modell der Zonen eingesetzt wird, bequem in einer Matrix festgehalten werden:

Quelle/Ziel Internet öffentliche Server Datenbankserver
Internet - HTTP / HTTPS -
öffentliche Server DNS - MySQL
Datenbankserver - - -

Diese Beispielmatrix definiert:
-    vom Internet zu den öffentlichen Servern darf HTTP/HTTPS transportiert werden
-    die öffentlichen Server dürfen DNS ins Internet benutzen
      und MySQL-Verbindungen zu der Datenbank herstellen
-    alles andere ist nicht erlaubt

Ist die Planung und Implementation erst einmal geschafft, dann gilt es den Betrieb und Wartung der Firewall in die eigenen Prozesse zu integrieren, was nicht mehr Teil dieses Artikels ist.
Wichtig ist es, alle diese Schritt mit offenen Augen zu durchlaufen. Auch auf den ersten Blick abwegige Szenarien soll verfolgt werden. Ein Angreifer wird aufgrund seiner Kreativität erfolgreich. Einfach dem neusten Hype nach zu rennen wird alleine noch nichts helfen. Die Analyse und Risikoabschätzung zählt. Dabei muss man wertfrei denken, sich die eigenen Schwächen eingestehen, sie verbessern und daraus lernen. 

 


Checklisten

Inventar
- Abhängigkeiten zwischen Systemen
- Schutzbedürftigkeit der Daten
- öffentliche Dienste
- interne Dienste

Best Practices
- Server verschiedener Teams trennen
- Entwickler- und Produktionsgeräte trennen
- eingehend und ausgehend Filtern
- Systeme mit unterschiedlichem Zweck voneinander trennen
- Host-Based Firewalls installieren
- Zugriff auf Management-Interfaces gesperrt

Prozesse
- Software-Updates
- Change Management
- Dokumentation von Regeln
- Prüfung/Archivierung der Logdateien
- Backup der Konfiguration


Die «smart, kompetent und leidenschaftlich» - Services für Unternehmen