Re: Port 135 Probes Continue

From: Nico Kadel-Garcia (nkadel_at_comcast.net)
Date: 01/17/04 

Date: Sat, 17 Jan 2004 13:19:51 -0500

"Casper H.S. ***" <Casper.***@Sun.COM> wrote in message
news:4002bbd4$0$323$e4fe514c@news.xs4all.nl...
> "Nico Kadel-Garcia" <nkadel@comcast.net> writes:
>
> >Various folks keep having to prove to Sun that NFS is not securable, that
an
> >exposed server can have its disk scribbled (though not necessarily read)
> >with a modicum of cracker effort.
>
> This is simply false; of course, if you use Linux and you're relegated
> to using a NFS implementation which does not implement any of the
> proper RPC security methods, then you can't secure your server.
> But if you use an NFS server with a complete implementation
> then you can't scribble to disks. (Your description of being able to
> write but not write leads to me believe that you're talking about using
> guessed or leaked filehandles with faked IP addresses; neither will by
> you anything on a server with proper NFS security)

No, there's a set of old issues involving guessing filehandles *without* the
need to fake IP addresses. Last I looked, Sun had never fixed this problem.
NFS filesystem security is a form of security through obscurity: while you
can't easily guess the file associated with a filesystem in a thoroughly
secured NFS system, you can guess at available filehandles and write to disk
in a random fashion, corrupting the server quite quickly. This has been
demonstrated to Sun by MIT hackers repeatedly, and at last look (admittedly
2 years ago) they had never found a solution for the fundamental problem.

And very, very few sites properly secure their NFS servers: simply running
"showmount -e servername" usually gives you more than enough information to
start an attack on vulnerable services, in particular for those sites that
do not put the extra effort into authenticating client users. And frankly,
very, very few sites do this.

> [ Description of why Kerberos is hard to setup elided ]
>
> >This is why I heartily recommend starting with AFS instead: it allows
more
> >usable group management and permissions, and is easily integrated into a
> >standard Linux distribution's file-sharing setup.
>
> Uhm, I must be missing something but isn't Kerberos the foundation
> of DCE/AFS security? In that case it really doesn't matter whether you
use
> secure NFS with GSS_API (Kerberos based) or AFS as both would seem to
> require similar security set-up.

Good point. I don't believe you have to set up a full Kerberos domain and
key server to use OpenAFS, however.

> There's no security problem with NFS other than that some implementations
> are incomplete and that "no security" is possible and much easier to
> use than "true security".

See above. There's a real problem, as I understand it, with guessing and
scribbling on accessible filehandles.

> NFSv2 and NFSv3 are not less secure than NFSv4; it's just that NFSv4
> makes the security mandatory for implementations.

Do you know *anyone* who operates NFSv4 in a home or small workplace
environment?

> NFSv2/v3 depend for security completely on the RPC layer so you will
> find little or no discussion about security in the NFSv2/v3 protocol
> specifications.

That... is a good point. But it means that, in practice, it's not there. For
a system that's going to be directly exposed to the Internet, it's
especially a problem.