[linux-l] Netzwerk-Dateisysteme

Steffen Schulz pepe_ml at gmx.net
Mo Jan 31 01:19:26 CET 2011


Hi Lutz,


da hab ich ja was losgetreten, vielen Dank fuer die Ausfuehriche
Beratung :-))

Das setup ist gar nicht so gross. Wir haben im Kern nur zwei
ungewoehnliche Anforderungen die wir halt fuer 20-30 Nutzer umsetzen
wollen. Ob die nachher auch alle den Dienst benutzen wage ich zu
bezweifeln, der Chef wird es aber auf jeden Fall tun. Ueber
Skalierbarkeit machen wir uns jedenfalls wenig sorgen, aber eine
vernuenftige Loesung muss natuerlich immer auch halbwegs Durchsatz
bringen und wartbar sein.

On 110130 at 18:45, Lutz Willek wrote:
> Kurze Fragen vorweg, wieso sind die Anforderungen so hoch?

Ich finde sie gar nicht hoch. Ungewoehnlich aber absolut verstaendlich
ist, dass die Clients selbst verschluesseln koennen(Datenhoheit) und
nicht zu irgendwelcher VPN-Software gezwungen werden sollen. Letzteres
ist mehr eine Sache der Bequemlichkeit, aber auch Kompatibilitaet und
usability. Siehe unten.

> Wie hoch ist die gesamte Datenmenge?
> Wie hoch ist die Datenmenge, die ständig im Zugriff ist?
> Wie hoch ist das geschätzte Datenwachstum?

Ach, das sind nur ein paar (truecrypt/dmcrypt/..)-Images, die alle paar
Tage mal manipuliert werden. Dennoch kann man dann ja nicht einfach ein
3GB Crypto-Image durchs Internet blasen nur weil mal jemand seinen
Truecrypt-Container in Windows geoeffnet hat. Es muessen auf binaerer
Ebene die Aenderungen in den Dateien uebertragen werden, wie es NFS
leistet.

> > Konkret suchen wir(bzw. unser Admin fuer uns) gerade nach einer Loesung
> > fuer Nutzerverzeichnisse, bei denen der Client FS-basiert oder (besser)
> > Volume-basiert Verschluesselung macht.
> Vorschlag:
> Die Verzeichnisse liegen Dateibasiert verschlüsselt auf einem zentralen 
> Server. Die Entschlüsselung erfolgt über einen Automounter, der bekommt 
> die nötigen credentials von Kerberos.

Hm, client-seitige Verschluesselung ist aber schon ein Kernpunkt.
Mit SMB/CIFS uebers Internet ist mir auch nicht wohl und ich wuerde
mich auch freuen, wenn man nicht extra Samba installieren muss.

> > Nutzer sollen kein VPN instalieren/starten muessen.(Chefs sind faul.)
> 
> Dann wird zwangsweise der Netzwerkverkehr unverschlüsselt sein, es sei 
> denn jede Verbindung verschlüsselt extra für sich, was irgendwann extrem 
> aufendig ist.

Naja, abseits von VPN gibt es ja zB persistente TLS-Verbindungen..

Der wesentliche Unterschied zu VPN ist denke ich, dass man in Windows
und OSX kein Tool installieren muss dass das routing am client komplett
zersaegt. Wenn die clients auf Reisen mit 3G oder Wifi an Netz gehen
darf es einfach keine Probleme geben. Wenn ich mir (als
nicht-mehr-admin) heutige Netzwerk-Manager in Windows und selbst
Linux so ansehe, geht aber eigentlich immer alles schief.

> Vorschlag: Was spricht dagegen beim starten des Rechners eine 
> automatische VPN-Verbindung aufzubauen? Das dazu nötige Zertifikat ist 
> Rechnerbezogen hinterlegt, kein Passwort.
> Dienste werden nur über das aufgebaute VPN angeboten. Das VPN dient so 
> daher allein dem Schutz der Verläßlichkeit gegenüber dem Netzwerk, nicht 
> mehr.

Kennt jemand *gute* VPN-clients fuer Windows?

Besagter Betrieb investiert gerade mehrere tausend Euro in
Netzwerkhardware um zwei Institute so zu verbinden, dass kein VPN ueber
Internet aufgemacht werden muss wenn man den Kalender in Exchange
aktualisiert. Von daher ist es wenig wahrscheinlich, dass man das Thema
nochmal diskutieren kann..

