Leicht überarbeitet: 3.11.2003

Bei mir zu Hause betreibe ich ein kleines Netzwerk mit 6-10 Rechnern (ändert sich dauernd...) und mehreren Netzwerkdruckern. Dieses Netzwerk ist über eine Standleitung ans Internet angeschlossen (TV-Kabelmodem). Hier möchte ich versuchen, Netzwerk-Anfängern eine Idee zu geben, wie ein solches Netzwerk aufgebaut ist, was ein Router ist, was der macht und weshalb man einen braucht, was es mit Packet Filter Firewalls auf sich hat.
Der ursprüngliche Ansporn kam daher, dass es zwar sehr detailierte Dokumente über einzelne Netzwerk-Dienste etc. gibt, aber kaum eine Seite, die alles einigermassen übersichtlich zusammenstellt und die wichtigsten Fragen erklärt. Genau dies habe ich hiermit versucht (ob es mir gelungen ist, musst du entscheiden...).
Über Feedback würde ich mich sehr freuen. Wenn du irgendwas nicht verstanden hast, einen Teil 10x lesen musstest, weil er zu kompliziert geschrieben ist oder etwas viel zu detailiert behandelt wird, zögere bitte nicht und teil es mir mit.

Den konkreten Bau eines Routers beschreibt Das "eierlegende Wollmilchsau" Router Projekt. Dort findest du detaillierte Anleitungen, wie man einen Router unter Linux aufsetzen kann.

PS: Die Rechtschreibefehler, die du findest, darfst du behalten ;-)

Grundsätzlich für jeden, der mehr als einen Rechner über eine Internetverbindung (TV-Kabelmodem, DSL, ISDN oder gar 56k analog) betreiben möchte oder schon immer etwas mehr über Netzwerke wissen wollte.

Manch einer fragt sich: Was ist der grosse Unterschied zwischen diesen beiden Technologien? Was soll ich nehmen wenn ich beides zur Wahl habe?
Nun, oftmals ist sowieso nur entweder das eine oder das andere verfügbar, dann fällt die Wahl nicht schwer. Trotzdem hier eine Auflistung der Vor- und Nachteile der beiden Internetverbindungen:
Geschwindigkeit Download:
Hardwaremässig wäre mit DSL eine Geschwindigkeit von Grössenordnung 8-10 MBit möglich mit den verfügbaren Modems, wobei die Telefonleitungen meist kaum mehr als 3-4 MBit zulassen. Dem gegenüber stehen die theoretischen 40-50 MBit der TV-Kabelmodemtechnologie, wobei das TV-Kabel ein "shared" Medium ist: Mehrere Benutzer hängen am gleichen physikalischen Kabel, und müssen sich daher die Bandbreite teilen. Aber keine Angst, der Anbieter der Dienstleistung ist (hoffentlich) dafür besorgt, dass nicht zuviele Benutzer am gleichen Knoten hängen.
Allerdings stehen bei beiden Übertragungsarten immer wieder neue Technologieen an, so dass sich diese Limits in Zukunft auch noch erhöhen können.
Geschwindigkeit Upload:
Möglich wären heute über das TV-Kabel 10 MBit Uplink; für ADSL (asymmetric DSL) sind die Werte normalerweise ca. Faktor 4 unter den Download-Geschwindigkeiten, weil für den Upstream ein niedrigeres Frequenzband benutzt wird. Bei SDSL (symmetric DSL) sind die Geschwindigkeiten in beide Richtungen gleich. Die effektiv dem Kunden zur Verfügung gestellten Upload-Raten sind üblicherweise auch deshalb wesentlich kleiner als die Download-Raten, um das Anbieten von Serverdiensten (HTTP, FTP, aber auch Peer to Peer) zu unterbinden, denn diese Dienste generieren üblicherweise sehr viel Traffic, der für den Provider nicht ganz billig ist.
Bedienungsfreundlichkeit:
Grundsätzlich bieten sowohl Kabel- als auch DSL-Modem eine Hardware-Ethernetverbindung zum Provider, wie das z.B. eine Powerline-Bridge oder auch ein stinknormaler Switch tut, nur mit einem anderen Übertragungsmedium. Viele Provider, in Europa insbesondere DSL-Anbieter, verwenden aber zusätzlich PPPoE (Point to Point Protocol over Ethernet), das ist eine Punkt-zu-Punkt-Verbindung, die AUF der Ethernet-Verbindung läuft. Wiederum auf dieser PPPoE-Verbindung läuft dann eine virtuelle Ethernet-Verbindung, die dann schlussendlich für den Datentransfer ins Internet genutzt wird. Dieses doppelte Verbindungtunneling sollte, wenn möglich, vermieden werden, also vorzugsweise einen Provider suchen, der das nicht verlangt. Ansonsten können die meisten Hardware-Router eine solche Verbindung selbst herstellen, dann muss man sich nicht auf Betriebssystemebene damit herumschlagen.
Es werden auch DSL/Kabelmodems mit USB-Anschluss verkauft; davon kann ich aber nur abraten, die Geräte mit Ethernet-Anschluss sind zuverlässiger und laufen unter allen Betriebssystemen.
Mögliche Anzahl Rechner:
Bei der Verwendung von PPPoE ist diese Zahl auf einen Rechner beschränkt, da die Punkt-zu-Punkt-Verbindung, wie der Name schon sagt, bei dir zu Hause nur einen Endpunkt hat. Wenn kein PPPoE verwendet wird, bieten einige Provider mehrere IP-Adressen an, so dass mehrere Rechner direkt ans Modem (bzw. ggf. über einen Switch/Hub) angeschlossen werden können. In beiden Fällen kann aber die Anzahl Rechner durch einen NAT-Router fast beliebig erhöht werden.
Zunkunftsaussichten:
Dazu sollte man sich im Klaren sein, was für ein Übertragungsmedium verwendet wird: Bei DSL ungeschirmte, wild verlegte Kabel und über das TV-Netz High-End Koaxialkabel. Wenn ich noch die heute mit den beiden Technologien möglichen Transferraten vergleiche und die distanzmässige Einschränkung der DSL-Technologie miteinbeziehe, muss ich für mich sagen, dass die TV-Kabelmodem-Technologie eindeutig vielversprechender ist als DSL. Der Unterschied mag im Moment zwar noch nicht wesentlich sein, aber wenn die Transferraten steigen werden die mit DSL möglichen Distanzen wahrscheinlich zu kurz für viele Haushalte. Aber wer weiss, bis dann hat vielleicht jeder einen Glasfaser-Anschluss...

