8.5 Arbeit mit dem Paketfilter

8.5.1 Hinzufügen von eigenen Ketten und Regeln

Zur Manipulation des Paketfilters steht eine Reihe von Routinen zur Verfügung, mit deren Hilfe man Ketten (engl. "`Chains"') und Regeln hinzufügen und wieder löschen kann. Eine Kette ist eine benannte und geordnete Liste von Regeln. Es gibt einen Satz vordefinierter Ketten (PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING); mit Hilfe dieser Funktionen können weitere Ketten nach Bedarf erstellt werden.

add_chain/add_nat_chain <chain>:

Fügt eine Kette zur "`filter"'- oder "`nat"'-Tabelle hinzu.

flush_chain/flush_nat_chain <chain>:

Entfernt alle Regeln aus einer Kette der "`filter"'- oder "`nat"'-Tabelle.

del_chain/del_nat_chain <chain>:

Entfernt eine Kette aus der "`filter"'- oder "`nat"'-Tabelle. Ketten müssen leer sein, bevor sie gelöscht werden können, und es darf auch keine Referenz mehr auf sie geben. Eine solche Referenz ist z.B. eine JUMP-Aktion, deren Ziel eben diese Kette ist.

add_rule/ins_rule/del_rule:

Fügt Regeln am Ende einer Kette (add_rule) bzw. an beliebiger Stelle in einer Kette (ins_rule) ein bzw. löscht Regeln aus einer Kette (del_rule). Ein Aufruf sieht wie folgt aus:

    add_rule <table> <chain> <rule> <comment>
    ins_rule <table> <chain> <rule> <position> <comment>
    del_rule <table> <chain> <rule> <comment>

wobei die Parameter folgende Bedeutung haben:

table: Die Tabelle, in der sich die Kette befindet
chain: Die Kette, in welche die Regel eingefügt werden soll
rule: Die Regel, die eingefügt werden soll; das Format entspricht dem in der Konfigurationsdatei verwendeten
position: Die Position, an der die Regel eingefügt werden soll (nur bei ins_rule)
comment: Ein Kommentar, der zusammen mit der Regel angezeigt werden soll, wenn sich jemand den Paketfilter ansieht.

8.5.2 Einordnen in bestehende Regeln

fli4l konfiguriert den Paketfilter mit einem gewissen Standardregelsatz. Will man eigene Regeln einfügen, wird man diese in der Regel nach dem Standardregelsatz einfügen wollen. Ebenfalls wird man wissen wollen, was denn die vom Nutzer gewünschte Aktion beim Verwerfen eines Paketes ist. Diese Informationen bekommt man für die FORWARD- und INPUT-Ketten durch Aufruf zweier Funktionen, get_defaults und get_count. Nach Aufruf von

    get_defaults <chain>

erhält man die folgenden Ergebnisse:

drop:: Diese Variable enthält die Kette, in die verzweigt wird, wenn ein Paket verworfen wird.
reject:: Diese Variable enthält die Kette, in die verzweigt wird, wenn ein Paket abgelehnt wird.

Nach Aufruf von

    get_count <chain>

erhält man in der Variable res die Anzahl der Regeln in der Kette <chain>. Diese Position ist insofern wichtig, als man nicht einfach add_rule verwenden kann, um eine Regel am Ende der vordefinierten "`filter"'-Ketten INPUT, FORWARD und OUTPUT einzufügen. Dies liegt daran, dass diese Ketten mit einer Standardregel abgeschlossen werden, welche alle verbliebenen Pakete behandelt, je nach Belegung der PF_<Kette>_POLICY-Variablen. Ein Einfügen hinter dieser letzten Regel hat also keine Auswirkungen. Die Funktion get_count erlaubt es nun hingegen, die Stelle direkt vor dieser letzten Regel zu ermitteln und die Position dann an die ins_rule-Funktion im Parameter <position> zu übergeben, um die Regel wie gewünscht am Ende der jeweiligen Kette, aber vor der letzten Auffang-Regel einzubauen.

Ein Beispiel aus dem Skript opt/etc/rc.d/rc390.dns_dhcp des Pakets "`dns_dhcp"' soll dies verdeutlichen:

    case $OPT_DHCPRELAY in
        yes)
            begin_script DHCRELAY "starting dhcprelay ..."

            idx=1
            interfaces=""
            while [ $idx -le $DHCPRELAY_IF_N ]
            do
                eval iface='$DHCPRELAY_IF_'$idx

                get_count INPUT
                ins_rule filter INPUT "prot:udp  if:$iface:any 68 67 ACCEPT" \
                    $res "dhcprelay access"

                interfaces=$interfaces' -i '$iface
                idx=`expr $idx + 1`
            done
            dhcrelay $interfaces $DHCPRELAY_SERVER

            end_script
        ;;
  esac

Hier sieht man inmitten der Schleife einen Aufruf von get_count, gefolgt von einem Aufruf der ins_rule-Funktion, der unter anderem die res-Variable als position-Parameter übergeben wird.

8.5.3 Erweiterung der Paketfilter-Tests

fli4l verwendet in den Paketfilterregeln die Syntax match:params, um zusätzliche Bedingungen an die Pakete zu stellen (siehe mac:, limit:, length:, prot:, ...). Will man zusätzliche Tests hinzufügen, wird das folgendermaßen gemacht:

Festlegen eines passenden Namens. Dieser Name muss mit einem Kleinbuchstaben im Bereich a-z beginnen und ansonsten aus beliebigen Buchstaben und Ziffern bestehen.

Wenn der Paketfilter-Test in IPv6-Regeln verwendet werden soll, dann muss darauf geachtet werden, dass der Name keine gültige IPv6-Adresskomponente ist!

Anlegen einer Datei opt/etc/rc.d/fwrules-<name>.ext. In dieser Datei steht in etwa Folgendes:

    # IPv4 extension is available
    foo_p=yes

    # the actual IPv4 extension, adding matches to match_opt
    do_foo()
    {
        param=$1
        get_negation $param
        match_opt="$match_opt -m foo $neg_opt --fooval $param"
    }

    # IPv6 extension is available
    foo6_p=yes

    # the actual IPv6 extension, adding matches to match_opt
    do6_foo()
    {
        param=$1
        get_negation6 $param
        match_opt="$match_opt -m foo $neg_opt --fooval $param"
    }

Der Paketfilter-Test muss nicht zwingend sowohl für IPv4 als auch für IPv6 implementiert sein (obwohl dies zu bevorzugen ist, falls er für beide Layer-3-Protokolle sinnvoll ist).

Testen der Erweiterung:

    $ cd opt/etc/rc.d
    $ sh test-rules.sh 'foo:bar ACCEPT'
    add_rule filter FORWARD 'foo:bar ACCEPT'
    iptables -t filter -A FORWARD -m foo --fooval bar -s 0.0.0.0/0 \
        -d 0.0.0.0/0 -m comment --comment foo:bar ACCEPT -j ACCEPT

Aufnahme der Erweiterung und aller noch benötigten Dateien (iptables-Komponenten) ins Archiv über einen der bekannten Mechanismen.
Zulassen der Erweiterung in der Konfiguration durch Erweitern von FW_GENERIC_MATCH und/oder FW_GENERIC_MATCH6 in einer exp-Datei, z.B. wie folgt:
```
    +FW_GENERIC_MATCH(OPT_FOO) = 'foo:bar' : ''
    +FW_GENERIC_MATCH6(OPT_FOO) = 'foo:bar' : ''
```