Grundlagen Firewall-Regeln

Zur Einstellung der Firewall der Vigor-Router werden 2 Möglichkeiten geboten - einerseits das Webinterface und andererseits die Konfiguration über Telnet.
Schaut man sich die Telnetbefehle an, erkennt man, dass über Telnet vieles einfacher oder überhaupt erst möglich ist.
Das Webinterface ist also sozusagen nur eine Teilmenge der Möglichkeiten, die die Firewall eigentlich bietet.
Andererseits ist die Konfiguration über Telnet nicht gerade einfach und es ist vielleicht gerade am Anfang sinnvoll die Konfiguration per Webinterface vorzunehmen und eventuell anschliessend per Telnet sich die Einträge anzuschauen oder zu erweitern und zu ergänzen.

Anmerkung: Offensichtlich wurde die Möglichkeit der Firewall-Konfiguraton mittels Telnet aus den aktuellen Firmware-Versionen wieder herausgenommen!
Weitere Infos darüber liegen uns derzeit noch nicht vor.
Einige wenige Einstellungen, die das Logging der Firewall betreffen, sind allerdings noch vorhanden. Es lassen sich nur keine Filter mehr per Telnet erstellen, löschen oder verändern.
Die Beschreibung ist zum Verständnis der Funktionsweise der Firewall des Vigor trotzdem noch interessant.



Es folgt hier nun ein nicht sehr bekannte Beschreibung des Telnet-Interface der Vigor-Firewall.
Der Text wurde von 2-com.de ursprünglich für den Vigor 2000 mit einer älteren Firmware (1.06?) geschrieben, aber hat in den meisten Punkten sowohl für den Vigor 2000 als auch die 2200er-Reihe immer noch Gültigkeit.
Er liegt leider nicht mehr auf dem 2-com-Server zum Download und wurde hier von mir als HTML-Text aufgearbeitet.

Die IP Filter-Regeln

Inhalt:
1. Einführung in die IP Filters
2. Die Filterregeln
2.1 Filterregel Syntax
2.2 Beschreibung der Filterregeln
     ACTIONS
     OPTIONS
     MATCHING PARAMETERS
     KEEP HISTORY
     GROUPS
     LOGGING
     BEISPIELE
3. Operationen den IP Filters
3.1 Das ipf Kommando
3.2 Das ipf view Kommando
3.3 Das log Kommando

firewall01_437_325.gif

firewall02_430_223.gif

1. Einführung in die IP Filters

Ihr Vigor 2000 ist ausgestattet mit einem leistungsstarken IP Filter, der vom Benutzer als Firewall genutzt/konfiguriert werden kann. Die IP Filter sind in 3 Interfaces des Routers implementiert: das LAN-Interface, das ISP-Dialup Interface und das Dial-in Interface (Remote Access). -siehe Abbildung 1

Es gibt 2 Sets (oder Profile) von Filterregeln, zwischen denen man mit einem Telnet Kommando hin- und herschalten kann, bzw. um jeweils eines dieser Profile als das aktive Profil festzulegen. Die Pakete, die durch den Filter durchgelassen oder geblockt wurden, können zur eventuellen Fehleranalyse protokolliert werden. Die Protokollfunktion (Log) folgt den Grundregeln spezifiziert in den Filterregeln und ausdrücklich durch einen Telnet Befehl!

Jedes Paket, dass durch den Filter gehen soll, wird behandelt wie in Abbildung 2 beschrieben. Die IP-Accounting Funktion (über den "count" Befehl in der Filterregel) bewirkt, dass das Paket in die Accounting Statistik des Filters eingeht. Diesem folgen 2 Cache-Matches, die den Paketen, die mit diesen übereinstimmen, erlauben "direkt" durchzufliessen, anstatt durch die Filterregel-Liste zu gehen. Die "keep frags" und "keep state" Filterregel-Funktionen können wichtige Informationen über fragmentierte Pakete und Informationen über den Datenfluss einer Kommunikations-Session speichern/loggen.

