Auswahl der zu verwendenden Ports

[Michael Schröpl]

Hallo Forum,

ich habe ein Problem mit der Verwendung eines FTP-Clients durch eine Firewall.
Das Problem ist dem Programmierer des FTP-Clients gemeldet, dieser meint aber, es nicht beheben zu können.
Ich würde gerne sicherstellen, daß ich selbst den Sachverhalt hinreichend genau verstanden habe (FTP ist nicht so meine Welt ...), deshalb versuche ich mal, den Effekt kurz zu beschreiben. Ideen und Anregungen aller Art könnten eventuell weiter helfen.

Nach meinem Erkenntnisstand baut ein FTP-Client eine Verbindung zu dem gewünschten FTP-Server normalerweise über den dafür reservierten Port 20 (?) auf.
Da der FTP-Server diesen Port aber nicht dauerhaft belegt haben will, handeln Client und Server anschließend andere Ports aus, über welche dann tatsächlich Daten übertragen werden - genau so, wie das bei HTTP mit Port 80 läuft, der auch nur für die Verbindungsaufnahme zuständig ist.

Der Client nimmt in meinen Fall nun irgendwelche Ports, die ggf. im Bereich zwischen 1800 und knapp über 2000 liegen. Genau darauf behauptet der Programmierer, keinen Einfluß zu haben: Er ruft eine Windows-API "gib mir einen freien Port" auf und nimmt, was er zurück bekommt. (Seine "Programmiersprache" ist Borland-Delphi.)
Bei den genannten Ports sind allerdings einige "well-known ports" dabei - jedenfalls nach der Aufffassung unserer Firmen-Firewall. (Beispiel: 2045) Selbige ist fest davon überzeugt, daß über diese speziellen Ports andere Protokolle als FTP zu laufen haben, und bricht den Kommunikationsversuch an dieser Stelle ab: Offenbar hat da ja irgend ein böser Angreifer versucht, einen Port zweckzuentfremden.
Gerade bei der Übertragung einer großen Anzahl von Dateien (FTP-"MGET") werden auf diese Weise sehr viele verschiedene Ports verwendet - und früher oder später würfelt der Client schlecht und erwischt einen Port, bei dem ihm die Firewall auf die Finger haut. Die Übertragung vieler kleiner Dateien bricht also alle paar Minuten ab - die Übertragung einiger weniger großer Dateien funktioniert dagegen reibungslos.

Meine Frage wäre nun im wesentlichen:

• Kann der FTP-Client unter Windows irgendwie den Port, den er für die Übertragung einer einzelnen Datei nehmen will, gezielt setzen?
  Eine Abfrage an das Betriebssystem, ob der Port frei ist, muß natürlich weiterhin sein - es laufen ja ggf. noch weitere Programme, die FTP machen, eventuell sogar dasselbe Programm in mehreren Instanzen.

Der Programmierer des FTP-Client hat empfohlen, im "passive mode" zu arbeiten; der Firewall-Administrator meinte dazu, das müßten dann aber die entsprechenden FTP-Server auch unterstützen, und das wäre (im WWW) nicht gerade die Regel ... ?

Mit der Hoffnung auf (für mich) überraschende neue Erkenntnisse
    Michael Schröpl

[Sven Rautenberg]

Hallo Forum,

Moin auch!

Mal ein paar Kommentare von mir:

Nach meinem Erkenntnisstand baut ein FTP-Client eine Verbindung zu dem gewünschten FTP-Server normalerweise über den dafür reservierten Port 20 (?) auf.
Da der FTP-Server diesen Port aber nicht dauerhaft belegt haben will, handeln Client und Server anschließend andere Ports aus, über welche dann tatsächlich Daten übertragen werden - genau so, wie das bei HTTP mit Port 80 läuft, der auch nur für die Verbindungsaufnahme zuständig ist.

Das ist definitiv FALSCH. Bei der HTTP-Kommunikation laufen alle Verbindungen zwischen Client und Server auf der Serverseite ausschließlich über Port 80. Nur der Client benutzt wechselnde Ports, aber niemals Port 80, da in der Regel für ausgehende Verbindungen freie Ports oberhalb von 1024 benutzt werden - je neuer Verbindung ein neuer Port, damit man die Verbindungen irgendwie unterscheiden kann.

Bei FTP mag das anders sein, da gibts neben dem normalen Port 21 auch noch einen Port 20 für "FTP-Data", der augenscheinlich für Datentransport zuständig ist.

Der Client nimmt in meinen Fall nun irgendwelche Ports, die ggf. im Bereich zwischen 1800 und knapp über 2000 liegen. Genau darauf behauptet der Programmierer, keinen Einfluß zu haben: Er ruft eine Windows-API "gib mir einen freien Port" auf und nimmt, was er zurück bekommt. (Seine "Programmiersprache" ist Borland-Delphi.)

Korrekt!

