[OpenAFS] Code to demo NFS/UDP weakness?
Wed, 2 Aug 2006 09:15:05 -0400
an even more compelling argument for AFS over NFS or other large =20
filesystems is the way you can essentially add unlimited space by =20
simply adding servers. the steep learning curve is bringing in afs and =20
getting it into production initially. after that, it's easy to add =20
space, move volumes around, etc. and the users will Never Notice. =20
every NFS site is used to dealing with disks filling up and having =20
data outages while stuff gets moved around. same with SAN space, =20
re-doings luns, all that stuff. i am pretty sure that AFS is the only =20
large filesystems technology that lets the administrators deal with =20
adding new space, moving stuff around, replacing servers, etc. doing =20
normal admin tasks without any interruption of service to the users.
another compelling argument might be if you can show how it would =20
interact with your existing infrastructure, regarding authentication, =20
to me, a real "weakness" of nfs is how poorly it scales up compared =20
with afs and how many normal administrative operations involve outages =20
for the users.
just my $0.02
Quoting Daniel Clark <firstname.lastname@example.org>:
> I'm putting together a "NFSv3 is disgustingly insecure, we should move
> to OpenAFS" type presentation for my management . I've found
> explanations to be less than completely understood, so I've decided to
> put together a demo.
> I've already found nfsshell , a commonly available user-level
> program that among other things allows creation of NFS requests as any
> other user on a system.
> The most useful article I found on the subject  also mentions that
> "UDP is also trivial to spoof, making it easy to get around the
> host-based access control, which relies on the IP address of the
> client." Does anyone know of code that would demo this vulnerability?
>  NFSv4 isn't an option due to platform support requirements.
>  Leendert van Doorn's nfsshell
>  ;LOGIN: February 2005 pg. 17 - Rik Farrow's Musings
> Daniel Clark
> OpenAFS-info mailing list