Galileo Computing :: Linux

23.6 Firewalls

Als nächstes Thema soll mit Firewalls ein klassisches Zugangsschutzkonzept erläutert werden. Etwas Verwirrung entsteht dabei üblicherweise bereits durch den Begriff. Firewall bezeichnet unter anderem:

das Zugangsschutzsystem für ein Netzwerk an sich

einen Rechner, der einen Teil dieses Konzepts realisiert (»unsere Firewall«)

eine Software, die ein Zugangsschutzsystem implementiert (»eine Firewall installieren«)

Welche dieser Deutungen dem eigentlichen Begriff nun am nächsten kommt, erklärt sich aus dem allgemeinen Verständnis einer Firewall: Sie soll nämlich den Zugriff auf ein Rechnersystem beziehungsweise ein ganzes Netzwerk eben auf die Zugriffe beschränken, die explizit dafür vorgesehen sind. Als Konsequenz erscheint hier eine Beschränkung auf ein Stück Hard- oder Software nicht angemessen.

23.6.1 Grundlagen

Aber es ergibt sich auch eine weitere Konsequenz für den konkreten Aufbau einer Firewall. So sollte man nicht verbieten, was man nicht möchte, sondern man sollte erlauben, was erwünscht ist – alles andere ist per Default verboten. Nur so kann man potenziell alle Eventualitäten abdecken und den Missbrauch des eigenen Computersystems verhindern. Dieses Prinzip nennt man auch Default Deny.

Auch wenn eine Firewall sich nun nicht auf Software oder ein Stück Hardware reduzieren lässt, so kann man ohne diese Komponenten kein Zugangsschutzsystem errichten. Im Folgenden sollen zwei wichtige Firewall-Typen unterschieden werden:

Paketfilter und Personal Firewalls.

Paketfilter-Firewalls

Diese Firewalls filtern, wie der Name schon sagt, die TCP/IP-Pakete des Netzwerks. Dazu arbeiten sie typischerweise als Gateway und untersuchen die weitergeleitete oder auch für sie selbst bestimmte Kommunikation nach bestimmten Regeln, dem sogenannten Ruleset.

Die Regeln einer solchen Firewall sind typischerweise nach dem Default-Deny- Prinzip ähnlich dem folgenden Schema aufgebaut:

State-Regel

Die sogenannten stateful Firewalls können sich den Status bereits aufgebauter Verbindungen merken. Mit anderen Worten: Wurde ein Verbindungsaufbau bereits erlaubt, so kann die aufgebaute Verbindung (established connection) ohne weitere Beachtung durchgelassen werden. Oft wird eine solche Regel aber auch implizit angenommen und muss nicht extra definiert werden; außerdem handelt es sich bei nahezu allen halbwegs modernen Paketfilter-Firewall-Systemen um stateful Firewalls.

Erlaubte Kommunikation

In den folgenden Regeln werden die freizuschaltenden Ports und Wege definiert, zum Beispiel:
Erlaube jeden Traffic, der aus dem internen Netz kommt und auf Port 80 (http) gerichtet ist.
Damit hätte man den Mitarbeitern einer Firma beispielsweise schon das Surfen im Netz erlaubt. Oft sind sinnvollerweise auch der E-Mail-Verkehr und FTP-Dienste freigeschaltet. Wie das Konzept selbst nun aber genau aussieht, ist stark von den individuellen Bedürfnissen des Firewall-Betreibers abhängig.

Spätestens an dieser Stelle ist eine genaue Kenntnis der TCP/IP-Protokoll-Suite unerlässlich. Man kann keine sinnvollen Regeln definieren, wenn man sich in der Begrifflichkeit nicht gut bis sehr gut zurechtfindet.

Catch-all-Regel

In der letzten Regel wird jeglicher weiterer Traffic verboten.