Bei den genannten Ports sind allerdings einige "well-known ports" dabei - jedenfalls nach der Aufffassung unserer Firmen-Firewall. (Beispiel: 2045) Selbige ist fest davon überzeugt, daß über diese speziellen Ports andere Protokolle als FTP zu laufen haben, und bricht den Kommunikationsversuch an dieser Stelle ab: Offenbar hat da ja irgend ein böser Angreifer versucht, einen Port zweckzuentfremden.

Das ist Sache der Firmen-Firewall, zu entscheiden, ob von innen heraus irgendwelche Ports benutzt werden dürfen, die normalerweise auch von anderen Programmen benutzt werden. Auf diese Weise sperrt man zum Beispiel die MP3-Sharing-Programme, solange die den Default-Port benutzen.

Gerade bei der Übertragung einer großen Anzahl von Dateien (FTP-"MGET") werden auf diese Weise sehr viele verschiedene Ports verwendet - und früher oder später würfelt der Client schlecht und erwischt einen Port, bei dem ihm die Firewall auf die Finger haut. Die Übertragung vieler kleiner Dateien bricht also alle paar Minuten ab - die Übertragung einiger weniger großer Dateien funktioniert dagegen reibungslos.

Da mußt du deinem Netzwerkadministrator auf die Finger hauen, daß er die Firewall mal etwas freundlicher konfiguriert.

Meine Frage wäre nun im wesentlichen:

• Kann der FTP-Client unter Windows irgendwie den Port, den er für die Übertragung einer einzelnen Datei nehmen will, gezielt setzen?
  Eine Abfrage an das Betriebssystem, ob der Port frei ist, muß natürlich weiterhin sein - es laufen ja ggf. noch weitere Programme, die FTP machen, eventuell sogar dasselbe Programm in mehreren Instanzen.

Der Programmierer des FTP-Client hat empfohlen, im "passive mode" zu arbeiten; der Firewall-Administrator meinte dazu, das müßten dann aber die entsprechenden FTP-Server auch unterstützen, und das wäre (im WWW) nicht gerade die Regel ... ?

Genau. Der Passive-Mode nutzt irgendwie bestehende Verbindungen zur Datenübertragung, wird aber tatsächlich nicht unbedingt von allen FTP-Servern unterstützt. Ausprobieren heißt die Devise.

Wenn ich mich recht erinnere, dann ist FTP im Normalfall so ein Protokoll, welches ständig neue Verbindungen zum Server knüpft (also im Gegensatz zu HTTP). Passive Mode unterbindet das, und könnte in deinem Fall wirklich helfen.

Mit der Hoffnung auf (für mich) überraschende neue Erkenntnisse

Überrascht?

- Sven Rautenberg

[Christian Kruse]

Hoi,

Nach meinem Erkenntnisstand baut ein FTP-Client eine Verbindung
zu dem gewünschten FTP-Server normalerweise über den dafür
reservierten Port 20 (?) auf.

21 ;-)

Da der FTP-Server diesen Port aber nicht dauerhaft belegt haben
will, handeln Client und Server anschließend andere Ports aus,
über welche dann tatsächlich Daten übertragen werden - genau
so, wie das bei HTTP mit Port 80 läuft, der auch nur für die
Verbindungsaufnahme zuständig ist.

Tatsache ist, dass FTP fuer Daten, die uebertragen werden muessen,
eine neue Verbindung aufbaut. Der Port fuer diese Verbindung liegt
irgendwo > 1024.

Das ist definitiv FALSCH. Bei der HTTP-Kommunikation laufen alle
Verbindungen zwischen Client und Server auf der Serverseite
ausschließlich über Port 80.

Ja.

Nur der Client benutzt wechselnde Ports, aber niemals Port 80,
da in der Regel für ausgehende Verbindungen freie Ports oberhalb
von 1024 benutzt werden - je neuer Verbindung ein neuer Port,
damit man die Verbindungen irgendwie unterscheiden kann.

Auch das stimmt.

Bei FTP mag das anders sein, da gibts neben dem normalen Port 21
auch noch einen Port 20 für "FTP-Data", der augenscheinlich für
Datentransport zuständig ist.

Ja. Aber dieser Port wird AFAIK nur fuer passive ftp benutzt. Aktives
handelt einen beliebigen Port aus.

Das ist Sache der Firmen-Firewall, zu entscheiden, ob von innen
heraus irgendwelche Ports benutzt werden dürfen, die
normalerweise auch von anderen Programmen benutzt werden. Auf
diese Weise sperrt man zum Beispiel die MP3-Sharing-Programme,
solange die den Default-Port benutzen.

IMHO ist das ziemlich sinnlos. Denn wenn ein 'Hacker' wirklich einen
Port zweckentfremden will, dann weiss er auch, wie er die Pakete
als FTP maskiert.

Der Programmierer des FTP-Client hat empfohlen, im "passive
mode" zu arbeiten; der Firewall-Administrator meinte dazu, das
müßten dann aber die entsprechenden FTP-Server auch
unterstützen, und das wäre (im WWW) nicht gerade die
Regel ... ?

Doch, eigentlich schon.

