Abnahmetests. Vorarbeiten KAPITEL 15. Testaufbau

Transkript

1 firewall 2006/1/4 15:26 page KAPITEL 15 Abnahmetests Bevor wir nun unseren Rechner an das Internet anschließen, sollten wir uns vergewissern, daß alles so funtioniert, wie wir uns das vorstellen. Dazu müssen wir zum einen überprüfen, ob die gewünschten Zugriffe möglich sind. So gilt es zum Beispiel festzustellen, ob die Benutzer in unserem loalen Netz Server im Internet mit allen vorgesehenen Protoollen erreichen önnen (z. B. HTTP, FTP, ... ). Betreiben wir zusätzlich Server in einer DMZ, so muß auch sichergestellt sein, daß diese aus dem Internet zu erreichen sind. Andererseits müssen wir aber auch überprüfen, ob unser System»sicher«ist. Dies geschieht, indem wir definieren, welche Klassen von Zugriffen zulässig sind und welche nicht. Dann wählen wir Beispiele für unerlaubte Zugriffe, die wir in Tests nachstellen und anhand dere wir überprüfen, ob die Firewall sie verhindert. Auf diese Weise önnen wir zwar immer noch nicht beweisen, daß unsere Firewall absolut sicher ist, wir önnen aber zumindest überprüfen, ob unsere Regeln die von uns gewünschten Funtionen erfüllen. Vorarbeiten Bevor wir mit den Tests beginnen önnen, müssen wir aber erst einmal ein paar Dinge vorbereiten. Wir benötigen ein Testnetz und mehrere Rechner, welche die Kommuniationsteilnehmer simulieren. Im folgenden wird es daher erst einmal darum gehen, wie man mit vertretbarem Aufwand eine Testumgebung aufbaut. Testaufbau Für unsere Tests brauchen wir mindestens drei Rechner. Da ist zum einen die Firewall selbst. Sie verbindet die Testnetze, die für die Dauer der Tests das Internet, das loale Netz und gegebenenfalls die DMZ simulieren. Diese Netze sollten während der Tests nicht mit dem normalen loalen Netz oder dem Internet verbunden sein, um Nebeneffete für oder durch unbeteiligte Rechner zu vermeiden. 441

2 firewall 2006/1/4 15:26 page Als zweites benötigen wir für die Funtionstests einen Klienten, wie er später in unserem loalen Netz stehen wird oder wie er von den Besuchern unseres Webservers aus dem Internet eingesetzt wird. In den Sicherheitstests dient dieser Rechner dann als Angreifer, der versucht, unsere Firewall zu überwinden. Als drittes fehlt uns noch ein Rechner, der als Server aufgesetzt ist. Er wird nicht nur für die Funtionstests benötigt, sondern dient auch als Angriffsziel für unsere Sicherheitstests (siehe Abbildung 15-1). Abbildung 15-1: Versuchsaufbau für die Abnahmetests Der Server befindet sich während der Funtionstests im»internet«, während er bei den Sicherheitstests im»loalen Netz«untergebracht ist. Betreiben wir auch eine DMZ, so benötigen wir dort sowohl einen Server als auch einen Klienten. Jeder Server, den wir dort betreiben, önnte ompromittiert und dann für Angriffe genutzt werden. Wir müssen also sowohl Angriffe aus dem Internet in die DMZ als auch aus der DMZ in das loale Netz simulieren. Am bequemsten erreichen wir unser Ziel, wenn in jedem Teilnetz ein Rechner aufgebaut ist, der sowohl als Server wie auch als Klient/Angreifer dienen ann. Wenn dies nicht pratiabel ist, dann werden Sie nicht umhinommen, die einzelnen Rechner zwischen den Netzen wandern zu lassen. Vergessen Sie dann aber nicht, jeweils die Netzweronfiguration nach jedem Wechsel anzupassen. Ansonsten werden Sie sich wundern, daß Ihre Firewall so effetiv ist, daß überhaupt eine Paete mehr durchommen. Simulation einer Einwahl Wenn wir über ein Modem oder eine ISDN-Karte an das Internet angeschlossen sind, haben wir ein Problem. Eigentlich müßten wir dann auch im Server ein Modem oder eine ISDN-Karte einbauen und beide über eine Telefonanlage verbinden. Wenn man aber nicht regelmäßig Firewalls aufsetzt, önnte der damit verbundene Aufwand und die Gefahr, neue Fehlerquellen in das System einzuführen, den zu erwartenden Nutzen überwiegen. Aus diesem Grund bietet es sich an, für den Test statt einer ISDN-Karte oder eines Modems eine weitere Netzwerarte einzubauen. Nachdem die nötigen Treiber onfiguriert wurden, müssen wir nur 442 Kapitel 15: Abnahmetests