Werden die Regeln nun von oben nach unten abgearbeitet, wird die Catch-all-Regel genau dann aktiv, wenn keine vorherige Regel gepasst hat. Dieser Traffic ist also nicht explizit erlaubt und wird durch diese Regel »aufgefangen« und blockiert.

Fallstudie

So eine Vorgehensweise setzt natürlich eine genaue Fallstudie vor der Regelerstellung und damit vor der eigentlichen Firewall-Konfiguration voraus. Es muss klar sein, welche Ports von wo wohin erlaubt sein sollen. Dazu muss unter Umständen der Traffic von Spezialanwendungen wie beispielsweise bestimmten Buchhaltungstools mit zentralem Server genau untersucht werden.

Sonst besteht die Gefahr, dass nach der Installation der Firewall erst einmal das gesamte Netz lahmgelegt wird.

Personal Firewalls

Personal Firewalls sind das, was man als gewöhnlicher Windows-Anwender unter einer Firewall versteht. Man installiert ein Programm, bei dem, übertrieben gesagt, die einzige Konfiguration im Wählen zwischen den Sicherheitsstufen »niedrig«, »mittel« und »hoch« besteht.

Eine Personal Firewall schützt einen einzelnen Rechner eines Netzwerks auf Applikationsebene.

Möchten sich dann einzelne Anwendungen mit dem Internet oder dem Netzwerk verbinden, bekommt der Anwender je nach getroffener Einstellung eine Meldung wie:

Anwendung »xyz« möchte eine Verbindung mit dem Internet aufnehmen. Soll diese Verbindung gestattet werden?

Man kann also sehen, dass eine solche Firewall prinzipiell auf einer anderen OSI- Ebene arbeitet als die Paketfilter. Trotzdem werden natürlich sinnvollerweise bei Personal Firewalls oft auch alle eingehenden Verbindungen mehr oder weniger blockiert, da eine Workstation kaum als Server fungieren wird.

Im Zusammenhang mit Firewalls stehen auch die Begriffe »NAT« (Network Address Translation) und »Masquerading«. Das Masquerading ist dabei ein Spezialfall der Adressübersetzung NAT.

Masquerading

LAN ans Netz bringen

Wozu man Masquerading braucht, wird schnell klar, wenn man sich wieder einmal ein typisches Netzwerk vor Augen führt. Dort werden nämlich intern inoffizielle IP-Adressen nach RFC1918 eingesetzt.

Diese werden im Internet nicht geroutet, und daher muss eine »Übersetzung« in offizielle IP-Adressen erfolgen.

Man benutzt private IP-Adressen, weil

einem die öffentlichen IP-Adressen knapp geworden sind,

man die echten IP-Adressen verbergen will (security through obscurity)

oder weil man schlicht den Sinn dieses Vorgehens verstanden hat. <Siehe auch Kapitel 10.>

**Tabelle 23.1** Private IP-Adressbereiche
Adressbereich	Netzmaske	CIDR-Schreibweise
10.0.0.0 – 10.255.255.255	255.0.0.0	10.0.0.0/8
172.16.0.0 – 172.31.255.255	255.240.0.0	172.16.0.0/12
192.168.0.0 – 192.168.255.255	255.255.0.0	192.168.0.0/16

Meist gibt es dann weiterhin ein Gateway mit Paketfilter, das über einen Breitbandanschluss mit dem Internet verbunden ist. Würden die Pakete einfach wie von einem normalen Gateway oder Router nur weitergeleitet werden, könnten die Adressen aufgrund ihrer definierten Unroutebarkeit spätestens beim Provider nicht mehr weitergeleitet werden.

Wird nun aber auf dem Gateway die ursprüngliche private und damit interne IP-Adresse des Absenderrechners durch die offizielle IP-Adresse des Gateways ersetzt, so spricht man von Masquerading. Natürlich muss für eine erfolgreiche Kommunikation zwischen Server und Client das Gateway die vom Server an die offizielle IP-Adresse geschickten Antwortpakete wieder »zurückübersetzen«, indem es die Ziel-IP-Adresse wieder in die private IP-Adresse des Rechners im LAN ändert. So ist dieser Vorgang sowohl für den Server als auch für den Client transparent.

NAT

Network Address Translation (NAT) an sich bietet dagegen eine voll qualifizierte Adressübersetzung.

Es ist damit also auch die dem Masquerading entgegengesetzte Adressübersetzung möglich, bei der zum Beispiel einzelne Ports auf der offiziellen IP-Adresse an bestimmte Rechner im internen Netz weitergeleitet werden können.

So kann man beispielsweise Serverdienste, die eigentlich nur auf dem Masquerading-Gateway beziehungsweise eben der Firewall laufen könnten, eben doch auf andere Rechner auslagern – und so die Angreifbarkeit der Firewall selbst deutlich reduzieren.

Ansonsten unterscheidet man in der Literatur oft auch zwischen

Source-NAT (SNAT) und

Destination-NAT (DNAT),

je nachdem, welche Adresse aus der Sicht des Routers beziehungsweise der Firewall in andere Adressen übersetzt werden soll. Da aber sowohl der eine als auch der andere Begriff nur Spezialfälle beschreiben, wollen wir diese Unterscheidung, sofern sie im Folgenden vermeidbar ist, nicht weiter benutzen.

23.6.2 Firewalling unter Linux: netfilter/iptables

Damit ein Betriebssystem überhaupt so etwas wie eine Paketfilter-Firewall unterstützen kann, wird entsprechender Support im Kernel benötigt. Diese Schnittstellen werden unter Linux als netfilter bezeichnet. Das entsprechende Frontend für den Userspace ist dabei iptables.

Mit dem iptables-Tool legt man also im Userspace nach einem definierten Format die Firewallregeln fest, die dann über das netfilter-Interface im Kernel aktiv werden. Ein iptables Aufruf setzt sich dabei aus folgenden Komponenten zusammen:

Tabelle

Zuerst muss man angeben, um was für eine Regel es sich handelt – eine Paketfilter- oder eine NAT-Regel.

Kette

Als Nächstes wird spezifiziert, auf welche Kette sich der folgende Regelausdruck bezieht und ob die folgende Regel einzufügen oder zu löschen ist. Filterketten sind dabei für den Paketfilter:

INPUT

In dieser Kette sind alle Regeln für die Pakete erhalten, die für den eigenen Rechner bestimmt sind.

OUTPUT

In dieser Kette werden alle Regeln eingefügt, die auf ausgehende Pakete angewandt werden sollen.

FORWARD

In dieser Kette werden alle weiterzuleitenden Pakete verarbeitet.

Filterausdruck

Hier legt man fest, auf welche Pakete sich die Regel genau beziehen soll. Fehlt dieser Filterausdruck, so bezieht man sich auf alle Pakete der betreffenden Kette.

Ziel

Was soll schließlich mit den passenden Paketen gemacht werden?

23.6.3 Iptables im Detail

Einige Optionen haben wir bereits im letzten Abschnitt besprochen. Im Folgenden wollen wir die verfügbaren Optionen, sofern sie nicht zu sehr ins Detail gehen, noch einmal zusammenfassen.

Operationen direkt auf Ketten

Da wären als Erstes die Kommadozeilenoptionen, die direkt auf den Ketten operieren:

-N Kette

Eine neue Kette anlegen. Benötigt wird weiterhin der Kettenname.

-X (Kette)

Eine Kette löschen. Wird keine Kette explizit angegeben, wird versucht, alle vom Benutzer angelegten Ketten zu löschen.

-E alterName neuerName

Mit dieser Option kann eine Kette umbenannt werden. Dies hat nur kosmetische Wirkung, da nichts an der Struktur der Firewall geändert wird.

-P Kette

