tcp wrappers and rpc.statd
Paul Lussier
p.lussier at comcast.net
Wed Aug 2 05:29:01 EDT 2006
Hi all,
Has anyone ever used tcp wrappers to explicitly control access to rpc.statd?
The man page for statd (at least on Debian) states that:
TCP_WRAPPERS SUPPORT
This rpc.statd version is protected by the tcp_wrapper
library. You have to give the clients access to rpc.statd if they
should be allowed to use it. To allow connects from clients of
the .bar.com domain you could use the following line in
/etc/hosts.allow:
statd: .bar.com
You have to use the daemon name statd for the daemon name (even if
the binary has a different name).
For further information please have a look at the tcpd(8) and
hosts_access(5) manual pages.
So, theoretically, it appears that just placing a line like this in
/etc/hosts.allow should do what I want:
statd: 10.0.123.0/255.255.255.0, 10.0.124.0/255.255.255.0
Yet, there's nothing anywhere that I can see that ever invokes tcpd to
wrap around the execution of statd. I'm quite familiar with wrapping
a daemon exec'ed from within inetd where you write something like:
finger stream tcp nowait nobody /usr/sbin/tcpd /usr/sbin/in.fingerd
Doing on nmap of the system in question shows statd running when
probing the 10.0.20.31 interface. Adding the line to /etc/hosts.allow
does nothing. But when I hack the init.d script to "wrap" statd with
tcpd, things seemt to work as expected. Unfortunately, to do *that*
means I also have to shove it in the background with & which means
that the init script doesn't work for stop or restart for some reason
(haven't investigated this part too much). However, wrapping it like
this does in fact prevent statd from being seen on any interface
except those on 10.0.2[34].X .
Any ideas?
--
Seeya,
Paul
More information about the gnhlug-discuss
mailing list