Genau. Der Passive-Mode nutzt irgendwie bestehende Verbindungen
zur Datenübertragung, wird aber tatsächlich nicht unbedingt von
allen FTP-Servern unterstützt. Ausprobieren heißt die Devise.

Das wird von allen aktuellen FTP-Servern unterstuetzt.

Wenn ich mich recht erinnere, dann ist FTP im Normalfall so ein
Protokoll, welches ständig neue Verbindungen zum Server knüpft
(also im Gegensatz zu HTTP). Passive Mode unterbindet das, und
könnte in deinem Fall wirklich helfen.

Ja.

Gruesse,
 CK

[Gero Takke]

Holdrio,

»» Bei FTP mag das anders sein, da gibts neben dem normalen Port 21
»» auch noch einen Port 20 für "FTP-Data", der augenscheinlich für
»» Datentransport zuständig ist.
Ja. Aber dieser Port wird AFAIK nur fuer passive ftp benutzt. Aktives
handelt einen beliebigen Port aus.

Nein. Ich weiss nicht, was aktives FTP macht, aber ich habe mal einen
Client fuer passives FTP geschrieben.
Das laeuft so:
Man gibt dem Server ein PASV Kommando, der Server beantwortet das mit
folgender Ausgabe:
227 Entering Passive Mode (127,0,0,1,134,157).

134 ist der Divisor des Ports von 256 und 157 der Modulus, oder wie
diese komischen mathematischen Begriffe heissen - auf jeden Fall:
134 * 256 + 157 ergibt den Port, auf dem _der Server_ horcht, um nach
einem Connect vom Client die Daten zu uebertragen.

Ich denke mal, dass bei Active FTP die Ports beim Client zum horchen
fuer Connects vom Server aufgemacht werden. Passive FTP ueber eine
Firewall zu blocken waere mir irgendwie ein wenig suspekt, weil man
dazu ausgehenden Traffic filtern muss, wofuer ich keinen wirklichen
Sinn sehe (jaja, Trojaner, ich weiss.)

»» »» Der Programmierer des FTP-Client hat empfohlen, im "passive
»» »» mode" zu arbeiten; der Firewall-Administrator meinte dazu, das
»» »» müßten dann aber die entsprechenden FTP-Server auch
»» »» unterstützen, und das wäre (im WWW) nicht gerade die
»» »» Regel ... ?
Doch, eigentlich schon.

Ja, ich kenne nur wenige Server, die Passive FTP nicht unterstuetzen.
Meistens klappts, zumindest bei mir.

»» Wenn ich mich recht erinnere, dann ist FTP im Normalfall so ein
»» Protokoll, welches ständig neue Verbindungen zum Server knüpft
»» (also im Gegensatz zu HTTP). Passive Mode unterbindet das, und
»» könnte in deinem Fall wirklich helfen.
Ja.

Nein ;-)

Tschuess,
Gero

[Gero Takke]

Nochmal Hoi,

»»  »» Wenn ich mich recht erinnere, dann ist FTP im Normalfall so ein
»»  »» Protokoll, welches ständig neue Verbindungen zum Server knüpft
»»  »» (also im Gegensatz zu HTTP). Passive Mode unterbindet das, und
»»  »» könnte in deinem Fall wirklich helfen.
»»  Ja.
Nein ;-)

Ich meine natuerlich: Ja, es koennte helfen, Nein, es unterbindet nicht,
dass mehrere Verbindungen zum Server aufgemacht werden.
Sorry fuers Doppelpost.

T.

[Michael Schröpl]

Hi Christian,

zu dem gewünschten FTP-Server normalerweise über den dafür
reservierten Port 20 (?) auf.
21 ;-)

Yep - meine Erinnerung war ungenau (und das Fragezeichen hat seinen
Zweck erfüllt ;-).

Das ist definitiv FALSCH. Bei der HTTP-Kommunikation laufen alle
Verbindungen zwischen Client und Server auf der Serverseite
ausschließlich über Port 80.
Ja.

Wie könnte dann der Server gleichzeitig mehr als einen Client bedienen?
"snoop" mal eine solche Maschine - Du wirst Dich wundern, was für Ports
HTTP verwendet ...

---

Wir sind der Sache inzwischen etwas weiter nachgegangen.

Zunächst mal: Mit anderen Windows-FTP-Clients (etwa dem "ftp"-Kommando
der WinNT-cmd-Box) tritt exakt dasselbe Problem auf.

Beide scheinen von Windows einen beliebigen freien Port oberhalb von
1024 zugeteilt zu bekommen. Das ist auch okay, so, wie ich dem Dokument
entnehme, auf welches Rolf gelinkt hat.