Um das Folgende zu verstehen, muss ich zuerst einige Sachen zum im Internet üblichen Protokoll TCP/IP sagen. Wer denkt, das er das Zeug schon gut versteht kann diesen Abschnitt ruhig überspringen.
TCP/IP ist ein Übertragungprotokoll, das platformübergreifend verfügbar ist, hohe Übertragungsraten ermöglicht, eine ausserordentlich gute Skalierbarkeit besitzt und deshalb für sehr viele Netzwerktransfers verwendet wird. Es basiert darauf, dass jeder Rechner in Netzwerk (das Internet kann als einziges gigantisches Netzwerk betrachtet werden) eine einmalige Nummer hat, die sog. IP-Adresse. Es ist eine bis zu 12-Stellige Nummer, die mit Dezimalpunkten unterteilt ist. Jeder einzelne Block kann Zahlen von 0 bis 255 enthalten, also 8 Bit Daten. Beispiel: "192.168.8.76". Diese Nummer ist einerseits eindeutig, andererseits enthält sie Informationen, in welchem "Subnet" (grosse Netzwerke werden in Teilnetzwerke, "Subnets" unterteilt) sich der Rechner befindet. Die sogenannte "Subnet-Mask" definiert welcher Teil der IP Angaben über das Subnet macht. Beispiel:

HTTP	80
FTP	21
Proxy-Server	3128
NetBIOS	137
Windows-Freigabe	139
DNS	53
DHCP	67

Dies sind lediglich Standard-Werte, die tatsächlichen Ports können davon abweichen; normalerweise sollten aber diese Ports eingehalten werden. Die Client-Seitigen Ports liegen bei allen obigen Diensten über 1023, ausser bei DHCP, dort ist der Client-Port 68.

