PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : NFS läuft auf falschen Ports (SuSE 8.1)



nobody0
21.10.02, 17:53
Nach dem update auf SuSE 8.1 funktioniert nur NFS nicht und der Grund ist, das die Daten-Pakete nicht mehr durch die Firewall kommen, weil die nun auf unassigned Ports sind:

Oct 17 10:27:36 gin kernel: DROP-UDP IN=eth0 OUT=MAC=00:e0:18:98:07:e0:00:04:76:72:f4:ed:08:00 SRC=192.168.59.7 DST=192.168.59.9 LEN=152 TOS=0x10 PREC=0x00 TTL=64 ID=46784 DF PROTO=UDP SPT=633 DPT=33754 LEN=132

Das Mounten funktioniert aber auch nicht mit der Option port=2049 die ohne Fehlermeldung/Kommentar einfach ignoiert wird (in der fstab wie von der Kommandozeile); es werden immer noch merkwürdige unassigned Ports genommen, die ich aus Sicherheitsgründen nicht akzeptieren kann (sonst müsste ich ja alles akzeptieren u. könnte die Firewall gleich weglassen).

Wie bekomme ich das NFS auf nur den NFS-Port (2049)? :confused:

Berufspenner
21.10.02, 21:30
Hi

Also wie du dein Problem auf eine normale Art lösenkannst kann ich dir leider nicht sagen. Es war schon (fast)immer so, dass ein SuSE-Update auf eine neuere Version Probleme und wahrloses Chaos mit sich gebracht hat; so auch bei mir.

Cu

jean_luc_picard
31.12.02, 17:17
tja, nicht sehr hilfreich... bin gerade mit der suchfunktion auf diesen thread gestossen... ich kann dich beruhigen, das liegt nicht am update, sondern an der version selbst... ich hab jetzt erstmal die firewall freigegeben (also sämtliche ports), da ich das ebenfalls festgestellt habe :( ... wie siehts denn nun aus? hast du vielleicht mitlerweile ne lösung gefunden?

dauni
31.12.02, 17:37
Das Update ist aber troztem nicht zu empfehlen

nobody0
31.12.02, 19:18
Nichts gefunden. Als Wordaround werde ich mit den nächsten Rechnern auf Debian wechseln und das Abo bei SuSE abbestellen.

jean_luc_picard
01.01.03, 19:31
also ich bin hier mal durchs forum gestöbert und hab gelesen, das der port vom portmapper zugewiesen wird und immer ein anderer ist.
dann hab ich noch diesen link gefunden

http://radawana.cg.tuwien.ac.at/mail-archives/lll/200203/msg00149.html

aber irgendwie will ich mich damit nicht abfinden, es kann doch nicht sein, das auf einem system ein skript per cronjob laufen lassen soll, um neue firewall-regeln hinzuzufügen. ausserdem müssten diese firewallregeln ja auch wieder gelöscht werden, wenn der client offline geht, oder hab ich das falsch verstanden?

kann man dem portmapper nicht vorschreiben, welche ports er vergeben soll? wozu soll dieser portmapper eigentlich gut sein? warum lässt man nfs nicht einfach auf festen ports laufen, wie man es von anderen diensten kennt?

nobody0
01.01.03, 20:23
Unter SuSE 8.0 funktionierte es auf den nfs-Ports und nicht auf unassigned Ports, so wie es sein soll!

jean_luc_picard
01.01.03, 23:52
tja... gut, dann gilt es ja nur herauszufinden, was suse seit 8.0 geändert hat ;)

leider bin ich da völlig überfragt, hat jemand ne ahnung welche konfigurationsdateien damit zu tun haben könnten, bzw. welche pakete?

dauni
02.01.03, 02:16
Hmm, hab mal ein wenig gegoogetl und die erkenntnis ist, dass nfsd immer auf 2049-udp und mountd variabel auf udp oder tcp läuft.

So, nun wäre die Ausgabe von "rpcinfo -p" deiner betroffenen Rechner sicherlich von Interesse

Edit:
Hab ein wenig weiter gegoogelt und dabei das gefunden: http://www.iiv.de/schwinde/buerger/tremmel/firewall.html

Das Script soll sich die Ports von nfs merken. Voraussetzung ist, dass nfs bereits läuft, wenn die Firewall aktiviert wird.

Nochmal Edit:
Der Kernel-nfsd soll auch auf anderen Ports gestartet werden können:
# Verwendung des Ports 1111 anstatt 2049
root@sonne> /usr/sbin/rpc.knfsd -p 1111

