[OpenAFS] Code to demo NFS/UDP weakness?

Wed, 2 Aug 2006 10:37:09 -0400

good luck with your presentation, and keep us posted! i like the =20
"here's why it makes sense financially" argument, followed by a =20
demonstration of nfs vulnerablity. just be prepared for, "oh, that's =20
so obscure, it'd never happen here....and, besides, we have =20
firewalls!"...8-)

anne

Quoting Daniel Clark <dclark@pobox.com>:

> I'm not disagreeing with any of your points, and I've brought most of
> them up myself, however they are all somewhat technical (or non-issues
> in our particular environment with enough painful planning), and from
> a nontechnical perspective "Let's just give more money to Network
> Appliance and their completely proprietary Data OnTAP OS" seems like a
> reasonable response (esp. now that some of the features you mentioned
> are being incorporated into their product line - I think they hired
> some ex-Transarc employees).
>
> On the other hand my workplace is *very* security sensitive (not
> secure so much, just sensitive ;-), so "look, a random visitor (and/or
> unauthorized employee) can jack into our network with a laptop and
> copy/modify our intellectual property, which we claim to value so
> much" seems like a better argument for my particular situation.
>
> And actually re: scale I think it's a mixed bag. OpenAFS support for
> doing things like moving volumes in the face of really big single
> volumes (multiple terabytes) seems to be iffy/slow based on reading
> random posts/bug reports (and other groups resist any changes to their
> processes, such as creating a new AFS volume per (multi-gigabyte)
> build or something like that).
>
> Also, although I've managed to nurse out performance of OpenAFS to be
> slightly greater than (untuned client) low-end netapp NFSv3
> performance by using memory cache (BTW anyone know why memcache isn't
> considered default? In my performance testing some of the filesystem
> tests were running so slowly using diskcache I had to end them
> prematurely), I doubt that it could match higher-end NFS servers/tuned
> clients in terms of raw performance on gigabit / trunked gigabit
> ethernet (we have a lot of
> copy-2GB-of-smallish-files-from-point-a-to-point-b-type use cases).
>
> Re: backups, that would actually be kind of painful/require custom
> scripting now that our backup vendor (IBM) no longer supports AFS/XBSA
> backups in the latest version of TSM (5.3). I'm thinking we'd need a
> large cheap IDE disk array to do dumps to, and then backup the dumps
> as normal files. Or a TiBS server (but that will never actually
> happen.)
>
> --
> Daniel Clark
> dclark@pobox.com
>
> On 8/2/06, Anne.Salemme@dartmouth.edu <Anne.Salemme@dartmouth.edu> wrote:
>> an even more compelling argument for AFS over NFS or other large
>> filesystems is the way you can essentially add unlimited space by
>> simply adding servers. the steep learning curve is bringing in afs and
>> getting it into production initially. after that, it's easy to add
>> space, move volumes around, etc. and the users will Never Notice.
>> every NFS site is used to dealing with disks filling up and having
>> data outages while stuff gets moved around. same with SAN space,
>> re-doings luns, all that stuff. i am pretty sure that AFS is the only
>> large filesystems technology that lets the administrators deal with
>> adding new space, moving stuff around, replacing servers, etc. doing
>> normal admin tasks without any interruption of service to the users.
>>
>> another compelling argument might be if you can show how it would
>> interact with your existing infrastructure, regarding authentication,
>> backups, etc.
>>
>> to me, a real "weakness" of nfs is how poorly it scales up compared
>> with afs and how many normal administrative operations involve outages
>> for the users.
>>
>> just my $0.02
>>
>> anne
>>
>>
>> Quoting Daniel Clark <dclark@pobox.com>:
>>
>>> I'm putting together a "NFSv3 is disgustingly insecure, we should move
>>> to OpenAFS" type presentation for my management [1]. I've found
>>> explanations to be less than completely understood, so I've decided to
>>> put together a demo.
>>>
>>> I've already found nfsshell [2], 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 [3] 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?
>>>
>>> [1] NFSv4 isn't an option due to platform support requirements.
>>>
>>> [2] Leendert van Doorn's nfsshell
>>> ftp://ftp.cs.vu.nl/pub/leendert/nfsshell.tar.gz
>>>
>>> [3] ;LOGIN: February 2005 pg. 17 - Rik Farrow's Musings
>>> http://www.usenix.org/publications/login/2005-02/pdfs/musings.pdf
>>>
>>> Thanks,
>>> --
>>> Daniel Clark
>>> dclark@pobox.com
>>> _______________________________________________
>>> OpenAFS-info mailing list
>>> OpenAFS-info@openafs.org
>>> https://lists.openafs.org/mailman/listinfo/openafs-info
>>
>>
>> _______________________________________________
>> OpenAFS-info mailing list
>> OpenAFS-info@openafs.org
>> https://lists.openafs.org/mailman/listinfo/openafs-info
>>
>>
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info