Lokaler PureFTP hängt beim LIST-Kommando

P

PatTheMav

Well-Known Member
Nabend - ich habe hier mein FreeBSD-Server als Firewall (IPFW) am laufen und nem Pure-FTP-Server. Bisher lief damit alles problemlos, bis ich mein IPFW-Script komplett mit Stateful Regeln und Traffic Shaping für den Upload neu geschrieben hab. Seitdem können Leute zwar von aussen sowohl active als auch passive connecten, aber nach dem PORT bzw. PASV-Kommando kommt das LIST und da hängts. Nach nem Timeout meldet der Server dann, dass er nicht auf nen bestimmten Port (am Client wohl) connecten kann und ich find nich raus woran es liegt.

Hier mal mein Ruleset :
Code: 
# Enable reinjecting
${fwcmd} disable one_pass

# Upload-pipe for 22 kbyte/s
${fwcmd} pipe 1 config bw 192Kbit/s

# High-Priority queue for ACK-Packets
${fwcmd} queue 1 config pipe 1 weight 100 gred 0.05/35/45/0.4

# Medium-Priority queue for DNS/Gaming/SSH
${fwcmd} queue 2 config pipe 1 weight 80 gred 0.05/35/45/0.4

# Low-Priority for the dirty rest ;)
${fwcmd} queue 3 config pipe 1 weight 40 gred 0.05/35/45/0.4

${fwcmd} add queue 1 tcp from any to any out via ${natd_interface} tcpflags ack iplen 0-80
${fwcmd} add queue 2 udp from any to any out via ${natd_interface}
${fwcmd} add queue 3 all from any to any out via ${natd_interface}

# Localhost-Traffic erlauben
${fwcmd} add allow ip from any to any via lo0

# Internen Traffic erlauben
${fwcmd} add allow all from any to any via ${lan_interface}

# Anti-Spoofing Regeln und Blockieren vom Pseudo-Port NULL und Port 1
${fwcmd} add unreach host-unknown log ip from 10.0.0.0/8 to any in via ${natd_interface}
${fwcmd} add unreach host-unknown log ip from 172.16.0.0/12 to any in via ${natd_interface}
${fwcmd} add unreach host-unknown log ip from 192.68.0.0/16 to any in via ${natd_interface}
${fwcmd} add unreach host-unknown all from any to any ${closed_ports} in via ${natd_interface}

# Fragmentierte Pakete verwerfen
${fwcmd} add deny all from any to any via ${natd_interface} frag

# ICMP Types 3 und 8 mitprotokollieren und benoetigte ICMP Types erlauben
${fwcmd} add allow log icmp from any to any in via ${natd_interface} icmptype 3
${fwcmd} add allow log icmp from any to any in via ${natd_interface} icmptype 8
${fwcmd} add allow icmp from any to any in via ${natd_interface} icmptype 4
${fwcmd} add allow icmp from any to any in via ${natd_interface} icmptype 11
${fwcmd} add allow icmp from any to any in via ${natd_interface} icmptype 30

# Dynamische Regeln fuer ausgehende Verbindungen anlegen
${fwcmd} add check-state
${fwcmd} add allow tcp from any to any out via ${natd_interface} setup keep-state
${fwcmd} add allow all from any to any out via ${natd_interface} keep-state

# Bereits aufgebaute verbindungen beibehalten
${fwcmd} add allow all from any to any via ${natd_interface} established

# Aktive FTP-Verbindungen erlauben
${fwcmd} add allow all from any 20,21 to any in via ${natd_interface} setup keep-state

# Erlaubte TCP-Dienste die ausm Internet erreicht werden dürfen
${fwcmd} add allow tcp from any to any ${open_tcp_ports} in via ${natd_interface} setup keep-state

# Erlaubte UDP-Dienste die ausm Internet erreicht werden dürfen
${fwcmd} add allow udp from any to any ${open_udp_ports} in via ${natd_interface} keep-state

# Dem Rest STEALTH-Verhalten vortaeuschen
${fwcmd} add unreach host-unknown all from any to any in via ${natd_interface}
Das ganze funktioniert wunderbar, eigene Dienste die ins Netz dürfen von den Windows-Rechnern (Gamevoice und co, ICQ) und auch Spiele funktionieren alle, Portscans von Sygate und Co erkennen alle (bis auf die freigegebenen) Ports als Stealth, bin mir aber bewusst, dass das keine TrueStealth Firewall ist, soll sie auch nicht sein.

Auf jedenfall dachte ich, dass ich mit der ersten Regel nach dem check-state sowohl Verbindungen, die die Client-Rechner im LAN aufbauen, als auch solche, die der Server selbst, bzw. Dienste auf diesem wie Pure-FTP aufbauen, erlaubt sind.
 
bei passiv ftp öffnet er ja eine "data connection"(dazu gehört auch list) auf irgendeinem port zb 51432. also du mußt alle ports über ca. 30000 (ich weiß jetzt den genauen port nicht) öffnen.
 
s-tlk schrieb:
bei passiv ftp öffnet er ja eine "data connection"(dazu gehört auch list) auf irgendeinem port zb 51432. also du mußt alle ports über ca. 30000 (ich weiß jetzt den genauen port nicht) öffnen.
Zum Vergrößern anklicken....
Hatte ich mit meinen alten Regeln auch nicht gemacht und da funktionierte noch alles. Ausserdem wird genau dieses Verhalten, also das öffnen der Data Connection nich über die "allow ip from any to any out keep-state"-Regel erfüllt ?
 
