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)