Die IP-Filterung durchläuft eine verästelte Filter-Liste, zuerst über einen "Haupt-Strang" und zweigt immer dann, wenn ein Paket mit einer Regel übereinstimmt, ab. Es gibt 3 mögliche Resultate des Filterns --- Pass, Block & No-match! Der Filter lässt also nur die "No-Match" Pakete durch.

nach oben

2. Die Filterregeln

2.1 Filterregel Syntax

Filter-Regel = [insert] action in-out [options] [tos] [ttl] [proto] [ip] [group]
insert= "@” decnumber
action= block / "pass” / log / "count” / skip
in-out= "in” / "out”
options= [ log ] [ "quick" ] [ "on" interface-name [ dup ] ] .
tos= "tos" decnumber | "tos" hexnumber .
ttl= "ttl" decnumber .
proto= "proto" protocol .
ip= srcdst [ flags ] [ with withopt ] [ icmp ] [ keep ] .
group= [ "head" decnumber ] [ "group" decnumber ] .
block= "block" [ icmp[return-code] | "return-rst" ] .
log= "log" [ "body" ] [ "first" ].
interface-name= "lan" | "isp" | "dialin" .
skip= "skip" decnumber .
dup= "dup-to" interface-name[":"ipaddr] .
protocol= "tcp/udp" | "udp" | "tcp" | "icmp" | decnumber .
srcdst= "all" | fromto .
fromto= "from" object "to" object .
icmp= "return-icmp" | "return-icmp-as-dest" .
object= addr [ port-comp | port-range ] .
addr= "any" | nummask | host-name [ "mask" ipaddr | "mask" hexnumber ] .
port-comp= "port" compare port-num .
port-range= "port" port-num range port-num .
flags= "flags" flag { flag } [ "/" flag { flag } ] .
with= "with" | "and" .
icmp= "icmp-type" icmp-type [ "code" decnumber ] .
return-code= "("icmp-code")" .
keep= "keep" "state" | "keep" "frags" .
nummask= host-name [ "/" decnumber ] .
host-name= ipaddr | hostname | "any" .
ipaddr= host-num "." host-num "." host-num "." host-num .
host-num= digit [ digit [ digit ] ] .
port-num= service-name | decnumber .
withopt= [ "not" | "no" ] opttype [ withopt ] .
opttype= "ipopts" | "short" | "frag" | "opt" ipopts .
optname= ipopts [ "," optname ] .
ipopts= optlist | "sec-class" .
icmp-type= "unreach" | "echo" | "echorep" | "squench" | "redir" | "timex" | "paramprob" | "timest" | "timestrep" | "inforeq" | "inforep" | "maskreq" | "maskrep" | decnumber .
icmp-code= decumber | "net-unr" | "host-unr" | "proto-unr" | "port-unr" | "needfrag" | "srcfail" | "net-unk" | "host-unk" | "isolate" | "net-prohib" | "host-prohib" | "net-tos" | "host-tos" .
optlist= "nop" | "rr" | "zsu" | "mtup" | "mtur" | "encode" | "ts" | "tr" | "sec" | "lsrr" | "e-sec" | "cipso" | "satid" | "ssrr" | "addext" | "visa" | "imitd" | "eip" | "finn" .
hexnumber= "0" "x" hexstring .
hexstring= hexdigit [ hexstring ] .
decnumber= digit [ decnumber ] .
compare= "=" | "!=" | "<" | ">" | "<=" | ">=" | "eq" | "ne" | "lt" | "gt" | "le" | "ge" .
range= "<<" | "><" .
hexdigit= digit | "a" | "b" | "c" | "d" | "e" | "f" .
digit= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" .
flag= "F" | "S" | "R" | "P" | "A" | "U" .

Diese Syntax ist vereinfacht dargestellt; manche der oben aufgeführten Kombinationen sind von der Software aus verboten, da sie keinen Sinn machen würden wie z.B. TCP-Flags für nicht TCP Pakete.

nach oben

2.2 Beschreibung der Filterregeln

Die "kürzesten" gültigen Regeln sind (momentan) no-ops und sehen so aus:
block in all, pass in all, log out all, count in all
Filterregeln werden der Reihe nach geprüft,wobei die letzte übereinstimmende Regel sozusagen das Schicksal des Paketes bestimmt. (lesen Sie dazu aber die quick-Options weiter unten) Filter werden standardmässig an das Ende der Filterliste des Routers gesetzt, versehen Sie die Regel mit "@n" wird sie als Eintrag an die Stelle "n" in die aktuelle Liste eingefügt.