Nur sind dort eben eine ganze Menge Ports "well known".
1024 ist zwar "legal", aber nicht "schlau".
Nehme ich nämlich einen UNIX-FTP-Client, dann habe ich das Problem nicht.
Das liegt daran, daß dieser mit wesentlich höheren Port-Nummern arbeitet
(so um die 37000), und so weit oben scheint es keine well-known Ports mehr
zu geben. Unsere Firewall kennt jedenfalls keine.
Windows selbst benutzt hingegen durchaus Ports in Bereichen bis zu 10000!
Das hätte sich diese Port-DLL mal besser vor Augen halten sollen - und
dann nicht so weit unten mit dem Ausliefern freier Ports anfangen sollen.
Würde sie "oben" anfangen (65536, richtig?), wäre das Problem ebenfalls
gelöst.

Ich habe mir vorhin erklären lassen, wie der Verbindungsaufbau-Handshake
ungefähr funktionieren soll (bitte um Korrekturen, falls erforderlich):

1. Der Client schickt ein SYN und schlägt eine Port-Nummer vor.
2. Der Server schickt ein SYN ACK und bestätigt diese Port-Nummer.
3. Der Client schickt ein ACK und fühlt sich ab hier befugt, diesen
   Port zum Kommunizieren nutzen zu dürfen.

In unserem Falle sagt die Firewall dem Client nicht mal explizit, wieso
sie den Port ablehnt (dafür scheint es auf dieser Ebene gar kein Sprach-
mittel zu geben):

1. Der Client schickt ein SYN und schlägt eine Port-Nummer vor.
2. Der Server schickt ein REJ und lehnt diese Port-Nummer ab.
3. Der Client muß darauf reagieren.

Beispielsweise, indem er sich nun eine neue Port-Nummer ausdenkt.

Wie macht er das? Er könnte beispielsweise wieder die schon erwähnte
Windows-API fragen. Diese weiß natürlich nichts von der Firewall, und
vor allem kommt sie nicht auf die Idee, daß dem FTP-Client die vorhin
gelieferte Port-Nummer nicht "gefallen" hat. Es besteht also die ernste
Gefahr, daß diese Windows-API wieder dieselbe Port-Nummer liefert.

Genau das passiert auch, wie wir in den Firewall-Traces sehen können:
Der FTP-Client überträgt ein paar hundert Dateien, stößt dann zufällig
an einen well-known Port, erhält ein REJ - und versucht dann aber stur
immer wieder denselben Port, bis er irgendwann aufgibt und abbricht.
Vermutlich macht er genau das, was ich auch tun würde, nämlich einen
nächsten freien Port anfordern ... aber die API liefert ihm offenbar
ständig dieselbe Port-Nummer, weil sie nicht kapiert, was los ist.
Alle Beteiligten halten sich an die Standards - aber sie arbeiten nicht
wirklich kooperativ an der Lösung des Problems. Alle "haben recht" ...

Wenn diese Windows-API immer den "nächsten" freien Port zurück liefert,
dann ist sie in meinen Augen der Haupt-Urheber des Problems - und der
Programmierer des FTP-Clients hat tatsächlich keine Chance, das Problem
zu lösen, wenn er kein "Vorschlagsrecht" für eine Port-Nummer hat.

Würde die Windows-API beispielsweise eine Port-Nummer _auswürfeln_, statt
immer wieder dieselbe zu liefern, dann würde sie das Problem automatisch
umgehen. Würfeln dauern natürlich etwas länger als mechanisch die nächste
freie Nummer aus einer Liste abzustreichen ... könnte der FTP-Client eine
Port-Nummer vorschlagen, dann wäre es seine Entscheidung, ob er würfelt
oder sequentiell einen Port-Range abscannt.

Jetzt müßten wir mal systematisch durchtesten, ob sich alle Windowse in
dieser Hinsicht gleich verhalten. Vielleicht wäre das Problem ja durch
irgend einen Patch einer System-Bibliothek lösbar ...
Wer macht eigentlich diese Prüfung der Ports in Windows? (socket.dll?)

Ratlos,
     Michael

[Gero Takke]

Hi,

Wie könnte dann der Server gleichzeitig mehr als einen Client bedienen?
"snoop" mal eine solche Maschine - Du wirst Dich wundern, was für Ports
HTTP verwendet ...

Ich nehme an, du meinst "sniffen" statt "snoopen" - zumindest kenne ich den
Begriff nur so.
Und: ja, ich habe schon oft HTTP gesnifft, und der Ziel-Port ist _IMMER_ 80
(sofern man ihn nicht anders angegeben hat).
Es ist moeglich Millionende von Clients ueber einen Port zu bedienen (Non-
Blocking Sockets), und das macht HTTP auch.

Den Rest deines Postings habe ich nur ueberflogen, und wuesste mangels Windows
auch nicht, was ich dazu sagen koennte ;-)

Tschuess,
Gero

[Michael Schröpl]

Hi Gero,

Ich nehme an, du meinst "sniffen" statt "snoopen" - zumindest kenne ich den
Begriff nur so.

Ich habe auch gerade erst erfahren, daß das Kommando "snoop" eine Solaris-
Eigenheit ist und daß auf Linux "tcpdump" in etwa vergleichbar wäre.

Viele Grüße
      Michael

[code2i]

moin

