Re: nfsd support for tcp_wrapper -> General RPC solution

From: Crist J. Clark (cjclark@reflexnet.net)
Date: 02/11/01 

Date: Sat, 10 Feb 2001 18:28:01 -0800
From: "Crist J. Clark" <cjclark@reflexnet.net>
To: Alfred Perlstein <bright@wintelcom.net>

On Fri, Feb 09, 2001 at 02:56:02PM -0800, Alfred Perlstein wrote:
> * Borja Marcos <borjamar@sarenet.es> [010209 14:52] wrote:
> > Alfred Perlstein wrote:
> >
> > > This is a really flawed idea.
> >
> > Humm. Yours is a flawed reading of my message? ;-)
>
> You're right. :)
>
> > >
> > > 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.
> >
> > Yes, and what about having portmap set the right firewall
> > rules to protect RPC services? Whenever a service registers itself
> > to portmap, it puts firewall rules to block access to the port.
> > That is what I am proposing!
> >
> > Yes, NFS uses a fixed port, but not other RPC services.
>
> Well, using a firewall would work fine, but relying on obfuscation
> by just hiding portmap won't. That's where I misread what you said,
> I thought you only meant to firewall portmap, but if you can add hooks
> to portmap to run ipfw rules... that would interesting. :)

The 'right' way to do it would be to look down to the session layer at
the RPC header and examine the RPC program number for each packet. A
rule would look something like,

  # ipfw add pass ip from $OK_HOST to $RPC_SERVER rpc $RPC_SERVICE

Where $RPC_SERVICE is a number or a name from /etc/rpc.

It actually would not be terribly hard to do... not that I am
volunteering (or discounting the idea of doing it either). 

-- 
Crist J. Clark                           cjclark@alum.mit.edu
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message

Relevant Pages

  • Re: "Trying to connect" problem with RPC-HTTP
    ... 443 is the only port that needs to be opened. ... on the RPC Proxy under IIS? ... The reason that I ask is that with an internal certificate, ... > connect through the firewall. ...
    (microsoft.public.exchange.setup)
  • Re: "Trying to connect" problem with RPC-HTTP
    ... 443 is the only port that needs to be opened. ... on the RPC Proxy under IIS? ... The reason that I ask is that with an internal certificate, ... > connect through the firewall. ...
    (microsoft.public.exchange.admin)
  • Re: "Trying to connect" problem with RPC-HTTP
    ... 443 is the only port that needs to be opened. ... on the RPC Proxy under IIS? ... The reason that I ask is that with an internal certificate, ... > connect through the firewall. ...
    (microsoft.public.exchange.misc)
  • Re: "Trying to connect" problem with RPC-HTTP
    ... 443 is the only port that needs to be opened. ... on the RPC Proxy under IIS? ... The reason that I ask is that with an internal certificate, ... > connect through the firewall. ...
    (microsoft.public.exchange.connectivity)
  • 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)