nach oben

ACTIONS

Die "action" gibt an was mit dem Paket passieren soll wenn es mit dem Rest der Filterregel übereinstimmt. Jede Regel muss eine "action" anthalten. Die folgenden "actions" werden erkannt:

block - zeigt an dass das Paket zum "Fallenlassen" markiert werden soll, in Erwiderung auf das Blocken eines Paketes kann der Filter instruiert werden ein Antwort-Paket, entweder ein ICMP Paket ("return-icmp"),ein ICMP Paket welches sich ausgibt als wäre es ein Paket von der Zieladresse des ursprünglichen Paketes ("return-icmp-as-dest"),oder ein TCP "reset" ("returnrst"). Ein ICMP Paket kann als Antwort für jedes IP Paket generiert werden und sein Typ kann optional spezifiziert werden, aber ein TCP-Reset darf nur mit einer Regel benutzt werden die sich auf TCP Pakete bezieht. Wenn Sie also "return-icmp" oder "return-icmp-as-dest" benutzen ist es möglich den aktuellen "unerreichbar" Typen zu spezifizieren! (Netzwerk unerreichbar, Port unerreichbar oder sogar administrativ verboten) Dieses erreicht man indem man den dazugehörigen ICMP Code in Klammern direkt hinter "return-icmp" oder "return-icmp-as-dest" setzt.
block return-icmp(11) ,würde einen Type-of-Service (TOS) ICMP unerreichbar Fehler ausgeben!

pass - würde das Paket markieren, sodass es durch den Filter gelangt!

log - veranlasst dass das Paket geloggt (protokolliert) (wie in der Protokoll-Sektion weiter unten beschrieben),hat aber keinen Einfluss darauf ob das Paket durch den Filter darf oder nicht!

count - veranlasst dass das Paket in die Accounting Statistik des Filters übernommen wird und hat auch keinen Einfluss darauf ob das Paket durch den Filter darf oder nicht! Diese Accounting Statistik ist abrufbar mit dem Telnet Kommando "ipf view"

skip <n> - veranlasst den Filter die nächsten "n" Filterregeln zu überspringen. Wenn eine Regel gelöscht oder hinzugefügt wird (innerhalb des skip-Bereiches) wird der Wert von "n" dementsprechend angepasst!
Das nächste Wort muss entweder "in" oder "out" sein. Jedes Paket das durch den Kernel geht ist entweder einlaufend (gerade von einem Interface empfangen,auf dem Weg in Richtung Protokoll- Verarbeitung) oder auslaufend (durchgestellt oder weitergeleitet vom Stack und auf dem Weg zu einem Interface). Es wird vorrausgesetzt das jede Filterregel ausdrücklich angibt für welche Seite (Ein - oder Ausgabe) sie bestimmt ist!

nach oben

OPTIONS

Die Liste der "options" ist kurz und diese sind in der Tat alle optional. Wenn "options" benutzt werden sollen müssen Sie in der folgenden Reihenfolge angewandt werden. Hier nun die momentan unterstützten "options":

log - zeigt an, dass sollte dieses die letzte übereinstimmende Regel sein, der Paket Header in das Filter Log geschrieben wird (Wie beschrieben in der Logging-Sektion weiter unten)

quick - erlaubt "short-cut" Regeln um den Filterprozess zu beschleunigen oder spätere Regeln zu übergehen. Wenn ein Paket mit einer Filterregel übereinstimmt, die als "quick" markiert ist, ist dies die letzte Regel die überprüft wird. Dieses erlaubt sozusagen einen kürzeren Weg ,wobei die Abarbeitung weiterer Regeln für dieses Paket verhindert wird.
Der aktuelle Status des Pakets (nach der Beeinflussung durch die aktuelle Regel) entscheidet ob das Paket durchgeht oder geblockt wird!
Wenn diese Option fehlt wird die Regel als eine "fall-through" ("fallen lass") Regel betrachtet. Das heisst, das Ergebnis der Übereinstimmung (block/pass) wird gespeichert und die Verarbeitung geht weiter um eventuelle weitere Übereinstimmungen zu finden.

