Re: tcpwrapped rpcbind/portmap?

From: Brian Parent (bparent@calvin.ucsd.edu)
Date: 08/23/01 

Date: Wed, 22 Aug 2001 15:57:16 -0700
From: Brian Parent <bparent@calvin.ucsd.edu>
To: "'focus-sun@securityfocus.com'" <focus-sun@securityfocus.com>
Subject: Re: tcpwrapped rpcbind/portmap?
Message-ID: <20010822155716.J7949@calvin.ucsd.edu>

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: strange NFS failure
    ... > mapper failure - ... > RPC: Unable to recieve ... > and yes rpcbind is running OK. ...
    (freebsd-stable)
  • RE: tcpwrapped rpcbind/portmap?
    ... libwrap.a and it listens on UDP and TCP ports 111, ... are UDP connects to rpcbind wrapped? ... > attacks of individual rpc services, it merely makes it a bit ... > One concern I have is that Sun recently released a security ...
    (Focus-SUN)
  • 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)