![[Inhalt]](../../Grundlagen/Firewall/images/toc.gif){kind=small}
|
|
Online Suche im Handbuch | LITTLE-IDIOT NETWORKING |
Ein Host, der gegen buffer overflows anfällig ist, benötigt keinen Schutz durch einen äußeren Router oder eine Firewall mehr. Ein Angreifer würde über den zugelassenen Port direkt Supervisorrechte auf dem Host erlangen.
I N T E R N E T
^
|
Router
|
| Transfernetz
| SERVER 1 SERVER 2
| WWW/FTP/DNS Mail/News
| WWW-PROXY |
Firewall | |
| | |
<---+--------+--------+-------------+------->lokales Netz
| | | |
Host A Host B Host C Host D
Beispiel 1
I N T E R N E T
^
|
|
MSQ-Router
| lokales Netz
<---+--------+--------+--------+------->
| | | |
Host A Host B Host C Host D
Beispiel 2
Betrachten wir einmal die Konfiguration in Beispiel 1. Das Netz besitzt feste, vom Provider zugewiesene IP - Nummern. Die Firewall arbeitet selber nicht als ISDN-Router, ist aber über ein Transfernetz (192.168.x.x) mit dem Router verbunden. Die Hosts A-D sind Arbeitsplatzrechner, die über den WWW-PROXY von Server 1 Zugang zum Internet besitzen. Die Firewall schirmt einige Ports des Server 1 ab, erlaubt aber Zugriffe auf den WWW-Server über Port 80 (HTTP) und Port 21 (FTP) aus dem Internet. Server 2 ist ein "store and forward" PROXY, der als interner DNS-Server, Mail-Server und NEWS-Server arbeitet. Die Firewall erlaubt keinen Zugriff auf Server 2 aus dem Internet. Ein Security Check mit SATAN oder SAINT aus dem Internet zeigt keine Probleme, alle Filterregeln sind korrekt eingestellt.
Um es vorweg zu nehmen - Ein Angreifer wäre in wenigen Minuten in das Netzwerk vorgedrungen. Wo liegen die Probleme ?
Problem 1
Der Angreifer sieht von außen nur folgende Ports: 25, 21, 53 und 3128 von Server 1, Server 2 sei abgeschirmt.
Der Angreifer ist dadurch, daß er direkten Zugriff auf die Ports der internen Server hat, in der Lage, das Betriebssystem des Servers genau zu bestimmen.
Über e-Mails aus dem Netz (kleine Anfrage) würde er genau wissen, ob eventuell das Netz mit Masquerading oder NAT aufgebaut ist. Er kennt dann genau das e-Mail Gateway (Server 2) und kann anhand der Headerinformationen das verwendete Betriebssystem genau identifizieren.
Nun sucht er in den einschlägigen Archiven nach "exploits", die von innen oder von außen her einen buffer overflow initiieren.
Angenommen, Server 1 hätte ein solches Problem. Es werden immer neue bekannt, im Prinzip muß der Angreifer nur warten. Dann wäre Server 1 im Netzwerk verloren. Der Angreifer könnte alle Dienste mit Supervisor Rechten starten. Da die Firewalls offene Ports hat, kann der Angreifer weitere Programme, die er benötigt, von Server 1 aus dem Internet downloaden. Dies könnten z.B. Netzwerksniffer sein, der ihm dann die Paßworte zu allen Servern im Netzwerk und jeden Zugriff auf alle Server im Netz ermöglichen würde. Die Firewall selber interessiert den Angreifer nicht, da er nach eigenem Belieben Tunnel über die offenen Ports aufbauen kann.
Problem 2
Angenommen, er würde auf die Schnelle keinen exploit finden. In diesem Falle kann er irgendeinem User ein trojanisches Pferd via e-Mail senden, und darauf warten, daß dieser es installiert. Da er den Namen des e-Mail Gateways kennt, kann er mit diesem ein Gateway in das Internet aufbauen, sofern die Firewall die Funktion "transparent proxy" aktiviert hat. Verschiedene Proxy-Module der Firewall erleichtern dem Angreifer den Aufbau eines Tunnels von einem Arbeitsplatz aus zu einem Server im Internet.
Problem 3
Es ist ein Split-DNS - Server aufgebaut, der eventuell ein Problem mit "additional informations" haben könnte. Ein eingeschleustes, trojanisches Pferd könnte den MX - Eintrag des internen DNS-Servers auf eine IP - Nummer im Internet umändern. Die Folge wäre, daß der Angreifer sämtliche internen und externen e-Mail aus dem Netzwerk erhalten würde, die er kopieren, und in das Netzwerk zurücksenden könnte.
Problem 4
Er nutzt die typischen Fehler der Browser auf den Arbeitsstationen (Host A-D) aus. Ein vorbereitetes, auf die internen IP - Nummern angepaßtes Active-X Applet könnte somit beliebige Angriffe auf Server intern starten. Er muß hierzu nur die Aufmerksamkeit eines Users im Intranet auf einen beliebigen Internet-Server lenken, damit dieser das Applet auf seine Arbeitsstation lädt und es startet.
Problem 5
Eine UNIX - Firewall könnte er versuchen, direkt von innen her mit einem buffer overflow anzugreifen, in der Hoffnung, daß diese einige wohlbekannten Ports nach innen hin geöffnet hat.
Problem 6
Hat er auch nur ein einziges mal die Firewall überwunden, so kann er trojanische Pferde installieren, später von alleine aktiv werden. Wir der Angriff entdeckt und das Sicherheitsproblem beseitigt, so wird wohl kaum der Systemadministrator alle Server im Intranet neu installieren. Finden würde er ein trojanisches Pferd wohl nicht.
Betrachten wir nun Beispiel 2
Diese leidet genauso wie Beispiel 1 unter allen dort schon erwähnten Problemen.
Es gibt einige Regeln, die man unter keinen Umständen mißachten sollte:
Zu einer Firewall gehören immer 3 Komponenten, einem äußeren Router, einem inneren Router und der Firewall selber. Soll ein Zugriff auf einen Server im Intranet aus dem Internet heraus möglich sein, so ist eine DMZ "DeMilitarisierte Zone" aufzubauen, die selber von Firewalls umgeben ist. In dieser sind die Server, die von außen erreichbar sein sollen, zu installieren. Der Grund besteht darin, daß man stets damit rechnen muß, daß ein von außen erreichbarer Server mit buffer overflows angreifbar ist. In diesem Falle muß unter allen Umständen noch einen Firewall als Sicherung gegen Zugriffe aus der DMZ auf das interne Netzwerk. Der korrekte Aufbau wäre also folgender:
I N T E R N E T
^
|
Router
|
| Transfernetz
| SERVER 1 SERVER 2
| WWW/FTP/DNS Mail/News
| WWW-PROXY |
Firewall 1 | |
| | |
<---+--------+--------+-------------+---- Firewall 2 --->lokales Netz
Beispiel 3
Für den Fall, daß Server 1 erfolgreich angegriffen wird, muß Firewall 2 Angriffen standhalten können. Firewall 1 und der Router bieten dann im Prinzip keinen Schutz gegen professionelle Angreifer mehr, halten aber viele DoS Angriffe und weniger erfahrene Angreifer fern. Sie dienen im Prinzip nur dazu, die Verfügbarkeit der Server zu erhöhen. Im Gegensatz zu früheren Empfehlungen (Einrichten von Firewalls Chapman/Zwicky) sollten die Firewalls mindestens Statful Paket Filter (SPF Firewalls) sein und über verschlüsselte Protokolle zur Fernwartung und Analyse der Logfiles verfügen.
Die Überwachung von Firewall 1 und der Server 1+2 in der DMZ stellt allerdings ein Problem dar, dessen Lösung nicht ganz trivial ist. Logserver sind ebenfalls anfällig gegen buffer overflows und können von Angreifern stillgelegt werden. (DoS attack) Es darf unter keinen Umständen Firewall 2 für die kontinuierliche Übertragung von Logfiles auf einen Logserver im lokalen Netz geöffnet werden. Es bietet sich an, den WWW-Server in der DMZ als Logserver für Router und Firewall 1 einzusetzen. Mit FTP z.B. könnte eine Arbeitsstation die puren ASCII Logfiles von Router und Firewall 1 herunterladen und auswerten. Besser ist jedoch ein eigener Server in der DMZ, der nur eine Aufgabe hat, nämlich die Logfiles zu speichern. Da auf diesem alle weiteren Funktionen deaktiviert sind, ist dieser höchstwahrscheinlich nicht anfällig gegen buffer overflows, weil er viel weniger Angriffspotential bietet. Ein Auswertungsprogramm könnte aber so geringe Differenzen zwischen den Logfiles von Router, Server 1 und dem Logserver sofort bemerken. Es ist höchst unwahrscheinlich, daß ein Angreifer zur gleichen Zeit beide Logserver angreifen kann.
|
|
Online Suche im Handbuch | LITTLE-IDIOT NETWORKING |