Jetzt such ich nicht weiter, das Problem hab ja nicht ich und du steigst eh auf debian um ;)

Nochmal Edit -> Erste Zeile: nfsd läuft immer auf 2049 und nicht auf 1049 :ugly:

nobody0
02.01.03, 08:05
Original geschrieben von dauni
So, nun wäre die Ausgabe von "rpcinfo -p" deiner betroffenen Rechner sicherlich von Interesse


Auf dem Client sieht es so aus:

lycee:~ # rpcinfo -p
Program Vers Proto Port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper

Und auf dem Server so:

gin:~ # rpcinfo -p
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 32768 status
100024 1 tcp 32768 status
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100021 1 udp 32770 nlockmgr
100021 3 udp 32770 nlockmgr
100021 4 udp 32770 nlockmgr
100021 1 tcp 32769 nlockmgr
100005 1 udp 32771 mountd
100005 1 tcp 32770 mountd
100005 2 udp 32771 mountd
100005 2 tcp 32770 mountd
100005 3 udp 32771 mountd
100005 3 tcp 32770 mountd
100021 3 tcp 32769 nlockmgr
100021 4 tcp 32769 nlockmgr

Und der Client meldet beim Booten das:

Importing Net File System (NFS)<notice>'/etc/init.d/rc3.d/S09sshd start' exits with status 0
<notice>/etc/init.d/rc3.d/S11nfs start
mount: RPC: Unable to receive; errno = Connection refused

jean_luc_picard
02.01.03, 11:10
Original geschrieben von dauni
Hab ein wenig weiter gegoogelt und dabei das gefunden: http://www.iiv.de/schwinde/buerger/tremmel/firewall.html

Das Script soll sich die Ports von nfs merken. Voraussetzung ist, dass nfs bereits läuft, wenn die Firewall aktiviert wird.


ich hab mir die firewall mal ein wenig angeschaut und so wie ich das sehe, muss nicht nur der nfs laufen, also der dienst, es müssen zudem auch alle clients bereits mit dem server verbunden sein wenn das skript gestartet wird. ich weiss nicht genau wie sich das verhalten würde, wenn gerade ein client versucht zum server zu connecten, aber selbst wenn dann entsprechende ports freigegeben werden würden, dann müsste man das skript ja per cron oder so alle paar min. laufen lassen, was auch sicher nicht der sinn sein kann.
... möglicherweise sehe ich das aber auch falsch (bin nicht gerade fit im skripten :( )?!


Original geschrieben von dauni
Jetzt such ich nicht weiter, das Problem hab ja nicht ich und du steigst eh auf debian um ;)

...naja... es gibt auch noch andere leute, die das problem haben :rolleyes: ... deine hilfe wäre also nicht für die katz ;) ... ich wäre jedenfalls für weitere hinweise dankbar :)

dauni
02.01.03, 13:27
Hehe, dann werd ich mich mal heut abend näher damit beschäftigen ;)

dauni
02.01.03, 13:47
Öhm - bevor ich jetzt wild zu spekulieren beginne: Ohne Firewall bootet der Client ohne Mucken? oder gibts da auch schon Probleme mit dem Import?

bp6rz
22.03.03, 08:11
Ohne Firewall (SuSEfirewall2) kann ich nfs-shares mounten (auch wenn ich protect_from_internal auf no setze). ich mounte von SuSE8.0 shares, die auf RedHat8.0 freigegeben sind. Also die firewall läuft auf dem SuSE Server.

Bei jedem Versuch ein nfs-Verzeichnis zu mounten wird eine Anfrage auf einem anderen Port
gestartet:

morpheus:~ # tail -f /var/log/firewall |grep IN=eth0
Mar 22 09:41:03 morpheus kernel: SuSE-FW-DROP-DEFAULT IN=eth0 OUT= MAC=00:40:63:c0:de:44:00:50:bf:68:eb:96:08:00 SRC=192.168.0.4 DST=192.168.0.2 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=32776 DPT=853 LEN=64
Mar 22 09:41:06 morpheus kernel: SuSE-FW-DROP-DEFAULT IN=eth0 OUT= MAC=00:40:63:c0:de:44:00:50:bf:68:eb:96:08:00 SRC=192.168.0.4 DST=192.168.0.2 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=32776 DPT=853 LEN=64