Die Policy für eine der eingebauten Ketten (INPUT, FORWARD oder OUTPUT) ändern. Sinnvolle Werte für eine Policy sind dabei ACCEPT und DROP. Standardmäßig – also wenn etwa nach dem Booten noch keine Firewall aktiviert ist – sind die Policies auf ACCEPT gestellt.

-L (Kette)

Diese Option listet die Regeln einer bestimmten Kette oder – falls keine Kette explizit angegeben wurde

– aller Ketten auf.

-F (Kette)

Eine Kette beziehungsweise alle Ketten flushen, d. h., alle Regeln löschen.

-Z (Kette)

Den Paket- und Bytezähler aller Regeln einer Kette auf null stellen.

Sie werden sich vielleicht bereits gefragt haben, warum man nur auf die eingebauten Ketten Policies definieren kann. Der Grund dafür liegt in der Handhabung benutzerdefinierter Ketten: Durchläuft ein Paket eine solche Kette, ohne auf einen Filterausdruck zuzutreffen, so wird die Verarbeitung des Pakets in der aufrufenden Kette an der entsprechenden Stelle fortgesetzt.

Policies definieren

Man benötigt also nur für die Standardketten, die die Pakete auf jeden Fall durchlaufen, eine solche Möglichkeit, ein »generelles Verhalten« festzulegen.

Operationen auf Regeln

Wenn man die Ketten angelegt und verwaltet hat, möchte man natürlich Regeln angeben und spezifizieren.

Die folgenden Optionen sind die wichtigsten iptables-Parameter für diesen Zweck.

-A Kette Regel

Eine neue Regel an einer Kette anhängen.

-I Kette (Position) Regel

Eine neue Regel in eine Kette einfügen. Gibt man keine Position der neuen Regel an, so wird diese standardmäßig an der ersten Position der Kette eingefügt.

-R Kette Position Regel

Mit dieser Option kann man eine Regel an einer bestimmten Position durch eine neue Regel ersetzen.

-D Kette Regelnummer/Regel

Über »-D« kann man eine Regel löschen, und zwar entweder unter Angabe der Regelnummer oder der Regel selbst.

Wenn man ein Skript schreibt, wird man eigentlich nur die Option »-A« benötigen, die restlichen Parameter sind im Prinzip nur der Vollständigkeit halber implementiert.

Regeln definieren

Im Folgenden soll uns der Punkt interessieren, den wir in der Beschreibung der Regelparameter im letzten Abschnitt schlicht mit »Regel« umschrieben haben. Eine Regel ist dabei, wie Sie bereits im Beispiel gesehen haben, eine Kombination von Filterausdrücken und einem Ziel.

Die Filterausdrücke schränken dabei selbstverständlich ein, auf welche Pakete die Regel zutreffen soll, und damit auch, auf welche Pakete letztendlich das angegebene Ziel angewendet werden soll.

Ziele können dabei vor allem folgende Werte sein:

Das Paket soll erlaubt werden, sofern es auf diese Regel zutrifft.

DROP

Das Paket soll verworfen werden, die Kommunikation wird also nicht erlaubt.

QUEUE

Falls der Kernel dies unterstützt, kann man mit dieser Option das Paket in den Userspace weiterleiten.

RETURN

Wenn man sich in einer benutzerdefinierten Kette befindet, kann man mit diesem Ziel in die aufrufende Kette zurückspringen. Die aufrufende Kette wird dabei ab der Stelle weiter durchlaufen, von der aus in die benutzerdefinierte Kette gesprungen wurde.

