Hallo! On 06 Apr 2004 at 08:59 -0700, Andreas Pakulat wrote:
> On 06.Apr 2004 - 12:25:13, Elmar W. Tischhauser wrote:
> >
> > Vorschl�ge: HTTPS mit Clientzertifikaten, WebDAV over SSL, sftp/scp,
>
> webdav, https??? ok, das erstere ermoeglicht den Upload das 2. den
> Download.
Soviel ich wei�, unterst�tz WebDAV beides und noch einiges mehr
(Versionierung, erweiterte Attribute usw.). Auch beim �berfliegen von
RFC 2518 sind mir keine Beschr�nkungen aufgefallen, die im von dir
geschilderten Anforderungsprofil eine Rolle spielen w�rden.
> Aber den Kram extra aufsetzen um ein paar private Files zu
> verschieben? Overkill wuerde ich sagen.
Kommt darauf an. Das Neuaufsetzen und die Forensik nach einer
Kompromittierung sind auch nicht gerade schnell erledigt...
> > [...] durch die Trennung von Daten- und Kontrollkanal ist FTP (aus
> > Firewallsicht) an sich schon schwierig zu handhaben, der Einsatz von
> > TLS macht das nat�rlich nicht besser.
>
> Hmm, wieso?
Die Verschl�sselung des Kontrollkanals macht gutes FTP-Firewalling quasi
unm�glich. Lassen wir aktives FTP mal beiseite und gehen von einem
Clientrechner "c" und einem FTP-Server "s" aus. Dann sieht ein
Verbindungsaufbau von c nach s bei passivem FTP so aus:
1. c:4000 -> s:21 (Client initiiert Verbindung zum Kontrollkanal und
sendet PASV)
2. s:21 -> c:4000 (Server lauscht an neuem Port 9000, teilt diesen dem
Client in seiner PASV-Antwort mit)
3. c:4001 -> s:9000 (Client �ffnet Datenkanal zu neuem Port)
4. s:9000 -> c:4001 (z.B. Datentransfer)
Dass ein zwischen c und s agierender simpler Paketfilter keine Chance
hat, hier sinnvoll selektiv Verbindungen zu erlauben, ist
offensichtlich.
'Stateful' Firewalls (wie z.B. iptables) k�nnen nun dieses Manko
beheben, indem sie die auf dem Kontrollkanal (21) ausgetauschten
FTP-Kommandos untersuchen und abh�ngig von der auf das PASV erfolgenden
Serverantwort (die ja die neue Portnummer enth�lt) tempor�r und gezielt
L�cher �ffnen und diese nach beendeter TCP-Verbindung wieder schlie�en.
(Bei iptables macht dies das Modul conntrack_ftp.)
Wird nun mit FTP-TLS Ende-zu-Ende-Verschl�sselung verwendet, kann die
Firewall nicht mitlesen, welche Ports vor�bergehend zu �ffnen sind.
Folglich degradiert FTP over TLS zustandsbasierte Firewalls wie iptables
zu einfachen Paketfiltern, welche zudem f�r funktionierendes FTP gro�e
L�cher in ihrer Konfiguration rei�en m�ssen.
Auch Application Layer Gateways, deren Einsatz bei FTP notwendiger ist
als bei den meisten anderen Protokollen, werden durch die
Verschl�sselung effektiv an ihrer Arbeit gehindert. Die einzige L�sung
(neben eines Protokollredisigns) w�re, einen ent- und verschl�sselnden
Proxy zu verwenden, was aber aus Sicht des Nutzers zu Recht einem
Man-in-the-Middle-Angriff gleichkommt.
Die Details dazu sind sehr gut in den RFCs 959, 1579 und 2228 sowie vor
allem in
<http://www.ietf.org/internet-drafts/draft-fordh-ftp-ssl-firewall-04.txt>
beschrieben.
Wie man es auch dreht und wendet: Aus Sicherheitssicht ist FTP 'broken
by design', und selbst lobenswerte Ans�tze wie das Einschieben von
SSL/TLS auf der Sitzungsschicht k�nnen daran nichts �ndern. Daher kam
meine Empfehlung, FTP stets nur f�r anonymen Datentransfer einzusetzen.
[ssh]
> chroot-Patch == Selberbauen des sshd == zu viel Arbeit.
?
Sollte eigentlich in ein paar Minuten erledigt sein, der Patch ist AFAIK
sogar im contrib/-Verzeichnis mit drin. Gut, wenn wie im Sommer 2002
jeden Tag ein neues ssh-Advisory eintrudelt, ist es langsamer als das
Einspielen fertiger Pakete .-)
> Spezielle Loginshells - ne Moeglichkeit wenn ich sehe das ftp/tls
> wirklich ein Scheunentor ist.
Zusammenfassen w�rde ich entweder das oder SSL/TLS-gesichertes WebDAV
empfehlen.
Gru� und gutes Gelingen,
Elmar
--
[ GnuPG: D8A88C0D / 2407 063C 1C92 90E9 4766 B170 5E95 0D7F D8A8 8C0D ]
�����������������������������������������������������������������������
Die eigene Erfahrung hat den Vorteil v�lliger Gewi�heit.
-- Schopenhauer
pgp00000.pgp
Description: PGP signature
