4.14 Neue Konfiguration des Paketfilters

Unterabschnitte

- 4.14.1 Aktionen des Paketfilters
- 4.14.2 Einschränkungen in den Regeln
  - 4.14.2.1 Einschränkungen der Quelle und des Ziels
  - 4.14.2.2 Einschränkung des Interfaces
  - 4.14.2.3 Einschränkungen des Protokolls
  - 4.14.2.4 Einschränkung der MAC-Adresse
  - 4.14.2.5 Einschränkungen basierend auf dem Zustand eines Paketes
  - 4.14.2.6 Einschränkung der Häufigkeit einer Aktion
- 4.14.3 Der Einsatz von Templates im Paketfilter
- 4.14.4 Die Konfiguration des Paketfilters
  - 4.14.4.1 Die Input-Liste
  - 4.14.4.2 Die Forward-Liste
  - 4.14.4.3 Die NAT-Listen (network address translation)
- 4.14.5 Beispiele
  - 4.14.5.1 Die Fli4l-Standardkonfiguration
  - 4.14.5.2 Trusted Nets
  - 4.14.5.3 Route Network
  - 4.14.5.4 Blacklists, Whitelists
- 4.14.6 Standardkonfigurationen
  - 4.14.6.1 Einfacher maskierender Router mit einem Netz dahinter
  - 4.14.6.2 Einfacher maskierender Router mit zwei Netzen dahinter
  - 4.14.6.3 Maskierender DSL-Router mit zwei Netzen dahinter und ssh/http-Zugriff aus dem Internet
  - 4.14.6.4 Portforwarding
  - 4.14.6.5 Transparent Proxy
- 4.14.7 DMZ - Demilitarisierte Zone
  - 4.14.7.1 Kommunikation zwischen Grün und Rot
  - 4.14.7.2 Kommunikation zwischen Grün und Orange
  - 4.14.7.3 Kommunikation zwischen Rot und Orange
  - 4.14.7.4 Kommunikation zwischen Orange und dem Router
  - 4.14.7.5 Konfiguration der DMZ
- 4.14.8 Port-Forwarding
- 4.14.9 Masquerading Module

# 4.14 Neue Konfiguration des Paketfilters

Seit geraumer Zeit steht eine neue Möglichkeit zur Verfügung, den Paketfilter zu konfigurieren. Diese ist seit 2.1.8 die Standardkonfiguration. Die originale Konfiguration existiert immer noch, muß aber separat aktiviert werden.

Mit der neuen Paketfilterkonfiguration lassen sich die einzelnen Tabellen des Paketfilters direkt konfigurieren. Dazu gibt es für jede relevante Tabelle eine eigene Liste, d.h. eine für die Input-Tabelle (INPUT_LIST_x), eine für die Forwarding-Tabelle (FORWARD_LIST_x) und eine für die Postrouting-Tabelle, in der das Masqerading gemacht wird (POSTROUTING_LIST_x). Für die Prerouting-Tabelle gibt es momentan zwei Konfigurationsmöglichkeiten, die gleichzeitig genutzt werden können. Die bereits bekannte Portforwarding-Konfiguration über PORTFW_x und die PREROUTING_LIST_x.

Ein Eintrag in einer dieser Listen, ausgenommen Pre-Routing, besteht im wesentlichen aus einer Aktion (ACCEPT, DROP, REJECT, SNAT oder MASQUERADE), die durch zusätzliche Bedingungen eingeschränkt werden kann. Diese Bedingungen beziehen sich auf Eigenschaften des betrachteten Paketes. Ein Paket enthält Informationen über seine Herkunft (Quelle, welcher Rechner hat das Paket losgeschickt), sein Ziel (an welchen Rechner und welche Anwendung soll das Paket gehen) u.a.m.. Bedingungen können sich auf folgende Eigenschaften eines Paketes beziehen:

- die Quelle (Quell-IP, Quell-Port oder beides)
- das Ziel (Ziel-IP, Ziel-Port oder beides)
- das Protokoll
- das Interface, über welches das Paket reinkommt bzw. rausgeht
- die Mac-Adresse des Rechners, von dem das Paket kommt
- den Zustand des Paketes bzw. der Verbindung, zu der das Paket gehört

Kommt ein Paket rein, werden die Einträge bzw. die daraus generierten Regeln von oben nach unten abgearbeitet und die erste Aktion ausgeführt, bei der alle Bedingungen gelten. Trifft keine der Regeln zu, wird die Standardreaktion ausgeführt, die man für (fast) jede Tabelle angeben kann.

Ein Eintrag hat dabei folgendes Format, wobei zu beachten ist, daß alle Einschränkungen optional sind:

    restriction{0,} [[source] [destination]] action [BIDIRECTIONAL|LOG|NOLOG]

##
4.14.1 Aktionen des Paketfilters

Aktionen können die folgenden sein:

ACCEPT
  Akzeptiere das Paket
DROP
  Verwerfe das Paket (der Absender erkennt das nur daran, daß keine Antwort, aber auch keine Fehlermeldung zurückkommt)
REJECT
  Weise das Paket zurück (der Absender enthält eine entsprechende Fehlermeldung)
LOG
  Logge das Paket und gehe zur nächsten Regel. Um verschiedene Log-Statements auseinanderhalten zu können, können Log-Prefixes verwendet werden. Diese werden via LOG:log-prefix angegeben.
MASQUERADE
  Maskiere das Paket (ersetze die Absender-IP des Paketes durch die eigene, bei der Einwahl dem Interface zugewiesene Adresse und sorge dafür, daß Antworten für diese Verbindung an den richtigen Rechner weitergeleitet werden; diese Aktion ist nur in der POSTROUTING_LIST möglich)
SNAT
  Ersetze die Absender-IP des Paketes durch die als Parameter für SNAT angegebene statische IP (für alle Pakete die zu der gerade betrachteten Verbindung gehören; diese Aktion ist nur in der POSTROUTING_LIST möglich)
NETMAP
  Mappe die Ziel- bzw. Absender-IP des Paketes in den als Parameter für NETMAP angegebenen Bereich, die Ports bleiben unverändert (für alle Pakete die zu der gerade betrachteten Verbindung gehören; diese Aktion ist nur in der PREROUTING_LIST oder POSTROUTING_LIST möglich; in der Preroutinglist wird die Zieladresse verändert, in der Postroutinglist die Quell-Adresse)
DNAT
  Ersetze die Ziel-IP und den Zielport des Paketes durch die als Parameter für DNAT angegebene IP (für alle Pakete, die zu der gerade betrachteten Verbindung gehören; diese Aktion ist nur in der PREROUTING_LIST möglich)
REDIRECT
  Ersetze den Zielport des Paketes durch die als Parameter für REDIRECT angegebenen Port und stelle das Paket lokal zu (für alle Pakete, die zu der gerade betrachteten Verbindung gehören; diese Aktion ist nur in der PREROUTING_LIST möglich)

Einige dieser Aktionen können durch die Optionen BIDIRECTIONAL, LOG oder NOLOG in ihrem Verhalten modifiziert werden. BIDIRECTIONAL generiert die gleiche Regel noch einmal nur mit Quell- und Zieladresse vertauscht. LOG/NOLOG (de)aktivieren das Logging für diese eine Regel.

##
4.14.2 Einschränkungen in den Regeln

Einschränkungen können durch die in den folgenden Abschnitten aufgeführten Bedingungen vorgenommen werden. Bei den Bedingungen kann man immer 'any' angeben, wenn man an irgendeiner Stelle keine Einschränkung vornehmen will, aber trotzdem etwas angeben will/muß. Einschränkungen können in beliebiger Reihenfolge angegeben werden, wenn sie einen vorangestellten Präfix haben. Das gilt für alle außer die Angabe einer Quell- bzw. Zieladresse. Diese müssen immer direkt vor der Aktion stehen, die anderen Einschränkungen müssen vorher erfolgen. Einschränkungen können auch negiert werden, dazu wird einfach ein '!' vorangestellt.

### 4.14.2.1 Einschränkungen der Quelle und des Ziels

Jedes Paket enthält eine Quell- und eine Zielangabe; jeweils in Form eines Tupels einer IP-Adresse und eines Ports. Diese Quelle bzw. dieses Ziel kann für eine Einschränkung herangezogen werden. Die Angabe für die Quelle bzw. das Ziel kann folgendermaßen vorgenommen werden:

ip | eine einfache IP-Adresse
network | eine Netzwerkangabe der Form ip/netmask
port[-port] | ein Port bzw. ein Port-Bereich
IP_NET_x_IPADDR | die IP-Adresse des Interfaces x des Routers
IP_NET_x | das Subnetz x des Routers
IP_ROUTE_x | das in einer Route angegebene Subnetz (default Routen können nicht verwendet werden, sie würden any entsprechen und werden vorsichtshalber ausgeklammert)
name | einer der via HOST_x_* vergebenen Namen oder Aliases; es wird die zugehörige IP-Adresse an dieser Stelle eingesetzt
<ip oder netzwerk>:port[-port] | IP/Netzwerk-Adresse in einer der obigen Varianten spezifiziert kombiniert mit einem Port/Port-Bereich

