Re: nfsd support for tcp_wrapper -> General RPC solution

From: Alfred Perlstein (bright@wintelcom.net)
Date: 02/09/01 

Date: Fri, 9 Feb 2001 13:36:15 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: Borja Marcos <borjamar@sarenet.es>

* Borja Marcos <borjamar@sarenet.es> [010209 02:41] wrote:
> Gerald Pfeifer wrote:
> >
> > On Tue, 30 Jan 2001, Alfred Perlstein wrote:
> > >> Or are we just missing something?
> > > Missing the fact that nfsd is an in-kernel process and therefore
> > > pretty hard to link against libwrap.
> >
> > Hard, or impossible? ;-)
>
> Well, nfsd must serve requests at high speed. Having it
> call TCP Wrapper can be a big overhead, depending on how you have
> configured /etc/hosts.allow and /etc/hosts.deny
>
> I was thinking about a different (and general) solution, but I
> have had no time to implement it. Perhaps I will try to find some time.
>
> The trick is to use the portmapper with TCP Wrapper with a slight
> twist. You keep a set of firewall (ipfw or ipfilter) rules in a file,
> and whenever portmap receives the RPC service registration from the
> daemon, it "runs" the ipfw or ipfilter configuration
> script passing it the port number where the service has registered.
>
> This provides good protection for *any* RPC service,
> you don't need to tinker with RPC daemons -only the portmapper-
> and the overhead is minimal: only a call to the TCP Wrapper library
> whenever a service registers itself to the portmapper.

This is a really flawed idea.

All portmap does is provide a name/version/protocol mapping of a
service to a tcp/udp port. One can trivially do a portscan of
a box running RPC services and figure out which are open. You
don't need portmap to brute force finding out where a remote
vulnerable service is located.

In fact because afaik NFS always uses a well known port, you really
don't need portmap to map it, you just need to use the port,
portmapper for NFS is just a formality.

Ok, with that out of the window, we _could_ consider mucking userland
mountd to use tcpwrappers to graft an ACL to what's in /etc/exports.
This is also a bad idea, one can just brute force the NFS
cookie/filehandle required to gain access, then contact the NFS
port.

The solution is to use a firewall. 

-- 
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message

Relevant Pages

  • Re: NFS Failover
    ... How do I check portmap is running on port 111? ... I would assume NFS wouldn't run first place (before failover to ... Do you have portmap (a.k.a. sunrpc) running on port 111? ...
    (linux.redhat)
  • Re: NFS Failover
    ... How do I check portmap is running on port 111? ... I would assume NFS wouldn't run first place (before failover to ... Do you have portmap (a.k.a. sunrpc) running on port 111? ...
    (linux.redhat)
  • Re: nfsd support for tcp_wrapper -> General RPC solution
    ... >> In fact because afaik NFS always uses a well known port, ... >> portmapper for NFS is just a formality. ... > to portmap, it puts firewall rules to block access to the port. ...
    (FreeBSD-Security)
  • Re: nfsd support for tcp_wrapper -> General RPC solution
    ... > service to a tcp/udp port. ... > don't need portmap to brute force finding out where a remote ... the brute force portscan will have no success. ... > portmapper for NFS is just a formality. ...
    (FreeBSD-Security)
  • [discuss] portmapping sucks
    ... Linux and UNIX (perhaps blame SUN for inventing portmap?) ... services are at a fixed RPC port number which are mapped ... This random TCP/UDP port selection is what makes it suck. ...
    (Linux-Kernel)