[linux-l] ftp lahmt

[Peter Ross]

Hi Boris,

On Sat, 24 Nov 2007, Boris Kirkorowicz wrote:

> <http://www.kirk.de/files/snafoo-2007-11-24_1911-filtered.pcap> hochgeladen.
> 
> >> Kann das vielleicht etwas mit dem passive mode zu tun haben?
> > Mich wundert, daß direkt passive mode benutzt wird; schließlich hast
> > Du den nicht angefordert.

Das koennte der Defaultclient sein.

Wie auch immer.. die Kommandos, die bei Dir haengen, sind die, bei denen 
Daten uebertragen werden.

Zum Verstaendnis: Fuer Datenuebertragung wird bei FTP neben der immer 
offenen Kontrollverbindung eine zweite aufgemacht (Port 20, "ftp-Data")

Bei aktiv ist es der Client, der sagt ueber die Kontrollverbindung via 
PORT-Kommando: "Ich habe einen TCP-Port xxx offen fuer Dich". Der Server 
verbindet sich mit diesem und die Datewn werden uebertragen.

Bei passiv hingegen sagt der Server ueber das Port-Kommando: "Ich habe 
einen Port fuer Dich" (der Portbereich ist implementationsabhaengig und 
kann bei vielen FTP-Servern konfiguriert werden )und der Client verbindet 
sich mit diesem.

Das ist fuer ein Firewall doof, weil zustandsbehaftetes Filtern schwierig 
ist (der Firewall muss in den Kontrollkanal hineinhorchen, um zu wissen, 
dass die temporaere Verbindung zur FTP-Verbindung dazugehoert und so die 
Pakete hindurchlaesst). Deshalb hat Linux/netfilter conntrack-Helferlein, 
die das tun.

Anyway, jedes Kommando wie DIR oder GET oder PUT nutzt den Datenkanal 
Kanal und das lahmt bei Dir.

Ich habe versucht, aus Deinem Dump war rauszulesen, aber ohne 
Verstaendnis, wann gemacht hast und wo das Warten war, verstehe ich das 
nicht.
 
Spiele mal bei Deinem Client mit Ein-Ausschalten des passive modes  
(PASV-Kommando).

Ich sehe das folgende Problem nicht, aber weil es bei FTP haeufiger 
vorkommt, erwaehne ich es mal:

Gelegentlich war der ident-Service das Problem (auth, Port 113). Manche 
Server wollen auf diesem port eine Antwort haben. Das tut identd.

Aber oft reicht es, wenn der Client bei Verbindungsaufbau via ICMP ein 
Reject meldet ("ich habe keinen identd") und der Server ists zufrieden.

Dooferweise sind viele Firewalls so konfiguriert, dass sie auf Ports, auf 
denen nicht geantwortet wird, kein Reject zurueckmelden, sondern das Paket 
einfach schlucken (Hintergedanke: Wenn ein Portscanner auf jeden nicht 
benutzten Port aufs Timeout warten musst, macht es das Scannen langsamer.. 
Was uebrigens stimmt, aber nicht unbedingt was nuetzt. Es macht einem 
automatischen Skript nichts auf, eine Weile zu warten, Warten kostet nix, 
erst recht nicht, wenn man tausend Rechner gleichzeitig testen kann.. 
aber es sieht so aus, als wenn es zumindest fuer viele Skript-Kiddies 
ausreichende Hemmschwelle ist)

Wie auch immer, es hilft dann, wenigstens fuer Port 113 in der Firewall 
ein Reject statt Drop zu konfigurieren.

Gruss
Peter