Das könnte z.B. wie folgt aussehen: '192.168.6.2 any DROP'.

Tauchen zwei dieser Angaben auf, wird die erste als Quelle, die zweite als Ziel betrachtet. In diesem Beispiel verwerfen wir also Pakete, die vom Rechner mit der IP-Adresse 192.168.6.2 gesendet wurden, unabhängig davon, an welches Ziel sie gerichtet sind.

Taucht nur eine Angabe auf, wird anhand des Wertes entschieden, ob die Quelle oder das Ziel gemeint ist, wobei die Entscheidung relativ einfach ist:

- Ist eine Port-Angabe enthalten, ist das Ziel gemeint.
- Sonst ist die Quelle gemeint.

Wenn wir also z.B. das obige Beispiel etwas kürzer schreiben wollen, können wir einfach '192.168.6.2 DROP' schreiben. Es ist kein Port angegeben, die Bedingung gilt also für die Quelle, den Rechner, von dem das Paket gesendet wurde.

Wollen die Kommunikation mit dem sshd erlauben, können wir 'any any:22 ACCEPT' (Pakete von einem beliebigen Rechner an einen beliebigen Rechner auf den sshd-Port 22 werden akzeptiert) oder kürzer '22 ACCEPT' schreiben. Es ist nur ein Port angegeben, also meinen wir das Ziel und damit Pakete, die an den Port 22 gerichtet sind.

Zur Vereinfachung der Regelmenge kann man an die Aktion ein BIDIRECTIONAL dranhängen, um auszudrücken, daß die Regel für beide Kommunikationsrichtungen gilt. Es werden dann Regeln generiert, in denen einfach die Quell- und die Ziel-IP und eventuelle Interfaces vertauscht sind und der Rest gleichbleibt.

Beispiele:

'127.0.0.1 ACCEPT' | Lokale Kommunikation (Quelle 127.0.0.1) ist erlaubt
'any 192.168.12.1 DROP' | Pakete an die IP-Adresse 192.168.12.1 werden weggeworfen
'any 192.168.12.1 DROP LOG' | Pakete an die IP-Adresse 192.168.12.1 werden weggeworfen und zusätzlich gelogged
'any 192.168.12.1 DROP NOLOG' | Pakete an die IP-Adresse 192.168.12.1 werden weggeworfen, werden aber nicht gelogged
'22 ACCEPT' | Pakete an den Port 22 (sshd) werden akzeptiert
'IP_NET_1_NET ACCEPT' | Pakete aus dem am 1. Interface hängenden Subnetz werden akzeptiert
'IP_NET_1_NET IP_NET_2_NET ACCEPT BIDIRECTIONAL' | Kommunikation zwischen dem am ersten und zweiten Interface hängenden Subnetzen ist gestattet

### 4.14.2.2 Einschränkung des Interfaces

Einschränkung des Interfaces, über das das Paket reinkam bzw. rausgeht. Das Format sieht wie folgt aus: if: in: out

In der Input-Liste kann man das rausgehende Interface nicht einschränken (das Paket geht ja nicht mehr raus), in der Masquerade-Liste (Postrouting) kann man das reinkommende Interface nicht einschränken, da die Information darüber nicht mehr vorhanden ist. Lediglich in der Forward-Liste kann man für beides Bedingungen angeben.

Möglich sind folgendes Werte für in bzw. out:

- lo (loopback Interface, lokale Kommunikation auf dem Router)
- eth0 - eth9
- br0 - br9
- circuit_1 - circuit_99
- IP_NET_1_DEV - IP_NET_99_DEV
- pppoe (das pppoe device)
- any

### 4.14.2.3 Einschränkungen des Protokolls

Einschränkung des Protokolls, zu dem dieses Paket gehört. Das Format sieht wie folgt aus: prot: protcol bzw. prot: icmp: icmp-type.

protcol kann dabei eines der folgenden Werte annehmen:

- tcp
- udp
- icmp

  Bei icmp kann man zusätzlich noch einen Namen für den icmp-Typ angeben, z.B. prot:icmp:echo-request.

- numerischer Wert der Protokoll-ID
- any

### 4.14.2.4 Einschränkung der MAC-Adresse

Mittels mac: mac addr kann eine Einschränkung der MAC-Adresse vorgenommen werden.

### 4.14.2.5 Einschränkungen basierend auf dem Zustand eines Paketes

Der von fli4l verwendete Paketfilter sammelt Informationen über den Zustand von Verbindungen. Diese Informationen kann man dann nutzen, um Pakete zu Filtern, also z.B. nur Pakete durchzulassen, die zu bereits bestehenden Verbindungen gehören. Die Zustände einer Verbindung können ein:

INVALID
  Das Paket gehört zu keiner bekannten Verbindung.
ESTABLISHED
  Das Paket gehört zu einer Verbindung, über die bereits in beide Richtungen Pakete geflossen sind.
NEW
  Das Paket hat eine neue Verbindung aufgebaut oder gehört zu einer Verbindung, bei der noch nicht Pakete in beide Richtungen geflossen sind.
RELATED
  Das Paket baut eine neue Verbindung auf, hat aber eine Beziehung zu einer bestehenden Verbindung (z.B. ftp baut eine separate Verbindung für den eigentlich Datentransfer auf).

Für eine genauere Beschreibung der Zustände siehe
http://www.sns.ias.edu/%7Ejns/index.php?pagename=ConnectionTracking.

Die Zustände werden wie folgt angegeben: state: state(s). Will man mehrere Zustände angeben, werden diese mit Komma getrennt. Um z.B. nur Pakete durchzulassen, die zu bestehenden Verbindungen gehören, kann man folgendes schreiben (für input und forwarding): state: ESTABLISHED,RELATED

### 4.14.2.6 Einschränkung der Häufigkeit einer Aktion

Unter bestimmten Umständen möchte man die Häufigkeit von Aktionen begrenzen, z.B. nur einen echo request pro Sekunde zulassen. Das kann man mit der limit Einschränkung erreichen, die wie folgt aussieht: limit: Häufigkeit:Burst. Die Häufigkeit wird dabei als n pro Zeiteinheit (second, minute, hour, day) angegeben wobei zusätzlich noch Ereignisse gehäuft auftreten können (Burst). limit:3/minute:5 heißt z.B. 3 Ereignisse pro Minute, wobei auch mal 5 Ereignisse dicht aufeinander folgend akzeptiert werden.

##
4.14.3 Der Einsatz von Templates im Paketfilter

Um den Umgang mit dem Paketfilter weiter zu vereinfachen gibt es die Möglichkeit häufig vorkommende Regeln zu sogenannten Templates zusammenzufassen. Damit ist es möglich eine ganze Reihe von Paketfilterregeln zusammenzufassen und dieser Sammlung von Regeln einen symbolischen Namen zu geben. Anstatt direkt mit Protokollen und Portnummern arbeiten Sie dann mit Einträgen wie 'tmpl:ssh' wenn Sie mit dem SSH Protokoll arbeiten wollen. Wie mit Templates zu verfahren ist, wird hier am Beispiel von SSH gezeigt.

Wollen Sie Ihren fli4l-Router vom Internet aus per SSH erreichen, so schreiben Sie als Wert in der Variablen INPUT_LIST_x den entsprechenden Dienstnamen mit vorangestelltem tmpl: und der Aktion, die für diesen Dienst gelten soll. Beispiel:

INPUT_LIST_2='tmpl:ssh ACCEPT'

Hierbei steht tmpl: dafür, dass eine Regel aus einem Template erstellt werden soll. Den Namen des Dienstes geben Sie nach dem ':' an. In unserem Beispiel also 'ssh'. Zum Schluss geben Sie an welche Aktion mit dem Dienst verbunden werden soll. Da Sie den fli4l-Router aus dem Internet erreichen wollen erlauben wir die Verbindung mit 'ACCEPT'. Einschränkungen von IP-Adressen oder Netzen sind nicht angegeben, also ist der SSH Dienst von allen Netzen und Interfaces erreichbar. Sie könnten bei Bedarf die gewohnten Schreibenweisen vom Paketfilter benutzen um den Zugriff auf den SSH Dienst weiter einzuschränken.

Für welche Dienste Regeln vorbereitet sind (=Templates existieren) kann in der Template Datei in opt/etc/fwrules.tmpl/templates nachgelesen werden, hier die Aufstellung in Tabellenform (siehe Tabelle 4.5).

Die Syntax fuer diese Form der Paketfilterregeln lautet also immer

tmpl:<Name des Dienstes> <Einschränkungen> <Gewünschte Aktion>

Wobei als <Einschränkungen> alles erlaubt ist was unter 4.14.2 beschrieben wird. Die möglichen Werte für <Gewünschte Aktion> sind in 4.14.1 aufgelistet und beschrieben.

Ein paar weitere Beispiele verdeutlichen die Arbeitsweise. Zuerst gucken wir uns meine PREROUTING_LIST an.

    PREROUTING_LIST_N='2'
    PREROUTING_LIST_1='tmpl:xbl dynamic DNAT:@xbox'
    PREROUTING_LIST_2='tmpl:https dynamic DNAT:192.168.193.250'

