Am Freitag, 26. M�rz 2004 18:09 schrieb Jan Kesten: > Hallo ich wieder ;-) > > Ich bastele immer noch an meinem NFS Server herum, besonders > Stabilit�t und Sicherheit machen mir noch etwas zu schaffen. Was ist unstabil und unsicher mit deinem NFS-Server?
> Das > Problem der Fragmentation hatten wir ja schon: > > http://nfs.sourceforge.net/nfs-howto/performance.html#FRAG-OVERFLOW > > Gibt's dazu schon (sagen wir mal) praxistaugliche Werte? Andere > Sache ist ja die MTU (die steht hier auch auf 1500 Bytes). Kann man > die gefahrlos erh�hen, so dass man eventuell 2k Pakete durchs Netz > bekommt (wg. rsize und wsize)? Oder hat das u.U. unliebsame > Nebeneffekte? Konnte es heute nicht mehr testen... Kann ich nichts dazu sagen, mu�t du halt austesten. Die Frage ist allerdings: was versprichst du dir davon? > Anderes Problem ist, wie kann ich den Rechner mit iptables sichern? *Was* willst du denn *warum* mit iptables absichern? Zugriff von au�en? Daf�r richtest du einen extra Firewall-Rechner ein. Zugriff von innen auf diesen Server? Dann machst du grunds�tzlich etwas falsch ;-) Wenn ich Server-Dienste blockieren mu� gegen Zugriffe von Clients brauche ich diese Dienste nicht. Oder habe diese falsch konfiguriert. Und dann bietet auch eine Firewall nur scheinbare Sicherheit. > Hatte schon einiges gelesen, wie man es schaffen kann, die NFS > Dienste alle an feste Ports zu binden. Ist etwas kniffeliger > offensichtlich, denn ich konnte z.B. den mountd nicht �ndern und hab > Probleme mit dem Kernel-NFS-Server: lockd.udpport=4001 > lockd.tcpport=4001 als Parameter funktionieren leider nicht, hab > aber auch nichts besseres gefunden (hat sich der Parameter-Name > vielleicht bei einem 2.6er Kernel ge�ndert?) Das Verfahren bei 2.6 kenne ich nicht. Aber du kannst z.B. in den init.d-Scripten jedem rpc.- bzw nfs.-Dienst per -p oder --port einen bestimmten Port zuweisen, sofern manche nicht �ber den portmapper geregelt werden. Der rpc.lockd wird IMHO ab Kernel 2.4 als Thread gestartet und hat keinen zuweisbaren Port. Aber auch diese Notwendigkeit der "Verwirrung" von Clients (und "Angreifer-Clients) erschlie�t sich mir nicht. Jedenfalls nicht als Allheilmittel. > Oder gibt es noch eine andere M�glichkeit? Leider musste ich mal > wieder feststellen, dass die gr��ten Probleme nicht von aussen in > das Netz kommen, sondern sich innen befinden. Welche Probleme hast du denn eigentlich? Kommen deine Client-User an Daten ran, die sie eigenlich nicht benutzen d�rfen? Dann hast du ein grunds�tzliches Admin-Problem. Und dann n�tzt es auch nicht �ber die Portreglung zu sagen: "Meine Vordert�r ist jetzt bittsch�n die Hintert�r", wenn eben diese Hintert�r auch sperrangelweit offensteht. Meine Meinung zu nfs in einem Netzwerk ist: - nfs ist per se ein *unsicheres* net-filesystem. - aber: nfs ist *einfach* zu konfigurieren und zu warten und ist ein *sicheres* net-filesystem wenn der Admin sich an die Spielregeln h�lt. Die da w�ren: a) Der nfs *Server* regelt nur die Frage: darf ein bestimmter Client-Rechner (oder IP) meine Dienste in Anspruch nehmen. Die Frage des Benutzers (uid/gid) spielt in diesem Stadium *keine* Rolle. b) Bei erfolgreichem Nutzen des Dienstes ist alles weitere Sache des verwendeten *Filesystem* bzw. der Benutzerverwaltung auf dem *Server*. c) Stell dir nfs nur als Dienst vor, der deinen Users erlaubt �ber ein Netzwerk so zu agieren, als w�rden sie direkt am Server arbeiten. Dann wird es IMHO klarer. Die wichtigsten Einstellungen f�r nfs in punkto Sicherheit stellst du �ber die Rechte-Verwaltung des Server-Filesystems sicher. Und da bieten selbst ext2|3 mit owner:group:other Regeln genug M�glichkeiten auch umfangreichere Zugriffs-Szenarien umzusetzen. d) Andere Filesysteme auf dem Server bieten da z.B. �ber ACLs besseren Schutz als ext2|3. Das ist halt eine Frage inwieweit man seinen Usern trauen kann bzw. wie hoch die Anforderungen des Netzwerkes sind. Das aber ist wie gesagt Server-Sache und hat mit nfs (als Transport) nur sekund�r zu tun. e) Die IMHO beste Methode bei h�herem Sicherheitsbed�rfniss ist, �ber nfs ein verschl�sselndes Dateisystem zu exportieren (z.B. cfs). > Warum auch immer einer > unserer Server permanent auf Porten Dienste �ffnet hab ich nie > herausbekommen - nur dass es wirklich nicht zur Performance > beitr�gt, wenn dann ein Prozess gestartet wird, nur um wieder > beendet zu werden... Das verstehe ich nicht. > Cheers, > Jan Gru� Gerhard