> > Ich sehe bisher im wesentlichen zwei Szenarien:
> >
> > 1)
> > - iSCSI zum Client und der Client macht TrueCrypt/DMcrypt/...
> 
> Also blockbasierte clientverschlüsselung: Gedanken dazu: was würde das 
> für die Sicherung bedeuten? Wie sichert ihr dann die Daten?

Ja, das ist ein Problem. Ich dachte daran, die devices fuer iSCSI als
image-Dateien auf der Platte zu lagern und dann mit dm-snapshot zu
arbeiten. Ebenso sollte man bei webdav/nfs-basierten Loesungen mit
dm-snapshot sinnvoll inkrementelle Backups erzeugen koennen.

Das ist zwar nicht schoen, aber es ist ja auch gerade Zweck der
client-seitigen Verschluesselung, dass nur der Client rekonstruieren
kann..

>  > - public dirs ueber webdav
> würde gehen. Mir ist aber kein Automatismus bekannt der 
> nachgewiesenermaßen sicher _und_ funktionierend ist. Das "beste" was ich 
> dann kenne wäre ntlm über den Apache, in dem Fall kommen die credentials 
> wieder von Kerberos: das funktioniert gut, ist aber nicht wirklich 
> sicher... und ich habe keine Ahnung ob das auch für osx funktioniert.

Klingt grausam. :-)

Ich dachte mehr an SSL, am besten mit Client-Zertifikaten. Wenn man das
Server-Zertifikat fest konfigurieren kann ist aber auch htaccess gut
genug. Fuer die wichtigen Sachen ist ja eh nochmal ein TrueCrypt-Layer
oben drauf.

> > - Alles per webdav und der Client legt image-files an
> 
> Das verstehe ich nicht ganz. Sagst Du noch 2 Sätze mehr dazu?

Client mounted webdav und macht darin eine Image-Datei, die wiederrum
lokal mit truecrypt gemountet wird.

Egal welche Loesung, am Ende muss am client Truecrypt oder dmcrypt oder so
laufen. Gegenseitig zugreifen tun sie nur auf 2-3 'public'
repositories, wo dann natuerlich auch kein Truecrypt gemacht wird.

> > Problem mit 1) ist, dass iSCSI nicht sicher ist. Zwar werden die Daten
> > wiederrum verschluesselt, aber ein Angreifer koennte das
> > iSCSI-Protokoll manipulieren um die Nutzerverzeichnisse logisch kaputt
> > zu machen. Ausserdem muss man zwei verschiedene Loesungen fahren.
> 
> iscsi ist für alle BS nativ verfügbar und beherscht eine Verschlüsselung 
> der Daten übers Netz, das ist also lösbar. Ich halte es bspw. aus 
> Gründen der Datensicherung für nicht akzeptabel.

Ich lese immer dass man iSCSI ueber VPN betreiben muss weil es
ungesichert ist: http://en.wikipedia.org/wiki/ISCSI#Security

CHAP ist das hinterletzte und ist auch nur fuer die Authentisierung
zustaendig. Der Datenkanal ist offenbar trotzdem ungeschuetzt.


In Linux koennte man sicherlich einen on-demand SSL tunnel basteln,
aber in Windows?

So eine Bastelei ist als Produktiv-Loesung auch nicht sonderlich attraktiv..
https://w3.physics.illinois.edu/physwiki/doku.php?id=pcs:unix:nfs_over_stunnel


Ich denke wir kommen nicht um VPN herum. Wenn es in Windows gescheit
implementiert ist kann man ja nur den benoetigten IP stream tunneln..

> [...]

Dein Vorschlag passt gut auf die uebliche Firma mit zentral verwalteten
Rechnern und definiertem Funktionsumfang. Bei uns hat jeder einen
eigenen Laptop, der auch teilweise privat benutzt wird und staendig
unterwegs ist. Saemtliche Dienste sind immer auch ueber Internet
verfuegbar und man will den Leuten keine spezielle Software aufzwingen.

Mit heutigen Tablets und Smartphones ist perimeter security eh vorbei.
Was man an Diensten faehrt muss transparent im Internet funktionieren
und per design sicher sein.



-- 
System Security Lab                            web:  www.trust.cased.de
CASED / TU Darmstadt                           phone: +49 6151 16-75565
PGP Key Fingerprint = B805 57BE E4AF 0104 CC51 77A1 CE6F 8D46 A04D 7875



Mehr Informationen über die Mailingliste linux-l