Und: ja, ich habe schon oft HTTP gesnifft, und der Ziel-Port ist _IMMER_ 80
(sofern man ihn nicht anders angegeben hat).
Es ist moeglich Millionende von Clients ueber einen Port zu bedienen (Non-
Blocking Sockets), und das macht HTTP auch.

Also ich denke das ist von der Implementierung abhängig. Mein Java Server arbeitet auch bei HTTP mit mehreren Ports. Das liegt daran das NON BLOCKING I/O erst in der neuen Version JDK 1.4 Merlin geht. Eine schöne Sache, welche der Performance zugute kommt.

cu

[code2i]

moin ....

Das scheint ja wieder richtig interessant zu werden.
Also erstmal ein bischen Grundlegendes, zum besseren Verständniss !
-----
Ich habe auf nem Rechner 65535 Ports. Davon sind Port 0-1023 für Anwendungen mit Superuser rechten reserviert. (Nach Standart)

Das FTP Protokoll ist eine Erweiterung des Telnet und arbeitet mit zwei Ports. Einem DataChannel und einem für den ControlChannel(Telnet).

Für den ControlChannel ist nach Standart Port 21 vorgegeben.
-----
Beim passiv mode versucht der Client eine Verbindung zum Server auf Port21 herzustellen. Nun bekommt er vom Server gesagt auf welchem Port der Client eine Datenverbindung(DataChannel) aufbauen darf.

aktive mode bedeutet das der Server den DataChannel zum Client aufbaut. (Wie bei Rolfs Link gut gezeigt)

Nur sind dort eben eine ganze Menge Ports "well known".
1024 ist zwar "legal", aber nicht "schlau".
Nehme ich nämlich einen UNIX-FTP-Client, dann habe ich das Problem nicht.
Das liegt daran, daß dieser mit wesentlich höheren Port-Nummern arbeitet
(so um die 37000), und so weit oben scheint es keine well-known Ports mehr
zu geben. Unsere Firewall kennt jedenfalls keine.
Windows selbst benutzt hingegen durchaus Ports in Bereichen bis zu 10000!
Das hätte sich diese Port-DLL mal besser vor Augen halten sollen - und
dann nicht so weit unten mit dem Ausliefern freier Ports anfangen sollen.
Würde sie "oben" anfangen (65536, richtig?), wäre das Problem ebenfalls
gelöst.

Ja ! aber da kann doch die arme dll nix dafür das eure Firewall da nen Port zerbrezelt. Kann ja sein das eine Applikation in eurem Hause in diesem Bereich schon Ports belegt und deshalb die Firewall da dicht macht.

ungefähr funktionieren soll (bitte um Korrekturen, falls erforderlich):

1. Der Client schickt ein SYN und schlägt eine Port-Nummer vor.
2. Der Server schickt ein SYN ACK und bestätigt diese Port-Nummer.
3. Der Client schickt ein ACK und fühlt sich ab hier befugt, diesen
      Port zum Kommunizieren nutzen zu dürfen.

Wo beim DataChannel oder ControlChannel. Beim ControlChannel kann ich mir das vorstellen aber beim DataChannel sagt der Server auf welchem Port. Indem der Client das Port Kommando schickt um zu erfahren auf welchem.

In unserem Falle sagt die Firewall dem Client nicht mal explizit, wieso
sie den Port ablehnt (dafür scheint es auf dieser Ebene gar kein Sprach-
mittel zu geben):

Du meinst die Transport Ebene oder ??? (TCP/IP)

1. Der Client schickt ein SYN und schlägt eine Port-Nummer vor.
2. Der Server schickt ein REJ und lehnt diese Port-Nummer ab.
3. Der Client muß darauf reagieren.

Beispielsweise, indem er sich nun eine neue Port-Nummer ausdenkt.

Das geschieht doch aber eine Ebene höher in der Anwendungsebene.(FTP,HTTP)

Wie macht er das? Er könnte beispielsweise wieder die schon erwähnte
Windows-API fragen. Diese weiß natürlich nichts von der Firewall, und
vor allem kommt sie nicht auf die Idee, daß dem FTP-Client die vorhin
gelieferte Port-Nummer nicht "gefallen" hat. Es besteht also die ernste
Gefahr, daß diese Windows-API wieder dieselbe Port-Nummer liefert.

Genau das passiert auch, wie wir in den Firewall-Traces sehen können:
Der FTP-Client überträgt ein paar hundert Dateien, stößt dann zufällig
an einen well-known Port, erhält ein REJ - und versucht dann aber stur
immer wieder denselben Port, bis er irgendwann aufgibt und abbricht.
Vermutlich macht er genau das, was ich auch tun würde, nämlich einen
nächsten freien Port anfordern ... aber die API liefert ihm offenbar
ständig dieselbe Port-Nummer, weil sie nicht kapiert, was los ist.

Hmmm ! Der Client donnert gegen eine verschlossene Tür. Der Server hat dem Client aber gesagt, das er genau da hereinkommen soll. (s.oben- Der Server sagt dem Client auf welchem Port er den DataChannel aufbauen soll..... im passiv mode).

