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 Linux 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 IP 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 Linux 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, wie viele 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.