IP 192.168.8.76 Subnet-Mask 255.255.255.0: 192.68.8 ist das Subnet, .76 die eindeutige Nummer des Rechners in diesem Subnet. Mit dieser Subnet-Mask können 253 Rechner pro Subnet betrieben werden.
IP 10.54.164.99 Subnet-Mask 255.0.0.0: 10 ist das Subnet, .54.164.99 die eindeutige Nummer des Rechners im Subnet. Hier können 253*255*255=16451325 Rechner pro Subnet betrieben werden.
Vielleicht hast du schon erkannt, wie das mit den Subnets funktioniert:
255.255.255.0 ist binär 11111111.11111111.11111111.00000000. Jede Stelle, wo eine 1 steht heisst, dass die entsprechende Stelle in der IP-Adresse das Subnet definiert; wenn an einer Stelle der Subnet-Mask eine 0 steht, heisst das dass die entsprechende Stelle der IP-Adresse die eindeutige Rechner-Adresse ist. Noch ein Beispiel:
255.255.128.0 ist binär 11111111.11111111.10000000.00000000. Also beispielsweise alle Rechner mit IPs zwischen 180.44.0.0 und 180.44.127.255 gehören in dasselbe Subnet, und alle Rechner mit IPs zwischen 180.44.128.0 und 180.44.255.255 gehören in ein anderes Subnet. Alles klar? Wenn nicht ist das auch nicht so wichtig.
Die Rechner verschiedener Subnets können nicht direkt miteinander kommunizieren. Als Verbindungsstelle zweier Subnets werden sog. Router eingesetzt. Wenn nun ein Rechner einem anderen Daten schicken will, schaut er zuerst, ob der andere Rechner im gleichen Subnet ist und wenn ja schickt er ihm die Daten direkt, wenn nein schickt er die Daten an das Standard-Router, wenn dieses die Daten auch nicht weiterschicken kann ans nächste eingetragene Router etc.
Die Daten selbst werden in einzelnen Paketen gesendet von z.B. 1 kB grösse. Jedes Paket enthält eine Absenderadresse, einen Absenderport, eine Zieladresse und einen Zielport.

Was hat es mit den Ports auf sich?
Man stelle sich nun vor, es laufen auf einem Computer verschiedene Programme, die gleichzeitig Daten über ein Netzwerk übertragen wollen. Beispielsweise der Real Audio Player, ein Download und über einen Browser wird noch gesurft. Wie wird nun sichergestellt, dass jede Anwendungen die für sie bestimmten Daten, und nur diese, erhält? Dazu verwendet jede Client-Anwendung, also jede Anwendung, die von einem Server Daten will (alle vorherigen Beispiele gehören dazu), einen normalerweise variablen, noch nicht besetzten Port. Dieser wird als Absender zusammen mit der IP-Adresse des Computers jedem Paket angefügt. Wenn nun der Server die Datenanforderung erhält, weiss er woher er sie hat und schickt ein Antwortpaket an dieselbe IP-Adresse und denselben Port zurück, woher er die Anfrage bekam. Eine Kurznotation für Ports ist ein Doppelpunkt mit der Portnummer nach der IP, also z.B. 192.168.8.76:1034
Jedes System hat 65536 Ports (16 Bit) zur Verfügung, wobei Clients normalerweise Ports über 1023 verwenden und Server Ports unter 1023. Hier an einem kleinen Beispiel die Kommunikation zwischen einem Webserver und einem Client:
1. Der Benutzer (also Client) mit der IP 192.168.8.76 will eine Homepage von einem Web-Server mit der IP 192.168.8.88 (Subnet-Mask beide Male 255.255.255.0). Da die beiden Rechner im gleichen Subnet sind, können sie direkt miteinander kommunizieren. Also wählt sich der Client einen freien Port aus (z.B. 1034) und schickt eine Anfrage an den Server. Diese Anfrage sieht so aus: Quell-IP: 192.168.8.76 Quell-Port: 1034 Ziel-IP: 192.168.8.88 Ziel-Port: 80 (Webserver verwenden allermeistens Port 80).
2. Der Server schickt eine Antwort in einem Paket mit Quell-IP: 192.168.8.88 Quell-Port: 80 Ziel-IP: 192.168.8.76 Ziel-Port: 1034.
Wenn ein Router dazwischen ist, funktioniert die Sache ganz ähnlich; aber der Client sieht, dass der andere Rechner nicht im Subnet ist, deshalb schickt er das Paket an das Router (die Ziel-Adresse des Pakets bleibt aber immer der Webserver, egal ob er im gleichen Subnet ist oder nicht), dieses sendet ggf. das Paket ans nächste Router etc. etc., bis der Webserver erreicht ist. Der Transfer in die andere Richtung erfolgt analog.