Nur scheint der FTP Server nicht zu wissen das da einer die Tür abgeschlossen hat(Firewall) und erwartet das der Client da hereinkommt.

Der Fehler liegt eigentlich (nicht nur eigentlich sondern bestimmt) bei der Firewall.

Normalerweise muss eine Firewall den ControlChannel analysieren und teilweise Kommandos verändern. Wenn der Client zu Beispiel das Port Kommando sendet, um zu erfahren auf welchen Port er den DC aufbauen darf, muss die Firewall prüfen ob der Port darf.

Wenn nicht sollte die Wall darauf konfiguriert sein alles umzuleiten. Ähnlich wie NAT (Network Address Translation) nur halt auf Anwendungsebene.

Fazit: Die Firewall ist das Problem.

Lösungen!

Hmmm ! Socks 4 oder 5 je nach dem was eure Firewall unterstützt.  Firewall Admin ausschimpfen !!!

Da fällt mir noch was auf : "die Übertragung einiger weniger großer Dateien funktioniert dagegen reibungslos. MGet"

Was heißt den MGet??? Multi Get ---> mehrere DataChannels ??? Jups habe gerade mal nachgeschaut.

Vieleicht kann die Firewall mit mehreren DataChannels nicht!? Also mal mit get probieren und den Firewall Admin nerven.

Huiiii !!! mir qualmt die Rübe. (immer diese Systemanalytiker):-)

cu

[Michael Schröpl]

Hi,

Also erstmal ein bischen Grundlegendes, zum besseren Verständniss !

Vielen Dank - langsam habe ich das Gefühl, mich wenigstens in den
Grundlagen halbwegs zurecht zu finden ...

Ja ! aber da kann doch die arme dll nix dafür das eure Firewall da
nen Port zerbrezelt.

Laut http://www.clickx3.com/commands/wellknown.htm
gibt es oberhalb von 10000 noch genau sechs well-known ports -
dort liegen aber mindestens 85% aller freien Ports.
So würfelt Linux einfach geschickter, denke ich.

Kann ja sein das eine Applikation in eurem Hause in diesem Bereich
schon Ports belegt und deshalb die Firewall da dicht macht.

Ist aber nicht. (Ja, wir verwenden _auch_ eigene Ports irgendwo dort oben,
aber die kennen wir und können sie von den besagten Ports unterscheiden.
Wir wüßten, wenn wir selbst schuld wären.)

Das ist einfach eine Einstellung der Firewall, die einen Haufen Ports kennt
und bei denen die üblichen Standard-Protokolle (HTTP, FTP, Telnet etc.) als
Hack-Versuche abwehrt.

ungefähr funktionieren soll (bitte um Korrekturen, falls erforderlich):

1. Der Client schickt ein SYN und schlägt eine Port-Nummer vor.
2. Der Server schickt ein SYN ACK und bestätigt diese Port-Nummer.
3. Der Client schickt ein ACK und fühlt sich ab hier befugt, diesen
      Port zum Kommunizieren nutzen zu dürfen.
   Wo beim DataChannel oder ControlChannel.

Diese Ebene muß ja wohl auf dem ControlChannel laufen, weil sie den
DataChannel aushandeln will.

In unserem Falle sagt die Firewall dem Client nicht mal explizit, wieso
sie den Port ablehnt (dafür scheint es auf dieser Ebene gar kein Sprach-
mittel zu geben):
Du meinst die Transport Ebene oder ??? (TCP/IP)

Wahrscheinlich meine ich die - in diesen Protokoll-Ebenen bin ich nicht
 zuhause.

1. Der Client schickt ein SYN und schlägt eine Port-Nummer vor.
2. Der Server schickt ein REJ und lehnt diese Port-Nummer ab.
3. Der Client muß darauf reagieren.
   Beispielsweise, indem er sich nun eine neue Port-Nummer ausdenkt.
   Das geschieht doch aber eine Ebene höher in der Anwendungsebene.
   (FTP,HTTP)

Genau. Diese Ebene besteht aber leider aus zwei Teilen, die einander
nicht wirklich verstehen:

• dem Portnummern-Auswürfler aus der Windows-API und
• dem FTP-Client, der nehmen muß, was er kriegt - vor allem eben immer
    denselben Port.
  Das ganze Problem wäre gar keines, wenn die Windows-API begreifen würde,
  daß die Firewall einen Port ablehnen darf, und beim nächsten Mal einfach
  einen _anderen_ Port anbieten würde - die Chance einer Kollision ist ja
  gar nicht wirklich hoch, das Problem entsteht nur, weil die Client-Seite
  keine koordinierte Fehlerbehandlung zustande bekommt.
  (Deshalb finde ich die Formulierung, die Firewall sei schuld, ziemlich
  hart - die macht doch nur ihren Job.)