morpheus:~ # tail -f /var/log/firewall |grep IN=eth0
Mar 22 09:57:26 morpheus kernel: SuSE-FW-DROP-DEFAULT IN=eth0 OUT= MAC=00:40:63:c0:de:44:00:50:bf:68:eb:96:08:00 SRC=192.168.0.4 DST=192.168.0.2 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=32776 DPT=743 LEN=64
Mar 22 09:57:29 morpheus kernel: SuSE-FW-DROP-DEFAULT IN=eth0 OUT= MAC=00:40:63:c0:de:44:00:50:bf:68:eb:96:08:00 SRC=192.168.0.4 DST=192.168.0.2 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=32776 DPT=743 LEN=64

Die Fragen sind denke ich,
wie kann man nfs dazu bringen, die Anfragen nur auf vorher definierten Ports auszuführen
oder
gibt es eine dynamische Variante, bspw. daß bei Eintreffen einer nfs-Anfrage einer vorher auf dem Firewall-Server registrierten mac-Adresse, der Port, auf dem diese mac anfragt ,freigeschaltet wird. Das sollte doch auch sicher genug sein , oder?

jean_luc_picard
22.03.03, 09:18
ich bin auch immer noch nicht zufrieden mit der vorhandenen situation... :(
es sollte doch möglich sein, eine ähnliche lösung wie bei passivem ftp zu programmieren und die benötigten ports über connection-tracking freizugeben... für ftp kann man ja ein entsprechendes modul laden, leider hab ich für nfs keins gefunden...

nur kurz zum connection-tracking (für alle die es nicht schon wissen ;) ):
bei ftp wird eine verbindung über port 21 hergestellt, dabei wird dann ein port für den datentransfer "ausgehandelt". da der ausgehandelte port in einem der pakete, die über port 21 gehen eingetragen ist, benötigt man für die firewall ein modul, welches dieses paket nach dem ausgehandelten port durchsucht. dieses modul sorgt dann dafür, das der port als "relatet", also zugehörig zur ftp-verbindung, der firewall bekannt ist und somit freigegeben werden kann... für alle die es genau wissen wollen ;) :
http://www.sns.ias.edu/~jns/security/iptables/iptables_conntrack.html


nun weiß nicht, ob das ganze bei nfs ähnlich abläuft und ein solches modul überhaut realisierbar ist...

jean_luc_picard
22.03.03, 09:20
Original geschrieben von dauni
Öhm - bevor ich jetzt wild zu spekulieren beginne: Ohne Firewall bootet der Client ohne Mucken? oder gibts da auch schon Probleme mit dem Import?

ohne firewall funktioniert das ohne probleme... genau

bp6rz
22.03.03, 09:22
hab's nur kurz aufgeschnappt und nich genau gelesen, aber könnte vielleicht nfs-over-tcp als kernel-option 'ne lösung sein?

jean_luc_picard
22.03.03, 09:40
probier doch mal und berichte uns ;)
ich hab schon ewig keinen kernel mehr kompiliert...

nobody0
22.03.03, 11:07
Ich werde demnächst mal über ssh getunneltes NFS probieren, das portmäßig keine Probleme machen sollte, sicher ist und mit blowfish statt 3DES nur wenig Performance braucht.

jean_luc_picard
22.03.03, 11:17
hast du dazu vielleicht ein paar empfehlenswerte seiten? würde mich auch mal interessieren...

nobody0
22.03.03, 16:31
Im Linuxmagazin waren mal ein paar Erläuterungen, die aber nicht ausreichen.
Hier ist es ausführlich erklärt:
http://www.samag.com/documents/s=4072/sam0203d/sam0203d.htm

nobody0
22.03.03, 18:45
In dem Artikel sind aber ein paar Fehler; da fehlen einige "--".

Ich habe das mal korrigiert:

# nfs over ssh for server (change client to client ip):
iptables -A INPUT -i eth0 -p tcp -s client --dport ssh -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --sport ssh -d client -j ACCEPT
iptables -A INPUT -i eth0 -p tcp -s client --dport 111 -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --sport 111 -d client -j ACCEPT

# nfs over ssh for client (change nfs to server ip):
iptables -A INPUT -i eth0 -p tcp ! --syn -s nfs1 --sport ssh -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp -d nfs1 --dport ssh -j ACCEPT
iptables -A INPUT -i eth0 -p tcp ! --syn -s nfs1 --sport 111 -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp -d nfs1 --dport 111 -j ACCEPT