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
Attachment:
pgpNINTkpIhFk.pgp
Description: PGP signature