3 firewall 2006/1/4 15:26 page die Paetfilterregeln anpassen, da sie einen Hinweis auf den Namen und die IP- Adresse des externen Interfaces enthalten. In den Beispielsripten haben wir aber darauf geachtet, daß diese Werte in den Variablen acbedgfih und a bedgfij eingetragen wurden, wodurch sie nur zentral an einer Stelle geändert zu werden brauchen. den pppd oder ipppd daran hindern zu starten. Insbesondere darf die Default-Route während der Tests nicht auf /dev/(i)ppp0 zeigen. Wir önnen dies erreichen, indem wir die Lins auf die Runlevel-Sripte dieser Dienste während der Tests entfernen. das externe Interface initialisieren und die Default-Route darauf zeigen lassen. ggf. /etc/ppp/ip-up starten, wenn wir dort Firewallregeln eingetragen haben. Dieses muß als 4. Parameter die Adresse unseres externen Interfaces übergeben beommen. Die letzten beiden Punte önnen wir relativ einfach mit einem leinen Sript erledigen, das z. B. während der Tests manuell oder als Runlevel-Sript gestartet werden ann:!/bin/sh siminternet Dieses Sript setzt die Default-Route, onfiguriert das externe Interface und startet /etc/ppp/ip-up Usage: siminternet {start stop} Copyright (C) 2003 Andreas G. Lessig Lizenz: GPL v2 oder höhere Version Externes Netzwer-Interface EXTIF=eth1 Externe IP-Adresse EXTIP= Die Netzwermase des externen Interfaces EXTMASK= Adresse des "Servers" GWIP= case $1 in start) echo "$EXTIF" is now our modem... /sbin/ifconfig "$EXTIF" "$EXTIP" netmas "$EXTMASK" up /sbin/route add default gw "$GWIP" /etc/ppp/ip-up "$EXTIF" /dev/null "$EXTIP" "$GWIP" ;; stop) echo Our virtual modem "$EXTIF" just hung up... /sbin/route del default gw "$GWIP" /etc/ppp/ip-down "$EXTIF" /dev/null "$EXTIP" "$GWIP" /sbin/ifconfig "$EXTIF" down ;; Vorarbeiten 443

4 firewall 2006/1/4 15:26 page *) esac echo Usage: siminternet {start stop} ;; Die Konfiguration der Testrechner Die Firewall sollte jetzt fertig onfiguriert sein. Nun gilt es noch, die Testrechner aufzusetzen. Idealerweise handelt es sich dabei um Rechner, auf denen eine Linux-Standarddistribution installiert wurde. Für den Einsatz als Testserver sollten dabei so viele Netzwerdienste wie möglich installiert sein. Zumindest ein Web-, ein FTP- und ein DNS-Server sollten ativ sein, wobei letzterer Einträge für die Firewall, den Server im»internet«und gegebenenfalls den Server in der»dmz«enthalten sollte. Es ist auch zu überlegen, ob für einen Teil der Funtionstests der DMZ ein Rechner herangezogen wird, der bereits so aufgesetzt ist wie der später verwendete Server. Dieser ann allerdings nur verwendet werden, um zu testen, wie gut der Zugriff aus Internet und loalem Netz in die DMZ funtioniert. Wenn Sie den Zugriff aus dem loalen Netz in das Internet überprüfen wollen, werden Sie wahrscheinlich auch Server für Protoolle benötigen, die Sie später nicht in Ihrer DMZ anbieten wollen. Ein Testlient benötigt in erster Linie Klientensoftware für alle Protoolle, mit denen Sie später aus dem loalen Netz auf das Internet zugreifen wollen. Dies gilt insbesondere für die Funtionstests. Für die Angriffstests benötigen Sie zusätzlich die Software Nmap (siehe Kapitel 15, Unterabschnitt Grundlagen, ab Seite 446). Darüber hinaus sollte auf jedem Testrechner das Program Netcat (siehe Kapitel 15, Abschnitt Funtionstests, ab Seite 444) installiert sein. Funtionstests Nun önnen wir beginnen zu testen, ob Verbindungen aus dem»loalen Netz«zu unserem Testserver im»internet«funtionieren. Für Protoolle, die von unserem Server nicht diret unterstützt werden, ann man sich oft damit behelfen, mit dem Programm Netcat auf einem bestimmten Port auf eingehende Verbindungen zu warten. Netcat ist in einigen Distributionen enthalten. Zusätzlich ann es aber auch von heruntergeladen werden, wo auch eine Version für Windows-Rechner zu finden ist. Es ist eigentlich ein universeller Netzwerlient, der ähnliche Funtionen wie das Programm telnet realisiert. Darüber hinaus ann Netcat aber auch: auf einem Port auf eingehende Verbindungen warten, UDP-Paete senden und empfangen, Paete gezielt von einer speziellen Quelladresse senden und einfache Port Scans durchführen. 444 Kapitel 15: Abnahmetests

5 firewall 2006/1/4 15:26 page Dies macht es zu einem universellen Werzeug, das man wie ein Schweizer Taschenmesser einsetzen ann, wenn das eigentlich benötigte Spezialwerzeug nicht zur Hand ist. Eine Übersicht über die Optionen, welche Netcat versteht, erhält man mit dem Aufruf > nc -h Wenn Sie SuSE-Linux einsetzen, so müssen Sie netcat statt nc benutzen. Das Programm wurde dort umbenannt. Es handelt sich aber um die gleiche Software. Um zum Beispiel zu testen, ob eine Verbindung zu externen Newsservern möglich ist, ann man Netcat auf dem»server«auf Port 119 auf Verbindungen warten lassen: nc -l -p 119 -v listening on [any] Hierbei bewirt -l, daß eine Verbindung geöffnet, sondern vielmehr auf eingehende Verbindungen gewartet wird. Das -p Port gibt den von Netcat zu verwendenden Port an, und das -v sorgt dafür, daß zusätzliche Angaben zu den Verbindungen gemacht werden. Verbindet sich nun der»klient«mit unserem»gefälschten«newsserver, so erhalten wir eine Meldung der Art: connect to [ ] from fw [ ] 1082 Hierbei sollten wir darauf achten, daß die angegebene Quelladresse immer die Adresse der Firewall ist. Taucht hier die Adresse des Klienten auf, so funtioniert das Masquerading nicht. Einige Protoolle, darunter auch NNTP, erwarten nach der Verbindungsaufnahme erst einmal eine Statusmeldung des Servers in Form einer Zahl. 200 bedeutet dabei oft»o.k.«: 200 MODE READER Offensichtlich hat diese nappe Antwort unserem Klienten gereicht, er antwortet nun»mode READER«. Wir önnten nun damit beginnen, manuell einen Newsserver zu emulieren, dies würde uns aber nicht weiterbringen. Statt dessen beenden wir Netcat durch Betätigen von <Ctrl><C>. Wenn wir zusätzlich noch eine DMZ betreiben, so müssen wir neben Verbindungen aus dem»loalen Netz«in das Internet auch noch Verbindungen aus dem Internet in die DMZ testen. Idealerweise dient dabei ein Rechner als Testserver, der schon so aufgesetzt ist, wie es unser späterer DMZ-Server sein wird. Es bietet sich dabei an, Netzwerlienten verschiedener Hersteller zu verwenden. So sollten Sie z. B. darauf achten, FTP-Zugriffe sowohl im Passive Mode (z. B. mit einem Browser) als auch im Active Mode (z. B. einfacher Kommandozeilenlient) durchzuführen. Auch sollten Sie ernsthaft überlegen, einen Testlienten unter Windows aufzusetzen, um Zugriffe mit dem Internet Explorer testen zu önnen. Dieser unterscheidet sich im Hinblic auf die Firewall schon darin von anderen Browsern, daß Zugriffe auf einen Web- Funtionstests 445

6 firewall 2006/1/4 15:26 page oder FTP-Server unter Umständen von Zugriffen auf die NetBIOS-Ports begleitet werden. Wenn man dies nicht weiß, ann man daraus resultierende Protoolleinträge leicht für einen Angriff halten. Zum Abschluß sollten Sie noch testen, ob Ihre Klienten im»loalen Netz«ebenfalls Ihren Server in der»dmz«ansprechen önnen. Dazu ann es sinnvoll sein, im loalen Netz benutzte Rechner als Testlienten zu benutzen, um die Tests realistisch zu gestalten. Port Scans Wir wissen nun, daß unsere Firewall die Verbindungen herstellt, die wir zulassen wollen. Was wir noch nicht wissen, ist, ob sie uns auch wie gewünscht gegen Angriffe schützt. Wir müssen daher beginnen, die Firewall mit den Augen eines Angreifers zu sehen. Insbesondere müssen wir herausfinden, ob die Möglicheit besteht, 1. von externen Rechnern auf interne Rechner zuzugreifen, 2. von externen Rechnern auf Server (Proxies) der Firewall zuzugreifen, 3. gegebenenfalls von externen Rechnern auf unerwünschte Ports des DMZ-Servers zuzugreifen, 4. gegebenenfalls von einem Rechner in der DMZ auf interne Rechner zuzugreifen, 5. gegebenenfalls von einem Rechner in der DMZ auf Server (Proxies) der Firewall zuzugreifen und 6. von internen Rechnern auf unerlaubte Ports externer Rechner zuzugreifen. Um dies zu testen, önnen wir Port Scans durchführen. Dies ann prinzipiell mit dem schon erwähnten Netcat geschehen, schneller und omfortabler geht es aber mit nmap. Dieses Werzeug wurde entwicelt, um diverse Arten von Port Scans durchzuführen und anhand von Fingerprinting das verwendete Betriebssystem zu erennen. Mittlerweile hat es sich für diesen Zwec zu einem anerannten Standard entwicelt und weite Verbreitung gefunden. Falls es Ihrer Distribution nicht beiliegt, önnen Sie es von herunterladen. Grundlagen nmap ennt diverse Möglicheiten, um Port Scans durchzuführen. Uns interessieren dabei vor allem SYN-Scans, FIN-Scans und UDP-Scans. Bei SYN-Scans werden Paete gesendet, die bei einem normalen Verbindungsaufbau das SYN-Flag gesetzt haben. Erhält nmap ein Antwortpaet, in dem SYN- und ACK-Flag gesetzt sind, so wartet auf dem untersuchten Port ein Server auf eingehende Verbindungen. Bei FIN-Scans werden Paete gesendet, in denen das SYN-Flag nicht gesetzt ist. Statt dessen ist das FIN-Flag gesetzt. Das Paet entspricht einem Verbindungsabbau. Diese Paete werden ignoriert, wenn der untersuchte Port nicht benutzt wird. Andernfalls wird ein Paet gesendet, in dem das RST-Flag gesetzt ist. Man untersucht hier also nicht, ob ein Port offen, sondern ob er geschlossen ist. Dabei önnen geschlossene Ports sogar 446 Kapitel 15: Abnahmetests

