VOICE Homepage: http://de.os2voice.org
[Inhaltsverzeichnis]
[Vorherige Seite] [Nächste Seite]
[Artikelverzeichnis]
|
VOICE Homepage: http://de.os2voice.org |
März 2002
[Inhaltsverzeichnis]
|
| Von Peter Moylan © März 2002, Übersetzung: Thomas Klein |
Ursprünglich schrieb ich diesen Artikel im Zusammenhang mit einem bestimmten
Problem: Ist es möglich, einen FTP-Server an's Laufen zu bekommen, wenn sich
dieser hinter einer Firewall befindet? Aus diesem Grund werden Sie hier zahlreiche
Verweise auf FTP vorfinden. Dennoch sollte dies auch für diejenigen unter den
Lesern interessant sein, die sich nicht unbedingt für FTP interessieren, aber dafür,
wie Netzwerke funktionieren.
Das Internet Protocol (IP) stellt die Grundfunktion zur Übertragung eines
Datenpakets von einem Knoten zu einem anderen zur Verfügung. Jedes IP-Paket
enthält Kopfdaten ("header"), die unter anderem Sender- und Empfängeradresse
des Datenpakets enthalten. Diese Adressen sind bekannt unter der allgemeinen
Bezeichnung IP-Adresse.
Innerhalb des mehrstufigen OSI-Referenzmodells für Netzwerkprotkolle ist das
Terminal Control Protocol (TCP) eine übergeordnete Schicht zum IP. Es wird für
weitergehende Funktionen verwendet, benötigt aber natürlich immer noch IP um die
eigentliche Übertragung der Befehls- und Datenpakete zu gewährleisten. Mehr
Informationen zu TCP und TCP/IP-Anwendungen erhalten Sie, wenn Sie auf der OS/2
Befehlszeile TCPhelp eingeben.
Die IP-Adressen im Format
Irgendwann im Laufe des Betriebs hat ein Netzwerkknoten mehrere Verbindungen
zu unterschiedlichen anderen Rechnern im Netzwerk aufgebaut. Wir brauchen jetzt
also einen Weg, diese Verbindungen zu kennzeichnen, um sie auseinanderhalten zu
können. Hierfür verwenden wir (an unserem Ende) Portnummern. Diese Portnummern
haben aber nichts mit den Hardware-I/O-Ports zu tun. Es handelt sich lediglich
um eine Nummerierungsmethode für die Verbindungen. Portnummern werden durch
vorzeichenlose 16-Bit-Zahlen dargestellt. Je ein Ende einer Verbindung wird
eindeutig identifiziert durch die Paarung von IP-Adresse + Portnummer.
Softwaretechnisch wird dieser Mechanismus durch sockets realisiert.
Einen socket können Sie sich vorstellen als Datenstruktur, die stets beide
IP-Adressen und beide Portnummern aufzeichnet, zusammen mit allen anderen für
die Verbindung vielleicht benötigten Angaben (Datenpuffer, Bytezähler, etc.).
Beim erstmaligem Erzeugen eines sockets kennen wir nur die IP-Adresse und den
Port an "unserem" Ende der Verbindung. Kommt nun eine Verbindung zustande,
wird uns IP-Adresse und Portnummer der Gegenstelle mitgeteilt. Natürlich muß
dabei eine der beiden Stellen der "Auslöser" der Verbindung sein. Der übliche
Mechanismus hierfür ist, daß ein Server sich im Bereitschaftszustand befindet
und auf Verbindungsanforderungen von Clients wartet, wobei das "clientseitige
Ende" den eigentlichen Verbindungsaufbau übernimmt.
Die Portnummern im Bereich 0 bis 49151 sind für "server"-Ports
reserviert. Genauer gesagt ist der Bereich von 0 bis 1023 sogar durch offizielle
Standards definiert. Die Ports 1024 bis 49151 sind zwar nicht ganz so offiziell,
jedoch zumindest "registrierte Ports", die von vorgegebenen Anwendungen
verwendet werden. Eine Liste dieser reservierten Ports können Sie sich in der
Datei \MPTN\ETC\SERVICES auf dem Systemlaufwerk anschauen.
Portnummern von 49152 bis 65535 bilden den Bereich der sogenannten
"freien" Ports, die immer dann verwendet werden, wenn ein neuer Port
benötigt wird. Ein solcher Port wird typischerweise für eine kurzzeitige Verbindung
angefordert und nach Beendigung des Vorgangs wieder freigegeben.
In einem Client/Server-Protokoll muss der Client eine Möglichkeit haben, den
Server zu finden. Aus diesem Grund warten Server grundsätzlich auf bekannten Ports
("well known ports"), die für diese Zwecke reserviert werden, auf
Anforderungen durch die Clients. Das FTP-Protokoll verwendet beispielsweise zwei
Kanäle - einen für Befehle und einen für Daten. Als Konsequenz daraus gibt es
zwei "well known ports": Port 21 für die Befehle und Port 20 für die Daten. Das
ist aber natürlich nur auf der Server-Seite so. Der Client kann für die Verbindung
einen beliebigen Port verwenden und normalerweise wird hierfür dann ein Port aus
der Menge der "freien Ports" angefordert.
Das FTP-Protokoll kennt zwei Arten der Datenübertragung. Im sogenannten
"passiven" Modus wird der Datentransfer clientseitig initiiert. Im nicht-passiven
FTP, auch bekannt als "port FTP", geschieht das durch den Server. In
beiden Fällen wird für die Befehlsübertragung serverseitig Port 21 verwendet.
Der Unterschied zwischen den beiden Modi liegt in der Art, wie der Datenport
angefordert wird.
227 Entering passive mode (127,0,0,1,203,197)
Die ersten vier Ziffern geben die IP-Adresse des Servers an. Die beiden übrigen
Ziffern geben eine Portnummer an. Eigentlich sagt der Befehl PASV nichts anderes
als "Bitte such Dir einen Datenport aus und sag' mir, welcher es ist".
Der Server wählt den Port (normalerweise aus seinem Vorrat an freien Ports) und
sendet dessen Nummer zurück an den Client. Dann wartet der Server auf dem angegebenen
Port auf den Verbindungsaufbau durch den Client. Natürlich muß auch der Client
auf seiner Seite einen Port auswählen - der Server erkennt diesen Port nachdem
die Verbindung vom Client aufgebaut wurde.
Im passiven FTP verhalten sich der Port des Befehlskanals und des Datenkanals
gleich: der Server wartet auf einem bekannten Port. Der Client kennt diesen Port
und kann daher eine Verbindung dorthin aufbauen.
Das wird durch den PORT Befehl erreicht, den der Client sendet. Beispiel:
PORT 127,0,0,1,203,201
Der Client sendet hierdurch seine IP-Adresse und den Port, den er für die
Datenübertragung gerne verwenden möchte. Das bedeutet also, daß der Client eine
Portnummer auswählt und auf diesem Port auf eine Verbindung wartet, die durch den
Server aufgebaut wird. Sowohl in diesem Beispiel als auch für den obigen PASV
Befehl war die IP-Adresse 127.0.0.1. Das kommt daher, daß ich in beiden Fällen
das loopback device meines Rechners zur Erzeugung der Beispiele verwendet habe.
Falls Sie das selbst ausprobieren, werden die IP-Adressen natürlich ganz anders
aussehen, in Abhängigkeit davon, was bei Ihnen eingestellt ist.
Natürlich muß der Server nun auch noch eine Portnummer auf seiner Seite
auswählen. Standardmäßig wird das fast immer Port 20 sein.
Beachten Sie, daß der Client grundsätzlich entweder den Befehl PASV oder PORT
senden muß, bevor ein upload oder download gestartet wird. Die Auswahl des
verwendeten Befehls bestimmt, ob passive oder nicht-passive Übertragung eingesetzt
wird.
Sinn und Zweck einer Firewall ist es, bestimmte Datenpakete passieren zu lassen
und andere eben nicht. Dies wird durch Regeln erreicht, die der Systemadministrator
festlegt. Hierfür muß dieser entscheiden, welche Arten des Datenverkehrs zulässig
sind.
Ich habe nicht gerade viel Erfahrung mit Firewalls und kann Ihnen daher keine
erschöpfende Auskunft darüber geben, was da so abläuft. Ich glaube aber, daß diese
Regeln (auch) auf Portnummern basieren. Datentransfer von/zu bestimmten Ports wird
unterbunden. Normalerweise sollten diese Regeln insofern asymmetrisch sein, als
daß die Regeln bezüglich abgehenden Paketen sich ziemlich von denen unterscheiden,
die die eingehenden Pakete betreffen.
Betrachten wir einmal den Fall, wo sich ein FTP-Client hinter einer Firewall
befindet und mit einem Server kommunizieren will, der sich nicht hinter einer
Firewall befindet. Typische Firewallregeln würden nicht-passives FTP verbieten,
denn dafür wäre es notwendig, daß der Server - also der Rechner "außerhalb" der
Firewall - die Verbindung einleitet. Firewalls sind häufig so konfiguriert, daß
es außenstehenden Rechnern nicht gestattet ist, eine Verbindung in die geschützte
Zone aufzubauen. Tatsächlich ist dieses Problem einer der Hauptgründe dafür, daß
passives FTP in den FTP-Standard aufgenommen wurde. Wenn sich der Client hinter
einer Firewall befindet, sollte er eigentlich ausschließlich den passiven Modus
verwenden.
Im umgekehrten Fall, wo sich der Server hinter einer Firewall befindet und
der Client nicht, ist es sehr wahrscheinlich, daß passives FTP nicht funktioniert
und Port-FTP der einzig gangbare Weg ist.
Wenn sich aber nun der Client hinter einer Firewall befindet und der Server
hinter einer anderen, steht uns Ärger ins Haus. Das Konzept der Firewall wurde
nicht vor dem Hintergrund einer solchen Konstellation entworfen. Server dürften
eigentlich nicht hinter einer Firewall stehen, es sei denn natürlich, daß sie
für das private LAN gedacht sind. Wenn Sie also zum Schutz ihres LANs eine Firewall
einsetzen, sollten Sie die öffentlichen Serveranwendungen auf dem Rechner laufen
lassen, der auch die Firewallsoftware betreibt. Dadurch befindet sich der Server
technisch gesehen außerhalb der Firewall.
Wenn Sie Ihren Server aus irgendeinem Grund unbedingt hinter einer Firewall
betreiben müssen, sollten Sie über etwas Fachwissen in Bezug auf die Definition
der Firewallregeln verfügen. Lesen Sie die vorherigen Abschnitte sorgfältig um
sicherzustellen, daß Ihre Regeln die richtigen Portnummern beinhalten. Dieser
Teil ist noch relativ einfach. Schwieriger ist es, das ganze so zu machen, daß
der FTP Server funktioniert, ohne die Sicherheit Ihres LANs dafür zu opfern. Wenn
Sie die Regeln zu lasch setzen, können Sie sich die Firewall auch direkt sparen.
Ein IP-Datenpaket besitzt einen Header, der unter anderem die IP-Adressen von
Sender und Empfänger beinhaltet - also wo das Paket herkommt und wo es hingeht.
Mit aktiviertem NAT wird die Firewall dazu veranlasst, die Sender-IP-Adresse im
Header des Datenpakets zu ändern, wodurch der Eindruck entsteht, es stamme von
einer anderen Adresse. Soviel zum Ausgangsdatenstrom; beim eingehenden Verkehr
fängt die Firewall die Pakete ab, die jetzt für die "vorgetäuschte"
IP-Adresse bestimmt sind und sendet sie stattdessen an den eigentlichen Empfänger
indem die Zieladresse im Header entsprechend geändert wird.
Betrachten wir nun wieder den Fall, wo sich der FTP-Client hinter der Firewall
befindet und der Server außerhalb. Wenn der Client die Verbindung zum Server
aufbaut, sieht dieser dann nicht die echte IP-Adresse des Clients, sondern die der
Firewall. Der Server hat natürlich keine Ahnung, daß die Firewall überhaupt
existiert. Er arbeitet ganz simpel mit der erhaltenen Adresse, so, wie er es auch
mit jedem anderen Client macht. Aus Sicht des Servers ist der Client einfach die
Firewall. Diese allerdings gibt die vom Server kommenden Pakete einfach weiter an
den echten Client.
Im Umkehrschluß denken alle Clients außerhalb einer Firewall, daß es sich bei
dieser um den FTP-Server handelt, der in Wirklichkeit hinter der Firewall steht.
Die Firewall verändert die IP-Adressen der Clients und gibt die geänderten Pakete
an den Server weiter.
Das klappt eigentlich alles sehr gut, bis auf zwei kleine Details: Wie wir aus
vorangegangenen Beispielen wissen, senden die Befehle PASV und PORT in ihren Daten
auch IP-Aressen. Da die Firewall (bzw. die NAT-Software) aber nur die IP-Adressen
in den Headern der Pakete ändert, werden also dummerweise immer noch die echten
IP-Adressen übermittelt, was dazu führen kann, daß die Pakete an die falsche
Adresse gesendet werden oder schlicht verlorengehen.
Als logische Konsequenz wäre die Lösung für dieses Dilemma, die NAT-Software
so einzustellen, daß sie die Befehle PASV und PORT ebenfalls abfängt um die
damit übermittelten IP-Adressen entsprechend abzuändern. Einige Firewallsysteme
sind pfiffig genug, um dies zu erkennen. Leider verfügen aber viele andere Systeme
nicht über diese Option.
In der Vergangenheit dachte aber normalerweise niemand daran, einen FTP-Server
hinter eine Firewall zu setzen. Jetzt, wo Kabelmodems, ADSL und diverse andere
Hochgeschwindigkeitsverbindungen immer selbstverständlicher werden, hat sich das
geändert. Um mit diesem Problem umgehen zu können, müßte der FTP-Server in der
Lage sein, in seiner Antwort auf den PASV-Befehl die IP-Adresse der Firewall
anstelle seiner eigenen anzugeben.
Genauso sollte ein FTP-Client, der sich hinter einer Firewall befindet, die Parameter seines PORT-Befehls entsprechend auf die Firewall anpassen. (Im Fall des PORT-Befehls muß das Problem auf der Seite des Client gelöst werden.) In Wirklichkeit habe ich aber noch nie von einem FTP-Client gehört, der sich so verhält. Das bedeutet also, daß ein FTP-Client hinter einer Firewall grundsätzlich passives FTP verwenden muß.
Quellenverzeichnis:
|
[Artikelverzeichnis]
editor@os2voice.org
[Vorherige Seite] [Inhaltsverzeichnis] [Nächste Seite]
VOICE Homepage: http://de.os2voice.org