eigentlich ja. aber
PatTheMav schrieb:
# Erlaubte TCP-Dienste die ausm Internet erreicht werden dürfen
${fwcmd} add allow tcp from any to any ${open_tcp_ports} in via ${natd_interface} setup keep-state
Zum Vergrößern anklicken....
hier öffnest du doch nur bestimmte ports ${open_tcp_ports}. oder liege ich da falsch?
nebenbeigesagt ich kenne mich mit ipfw nicht so richitg aus. bin pf'ler.
 
s-tlk schrieb:
eigentlich ja. aber

hier öffnest du doch nur bestimmte ports ${open_tcp_ports}. oder liege ich da falsch?
nebenbeigesagt ich kenne mich mit ipfw nicht so richitg aus. bin pf'ler.
Zum Vergrößern anklicken....
Jup, da öffne ich bestimmte Ports auf der Verbindungen von aussen aufgebaut werden dürfen, aber das ist nur die Richtung IN.

Für ausgehende Verbindungen sind diese Regeln verantwortlich :

${fwcmd} add check-state
${fwcmd} add allow tcp from any to any out via ${natd_interface} setup keep-state
${fwcmd} add allow all from any to any out via ${natd_interface} keep-state

Und damit sollte eigentlich auch der FTP rauskommen können.
 
PatTheMav schrieb:
Jup, da öffne ich bestimmte Ports auf der Verbindungen von aussen aufgebaut werden dürfen, aber das ist nur die Richtung IN.
Zum Vergrößern anklicken....
ja genau hier müssen alle ports <30000 geöffnet sein. das ist es doch. versuch das mal.

an meiner openbsd kiste muß für pasv. ftp das auch so sein, natürlich dann mit pf.
 
Schnall ich den Sinn ehrlich gesagt nicht. Eingehend horcht der FTP nur auf einem Port und auf dem können sich Clients ja connecten, da wo es hakt handelt es sich um eine ausgehende Verbindung vom Server zum Client, die fehlschlägt. Mir erschliesst sich nicht, wie da das komplette Öffnen einer endlosen Portrange (und damit das ad absurdum-führen der Firewall) für eingehende (und nicht ausgehende, da wo das Problem liegt) Verbindungen helfen soll.

Vielleicht erklärt mir einer wie denn die Verbindungen aufgebaut werden, wenn von aussen einer connected.

So wie ich das verstehe gibt es einen Connect von Aussen auf einen bestimmten Port, da antwortet der Server, lässt den Client einloggen (anonymous gibts bei mir nicht) und bekommt danach vom Client per PORT bzw. per PASV mitgeteilt, auf welchen Port der Server zusätzlich zu der existierenden Control-Verbindung die Data-Verbindung zum Client aufbauen soll. Danach folgt das LIST-Kommando zum anzeigen der Directory-Contents, dabei meldet der Server dann, dass er keine Verbindung zum Port, der vorher mitgeteilt wurde, nach aussen aufbauen kann.
 
vielleicht hilft das:
In passive mode FTP the client initiates both connections to the server,
solving the problem of firewalls filtering the incoming data port
connection to the client from the server. When opening an FTP connection,
the client opens two random unprivileged ports locally (N &gt; 1024 and N+1).
The first port contacts the server on port 21, but instead of then issuing
a PORT command and allowing the server to connect back to its data port,
the client will issue the PASV command. The result of this is that the
server then opens a random unprivileged port (P &gt; 1024) and sends the PORT
P command back to the client. The client then initiates the connection from
port N+1 to port P on the server to transfer data.
Zum Vergrößern anklicken....

this is interesting, too. *g*
http://www.dzug.org/mailinglisten/zope/archive/2004/2004-07/1090085279058 ist suse, ist ecklig, ich weiß, also verschont mich direkt

alle ports über 1024 sind nicht privilegiert, also können (dürfen, sollten) sie nichts böses (systembeinflussendes) machen.

[alles was mir gerade über die tasten gelaufen ist wie immer ohne gewähr]
 
Zuletzt bearbeitet:
Hab ich alles schon gelesen, hab auch die Erklärungen auf dieser Seite komplett durchgelesen. Aber es sind alle Voraussetzungen erfüllt. Clients können auf dem Command-Port connecten und haben auch eine kleine Portrange für PASV-Connections zur Verfügung, die im IPFW-Script reindürfen. Alles was ausgehend ist, wird ja zugelassen, aber die ausgehenden Verbindungen vom FTP gehen nicht durch, obwohl sie durchgehen müssten (ist doch kein Unterschied, ob z.B. UT2004 bei mir auf irgendwelchen Ports nach draussen connected, oder der FTP auf irgendeinen Port nach draussen geht). Und genau das geht mir nich durch 'n Kopp, warum ausgerechnet der Server als einziges in der Config nich rauskommt.
 
Weiss also niemand, warum meine Firewall gemäss der "allow all from any to any out keep-state"-Regel die ausgehende Verbindung des FTPs zum Client nicht zulässt ? :(
 
oder vielleicht hilft ein öffnen der Firewall und dann ein tcpdump auf den host der connectet? da siehst du genau, wer was wann machen will!
 
Hallo PatTheMav,

was ist denn bei Deinem Problem herausgekommen?
Ich sitze hier genau von den gleichen Schwierigkeiten.

Viele Grüße

Jürgen
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben