LPI-Prüfungsvorbereitung LPIC-2

Konfiguration eines Routers
Bewertung 2
Die Kandidaten sollten in der Lage sein, ipchains und iptables für die Anwendung von IP-Masquerading zu konfigurieren und auf die Bedeutung von NAT (Network Address Translation) und Private Network Addresses bezüglich der Absicherung eines Netzwerks hinzuweisen. Dieses Lernziel beinhaltet die Konfiguration von Portweiterleitung, das Auflisten von Filterregeln und das Schreiben von Regeln, die Datenblöcke auf der Basis von Quell- oder Zielprotokoll, Port und Adresse zulassen oder blocken. Ebenfalls enthalten ist das Speichern und Neuladen von Filterkonfigurationen, das Verwenden von Einstellungen in /proc/sys/net/ipv4, um auf DOS-Attacken zu reagieren, die Verwendung von /proc/sys/net/ipv4/ip_forward, um IP-Forwarding an- oder abzustellen, und das Verwenden von Tools wie PortSentry, um Portscans und Schwachstellenanalysen abzublocken.
Schlüsseldateien, Begriffe und Hilfsmittel beinhalten:

ipchains
/proc/sys/net/ipv4
/etc/services
iptables
routed

Die Linux-Kernel der verschiedenen Generationen haben regelmäßig eine neue Technik entwickelt, um Filterregeln für die Firewalls zu verwalten. Die erste Generation (Kernel 2.0.x) brachte das Programm ipfwadmin mit, die nächste Generation (Kernel 2.2.x) ersetzte es durch ipchains und die heutigen Kernel (ab Version 2.4.x) benutzen iptables. Über Module können auch moderne Kernel mit den jeweils älteren Methoden eingesetzt werden.
Wenn im Folgenden mit Firewall-Regeln umgegangen wird, werden immer die beiden Methoden ipchains und iptables besprochen, die älteste Methode wird von LPI nicht mehr verlangt und wird in der Praxis auch kaum noch eingesetzt.

Bedeutung privater Adressen hinsichtlich der Sicherheit
Private IP-Adressen sind Adressen, die im Internet nicht geroutet werden dürfen. Selbst wenn sie geroutet werden sollen, gibt es keine Möglichkeit, eine solche Adresse zu erreichen, da es davon ja unendlich viele geben kann. Aus diesem Grund sollten lokale Netze, die nicht direkt von außen zugänglich sein sollen, immer mit diesen privaten Adressen betrieben werden. Die privaten Adressen sind:

Klasse A: 10.0.0.0
Klasse B: 172.16.0.0 bis 172.31.0.0
Klasse C: 192.168.0.0 bis 192.168.255.0
Wenn ein Netz intern mit solchen Adressen arbeitet, dann kann ein Angriff von außen auf einzelne Rechner in diesem Netz gar nicht stattfinden, denn die einzelnen Rechner sind von außen ja gar nicht zu adressieren.
NAT/Masquerading
Damit aber trotz der Verwendung von privaten Adressen die Mitglieder des lokalen Netzes Zugriff auf das Internet haben, benötigen wir einen Router, der die Pakete des lokalen Netzes ins Internet weitergibt. Das alleine würde aber nichts helfen, denn die im IP-Header eingetragenen Adressen sind ja privat, das heisst, ein Server im Internet könnte die Antwort auf eine Nachfrage eines Rechners aus dem lokalen Netz gar nicht losschicken.
Aus diesem Grund kann der Router eine Übersetzung der privaten Adressen in seine eigene Adresse vornehmen. Er muss ja zwangsläufig eine allgemeingültige IP-Adresse haben, sonst könnte er ja eben nicht auf das Internet zugreifen. Der Router bekommt jetzt also Pakete aus dem lokalen Netz, ersetzt die Absender-Adresse in seine eigene und merkt sich das in einer Kerneltabelle. Erst dann schickt er die Pakete wirklich ins Internet. Ein Server im Internet bekommt also das Paket mit der - gültigen - Adresse des Routers. Die Antwort wird also an den Router geschickt. dieser nimmt die Antwort entgegen, kontrolliert anhand der Tabelle, an welchen Rechner diese Antwort gehen soll und ersetzt jetzt die Empfänger-Adresse durch dessen lokale IP-Adresse. Erst jetzt schickt er das Antwortpaket an den ursprünglichen Sender zurück.
Diese Technik macht es möglich, dass alle Rechner eines Netzes aus der Sicht des Internets nur eine einzige IP-Adresse haben - die des Routers. Ein Server im Internet kann nicht unterscheiden zwischen den einzelnen Rechnern, aus seiner Sicht kommuniziert er ja nur mit dem Router. Das hat den Vorteil, dass der Router die einzige Angriffsfläche ist, die ein lokales Netz nach außen hin bietet.

Aktivieren des Masqueradings mit ipchains
Auf dem Router muss mit ipchains eine Regel für die Forward-Chain formuliert werden, die als Policy das Masquerading zulässt. Angenommen wir haben das externe Interface eth1 und die private Netzadresse 192.168.100.0 im lokalen Netz, dann würde die entsprechende Befehlszeile auf dem Router lauten:
  EXTERNAL_INTERFACE=eth1
  ipchains -A forward -i $EXTERNAL_INTERFACE -s 192.168.100.0/24 -j MASQ
Übersetzt heisst das soviel wie
Hänge die folgende Regel an die forward-chain an (-A forward): Wenn auf dem externen Interface Pakete (-i) mit der Senderadresse (-s) unseres privaten Netzes auftauchen, dann maskiere sie (-j MASQ)

Aktivieren des Masqueradings mit iptables
iptables verwaltet nicht nur die Regelketten wie ipchains, sondern darüberhinaus Tabellen für bestimmte Vorgänge. Eine der Standard-Tabellen ist extra für das Masquerading vorgesehen, nur heisst es jetzt eben Network Address Translation oder kurz NAT. Die Tabelle, die das NAT steuert heisst konsequenterweise auch so, nämlich nat.
Für den Umgang mit iptables muss noch ein spezielles Modul für NAT geladen werden, das Modul iptable_nat. Erst jetzt können wir schreiben
  EXTERNAL_INTERFACE=eth1
  iptables -t nat -A POSTROUTING -o $EXTERNAL_INTERFACE -j MASQUERADE
Besser ist es aber, statt -j MASQERADE die Anweisung -j SNAT zu verwenden. Zumindestens, wenn es sich bei der Internet-Verbindung um eine dynamisch vergebene IP-Adresse handelt. Nach dieser Angabe steht dann noch, welches Netz maskiert werden soll. Das kann über --to-source angegeben werden, etwa in der Art
  EXTERNAL_INTERFACE=eth1
  iptables -t nat -A POSTROUTING -o $EXTERNAL_INTERFACE -j SNAT\
           --to-source 192.168.1.1-192.168.100.17
Port-Forwarding
Port-Forwarding ist - vereinfacht gesagt - genau das Gegenteil von NAT. Beziehungsweise könnten wir uns vorstellen, dass es eine Art Destination-NAT im Gegensatz zur Source-NAT darstellt. Worum geht es?
Wenn ein lokales Netz mit privaten Adressen über einen NAT-Router ans Internet angebunden ist, dann kann kein Rechner aus dem Internet auf einen Rechner im lokalen Netz zugreifen. Das ist in der Regel ja auch erwünscht, in Ausnahmefällen wollen wir aber z.B. dass ein Rechner im lokalen Netz auch als Server dient. Nehmen wir an, dass ein Rechner im lokalen Netz ein von außen zugänglicher Webserver sein soll, der auf Anfragen des TCP-Ports 80 lauscht. Dann kann der Router, der ja tatsächlich auch aus dem Internet erreichbar ist, alle Anfragen an den TCP-Port 80 an den entsprechenden Rechner im lokalen Netz weiterleiten. Das ist dann eigentlich auch nichts anderes, als NAT, nur eben in die andere Richtung (nach innen) und anhand anderer Kriterien (Portnummern).

Portforwarding mit ipchains
ipchains selbst kann kein Portforwarding selbst initialisieren. Dazu gibt es ein Hilfsprogramm ipmasqadm. Um zum Beispiel alle Pakete, die von außen an den TCP-Port 80 gehen, an den lokalen Rechner 192.168.100.17 weiterzuleiten können wir schreiben:
  EXT_IP_ADDR=199.232.12.23
  ipmasqadm portfw -a -P tcp -L $EXT_IP_ADDR 80 -R 192.168.100.17 80
Die Variable EXT_IP_ADDR verweist auf die Adresse, die unser Router von außen hat, also seine "echte" IP-Adresse im Internet.

Portforwarding mit iptables
Das iptables Programm hat das Ganze konsequenter durchdacht und kennt Portforwarding tatsächlich als eine Art der NAT. Aus diesem Grund wird auch hier - wie im obigen Beispiel - mit der Tabelle nat gearbeitet.
  iptables -A PREROUTING -t nat -p tcp -d $EXT_IP_ADDR --dport 80 \
           -j DNAT --to 192.168.100.17:80
Das DNAT steht für Destination-NAT und meint - wie oben beschrieben eben die Umsetzung der Empfängeradresse.

Firewallregeln auflisten
Um alle bestehenden Regeln einer Regelkette anzeigen zu lassen wird entweder der Befehl
  ipchains -L input  
oder
  iptables -L INPUT
verwendet. Wird keine Kette angegeben, dann werden alle angezeigt.
Firewallregeln definieren
Das hier kann nur eine sehr kurze Darstellung der Regelerstellung werden, sonst stünden in diesem Abschnitt zwei Bücher, eins über ipchains und eins über iptables. Aus diesem Grund sind hier nur ein paar ganz rudimentäre Techniken genannt.
Jede Regel bezieht sich auf eine der drei Standard-Filterketten INPUT, OUTPUT und FORWARD. Jede dieser Regelketten muss am Anfang eine Grundpolicy gesetzt bekommen, aus der hervorgeht, dass entweder

alles verboten ist, was nicht erlaubt ist (DENY) oder
alles erlaubt ist, was nicht verboten wurde (ACCEPT)
Sicherer ist sicherlich die erste Methode, auch wenn sie etwas mehr Arbeit beim Aufstellen der Regeln macht.
Jede Regel kann als Kriterien die IP-Adresse (und den Port) des Senders (-s) und des Empfängers (-d) verwenden um zu entscheiden, ob ein Paket durchgelassen werden soll oder nicht.
Zusätzlich stehen noch die Information des verwendeten Protokolls (tcp, udp, icmp) zur Verfügung, das mit dem Schalter -p angegeben wird.
Mit -i kann noch bestimmt werden, auf welches Interface (Netzwerkkarte) sich die Regel bezieht.
Schließlich wird mit -j festgelegt, was mit dem Paket passieren soll (ACCEPT, DENY, ...)

Regeln mit ipchains formulieren
Mit ipchains wird zunächst festgelegt, welches die Grundeinstellungen für jede Regelkette (chain) sein soll. Dazu werden erstmal alle Regeln aus einer Kette gelöscht:
  ipchains -F
Jetzt wird die Grundpolicy der Regeln gesetzt:
  ipchains -P input    DENY
  ipchains -P output   DENY
  ipchains -P forward  DENY
Ab diesem Punkt ist unser System absolut wasserdicht, kein Paket kann rein oder raus.
Die einzelnen Regeln werden jetzt Stück für Stück erstellt. Die folgende Regel erlaubt Pakete von unserem Rechner nach außen zu geben, wenn sie auf den TCP Port 80 (http) eines Rechners im Internet addressiert sind:
  ipchains -A output -i eth1 -p tcp -d 0.0.0.0/0 80 -j ACCEPT
Damit auch eine Antwort eingehen kann benötigen wir eine Regel, die Pakete von außen, die den Absenderport 80 haben auch wieder reinlassen:
  ipchains -A input -i eth1 -p tcp -s 0.0.0.0/0 80 -j ACCEPT
Auf diese Art muss für jedes denkbare Paket eine Regel erstellt werden.
Regeln mit iptables formulieren
Mit iptables kann das auf die selbe Art und Weise erledigt werden, mit ein paar Unterschieden. Erstens werden die Regelketten groß geschrieben, also INPUT statt input und zweitens beziehen sich die Angaben auf bestimmte Tabellen (tables), die iptables verwaltet. Diese Tables können auch weggelassen werden, dann funktioniert iptables wie ipchains.
  iptables -A OUTPUT -p tcp -d 0.0.0.0/0 --dest-port 80 -j ACCEPT
  iptables -A INPUT  -p tcp -s 0.0.0.0/0 --source-port 80 -j ACCEPT
Firewallregeln absichern und wieder laden
Eigentlich gibt es wenig Gründe alle Regeln abzusichern, wenn eine Firewall mit Hilfe eines Scripts aufgebaut wurde. Denn dieses Script sollte ja grundsätzlich damit beginnen, alle Regeln zu löschen, die Grundpolicy zu setzen und dann alle notwendigen Regeln formulieren. Durch diese Architektur kann man es beliebig oft hintereinander aufrufen, ohne dass etwas durcheinander geraten könnte.
Für ipchains gibt es zwei Hilfsmittel, die trotzdem erlauben, alle Regeln aus dem Kernelspace auf die Standard-Ausgabe zu schreiben (und damit natürlich auch in eine Datei umleiten können) und sie entsprechend wieder aus der Standard-Eingabe (oder einer umgeleiteten Datei) lesen können.
  ipchains-save [Kette] -v
  ipchains-restore 
Um also alle Regeln in die Datei Firewall.regeln zu sichern, schreiben wir
  ipchains-save -v > Firewall.regeln
und um sie wieder zu laden wird der folgende Befehl eingesetzt:
  ipchains-restore < Firewall.regeln
Analog dazu gibt es auch die beiden Programme iptables-save und iptables-restore.
Einstellungen im proc-Verzeichnis
Über die Dateien im Verzeichnis /proc/sys/net/ipv4/ können verschiedene Eigenschaften des Kernels manipuliert werden, die die Netzwerksicherheit beeinflussen können. Die wichtigsten dieser Einstellmöglichkeiten sind:
ip_forward
Diese Datei regelt die Fähigkeit des Kernels, Pakete von einer Netzschnittstelle auf eine andere weiterzuleiten, also kurz die Frage ob unser Rechner ein Router ist oder nicht. Steht in der Datei eine 0, so werden Pakete nicht weitergeleitet, steht dort eine 1, dann werden sie weitergeleitet. Einstellungen sind möglich, indem diese Werte in die Datei eingetragen werden, etwa mit
  echo 1 > /proc/sys/net/ipv4/ip_forward
tcp_syncookies
Regelt den Umgang mit Synflooding Angriffen. Eine 1 in dieser Datei aktiviert diese Fähigkeit und blockt solche Angriffe ab.
tcp_syn_retries
Hier wird eingetragen, wieviele Pakete mit Syn-Flag hintereinander akzeptiert werden, bevor die syncookie-Methode greift. Die voreingestellte Anzahl ist 5.
icmp_echo_ignore_all
Ermöglicht das Abblocken aller ICMP-Echo Anforderungen (Ping)
icmp_echo_ignore_broadcasts
Ermöglicht das Abblocken aller ICMP-Echo Anforderungen (Ping), die an Broadcast-Adressen verschickt wurden.
Im Verzeichnis /proc/sys/net/ipv4/conf existieren für alle Netzwerkschnittstellen noch weitere Verzeichnisse, die Einstellungen für die jeweilige Schnittstelle ermöglichen. Dort kann beispielsweise über die Datei rp_filter festgelegt werden, dass die Source-Verification eingeschalten wird.
Der PortSEnty Daemon
Der Daemon portsentry ist ein Programm, das versucht, Portscans auf Netzwerkschnittstellen zu entdecken. Im Fall eines entdeckten Portscans können verschiedene Aktivitäten entfaltet werden, von der einfachen Meldung an den Syslog-Daemon bis hin zum Aufbau von Firewallregeln (über ipfwadm, ipchains oder iptables), Einträgen in /etc/hosts.deny oder fallengelassenen Routen.
In der Datei /etc/portsentry/portsentry.conf können die entsprechenden Einstellungen vorgenommen werden. Dabei kann detailiert festgelegt werden, welche Ports überwacht werden sollen und was passieren soll, wenn ein Angriff entdeckt wurde.
Der Routing-Daemon routed
Der Daemon routed wird beim Systemstart über ein Init-Script gestartet. Seine Aufgabe ist es, die Kernel-Routing-Tabelle auf dem aktuellen Stand zu halten und die an sich sehr statischen Routen dort dynamisch an die Gegebenheiten anzupassen. Der Daemon startet einen Broadcast-Request an alle angeschlossenen Schnittstellen und wartet auf entsprechende Antworten. Jeder angesprochene Rechner schickt auf eine solche Anfrage hin die Routen, die er kennt. Der Routed kann aus dieser Information genau festlegen, welche Routen existieren und so eine sehr genaue Tabelle aufbauen, die immer auf dem aktuellen Stand ist.

[ Zurück zur Startseite LPI 201 ] [ Zurück zur LPI-Seite ] [ Zurück zur Hauptseite von Linux-Praxis ] [ Guestbook ] [ Kontakt ]
Diese und die darunterliegenden Seiten wurden erstellt von F. Kalhammer
© 2001 by F.Kalhammer -
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License..