NFS security with /etc/hosts.deny

supernode · 06-30-2005, 05:06 AM

Dear all,

I am currently building a supernode including one server and eight clients.

I used RedHat 9.0 on my server and the nfs version is here:

redhat-config-nfs-1.0.4-5
nfs-utils-1.0.1-2.9

I want to safe my system in using NFS by configuring the two following files:
1) /etc/hosts.allow

portmap:ALL

2) /etc/hosts.deny

portmap:ALL
lockd:ALL
mountd:ALL
rquotad:ALL
statd:ALL

I think that with this configuration there will be no client host that can mount to my server.However, any of these eight clients hosts can mount to my server (the mount command is always successful).This means that there is no security with the server, and the remote client is still allowed to contact with the mountd daemon while the mountd daemon is denied from ALL in the latter file. I don't know why so.
If anyone knows the reason please answer me.

Thanks very much

synaptical · 06-30-2005, 10:04 PM

afaik portmap:ALL (and the other services:ALL) goes only in hosts.deny, or else everyone is allowed access.

the client entries in hosts.allow should look something like this example:

Code:

portmap: 192.168.0.100 , 192.168.0.101
lockd:  192.168.0.100 , 192.168.0.101
rquotad: 192.168.0.100 , 192.168.0.101
mountd: 192.168.0.100 , 192.168.0.101
statd:  192.168.0.100 , 192.168.0.101

gl

supernode · 06-30-2005, 10:46 PM

Hi synaptical,
Thanks for your reply,

Infact, I didn' t have any problem with NFS.

The problem I can' t understand here is why the mount command from the client to the server is still successful whereas the /etc/hosts.deny file in the server is configured to ban all access to the mountd daemon on the server.

With the configuration of this /etc/hosts.deny file, all I hope is that when the client mount to the server, it will receive an UNsuccessful message from the server.

Now i always receive the successful message from the server when the mount command is done from the client. I don' t know why.

Hope I can receive your reply soon.
Thanks.

synaptical · 06-30-2005, 11:10 PM

my guess would be because you are allowing "ALL" access to the portmapper, which perhaps is then calling the other daemons. (?)

also, i think i misspoke above. not having clients specified shouldn't allow access if you have the daemons denied in hosts.deny -- i'll edit that out in case it caused any confusion, apologies.

so try that (removing portmap:ALL from hosts.allow), and post back.

p.s. in case it helps clarify, the hosts.allow is read first. if the client is in there, access is allowed. if the client is not in there, hosts.deny is read to see if the client is explicitly blocked. if it's not, it gets access. so that's why i say my guess is that the portmap:ALL in hosts.allow is granting access, and then hosts.deny is not even read.

supernode · 07-01-2005, 01:28 AM

Hi synaptical,

I think that portmapper just provides the port number of the mountd daemon on the server to the client, so the client will access the mountd daemon via this port number. At this point, when the client access the mountd daemon via the port number, it will be banned because of /etc/hosts.deny file. But it is still allowed.

I think it may be due to other causes.

,
but i don't know which cause?

Thanks for your reply.

trickykid · 07-01-2005, 09:05 AM

You do realize that the allowed hosts are specified in the /etc/exports file for NFS so I don't see the need to deny hosts by your /etc/hosts.deny file or allowing them with the allow file as you can do all of this simply with your exports file to determine who can mount what.

synaptical · 07-01-2005, 09:46 AM

Quote:

Originally posted by supernode
Hi synaptical,

I think that portmapper just provides the port number of the mountd daemon on the server to the client, so the client will access the mountd daemon via this port number. At this point, when the client access the mountd daemon via the port number, it will be banned because of /etc/hosts.deny file. But it is still allowed.

I think it may be due to other causes.,
but i don't know which cause?

Thanks for your reply.

i am not sure that is entirely true, as you are missing the point that the mount is being allowed somewhere before the system is even reading your deny file, most likely in the exportfs, as trickykid said.

but if even that isn't case, instead of asking for a theoretical reason, imo you should just start experimenting until you find out the variable that is allowing it.

man exports
NFS howto

might help

gl

Stéphane Ascoët · 10-21-2005, 11:21 AM

The message "RPC problem" is clear: Your Linux can't talk to the OS X portmapper.

ravee · 10-22-2005, 09:51 AM

Quote:

p.s. in case it helps clarify, the hosts.allow is read first. if the client is in there, access is allowed. if the client is not in there, hosts.deny is read to see if the client is explicitly blocked. if it's not, it gets access. so that's why i say my guess is that the portmap:ALL in hosts.allow is granting access, and then hosts.deny is not even read.

Yes you are right. tcpwrappers first checks the hosts.allow file. If a rule matches, then the service is allowed. So the right thing to do is to remove that ofending line from the hosts.allow file.

You might try this rule in the hosts.allow file:

portmap:ALL EXCEPT .yourdomain.com :deny

where yourdomain.com is the domain/IP address of your internal LAN. If you are using the IP address just the network portion of the address will do with a leading dot (.) .

eg:
portmap:ALL EXCEPT 192.168.2. :deny

You can find a nice article about this topic at
http://linuxhelp.blogspot.com/2005/1...ure-linux.html