Galileo Computing < openbook > Galileo Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort
1 Einleitung
TEIL I: Einstieg in Linux
2 Die Installation
3 Erste Schritte
4 Linux als Workstation für Einsteiger
TEIL II: Grundlagen
5 Kernel
6 Grundlagen aus Anwendersicht
TEIL III: Die Shell
7 Die Shell
8 Reguläre Ausdrücke
9 Konsolentools
10 Die Editoren
11 Shellskriptprogrammierung mit der bash
12 Die C-Shell
TEIL IV: System- & Netzwerkadministration
13 Benutzerverwaltung
14 Grundlegende Verwaltungsaufgaben
15 Netzwerkgrundlagen
16 Anwendersoftware für das Netzwerk
17 Netzwerkdienste
18 Mailserver unter Linux
19 LAMP & Co.
20 DNS-Server
21 Secure Shell
TEIL V: Die grafische Oberfläche
22 Die grafische Oberfläche
23 Window-Manager und Desktops
24 X11-Programme
25 Multimedia und Spiele
TEIL VI: Systeminterna
26 Prozesse und IPC
27 Bootstrap und Shutdown
28 Dateisysteme
29 Virtualisierung und Emulatoren
TEIL VII: Programmierung und Sicherheit
30 Softwareentwicklung
31 Crashkurs in C und Perl
32 Einführung in Computersicherheit
33 Netzwerksicherheit überwachen
TEIL VIII: Anhang
A Lösungen zu den einzelnen Aufgaben
B Kommandoreferenz
C X11-InputDevices
D MBR
E Buch-DVDs
F Glossar
G Literatur
Stichwort

Download:
- ZIP, ca. 20,7 MB
Buch bestellen
Ihre Meinung?

Spacer
Linux von Johannes Plötner, Steffen Wendzel
Das umfassende Handbuch
Buch: Linux

Linux
Galileo Computing
1282 S., 5., aktualisierte Auflage 2012, geb., mit 2 DVDs
49,90 Euro, ISBN 978-3-8362-1822-1
Pfeil 32 Einführung in Computersicherheit
Pfeil 32.1 Sicherheitskonzepte
Pfeil 32.2 Unix und Sicherheit
Pfeil 32.2.1 Benutzer und Rechte
Pfeil 32.2.2 Logging
Pfeil 32.2.3 Netzwerkdienste
Pfeil 32.3 Grundlegende Absicherung
Pfeil 32.3.1 Nach der Installation
Pfeil 32.3.2 Ein einfaches Sicherheitskonzept
Pfeil 32.4 Backups und Datensicherungen
Pfeil 32.4.1 Backup-Strategien
Pfeil 32.4.2 Software
Pfeil 32.5 Updates
Pfeil 32.6 Firewalls
Pfeil 32.6.1 Grundlagen
Pfeil 32.6.2 Firewalling unter Linux: Netfilter/iptables
Pfeil 32.6.3 iptables im Detail
Pfeil 32.7 Proxyserver
Pfeil 32.7.1 Funktion
Pfeil 32.7.2 Einsatz
Pfeil 32.7.3 Beispiel: Squid unter Linux
Pfeil 32.8 Virtuelle private Netzwerke mit OpenVPN
Pfeil 32.8.1 Pre-shared Keys
Pfeil 32.8.2 Zertifikate mit OpenSSL
Pfeil 32.8.3 OpenVPN als Server einrichten
Pfeil 32.8.4 OpenVPN als Client
Pfeil 32.9 Verdeckte Kanäle und Anonymität
Pfeil 32.10 Mails verschlüsseln: PGP und S/MIME
Pfeil 32.10.1 PGP/GPG
Pfeil 32.10.2 S/MIME
Pfeil 32.11 Trojanische Pferde
Pfeil 32.12 Logging
Pfeil 32.13 Partitionierungen
Pfeil 32.14 Restricted Shells
Pfeil 32.15 Loadable Kernel Modules
Pfeil 32.16 chroot
Pfeil 32.17 Kernel-Erweiterungen und ProPolice
Pfeil 32.17.1 ProPolice
Pfeil 32.17.2 SELinux/SEBSD und AppArmor
Pfeil 32.17.3 Openwall (OWL)
Pfeil 32.17.4 grsecurity
Pfeil 32.17.5 PaX
Pfeil 32.18 Sichere Derivate und Distributionen
Pfeil 32.18.1 Trusted Solaris (jetzt Teil von Solaris)
Pfeil 32.18.2 OpenBSD
Pfeil 32.18.3 TrustedBSD
Pfeil 32.18.4 Hardened Gentoo
Pfeil 32.18.5 Openwall
Pfeil 32.18.6 Fedora Core
Pfeil 32.19 Zusammenfassung
Pfeil 32.20 Aufgaben

Galileo Computing - Zum Seitenanfang

32.6 FirewallsZur nächsten Überschrift

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.


Galileo Computing - Zum Seitenanfang

32.6.1 GrundlagenZur nächsten ÜberschriftZur vorigen Überschrift

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.
  • 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.

  • Erlaubte Kommunikation
    In den folgenden Regeln werden die freizuschaltenden Ports und Wege definiert, zum Beispiel wie folgt:
  • 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 Catch-all-Regel wird jeglicher weiterer Traffic verboten.

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)

Tabelle 32.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 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.


Galileo Computing - Zum Seitenanfang

32.6.2 Firewalling unter Linux: Netfilter/iptablesZur nächsten ÜberschriftZur vorigen Überschrift

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?

Galileo Computing - Zum Seitenanfang

32.6.3 iptables im DetailZur nächsten ÜberschriftZur vorigen Überschrift

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.
  • 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.

  • »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.

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).
    • 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.

    • 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 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 überprüfen

    • --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.
    • 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.

    • --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.
  • 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:

    • --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.

    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.

    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.

  • -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.
  • -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 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.







<< zurück
  Zum Katalog
Zum Katalog: Linux
Linux
Jetzt bestellen


 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Linux-Server






 Linux-Server


Zum Katalog: Linux Hochverfügbarkeit






 Linux Hoch-
 verfügbarkeit


Zum Katalog: Linux-Server einrichten und administrieren
                  mit Debian 6 GNU/Linux






 Linux-Server einrichten
 und administrieren mit
 Debian 6 GNU/Linux


Zum Katalog: LPIC-1






 LPIC-1


Zum Katalog: LPIC-2






 LPIC-2


Zum Katalog: Webserver einrichten und administrieren






 Webserver einrichten
 und administrieren


Zum Katalog: Apache 2.4






 Apache 2.4


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Galileo Press 2012
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Galileo Computing]

Galileo Press, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de