Die Regel PREROUTING_LIST_1 versorgt meine Xbox mit allem was für Xbox Live notwendig ist. Im einzelnen wird mit 'tmpl:xbl' alle Ports und Protokolle die für Xbox Live notwendig sind an den Host 'xbox' weitergeleitet. Anstelle der IP-Adresse wird ein Eintrag aus der HOST_x_NAME Liste benutzt. Durch 'dynamic' weiss der fli4l, dass die Ports vom Internetinterface weitergeleitet werden sollen.

Die zweite Regel leitet das https Protokoll an einen Webserver in der DMZ weiter.

Jetzt sehen wir uns an wie es mit den INPUT_LIST weitergeht.

    INPUT_LIST_N='3'
    INPUT_LIST_1='if:IP_NET_1_DEV:any ACCEPT'
    INPUT_LIST_2='if:pppoe:any prot:tcp 113 ACCEPT'
    INPUT_LIST_3='if:br0:any tmpl:dns @xbox 192.168.193.254 ACCEPT'

Die erste Regel läßt alle aus dem Netz das mit IP_NET_1 definiert ist auf den Router zugreifen. Die zweite Regel ist für das oident Paket. Dort wird der ident Port geöffnet. Die dritte und letzte Regel erlaubt der Xbox den Zugriff auf den DNS Server auf dem fli4l. Hier ist auch wieder schon zu sehen wie man einen Hostalias einsetzt. Anstelle der IP-Adresse 192.168.193.254 hätte ich auch IP_NET_1_IPADDR schreiben können.

In meiner FORWARD_LIST und POSTROUTING_LIST steht nichts 'tmpl:' spezifisches mehr.

Abbildung 4.6: Verzeichnisstruktur fli4l

Es ist auch möglich, dass Sie eigene Templates anlegen oder das opt-Pakete ihre eigenen Templates mitbringen. Um ein eigenes Template anzulegen muss lediglich eine Datei mit den Namen des Templates erstellt werden und die entsprechenden Regeln dort aufgenommen werden. Wenn Sie eine private Templatedatei anlegen wollen erstellen Sie in dem Verzeichnis etc/fwrules.tmpl unterhalb Ihres config Verzeichnisses die Templatedatei, so wie es die Abbildung 4.6 zeigt. Wenn das Verzeichnis etc/fwrules.tmpl unterhalb Ihres config Verzeichnisses noch nicht existiert legen Sie bitte zuerst beide Verzeichnisse neu an. Alternativ können opt-Entwickler oder Benutzer die Templates für mehr als eine Konfiguration anlegen wollen Ihre Regeln direkt in das Verzeichnis opt/etc/fwrules.tmpl ablegen. In dieses Verzeichnis kommen dann die neuen Templates. Dabei gilt die Regel, dass die Templates im config Verzeichnis des Benutzers vor den Templates von opt-Paketen kommen. Zum Schluss wird die templates Datei, die zum Lieferumfang von fli4l gehört, ausgewertet. Sie können also Einträge in der fli4l templates Datei dadurch ,,überschreiben`` indem Sie eine Templatedatei mit dem Namen des zu überschreibenden Templates in Ihrem config Verzeichnis anlegen.

Wenn Sie zum Beispiel das Template vpn_freunde anlegen wollen, legen Sie die Datei vpn_freunde an. Das Template soll die Dienste ssh, smtp, dns und samba enthalten. Also schreiben Sie in die Datei vpn_freunde folgendes:

    prot:tcp 22
    prot:tcp 25
    53
    prot:udp 137-138
    prot:tcp 139
    prot:tcp 445

Wann immer Sie jetzt das Template vpn_freunde benutzen, werden daraus Regeln für alle darin aufgeführten Protokolle und Ports erzeugt. Wenn Sie also schreiben FORWARD_LIST_x='tmpl:vpn_freunde ACCEPT' werden daraus folgende Regeln erstellt:

    FORWARD_LIST_x='prot:tcp 22 ACCEPT'
    FORWARD_LIST_x='prot:tcp 25 ACCEPT'
    FORWARD_LIST_x='53 ACCEPT'
    FORWARD_LIST_x='prot:udp 137-138 ACCEPT'
    FORWARD_LIST_x='prot:tcp 139 ACCEPT'
    FORWARD_LIST_x='prot:tcp 445 ACCEPT'

Tabelle 4.5: Die im Lieferumfang von fli4l enthaltenen Templates
Templatename | Protokoll | Port(s)
dhcp | udp | 67-68
dns | tcp/udp | 53
elster | tcp | 159.154.8.2:21
| tcp | 193.109.238.26:8000
| tcp | 193.109.238.27:8000
| tcp | 193.109.238.58:80
| tcp | 193.109.238.59:80
| tcp | 62.157.211.58:8000
| tcp | 62.157.211.59:8000
| tcp | 62.157.211.60:8000
| tcp | 80.146.179.2:80
| tcp | 80.146.179.3:80
ftp | tcp | 21
http | tcp | 80
https | tcp | 443
hylafax | tcp | 4559
imap | tcp | 143
imaps | tcp | 993
imond | tcp | 5000
irc | tcp | 6667
jabber | tcp | 5222-5223
ldap | tcp/udp | 389
mysql | tcp | 3306
nntp | tcp | 119
ntp | udp | 123
pcanywhere | tcp | 5631-5632
pop3 | tcp | 110
pop3s | tcp | 995
rsync | tcp | 873
samba | tcp | 139
| tcp | 445
| udp | 137-138
smtp | tcp | 25
snmp | tcp/udp | 161
socks | tcp | 1080
ssh | tcp | 22
ssmtp | tcp | 465
submission | tcp/udp | 587
svn | tcp | 3690
syslog | udp | 514
teamspeak | tcp | 14534
| tcp | 51234
| udp | 8767
telmond | tcp | 5001
telnet | tcp | 23
vnc | tcp | 5900
xbl | tcp/udp | 3074
| udp | 88

## 4.14.4 Die Konfiguration des Paketfilters

Der Paketfilter im wesentlichen wird über 3 Listen konfiguriert:

- Input-Liste
- Forward-Liste
- Masquerade-Liste

Aktiviert wird die Konfiguration durch NEW_FW_CONFIG='yes'.

### 4.14.4.1 Die Input-Liste

Über die Input-Liste wird konfiguriert, wer auf den Router zugreifen darf. Trifft keine der Regeln der Input-Liste zu, bestimmt die Default-Policy, was mit dem Paket passieren soll und die Log-Variable, ob es bei einer Ablehnung ins System-Log geschrieben werden soll.

Bei den verwendeten Parametern gibt es zwei Einschränkungen:

- MASQUERADE und SNAT können nicht als Aktion angegeben werden
- bei einer Interface-Einschränkung kann man nur das Eingangsinterface einschränken.

INPUT_POLICY

  Diese Variable beschreibt die Default Policy, die angewand wird, wenn keine der anderen Regeln zutrifft. Möglich sind:

  - ACCEPT (nicht empfohlen)
  - REJECT
  - DROP (nicht empfohlen)

INPUT_ACCEPT_DEF

  Steht diese Variable auf 'yes', werden drei default-Regeln generiert. Die erste gestattet icmp echo requests ('prot:icmp:8 ACCEPT'), die zweite akzeptiert Pakete, die zu bestehenden Verbindungen gehören ('state:ESTABLISHED,RELATED ACCEPT', damit auch alle icmp pakete, die Resultat einer bestehenden Verbindung sind) und die dritte lokale Kommunikation ('if:lo:any ACCEPT'). Im Zweifelsfalle sollte man hier 'yes' eintragen.

INPUT_LOG

  Definiert, ob abgelehnte Pakete ins System-Log geschrieben werden sollen.

INPUT_LIST_N INPUT_LIST_x

  Liste der Regeln, die beschreiben, welche Pakete vom Router angenommen bzw. verworfen werden.

INPUT_LOG_LIMIT

  Definiert, wie häufig Log-Einträge generiert werden, die Häufigkeit wird analog zur Limit-Einschränkung als n pro Zeiteinheit mit Bursts beschrieben, also z.B. '3/minute:5'. Ist dieser Eintrag leer, wird keine Limitierung durchgeführt.

INPUT_REJ_LIMIT INPUT_UDP_REJ_LIMIT

  Definiert, wie häufig bei einer Ablehnung eines reinkommenden Paketes auch ein entsprechendes Reject-Paket generiert wird, die Häufigkeit wird analog zur Limit-Einschränkung als n pro Zeiteinheit mit Bursts beschrieben, also z.B. '3/minute:5'. Ist das Limit überschritten, wird das Paket einfach gedroppt. Ist dieser Eintrag leer, wird keine Limitierung durchgeführt.

### 4.14.4.2 Die Forward-Liste

Über die Forward-Liste wird konfiguriert, welche Pakete vom Router weitergeleitet werden. Trifft keine der Regeln der Forward-Liste zu, bestimmt die Default-Policy, was mit dem Paket passieren soll und die Log-Variable, ob es bei einer Ablehnung ins System-Log geschrieben werden soll.