7 firewall 2006/1/4 15:26 page dann erannt werden, wenn sie durch Firewallregeln geschützt sind, die den Aufbau einer Verbindung zu diesen Ports verbieten (z. B. ipchains mit einer DENY-Regel, die die Option -y enthält). Lassen Sie mich den Unterschied verdeutlichen. Ich habe hier einmal ein System untersucht, bei dem Port 8000 offen, aber gegen Aufbau von Verbindungen geschützt ist, Port 8001 geschlossen und mit einer Regel geschützt ist, die alle Paete unterdrüct, und Port 8002 geschlossen, aber nur gegen den Aufbau von Verbindungen geschützt ist. Als ersten Port Scan habe ich einen SYN-Scan (-ss) von Port 20 (-g 20) auf die Ports (-p ) des Rechners localhost durchgeführt, wobei ich nmap untersagt habe, sich erst mit einem Ping davon zu überzeugen, ob der Rechner gegenwärtig im Netz verfügbar ist (-P0): nmap -ss -g 20 localhost -p P0 Starting nmap V. 2.3BETA14 by ( ) Interesting ports on localhost ( ): Port State Protocol Service 8000 filtered tcp unnown 8001 filtered tcp unnown 8002 filtered tcp unnown Nmap run completed -- 1 IP address (1 host up) scanned in 4 seconds Wie wir sehen, werden alle drei Ports als»filtered«angezeigt. nmap hat festgestellt, daß er von diesen weder eine positive Antwort auf einen Verbindungsaufbau noch eine Fehlermeldung erhält, und vermutet zu Recht, daß hier eine Firewall im Spiel ist. Wiederholen wir nun dasselbe als FIN-Scan (-sf), so erhalten wir ein anderes Bild: nmap -sf -g 20 localhost -p v -v -P0 Starting nmap V. 2.3BETA14 by fyodor@insecure.org ( ) Interesting ports on localhost ( ): Port State Protocol Service 8000 open tcp unnown 8001 open tcp unnown Nmap run completed -- 1 IP address (1 host up) scanned in 3 seconds Hier fehlt Port Das bedeutet, nmap hat ihn (zu Recht) als geschlossen erannt und zeigt ihn deshalb nicht an. Daß ihm diese Aussage gelang, liegt daran, daß das verwendete FIN-Paet von der Filterregel nicht erfaßt wurde. Für uns heißt das, daß ein Angreifer bei einem Scan unter Umständen feststellen ann, auf welchen Ports über 1024 wir Proxies betreiben. Die Ports unter 1024 werden in unserer Konfiguration als offen oder filtered angezeigt, da Paete an sie grundsätzlich verworfen werden. Paete ohne SYN-Flag an hohe Ports Port Scans 447

8 firewall 2006/1/4 15:26 page müssen wir aber prinzipiell immer zulassen, da wir ansonsten eine Antwortpaete von Servern im Internet empfangen önnten. Lediglich für Ports, die schon von Proxies belegt sind und nur aus dem loalen Netz angesprochen werden önnen, önnen wir Regeln definieren, die alle Paete aus dem Internet verwerfen. Führt unser Angreifer einen FIN-Scan auf die hohen Ports durch, so werden wir die Ports in der Ausgabe von nmap finden, die durch stare Regeln geschützt sind, von Servern belegt sind. Alle diese Ports sind aus seiner Sicht interessant. Wirlich nutzen ann er die Information allerdings nur, wenn sich auf einem Port ein Server befindet, der nicht durch Filterregeln geschützt ist. Erlauben wir FTP, so hat es unser Angreifer sogar noch leichter. Wir müssen den Aufbau von Verbindungen von Port 20 an unsere Firewall erlauben. D. h., unser Angreifer ann sogar einen SYN-Scan gegen unsere Firewall durchführen, vorausgesetzt, er benutzt als Quellport, wie oben angegeben, Port 20. Haben wir nun vergessen, einen Server auf einem hohen Port durch eine eigene Firewallregel zu schützen, so wird der Port von nmap auch als offen angezeigt. In diesem Fall sollten wir schleunigst die fehlende Regel nachtragen. Fehlt die Regel, so ist nicht nur ein Port Scan möglich. Es ann sogar eine reguläre Verbindung zu dem betreffenden Server aufgebaut werden. Ist der Server nicht zusätzlich so onfiguriert, daß er selbst überprüft, von welcher Adresse die Verbindungsanfrage am, so ist für einen Angreifer, der seine Anfragen von Port 20 aus stellt, derselbe Zugriff möglich, wie er auch einem Rechner im loalen Netz gestattet ist. Seit den Kernel-Versionen der Serie 2.4 besitzen wir allerdings eine stare Waffe gegen diese Probleme. Mit Stateful Pacet Filtering önnen wir Regeln aufstellen, die zwischen dem Aufbau von neuen Verbindungen und solchen, die als Antwort auf ein Kommando auf einer bestehenden FTP-Kontrollverbindung gesendet wurden, unterscheiden. Wir önnen auch Paete aussortieren, die eine Verbindung beenden sollen, die nie bestanden hat. Neben TCP-Scans existiert auch noch die Möglicheit, einen Rechner auf offene UDP- Ports zu untersuchen. Hierzu sendet nmap leere Datenpaete an den zu untersuchenden Port. Erhält er eine ICMP-Fehlermeldung, so betrachtet er den Port als geschlossen. Andernfalls gibt er an, der Port sei offen. Im folgenden Beispiel habe ich einen UDP-Scan (-su) von Port 53 aus durchgeführt: nmap -su -g 53 localhost -p P0 Starting nmap V. 2.3BETA14 by ( ) Interesting ports on localhost ( ): Port State Protocol Service 6000 open udp unnown Nmap run completed -- 1 IP address (1 host up) scanned in 3 seconds 448 Kapitel 15: Abnahmetests

