Hallo! On 19 Sep 2004 at 22:27 +0200, Gerald Holl wrote: > Ich verwende ein iptables [1]Firewall-Skript, welches ich zuerst in > Verdacht hatte. Es werden nämlich ein paar Pakets gedropped: > Sep 19 21:55:48 jimbo kernel: fp=TCP:1 a=DROP IN=eth0 OUT= MAC= > SRC=xxx.xx.xxx.xxx DST=yyy.yyy.yyy.yyy LEN=48 TOS=0x00 PREC=0x00 TTL=116 > ID=207 DF PROTO=TCP SPT=1046 DPT=37584 WINDOW=64240 RES=0x00 SYN URGP=0 [...] > Wenn ich im vsftpd SSL disable, funktioniert die Verbindung jedoch > problemlos ... > Ich dachte zuerst an ein connection tracking Problem, doch conntrack ist > im Kernel (2.6.7) fix einkompiliert. Das dürfte ganz einfach daran liegen, dass alles Firewalling und Connection Tracking bei FTP-over-SSL schlicht hilflos ist. FTP ist aus Protokollsicht wegen der getrennten Kontroll- und Datenkanäle (und der damit verbundenen Portaushandlung) eben 'broken by design'. Normalerweise kann ein zustandsbasierter Paketfilter die über den Kontrollkanal ausgetauschten Ports mitlesen und selektiv öffnen bzw. nach Verbindungsabbau wieder schließen (das ist das sog. Connection Tracking). Wird nun wie bei FTP-over-SSL der Kontrollkanal verschlüsselt, funktioniert das prinzipbedingt nicht mehr - der Paketfilter müsste die Daten entschlüsseln, um noch mitzukommen. Auch im Zusammenspiel mit Transfers hinter einem NAT-Gateway kann es bei FTP-over-SSL zu Problemen kommen (alles außer Passive FTP von Client hinter NAT zu fester IP oder aktivem FTP bei Server hinter NAT ist problematisch). Da das großflächige präventive Öffnen von hohen Portnummern inakzeptabel ist, wäre die einzige "Lösung", die Firewall auch zum Endpunkt der öffentlichen SSL-Verbindung zu machen (Proxying) und eine weitere "private" zwischen Proxy und FTP-Server einzurichten. Dabei ist aber zu bedenken, dass wohl, was die Überprüfung der Authentizität des FTP-over-SSL-Servers anbelangt, Kompromisse geschlossen werden müssen, da aus Clientsicht ein SSL-Zertifikat für einen anderen Rechner (den Proxy) gesehen wird, und nicht dasjenige des eigentlichen FTP-Servers. Im Großen und Ganzen gehört FTP (auch mit SSL) verdient auf den Müllhaufen der Geschichte. Mit HTTPS, SFTP (aus dem SSH-Paket) oder SSL-gesichertem WebDAV gibt es ausreichend funktionierende Alternativen, die aus Sicherheitssicht weit weniger Kopfschmerzen verursachen. Lesetipp: <http://www.ietf.org/internet-drafts/draft-fordh-ftp-ssl-firewall-05.txt> Gruß, Elmar -- [ GnuPG: D8A88C0D / 2407 063C 1C92 90E9 4766 B170 5E95 0D7F D8A8 8C0D ] ······································································· What is wanted is not the will to believe, but the will to find out - which is the exact opposite. -- Bertrand Russell
Attachment:
pgpwz_PPiT36e.pgp
Description: PGP signature