BMW möchte sich im Internet mit Hilfe eines WWW-servers präsentieren. Dieser server sollte vor dem eigentlichen Firewall plaziert werden, da die große Gefahr besteht, daß er erfolgreich angegriffen werden kann. Befindet er sich dann innerhalb des privaten Netzes, so ist das gesamte Netz gefährdet, während bei Plazierung vor dem Firewall nur der server selber gefährdet ist. Bei der Konfiguration dieses servers muß unbedingt darauf geachtet werden, daß dieser Rechner keine weiteren Dienste zur Verfügung stellt, da diese von Angreifer ausgenutzt werden könnten.
Diese beiden server enthalten Informationen über Benutzer sowie z. T. Daten, die nicht nach außen gelangen sollten. Deshalb sollten sie innerhalb des Firewalls plaziert werden. Der mail-server sollte so konfiguriert werden, daß nur berechtigte Benutzer Nachrichten verschicken können, während der newsserver so konfiguriert werden muß, daß bestimmte news-Gruppen nicht nach außen bekannt gemacht werden.
Aufgrund der bisherigen Untersuchungen bietet sich das in Abbildung ![[*]](http://wwwbode.informatik.tu-muenchen.de/icons/latex2html-97.1/gif/cross_ref_motif.gif){kind=icon}
dargestellte Szenario an.
Der WWW-server verfügt über keinen Schutz durch den Firewall. Eventuell wäre es möglich, einen Router vor den server zu schalten, um so die möglichen Verbindungen auf Verbindungen zu Port 80 beschränken zu können. Bei entsprechender Konfiguration des server erscheint dies aber überflüssig. Der mailserver hat im Beispiel die IP-Adresse 192.1.1.1, während der newsserver zu Beispielszwecken die Adresse 192.1.1.2 erhält.
Die beiden im Umfang des Firewalls enthaltenen Proxies werden so konfiguriert, daß kein externer Benutzer Zugang erhält, ohne sich über ein one-time password authentifiziert zu haben. Interne Benutzer erhalten Zugang über normale Paßworte.
Der mail-Proxy wird vom Firewall automatisch so konfiguriert, daß eintreffende mail an den internen newsserver weitergeleitet wird, während Nachrichten aus dem internen Netz an den entsprechenden Zielrechner übergeben werden.
Es sollte ein news-Proxy eingesetzt werden, der eine sofortige Weiterleitung eintreffender Artikel an den internen news-server durchführt. Ebenso verhält es sich in der umgekehrten Richtung.
Der WWW-Proxy vermittelt zwischen einem client und dem gewünschten server. Der client muß hierzu aber in der Lage sein, über einen Proxy zu kommunizieren. Eventuell müssen die Benutzer mit neuen clients versorgt werden oder gewisse Änderungen an der Konfiguration der clients vorgenommen werden.
Abschließend soll noch eine Beispielskonfiguration für den Paket-Filter des IBM NetSP angegeben
werden. Die einzelnen Felder der in Tabelle dargestellten Regeln haben
folgende Bedeutung:
Hier läßt sich festlegen, ob die entsprechende Regel dazu dient, bestimmte Pakete zu gestatten oder zu verwerfen.
Hier läßt sich die IP-Adresse des Absenders eingeben.
Die source mask gibt an, welche Bits der source adress untersucht werdne sollen. Zu beachten ist hierbei, daß beim NetSP im Gegensatz zum CISCO-Router ein logisches UND verwendet wird, um die gültigen Bits zu bestimmen. Das bedeutet, daß nur die Bits untersucht werden, die in der Maske den Wert 0 enthalten.
Diese zwei Felder geben die Zieladresse an.
Das Protokoll, auf das sich diese Regel beziehen soll. Außer den bekannten Protokollen TCP, UDP,
und ICMP ist hier der Eintrag 'all' möglich, um sich auf beliebige Protokolle zu beziehen.
Enthält dieses Feld den Wert TCP/ACK, so sind nur TCP-Pakete gestattet, die das ACK-FLAG gesetzt
haben (vgl. Kap. ).
Diese Felder geben den Port des Absenders bzw. des Empfängers an. Hierzu stehen verschieden Operatoren sowie der Eintrag 'any', der sich auf beliebige Ports bezieht, zur Verfügung.
Hier kann festgelegt werden, ob sich die betreffende Regel auf das zum Internet gehende (non-secure) Interface beziehen soll, ob es sich um das zum privaten Netz gehende (secure) Interface handeln soll oder ob die Regel für beide Interfaces gelten soll.
Dieses Feld dient dazu, festzulegen, ob es sich um ein an den Firewall selbst adressiertes Paket handelt (local) oder um ein an einen anderen Rechner gerichtetes (route). Verwendet man hier 'local', so kann man auf die Angabe einer Zieladresse verzichten. Ebenso verhält es sich bei vom Firewall stammenden Paketen.
Mit Hilfe dieses Feldes kann man bestimmen, ob die Regel für Pakete gelten soll, die auf dem entsprechenden Interface eintreffen (inbound) oder von dem entsprechenden Interface versendet werden sollen (outbound).
| 1 | permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 TCP/ACK any 0 any 0 non-secure local inbound |
| 2 | permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 TCP any 0 eq 23 non-secure local inbound |
| 3 | permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 TCP any 0 eq 25 non-secure local inbound |
| 4 | permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 UDP any 0 eq 53 non-secure local inbound |
| 5 | deny 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 TCP any 0 lt 1024 non-secure local inbound |
| 6 | deny 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 TCP any 0 eq 6000 non-secure local inbound |
| ... | ... |
| 7 | permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 TCP any 0 any 0 non-secure local inbound |
| 8 | permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 any any 0 any 0 non-secure local outbound |
| 9 | permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 TCP/ACK any 0 any 0 secure local inbound |
| 10 | permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 TCP any 0 eq 23 secure local inbound |
| 11 | permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 TCP any 0 eq 20 secure local inbound |
| 12 | permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 TCP any 0 eq 80 secure local inbound |
| 13 | permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 UDP any 0 eq 53 secure local inbound |
| 14 | permit 192.1.1.2 255.255.255.255 0.0.0.0 0.0.0.0 TCP any 0 eq 119 secure local inbound |
| 15 | permit 192.1.1.1 255.255.255.255 0.0.0.0 0.0.0.0 TCP any 0 eq 25 secure local inbound |
| 16 | permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 any any 0 any 0 secure local outbound |
Die Regeln 1 bis 8 beziehen sich ausschließlich auf das Interface zum Internet. Hierbei dienen die Regeln 1 bis 7 für Pakete, die aus dem Internet an den Firewall adressiert wurden, während Regel 8 der umgekehrten Richtung dient. Die Aufgaben der Regeln sind im einzelnen die folgenden: Regel 1 erlaubt es beliebigen Rechnern, auf vom Firewall initiierte Verbindungen zu antworten. Regel 2 bis 4 erlauben telnet, mail sowie DNS aus dem externen Netz zum Firewall, wo diese Dienste von den entsprechenden Proxies weiterbehandelt werden. Die Regel 5 verbietet daraufhin jeden Zugang zu nicht-privilegierten Ports. Aufgrund der Reihenfolge der Regeln ist natürlich weiterhin der Zugang zu den vorher explizit gestatteten Ports möglich. Um FTP durch den Firewall zu ermöglichen, ist es erforderlich, den gesamten nicht-privilegierten Portbereich von außen zugänglich zu machen. Einige, besonders gefährdete Ports können natürlich ausdrücklich ausgeschlossen werden. Dies ist im Beispiel bei Regel 6 der Fall, die den Zugang zu Port 6000, dem üblichen Port für X-server, verwehrt. Hier können noch beliebige weitere Ports gesperrt werden. Die abschließende Regel 7 gestattet alle anderen TCP-Pakete zum Firewall. Alle weiteren Pakete, also insbesondere nicht an den Firewall selbst adressierte Pakete, werden automatisch verworfen. Regel 8 dient ausschließlich dazu, vom Firewall ausgehende Pakete zu gestatten.
Die Regeln 9 bis 16 dienen nun dazu, Verbindungen über das sichere Interface zu ermöglichen. Wiederum dienen die Regeln 9 bis 15 für Verbindungen zum Firewall, während Regel 16 nur dazu dient, daß der Firewall Pakete in das interne Netz verschicken darf. Die Regel 9 erlaubt es jedem internen Rechner auf vom Firewall ausgehende Verbindungen zu antworten, während die Regeln 10 bis 14 die Dienste telnet, FTP, WWW sowie DNS erlauben. Allerdings sind nur Verbindungen zum Firewall möglich, wo die Weiterleitung der Verbindungswünsche mit einem Proxy erfolgt. Die Regel 14 wurde eingefügt, um nur dem mailserver die Möglichkeit zu geben e-mail zu versenden. Hiermit wird erreicht, daß der mailserver zum Versenden von Nachrichten verwendet werden muß, und somit eine Beschränkung auf autorisierte Benutzer ermöglicht. Regel 15 gestattet dem newsserver den Aufbau einer Verbindung zum Firewall, der über einen Proxy die Verbindung zu einem externen newsserver herstellt. Alle weiteren Pakete werden auch hier vom Firewall automatisch verworfen.
Um den Problemen, die durch das fehlende Alerting auftreten, entgegenzuwirken, erscheint es sinnvoll, einige Skripts zu entwerfen, die die erstellten Log-Files in regelmäßigen Abständen auf verdächtige Einträge untersuchen.
Zu beachten ist weiterhin, daß das automatisch erstellte Konfigurationsfile für den name server keinen Eintrag für den WWW-server erhält. Dieser Eintrag muß von Hand eingefügt werden, da der WWW-server im externen Netz bekannt sein muß.
