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):
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 -l IP firewall forward rules, default policy: accept
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.[root@beta /root]# ipfwadm -F -p deny
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 :-).
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.[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
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:
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 -S 192.168.100.0/24 -D 0.0.0.0/0 23
[root@beta /root]# ipfwadm -F -a accept -P tcp -k -S 0.0.0.0/0 23 -D 192.168.100.0/24
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!
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
gegenfinger stream tcp nowait nobody /usr/sbin/in.fingerd 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!finger stream tcp nowait nobody /usr/sbin/tcpd in.fingerd -w
Sofern /etc/inetd.conf modifiziert werden mußte, ist der Internet-Dämon (auf gamma) neu zu starten:
Die Nutzerinformationen des Rechners gamma erhalten wir jedoch immer noch:gamma:/root # killproc /usr/sbin/inetd
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:[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
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.in.fingerd : 192.168.100. : allow in.fingerd : ALL : twist /bin/echo "You are too curious..."
Anmerkung: Wie Sie sehen, wird hier die erweiterte Syntax der Zugriffskontroll-Regeln verwendet. Damit besteht keine Notwendigkeit, die Datei /etc/hosts.deny zu verwalten.
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.
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:
Nun können wir die eigentliche Regel eintragen:[root@beta /root]# ipfwadm -F -p deny
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).[root@beta /root]# ipfwadm -F -a m -S 192.168.100.0/24 -D 0.0.0.0/0
Überprüfen Sie nun die Funktion des IP Masquerading, indem Sie sich von gamma aus auf alpha mittels TELNET einloggen:
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.[root@alpha /root]# tcpdump -i eth0 [root@beta /root]# tcpdump -i eth1
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.