32.6 Firewalls
Als nächstes Thema erläutern wir mit den Firewalls ein klassisches Zugangsschutzkonzept. Etwas Verwirrung entsteht dabei üblicherweise bereits durch den Begriff. Firewall bezeichnet unter anderem:
- das Zugangsschutzsystem für ein ganzes Netzwerk
- einen Rechner, der einen Teil dieses Konzepts realisiert (»unsere Firewall«)
- eine Software, die ein Zugangsschutzsystem implementiert (»eine Firewall instal- lieren«)
Welche dieser Bedeutungen dem eigentlichen Begriff nun am nächsten kommt, erklärt sich aus dem allgemeinen Verständnis einer Firewall: Diese soll die Zugriffe auf ein Rechnersystem beziehungsweise ein ganzes Netzwerk beschränken, die explizit dafür vorgesehen sind. Folglich erscheint hier eine Beschränkung des Begriffs auf ein Stück Hard- oder Software nicht angemessen.
32.6.1 Grundlagen
Es ergibt sich jedoch noch eine weitere Konsequenz für den konkreten Aufbau einer Firewall. So sollte man grundsätzlich 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 alle Eventualitäten abdecken und den Missbrauch des eigenen Computersystems verhindern. Dieses Prinzip nennt man auch Default Deny.
Auch wenn sich eine Firewall nicht auf eine Software oder ein Stück Hardware reduzieren lässt, so kann man doch ohne diese beiden 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 entsprechend 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. - Erlaubte Kommunikation
In den folgenden Regeln werden die freizuschaltenden Ports und Wege definiert, zum Beispiel wie folgt:
Oft wird eine solche Regel aber auch implizit angenommen und muss nicht eigens definiert werden; außerdem handelt es sich bei nahezu allen halbwegs modernen Paketfilter-Firewall-Systemen um Stateful Firewalls.
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.
Werden die Regeln nun von oben nach unten abgearbeitet, so 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, auf welchen Ports Traffic von welchem Ausgangssystem zu welchem Zielsystem erlaubt sein soll. Dazu muss unter Umständen der Traffic von Spezialanwendungen wie beispielsweise von bestimmten Buchhaltungstools mit dem zentralen 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 in der Wahl zwischen den Sicherheitsstufen »niedrig«, »mittel« und »hoch« besteht.
Eine Personal Firewall schützt einen einzelnen Rechner eines Netzwerks (hauptsächlich 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 nahezu alle eingehenden Verbindungen blockiert, da ein Arbeitsplatzrechner 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 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)
| 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 darüber hinaus 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, so könnten die Adressen aufgrund ihrer definierten Unroutebarkeit spätestens beim Provider nicht mehr weitergeleitet werden.
Wird nun aber auf dem Gateway die ursprngliche, 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
Die Network Address Translation (NAT) an sich bietet dagegen eine voll qualifizierte Adressübersetzung. Somit ist 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 der Firewall laufen könnten, eben doch auf andere Rechner auslagern – und so die Angreifbarkeit der Firewall selbst deutlich reduzieren.
Oft unterscheidet man in der Literatur 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 beide Begriffe nur Spezialfälle beschreiben, wollen wir diese Unterscheidung im Folgenden nach Möglichkeit nicht weiter benutzen.
32.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 Firewall-Regeln 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 der Filterausdruck, so bezieht man sich auf alle Pakete der betreffenden Kette. - Ziel
Was soll mit den passenden Paketen schließlich gemacht werden?
32.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 sind zunächst die Kommadozeilenoptionen, die direkt auf den Ketten operieren:
- -N Kette
Legt eine neue Kette an. Benötigt wird außerdem der Kettenname. - -X (Kette)
Löscht eine Kette. Wird keine Kette explizit angegeben, so 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
Ändert die Policy für eine der eingebauten Ketten (INPUT, FORWARD oder OUTPUT). 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 – die Regeln aller Ketten auf. - -F (Kette)
Löscht die Regeln einer Kette beziehungsweise aller Ketten (flush). - -Z (Kette)
Stellt den Paket- und Bytezähler aller Regeln einer Kette auf Null.
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 dass es auf einen Filterausdruck zutrifft, 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 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 eine 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.
Schreibt man ein Skript, wird man eigentlich nur die Option -A benötigen, die restlichen Parameter sind nur der Vollständigkeit halber implementiert.
Regeln definieren
Im Folgenden beschäftigen wir uns mit Regeln. Eine Regel ist, wie Sie bereits im Beispiel gesehen haben, die Kombination von Filterausdrücken und einem Ziel.
Die Filterausdrücke schränken dabei ein, auf welche Pakete die Regel zutreffen soll, und somit auch, auf welche Pakete letztendlich das angegebene Ziel angewendet werden soll. Ziele können dabei vor allem folgende Werte sein:
- ACCEPT
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. Diese wird dann ab der Stelle weiter durchlaufen, von der aus in die benutzerdefinierte Kette gesprungen wurde. - LOG
Dieses Ziel bietet die Möglichkeit, bei bestimmten Paketen einen Eintrag im Kernel-Log zu erzeugen. Weitere wichtige von diesem Ziel bereitgestellte Optionen sind dabei: - --log-level
Diese Option wird 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
Diese Option wird 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 teilt explizit mit, dass ein Dienst nicht verfügbar ist, anstatt den anderen Verbindungsendpunkt »verhungern« zu lassen. - »Kette«
Selbstverständlich kann man als Ziel auch eine benutzerdefinierte Kette angeben. Auch aus einer solchen Kette lässt es in eine weitere benutzerdefinierte Kette springen – sobald der Kernel allerdings feststellt, dass sich ein Paket in einer Schleife befindet, wird es verworfen.
Manche Systemadministratoren argumentieren gegen eine solche »freundliche« Absage, dass man mit DROP Port-Scans ausbremsen könne. Dem ist aber nicht so, da jeder halbwegs intelligent programmierte Port-Scanner 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.
Man muss sich bei der Regelerstellung immer bewusst sein, 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
Bleibt zu erwähnen, wie sich Pakete am Ende von Ketten verhalten. Handelt es sich um eine benutzerdefinierte Kette, so 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 – auch dann, wenn in einer eingebauten Kette das RETURN-Ziel auftaucht.
Insbesondere bei NAT gibt es noch mehr Ziele, die wir auszugsweise an geeigneter Stelle beschreiben werden. Im Folgenden wollen wir 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 auch NAT sowie diverse Paketveränderungen vornehmen. Auf welche Funktionalität man zugreifen will, gibt man daher über diese Option an: - filter
Diese Tabelle bezeichnet den normalen Paketfilter. Sie ist standardmäßig eingestellt, wenn man die Option -t weglässt. In ihr stehen die bereits bekannten INPUT-, OUTPUT- und FORWARD-Ketten zur Verfügung. Jedes Paket muss die entsprechende(n) 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). - 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: Sie 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. [Fn. Mit der -Z-Option kann man diesen Zähler wieder auf Null stellen.]
Die Ketten sind also ähnlich angeordnet wie die bereits beschriebenen Standardketten des Paketfilters, besitzen jedoch eine andere Semantik. Diese wird deutlich, wenn man sich vor Augen führt, dass PREROUTING für DNAT von weitergeleiteten Paketen, OUTPUT für DNAT von lokal generierten Paketen und POSTROUTING für SNAT von allen Paketen benötigt wird.
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. Sie 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 [Fn. 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
Betrachten wir zuerst die immer verfügbaren einfachen Optionen:
- -s Quelle
Der Absender (Quelle, engl. source) eines Pakets – hier kann man 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 im Zusammenhang mit den FORWARD-, OUTPUT- und POSTROUTING-Ketten. - -p Protokoll
Mit dieser Option können Sie 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 keineswegs vollständig, daher verweisen wir Sie erneut auf die Manpage von iptables für detailliertere Informationen.
- tcp
Die TCP-Erweiterung wird 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 Port-Ranges ansprechen. Hier wird auch deutlich, warum dieser Parameter erst durch die Angabe des Parameters -p tcp möglich wird: Das ICMP-Protokoll kennt zum Beispiel keine Ports. - --tcp-flags Maske Flags
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) angibt. Im zweiten Argument gibt man an, welche davon gesetzt sein müssen, damit das Paket vom Filter durchgelassen wird. Alle anderen in der Maske angegebenen Flags dürfen nicht gesetzt sein. - --syn
Dieser Parameter ist die Abkürzung für das im obigen Listing gezeigte Beispiel zu SYN-Paketen, die ja im TCP-3-Wege-Handshake einen Verbindungsaufbau initiieren. - state
Dieses Modul können Sie, wie im Beispiel gesehen, über den Parameter -m laden, sofern das ip_conntrack-Modul geladen ist. Dadurch wird dann der folgende Parameter bereitgestellt: - --state Status
Mit diesem Parameter können Sie 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 ausgestattet werden. - --uid-owner UID
Diese Regel trifft zu, wenn das Paket von dem Benutzer mit der entsprechenden UID erstellt wurde. [Fn. 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 GID
Diese Erweiterung bezieht sich auf die Gruppen-ID des Prozesses. - --cmd-owner Name
Hier können Sie auf den Namen des erzeugenden Prozesses prüfen.
TCP-Flags überprüfen
Listing 32.1 Beispiel: SYN-Pakete
iptables -A FORWARD -p tcp --tcp-flags SYN,ACK, \
RST SYN -j DENY
Das Beispiel würde also auf alle Pakete zutreffen, die das SYN-Flag gesetzt und das ACK- sowie das RST-Flag nicht gesetzt haben.
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 deshalb gar nicht erfasst werden kann.
Für alle anderen Pakete werden aber folgende Erweiterungen zur Verfügung gestellt:
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 empfehlen wir Ihnen nochmals die Manpage.
iptables und NAT
Diese Thematik wollen wir nicht zu sehr vertiefen, da wir mit dem Beispiel zu Masquerading schon die wichtigste und am häufigsten genutzte Anwendung erklärt haben 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 Port-Range angeben. - -j SNAT
Dieses Ziel funktioniert im Gegensatz zu DNAT nur auf der POSTROUTING-Kette. Davon abgesehen sind 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 Quell-Ports angeben.
- --to-source IP(-IP)(:Port-Port)
- -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.
Gibt man mehrere dieser Optionen oder eben eine Adress- beziehungsweise Port-Range 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.
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 Dial-up-Verbindungen darstellt.
Mit diesen Hilfen, der Manpage und vielleicht noch einigen Beispielskripten 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
Ein iptables-Befehl setzt sich aus folgenden Komponenten zusammen:
- Tabelle
Meist wird die Paketfiltertabelle mit der Option -t filter automatisch bestimmt, ansonsten kann man an 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 sie sich auf alle Pakete. - Ziel
Was soll mit den passenden Paketen gemacht werden?
Wenn Sie diesen Aufbau eines iptables-Befehls präsent haben, 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.