Bei den verwendeten Parametern gibt es zwei Einschränkungen:

- MASQUERADE und SNAT können nicht als Aktion angegeben werden.
- REJECT kann (momentan noch) nicht als Aktion angegeben werden.

FORWARD_POLICY

  Die Default Policy wird angewand, wenn keine der Regeln zutrifft. Möglich sind:

  - ACCEPT
  - DROP

FORWARD_ACCEPT_DEF

  Bestimmt, ob der Router Pakete akzeptiert, die zu bestehenden Verbindungen gehören. Steht diese Variable auf 'yes', generiert fli4l automatisch eine Regel, die Pakete mit dem entsprechenden Zustand akzeptiert.

FORWARD_LOG

  Definiert, ob abgelehnte Pakete ins System-Log geschrieben werden sollen.

FORWARD_LOG_LIMIT

  Definiert, wie häufig Log-Einträge generiert werden, die Häufigkeit wird analog zur Limit-Einschränkung als n pro Zeiteinheit mit Bursts beschrieben, also z.B. '3/minute:5'. Ist dieser Eintrag leer, wird keine Limitierung durchgeführt.

FORWARD_REJ_LIMIT FORWARD_UDP_REJ_LIMIT

  Definiert, wie häufig bei einer Ablehnung eines reinkommenden Paketes auch ein entsprechendes Reject-Paket generiert wird, die Häufigkeit wird analog zur Limit-Einschränkung als n pro Zeiteinheit mit Bursts beschrieben, also z.B. '3/minute:5'. Ist das Limit überschritten, wird das Paket einfach gedroppt. Ist dieser Eintrag leer, wird keine Limitierung durchgeführt.

FORWARD_LIST_N FORWARD_LIST_x

  Liste der Regeln, die beschreiben, welche Pakete vom Router weitergeleitet werden bzw. verworfen werden.

### 4.14.4.3 Die NAT-Listen (network address translation)

Pakete können vor und nach Routing-Entscheidungen noch manipuliert werden, sie können zum Beispiel eine neue Zieladresse erhalten, um sie an einen anderen Rechner weiterzuleiten (Portforwarding) oder eine andere Quell-Adresse erhalten, um das hinter dem Router liegende Netzwerk zu maskieren. Maskieren nutzt man z.B. um ein privates Netz über eine öffentliche IP ins Netz zu bringen oder in einem DMZ Setup die Struktur des lokalen Netzes vor den Rechnern in der DMZ zu verbergen.

Die Konfiguration erfolgt über zwei Listen, die pre- und die postrouting-Liste.

Über die Postrouting-Liste wird konfiguriert, welche Pakete vom Router maskiert werden. Trifft keine der Regeln der Postrouting-Liste zu, werden die Pakete unmaskiert weitergeleitet.

Beim Maskieren gibt es zwei Varianten, eine für Interfaces, die bei der Einwahl erst eine IP zugewiesen bekommen (MASQUERADE) und eine für Interfaces mit statischer IP (SNAT). Letzteres erwartet dabei zusätzliche Parameter:

- die IP, die im Paket als Quelle eingetragen werden soll. Diese kann als
  - IP-Adresse (SNAT:1.2.3.4),
  - IP-Bereich (SNAT:1.2.3.4-1.2.3.10),

  - oder als Interface-Name angegeben werden, dessen IP-Adresse als Quelle dienen soll (SNAT:ip:eth_x_ipaddr).