TCP, UDP, ICMP
TCP/IP wird normalerweise als synonym für das Ganze Protokoll-System gebraucht. Eigentlich ist das falsch, denn IP ist die "Transport-Schicht", die mit Hilfe von IP-Adressen und Hardware-Adressen die Pakete durch die Netzwerke schickt. TCP hingegen ist das eigentliche Protokoll, das für die korrekte Auslieferung der Daten sorgt. Bei TCP-Transfers sorgt also das Protokoll automatisch dafür, dass keine Datenfehler auftreten: Zuerst wird mit einem sog. "Software-Handshake" eine Verbindung aufgebaut und von beiden Seiten das Okay für den Datentransfer gegeben; danach werden die Daten übertragen und es wird konrolliert, ob sie korrekt angekommen sind. Wenn nicht werden die Daten nochmal geschickt.
Im Gegensatz dazu UDP. Hier werden die Daten einfach mal losgeschickt, es besteht keine gesicherte Verbindung, die Daten können einfach verloren gehen. Dafür ist der Protokoll-Overhead (=Verwaltungsinformationen, die gebraucht werden, um die Daten richtig zuzustellen) natürlich sehr viel kleiner. UDP wird also dort verwendet, wo es auf die zuverlässige Zustellung der Daten nicht so ankommt und wo die Anfrage/Antwort möglichst schnell mit geringem Bandbreitenverbrauch gehen soll (z.B. online-Games, DNS-Auflösung, DHCP, RealAudio).
ICMP hingegen ist nochmals etwas anderes, es dient dazu, Pakete auf dem schnellstmöglichen Weg von einem Ort zum anderen zu schicken und hat gewisse Netzwerk-Debugging-Tools (z.B. das allseits bekannte PING).

Es gibt zwei Varianten, um die Netzwerkeinstellungen der Rechner auszuführen: Man kann jedem Gerät von Hand eine IP eintragen, die Subnet Mask, die Router-Adresse und den DNS-Server. Bei grossen Netzwerken (mehr als etwa 20 Rechner) ist dies aber äusserst mühsam ünd für Notebooks, die mal im einen, mal im anderen Netzwerk betrieben werden, völlig unpraktikabel.
Die Lösung dieses Problems besteht in der automatischen Zuteilung der IP-Adressen und anderen Netzwerkeinstellungen. Dazu dient das DHCP-Protokoll, in Kombination mit einem Server, der aber nur sehr wenig Leistung benötigt. In der Server-Software kann man einstellen, welche IP-Bereiche verteilt werden sollen, welche Subnet Mask die Rechner verwenden und welcher Computer als Router und DNS-Server verwendet werden soll. Weiter kann man einstellen, wie lange die IP-Adressen maximal gültig sind.
DHCP ermöglicht auch das Verwenden von mehr Rechnern im gleichen Subnet, als überhaupt möglich wären, da ja nur diejenigen Computer, die momentan in Betrieb sind, eine IP-Adresse benötigen. Die maximale Zahl gleichzeitig laufender Computer bleibt allerdings weiterhin beschränkt. Diese kann ohne Änderung der Adressierung nur mit Routern, die NAT durchführen, erhöht werden; mehr dazu später.
DHCP-Server werden auch von den Internet-Providern verwendet, um die Netzwerkeinstellungen der Clients (also beispielsweise du) duchzuführen. Mit Start -> Ausführen -> winipcfg bei W9x/ipconfig bei NT kannst du dir die aktuellen Einstellungen anzeigen lassen.