Der FTP-Client überträgt ein paar hundert Dateien, stößt dann zufällig
an einen well-known Port, erhält ein REJ - und versucht dann aber stur
immer wieder denselben Port, bis er irgendwann aufgibt und abbricht.
Vermutlich macht er genau das, was ich auch tun würde, nämlich einen
nächsten freien Port anfordern ... aber die API liefert ihm offenbar
ständig dieselbe Port-Nummer, weil sie nicht kapiert, was los ist.
Hmmm ! Der Client donnert gegen eine verschlossene Tür. Der Server hat
dem Client aber gesagt, das er genau da hereinkommen soll.
(s.oben- Der Server sagt dem Client auf welchem Port er den DataChannel
aufbauen soll..... im passiv mode).

Passive Mode haben wir noch gar nicht ausprobiert.
Da müßte ja jeder der diversen Kollegen die Konfiguration sämtlicher
gespeicherter FTP-Verbindungen auf jedem seiner Rechner ändern!
Weia, das möchte ich nur als allerletztes Mittel einsetzen.

Der Fehler liegt eigentlich (nicht nur eigentlich sondern bestimmt) bei
der Firewall.
Normalerweise muss eine Firewall den ControlChannel analysieren und
teilweise Kommandos verändern. Wenn der Client zu Beispiel das Port
Kommando sendet, um zu erfahren auf welchen Port er den DC aufbauen
darf, muss die Firewall prüfen ob der Port darf.

Hm. Also müßte die Firewall für Port 21 die Antwort des Servers verstehen
und umschreiben? Wie soll sie das aber machen? Sie kann ja nicht selbst
einen Port auswürfeln, der auf dem Server gar nicht frei ist, oder?

Wenn nicht sollte die Wall darauf konfiguriert sein alles umzuleiten.
Ähnlich wie NAT (Network Address Translation) nur halt auf Anwendungs-
ebene.

Ach so: Du meinst, sie soll nach beiden Richtungen über unterschiedliche
Ports FTP sprechen? Etwa wie ein Proxy, nur auf Port-Ebene statt auf URL-
bzw. IP-Ebene? Das klingt allerdings nach einer machbaren Lösung.
(Hoffentlich kann das ihre Software auch ...)

Lösungen!
Hmmm ! Socks 4 oder 5 je nach dem was eure Firewall unterstützt.
Firewall Admin ausschimpfen !!!

Würde ich nie tun!
Der hat auch seine Vorhaben, was er kaufen darf und was nicht.

Da fällt mir noch was auf : "die Übertragung einiger weniger großer
Dateien funktioniert dagegen reibungslos. MGet"

Ich wollte damit nur sagen: Das Problem ist kein Lastproblem - die FTP-
Verbindung läuft tadellos, wenn der Port erfolgreich ausgehandelt ist.

Was heißt den MGet??? Multi Get ---> mehrere DataChannels ???
Jups habe gerade mal nachgeschaut.
Vieleicht kann die Firewall mit mehreren DataChannels nicht!?

Der FTP-Client macht meines Wissens nichts über mehrere Kanäle parallel.
Zumindest zeigt seine graphische Oberfläche während der Übertragung den
genauen Zwischenstand an (welche Datei zu wieviel Bytes etc.).

Also mal mit get probieren und den Firewall Admin nerven.

Ich kann nichts "probieren" - der FTP-Client ist nicht von uns, der
ist einfach ein Standardprodukt (das ich aber nicht entbehren kann).
Und das macht eben MGET, wie ein normaler FTP-Client das auch tut.

Huiiii !!! mir qualmt die Rübe. (immer diese Systemanalytiker):-)

Vielen Dank erst mal - das hat mir bisher am deutlichsten weiter geholfen.

Viele Grüße
      Michael

[code2i]

Hi,

Also erstmal ein bischen Grundlegendes, zum besseren Verständniss !

Vielen Dank - langsam habe ich das Gefühl, mich wenigstens in den
Grundlagen halbwegs zurecht zu finden ...

:-) Hätte ich vieleicht besser als Frage formulieren sollen. Ich war mir nicht ganz sicher ob das so hundertpro stimmt.

Ist mir noch aufgefallen das ich falschherum gedacht habe. Der Client ist ja drin und der Server außerhalb.(da hab ich wohl gepennt)

Das ist einfach eine Einstellung der Firewall, die einen Haufen Ports kennt
und bei denen die üblichen Standard-Protokolle (HTTP, FTP, Telnet etc.) als
Hack-Versuche abwehrt.

Genau ! Jetzt verstehe ich das schon eher. Bei aktiv kommt ja die Verbindung von außen. Die Firewall hat aber über den gleichen Port gar keine Anforderung von innen bekommen.

Dazu muss die Firewall den ControlChannel(Port21) analysieren, um herauszufinden welcher Port freigegeben werden muss.

Das geht zwar, ist aber problematisch. Dazu müssen bei diversen Firewalls bestimmte Einstellungen vorgenommen werden. Hier kann ein Sicherheitsloch entstehen. Zusätzlich kann dabei die Performance der Wall tierisch in die Knie gehen.(Wegen Paketfilter,Protokollfilter etc.)

