Hallo,
diesmal keine Frage sondern ein kleiner Erfahrungsbericht. Vielleicht interessiert es ja jemanden.
Ich brauchte zu Hause plötzlich unbedingt einen NFS-Server für interne Zwecke. Und zwar auf dem Rechner, der auch Router ins Internet ist. Das heißt: Der Rechner brauch RPC-Dienste (*bähkse*) und diese müssen nach aussen abgesichert werden. NFS-Server bedeutet: portmapper + statd + nfsd + mountd + lockd
Wenn man das Zeugs einfach alles startet, belegen die verschiedenen RPC-Dienste wild irgendwelche Ports auf dem Rechner. Der portmapper vergibt die Ports, wie er gerade Lust hat. Die Dienstliste sieht z.B. so aus (rpcinfo -p localhost)
program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 1091 status 100024 1 tcp 2502 status 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100021 1 udp 1092 nlockmgr 100021 3 udp 1092 nlockmgr 100021 4 udp 1092 nlockmgr 100005 1 udp 1093 mountd 100005 1 tcp 2503 mountd 100005 2 udp 1093 mountd 100005 2 tcp 2503 mountd 100005 3 udp 1093 mountd 100005 3 tcp 2503 mountd
Wenn man den Rechner neu startet, schnappen sich die Dienste völlig andere Ports, nur die 111 und 2049 von portmapper und nfsd wären konstant. Das ist ein ekliger Zustand, wenn man den Rechner per Paketfilter absichern will. Ich möchte nicht einfach alle Ports (bis auf ein paar erlaubte) sperren sondern nur die, auf denen auch wirklich was schützenswertes läuft. Also müßte ich entweder jedesmal die FW-Konfiguration anpassen (*pfui*) oder die RPC-Server auf feste Ports zwingen. Die 2. Lösung ist natürlich besser. Deshalb will ich sie hier vorstellen.
Ich habe also in /etc/init.d/* die Startskipte der Daemonen editiert und ihnen feste Ports (2000 und folgende) zugewiesen. Im einzelnen sind das:
rcp.statd -p 2000 rpc.nfsd -p 2001 rpc.mountd -p 2003
Nun startete ich den NFS-Kram neu und bekam folgende Dienstliste (ich habe mal die verantwortlichen Programme mit reingeschrieben):
program vers proto port portmap 100000 2 tcp 111 portmapper // logo, immer 111 100000 2 udp 111 portmapper rpc.statd 100024 1 udp 2000 status // auf 2000 gezwungen 100024 1 tcp 2000 status rpc.nfsd 100003 2 udp 2001 nfs // auf 2001 gezwungen 100003 3 udp 2001 nfs [lockd] 100021 1 udp 1090 nlockmgr !!!!!!!! 100021 3 udp 1090 nlockmgr !!!!!!!! 100021 4 udp 1090 nlockmgr !!!!!!!! rpc.mountd 100005 1 udp 2003 mountd // auf 2003 gezwungen 100005 1 tcp 2003 mountd 100005 2 udp 2003 mountd 100005 2 tcp 2003 mountd 100005 3 udp 2003 mountd 100005 3 tcp 2003 mountd
Man sieht, daß einer der Dienste noch verrückt spielt, der nlockmgr. Dieser Lockmanager ist kein normales Programm sondern ein Kernelthread, der vom rpc.nfsd automatisch mit gestartet wird. Er taucht als [lockd] in der Prozessliste auf. Man kann dem Ding nicht einfach beim Aufruf einen Parameter für den Port verpassen wie den anderen Daemonen.
Ein Blick in der Kernelsource zeigt aber, daß man lockd so wie auch Gerätetreibern durch die /etc/modules.conf bestimmte Optionen übergeben kann. Die entsprechende Zeile für die modules.conf lautet:
options lockd nlm_udpport=2002 nlm_tcpport=2002
Nach Neuladen des lockd-Moduls in den Kern und Neustart der NFS-Dienste sieht es so aus:
program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 2000 status 100024 1 tcp 2000 status 100003 2 udp 2001 nfs 100003 3 udp 2001 nfs 100021 1 udp 2002 nlockmgr 100021 3 udp 2002 nlockmgr 100021 4 udp 2002 nlockmgr 100005 1 udp 2003 mountd 100005 1 tcp 2003 mountd 100005 2 udp 2003 mountd 100005 2 tcp 2003 mountd 100005 3 udp 2003 mountd 100005 3 tcp 2003 mountd
Schön! Jetzt kann man einfach die Ports 111 sowie 2000-2003 für UDP und TCP per Paketfilter für Zugriffe von außen sperren und hat Ruhe. Über die Wahl der Ports läßt sich natürlich streiten.
Reinhard
Hallo Reinhard!
On Sat, Mar 16, 2002 at 01:29:40PM +0100, Reinhard Foerster wrote:
Hallo,
diesmal keine Frage sondern ein kleiner Erfahrungsbericht. Vielleicht interessiert es ja jemanden.
Ich brauchte zu Hause plötzlich unbedingt einen NFS-Server für interne Zwecke. Und zwar auf dem Rechner, der auch Router ins Internet ist.
...
Ich möchte nicht einfach alle Ports (bis auf ein paar erlaubte) sperren sondern nur die, auf denen auch wirklich was schützenswertes läuft.
Warum nicht? Ich denke es ist sicherer alles zu verbieten und nur das zuzulassen, was gebraucht wird.
thomas
On Sun, Mar 17, 2002 at 08:55:36PM +0100, Thomas Guettler wrote: Hi Thomas!
Ich möchte nicht einfach alle Ports (bis auf ein paar erlaubte) sperren sondern nur die, auf denen auch wirklich was schützenswertes läuft.
Warum nicht?
Ich probiere oft irgendwelche Netzwerksachen aus. Würde ich per default alles sperren, müßte ich pausenlos an der FW-Konfig schrauben um arbeiten zu können. Wenn man kein RPC nutzt kommt man auf dem typischen heimischen Router mit 2 Interfaces sehr gut völlig ohne FW aus. Abseits der RPC-Altlasten kann man alle Programe (bind, squid, ...) so konfigurieren, daß sie nur am internen Interface lauschen. Das ist mMn die beste Lösung. Gegen den "Feind von innen" mache ich hier zu Hause sowieso nichts. Wenn ich mir selbst ins Knie schieße ist das OK.
Ich denke es ist sicherer alles zu verbieten und nur das zuzulassen, was gebraucht wird.
Nein, das ist so pauschal falsch. Solange ich nicht vergesse, irgendwas zu sprerren, ist dein Ansatz nicht besser. Es bringt z.B. null Sicherheitsgewinn, Ports per Paketfilter zu sperren, auf denen nichts läuft. Und: Wo ich vergessen könntem, was zu sperren, könnstest du mit deinem Ansatz aus Versehen zu viel Erlauben. Vor allem muß die FW-Konfig zum Einsatzfall passen und da passt bei mir mein Ansatz besser. Dein Ansatz ist sicherlich dort besser, wo FW-Admin und Anwender nicht die gleiche Person sind und wo keine "Netzwerkspielereien" veranstaltet werden.
Davon abgesehen halte ich das ist das Festnageln von RPC-Servern auf bestimmte Ports gernerell für eine gute Idee. Schön, daß das mit Linux gemacht werden kann. Bei Solaris scheint das z.B. nicht zu gehen. Ein Argument mehr für Linux :-)
Reinhard
Hallo
On Sat, 16 Mar 2002, Reinhard Foerster wrote:
Ich habe also in /etc/init.d/* die Startskipte der Daemonen editiert und ihnen feste Ports (2000 und folgende) zugewiesen. Im einzelnen sind das:
rcp.statd -p 2000
Welche Distribution und rpc.statd Version benutzt du? SuSE 7.3 und rpc.statd 0.3.1 kennt den Parameter -p für rpc.statd nicht. Für rpc.nfsd und rpc.mountd klapts.
Ein Blick in der Kernelsource zeigt aber, daß man lockd so wie auch Gerätetreibern durch die /etc/modules.conf bestimmte Optionen übergeben kann. Die entsprechende Zeile für die modules.conf lautet:
options lockd nlm_udpport=2002 nlm_tcpport=2002
Wo hast du den das gefunden. Ein Blick in meine aktuelles Kernel Version 2.4.18 zeigt mir das es diese Parameter dort nicht gibt und die Ports beim erstellen mit 0 angegeben sind und damit vom Kernel vergeben werden.
Mfg
Michael Mühle
On Sat, Mar 23, 2002 at 10:34:46AM +0100, Michael Mühle wrote: Hallo,
rcp.statd -p 2000
Welche Distribution und rpc.statd Version benutzt du? SuSE 7.3 und rpc.statd 0.3.1 kennt den Parameter -p für rpc.statd nicht. Für rpc.nfsd und rpc.mountd klapts.
debian woody. Die upstream release ist nfs-utils-0.3.3 von http://sourceforge.net/projects/nfs/, die bei Debian wegen &$#% auf 1.0 umgenannt wurde. Aktuell in woody ist nfs-utils_1.0-2.
options lockd nlm_udpport=2002 nlm_tcpport=2002
Wo hast du den das gefunden. Ein Blick in meine aktuelles Kernel Version 2.4.18 zeigt mir das es diese Parameter dort nicht gibt und die Ports beim erstellen mit 0 angegeben sind und damit vom Kernel vergeben werden.
Dann hast du einen einen anderen 2.4.18 als ich. Bei mir steht in linux-2.4.18/fs/lockd/svc.c:
MODULE_AUTHOR("Olaf Kirch okir@monad.swb.de"); MODULE_DESCRIPTION("NFS file locking service version " LOCKD_VERSION "."); MODULE_LICENSE("GPL"); MODULE_PARM(nlm_grace_period, "10-240l"); MODULE_PARM(nlm_timeout, "3-20l"); MODULE_PARM(nlm_udpport, "0-65535l"); MODULE_PARM(nlm_tcpport, "0-65535l");
Reinhard
Mfg
Michael Mühle
Lug-dd maillist - Lug-dd@schlittermann.de http://mailman.schlittermann.de/mailman/listinfo/lug-dd
Hallo
On Sat, 23 Mar 2002, Reinhard Foerster wrote:
debian woody. Die upstream release ist nfs-utils-0.3.3 von http://sourceforge.net/projects/nfs/, die bei Debian wegen &$#% auf 1.0 umgenannt wurde. Aktuell in woody ist nfs-utils_1.0-2.
Dann muß ich das hier wohl mal aktualisieren in Version 0.3.1 gibt es das Parameter -p für rpc.statd noch nicht.
Dann hast du einen einen anderen 2.4.18 als ich. Bei mir steht in linux-2.4.18/fs/lockd/svc.c:
Dummer Fehler beim herunterladen. Ich war im MC verrutscht und hatt eine andere Version erwischt.
Da ich den lockd ins Kernel integriet habe müssen die Parameter lockd.udpport und lockd.tcpport lauten.
Mfg
Michael
lug-dd@mailman.schlittermann.de