DNS wurde eingeführt, damit sich die Benutzer des Internets nicht die IP-Adresse einer Webseite merken mussten, sondern einen einfachen Namen wie www.google.com (alternativ müsste man sich 216.239.35.101 merken). Wenn nun der User z.B. im Browser eine solche Adresse eingibt, fragt der Browser zuerst einen dem Betriebssystem bekannten DNS-Server an, der den Hostnamen in eine IP (in unserem Beispiel 216.239.35.101) auflöst. Mit dieser IP wird dann der eigentliche Webserver von Google angesprochen.
Dieses System hat auch den Vorteil, dass, wenn die IP-Adresse eines Servers ändert, der Domainname gleich bleiben kann, man muss dann lediglich die Einträge der DNS-Server ändern.
In einem lokalen Netzwerk hat man normalerweise keinen richtigen DNS-Server, sondern einen DNS-Forwarder, der zwar wie ein richtiger DNS-Server angesprochen werden kann, die Anfrage aber nicht selbst beantwortet, sondern nur an einen DNS-Server im Internet weiterleitet (oder ggf. einen Domain-Name-Cache führt und diesen für die Auflösung verwendet). Daher kommt auch der Umstand, dass der Router ins Internet zugleich der DNS-Forwarder ist und bei den anderen Netzwerkrechnern unter "DNS-Server" eingetragen werden muss.
DNS-Server können auch einen sogenannten "Reverse-Lookup" machen, bei dem sie eine IP-Adresse in den dazugehörigen Domainnamen auflösen können. Dies wird aber eigentlich nur für Netzwerk-Debugging verwendet sowie für eine Kontrolle, ob der DNS-Server die richtige IP-Adresse geliefert hat (es könnte sein, dass ein Hacker die DNS-Anfrage abgefangen und falsch beantwortet hat [DNS-Spoofing], und so den Client auf einen falschen Server verweist).

Für den Normaluser stellt sich oft das Problem, dass er mehrere Computer z.B. über eine DSL-Leitung mit dem Internet verbinden will. Vom Provider bekommt man aber nur eine einzige (oder vielleicht auch mehr, auf jeden Fall zuwenige) IP-Adressen per DHCP zugewiesen. Das Resultat ist, dass diejenigen Computer, die später eingeschaltet wurden, keine IP mehr erhalten und daher keinen Netzwerkzugriff haben. Ausserdem, wenn man die Windows Datei- und Druckerfreigabe im eigenen LAN nutzen will, öffnet man seine Windows-Shares nicht nur für die Computer des eigenen LANs, sondern gleich fürs ganze Internet... Das ist ja wohl nicht gewünscht. Beide Probleme löst ein NAT/Masquerading-Router.

Dieser Router macht nichts anderes, als viele private IP-Adressen hinter einer öffentlichen IP zu "verstecken". Wie ein solcher Transfer dann aussieht, ist aus der Grafik rechts ersichtlich.
Dabei fällt auf, dass das NAT/Masquerading nicht nur die Absenderadresse verändert, sondern auch den Absenderport. Dies ist nötig, damit es auf dem NAT/Masquerading-Interface des Routers nicht zu überschneidungen der Ports kommt, wenn mehrere Clients gleichzeitig online sind. Von aussen gesehen scheinen nun alle Verbindungen vom Router direkt zu kommen, das dahinterliegende LAN wird versteckt, die darin verwendeten IP-Adressen gelangen nie nach aussen und können daher praktisch beliebig gewählt werden; Es ist jedoch vorteilhaft, einen privaten IP-Bereich zu wählen:

Ein privates A-Klass-Netz (16646144 Rechner in dem einen möglichen Subnet):
10.x.y.z, Subnet-Mask 255.0.0.0

16 private B-Klass-Netze (65024 Rechner pro Subnet):
172.16.x.y bis 172.31.x.y, Subnet-Mask 255.255.0.0

256 private C-Klass-Netze (254 Rechner pro Subnet):
192.168.0.x bis 192.168.255.x, Subnet-Mask 255.255.255.0

Dabei ist die Zuordnung zwischen dem IP-Bereich und der Subnet-Mask nicht zwingend; es kann auch beispielsweise der 10.x.y.z-Bereich mit der Subnet-Mask 255.255.0.0 verwendet werden, es ist jedoch "schöner", dies zu vermeiden.

