Re: Sicherer Datentransfer (was: Kernel config)

[Andreas Pakulat]

On 07.Apr 2004 - 22:21:53, Hans-Georg Bork wrote:
> Moin,
> 
> On Wed, 2004-04-07 at 09:05, Andreas Pakulat wrote:
> > [...]
> > > > Spezielle Loginshells - ne Moeglichkeit wenn ich sehe das ftp/tls
> > > > wirklich ein Scheunentor ist.
> > Hmm, hast mich irgendwie nicht ueberzeugt, ist mir alles zuviel
> > Aufwand fuer so ein paar laecherliche Daten. Anonymen FTP will ich
> > dennoch nicht, denn dann kann ja nun wirklich jeder raus. So muss man
> > erstmal das Passwort mitlesen...
> 
> unter http://www.weidner.ch/download.html findest Du chrlogin um diese
> "User" in ein chroot-jail umzuleiten indem sie dann Deine Bilder finden
> und ihre Texte ablegen koennen; sshd braucht dafuer nicht umgebaut
> werden. 

Muss dann aber immernoch extra User anlegen und fuer diese ein Home...

Andreas

-- 
They have been at a great feast of languages, and stolen the scraps.
-- William Shakespeare, "Love's Labour's Lost"


-- 
Haeufig gestellte Fragen und Antworten (FAQ): 
http://www.de.debian.org/debian-user-german-FAQ/

Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED]
mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)

Re: Sicherer Datentransfer (was: Kernel config)

[Hans-Georg Bork]

Moin,

On Wed, 2004-04-07 at 09:05, Andreas Pakulat wrote:
> [...]
> > > 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.
> 
> Hmm, hast mich irgendwie nicht ueberzeugt, ist mir alles zuviel
> Aufwand fuer so ein paar laecherliche Daten. Anonymen FTP will ich
> dennoch nicht, denn dann kann ja nun wirklich jeder raus. So muss man
> erstmal das Passwort mitlesen...

unter http://www.weidner.ch/download.html findest Du chrlogin um diese
"User" in ein chroot-jail umzuleiten indem sie dann Deine Bilder finden
und ihre Texte ablegen koennen; sshd braucht dafuer nicht umgebaut
werden. 

Gruss
-- hgb

Re: Sicherer Datentransfer (was: Kernel config)

[Andreas Pakulat]

On 07.Apr 2004 - 11:02:40, Timo Eckert wrote:
> On Wed, 7 Apr 2004 00:05:09 -0700
> Andreas Pakulat <[EMAIL PROTECTED]> wrote:
> 
> > > 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.
> 
> Hallo,
> 
> schau doch mal bei http://lufs.sourceforge.net/lufs/ vorbei.
> Da gibts ein paar nette sachen. zB ein sshfs mounten etc.
> 
> Vielleicht gefällt Dir das ja besser. ;)

Noe, laeuft soweit ich das sehe nur unter Linux, die andere Seite hat
aber Windows...

Andreas

-- 
If you want to read about love and marriage you've got to buy two separate
books.
-- Alan King


-- 
Haeufig gestellte Fragen und Antworten (FAQ): 
http://www.de.debian.org/debian-user-german-FAQ/

Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED]
mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)

Re: Sicherer Datentransfer (was: Kernel config)

[Timo Eckert]

On Wed, 7 Apr 2004 00:05:09 -0700
Andreas Pakulat <[EMAIL PROTECTED]> wrote:

> > 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.

Hallo,

schau doch mal bei http://lufs.sourceforge.net/lufs/ vorbei.
Da gibts ein paar nette sachen. zB ein sshfs mounten etc.

Vielleicht gefällt Dir das ja besser. ;)

Sonnige Grüsse,
Timo.

Re: Sicherer Datentransfer (was: Kernel config)

[Andreas Pakulat]

On 06.Apr 2004 - 20:16:49, Elmar W. Tischhauser wrote:
> Hallo!
> 
> On 06 Apr 2004 at 08:59 -0700, Andreas Pakulat wrote:
> 
> > On 06.Apr 2004 - 12:25:13, Elmar W. Tischhauser wrote:
> > 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...

Na ich glaube du ueberschaetzt mein Anforderungsprofil. Es handelt
sich um 2 Privatpc's die auch nur privaten Kram austauschen, da sind
im hoechsten Falle mal hochsicherheitsbeduerftige Dinge wie der Preis
meiner letzten CD drin oder sowas in der Richtung. Selbst wenn jemand
auf dem Server (der auf meinem Laptop laeuft) einbricht und sich alle
meine huebschen Bilder und was weiss ich was noch auf meiner Platte
rumliegt holt ist mir das ziemlich egal... 

[ftp+ssl und Firewalls]

Danke das hat mir ein wenig die Augen geoeffnet.

> 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.

Hmm, ja macht Sinn. Dann kann ich das SSL genausogut weglassen...

> 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 .-)

Ist immernoch zuviel Aufwand. Ich sollte naechstes Mal dazuschreiben
dass es wirklich nur um ein paar Bilder (von denen der groesste Teil
dann auch noch auf meinem oeffentlichen Webspace liegt) und ein paar
Murphysche Gesetze geht...

> > 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.

Hmm, hast mich irgendwie nicht ueberzeugt, ist mir alles zuviel
Aufwand fuer so ein paar laecherliche Daten. Anonymen FTP will ich
dennoch nicht, denn dann kann ja nun wirklich jeder raus. So muss man
erstmal das Passwort mitlesen...

Andreas

-- 
There is an old time toast which is golden for its beauty.
"When you ascend the hill of prosperity may you not meet a friend."
-- Mark Twain


-- 
Haeufig gestellte Fragen und Antworten (FAQ): 
http://www.de.debian.org/debian-user-german-FAQ/

Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED]
mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)

Sicherer Datentransfer (was: Kernel config)

[Elmar W. Tischhauser]

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

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


pgp0.pgp
Description: PGP signature