RE: tcpwrapped rpcbind/portmap?

From: David LaPorte (dave@laportestyle.org)
Date: 08/23/01


From: "David LaPorte" <dave@laportestyle.org>
To: "'Brian Parent'" <bparent@calvin.ucsd.edu>, <focus-sun@securityfocus.com>
Subject: RE: tcpwrapped rpcbind/portmap?
Date: Wed, 22 Aug 2001 22:00:56 -0400
Message-ID: <003901c12b77$72704ef0$f6f4dc40@harvard.edu>

I have a somewhat related question. I know Weitse's rpcbind links to
libwrap.a and it listens on UDP and TCP ports 111, but I have always
been under the impression that libwrap.a could only wrap TCP-based
services. If that's the case (and please correct me if I'm wrong), how
are UDP connects to rpcbind wrapped?

[root@jojo /root]# lsof -P | grep 111
rpcbind 275 root 3u IPv4 0x300003e71c0 0t0 UDP *:111
(Idle)
rpcbind 275 root 6u IPv4 0x3000093f6e8 0t0 TCP *:111
(LISTEN)

Thanks!
Dave LaPorte
dave@laportestyle.org

> -----Original Message-----
> From: Brian Parent [mailto:bparent@calvin.ucsd.edu]
> Sent: Wednesday, August 22, 2001 6:57 PM
> To: 'focus-sun@securityfocus.com'
> Subject: Re: tcpwrapped rpcbind/portmap?
>
>
> A wrapped version of rpcbind does *not* prevent remote
> attacks of individual rpc services, it merely makes it a bit
> more difficult to determine which rpc port numbers your
> services are at.
>
> Yet if it is available, it doesn't hurt to use it. Maybe.
>
> One concern I have is that Sun recently released a security
> patch for rpcbind. If Weitse's tcpwrap enabled rpcbind was
> based on Sun code (pre-security patch), then it is possible
> that you could unwittingly increase your level of
> vulnerability by using it. I'd like to believe that Weitse's
> code was closely scrutinzed, and has no such security
> problem. Can anyone confirm/contradict this?
>
> Re:
> > From: Geoff Collis <geoff@andale.com>
> > To: "'Casper Dik'" <Casper.Dik@Sun.COM>,
> > "'focus-sun@securityfocus.com'"
> <focus-sun@securityfocus.com>
> > Subject: RE: tcpwrapped rpcbind/portmap?
> > Date: Tue, 21 Aug 2001 10:34:15 -0700
> >
> > Regardless of the merits or otherwise I need to rpcbind to
> support the
> > reading/writing files stored on a NetApp NFS file server.
> There may be
> > better alternatives, but these are not going to work with
> the hardware
> > we have.
> >
> > On Solaris 2.6 and 7 I would handle this scenario by installing
> > ipfilter, to restrict access to the local subnet, and use the
> > tcp-wrapped version of rpcbind to make sure RPC will only work with
> > hosts on the local subnet. Mistakes happen so I prefer to have two
> > level of *access restriction* rather than rely totally on
> the ipfilter
> > rules. :-)
> >
> > I do not have any intention of running NIS or NIS+.
> >
> > So I would like to have tcp-wrapped versions of rpcbind/portmap for
> > Solaris 8, but I have to confess I do not know the internal
> details of
> > RPC, so there may be better alternative solutions.
> >
> > - Geoff
> >
> > -----Original Message-----
> > From: Casper Dik [mailto:Casper.Dik@Sun.COM]
> > Sent: Saturday, August 18, 2001 2:23 PM
> > To: Geoff Collis
> > Cc: 'Reg Quinton'; 'focus-sun@securityfocus.com'
> > Subject: Re: tcpwrapped rpcbind/portmap?
> >
> > He,, we were all at Usenix security in Washington !
> >
> > File locking does require RPCbind on the client, but I suppose you
> > could be fine without it.
> >
> > Wouldl it be a good idea to have a "safer" rpcbind in Solaris?
> >
> > If so, what would "safer" mean?
> > o Not listening to the world at all optionally)
> > o No indirect calls (optionally)
> > o "wrapped" functionality.
> >
> > And which would you like best?
> >
> > In principle, option 2 would do away with most uncertainty about
> > rpcbind security.
> >
> > Casper
> >
>



Relevant Pages

  • Re: NFS Over Private Network
    ... >with the version of rpcbind on production systems. ... >allow NFS due to the many security issues associated with it. ... As for NFS security issues: in reality there are none if you don't ... With DH Secure RPC ...
    (Focus-SUN)
  • Re: tcpwrapped rpcbind/portmap?
    ... A wrapped version of rpcbind does *not* prevent remote attacks ... of individual rpc services, it merely makes it a bit more difficult ... to determine which rpc port numbers your services are at. ... One concern I have is that Sun recently released a security patch ...
    (Focus-SUN)
  • RE: strange NFS failure
    ... > mapper failure - ... > RPC: Unable to recieve ... > and yes rpcbind is running OK. ...
    (freebsd-stable)
  • Re: RPC: Rpcbind failure (NFS)
    ... I assumed RPC was started by inetd. ... rpcbind is a name server, so you must start rpc services after rpcbind. ...
    (comp.unix.solaris)