Ein Problem taucht jetzt auf: Wenn man auf einem Rechner im LAN, dessen IP ja von aussen nicht sichtbar ist, einen Server-Dienst anbieten möchte (z.B. einen Webserver auf Port 80), dann klappt das so nicht. Weshalb? Nun, mit der IP, die der Rechner im LAN hat, kann man ihn von aussen nicht erreichen wegen dem NAT/Masquerading; man ist gezwungen, die einzige öffentliche IP die man hat (diejenige des NAT/Masquerading-Interfaces des Routers) zu verwenden.
Wenn nun aber der Router eine HTTP-Anfrage erhält, hat er keine Ahnung, was er damit anfangen soll und lässt entsprechende Datenpakete fallen. Per Port-Forwarding, auch Port-Mapping genannt, kann man den Router nun anweisen, entsprechende Anfragen an einen internen Server weiterzuleiten. Dabei wird der Port 80 auf die interne IP des Webservers "gemappt".

Das Grundproblem liegt ja darin, dass man im LAN Serverdienste anbieten möchte, diese sollten aber nur für die Rechner im LAN zugänglich sein, keinesfalls für die Rechner aus dem Internet. Ein NAT/Masquerading-Router bietet hier schon verhältnismässig viel Schutz; Es können ja grundsätzlich keine Verbindungen vom Internet ins LAN hergestellt werden, die Verbindungen können nur aus dem LAN ins Internet aufgebaut werden (wer das nicht versteht sollte sich das letzte Kapitel über NAT/Masquerading-Router nochmals ansehen). Trotzdem ist ein sauber konfigurierter Paketfilter auch hier empfehlenswert.
Ein simpler Paketfilter basiert darauf, die Pakete anhand ihrer Quell-/Ziel-Adresse und insbesondere anhand ihres Quell-/Ziel-Portes zu sortieren und entweder durchzulassen oder abzulehnen. Einfaches Beispiel:
Im LAN bietet ein Rechner einen Serverdienst für die Windows Datei- und Druckerfreigabe an. Dieser soll natürlich nur für Rechner im LAN zugänglich sein. Also verbietet man Rechnern aus dem Internet, Pakete mit dem Zielport 139 (das ist derjenige der Datei- und Druckerfreigabe) ins LAN zu schicken:
DROP: PROTOCOL tcp, SOURCE any host any port, DESTINATION any host port 139
"DROP" heisst, dass der Filter das Paket einfach ignorieren soll (DROP = fallen lassen); "PROTOCOL tcp" heisst, dass diese Regel nur fürs TCP-Protokoll gelten soll, "SOURCE any host any port" heisst, dass die Regel für alle Quell-Rechner (IP und Quellport egal) gelten soll und "DESTINATION any host port 139" heisst, dass die Ziel-IP egal sein soll, aber zwingend muss der Zielport 139 sein, damit die Regel zutrifft. Die Regeln können auch an einzelne Interfaces gebunden werden; bei diesem Beispiel würde es sinn machen, die Regeln nur ans externe Interface zu binden (sonst wäre es für die Rechner des LANs nicht möglich, auf einen Server im Internet mit Server-Port 139 zuzugreiffen; wobei dies normalerweise nicht stört, wer im Internet bietet schon willentlich Server-Dienste mit der Datei- und Druckerfreigabe an...). Es wird auch unterschieden zwischen hereinkommenden Paketen und hinausgehenden Paketen; das sind bei einem typischen Router mit zwei Netzwerkkarten also vier mögliche sog. "queues", um die Daten zu filtern.
Ein Paketfilter hat für jede Queue einen ganzen Stapel von Regeln; diese Stapel werden von oben her abgearbeitet. Sobald SOURCE und DESTINATION zutreffen, wird die Regel angewendet! Wenn also eine Regel zuoberst ist, die alles erlaubt:
ACCEPT: PROTOCOL any, SOURCE any host any port, DESTINATION any host any port
dann ist es völlig egal, was danach noch verboten wird: alle Pakete werden akzeptiert.
Jetzt möchte ich mal ein typisches Beispiel zeigen, das mir für den Home-User einigermassen sinnvoll scheint. Folgende Regeln müssen in der Input-Queue des externen Interfaces stehen (d.h. alle Pakete, die ins LAN wollen, werden erst mal gefiltert):

