Gruesse!
* Ruediger Noack <[EMAIL PROTECTED]> schrieb am [17.01.04 00:11]:
> >Tja, NFS ist f�r dein Vorhaben einfach nicht gemacht.
> >
> Und jetzt mal (f�r mich) theoretisch:
> In einer Umgebung mit Linux-Desktops w�re NFS doch naheliegend. Ist aber
> nach meinem Scenario eigentlich unverantwortlich. Da kommt jemand mit
> seinem Notebook (Linux), st�pselt sich anstelle seines Desktops mal
> vor�bergehend mit der fremden IP-Adresse und mit fremdem Usernamen ins
> LAN und nimmt alle geklauten Daten fr�hlich mit nach Hause. :-(
>
> So extrem hatte ich dieses Thema bisher nicht gesehen. Gut, dass wir
> dar�ber gesprochen haben. ;-)
Allgemein hast du recht, nur noch mal f�r die Genauigkeit:
a) der *Benutzername* allein langt nicht. Der B�seBube(B�Bu) mu� seinen
geklauten Usernamen mit den gleichen UserID/GroupID ausstatten. Auf dem
NFS-Server sind User/Group-Namen nur insofern relevant indem sie in
ensprechende UID/GID umgesetzt werden.
b) Man kann die Verzeichniss-Struktur (= Rechte-Struktur �ber UID/GID)
der exportierten Verzeichnisse "schmal" setzen. D.h., wenn ich /Daten
exportiere mu� User Paul nicht in /Daten/Briefe schauen k�nnen, wenn er
eigentlich nur Zugriff auf /Daten/MP3 haben soll.
c) Man kann (sollte) Usern das Mounten verbieten. An importierten
(NFS/Netz-Dateisystemen nur, was root beim Systemstart fest �ber fstab
einmountet. Dann greift aber wieder obiges a) + b).
d) Keine Root-Rechte �ber NFS! nur root_squash.
e) Man kann �ber netfilter die IPs an bestimmte MAC-Adressen binden.
f) Den nfs-port an einen un�blichen Port (! 2049) binden.
Das f�llt mir jetzt ein, um NFS etwas sicherer zu machen. Es sind
allerdings nur *Hindernisse* um einen an sich unsicheren Dienst zu
verbessern. Wenn der B�Bu auf seinem Laptop �ber Root-Rechte verf�gt und
einigerma�en versiert ist, sind das keine Hindernisse.
NFS ist also �hnlich als w�rde ich jeden mit einer Knoppix-CD an meinen
Server lassen, der praktischerweise noch �ber Schnittstellen wie Floppy,
CD-Rom, USB, ... verf�gt. W�rdest Du das?
Eine Alternative f�r den semiprofessionellen Bereich w�re noch der
Einsatz von crypto-Filessystemen, z.B. cfs (siehe apt-cache show cfs).
Du w�rdest dann per nfs die verschl�sselten Daten exportieren, was z.B.
so ausehen w�rde (wobei /data bei mir ein gemounteter NFS-Import ist):
[EMAIL PROTECTED]:~$ ls /data/privat/
0538edce1bd4478516416b399aef6abb
09526e8b24fdf43c2eac25bd8d7dfed4
1f0263f3396d361a
304c9bcf76e19563
396b501b5ddcec38e42a98f041f3152d4c96a593b93eb3d0bfece74bc2e6d69d
59b429159a6fd7a95e3aadf5e787d844
5fc77b61869c1e370098d9f87d4c19c094c90964e74ef6df
68378ec77a1088fe59e34c5d3f9a7ee9
76cadfa603003b2d
7b695e0ebc1dedceaf217112b229558b
8f3b6ed227878e0bb7ed38b58419f271
98c9766315bcf7cf1e56fb0597d41bb6
9dd4ee62dce9d5304fe12f3b2b28e115
a3043240a24177fc
bf09237c4404ccea
c1fc99e3a9e16fec2eb9d3cca298ce5f6370965f86a66f34
c36c94932a2f4f4e75dd5cc948c8477c
c8d41bc32fbb7c96a22e5ba6d33ae495
c97141a1c470ed6cd1745a6866f7f685
e6f72d033ff039dd
ed85032c6a6ce34068c996a062435c413c7d2f2d8ae2e8e2
Auf dem Client wird dann vom User mittels cattach das verschl�sselte
Verzeichniss unter Abfrage einer starken Passphrase lokal eingemountet
(z.B. nach /crypt/privdata. Dort kann der User kann wieder mit den
unverschl�sselten Daten arbeiten, die weiterhin aber verschl�sselt auf
dem NFS-Server sind.
Da� kostet halt etwas CPU-Zeit auf den Clients. Obiges a) und b) gelten
aber weiterhin. Wenn der B�Bu Schreibzugriff auf die verschl�sselt
abgelegten Daten erlangen sollte (�ber UID/GID oder als root) l�scht er
halt Dateien und Verzeichnisse mit "kryptischen Inhalt". Das *Lesen* und
Nutzen der Daten ist aber nahezu unm�glich.
> Gru�
> R�diger
Gru�
Gerhard
--
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)
