[sclug] Hosts.deny for NFS deny on Redhat Ent 4 update 4

[Alex Butcher]

Hi Martin -

On Wed, 18 Apr 2007, Martin Summers wrote:

> I have been scratching my head on this one this morning: I have a
> handful of hosts that I want to temporarily ban from a large NFS server
> which is served from a redhat4 update 4 server.
> I have been populating the hosts.deny file so that is looks something
> like:-
>
> ALL : 10.121.9.187
> ALL : 10.121.9.229
> ALL : 10.121.9.176
> ALL : 10.121.9.186
> ALL : 10.121.9.188
> ALL : 10.121.9.217
> ALL : 10.121.9.205
> ALL : 10.121.9.204
> ALL : 10.121.9.180
> ALL : 10.121.9.228
>
> And hosts.allow is blank - just the usual default comments in it. I have
> restarted the nfs portmap service just to make sure, but unfortunately,
> I can still NFS mount from this host from these IP addresses.
> Am I doing something daft here ? It seemed to work fine on the SuSE 9.3
> NFS server I tested it on.....
>
> Any ideas - I'd be glad to hear them !

Things I'd try:

1) Make sure I've stopped and restarted all NFS-related services, including
portmap and rpc.statd/nfslock.

2) Check whether all NFS-related services have been linked against
TCP_WRAPPERS;

# strings /sbin/portmap | grep -i hosts
[...]
/etc/hosts.allow
/etc/hosts.deny

should be a good enough test, I reckon.

3) Check I'm not using a kernelspace NFS server. I'd guess that would ignore
the TCP_WRAPPERS config files.

4) Attach strace to the NFS server and see what happens when a banned and an
allowed client connect.

5) Shrug my shoulders and use iptables/netfilter instead. :-)

HTH,
Alex.
-- 
Alex Butcher, Bristol UK.                           PGP/GnuPG ID:0x5010dbff

"[T]he whole point about the reason why I think it is important we go for
identity cards and an identity database today is that identity fraud and
abuse is a major, major problem. Now the civil liberties aspect of it, look
it is a view, I don't personally think it matters very much."
  - Tony Blair, 6 June 2006 <http://www.number-10.gov.uk/output/Page9566.asp>