(1) ALLOW: PROTOCOL tcp, SOURCE any host any port, DESTINATION any host port>1023
(2) ALLOW: PROTOCOL udp, SOURCE any host any port, DESTINATION any host port>1023
(3) ALLOW: PROTOCOL udp, SOURCE any host port 67, DESTINATION any host port 68
(4) ALLOW: PROTOCOL icmp, SOURCE any host, DESTINATION any host
(5) DENY: PROTOCOL tcp, SOURCE any host any port, DESTINATION any host any port
(6) DENY: PROTOCOL udp, SOURCE any host any port, DESTINATION any host any port

Schauen wir uns das mal im Detail an.

(1):
Alle TCP-Pakete, die ins LAN wollen mit einem Zielport über 1023 werden akzeptiert. Die Gefährlichen Dienste haben normalerweise privilegierte Ports (unter 1024), und diese werden hier nicht erlaubt.

(2):
Dasselbe für die UDP-Pakete. UDP wird hauptsächlich für Spiele verwendet (sowie DNS und DHCP), deshalb müssen UDP-Pakete auch erlaubt werden. Auch hier sind die Server-Dienste normalerweise unter Port 1024.

(3):
Das ist ein Spezialfall, es ist nötig, damit das externe Interface deines Rechners per DHCP konfiguriert werden kann. Der DHCP-Client verwendet den Client-Port 68 und der DHCP-Server verwendet den Server-Port 67, diese Regel erlaubt nun dem Server, eine Antwort zu schicken. Die Quelle ist der Server-Port 67, das Ziel der Client-Port 68. Da DHCP ausschliesslich über UDP läuft, wird das Ganze auch nur für UDP erlaubt.

(4):
ICMP-Pakete werden hier alle erlaubt. Sie sind wichtiger Bestandteil der "Wegfindung durch das Internet" und dienen auch dem Netzwerk-debugging. Zu beachten ist, dass hier das "port"-Statement fehlt. Das kommt daher, dass ICMP nicht mit Ports arbeitet.

(5) und (6): Alles, was bisher nicht explizit erlaubt wurde, ist nicht erwünscht und wird daher verboten.

Wie gesagt, diese Regeln gelten für die Incoming-Queue des externen Interfaces. Wer auf Nummer sicher gehen will kann eine symmetrische Konfiguration für die Outgoing-Queue des externen Interfaces machen; wenn die Incoming-Queue also falsch konfiguriert sein sollte, dann können aus dem Internet zwar Daten ins LAN geschickt werden, aber die Server im LAN können bei korrekter Output-Queue nicht antoworten, und der Zweck des Paketfilters ist auch erfüllt. Zur kontrolle kannst du jetzt ja mal die Regeln für die Output-Queue versuchen aufzuschreiben, hier auf jeden Fall mal die Lösung:

(1) ALLOW: PROTOCOL tcp, SOURCE any host port>1023, DESTINATION any host any port
(2) ALLOW: PROTOCOL udp, SOURCE any host port>1023, DESTINATION any host any port
(3) ALLOW: PROTOCOL udp, SOURCE any host port 68, DESTINATION any host port 67
(4) ALLOW: PROTOCOL icmp, SOURCE any host, DESTINATION any host
(5) DENY: PROTOCOL tcp, SOURCE any host any port, DESTINATION any host any port
(6) DENY: PROTOCOL udp, SOURCE any host any port, DESTINATION any host any port

Klar, jetzt müssen einfach die SOURCE- und DESTINATION-Ports und Adressen vertauscht werden, denn der Output-Traffic geht ja genau in die entgegengesetzte Richtung des Input-Traffics.

Die tatsächliche Implementation dieser Regeln, also wie sie er Routing-Software beigebracht werden müssen, variiert extrem. Auch gibt es manchmal sehr viele zusätzliche Möglichkeiten. Für weiterführende Beispiele möchte ich auf Das "eierlegende Wollmilchsau" Router Projekt verweisen, wo ich IPTABLES einen recht grossen Abschnitt gewidmet habe. Die Syntax dort ist zwar Linux-spezifisch, aber die grundsätzlichen Funktionen und die Konzepte sind überall ähnlich.