on - erlaubt es einen Interface Namen in die Übereinstimmungs-Prozedur einzubeziehen. Wenn diese Option benutzt wird ,wird die Regel nur übereinstimmen wenn das Paket in die spezifizierte Richtung (in/out) über dieses Interface geht. Wenn diese Option fehlt wird die Regel auf jedes Paket angewandt, unabhänging vom jeweiligen Interface. Filterregel Sets sind gleich für alle Interfaces , anstatt eine Filterliste für jedes einzelne Interface zu haben. Diese Option ist besonders nützlich für einfachen IP-Spoofing Schutz: Es sollten nur eingehende Pakete auf das Interface durchgelassen werden , von denen die spezifizierte Quell-Adresse bekannt ist, andere sollten geloggt (protokolliert) und/oder fallengelassen werden.

dup-to - bewirkt, dass das Paket kopiert wird und das duplizierte Paket über das spezifizierte Interface herausgeschickt wird, optional zu einer zusätzlich spezifizierten Ziel IP-Adresse. Dieses ist nützlich für off-host logging mit einem Netzwerk Sniffer.

nach oben

MATCHING PARAMETERS

Die Keyworte die in diesem Abschnitt beschrieben werden, werden benutzt um Attribute eines Pakets zu beschreiben, die benötigt werden um festzustellen ob Regeln übereinstimmen oder nicht! Die folgenden Attribute dienen der Übereinstimmung und müssen in dieser Reihenfolge benutzt werden:

tos - Pakete mit verschiedenen Type-of-Service Werten können gefiltert werden. Darüber hinaus können individuelle Service Level oder Kombinationen gefiltert werden. Der Wert für die TOS Maske kann entweder als Hex-Nummer oder als ein dezimaler Integer Wert dargestellt werden.
ttl - Pakete können auch nach ihrem Time-to-Live Wert selektiert werden. Der Wert in der Filterregel muss exakt übereinstimmen mit dem Wert in dem Paket , damit eine Übereinstimmung zustande kommt. Dieser Wert kann nur als dezimaler Integer Wert angegeben werden.
proto - erlaubt, dass spezifische Protokolle gegeneinander geprüft werden. Alle Protokoll Namen die Sie in \fB/etc/protocols\fP finden werden erkannt und können benutzt werden. Wie auch immer.. das Protokoll kann auch als dezimal Nummer angegeben werden um es Regeln zu ermöglichen Ihre eigenen Protokolle, oder neuere Protokolle übereinstimmen zu lassen. Das Spezielle Protokoll Keywort "TCP/UDP" kann benutzt werden um entweder ein TCP oder ein UDP Paket überprüfen/übereinstimmen zu lassen, und wurde aus Bequemlichkeit hinzugefügt um sich das Duplizieren von gegebenenfalls identischen Regeln zu sparen.

Die Keyworte " from" und "to" werden benutzt um IP Adressen (und optional Port Nummern) gegeneinander zu prüfen. Die Regeln müssen beide also Quell und Ziel Parameter spezifizieren!

IP Adressen können in einem von 2 Wegen angegeben werden: als eine numerische Adress "/" Maske, oder als eine Hostname "mask" Netzmaske. Der Hostname kann entweder ein gültiger Hostname sein (entweder aus dem host-File oder DNS (abhänging von Ihrer Konfiguration)) oder einer numerischen Adresse (separiert mit Punkten).
Es gibt keine bestimmte Kennzeichnung bei Netzwerken aber Network Names werden erkannt.
Bemerkung: wenn Sie ihre Filterregeln abhängig von DNS machen, könnte dieses die Türen für einen Angriff von außen öffnen.

Es gibt einen bestimmten Fall für den Hostnamen "any" der auf 0.0.0.0/0 gesetzt ist (lesen Sie weiter unten mehr über die Masken Syntax) und alle IP Adressen abdeckt! Nur "any" hat eine Maske mit inbegriffen, in allen anderen Fällen wird ein Hostname immer von einer Maske begleitet. Es ist möglich "any" eine Hostmaske zuzuweisen,aber in diesem Zusammenhang macht dies keinen Sinn.

