Re: [suse-security] firewals package - NFS exports
I think that running NFS on a firewall is _never_ reasonable. I played a
Yes you're right, sorry my question must have sounded a bit stupid without further info. My setup is rather small-scale: while I have the computer at uni, I need NFS-access (both directions) over the local ethernet. The university has border firewalls installed, any attack would have to come from a (possibly hacked) machine inside. While I have the machine at home, I have no ethernet, and definitely need any protection I can get (ISPs are providing real internet service - in both directions, i.e. everything open). Back at uni I thought it doesn't hurt to keep the firewall setup running... And I can dialup as well while being at uni, in which case I definitely want to close NFS ports to ppp0!
A firewall with server functionality is a contradiction in itself and certainly not recommended.
True, but running firewals is better than not doing it... So, is anyone able to give a port-range which is typically used by NFS? Thanks, Volker
On Sat, Sep 02, 2000 at 12:28 +1200, Volker Kuhlmann wrote:
So, is anyone able to give a port-range which is typically used by NFS?
No, due to the "dynamic" nature of RPC. You might want to have a filter hooked up in the portmapper stream (ports 111 udp+tcp) generating rules on the fly as connections get established and closed. It's very much like FTP data sessions. virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.
At 12:28 02.09.2000 +1200, you wrote:
I think that running NFS on a firewall is _never_ reasonable. I played a
A firewall with server functionality is a contradiction in itself and certainly not recommended.
True, but running firewals is better than not doing it...
So, is anyone able to give a port-range which is typically used by NFS?
"Building Internet Firewalls" says: TCP/UDP External NFS Client to Internal Server, Portmapper req., In Source >1023 Dest 111 Internet NFS Server to external Client, Portmapper res, Out Source 111 Dest >1023 ACK External NFS Client to Internal Server, NFS req, In Source <1024 * Dest 2049 Internet NFS Server to external Client, NFS res, Out Source 2049 Dest <1024 * ACK * (Some implementations may use ports >1023 instead) [...] MfG Matthias Compositiv EDV- und Kommunikationslösungen, PC-Service Matthias Krawen Peiffersweg 9 22307 Hamburg Tel: 040 / 611 673 - 40 EMail: info@compositiv.de Fax: 040 / 611 673 - 41 http://www.compositiv.de
On Sat, Sep 02, 2000 at 12:21 +0200, Matthias Krawen wrote:
At 12:28 02.09.2000 +1200, you wrote:
So, is anyone able to give a port-range which is typically used by NFS?
"Building Internet Firewalls" says:
[ ... 111 for portmapper, 2049 for nfs ... ]
Is this a "given" or is it just "observed many times and usually done so"? I'm not clear about how determined or fix this knowledge is (and I thought the thread's originator watched NFS using different and mostly unpredictable ports). virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.
Hi While looking in /etc/shadow i saw gdm login with no password. The implications of this are obvious... I'm using suse 6.3 The only thing im using is : gnlibs GNOME Base package (Libs) Any explanation for this? Joao Seabra
On Sat, 02 Sep 2000, you wrote:
While looking in /etc/shadow i saw gdm login with no password. The implications of this are obvious...
I checked SuSE 6.3 and 6.4 and saw a '*' in /etc/shadow. This means that no password can be used and is different from a void password. -- Bye, /\/\ / |char*p="char*p=%c%s%c;main(){printf(p, (/\/\)ax. |34,p,34);}";main(){printf(p,34,p,34);}
Normally when I am blocking NFS on my firewalls I typically block tcp an udp port 2049 so maybe you should open up that port.
participants (6)
-
Gerhard Sittig -
Joao Seabra -
Massimiliano Hofer -
Matthias Krawen -
semat＠wawa.eahd.or.ug -
Volker Kuhlmann