|
Das unter V. nachfolgende Beispielfilterset lässt sich über das Webinterface des
Routers eingeben. Eine Programmierung der Filterregeln mit Telnet scheint zur Zeit
nicht möglich zu sein. Jedenfalls ist es mir nicht gelungen, auch nur eine einzige
44
___________________________
Hinweise
simple Regel über das Telnet-User-Interface einzugeben. Im Internet kursieren an
mehreren Stellen Beschreibungen zum Vigor 2000, in denen beschrieben wird, wie
man die Firewall-Regeln für diesen Router mit Telnet-Befehlen eingeben kann. Wenn
man jedoch beim Vigor 2200 in einer Telnet-Sitzung ,ipf ?' eingibt, fehlen die meisten
Befehlsmöglichkeiten, die in den Beschreibungen zum Vigor 2000 erwähnt werden
und die erforderlich wären, den Vigor 2200 hinsichtlich der Filterregeln zu programmieren.
Nach der Eingabe ,ipf view ?' erhält man einen Hinweis, der mit ,Usage:' beginnt,
gleiches fehlt, wenn man ,ipf rule ?' eingibt (www.vigor-users.de vermitteln
ebenfalls die Information, eine Konfiguration der Filter-Regeln mittels Telnet sei bei
den aktuellen Firmware-Versionen nicht möglich). Das Original-Handbuch beschreibt
,ipf rule' mit keinem Wort und in den technischen Spezifikationen im Anhang zum
Handbuch wird als Eigenschaft des Routers u.a. angegeben: ,IP-based packet filtering
with web-based configuration', während bei anderen Konfigurationsbeschreibungen
ausdrücklich das ,Telnet-based user Interface (TUI)' beschrieben wird. Die fehlende
Telnet-Konfiguration ist wirklich sehr bedauerlich, denn wenn man in einer Telnet-
Sitzung mit dem Vigor 2200 ,ipf rule ?' oder auch nur ,ipf rule' eingibt, wird eine
Vielzahl von Regelmöglichkeiten angezeigt, die - sollten sie tatsächlich zur Verfügung
stehen - eine enorm leitungsfähige Firewall lieferten (z.B. kann das ACK-Flag
abgefragt werden, bei ICMP-Paketen kann der genaue Typ herausgefiltert werden
usw.), die mit dem Webinterface nicht erstellt werden kann. Durch meine Versuche
mit dem ipf-Befehl ist mir allerdings aufgefallen, dass der mit ,ipf rule' angezeigte Befehlssatz
exakt mit dem Befehlssatz einer im Unix/Linux-Bereich weit verbreitete
Freeware-Firewall übereinstimmt, die auf der Homepage [39] kostenlos heruntergeladen
werden kann und zu der es sogar eine sehr gute deutsche Anleitung [40] gibt.
Über die Links auf der zitierten Homepage können Sie auf einen riesigen Pool zusätzlicher
Infos zur Firewall zugreifen.
Nun habe ich natürlich darüber nachgedacht, was ich aus dieser Übereinstimmung
folgern kann. Da ich an Zufälle nicht glaube (es ist einfach nicht denkbar, dass zwei
Programmierer völlig unabhängig voneinander eine Firewall entwickeln und am Ende
zu genau demselben Befehlssatz kommen), gehe ich davon aus, dass die Vigor-
Firewall tatsächlich auf dieser IPF-Firewall aus dem Unix/Linux-Lager beruht [41].
Eine andere Frage ist natürlich, ob die IPF-Firewall tatsächlich komplett übernommen
wurde und durch das WebInterface des Routers ausgebremst wird oder ob DrayTek
(z.B. weil der Speicher im Router nicht ausreicht) die Firewall zusammengestrichen
hat, so dass die Firewall tatsächlich nur das kann, was das WebInterface anzeigt.
Letzteres scheint mir eher unwahrscheinlich, auch wenn ich es leider nicht prüfen
kann, weil ich in das Programm des Routers nicht ,hineinsehen' und auch nicht testweise
andere Regeln eingeben kann, als das WebInterface zulässt. Gleichwohl wird
man doch folgendes überlegen müssen:
- Warum sollte DrayTek die Firewall kürzen, nicht aber die dazugehörige und mit
,ipf rule' angezeigte Hilfeseite ?
- Das Kürzen der Firewall ist mit Arbeit und einem hohen Fehlerrisiko behaftet, inwieweit
es urheberrechtlich zulässig ist, kann ich nicht beurteilen.
- Insbesondere das Verhalten des Routers beim Update auf die Fw 2.3 belegt,
dass die Firewall mehr kann, als das WebInterface zulässt: Der Router arbeitete
mit der Source-Route-Option weiter einwandfrei, obwohl sie nicht mehr eingegeben
werden konnte und das WebInterface sie bei der ersten Änderung einer be45
___________________________
Hinweise
liebigen Regel entfernt hat (s. dazu schon unter BegriffserläuterungenSource
Route).
Auch der Umstand, dass mit dem WebInterface nicht der gesamte IPF-Befehlssatz
ausgenutzt werden kann, spricht nicht gegen meine Vermutung. Das WebInterface
müsste ganz erheblich erweitert und mit weiteren Untermenus versehen werden, um
den gesamten Befehlssatz nutzen zu können. Möglicherweise reicht hierzu der Speicherplatz
im Router nicht oder DrayTek hat noch keine Gelegenheit gefunden, sich
dieser Arbeit anzunehmen. Auf das WebInterface kann DrayTek nicht verzichten; der
Router würde jeden Vergleichstest wegen mangelhafter Bedienbarkeit verlieren,
wenn die Firewall nur über Telnet programmiert werden könnte. DrayTek kann es
(sinnvollerweise) eigentlich auch nicht zulassen, dass die Firewall sowohl über Telnet
als auch über das WebInterface eingestellt werden kann, solange diese beiden Zugangsmöglichkeiten
nicht absolut die gleichen Optionen bieten. Es würde ein totales
Chaos entstehen, wenn ich z.B. über Telnet Firewall-Regeln unter voller Ausnutzung
des ipf-Befehlssatzes eingäbe und dann das WebInterface aufriefe: Alle Regeln würden
unvollständig und unverständlich wiedergegeben und - noch schlimmer - bei
der ersten Änderung im WebInterface völlig verkrüppelt, weil das WebInterface in
diesem Fall alle Regeln in den ipf-Befehlssatz neu übersetzt und dabei aber nur die
Möglichkeiten nutzt, die es selbst hat (wie beim Entfernen der Source Route-Option).
Nach meiner Auffassung gäbe es einen Ausweg (immer vorausgesetzt, der Router
beherrscht tatsächlich alle ipf-Befehle, denn dann wäre es eigentlich schade, das
verkümmern zu lassen): Wenn DrayTek eine Möglichkeit schüfe, die Firewall-
Programmierung über das WebInterface durch eine zusätzliche Option in eben diesem
Interface abzuschalten, könnte man eine andere Zugangsart öffnen:
Unter Linux lädt der Anwender sich die Firewall z.B. in den Kernel und kann die Regeln
über ipf -F a -f {Datei} ändern (Der Parameter -F a löscht die vorhandenen Regeln,
der Parameter - f {Datei} übergibt die neuen). In der {Datei} stehen die eigentlichen
Regeln, die so aufgebaut werden müssen, wie es ipf rule vorgibt und wie sie
auch vom Router mit , ipf view -r' wiedergegeben werden.
Denkbar wäre, dass DrayTek ein Hilfsprogramm verteilt, mit dem der Anwender die
Firewall-Regeln, die in einer Text-Datei abgelegt sind, an den Router schicken kann
(ähnlich wie das Programm für die Firmware-Updates). Dieses Programm müsste so
ausgelegt sein, dass es nur funktioniert, wenn vorher die Programmierungsmöglichkeit
für die Firewall-Regeln im WebInterface abgeschaltet ist. Umgekehrt müssten
alle Firewall-Regeln im Router (natürlich nach einer entsprechenden Warnung) gelöscht
werden, wenn der Anwender die Firewall-Programmierung über das WebInterface
wieder aktivieren will.
Damit hätte DrayTek alle Anwender zufrieden gestellt: Für den Einstieg könnte man
sich mit dem WebInterface zufrieden geben und danach auf die ,richtige' IP-Firewall
umsteigen. Die Vorteile wären immens:
- Der gesamte IPF-Befehlssatz stünde zur Verfügung.
- Die Anzahl der Regeln wären nur durch den Speicherplatz im Router begrenzt.
- Die Regeln könnten mit jedem Text-Editor bearbeitet werden. Man könnte sie
nach oben und unten schieben, in die Zwischenablage kopieren usw. usw.
46
___________________________
Hinweise
- Die eigentlichen Firewall-Regeln, die ja jetzt in einer einfachen Text-Datei stecken,
könnten problemlos zwischen den Anwendern ausgetauscht werden.
- Man hätte das gesamte Linux-Lager mit unzähligen Beispiel-Konfigurationen als
Hilfe zur Verfügung (soviel kann man gar nicht lesen, bevor der Router völlig veraltet
ist).
- Man könnte sich verschiedene (und unbegrenzt viele) Regel-Sets in Textdateien
ablegen und die gesamte Firewall per Mausklick in Sekundenbruchteilen austauschen
und für jeden Benutzer verschiedene Firewalls anlegen.
- Es könnten Regel-Gruppen gebildet werden (dazu gleich mehr).
Es wäre doch wirklich schade, wenn das alles ein Traum bliebe (Vielleicht übersetzt
ja jemand einmal diese Passagen ins Chinesische und schickt sie an DrayTek; die
ersten Regel-Sets in Textform stelle ich.)
Eine Beispieltextdatei könnte z.B. wie folgt aussehen:
block in quick from any to any with short
pass in quick proto icmp from any to any
pass in quick proto tcp from any port = ftp-data to any port > 1024
block in quick from any to any
block out quick proto tcp/udp from any port = 445 to any
pass out quick proto icmp from any to any
pass out quick proto udp from any to 217.5.99.9/32 port = domain
pass out quick proto udp from any to 194.25.2.128/25 port = domain
pass out quick proto tcp from any to any port = www
pass out quick proto tcp from any to any port = 443
pass out quick proto tcp from any to 194.25.134.0/24
pass out quick proto udp from any port = ntp to 130.149.17.21/32 port = ntp
pass out quick proto tcp from any to 62.153.159.134/32 port = nntp
pass out quick proto tcp from any to 207.46.230.185/32 port = nntp
pass out quick proto tcp from any port > 1024 to any port = ftp
pass out quick proto tcp from any to any port = telnet
pass out quick proto tcp from any port > 1024 to any port > 1024
block out quick from any to any
Eine weitere recht originelle Methode, mit der das WebInterface den ipf-Befehlssatz
nutzt, findet man, wenn versucht bei den einzelnen Filterregeln unter Branch to Other
Filter Set etwas anderes als ,None' einzutragen. Zunächst fällt auf, dass man
diese Option in der Firewall nur bei einer einzigen Regel benutzen kann. Versucht
man die Option bei einer zweiten Regel einzusetzen, verweigert sich der Router bzw.
trägt eigenmächtig wieder ,None' ein. Noch skeptischer wird man, nachdem man
festgestellt hat, dass man nur nach ,oben' auf das Set#1 verweisen kann und bekommt
natürlich sofort Angst, hier eine nicht mehr endende Rekursion zu programmieren.
Aber keine Sorge: Wenn man sich die Regel, bei der man den ,Verweis' auf
das Set#1 gesetzt hat, unter Telnet mit ,ipf view -r' ansieht, stellt man fest, dass diese
Regel den Zusatz ,head 1' bekommen hat.
Um dies zu verstehen, musste ich wieder auf die Beschreibungen zur IP-Firewall zurückgreifen:
47
___________________________
Beispielfilterset für die Router Firewall
Wenn man einer Regel den Zusatz head # (z.B. 100) verpasst und die Regel zutrifft,
arbeitet die Firewall zunächst alle Regeln ab, die zu dieser "Überschrift"-Regel gehören.
Diese Zusammengehörigkeit wird dadurch gekennzeichnet, dass man diesen
Regeln group # (z.B. 100) hinzufügt. Findet die Firewall eine Gruppenregel mit dem
Zusatz "quick" wird diese Regel sofort ausgeführt und die Firewall ist mit ihrer Arbeit
am Ende. Findet die Firewall keine zutreffende Gruppenregel, kehrt sie zur Überschrift-
Regel zurück. Ist dies ein quick-Regel, wird diese Regel ausgeführt und die
Firewall ist fertig; ist es keine quick-Regel, macht die Firewall mit den Regeln "hinter"
den Gruppenregeln weiter, und zwar mit der Standard-Aktion, die die Überschrift-
Regel setzt (pass if no further match oder block if no further match). Findet die Firewall
eine zutreffende Gruppenregel, die keine quick-Regel ist, und wird auch in den
folgenden Gruppenregeln keine quick-Aktion befohlen, dann ist die Überschrift-Regel
"übersteuert" (gleichgültig, ob es sich um eine quick-Regel handelt oder nicht). Die
Firewall macht mit den Regeln "hinter" den Gruppenregeln weiter, und zwar mit der
Standard-Aktion, die die zutreffende Gruppen-Regel gesetzt hat (pass if no further
match oder block if no further match).
I
nnerhalb einer Gruppe kann man sogar weitere Untergruppen bilden, indem man
einer Regel z.B. den Zusatz "head 101 group 100" hinzufügt.
Der entscheidende Vorteil einer solchen Gruppierung besteht darin, dass sie die Arbeit
der Firewall dramatisch beschleunigen kann: Ein Paket, auf das die Überschrift-
Regel nicht zutrifft, überspringt alle Gruppenregeln, die zu dieser Überschrift-Regel
gehören und durchläuft sofort die danach kommenden Regeln.
Beispiel:
block out quick from 192.168.1.10/32 to any head 1
pass out quick proto icmp from 192.168.1.10/32 to any group 1
pass out quick proto tcp from 192.168.1.10/32 port > 1024 to any port > 1024 group 1
... group 1
... group 1
... group 1
pass out quick from any to any
Alle ausgehenden Pakete vom Rechner mit der IP 192.168.1.10 werden einer genauen
Prüfung unterzogen, indem sie das gesamte Regelwerk der group 1 durchlaufen.
Finden sie dort keine Erlaubnisregel, werden sie durch die head 1-Regel sofort
verworfen. Pakete von allen anderen Rechnern überspringen nach der head 1-Regel
die dazugehörigen Gruppenregeln und werden durch die letzte Regel sofort durchgelassen.
Da der Router keine Regeln mit dem Zusatz ,group 1' versieht, bringt es überhaupt
nichts, unter Branch to Other Filter Set etwas anderes als ,None' einzutragen. Es gibt
keine zu ,head 1' passende Gruppe. Alle Pakete durchlaufen die head 1-Regel und
machen danach mit der nächsten Regel weiter. Es scheint mir auch etwas übertrieben,
bei einer Router-Firewall, die überhaupt nur 84 Regeln zulässt, Gruppierungen
vorzunehmen (zum Vergleich: In den Linux-Beschreibungen habe ich Berichte über
ipf-Firewalls mit 45.000 (!) Regeln gefunden. Da muss der Vigor noch etwas üben.)
|