Bei beiden kann ein Port/Portbereich angegeben werden, auf den der Quellport gemapped werden soll (Normalerweise ist das nicht nötig, da der Kern die Ports allein auswählen kann. Es gibt aber Anwendungen, die verlangen, daß der Quellport unverändert bleibt (erfordern ein 1:1 NAT oder verbieten PAT (Port Address Translation) bzw. NAPT (Network Port Address Translation)). Der Portbereich wird einfach hinten angehängt, z.B. so: SNAT:IP_NET_1_IPADDR:4000-8000.

Bei den verwendeten Parametern gibt es zwei Einschränkungen:

- DROP kann nicht als Aktion angegeben werden.
- REJECT kann nicht als Aktion angegeben werden.

POSTROUTING_LIST_N POSTROUTING_LIST_x

  Liste der Regeln, die beschreiben, welche Pakete vom Router maskiert werden (bzw. unmaskiert weitergeleitet werden). Will man Pakete vom Maskieren ausklammern, kann man eine Accept-Regel für die auszuklammernden Pakete der Masquerade-Regel voranstellen.

Über die Prerouting-Liste wird konfiguriert, welche Pakete an einen anderen Rechner weitergeleitet werden sollen. Trifft keine der Regeln der Prerouting-Liste zu, werden die Pakete unverändert weiterbehandelt.

DNAT erwartet als Parameter eine IP, die als neue Adresse des Paketes eingetragen werden soll und akzeptiert auch einen neuen Port:

- IP-Adresse: DNAT:1.2.3.4
- IP-Adresse und neuer Port: DNAT:1.2.3.4:8080
- IP-Adresse als Name: DNAT:client1

Redirect verhält sich wie DNAT, nur daß die Ziel-IP-Adresse immer auf 127.0.0.1 gesetzt wird und damit das Paket lokal zugestellt wird.

Will man Portforwarding auf Interfaces mit dynamischen IPs machen, weiß man zum Zeitpunkt der Konfiguration noch nicht, an welche IP die Pakete gerichtet sein werden. Daher kann man in der Prerouting-Liste dynamic als Platzhalter für die später zugewiesene IP verwenden. z.B. wie folgt:

        'dynamic:80  DNAT:1.2.3.4'           # forwarde http-Pakete
                                             # an die ip 1.2.3.4
        'prot:gre any dynamic DNAT:1.2.3.4'  # forwarde gre (teil des pptp
                                             # protokolls) an die ip 1.2.3.4

Bei den verwendeten Parametern gibt es eine Einschränkung, REJECT kann nicht als Target angegeben werden.

PREROUTING_LIST_N PREROUTING_LIST_x

  Liste der Regeln, die beschreiben, welche Pakete vom Router an ein anderes Ziel weitergeleitet werden sollen.

## 4.14.5 Beispiele

Im folgenden einige Beispiele für die neue Konfiguration.

### 4.14.5.1 Die Fli4l-Standardkonfiguration

Die fli4l-Standardkonfiguration der Distribution sah wie folgt aus, wenn man alle deaktivierten Optionen wegläßt:

        MASQ_NETWORK='192.168.6.0/24' # networks to masquerade (e.g. our LAN)
        INPUT_POLICY='REJECT'         # policy for input chain: reject or drop
        FORWARD_DENY_PORT_N='1'       # no. of ports to reject/deny forwarding
        FORWARD_DENY_PORT_1='137:139 reject'  # drop/reject forwarding of netbios
        DENY_ICMP='no'                # deny icmp (ping): yes or no
        PACKETFILTER_LOG='no'         # log access to rejected/denied ports

Nehmen wir diese Optionen und die im Paketfilter-Kapitel beschriebenen Annahmen, sieht eine Übersetzung ins neue Schema wie folgt aus:

        INPUT_POLICY='REJECT'
        INPUT_ACCEPT_DEF='yes'
        INPUT_LOG='no'
        INPUT_LIST_N='1'
        INPUT_LIST_1='IP_NET_1 ACCEPT'

Damit erreichen wir, daß

- Rechner im lokalen Netzwerk auf den Router zugreifen dürfen (Regel 1),
- lokale Kommunikation auf dem Router erlaubt ist (INPUT_ACCEPT_DEF),
- Pakete, die zu vom Router aufgebauten Verbindungen gehören, akzeptiert werden (INPUT_ACCEPT_DEF),
- alles andere abgelehnt wird (INPUT_POLICY),
- aber nicht ins Systemlog geschrieben wird.

Für die Forward-Liste sieht das so ähnlich aus. Nur Pakete unseres lokalen Netzes und Pakete, die zu Verbindungen gehören, die von Rechnern im lokalen Netz aufgebaut wurden, sollen weitergeleitet werden. Netbios-Pakete und der neue cifs Port werden verworfen.

        FORWARD_POLICY='REJECT'
        FORWARD_ACCEPT_DEF='yes'
        FORWARD_LOG='no'
        FORWARD_LIST_N='2'
        FORWARD_LIST_1='tmpl:samba DROP'
        FORWARD_LIST_2='IP_NET_1 ACCEPT'

Was man hier gut sieht, ist die Abhängigkeit von der Reihenfolge der Regeln. Als erstes werden Netbios-Pakete verworfen, dann werden die Pakete des lokalen Netzes akzeptiert.

Nun kann das lokale Netz mit dem Router kommunizieren, seine Pakete werden weitergeleitet, es fehlt nur noch das Maskieren, welches für den Zugriff eines privaten Netzwerkes auf das Internet notwendig ist:

        POSTROUTING_LIST_N='1'
        POSTROUTING_LIST_1='IP_NET_1  MASQUERADE'

Für diesen einfachen Fall sieht die ursprüngliche Konfiguration wesentlich einfacher aus. Das ändert sich, wenn wir die anderen Optionen mit hinzunehmen, die da sind:

- trusted nets
- route network
- white list
- black list

### 4.14.5.2 Trusted Nets

Wollen wir lokal mehrere Subnetze haben, die frei und unmaskiert miteinander kommunizieren können, müssen wir dasfür sorgen, daß Pakete zwischen diesen Subnetzen nicht verworfen und auch nicht maskiert werden. Dazu wurden in der originalen FW-Konfiguration diese Netze in TRUSTED_NETS aufgezählt. In der neuen Konfiguration fügen wir einfach eine Regel hinzu oder modifizieren die vorhandene.

Angenommen, die beiden Subnetze sind IP_NET_1 (192.168.6.0/24) und IP_NET_2 (192.168.7.0/24) und wir haben einen DSL-Zugang über pppoe. Dann würde die Konfiguration wie folgt aussehen:

        FORWARD_POLICY='REJECT'
        FORWARD_ACCEPT_DEF='yes'
        FORWARD_LOG='no'
        FORWARD_LIST_N='4'
        FORWARD_LIST_1='IP_NET_1 IP_NET_2 ACCEPT BIDIRECTIONAL'
        FORWARD_LIST_2='tmpl:samba DROP'
        FORWARD_LIST_3='IP_NET_1 ACCEPT'
        FORWARD_LIST_4='IP_NET_2 ACCEPT'

        POSTROUTING_LIST_N='3'
        POSTROUTING_LIST_1='IP_NET_1 IP_NET_2 ACCEPT BIDIRECTIONAL'
        POSTROUTING_LIST_2='IP_NET_1 MASQUERADE'
        POSTROUTING_LIST_3='IP_NET_2 MASQUERADE'

Die Regel eins sorgt jetzt dafür, daß Pakete zwichen den beiden Subnetzen ohne weitere Prüfung weitergeleitet werden. Regel 3 und 4 sorgen dafür, daß beide Subnetze auch ins Internet kommen. Die erste Regel der MASQ-Liste sorgt dafür, daß die Kommunikation zwischen den Subnetzen unmaskiert erfolgt. Alternativ könnten wir auch sagen, daß nur Pakete, die über das pppoe-Device rausgehen, maskiert werden sollen:

        POSTROUTING_LIST_N='1'
        POSTROUTING_LIST_1='if:any:pppoe MASQUERADE'

Genauso hätte man die Filterung der Ports auch auf das pppoe-device beschränken und die beiden Subnetze zu einem zusammenfassen können, das würde dann wie folgt aussehen:

        FORWARD_POLICY='REJECT'
        FORWARD_ACCEPT_DEF='yes'
        FORWARD_LOG='no'
        FORWARD_LIST_N='2'
        FORWARD_LIST_1='if:any:pppoe tmpl:samba DROP'
        FORWARD_LIST_2='192.168.6.0/23 ACCEPT'

        POSTROUTING_LIST_N='1'
        POSTROUTING_LIST_1='if:any:pppoe MASQUERADE'

Pakete, die über das pppoe-Device hinaus gehen und die an die Ports 137-138 udp sowie 139 und 445 tcp adressiert sind, werden verworfen (Regel 1), alle anderen Pakete, die aus dem Subnetz 192.168.6.0/23 kommen, werden weitergeleitet (Regel 2).

### 4.14.5.3 Route Network

Fügen wir dem ganzen noch ein Netzwerk 10.0.0.0/24 hinzu (z.B. ein Dial-In-Netzwerk, mit dem wir unmaskiert kommunizieren wollen, wobei die Ports 137-138 udp, 139 und 445 tcp verworfen werden sollen. Das würde wie folgt aussehen:

        FORWARD_POLICY='REJECT'
        FORWARD_ACCEPT_DEF='yes'
        FORWARD_LOG='no'
        FORWARD_LIST_N='4'
        FORWARD_LIST_1='IP_NET_1 IP_NET_2 ACCEPT BIDIRECTIONAL'
        FORWARD_LIST_2='tmpl:samba DROP'
        FORWARD_LIST_3='192.168.6.0/23 ACCEPT'
        FORWARD_LIST_4='10.0.0.0/24 ACCEPT'

        POSTROUTING_LIST_N='2'
        POSTROUTING_LIST_1='10.0.0.0/24 ACCEPT BIDIRECTIONAL'
        POSTROUTING_LIST_2='192.168.6.0/23 MASQUERADE'

- Regel 1 erlaubt die freie Kommunikation zwischen den Subnetzen IP_NET_1 und IP_NET_2
- Regel 2 verwirft die Samba-Ports
- Regel 3 und 4 lassen Pakete durch, die aus den Subnetzen 192.168.6.0/24, 192.168.7.0/24 und 10.0.0.0/24 kommen, die Rückrichtung wird von FORWARD_ACCEPT_DEF='yes' abgedeckt.
- Regel 1 der Masq-Liste sorgt dafür, daß Pakete in das/aus dem 10.0.0.0/24 Subnetz nicht maskiert werden.

Alternativ ginge auch:

        POSTROUTING_LIST_N='1'
        POSTROUTING_LIST_1='if:any:pppoe MASQUERADE'

Nur Pakete, die über das pppoe-Interface hinausgehen, werden maskiert.

### 4.14.5.4 Blacklists, Whitelists

Blacklists (ein Rechner in dieser Liste darf etwas nicht) und Whitelists (ein Rechner in dieser Liste darf etwas) werden prinzipiell ähnlich umgesetzt. Es werden Regeln geschrieben, die am Anfang sehr speziell sind und nach hinten immer allgemeiner werden. Bei einer Blacklist stehen am Anfang Regeln, die etwas verbieten und am Ende Regeln, die allen bisher nicht erwähnten etwas erlauben, bei einer Whitelist ist es genau umgekehrt. Einfaches Beispiel: Alle Rechner im Subnetz 192.168.6.0/24 außer Rechner 12 dürfen ins Internet, solange sie nicht mit den CIFS Ports 137-138 udp, 139 und 445 tcp kommunizieren wollen:

        FORWARD_POLICY='REJECT'
        FORWARD_ACCEPT_DEF='yes'
        FORWARD_LOG='no'
        FORWARD_LIST_N='3'
        FORWARD_LIST_1='192.168.6.12 DROP'
        FORWARD_LIST_2='tmpl:samba DROP'
        FORWARD_LIST_3='192.168.6.0/23 ACCEPT'

        POSTROUTING_LIST_N='1'
        POSTROUTING_LIST_2='192.168.6.0/24 MASQUERADE'

Nur Rechner 12 darf ins Internet (aber nicht an die Ports ...), alle anderen dürfen nur lokal mit einem anderen Subnetz kommunizieren:

        FORWARD_POLICY='REJECT'
        FORWARD_ACCEPT_DEF='yes'
        FORWARD_LOG='no'
        FORWARD_LIST_N='3'
        FORWARD_LIST_1='192.168.6.0/24 192.168.7.0/24 ACCEPT BIDIRECTIONAL'
        FORWARD_LIST_2='tmpl:samba DROP'
        FORWARD_LIST_3='192.168.6.12 ACCEPT'

        POSTROUTING_LIST_N='1'
        POSTROUTING_LIST_1='if:any:pppoe MASQUERADE'

## 4.14.6 Standardkonfigurationen

### 4.14.6.1 Einfacher maskierender Router mit einem Netz dahinter

    ORIG_FW_CONFIG='no'
    NEW_FW_CONFIG='yes'

    #
    # Zugriff auf den Router
    #
    INPUT_POLICY='REJECT'
    INPUT_ACCEPT_DEF='yes'
    INPUT_LOG='no'
    INPUT_LIST_N='1'
    INPUT_LIST_1='IP_NET_1 ACCEPT'   # alle hosts im lokalen netz dürfen
    				 # auf den router zugreifen

    #
    # Zugriff auf das ``Internet''
    #
    FORWARD_POLICY='REJECT'
    FORWARD_ACCEPT_DEF='yes'
    FORWARD_LOG='no'

    FORWARD_LIST_N='2'
    FORWARD_LIST_1='tmpl:samba DROP' # samba pakete, die das netz
    				 # verlassen wollen, werden verworfen
    FORWARD_LIST_2='IP_NET_1 ACCEPT' # alle anderen pakete dürfen das
    				 # lokale netz verlassen

    #
    # Maskieren des lokalen Netzes
    #
    POSTROUTING_LIST_N='1'
    POSTROUTING_LIST_1='IP_NET_1 MASQUERADE'  # masquerade traffic leaving
                                     # the subnet

### 4.14.6.2 Einfacher maskierender Router mit zwei Netzen dahinter

    ORIG_FW_CONFIG='no'
    NEW_FW_CONFIG='yes'

    #
    # Zugriff auf den Router
    #
    INPUT_POLICY='REJECT'
    INPUT_ACCEPT_DEF='yes'
    INPUT_LOG='no'
    INPUT_LIST_N='2'
    INPUT_LIST_1='IP_NET_1 ACCEPT'   # alle hosts im lokalen netz dürfen
    				 # auf den router zugreifen
    INPUT_LIST_2='IP_NET_2 ACCEPT'   # alle hosts im lokalen netz dürfen
    				 # auf den router zugreifen

    #
    # Zugriff auf das ``Internet''
    #
    FORWARD_POLICY='REJECT'
    FORWARD_ACCEPT_DEF='yes'
    FORWARD_LOG='no'

    #
    # Kein Samba zwischen den Netzen
    #
    FORWARD_LIST_N='3'
    FORWARD_LIST_1='tmpl:samba DROP' # samba pakete, die das netz
    				 # verlassen wollen, werden verworfen
    FORWARD_LIST_2='IP_NET_1 ACCEPT' # alle anderen pakete dürfen das
    				 # lokale netz verlassen
    FORWARD_LIST_3='IP_NET_2 ACCEPT' # alle anderen pakete dürfen das
    				 # lokale netz verlassen

    #
    # Freie Kommunikation zwischen den Netzen
    #
    FORWARD_LIST_N='4'
    FORWARD_LIST_1='IP_NET_1 IP_NET_2 ACCEPT BIDIRECTIONAL'
    FORWARD_LIST_2='tmpl:samba DROP' # samba pakete, die das netz
    				 # verlassen wollen, werden verworfen
    FORWARD_LIST_3='IP_NET_1 ACCEPT' # alle anderen pakete dürfen das
    				 # lokale netz verlassen
    FORWARD_LIST_4='IP_NET_2 ACCEPT' # alle anderen pakete dürfen das
    				 # lokale netz verlassen

    #
    # Maskieren der lokalen Netze, unmaskierte Kommunikation zwischen den
    # Netzen
    #
    POSTROUTING_LIST_N='3'
    POSTROUTING_LIST_1'IP_NET_1 IP_NET_2 ACCEPT BIDIRECTIONAL'
    POSTROUTING_LIST_2='IP_NET_1 MASQUERADE'  # masquerade traffic leaving
                                     	  # the subnet
    POSTROUTING_LIST_3='IP_NET_2 MASQUERADE'  # masquerade traffic leaving
                                     	  # the subnet

### 4.14.6.3 Maskierender DSL-Router mit zwei Netzen dahinter und ssh/http-Zugriff aus dem Internet

    ORIG_FW_CONFIG='no'
    NEW_FW_CONFIG='yes'

    #
    # Zugriff auf den Router
    #
    INPUT_POLICY='REJECT'
    INPUT_ACCEPT_DEF='yes'
    INPUT_LOG='no'
    INPUT_LIST_N='4'
    INPUT_LIST_1='IP_NET_1 ACCEPT'   # alle hosts im lokalen netz dürfen
    				 # auf den router zugreifen
    INPUT_LIST_2='IP_NET_2 ACCEPT'   # alle hosts im lokalen netz dürfen
    				 # auf den router zugreifen
    INPUT_LIST_3='tmpl:ssh ACCEPT'   # gestatte Zugriff auf ssh-Service
    				 # von Überall her
    INPUT_LIST_4='tmpl:http 1.2.3.4/24 ACCEPT'  # gestatte Rechner aus
    				 # einem bestimmten Subnetz Zugriff
    				 # auf http-Service

    #
    # Zugriff auf das ``Internet''
    #
    FORWARD_POLICY='REJECT'
    FORWARD_ACCEPT_DEF='yes'
    FORWARD_LOG='no'

    #
    # Keine Kommunikation zwischen den Netzen, beide Netze dürfen ins
    # Internet, Samba-Pakete werden verworfen
    #
    FORWARD_LIST_N='2'
    FORWARD_LIST_1='tmpl:samba if:any:pppoe DROP' # samba pakete, die das netz
    				     # verlassen wollen, werden verworfen
    FORWARD_LIST_2='if:any:pppoe ACCEPT' # alle anderen pakete dürfen das
    				     # lokale netz verlassen

    #
    # Maskieren der lokalen Netze, unmaskierte Kommunikation zwischen den
    # Netzen
    #
    POSTROUTING_LIST_N='1'
    POSTROUTING_LIST_1='if:any:pppoe MASQUERADE'  # masquerade traffic leaving
                                    	      # the subnet

### 4.14.6.4 Portforwarding

Will man statt der alten Portforwarding-Konfiguration die neue verwenden, läßt sich das wie folgt übersetzen:

    TARGET='<port>'
    NEW_TARGET='<ip>'
    PROTOCOL='<proto>'
    PREROUTING_LIST_x='prot:<proto> dynamic:<port> DNAT:<ip>'

    TARGET='<port1>-<port2>'
    NEW_TARGET='<ip>'
    PROTOCOL='<proto>'
    PREROUTING_LIST_x='prot:<proto> dynamic:<port1>-<port2> DNAT:<ip>'

    TARGET='<ip>:<port-a>'
    NEW_TARGET='<ip>:<port-b>'
    PROTOCOL='<proto>'
    PREROUTING_LIST_x='prot:<proto> <ip>:<port-a> DNAT:<ip>:<port-b>'

### 4.14.6.5 Transparent Proxy

Will man bestimmte Zugriffe auf das Internet nur über einen lokalen Proxy zulassen, kann man das mit Hilfe der Pre/Postroutinglisten erzwingen, ohne dass der Client davon etwas merkt.

Prinzipiell sind dazu drei Schritte notwendig:

1. Anfragen an den http Port, die nicht vom proxy kommen, an den Proxy umleiten (PREROUTING).
2. Die umgeleiteten Pakete so verändern, dass der Proxy denkt, sie kommen vom Router, sodaß er sie wieder dorthin zurückschickt (POSTROUTING).
3. Die Pakete durch die Forwardchain durchlassen, sofern ein Eintrag alà FORWARD_LIST_x='IP_NET_1 ACCEPT' nicht existiert (FORWARD).

1. Beispiel: Angenommen wir haben nur ein Netz IP_NET_1, in dem auf einem Rechner namens ``proxy'' ein Squid läuft und wollen den gesamten http-Traffic über ihn leiten. Squid lauscht auf Port 3128. Der Einfachheit halber beziehen wir uns via '@proxy' auf den eingetragenen Host aus HOST_1_NAME='proxy' (vgl. Domainkonfiguration).

Das ganze würde wie folgt aussehen:

    ...
      PREROUTING_LIST_x='@proxy ACCEPT'
          # Pakete vom Proxy sollen nicht umgeleitet werden

      PREROUTING_LIST_x='prot:tcp IP_NET_1 any:80 DNAT:@proxy:3128'
          # http-Pakete aus IP_NET_1 mit einem beliebigen Ziel werden
            umgeleitet nach @proxy Port 3128

      POSTROUTING_LIST_x='any @proxy:3128 SNAT:IP_NET_1_IPADDR'
          # alle Pakete an den Proxy Port 3128 so umschreiben als wären sie
            vom fli4l (IP_NET_1_IPADDR)

      FORWARD_LIST_x='prot:tcp @proxy 80 ACCEPT'
          # http-Pakete vom Proxy durch die Forwardchain durchlassen
            (wenn nötig)
    ...

Gibt es mehrere Netze oder potentielle Konflikte mit anderen Portforwardings (die ja auchnichts anderes sind als DNAT-Regeln), muss man die Regeln vielleicht noch etwas enger formulieren.

2. Beispiel: Unser Proxy namens ``proxy'' steht in IP_NET_1, lauscht auf Port 3128 und soll nur für Clients aus IP_NET_1 wirksam werden. IP_NET_1 ist über IP_NET_1_DEV erreichbar. Pakete aus weiteren Netzen sollen nicht berücksichtigt werden.

    ...
      PREROUTING_LIST_x='if:ip_net_1_dev:any !@proxy 80 DNAT:@proxy:3128'
          # Anfragen an den http Port, die nicht vom proxy aber über ein
            internes Interface (ip_net_1_dev) kommen, an den Proxy Port
            umleiten
          # An dieser Stelle ist es wichtig, mit if:ip_net_1_dev:any zu
            überprüfen ob die Pakete von innen kommen da sonst auch Pakete
            von außen
          # umgeleitet werden würden (Sicherheitslücke)

      POSTROUTING_LIST_x='prot:tcp IP_NET_1 @proxy:3128
    SNAT:IP_NET_1_IPADDR'   # (alles eine Zeile!)
          # http-Pakete die aus IP_NET_1 stammen und für den Proxy Port 3128
            gedacht sind, so umschreiben als wären sie vom fli4l
           (IP_NET_1_IPADDR)

      FORWARD_LIST_x='prot:tcp @proxy 80 ACCEPT'
          # http-Pakete vom proxy durch die Forwardchain durchlassen (wenn
            nötig)
    ...

3. Beispiel: Um sich das Leben etwas zu erleichtern und die Regeln kürzer zu gestalten, kann man auch Templates einsetzen (vgl. Templates im Paketfilter). Zweckmäßig ist an dieser Stelle das tmpl:http.

tmpl:http wird zu 'prot:tcp any any:80' und so wird bspw. aus 'tmpl:http IP_NET_1 DNAT:@proxy:3128' 'prot:tcp IP_NET_1 80 DNAT:@proxy:3128'

Sowohl IP_NET_1 als auch IP_NET_2 sollen transparent über den Proxy umgeleitet werden. Damit ließe sich vereinfacht auch schreiben:

    ...
      PREROUTING_LIST_x='tmpl:http @proxy   ACCEPT'
      # http-Pakete von IP_NET_2 sollen umgeleitet werden
      PREROUTING_LIST_x='tmpl:http IP_NET_1 DNAT:@proxy:3128'
      # http-Pakete aus IP_NET_1 sollen umgeleitet werden
      PREROUTING_LIST_x='tmpl:http IP_NET_2 DNAT:@proxy:3128'
      # http-Pakete aus IP_NET_2 sollen umgeleitet werden

      POSTROUTING_LIST_x='IP_NET_1 @proxy:3128 SNAT:IP_NET_1_IPADDR'

      FORWARD_LIST_x='tmpl:http @proxy ACCEPT'
    ...

Und so ließe sich das endlos fortsetzen ...

##
4.14.7 DMZ - Demilitarisierte Zone

Fli4l gestattet auch den Aufbau einer einfachen DMZ. Voraussetzung ist ein Router mit drei Interfaces, eines zum WAN (das rote Interface), eines in die DMZ (das orange Interface) und mindestens eins in lokale Netzwerke (grüne Interfaces). Die DMZ kann so konfiguriert werden, daß das im folgenden beschriebene möglich wird.

### 4.14.7.1 Kommunikation zwischen Grün und Rot

Diese Kommunikation wird ganz normal wie oben beschrieben konfiguriert.

### 4.14.7.2 Kommunikation zwischen Grün und Orange

Grüne Netze dürfen frei mit Rechnern im orangen Netz kommunizieren. Die Rechner im orangen Netz sehen dabei nichts von der Struktur der grünen Netze; die Verbindungen scheinen alle vom orangen Interface des Routers auszugehen (SNAT).

Die Rechner aus dem orangen Subnetz dürfen keine Verbindungen in grüne Netzwerke hinein aufbauen. Es werden lediglich Pakete durchgelassen, die zu Verbindungen gehören, die von Rechnern eines grünen Netzwerkes aufgebaut wurden.

### 4.14.7.3 Kommunikation zwischen Rot und Orange

Verbindungen aus dem roten Netz ins orange Netz können über Portforwarding eingerichtet werden. Die dort aufgeführten Dienste sind aus dem Wan erreichbar. Pakete, die zu solchen Verbindungen gehören, dürfen das orange Netz auch wieder verlassen. Beim Verlassen des orangen Netzes werden die Pakete maskiert, erhalten also die IP des roten Interfaces.

Sollen auch andere Pakete das orange Subnet verlassen, muss das separat konfiguriert werden (DMZ_ORANGE_RED_x).

### 4.14.7.4 Kommunikation zwischen Orange und dem Router

Rechner aus dem Orangen Netz können ausgewählte Dienste des Routers nutzen; welche das sind, wird über DMZ_ORANGE_ROUTER_x konfiguriert.

### 4.14.7.5 Konfiguration der DMZ

Die Typen der Subnetze werden bei ihrer Definition mit festgelegt. Dazu wurde die Variable IP_NET_x_TYPE eingeführt. Die anderen Parameter werden in DMZ_*-Variablen definiert.

OPT_DMZ

  Aktiviert eine DMZ Konfiguration.

IP_NET_x_TYPE

  Definiert den Typen des Subnetz. Erlaubte Werte sind 'green' und 'orange'. Wird diese Variable weggelassen, wird das Netz bei der DMZ-Konfiguration ignoriert.

DMZ_RED_DEV

  Das Interface zum Internet. Dieses kann als pppoe für ein dsl-Interface, ppp<index> für ein ppp-Device, ippp+ für isdn-Interfaces oder als IP_NET_x_DEV angegeben werden.

DMZ_NAT

  Wenn in der DMZ private Adressen genutzt werden, muß der Router diese maskieren. DMZ_NAT='yes' aktiviert das maskieren.

DMZ_ORANGE_RED_N DMZ_ORANGE_RED_x

  Definiert, welche Verbindungen vom orangen Subnetz aus aufgebaut werden können. Die Syntax entspricht der Syntax des Paketfilters.

DMZ_ORANGE_ROUTER_N DMZ_ORANGE_ROUTER_x

  Definiert, welche Dienste des Routers im oranges Subnetz in Anspruch genommen werden können. Die Syntax entspricht der Syntax des Paketfilters.

DMZ_LOG

  Aktiviert das Loggen abgelehnter Pakete.

Ein kleines Beispiel mit einem Mail-, Web-Server und einem Web-Proxy in der DMZ könnte wie folgt aussehen:

    IP_NET_N='3'
    IP_NET_1_DEV='eth0'
    IP_NET_1='192.168.6.1/24'
    IP_NET_1_TYPE='green'
    IP_NET_2_DEV='eth1'
    IP_NET_2='192.168.7.1/24'
    IP_NET_2_TYPE='green'
    IP_NET_3_DEV='eth3'
    IP_NET_3='192.168.8.1/24'
    IP_NET_3_TYPE='orange'

    OPT_DMZ='yes'
    DMZ_NAT='yes'
    DMZ_LOG='yes'
    DMZ_RED_DEV='ppp0'
    DMZ_ORANGE_RED_N='2'
    DMZ_ORANGE_RED_1='prot:tcp 80 ACCEPT' # allow access to http
    DMZ_ORANGE_RED_2='prot:tcp 25 ACCEPT' # allow access to smtp
    DMZ_ORANGE_ROUTER_N='1'
    DMZ_ORANGE_ROUTER_1='53 ACCEPT'       # accept dns requests

    PORTFW_N='2'
    PORTFW_1_TARGET='80'                  # forward http
    PORTFW_1_NEW_TARGET='192.168.8.2'     # ...to dmz host 192.168.8.2
    PORTFW_1_PROTOCOL='tcp'               # ...using tcp
    PORTFW_2_TARGET='25'                  # forward smtp
    PORTFW_2_NEW_TARGET='192.168.8.3'     # ...to dmz host 192.168.8.3
    PORTFW_2_PROTOCOL='tcp'               # ...using tcp

##
4.14.8 Port-Forwarding

Für einige Internet-Protokolle ist es nötig, einen Verbindungsaufbau eines Rechners von außen in das interne Netz umzuleiten. Ist das Netz nach außen hin maskiert (IP-Masquerading), also nur eine offizielle IP-Adresse für das gesamte LAN vorhanden, kann man bestimmte Ports oder Protokolle, die von außen erreichbar sein sollen, auf einen bestimmten internen Rechner umleiten. Dieses nennt man Port-Forwarding (bzw. allgemeiner Destination Network Address Translation, kurz DNAT). Die Problematik des Port-Forwarding wird bei der Beschreibung von MASQ_MODULE_N noch angesprochen (s.u.).

Oft müssen bei Spielen, Chat oder Internet-Telefonie solche Ports freigeschaltet werden. Können dies die Masquerading-Module selber nicht lösen, kann man selbst Port-Weiterleitungen einrichten.

PORTFW_N

  Hiermit wird die Anzahl der Port-Weiterleitungen angegeben. Diese werden in PORTFW_x_TARGET, PORTFW_x_NEW_TARGET und PORTFW_x_PROTOCOL definiert.

PORTFW_x_TARGET

  Pakete sind an ein bestimmtes Ziel gerichtet (normalerweise eine IP-Adresse und ein Port) und gehören zu einem bestimmten Protokoll. Dieses Ziel ist in einem maskierten Netz der Router, das eigentliche Ziel liegt aber im maskierten Netz, die Pakete müssen also dorthin weitergereicht werden.

  PORTFW_x_TARGET gibt an, an welches Ziel Pakete gerichtet sein müssen, um weitergeleitet zu werden. Kommt ein solches Paket am Router an, wird es an das eigentliche Ziel weitergeleitet.

  Das Ziel wird immer durch eine IP-Adresse, ein Protokoll und evtl. noch einen Port beschrieben. Bei einem Router mit dynamisch zugewiesener IP-Adresse ist die IP zum Zeitpunkt der Konfiguration noch nicht bekannt, kann also nicht angegeben werden. Hier wird das Port-Forwarding erst beim Aufbau der Verbindung eingerichtet, wenn die IP-Adresse bekannt ist und es bezieht sich immer auf Pakete, die am Router ankommen und an die dynamisch zugewiesene IP gerichtet sind.

  Im Gegensatz dazu wird das Forwarding bei bekannter IP-Adresse bereits beim Booten eingerichtet.

  Wichtig: Bei Routern mit fester IP Adresse muß diese hier angegeben werden, sonst wird das Port-Forwarding aufgrund des fehlenden Einwählens nicht korrekt aufgesetzt.

  Folgende Formate sind hier möglich:

  `PORTFW_x_TARGET='<port>'`

  Leitet alle Pakete weiter, die auf dem Port `<port>` ankommen an einen anderen Rechner weiter.

  `PORTFW_x_TARGET='<port1>-<port2>'`

  Leitet alle Pakete, die auf den Ports im Bereich zwischen `<port1>` und `<port2>` ankommen, an einen anderen Rechner weiter.

  `PORTFW_x_TARGET='<ip>:<port>'` `PORTFW_x_TARGET='<ip>:<port1>-<port2>'`

  Leitet alle Pakete, die auf der IP `<ip>` des Routers auf Port `<port>` (oder im Port-Bereich `<port1>-<port2>`) ankommen, an einen anderen Rechner weiter. Die IP-Adresse kann über einen der in HOST_x_NAME/HOST_x_ALIAS_x angegebenen Namen bzw. als Referenz auf IP_NET_x (das in dieser Variable angegebene Netzwerk) oder IP_NET_x_IPADDR (die dort enthaltene IP-Adresse) angegeben werden.

  `PORTFW_x_TARGET='<circuit>:<port>'`

  Leitet alle Pakete, die bei eingewähltem Circuit `<circuit>` an der dazugehörigen IP-Adresse am Port `<port>` ankommen, an einen anderen Rechner weiter. `<circuit>` ist entweder die Nummer eines ISDN-Circuits oder ``pppoe'' für eine DSL-Verbindung (siehe Package DSL).

  `PORTFW_x_TARGET='none'`

  Keine Einschränkung des Ziels. Alle Pakete, die am Router ankommen und zum in PORTFW_x_PROTOCOL angegebenen Protokoll gehören, werden an einen anderen Rechner weitergeleitet.

  `PORTFW_x_TARGET='<ip>:none'`

  Alle Pakete, die am Router ankommen, als Zieladresse die angegebene IP-Adresse haben und zum in PORTFW_x_PROTOCOL angegebenen Protokoll gehören, werden an einen anderen Rechner weitergeleitet.

PORTFW_x_NEW_TARGET

  Dieser Parameter gibt das Ziel eines Port-Forwardings an. Dies ist in der Regel ein anderer Computer im internen Netzwerk. Folgende Formate sind hier möglich:

  `PORTFW_x_NEW_TARGET='<ip>'`

  Leitet alle Pakete, die für diese Regel ankommen, an den Rechner mit der IP `<ip>` weiter. Die IP-Adresse kann über einen der in HOST_x_NAME/HOST_x_ALIAS_x angegebenen Namen bzw. als Referenz auf IP_NET_x (das in dieser Variable angegebene Netzwerk) oder IP_NET_x_IPADDR (die dort enthaltene IP-Adresse) angegeben werden.

  `PORTFW_x_NEW_TARGET='<ip>:<port>'`

  Leitet alle Pakete, die für diese Regel ankommen, an den Rechner mit der IP `<ip>` an den Port `<port>` weiter. Diese Regel ist für Portbereiche (`<port1>-<port2>`) unzulässig! Die IP-Adresse kann über einen der in HOST_x_NAME/HOST_x_ALIAS_x angegebenen Namen bzw. als Referenz auf IP_NET_x (das in dieser Variable angegebene Netzwerk) oder IP_NET_x_IPADDR (die dort enthaltene IP-Adresse) angegeben werden.

PORTFW_x_PROTOCOL

  Dieser Parameter gibt das Protokoll an, für das diese Regel zutrifft. Zugelassen sind hier `tcp', `udp', `gre' und die Angabe der Protokollnummer (siehe Liste der Protokoll-Nummern der IANA unter http://www.iana.org/assignments/protocol-numbers.

  In früheren Versionen bestand die Möglichkeit, eigene Regeln in einem speziellen Script abzulegen. Diese Möglichkeit besteht seit fli4l 2.1.0 NICHT mehr, da dieses Script das variablengesteuerte Port-Forwarding stören würde und eine reibunglose Funktion nicht mehr garantiert werden könnte.

  Ich habe auf meiner Homepage ein Script hinterlegt, welches die Regeln, die man auf dieser Seite findet, in das fli4l-Konfigurationsformat umwandelt. Hiermit können auch Port-Forwarding-Scripts aus alten fli4l-Versionen in das neue Format umgewandelt werden:

  http://portfolio16.de/fli4l/portfw.pl

  Mit dem Windows-Client imonc ist es möglich, die Regeln zur Laufzeit des Routers zu ändern und die aktualisierte Fassung wieder zurück an den fli4l-Router zu schicken.

##
4.14.9 Masquerading Module

Die Verwendung von IP-Masquerading hat zwar den Vorteil, daß mehrere Rechner im LAN über eine einzige offizielle IP-Adresse geroutet werden kann, es gibt aber auch Nachteile, die man in Kauf nehmen muß.

Ein großes Problem ist zum Beispiel, daß kein Rechner von außen von sich aus eine Verbindung zu einem Rechner aufnehmen kann. Das ist zwar aus Sicherheitsgründen eigentlich durchaus erwünscht, aber bestimmte Protokolle funktionieren nicht mehr, weil sie einen Verbindungsaufbau von außen einfach erfordern.

Ein klassisches Beispiel ist ftp. Neben dem Kommunikationskanal, auf dem Befehle und Antworten ausgetauscht werden, wird ein weiterer Kanal (in Form eines IP-Ports) verwendet, um die eigentlichen Nutzdaten zu versenden. fli4l verwendet dafür bestimmte Masquerading-Module, um solche zusätzlichen Ports, die verwendet werden, ad hoc dann freizuschalten und an den internen Rechner weiterzuleiten, wenn sie benötigt werden. Dabei ``horcht'' das Masquerading-Modul in den Datenstrom, um zu erkennen, wann ein zusätzlicher Port benötigt wird.

Typische Anwendungen für Masquerading-Module sind Chat-Protokolle und Spiele im Internet.

MASQ_MODULE_N MASQ_MODULE_x MASQ_MODULE_x_OPTION

Bisher wurde für fli4l das ftp-Masquerading-Modul immer automatisch geladen. Mittlerweile sind weitere Module verfügbar. Diese lassen sich auch mit zusätzlichen Optionen aufrufen. Dies ist zum Beispiel dann nötig, wenn ein FTP-Server auf einem anderen Port als 21 angesprochen werden soll. Hier eine Übersicht aller Module mit ihren Parametern, die vorgegebenen Werte sind die Standardwerte:

ftp
  File Transfer Protocol

  Parameter:

  ports=21
    Gibt Ports an, die dieses Modul überwachen soll. Wenn also ein FTP-Server auch auf Port 2021 angesprochen werden soll, muß dieser Parameter ``ports=21,2021'' lauten.

irc
  Internet Relay Chat

  Parameter:

  ports=6667
    Gibt die Ports an, auf denen ein IRC-Server laufen kann, zu dem man sich verbinden möchte.
  Bemerkungen: mIRC ist standardmäßig falsch konfiguriert, so daß er nicht mit diesem Modul zusammenarbeitet. Um mIRC richtig einzustellen, geht man folgendermaßen vor (Verbindung zum IRC-Server erst trennen): Im ``Options''-Dialog: Auswahlliste: ``Connect'', dann ``Local Info'', hier beide Eingabefelder löschen (falls etwas drin steht), dann ``Lookup Method:'' auf ``Normal'' stellen.

Alle Parameter, die eine Liste von Ports annehmen, können höchstens 12 Ports übergeben bekommen.

Natürlich kann man nicht für jedes Protokoll, welches zusätzliche Ports verwendet, ein separates Masquerading-Modul programmieren. Aus diesem Grund gibt es neben den oben aufgeführten Modulen auch noch eine andere Möglichkeit, neue Ports an einen internen Rechner weiterzuleiten. Siehe dafür auch die Beschreibung zu PORTFW_N (Port-Forwarding). Noch ein Tip: Auf http://www.fli4l.de wurde speziell zum Thema Port-Forwarding eine eigene FAQ eingerichtet.

Zu den Konfigurationsvariablen:

MASQ_MODULE_N gibt die Anzahl der zu ladenden Masquerading-Module an. MASQ_MODULE_x gibt das x'te zu ladende Masquerading-Modul an. Desweitern gibt MASQ_MODULE_x_OPTION die Parameter des entspechenden Masquerading- Moduls an. Hier können die oben beschriebenen Parameter, mit Leerzeichen getrennt angegeben werden.

Die Standardeinstellung für MASQ_MODULE_N ist `1'. Damit wird nur das erste Modul, nämlich ftp, geladen. Möchte man weitere Module laden, ist MASQ_MODULE_N entsprechend zu erhöhen. Die Reihenfolge in der beigefügten Datei config/base.txt ist nur ein Beispiel. Sie kann also beliebig geändert werden, z.B.

            MASQ_MODULE_N='2'
            MASQ_MODULE_1='ftp'
            MASQ_MODULE_1_OPTION='ports=21,2121'
            MASQ_MODULE_2='irc'
            MASQ_MODULE_2_OPTION=''

Weitere Inhalte von MASQ_MODULE_x werden einfach ignoriert.

Hier wurde auch gleich ein Beispiel für die Parameter des FTP-Moduls angegeben.

Das Fli4l-Team
23. Februar 2006