Das numerische Format " x'/'y " zeigt an, dass eine Maske von y aufeinanderfolgenden Bits generiert wird, angefangen mit dem MSB , sodass ein y-Wert von 16 "0xffff0000" ergeben würde. Die symbolische "x `mask` y" zeigt an, dass die Maske y in punktierter IP Darstellung oder als Hexadezimale Nummer in der Form von 0x12345678 ist. Denken Sie daran ,das alle Bits der IP Adresse vorgegeben durch die Bit Maske mit der Adresse des Paketes exakt übereinstimmen müssen. Es gibt momentan keinen Weg die Richtung der Übereinstimmung umzukehren,oder ganze IP Adressbereiche überprüfen zu lassen, sofern diese sich nicht selbst als Bit Masken identifizieren!

Wenn eine "port" Übereinstimmung hinzugefügt wird für jeweils entweder Quelle und Ziel ,so gilt dies bloss für TCP und UDP Pakete.

Wenn kein "proto" Übereinstimmungs-Parameter angegeben wurde, werden die Pakete beider Protokolle verglichen. Dieses ist äquivalent zu "proto tcp/udp". Wenn Sie Port-Vergleiche zusammenstellen können Sie entweder den Service Namen oder eine integre Port Nummer angeben. Port Vergleiche können in einer Anzahl von Formularen, mit einer Anzahl von Vergleichs-Operatoren,oder ganzen Port-Bereichen spezifiziert werden.
Wenn ein Port als Teil eines "from" Objektes auftritt, wird er verglichen mit der Quell- Portnummer! Wenn ein Port als Teil eines "to" Objektes auftritt, wird er verglichen mit der Ziel- Portnummer! Sehen Sie sich die Beispiele für nähere Informationen an.

Das "all" Keywort ist im Wesentlichen ein Synonym für "von any zu any" mit keinen anderen Übereinstimmungs-Parametern!

Folgend auf die Quell und Ziel Vergleichsparameter können zusätzliche Parameter verwendet werden:

with wird benutzt um unregelmässige Attribute ,die manchen Paketen anhängen , zu vergleichen. Um die generelle Präsenz von IP Optionen zu vergleichen, benutzen Sie "with ipopts". Um Pakete zu vergleichen die zu kurz sind um einen kompletten Header enthalten zu können , benutzen Sie "with short". Um fragmentierte Pakete zu vergleichen, benutzen Sie bitte "with frag". Für noch spezielleres Filtern von IP Optionen, können individuelle Optionen gelistet werden.
Vor einem Parameter (angegeben nach dem "with" Keywort") , können Sie noch das Wort "not" oder "no" einfügen, um die Filter Regel dazu zubringen nur Übereinzustimmen wenn die Option(en) nicht präsent sind.
Mehrere aufeinanderfolgende "with" Klauseln sind erlaubt. Alternativ können Sie das Keywort "and" benutzen anstelle von "with", dieses dient einfach nur dazu die Regeln übersichtlicher zu machen ("with... and ..."). Wenn mehrere Klauseln erstellt wurden müssen alle diese verglichen werden ,um eine Übereinstimmung der Regel zu erzielen!

flags ist nur effektiv bei IP Filtern. Jeder der möglichen Buchstaben steht für eins der möglichen Flags, die in einem TCP Header gesetzt werden können. Hier die Beispiele:
F - Fin
S - Syn
R - Rst
P - Push
A - Ack
U - Urg
Die verschiedenen Flags können in Kombination benutzt werden, sodass z.B. "SA" für eine Syn- Ack Kombination eines Pakets darstellt. Es gibt nichts was gegen eine Spezifikation von Kombinationen wie z.B: "SFR" spricht, welches normalerweise nicht benutzt werden würde bei "gesetzestreuen" TCP Implementationen. Wie auch immer, um sich gegen merkwürdige Abweichungen zu schützen, ist es notwendig anzugeben, gegen welche Flags man filtern möchte. Um dieses zu erlauben ist es möglich eine Maske zu setzen, die angibt welche TCP Flags zu vergleichen sind (also die von denen Sie denken dass sie signifikant sind). Dieses erreicht man durch Anfügen von "/<flags>" zu dem Set von TCP Flags die Sie überprüfen lassen möchten!

Beispiele:

... flags S
# wird "flags S/AUPRFS" und überprüft Pakete bei denen nur das SYN Flag gesetzt ist

... flags SA
# wird "flags SA/AUPRFS" und überprüft sämtliche Pakete bei denen das SYN und ACK Flag gesetzt ist

... flags S/SA
# überprüft jedes Paket bei dem nur das SYN Flag gesetzt ist aus einem SYN-ACK Paar ; die übliche "establish" Keywort "Action". S/SA überprüft nicht Pakete bei denen beides (SYN-ACK) gesetzt ist,dafür aber überprüft dieses "SFP"

icmp-type ist nur effektiv in Verbindung mit "proto icmp" und muss nicht im Zusammenhang mit "flags" benutzt werden. Es gibt eine Anzahl von "Types" auf die verwiesen werden kann durch eine Abkürzung, die von dieser Sprache erkannt wird,oder die Nummern denen diese zugeordnet sind , können benutzt werden. Das Allerwichtigste aus der Sicht der Sicherheit ist das ICMP redirect.

nach oben

KEEP HISTORY

Das zweitletzte Parameter das für eine Filterregel gesetzt werden kann ist, ob eine wichtige Information für ein Paket gespeichert werden soll oder nicht, und welche behalten werden sollen. Folgenden Informationen können behalten werden:

state behält Informationen über den Datenfluss einer Kommunikations-Session. State kann angewandt werden für TCP,UDP und ICMP Pakete.

frags behält Informationen über fragmentierte Pakete um sie auf spätere Pakete zu übertragen.

nach oben

GROUPS

Standardmässig sind alle Filter Regeln in Gruppe 0, sofern keine andere Gruppe angegeben wurde. Um eine Regel einer anderen Gruppe zuzufügen , muss diese erst erstellt werden durch Vergabe eines sogenannten "Group - "head"". Wenn ein Paket verglichen wird mit einer Regel die der "head" einer Gruppe ist , geht der Filtervergleichsprozess in dieser Gruppe weiter, mit dieser Regel als Standard für diese Gruppe.
Bemerkung: wenn "quick" verwendet wird zusammen mit einer "head" Regel, wird die Abarbeitung solange nicht gestoppt bis die Gruppe vollständig abgearbeitet wurde.
Eine Regel kann beides sein, sowohl ein "head" einer neuen Gruppe aber auch Bestandteil einer nicht-standard-Gruppe. ("head" und "group" können in einer Regel zusammen benutzt werden)

head <n> zeigt an, dass eine neue Gruppe (Nummer "n") erzeugt werden soll

group <n> zeigt an, dass die Regel in Gruppe Nummer "n" soll, und nicht in Gruppe 0

nach oben

LOGGING

Wenn ein Paket entweder mit der "log" Action oder Option protokolliert wird, werden die Header des Paketes in den Paketbeinhalteten "Log-Speicher" geschrieben. Benutzen Sie das "log" Keywort, können Sie die folgenden Parameter mit angeben (in dieser Reihenfolge..):

body – gibt an das die ersten 128 Bytes des Paketinhaltes nach den Headern protokolliert werden

first – Wenn log in Verbindung mit einer "keep" Option benutzt wird empfiehlt es sich ,das diese Funktion (first) auch angewandt wird damit nur das "Trigger"-Paket protokolliert wird, und nicht jedes darauffolgende Paket was mit der "state" Information übereinstimmt!

nach oben

BEISPIELE:

Die "quick" Option ist gut für Regeln wie:

block in quick from any to any with ipopts

dieses Überprüft jedes Paket mit einer nicht standard Header-Länge (IP Optionen präsent) und bricht die weitere Verarbeitung von späteren Regeln ab, speichert eine Übereinstimmung und auch dass das Paket geblockt werden soll!

Die "fall-through" Regel Satzgliederung erlaubt Dinge wie diese:

block in from any to any port < 6000
pass in from any to any port >= 6000
block in from any to any port > 6003

(der Bereich 6000-6003 wird geöffnet, alle Anderen verweigert)

Bemerkung – Die Wirkung der ersten Regel wird beeinflusst/aufgehoben, von den folgenden Regeln.

Ein anderer (einfacherer) Weg dieses zu tun ist:

block in from any to any port 6000 <> 6003
pass in from any to any port 5999 >< 6004

Bedenken Sie dass beide (sowohl "block” als auch "pass”) in diesem Fall benötigt werden um ein Resultat zu bewirken, da eine "failed" Übereinstimmung auf die "block" Funktion nicht unbedingt einen Durchlauf bedeutet, sondern nur das die Regel nicht wirksam gewesen ist.

Um dann Ports < 1024 zu erlauben wäre eine Regel wie:

pass in quick from any to any port < 1024

vor dem ersten "block” zu setzen.

Um eine neue Gruppe für ein "LAN/ISP/DIAL IN",mit dem Ziel alle internen Pakete zu blocken, zu erstellen gehen Sie folgendermassen vor:

block in all
block in quick on lan all head 100
block in quick on isp all head 200
block in quick on dialin all head 300

und um nun ICMP Pakete im LAN durchgehen zu lassen kommt dazu:

pass in proto icmp all group 100

Weil nur "inbound” Pakete im LAN durch die Gruppe 100 bearbeitet werden ,müssen Sie den Interface Namen nicht noch einmal Spezifizieren. Ebenfalls können Sie weiteres Breakup- Processing von TCP, etc. folgendermassen bewirken:

block in proto tcp all head 110 group 100
pass in from any to any port = 23 group 110

und so weiter..

Die letzte Zeile (ohne die Gruppen) würde sein:

pass in on lan proto tcp from any to any port = telnet

Wenn Sie "port = telnet” sagen wollen , müsste "proto tcp” spezifiziert werden, da der Parser jede Regel für sich selbst interpretiert und alle Service/Port Namen mit dem spezifizierten Protokoll kennzeichnet.

nach oben

3. Operationen den IP Filters

Alle IP Filter Operationen werden über Telnet an den Router weitergegeben. Drei Haupt- Kommandos sind unterstützt:
ipf – verändert Paket Filterlisten für IP Paket input und output
ipf view – liest die akkumulierten Statistiken die gesammelt wurden in der Zeit während Pakete durch den Filter gingen aus,und zeigt diese an.
log – zeigt die protokollierten Filterpakete ,die PPP/MP Logs und die ISDN D-Kanal Protokolle in einem für Menschen verständlichen Format!

nach oben

3.1 Das ipf Kommando

Benutzung:

Ipf [ -ADEInorstVzZ] [-l block/pass/nomatch] [-F i/o/a/s/S] [-f rule]

-A Setzt die Liste um Änderungen der aktiven Liste zuzufügen
-D deaktiviert den Filter (falls aktiviert)
-E aktiviert den Filter (falls deaktiviert)
-I Setzt die Liste um Änderungen in der inaktiven Liste zuzufügen
-n Dieses Flag (no-change) verhindert das ipf etwas an der aktuell laufenden Konfiguration ändert!
-o Bewegt die Regeln standardmässig zur Output Liste hinzuzufügen/zu entfernen, anstatt dies in der Input Liste zu tun.
-r Entferne Übereinstimmungs Filterregeln anstatt sie zur internen Liste hinzuzufügen
-s tauschen der "aktiven" Filterliste gegen die Zweite (Andere)
-t Anzeige bis zum Ende (deaktivieren der "more" Funktion im Telnet)
-V Zeige Version IP Filter Information,Informationen über seinen aktuellen Status werden auch angezeigt (ob Logging etc. aktiv ist)
-z Setzte die Statistiken für jede Regel im Input File auf 0 und zeige die letzten Statistiken bevor sie "genullt" wurden.
-Z Setze alle "globalen" Statistiken im Kernel auf 0 (Nur für die Filterstatistiken) (dieses betrifft nicht die Fragment und State – Statistiken)
-l Schalte das standardmässige Loggen der Pakete ein oder aus. Gültige Parameter dieser Option sind "pass","block" und "nomatch". Alle anderen Parameter bewirken dass das Logging deaktiviert wird. Wenn eine gültige Option gesetzt wird, wird jedes Paket protokolliert,dass durch den Filter kommt und irgendwelche Übereinstimmungen mit der Set Kategorie hatte. Dieses ist am nützlichsten, um sämtliche Pakete zu protokollieren , die nicht mit einer der geladenen Regeln übereinstimmen.
-F Diese Option gibt an ,welche der Filterlisten geleert werden sollen. Das Parameter sollte entweder "i" (input),"o" (output) oder "a" (entfernen aller Filterregeln) sein
-F s Entfernt Status Informationen über alle nicht vollständig zustande gekommenen Verbindungen
-F S Löscht die gesamte Status Tabelle. Eine voll zustande gekommene Funktion erscheint in der "ipf view –s" Ausgabe als 4/4
-f setzt die Filterregel (geben Sie "ipf rule ?" ein für Beispiele)

nach oben

3.2 Das ipf view Kommando

Die Aufgabe von "ipf view" ist die Anzeige aktueller Kernel Statistiken . Diese entnimmt das Kommando aus den Filtern & über ein und ausgehende Pakete.
"ipf view" ist das Standardkommando, wenn keine weiteren Parameter angegeben werden.
Geben Sie zusätzlich "-i" oder "-o" ein, wird es die dementsprechende Liste der Filterregeln Auslesen und anzeigen.

Benutzung:

ipf view [-afhinostz] [-g <group>] [-l <line>]

-a Zeigt die Accounting Filterliste und zeigt Bytes die gegen eine Regel gezählt wurden
-f Zeigt fragment-Status Information (Statistik) und gespeicherte "state" Informationen, sofern es welche geben.
-h Zeigt die Nummer der "Treffer" pro angewandter Regel. . Zu benutzen im Zusammenhang mit "-i"
-i Zeigt die Filterliste für die Input (eingangs) Seite des Routers
-n Zeigt das inaktive Filterset
-o Zeigt die Filterliste für die Output (ausgangs) Seite des Routers
-s Zeigt die Paket/Fluss "state" Information (Statistik)
-t Anzeige bis zum Ende (deaktivieren der "more" Funktion im Telnet)
-z Löscht die Statistik nach diesem Kommando
-g <group> Gibt die Gruppennummer an (group)
-l <line> Gibt die Position einer Regel innerhalb einer Liste/Gruppe an.

nach oben

3.3 Das log Kommando

Es sind 4 Ring-Puffer im Router, um 4 verschiedene Datentypen zu protokollieren:
Wan Log – protokolliert ISDN D-Kanal Protokolle genauso wie PPP Protokolle
Call Log – Speichert das Zustandekommen einer Verbindung
Filter Log – Speichert Pakete die mit der Filter Regel übereinstimmen,genauso wie das "ipf –l" Kommando.
State Log – Speichert den IP Paket Status (state) übereinstimmend mit der "keep state" Filterregel

Das Wan Log und das Call Log sind immer aktiviert. Sollte der Puffer einmal voll sein, wird das älteste protokollierte Datensegment automatisch überschrieben.

Benutzung:

log [-cfhipstwx?][-F a/c/f/s/w]

-c Zeigt das Call Log an
-f Zeigt das Filter Log
-F Löscht die Log-Puffer
   a Löscht alle Logs
   c Löscht das Call Log
   f Löscht das Filter Log
   s Löscht das "state" Log
   w Löscht das Wan (ISDN & PPP) Log
-h für diese Benutzerhilfe
-i Zeigt den ISDN D-Kanal Part des Wan Logs
-p Zeigt den PPP/MP Part des Wan Logs
-s Zeigt das "state" Log
-t Anzeige bis zum Ende (deaktivieren der "more" Funktion im Telnet)
-w Zeigt das Wan Log (ISDN & PPP)
-x für einen Paket Hex-Dump, falls vorhanden

nach oben

Text mit freundlicher Genehmigung von 2-com.de (Copyright © 2000 TwoCom)
Überarbeitung und HTML-Umsetzung von deMattin

- deMattin -



© 2001 www.vigor-users.de