9 firewall 2006/1/4 15:26 page Der hier als offen angezeigte Port wird durch eine Filterregel geschützt und ist damit nicht zugreifbar. Für die Ausgabe von nmap ist es dabei egal, ob ein Server auf diesem Port auf Paete wartet oder nicht. Das einzige UDP-Protooll, das unsere Beispiel-Firewall verwendet, ist DNS. Dieses benutzt Port 53. Aus diesem Grund müssen wir Paete von Port 53 an hohe Ports annehmen. Ein UDP-Scan dieser Ports ist also möglich, vorausgesetzt, der Angreifer benutzt als Quellport 53 und ann die Adresse des DNS-Servers fälschen. Er sollte dort allerdings in unserer Konfiguration eine offenen Ports finden. Darüber hinaus önnen wir mit Stateful Pacet Filtering auch für UDP verbieten, daß Paete angenommen werden, wenn zuvor ein Paet von uns gesendet wurde. Die Tests Der wichtigste Test besteht darin, die Firewall auf offene Ports zu untersuchen, um eventuell noch ungeschützte Server zu finden. Dieser Test sollte sowohl aus dem»internet«als auch gegebenenfalls aus der»dmz«durchgeführt werden. Hierzu sollten wir alle drei Scans von unterschiedlichen Ports aus durchführen. TCP- Scans sollten dabei zumindest von einem hohen Port und Port 20 aus erfolgen, idealerweise auch von anderen Ports, für die wir spezielle Regeln haben (53, 80, 119,... ). UDP-Scans sollten von einem hohen Port und Port 53 aus erfolgen. Es bietet sich an, die zu untersuchenden Ports in vier Bereiche aufzuteilen: TCP Hier sollten Port Scans grundsätzlich fehlschlagen. SYN-Scans sollten»filtered«ergeben, FIN-Scans dagegen»open«. Eine Ausnahme bildet Port 113. Dieser sendet eine ICMP-Fehlermeldung (Action: REJECT) 1. Hier melden sowohl SYN- als auch FIN-Scan»filtered« TCP SYN-Scans, die nicht von Port 20 aus gestellt werden, sollten für alle Ports»filtered«ergeben. Für Ports, die als»open«gemeldet werden, muß untersucht werden, zu welchem Programm sie gehören. Gegebenenfalls ist der Port durch zusätzliche Filterregeln zu schützen. Ohne Stateful Pacet Filtering sollten FIN-Scans nur die Ports melden, die durch spezielle Filterregeln geschützt sind. Auch hier sollten Ports, die als offen angegeben werden, noch einmal genau unter die Lupe genommen werden. Mit Stateful Pacet Filtering sollten alle Ports als»open«gemeldet werden UDP Alle Ports sollten als»open«gemeldet werden UDP Ohne Stateful Pacet Filtering sollten Scans von der Adresse des DNS-Servers Port 53 aus eine offenen Ports finden. Scans von anderen Quellports sollten alle Zielports als»open«melden. Mit Stateful Pacet Filtering sollten alle Ports als»open«gemeldet werden. Als nächstes sollten wir versuchen, ob es uns möglich ist, von unserem»server«im»internet«oder ggf. in der»dmz«aus auf den»klienten«im loalen Netz zuzugreifen. 1 Für diesen Port (Ident) hatten wir ja eine Ausnahmeregel definiert. Port Scans 449