Dieses Ziel bietet die Möglichkeit, bei bestimmten Paketen einen Eintrag im Kernel-Log zu erzeugen. Weitere wichtige von diesem Ziel bereitgestellte iptables-Optionen sind dabei:
- --log-level
- Gefolgt von einer Level-Nummer oder einem Namen. Erlaubte Namen sind (man achte auf Groß- und Kleinschreibung) 'debug', 'info', `notice', 'warning', 'err', 'crit', 'alert' und 'emerg', entsprechend dazu die Nummern 7 bis 0. Die Manpage des syslogd bietet mehr Informationen zu diesen Leveln.
- --log-prefix
- Gefolgt von einem String von bis zu 30 Zeichen, der zu Beginn der Logmeldung gesetzt wird.

REJECT

Dieses Ziel hat denselben Effekt wie DROP, außer dass dem Absender noch eine ICMP-»Port unreachable«-Fehlermeldung geschickt wird. Man ist also nett und sagt explizit, dass ein Dienst nicht verfügbar ist, anstatt den anderen Verbindungsendpunkt »verhungern« zu lassen. Manche Systemadministratoren argumentieren gegen eine solche fast »freundliche« Absage, dass man mit DROP Portscans ausbremsen könne. Dem ist aber nicht so, da jeder halbwegs intelligent programmierte Portscanner solche Wartezeiten mit einem Timeout abfängt. Ein REJECT hat hingegen den Vorteil, dass es die eigene Netzwerkperformance sowie die harmloser Benutzer deutlich erhöhen kann.

»Kette«

Selbstverständlich kann man als Ziel auch eine benutzerdefinierte Kette angeben, wie wir es bereits im ersten Beispielskript gesehen haben. Natürlich kann man auch aus einer benutzerdefinierten Kette in eine weitere benutzerdefinierte Kette springen – sobald der Kernel allerdings feststellt, dass sich ein Paket in einer Schleife befindet, wird es verworfen.

Natürlich muss man sich bei der Regelerstellung immer vor Augen halten, dass die Regeln der Reihe nach durchlaufen werden und dass, sobald eine Regel für ein Paket passt, die Verarbeitung abgebrochen wird – sei es, weil ein Ziel wie ACCEPT oder DROP das Schicksal des Pakets endgültig besiegelt oder weil die Verarbeitung in einer anderen Kette fortgesetzt werden soll.

Standardverhalten

Zu erwähnen bleibt nur noch, wie sich Pakete am Ende von Ketten verhalten. Handelt es sich um eine benutzerdefinierte Kette, wird die Verarbeitung an der entsprechenden Stelle in der aufrufenden Kette fortgeführt. Ist die Kette allerdings eine der eingebauten Standardketten, so tritt das Ziel der Policy in Kraft. Das tut sie auch, wenn in einer eingebauten Kette das RETURN-Ziel auftaucht.

Es gibt vor allem für NAT natürlich noch mehr Ziele, die wir auszugsweise an geeigneter Stelle beschreiben werden. Im Folgenden wollen wir aber zuerst auf die normalen iptables-Optionen eingehen:

-t Tabelle

Dies ist eine der wichtigsten Optionen. Wie wir bereits gesehen haben, kann iptables/netfilter neben der normalen Paketfilterfunktionalität noch NAT sowie diverse Paketveränderungen vornehmen. Auf welche dieser Funktionalitäten man zugreifen will, gibt man daher über diese Option an:
- filter
- Diese Tabelle bezeichnet den normalen Paketfilter und ist auch die Vorgabe, wenn man die Option »-t« weglässt. In dieser Tabelle stehen uns die bereits bekannten INPUT-, OUTPUT- und FORWARD-Ketten zur Verfügung. Jedes Paket muss die (entsprechende) Kette(n) dieser Tabelle durchlaufen.
- nat
- Diese Tabelle wird überprüft, sobald ein Paket eine neue Verbindung aufbaut. Es stehen die folgenden Ketten zur Verfügung: PREROUTING (für das Verändern von Paketen vor dem Routing und direkt nach dem Eintreffen), OUTPUT (für das Verändern von lokal generierten Paketen vor dem Routing) und POSTROUTING (für das Verändern von Paketen nach dem Routing und kurz vor dem Weiterversenden). Die Ketten sind also ähnlich angeordnet wie die bereits beschriebenen Standardketten des Paketfilters, besitzen aber natürlich eine andere Semantik. Diese wird deutlich, wenn man sich veranschaulicht, dass PREROUTING für DNAT von weitergeleiteten Paketen, OUTPUT für DNAT von lokal generierten Paketen und POSTROUTING für SNAT von jeweils allen Paketen benötigt wird.
- mangle
- Diese Tabelle benötigt man für das Verändern von Paketen. Seit Kernel 2.4.18 kann man in dieser Tabelle Pakete in allen Ketten (der beiden anderen Tabellen) verändern. Allerdings sollte man beachten, dass Pakete entsprechend ihrer Semantik auch mehrere Ketten durchlaufen können.

-j Ziel

Diese wohl wichtigste Option gibt als Ziel einer Regel an, welches Schicksal dem Paket zuteil wird. Achtung: Diese Option darf auch fehlen! Die Regel hat dann auf die Pakete, auf die sie zutrifft, keine Auswirkungen. Allerdings wird trotzdem der Zähler für die Pakete erhöht. <Mit der »-Z«-Option kann man diesen Zähler wieder auf null stellen.>

Die Filterausdrücke, die ein Paket nun für eine Regel auswählen, sind zum Teil abhängig von geladenen Erweiterungen (zum Beispiel über »-m«, wie im Beispiel gesehen) oder von speziellen Zielen und anderen Parametern.

Diese Filteroptionen lassen sich jeweils auch über ein Ausrufezeichen (»!«) negieren, und alle Rechner- oder Netzwerkadressen können in fast allen geläufigen Darstellungsformen angegeben werden, zum Beispiel als:

Netzwerkname

Rechnername <Sie sollten allerdings darauf achten, dass diese Namen nicht erst remote mit DNS oder ähnlichen Diensten aufgelöst werden müssen!>

Netzwerkadresse samt Netzwerkmaske

einfache IP-Adresse

Aber sehen wir uns zuerst die immer verfügbaren einfachen Optionen an:

-s Quelle

Der Absender (Quelle, engl. source) eines Pakets. Wie gesagt kann man hier nach Netzwerken oder einzelnen Rechnern filtern.

-d Ziel

Der Empfänger (Ziel, engl. destination) eines Pakets.

-i Interface

Das Interface, auf dem ein Paket angekommen ist (in-interface). Natürlich funktioniert diese Option nur auf den INPUT-, FORWARD- und PREROUTING-Ketten.

-o Interface

Das Interface, auf dem ein Paket den Rechner verlassen wird (out-interface).

Analog zur Option »-i« funktioniert dieser Parameter nur in Zusammenhang mit den FORWARD-, OUTPUT- und POSTROUTING- Ketten.

-p Protokoll

Damit kann man das Protokoll genauer spezifizieren. Meistens gibt man an dieser Stelle entweder »tcp«, »udp«, »icmp« oder »all« an. Durch Spezifizierung des Protokolls kann man weitere Extensions laden und damit genauere Optionen zum Angeben des Filters nutzen (zum Beispiel könnte man auf diverse TCP-Flags beim Angeben von »-p tcp« prüfen).

Die wichtigsten Erweiterungen samt der durch sie zur Verfügung gestellten Flags wollen wir in der folgenden Übersicht zusammenstellen. Die Liste ist bei Weitem nicht vollständig, daher müssen wir Sie erneut auf die Manpage von iptables verweisen, wenn Sie detailliertere Informationen suchen.

Die TCP-Erweiterung wird wie gesagt durch den Parameter »-p tcp« geladen und stellt unter anderem folgende weitere Kommandozeilenoptionen zur Verfügung:
- --source-port port(:port) --destination-port port(:port)}
- Über diese beiden Direktiven kann man einzelne Ports beziehungsweise über den Doppelpunkt auch ganze Portranges ansprechen. An diesem Beispiel wird auch deutlich, warum dieser Parameter erst durch die Angabe von »-p tcp« möglich wird: Das ICMP-Protokoll kennt zum Beispiel keine Ports.
- - -tcp-flags Maske gesetzt
- Mit dieser Option können die TCP-Flags eines Pakets überprüft werden. Das Ganze funktioniert dann so, dass man im ersten Argument »Maske« eine durch Kommas getrennte Liste aller zu überprüfenden Flags (SYN, ACK, FIN, RST, URG, PSH, ALL oder NONE) angeben muss. Im zweiten Argument muss man angeben, welche dieser Flags gesetzt sein müssen, damit das Paket vom Filter durchgelassen wird. Alle anderen in der Maske angegebenen Flags dürfen nicht gesetzt sein.
```
iptables -A FORWARD -p tcp --tcp-flags SYN,ACK, \ 
  RST SYN -j DENY
