8.3.6. Praktikum zum Linux-Firewall

Das Firewall-Praktikum besteht aus den folgenden drei Teilversuchen:
  1. IP Filtering
  2. TCP Wrapper
  3. IP Masquerading

IP Filtering

Im ersten Teil wollen wir uns mit dem Ausfiltern von IP-Paketen befassen. Zu diesem Zweck verwenden wir die abgebildete Laboranordnung (Skript net_config_2 auf allen Maschinen starten). Unser Mini-Internet wird durch alpha und das Intranet durch gamma realisiert. Als Übergang zwischen diesen Netzen fungiert beta als Firewall.

Das IP Filtering wird vom Betriebssystem realisiert, daher müssen die Firewall-Regeln in den Linux-Kern eingetragen werden. Dies wird zur Laufzeit mit dem Tool ipfwadm (IP-Firewall-Administrator) durchgeführt.

Nach dem Systemstart können alle IP-Pakete den Firewall ungehindert passieren, da die Firewall-Regeln folgendermaßen aussehen (der erste Parameter gibt stets den Regelsatz an, -I für Input, -O für Output und -F für Forward):

[root@beta /root]# ipfwadm -F -l
IP firewall forward rules, default policy: accept
Im folgenden wollen wir uns hauptsächlich auf die Forward Rules konzentrieren, da beta als Router arbeitet. Für den Aufbau eines Regelsatzes hat es sich als günstig erwiesen, zunächst eine Default-Regel (die immer dann angewendet wird, wenn keine andere passende gefunden wird) zu definieren, die alles verbietet:
[root@beta /root]# ipfwadm -F -p deny
Nun sollte keinerlei Kommunikation zwischen den beiden Netzen mehr möglich sein (überprüfen Sie dies durch ping). Erst danach werden die Regeln eingetragen, die die IP-Pakete der ausgewählten Dienste passieren lassen.

Als erstes soll es möglich sein, aus unserem Mini-Internet heraus die Verfügbarkeit (mittels ping) eines Rechners im Intranet zu testen - umgekehrt soll dies nicht funktionieren. Sinnvoll ist diese Forderung bei einer automatischen Einwahl ins Internet (jedes ping würde einen erneuten Verbindungsaufbau zur Folge haben bzw. eine bestehende Verbindung aufrechterhalten - sicherlich zur Freude der Telekommunikationsunternehmen :-).

[root@beta /root]# ipfwadm -F -a accept -P icmp -S 0.0.0.0/0 8 -D 192.168.100.0/24
[root@beta /root]# ipfwadm -F -a accept -P icmp -S 192.168.100.0/24 0 -D 0.0.0.0/0
Wir erinnern uns, daß ping auf ICMP basiert (Parameter -P icmp). Daher müssen ICMP-Pakete vom Typ echo request den Firewall aus Richtung Internet in das Intranet passieren können. Für die Antwort darauf (echo reply) darf nur die Gegenrichtung offen sein. Der Parameter -S (source) legt dabei die Herkunft des IP-Paketes und der Parameter -D (destination) dessen Ziel fest.

Häufig soll eine Regel für ein gesamtes Subnetz gelten. Daher kann durch einen Schrägstrich die Anzahl der von vorn zu betrachtenden Bits der IP-Adresse angegeben werden, so daß eine 24 der Netzmaske 255.255.255.0 entspricht (der Wert 0 entspricht der Maske 0.0.0.0 - die Regel gilt damit für alle IP-Adressen).

Wie wir später sehen werden, können die Firewall-Rules auch noch von Portnummern (bei TCP, UDP) abhängig gemacht werden. Bei einer Regel für ICMP wird die Portnummer jedoch als ICMP-Typ (8 - echo request, 0 - echo reply) interpretiert.

Als nächstes wollen wir TELNET-Sitzungen zu Rechnern im Internet erlauben. TELNET basiert auf dem Protokoll TCP und verwendet serverseitig den Port 23. Wir müssen daher mit der folgenden Regel die Verbindung zu einem TELNET-Dämon im Internet gestatten:

[root@beta /root]# ipfwadm -F -a accept -P tcp -S 192.168.100.0/24 -D 0.0.0.0/0 23
Zusätzlich müssen wir natürlich die Rückrichtung ermöglichen. Das Problem ist nur, daß wir den Absender-Port des TELNET-Klienten nicht kennen, da dieser bei jeder Sitzung neu gewählt wird. Wir können daher die Rückrichtung nicht über den Port kontrollieren. Die Besonderheit der Rückrichtung besteht jedoch im Typ der TCP-Pakete, bei denen das ACK-Flag im Header gesetzt ist - genau diese Pakete lassen wir mit der folgenden Regel (Option -k) passieren. Eine Verbindungsaufnahme vom Internet in das Intranet wird verhindert, da Verbindungsaufbau-Pakete (SYN-Flag gesetzt) ausgefiltert werden (überprüfen Sie dies auch mittels telnet!).
[root@beta /root]# ipfwadm -F -a accept -P tcp -k -S 0.0.0.0/0 23 -D 192.168.100.0/24


Frage 8.3.6.1

Für FTP ist ein Firewall (mit IP-Filter) eine Hürde, da die Datenverbindung in Gegenrichtung zur Steuerverbindung (also vom Internet aus ins Intranet hinein) aufgebaut wird. Die meisten Firewalls erlauben jedoch keine Verbindungsaufnahme von "außen". Wie könnte prinzipiell eine Lösung dieses Problems aussehen (außer den Server im Passiv-Modus zu betreiben)?
Hinweis: Denken Sie daran, wie lange und zu welchem Port die Datenverbindung aktiv ist!


TCP Wrapper

Für diesen Versuch verwenden wir die gleiche Anordnung wie beim vorangegangenen (evtl. den Rechner beta booten, um die Firewall-Regeln zu entfernen, und dann wieder das Skript net_config_2 starten). Jeder Rechner in unserem Intranet besitzt also eine vollständige Verbindung von und zum Internet. Wir wollen nun einen Intranet-Rechner (gamma) mit dem TCP Wrapper versehen, um den weltweiten Zugriff nur auf bestimmte Dienste zu erlauben.

Als Beispiel hierzu werden wir den finger-Dienst verwenden, der Informationen zu den eingeloggten Nutzern einer entfernten Maschine bereitstellt. Wir wollen natürlich nicht, daß jeder Nutzer im Internet diese Angaben bekommt. Daher schalten wir den tcpd vor den finger-Dämon (in.fingerd). Dies geschieht dadurch, daß man in der Datei /etc/inetd.conf die Zeile

finger  stream  tcp     nowait  nobody  /usr/sbin/in.fingerd    in.fingerd -w
gegen
finger  stream  tcp     nowait  nobody  /usr/sbin/tcpd  in.fingerd -w
austauscht. Dieser Austausch sollte auf gamma nicht notwendig sein, da die Aktivierung des TCP Wrappers voreingestellt ist. Überprüfen Sie das bitte!

Sofern /etc/inetd.conf modifiziert werden mußte, ist der Internet-Dämon (auf gamma) neu zu starten:

gamma:/root # killproc /usr/sbin/inetd
Die Nutzerinformationen des Rechners gamma erhalten wir jedoch immer noch:
[root@alpha /root]# finger @192.168.100.2
[192.168.100.2]

Welcome to Linux version 2.0.33 at gamma !

  3:22pm  up  1:54h,  1 user,  load average: 0.08, 0.02, 0.01

Login    Name                 Tty  Idle  Login Time   Office     Office Phone
root     root                  S0        Oct 14 15:22
Wir haben ja auch noch keine Zugriffskontroll-Regeln für den TCP Wrapper definiert, die angeben, unter welchen Bedingungen ein bestimmter Dienst verfügbar ist. Daher fügen wir in die Datei /etc/hosts.allow (auf gamma) die folgenden beiden Zeilen ein:
in.fingerd : 192.168.100. : allow
in.fingerd : ALL : twist /bin/echo "You are too curious..."
Jede Zeile beginnt mit den Angaben zum Server, gefolgt von einer Spezifikation des bzw. der Klienten (IP-Adressen, Hostnamen, Muster, Wildcards). Dahinter wird optional eine Aktion definiert, die auszuführen ist, wenn die Regel zutrifft. Die erste Zeile erlaubt für alle Maschinen aus dem Subnetz 192.168.100 diesen Dienst - für alle anderen Rechner erfolgt eine Ablehnung (die folgende Zeile). Überprüfen Sie dies, indem Sie das obige finger-Kommando sowohl auf alpha als auch auf beta ausführen.

Anmerkung: Wie Sie sehen, wird hier die erweiterte Syntax der Zugriffskontroll-Regeln verwendet. Damit besteht keine Notwendigkeit, die Datei /etc/hosts.deny zu verwalten.

IP Masquerading

Normalerweise erhält man von seinem Internet-Provider nur eine IP-Adresse. Soll an den Zugangsrechner jedoch ein lokales Netz (Intranet) mit Internetzugang angeschlossen werden, so bietet das IP Masquerading eine interessante Alternative gegenüber der Nutzung von Proxies bzw. der teuren Beantragung mehrerer IP-Adressen.

Die genaue Funktionsweise wollen wir uns an der folgenden Abbildung verdeutlichen. Dazu nehmen wir an, daß gamma eine TCP-Verbindung (z.B. TELNET) zu alpha aufbauen möchte. Der Rechner beta ist unser Internet-Gateway und übernimmt das Masquerading der IP-Pakete von gamma, so daß von diesem Rechner aus der Internet-Zugang möglich ist.

  1. Der Rechner gamma sendet ein Verbindungsaufbau-Paket mit dem Ziel alpha aus. Dieses gelangt zunächst an unser Gateway beta, das sich die IP-Adresse sowie den Port des Absenders merkt. Anhand der Masquerading Rules (wir werden später sehen, wie man diese erzeugt) ersetzt beta diese beiden Werte durch seine eigene IP-Adresse und einen neuen Absender-Port.

  2. Der Zielrechner alpha liest dieses modifizierte Paket und sendet die Bestätigung an den Absender beta zurück. Ersterer erhält also keinerlei Kenntnis über die tatsächliche Herkunft dieses IP-Pakets.

  3. Unser Gateway beta empfängt die Bestätigung und weiß anhand der Zielportnummer, daß dieses Paket an gamma weiterzuleiten ist. Dazu werden die IP-Adresse sowie der Port des Ziels wieder durch die im ersten Schritt gespeicherten Werte ersetzt.
Wir sehen also, daß die Phase des Verbindungsaufbaus wichtig für die Funktion dieser Technik ist, da erst zu diesem Zeitpunkt der Eintrag in die Masquerading-Tabelle erzeugt werden kann.

Auch für den folgenden Versuch verwenden wir die gleiche Anordnung wie beim ersten Experiment (evtl. beta booten und die Anfangskonfiguration wiederherstellen).
Bevor wir die Regeln für das IP Masquerading festlegen, verbieten wir als erstes die Weiterleitung aller IP-Pakete:

[root@beta /root]# ipfwadm -F -p deny
Nun können wir die eigentliche Regel eintragen:
[root@beta /root]# ipfwadm -F -a m -S 192.168.100.0/24 -D 0.0.0.0/0
Dadurch werden alle TCP/IP-Pakete in der beschriebenen Weise maskiert, die aus unserem Intranet stammen und jedes beliebige Ziel (0.0.0.0/0) im Internet haben. Im Gegensatz zu den Firewall-Regeln der anderen Versuche gelten die Masquerading-Rules gleichzeitig für die Rückrichtung (Demaskierung).

Überprüfen Sie nun die Funktion des IP Masquerading, indem Sie sich von gamma aus auf alpha mittels TELNET einloggen:

Mittels tcpdump sehen wir uns nun die IP-Adressen der transportierten IP-Pakete an:
[root@alpha /root]# tcpdump -i eth0
[root@beta /root]# tcpdump -i eth1
Dadurch können wir sowohl den Netzwerkverkehr im Internet als auch im Intranet betrachten, der bei jedem Tastendruck (auf alpha) entsteht. Gleichzeitig ist die Maskierung der TCP/IP-Pakete an den dabei verwendeten großen Portnummern (> 60000) zu erkennen.


Frage 8.3.6.2

Das verbindungslose UDP verwendet ebenfalls Portnummern, so daß das IP Masquerading prinzipiell möglich ist. Welches Problem kann dabei jedoch auftreten? Beschreiben Sie einen Lösungsvorschlag.

Hinweis: Denken Sie daran, daß bei TCP ein Verbindungsabbau erfolgt, der für die Entfernung des entsprechenden Eintrages aus der Masquerading-Tabelle sorgt.


Literatur


© Heino Gutschmidt, 16.6.1997
Holger Trapp, 14.10.1998