10 firewall 2006/1/4 15:26 page Dazu sollten wir Port Scans von diversen Ports aus starten. Alle Scans sollten scheitern. Nun müssen wir gegebenenfalls testen, ob unser Server in der»dmz«hinreichend vor Angriffen aus dem»internet«geschützt ist. Hier sollten ebenfalls alle Arten von Port Scans eingesetzt werden, obwohl FIN-Scans eigentlich eine anderen Ergebnisse als SYN- Scans liefern sollten. Da wir außer DNS eine Klientenzugriffe in das Internet erlaubt haben, sollten außer 53 TCP/UDP und gegebenenfalls 20 TCP (FTP-Data) eine Ports existieren, zu denen Paete nur dann zugestellt werden, wenn es sich um eine SYN- Paete handelt. Auch sollten wir neben hohen Quellports spezielle Ports wie 20 TCP, 53 TCP, 80 TCP und 53 UDP verwenden. Allerdings sollte hier nur Port 53 eine besondere Rolle spielen, da DNS der einzige Dienst ist, für den wir Rechnern in der DMZ Klientenzugriffe erlauben. Ohne Stateful Pacet Filtering önnten daher von diesem Port ausgeführte FINoder UDP-Scans ungeschützte Server auf hohen Ports finden. Diese sollten aber durch eigene Regeln geschützt sein. Darüber hinaus sind solche Zugriffe auf eine leine Anzahl von zuvor definierten Servern beschränt, so daß sie nur dann gelingen, wenn unser Testrechner die Adresse eines DNS-Servers benutzt. Was Port 20 TCP angeht, so werden auch beim ativen FTP Verbindungen aus der DMZ ins Internet aufgebaut, diese erfolgen aber von Port 20 TCP auf hohe Ports. Die dafür nötigen Regeln erlauben einem Rechner im Internet daher Zugriffe von hohen Ports auf Port 20. FIN-Scans auf Port 20 durchzuführen, dürfte für einen Angreifer aber wenig informativ sein. Wir sollten daher grundsätzlich nur auf die von uns freigegebenen Server zugreifen önnen. Verwenden wir ein Stateful Pacet Filtering und betreiben wir einen FTP-Server, so besteht die Möglicheit, daß die Scans auch Ports finden, auf denen der FTP-Server auf eingehende Datenverbindungen wartet. Werden andere Server gefunden, so haben wir bei der Definition unserer Regeln einen Fehler begangen. Um schließlich noch zu testen, ob wir versehentlich mehr Ports als nötig freigeschaltet haben, önnen wir einen Port Scan vom»klienten«im loalen Netz zum»server«im»internet«durchführen. FIN-Scans sind hierbei allerdings nicht nötig, da es uns hier nicht darum geht, wie sicher der»server«onfiguriert ist, sondern ob es möglich ist, Verbindungen aufzubauen. SYN-Scans sollten für alle unerwünschten Ports»filtered«ergeben, UDP-Scans sollten alle Ports als»open«melden. Der Übersicht halber habe ich die vorangegangenen Ausführungen noch einmal in Tabelle 15-1 auf Seite 451 zusammengestellt. Dabei bedeutet: S F SYN-Scans von allen Ports, für die spezielle Regeln bestehen (20, 53, 80,... ), sowie von hohen Ports FIN-Scans von allen Ports, für die spezielle Regeln bestehen (20, 53, 80,... ), sowie von hohen Ports U UDP-Scans von allen Ports, für die spezielle Regeln bestehen (insbesondere 53), sowie von hohen Ports Kapitel 15: Abnahmetests

11 firewall 2006/1/4 15:26 page ext Der Testrechner steht im»internet«. dmz Der Testrechner steht in der»dmz«. lan Der Testrechner steht im»loalen Netz«. Firewall Die Angriffe richten sich gegen die Firewall. Tabelle 15-1: Testplan für die Abnahmetests Angreifer Opfer Stateful Pacet Filtering ohne mit ext, dmz Firewall SYN: SYN: niedrige Ports: filtered filtered hohe Ports: von Port 20: findet geschützte Ports und Server von hohen Ports: filtered FIN: FIN: niedrige Ports: Port 113 filtered Port 113: filtered andere: open andere: open hohe Ports: von Port 20, 21, 53, 80,...> 1024: findet geschützte Ports und Server von anderen: open UDP: UDP: niedrige Ports: open open hohe Ports: von DNS-Server 53: findet geschützte Ports und Server von anderen: open ext, dmz lan ein Erfolg ext dmz SYN: SYN: von niedrigen Ports: filtered findet erlaubte Server von hohen Ports: findet erlaubte und ungeschützte Server FIN: FIN: von 20, 80, 21: open findet erlaubte Server von DNS-Server 53: findet ungeschützte Server auf hohen Ports von hohen Ports: findet erlaubte und ungeschützte Server UDP: open lan ext, dmz nur erlaubte Dienste UDP: open Port Scans 451