```
Listing 23.1 Beispiel: SYN-Pakete
- Das Beispiel würde also auf alle Pakete zutreffen, die das SYN-Flag gesetzt und das ACK- sowie das RST-Flag nicht gesetzt haben.
- --syn
- Dieser Parameter ist die Abkürzung für das obige Beispiel zu SYN-Paketen, die ja im TCP-3-Wege-Handshake einen Verbindungsaufbau initiieren (siehe Kapitel 10).

state

Dieses Modul kann man, wie Sie im Beispiel gesehen haben, über den »-m«-Parameter laden, sofern das ip_conntrack-Modul geladen ist. Dadurch wird dann der folgende Parameter bereitgestellt:
- --state Status
- Hier kann man den Status der Pakete spezifizieren. Mögliche Werte sind dabei INVALID (das Paket gehört zu keiner bekannten Verbindung), ESTABLISHED (das Paket gehört zu einer bereits aufgebauten Verbindung), NEW (das Paket gehört zu keiner Verbindung und baut eine neue Verbindung auf) und RELATED (das Paket gehört zu einer Verbindung und baut eine neue Verbindung auf, beispielsweise beim FTP-Datentransfer).

owner

Dieses Modul soll stellvertretend für viele weitere Match-Extensions stehen. Wenn der Kernel nämlich entsprechenden Support bietet, kann über diese mit -m owner geladene Erweiterung iptables schon fast mit Funktionen ähnlich einer Personal Firewall versorgt werden.
Funktionalität einer Personal Firewall

Prinzipiell arbeitet das Modul nur auf der OUTPUT-Kette und untersucht dort den Ersteller des Pakets. Natürlich kann es auch vorkommen, dass ein Paket – beispielsweise eine ICMP-Kontrollnachricht – keinen Besitzer hat und so gar nicht erfasst werden kann. Für alle anderen Pakete werden aber folgende Erweiterungen zur Verfügung gestellt:
- --uid-owner Userid
- Diese Regel trifft zu, wenn das Paket von dem Benutzer mit der entsprechenden UID erstellt wurde. <Natürlich wird diese ID über die Benutzer-ID des Prozesses festgestellt, der das Paket erzeugt hat. Insofern könnte es also Probleme mit suid-Rechten geben.>
- --gid-owner Groupid
- Diese Erweiterung bezieht sich auf die Gruppen-ID (GID) des Prozesses.
- --cmd-owner Name
- Hier kann man auf den Namen des erzeugenden Prozesses prüfen.
Auch wenn man über dieses Modul die Anwendungsschicht mit in das Regelwerk integrieren kann, sollte man sich nicht täuschen lassen: Bei iptables handelt es sich immer noch um einen Paketfilter.

So weit unser kurzer Überblick über die iptables-Paketfilteroptionen.

Für weitere Informationen sowie für eine Übersicht über alle verfügbaren Match-Extensions sei Ihnen nochmals die Manpage empfohlen.

iptables und NAT

Diese Thematik wollen wir nicht zu sehr vertiefen, da mit dem Beispiel zu Masquerading schon die wichtigste und am meisten genutzte Anwendung erklärt wurde und dieses Buch schließlich keine iptables-Referenz darstellt.

NAT-Tabelle

Im Folgenden sollte klar sein, dass wir für NAT mit der Option -t nat die entsprechende Tabelle und natürlich auch die dort gültigen Ketten ansprechen müssen. Ansonsten benötigen wir natürlich wieder entsprechende Erweiterungen, also unsere Match-Extensions. Match-Extensions werden bei NAT vor allem über die Angabe eines entsprechenden Ziels geladen:

-j DNAT

Mit diesem Ziel lädt man die Erweiterungen für Destination-NAT. Natürlich funktioniert dieses nur auf der PREROUTING- und der OUTPUT-Kette, da schließlich das Ziel einer Verbindung geändert werden soll. Dafür wird eine weitere Option zur Verfügung gestellt:
- --to-destination IP(-IP)(:Port-Port)
- So kann man ein einfaches neues Ziel, eine ganze Range von neuen Zieladressen sowie – falls man -p tcp oder -p udp angegeben hat – optional auch eine Portrange angeben.

Gibt man mehrere dieser Optionen oder eben eine Adress- beziehungsweise Portrange an, so wird ein einfaches Round-Robin-Verfahren angewendet. Mit anderen Worten: Es werden alle möglichen Zieladressen der Reihe nach verwendet, was ein sehr einfaches Loadbalancing ermöglicht.

-j SNAT

Dieses Ziel funktioniert im Gegensatz zu DNAT nur auf der POSTROUTING-Kette. Ansonsten ist der Kontext und das prinzipielle Verhalten dem DNAT recht ähnlich:
- - -to-source IP(-IP)(:Port-Port)
- Entsprechend dem DNAT kann man hier die neue(n) Quelladresse(n) und eventuell Quellports angeben.

-j MASQUERADE

Dieses Ziel kennen Sie bereits aus dem Beispielskript zu Masquerading. Eigentlich ist Masquerading ja nichts anderes als SNAT (und gilt damit auch nur in der POSTROUTING-Kette), es bietet aber noch einige sinnvolle Erweiterungen.

Masquerading- Eigenschaften

Die Quelladresse wird nämlich implizit auf die IP-Adresse der Schnittstelle geändert, auf der das Paket den Rechner verlässt. Außerdem werden alle Verbindungen »vergessen«, wenn das Interface deaktiviert wird, was das korrekte Verhalten bei Dialup-Verbindungen darstellt.

Mit diesen Hilfen, der Manpage und vielleicht einigen Beispielskripts aus dem Internet sollten Sie nun in der Lage sein, Ihre eigene kleine Firewall mit iptables aufzusetzen. Dazu wollen wir noch einmal einen kurzen Überblick über den Regelaufbau geben.

Abschließender Überblick

Fassen wir also noch einmal zusammen: Ein iptables-Befehl setzt sich aus folgenden Komponenten zusammen:

Tabelle

Meist wird mit »-t filter« die Paketfiltertabelle automatisch bestimmt, ansonsten kann man aus dieser Option erkennen, welche Funktionalität die Regel besitzen soll.

Kette

Als Nächstes wird spezifiziert, auf welche Kette sich der folgende Regelausdruck bezieht und ob die folgende Regel einzufügen oder zu löschen ist.

Filterausdruck

Hier legt man fest, auf welche Pakete sich die Regel beziehen soll. Fehlt dieser Filterausdruck, so bezieht man sich auf alle Pakete.

Ziel

Was soll mit den passenden Paketen gemacht werden?

Wenn Sie diesen Aufbau eines iptables-Befehls vor Augen halten, sollte für Sie kein Firewall-Skript mehr Rätsel bergen.

Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.