From owner-freebsd-questions@FreeBSD.ORG Mon Jul 5 15:54:09 2004 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C278616A4CE for ; Mon, 5 Jul 2004 15:54:09 +0000 (GMT) Received: from mail.seekingfire.com (coyote.seekingfire.com [24.72.10.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48FA443D2F for ; Mon, 5 Jul 2004 15:54:09 +0000 (GMT) (envelope-from tillman@seekingfire.com) Received: by mail.seekingfire.com (Postfix, from userid 500) id 3A667478; Mon, 5 Jul 2004 09:54:08 -0600 (CST) Date: Mon, 5 Jul 2004 09:54:08 -0600 From: Tillman Hodgson To: freebsd-questions@freebsd.org Message-ID: <20040705155408.GD56432@seekingfire.com> References: <00ba01c460fe$d9cae910$6601a8c0@grant> <40E6FBF2.1060201@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40E6FBF2.1060201@mac.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . X-GPG-Key-ID: 828AFC7B X-GPG-Fingerprint: 5584 14BA C9EB 1524 0E68 F543 0F0A 7FBC 828A FC7B X-GPG-Key: http://www.seekingfire.com/gpg_key.asc X-Urban-Legend: There is lots of hidden information in headers User-Agent: Mutt/1.5.6i Subject: Re: NFS and Backups X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2004 15:54:10 -0000 On Sat, Jul 03, 2004 at 02:33:22PM -0400, Chuck Swiger wrote: > Grant Peel wrote: > >I have recently decided to use some extra disk space on one of my servers > >as > >backup space. I have NFS client and Servers running OK, but was wondering > >how > >secure it really is. > > NFS is not secure at all. If you don't trust the local subnet, don't use > NFS there. Certainly don't use NFS across the Internet, unless using a > secure tunnelling/VPN protocol.... > > >So if in my nfsd configuration, I specify a host called 'ahab' for example, > >how does the nfsd authenticate this host, and how secure is it? > > NFS doesn't authenticate the host. NFS trusts the resolver when reversing > the IP addr into a hostname. Even on local networks, NFS over IPsec can be a win due to the deflate algorithm. Here's some netperf results from some tests I did recently between a Celeron 900 (-STABLE) file server and an 360Mhz sparc64 Ultra 5 (-CURRENT): Raw speed, no IPsec: [root@caliban /usr/local/netperf]# ./netperf -t UDP_STREAM -H athena UDP UNIDIRECTIONAL SEND TEST to athena : histogram Socket Message Elapsed Messages Size Size Time Okay Errors Throughput bytes bytes secs # # 10^6bits/sec 9216 9216 10.01 13004 13160 95.81 42080 10.01 12778 94.14 IPsec (3des): [root@caliban /usr/local/netperf]# ./netperf -t UDP_STREAM -H secathena UDP UNIDIRECTIONAL SEND TEST to secathena : histogram Socket Message Elapsed Messages Size Size Time Okay Errors Throughput bytes bytes secs # # 10^6bits/sec 9216 9216 10.01 715 0 5.27 42080 10.01 713 5.25 IPsec (blowfish): ot@caliban ~]# /usr/local/netperf/netperf -t UDP_STREAM -H secathena UDP UNIDIRECTIONAL SEND TEST to secathena : histogram Socket Message Elapsed Messages Size Size Time Okay Errors Throughput bytes bytes secs # # 10^6bits/sec 9216 9216 10.01 14744 0 108.63 42080 10.01 3681 27.12 Blowfish is definitely preferable to 3des for IPsec work involving NFS-like traffic. Due to the deflate feature, netperf reports a result greater than the 100Mbit/s wire speed. Unfortunately, encryption speed drops off quickly as socket size increases, but 8k NFS looks like it's in good shape. Newer hardware will only nmake things better, naturally. IPsec handles the host authentication bit that NFS is pretty loose about. That still leaves the "UID is checked on the wrong end" problem, but that's very much a different problem than network level trust attacks. -T -- "That time in Seattle... was a nightmare. I came out of it dead broke, without a house, without anything except a girlfriend and a knowledge of UNIX." "Well, that's something," Avi says. "Normally those two are mutually exclusive." -- Neal Stephenson, "Cryptonomicon"