|
Allgemeine Hinweise
Sehr wichtig: Die Beispiele habe ich für einen Router erstellt, auf dem die Firmware
2.3 (Build Date/Time Fri Jan 10 9:35:52.74 2003) und zwar in der Version eingespielt
war, die ich von DrayTek/Taiwan unter ftp://ftp.draytek.com.tw heruntergeladen habe
(die deutsche Oberfläche habe ich mir gespart). Vorher habe ich die Regeln auch mit
den Firmware-Versionen 2.1a und 2.2 ohne Probleme im Einsatz gehabt. Mit der
Firmware 2.0a - jedenfalls in der Fassung, mit der mein Router im Auslieferungszustand
bestückt war - funktioniert das Regelset nicht. Bei dieser Firmware sind ziemlich
genau doppelt so viele Regeln erforderlich, und zwar aus folgendem Grund:
Ausgehende Verbindungen mit dem TCP-Protokoll werden immer eingehend bestätigt.
Von anderen Firewalls war ich es gewohnt, dass diese eingehenden Quittungspakete
automatisch zugelassen waren, wenn ich eine ausgehende Verbindung gestattet
habe (so arbeiten jetzt offenbar auch die Versionen 2.1a bis 2.3). Die Firmware
2.0a blockte diese Pakete, wenn man sie nicht durch eine ausdrückliche Regel zuließ.
Diese Voreinstellung macht natürlich beim TCP-Protokoll die Unterscheidung in
den Filterregeln zwischen aus- und eingehenden Datenpaketen unsinnig, weil man
dann ohnehin für jede erlaubte Ausgangsverbindung eine korrespondierende Eingangsverbindung
erlauben muss. Außerdem schafft man hierdurch zusätzliche Risiken,
denn die eingehende Verbindung ist jetzt generell gestattet, also unabhängig
davon, ob es sich um Quittungspakete oder eine von außen eigenständig initiierte
Verbindung handelt (Auch wenn ich bei den ausgehenden Erlaubnisregeln die \'Keep
State\'-Option aktiviert habe, habe ich ohne ausdrückliche Erlaubnisregel für eingehende
Pakete keine Verbindung zustandegebracht, was mir inzwischen auch logisch
erscheint: Wenn der Router bereits die Antwortpakete des angesprochenen Servers
mit dem ACK-Flag blockt, wird eben gar keine Verbindung etabliert, deren Status
gehalten werden könnte). Wenn Sie also unbedingt bei der Firmware 2.0a bleiben
wollen, müssen Sie bei jeder ausgehenden Erlaubnisregel über das TCP-Protokoll
eine eingehende Erlaubnisregel eingeben, bei der Sie im Vergleich zur ausgehenden
Regel [Quell-Adresse + Port] gegen [Ziel-Adresse + Port] tauschen. Spiegelbildlich
gilt Gleiches, wenn Sie eine eingehende Verbindung erlauben wollen.
I
ch habe mich beim Abfassen des Regelsatzes bewusst darauf konzentriert, einen
möglichst ungehinderten Internet-Verkehr zuzulassen, Sicherheitsgesichtspunkte
mussten demgegenüber zurückstehen. Es handelt sich daher nicht um einen besonders
sicheren Regelsatz, sondern um einen besonders zugangsfreundlichen. Jeder
Anwender kann durch das Deaktivieren der einen oder anderen Regel zusätzliche
Sicherheit schaffen. Die Anmerkungen im Anschluss an das Beispiel sollen dabei
behilflich sein.
I
ch habe mich ferner für einen Aufbau entsprechend der deny-all-Strategie entschieden,
bei der durch die letzten Regeln alles verboten wird, was nicht vorher gestattet
wurde. Diese Vorgehensweise scheint mir die sicherste zu sein, weil mir durch die
Eingabe einer entsprechenden Erlaubnisregel unmittelbar vor Augen geführt wird,
welche Tore ich öffne. Ich muss allerdings einräumen, dass die Eingabe einer einzigen
,falschen' Erlaubnisregel 83 wohlüberlegte andere Regeln überflüssig machen
kann. Man sollte daher jede Erlaubnisregel sehr genau überprüfen und Kontrollen
49
___________________________
Beispielfilterset für die Router Firewall
durchführen, indem man z.B. eine Erlaubnisregel, die für einen bestimmten Dienst
eigentlich zwingend erforderlich ist (z.B. die Regeln für den DNS-Port 53), testweise
deaktiviert: Kann man dann trotzdem problemlos im Internet surfen, ist ein Fehler im
Regelset. Die deny-all-Strategie erleichtert außerdem die Fehlersuche: Wenn ich den
Eindruck habe, bestimmte Dinge im Internet wegen der Router-Firewall nicht mehr
nutzen zu können, so reicht es aus, die beiden letzten Regeln vorübergehend zu deaktivieren.
Klappt es dann, ist eine weitere Erlaubnisregel erforderlich, während ich
die Firewall als Ursache ausschalten kann, wenn trotz dieser Deaktivierung die gewünschte
Verbindung nicht zustande kommt.
Schließlich habe ich es vermieden, Regeln nach den Vorgaben ,Block If No Further
Match' bzw. ,Pass If No Further Match' einzusetzen oder in ein anderes Filterset als
das nachfolgende zu verzweigen, weil ich Sorge habe, dass hierdurch das gesamte
Regelgerüst unübersichtlich wird. Aus dem gleichen Grunde habe ich bei jedem Filterset
(mit Ausnahme des Call-Fiter-Sets 1) einen Verweis auf das nachfolgende Filterset
gesetzt, und zwar auch dann, wenn dieses z.Zt. gar nicht belegt ist (Vorsicht:
Wenn Sie ein komplettes Set in der Übersicht mit ,Clear' löschen, wird auch der Verweis
auf ,None' gesetzt, was bei dem von mir gewählten Aufbau zu einer ziemlichen
Katastrophe führt, weil die gesamten Filterregeln unsinnig werden: Die zentralen Regeln
sind in Set 12; dieses muss angesprungen werden !!).
Gegen meinen Regelaufbau ist einem Forum eingewandt worden, er sei zu riskant;
es sei besser, zwei Regeln für ein- und ausgehende Pakete mit dem Befehl ,Block If
No Further Match' voranzustellen. Ich will wirklich niemanden davon abhalten, nach
dieser Methode vorzugehen. Wer sich mit einem solchen Aufbau besser fühlt, kann
ihn ohne weiteres wählen. Als Programmierer widerstrebt er mir, weil er langsamer
und daher nicht sauber programmiert ist. Auch wenn diese Anleitung vielleicht gelegentlich
einen anderen Eindruck erweckt: Hauptaufgabe eines Routers ist es, zu verbinden
und nicht zu blocken. Deshalb gehören die wichtigsten Erlaubnisregeln (DNS,
http und https) an den Anfang des Regel-Sets. Findet der Router diese Regeln kann
er sofort verbinden und ist mit der Paketüberprüfung nicht weiter beschäftigt (es ist
deshalb auch kein Zufall, dass alle meine Regeln mit dem Parameter ,quick' in den
ipf-Befehlssatz übersetzt werden). Bei Paketen, die geblockt werden sollen, muss er
sich durch den ganzen Regelsatz durcharbeiten, was jedoch - zeitlich betrachtet -
unschädlich ist, weil diese Pakete ohnehin verworfen werden sollen. Bei der ,Block If
No Further Match'-Variante muss der Router die ausgehende Regel und die eingehende
Regel zunächst einmal zwischenspeichern, um sich den nächsten Regeln zu
widmen. Erst wenn er eine passende ,quick'-Regel findet, kann er aufatmen, die zwischengespeicherten
Regeln löschen und endlich die gewünschte Verbindung herstellen.
Diese Variante ist nach meiner Auffassung letztlich auch nicht wirklich sicherer:
Wenn ich im folgenden versehentlich eine Regel mit dem Inhalt ,pass out quick from
any to any' einbaue, habe ich wieder eine völlig unbrauchbare Firewall. Wenn ich
mehrere ,...If No Further Match'-Regeln hintereinanderschalte, kann ich den Überblick
unter Umständen sehr schnell verlieren. Auch deshalb würde ich diese Varianten
nach Möglichkeit meiden. Ich persönlich halte daher meinen Aufbau für besser
und ziehe es vor, die komplett fertiggestellten Regeln einmal unter Telnet mit ,ipf
view -r' zu kontrollieren (am Ende der eingehenden Regeln muss block in quick from
any to any stehen, am Ende der ausgehenden block out quick from any to any), statt
den Router tausendfach bei jedem Paket auszubremsen.
50
___________________________
Beispielfilterset für die Router Firewall
In- und Out-Filter habe ich in getrennten Sets untergebracht, um mir selbst klarzumachen,
dass man hier auch bei Source- (Quell-) und Destination- (Ziel-) Adresse
umdenken muss. Einfacher wäre es manchmal gewesen, die In- und Out-Regel unmittelbar
hintereinanderzuschalten.
Die möglichen 84 Regeln mögen auf den ersten Blick viel erscheinen, sind es aber
nicht, wenn man bedenkt, dass es um die Einstellung eines Routers geht, bei dem im
Gegensatz zu einer Desktop-Firewall u.U. verschiedene Regelsätze für verschiedene
Rechner erstellt werden müssen. Erheblich nachteilig wirkt sich in diesem Zusammenhang
auch aus, dass für ein- und ausgehende Datenpakete separate Regeln
erstellt werden müssen, weil es nicht möglich ist, eine Regel für beide Richtungen
einzugeben. Schließlich erhöht sich die Anzahl der Regeln auch deshalb, weil man
mit einer einzigen Regel nur dann mehrere Ports freischalten/sperren kann, wenn die
Ports zusammenhängen (von ... bis ...). Die Möglichkeiten anderer Router, auch bei
nicht zusammenhängenden Ports (z.B. http=Port 80 und https=Port 443) mit einer
Regel auszukommen, bietet der Vigor im WebInterface nicht.
Sie werden sich vielleicht wundern, dass ich bei keiner einzigen Regel die Keep State-
Option gesetzt habe. Dies hat mehrere Gründe: Nach meinen Erfahrungen mit
anderen ,Optionen' des Routers traue ich auch dieser Geschichte nicht mehr. Ferner
haben mich Berichte irritiert, wonach es Angreifern möglich sein soll, auch in eine
etablierte Verbindung Pakete einzuschmuggeln. Schließlich bin ich mir nicht sicher,
ob diese Option beim Vigor mit maximal 84 Regeln tatsächlich die Firewall beschleunigt
oder - zumindest im Einzelfall - nicht eher verlangsamt. Auch mit gesetzter
Keep State-Option muss der Router schließlich die Daten der etablierten Verbindung
zwischenspeichern und bei jedem Paket prüfen, ob dieses zur etablierten Verbindung
gehört. Das kann u.U. langsamer sein als festzustellen, ob das Paket über den
Port 80 nach draußen geht. Es schien mir daher wichtiger zu sein, die Regeln für die
wichtigsten Ports (DNS, http, https) nach oben zu stellen. Bei einer Firewall mit
45.000 Regeln sieht das sicher anders aus.
Das Feld ,Branch to Other Filter Set' sollten Sie aus den Gründen auf ,None' stehen
lassen, die ich unter IV. Hinweise Kann die Firewall mehr ? erläutert habe.
Sollten Sie noch mit einer Firmware < 2.3 arbeiten, finden Sie bei den einzelnen Filterregeln
eine Option ,Source Route'. Kreuzen Sie dies nicht an. Nach einer Stellungsnahme
von DrayTek ist diese Option ,invalid', sie wird in jedem Fall in unbrauchbarer
Weise in den ipf-Befehlssatz übersetzt.
|