Würde eure Firewall alle Verbindungen außerhalb der für FTP zuläßigen ablehen, wäre das einfacher zu verstehen. Dann würde ich sagen ... es geht nur passiv oder nen FTP-Proxy muss her oder bla...

Mich wundert allerdings das teilweise Pakete von außen ohne Anforderung zu euch ins Netz kommen. Eigentlich soll doch genau das die Wall unterbinden.(grob ausgedrückt).

Ich gehe mal davon aus, daß die Firewall den ControlChannel doch analysiert, ansonsten sollte sie keine Verbindungen von außen ohne weiteres zulassen.

Nun gibt es da aber die Außnahme einiger bestimmter Ports, welche ein direktes Verbot haben auf Verbindungen dieser Art einzugehen.
(Das sollte allerdings aus der Wall config zu ersehen sein).

Selbst wenn das passiert sollte die Wall über einen Filter verfügen um Port-Forwarding zu betreiben. (Ich glaub so hieß das).

Dabei erkennt die Wall im ControlChannel das Port Kommando. Ist dieser Port für die Wall OK bleibt das Kommando wie es ist. Wenn nicht ändert die Wall den Port in einen neuen. Die Antwort des Servers kommt auf dem neuen Port und muss nun auf den alten Port für den Client umgeleitet werden.

Generell gibt es bei aktiv mode und Firewalls immer Probleme. Das ist unter anderem bei LINUX Firewalls nachzulesen.

Ich denke, da für gerade diese Thematik oft eine Mischung aus ProxyServern und Firwalls genutzt wird, wäre das vieleicht auch hier eine Lösung.  Ist aber genauso aufwendig wie alle Clients auf passiv umzustellen, außer ihr verfügt schon über einen Transparenten Proxy, der nur noch auf FTP konfiguriert werden muss. Wie gesagt, moderne Walls sollten das auch können.

Bei passiv mode kann ich mir vorstellen, das die Wall weniger Probleme hat eine Verbindung freizugeben, da der DataChannel vom Client aufgebaut wird und hierbei die Wall das als Anfrage aus dem internen Netz ansieht.

Hmmm soweit erstmal !

Das Thema ist auch für mich von Interesse. Hat mir geholfen einige Themen besser auszuleuchten.

Bis bald .. Grüße !
code2i

[Simon Reinhardt]

Hi Micheal!

Nur sind dort eben eine ganze Menge Ports "well known".
1024 ist zwar "legal", aber nicht "schlau".
Nehme ich nämlich einen UNIX-FTP-Client, dann habe ich das Problem nicht.
Das liegt daran, daß dieser mit wesentlich höheren Port-Nummern arbeitet
(so um die 37000), und so weit oben scheint es keine well-known Ports mehr
zu geben. Unsere Firewall kennt jedenfalls keine.

Soweit ich weiß, gehen die "wellknowns" nur bis 1024.
Die Ports darüber sind bis zu einer bestimmten Zahl "halb-reserviert". Unter Linux gibt es eine Datei ("services", glaube ich), in der das genauer steht. Auf die Schnelle hab ich das nur auf folgender Seite gefunden: http://www.clickx3.com/commands/wellknown.htm.
Da ist aber leider das wichtigste abgekürzt.

VG Simon

[Rolf]

Hallo Michael,

neu schöne Seite zu FTP gibts hier
 http://olli.informatik.uni-oldenburg.de/janssen_neumann/Lernprogramm/ftp1.htm

Mit Animation ;-)

Viele Grüße, rolf

[Ludwig Ruderstaller]

Hallo,

Mal kurz notiert was ich über FTP weiß, und aus böser erfahrung gelernt habe:

Wie bereits angesprochen gibt es AKTIVE und PASV modes.

PASV mode ist der quasi standard, bzw der default. Dabei sendet der client auf den port 21 einen Request an den server. Der Server antwortet auf diesen port mit der user/passwort request. gibt den client nach erfolg allerdings eine neuen port bekannt (>1024) auf den er bei einem neuerlichen request antwortet (meistens bei graphischen clients der LIST befehl).

Das kann nun dazu führen das wenn ein proxy oder firewall dazwischen hängt, die User/pass überprüfung noch funktioniert, auch der LIST befehl abgesetzt werden kann, aber die antwort des FTPs von der Firewall abgeblockt wird. (da ja nicht der client den port geöffnet hat, sondern der server).

AKTIVE mode arbeitet hingegen IMMER auf port 21. Drum gehts meist durch die Firewall durch.

Es gibt natürlich noch eine dritte methode: man kann per ftp client über den proxy/firewall connecten. zb. mittels SOCK4/5 dabei kann ein usernamen sowie ein passwort (für die firewall/proxy wohlgemerkt) mit übergeben werden. Bei dieser methode ist es meist möglich sowohl passv als auch aktie mode zu verwenden. Kommt natürlich immer auf die einstellungen der firewall an.

bei weiteren fragen stehe ich gerne per PM zur Verfügung.

lg
Ludwig