From owner-freebsd-security@FreeBSD.ORG Sun Jan 29 02:29:47 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE6B916A420 for ; Sun, 29 Jan 2006 02:29:47 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0DC0143D46 for ; Sun, 29 Jan 2006 02:29:46 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail02.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k0T2Ti5J020367 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 29 Jan 2006 13:29:45 +1100 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.4/8.13.4) with ESMTP id k0T2TiJ6004950; Sun, 29 Jan 2006 13:29:44 +1100 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.4/8.13.4/Submit) id k0T2Thcu004949; Sun, 29 Jan 2006 13:29:43 +1100 (EST) (envelope-from peter) Date: Sun, 29 Jan 2006 13:29:43 +1100 From: Peter Jeremy To: Christian Baer Message-ID: <20060129022943.GJ2341@turion.vk2pj.dyndns.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: freebsd-security@freebsd.org Subject: Re: Should I use gbde or geli? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2006 02:29:47 -0000 On Sat, 2006-Jan-28 19:34:49 +0100, Christian Baer wrote: >For a friend of mine I am thinking up a fileserver for his own little >company that contains *very* sensitive information (mainly stuff that is >still in developement or on the way of a patent or something like that). Security is not an absolute - it's a cost/benefit analysis. Your friend needs to consider the value of his data, who is likely to want to steal it and what resources they have available. I suggest you have a read of some of (eg) Bruce Schneier's recent books. >Attempts have been made to get at this data the "hard way". The only >thing that hasn't happened so far is someone coming into the office with >a gun and saying "Stick 'em up!". :-) With virtually any modern, properly implemented crypto solution, the weaknesses in the system are going to be human not technical. Your friend is far more likely to have his data stolen via a disgruntled employee, a secretary being conned into giving out the password, spyware copying the unencrypted data or someone arriving with a gun. Have a close look at what has access to the data when it is unencrypted - it's far easier to steal this way than having to break the encryption. >1. >The file system (or rather the encryption) itself must be as secure as >possible. gbde uses 128bit AES with a different key for every sector, >geli uses up to 256bit AES with the same key all the time. geli also >supports blowfish. Which one of these approaches is more secure? geli is >newer but that doesn't say much for itself. Realistically, neither are going to fall to a brute force attack in the near future. Both use AES so a break in AES is likely to equally affect both (though a partial break would have a bigger impact on 128-bit AES). You probably need to spend more time thinking about the passphrase that you use to secure the master key - unless that has at least 128 (or 256) bits of entropy, it will be quicker to break the master key. >5. >The ideal protection would be to keep the server running[2] and have it >connected to the alarm system, so when the alarm is tripped, the server >destroys its master-keys and renders the information useless. You need to take into account the likelihood of the alarm system false triggering or a burglar stealing the computer without setting off the alarm. You might find it easier to protect the master keys with a (volatile) passphrase and rely on adequate protection of the passphrase. (You might also consider looking up "secret sharing" "threshold system"). >After considering this, am I better off with gbde or geli? Have I missed >anything in my little list? How will backups be protected? -- Peter Jeremy From owner-freebsd-security@FreeBSD.ORG Sun Jan 29 11:13:33 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9BA3C16A420 for ; Sun, 29 Jan 2006 11:13:33 +0000 (GMT) (envelope-from freebsd-security@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4045F43D77 for ; Sun, 29 Jan 2006 11:13:25 +0000 (GMT) (envelope-from freebsd-security@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1F3AUm-0006Gw-3N for freebsd-security@freebsd.org; Sun, 29 Jan 2006 12:13:24 +0100 Received: from p508c1476.dip0.t-ipconnect.de ([80.140.20.118]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 29 Jan 2006 12:13:24 +0100 Received: from christian.baer by p508c1476.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 29 Jan 2006 12:13:24 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-security@freebsd.org From: Christian Baer Date: Sun, 29 Jan 2006 12:10:34 +0100 (CET) Organization: Convenimus Projekt Lines: 115 Message-ID: References: <20060129022943.GJ2341@turion.vk2pj.dyndns.org> X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: p508c1476.dip0.t-ipconnect.de User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Subject: Re: Should I use gbde or geli? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2006 11:13:33 -0000 On Sun, 29 Jan 2006 13:29:43 +1100 Peter Jeremy wrote: > Security is not an absolute - it's a cost/benefit analysis. I know that and it's something I "feel" every day. I have a rather long pass-phrase for my gpg-key, which is a real pain to type sometimes. This pain is the downside (cost) of security. And is something I have taken into consideration. We may have to work on workflows for a while when we try to perfect the security while still leaving the actual work as uninfluence as possible, but that is a completely different problem. > Your friend needs to consider the value of his data, who is likely to > want to steal it and what resources they have available. I suggest > you have a read of some of (eg) Bruce Schneier's recent books. I am reading up on the basics of this subject. However, the theory doesn't really cover too much of the practical sides like the real differences between approaches or even gbde and geli. > With virtually any modern, properly implemented crypto solution, the > weaknesses in the system are going to be human not technical. Your > friend is far more likely to have his data stolen via a disgruntled > employee, a secretary being conned into giving out the password, > spyware copying the unencrypted data or someone arriving with a gun. > Have a close look at what has access to the data when it is > unencrypted - it's far easier to steal this way than having to break > the encryption. Human failure can never be ruled out, if you can call being forced to do something at gunpoint a "failure". But we went through a lot of scenarios and some are just more unlikely than others. Taking something by force (the gun-idea) is a very different crime than stealing something during a break-in. Getting away with a break-in seems far more likely than getting away with a crime that includes violence. So to our consideration, it is far more likely that someone actually tries to steal the information rather than take it by force. As silly as it may seem, we believe that there are certain lines that the competitors just won't cross. We are talking about Germany, not the United States. With all that said, we are still looking for a maximum of security for the information. Workflows are being optimized - some have already been changed to be more secure - but so far we also want to rule out a technical flaw, or rather a weakness in the chain cause by such a flaw. The actual keys and pass-phrases will only be known to the two bosses of the firm and to myself (which btw. wasn't my idea). Forcing the secretary hand out the pass-phrase is therefore not really helpful (because she doesn't have it), but I guess you could still threaten the families of my friend or his partner. I know that a trusted employee can always turn on you. But for the moment let's assume that they will not do so und thus will not willingly hand over or sell sensitive information. One of the aces we may have is the fact that noone (including the employees) will know that the information is encrypted. This way a theft could look more promising and if it succeeds the thief will find out that what he stole is worthless (apart from the hardware itself). > Realistically, neither are going to fall to a brute force attack in the > near future. Both use AES so a break in AES is likely to equally affect > both (though a partial break would have a bigger impact on 128-bit AES). > You probably need to spend more time thinking about the passphrase that > you use to secure the master key - unless that has at least 128 (or 256) > bits of entropy, it will be quicker to break the master key. The pass-phrase consists of a string of characters with a length of about 1024 bytes. It hasn't actually been generated yet but the plans are to create a long string of entropy (something like 800 bytes) and then a part that can be memorized. This way the idea of "something you have" and "something you know" can be used. This seems a little oversized, because the anount of possible character-combinations is much larger than the amount of the hash's combinations but in case for some reason the hash is broken and some of the pass-phrase's characters are known, there are plenty of permutations to try so brute force shouldn't even work in that case. We have been talking of AES all the time. How secure is blowfish? It's open source but not too well analysed so far. Can you say something about that. I have a problem trusting something that the NSA suggests, as there is always the possibility of a flaw in that. I know, some wild conspiricy, but worth a consideration at least. > You need to take into account the likelihood of the alarm system false > triggering or a burglar stealing the computer without setting off the > alarm. You might find it easier to protect the master keys with a > (volatile) passphrase and rely on adequate protection of the > passphrase. (You might also consider looking up "secret sharing" > "threshold system"). I'm not really sure where you're going with this volatile pass-phrase. Both gbde and geli (AFAIK) don't save the pass-phrase on the disc. So they are by definition volatile. If some burglar were to steal the computer it most likely would be cut off from power. This way the discs would be "cold" and the information safe. The bigger risk would be the burglar copying the information. Or am I missing the point here? >>After considering this, am I better off with gbde or geli? Have I missed >>anything in my little list? > How will backups be protected? I have only thought up a method, now a complete solution (which would include choosing the software). The idea is to use a software similar to truecrypt. The backups would be made in some sort of container and then copied to DVD-RAM. After that the backups would be locked away. Regards Chris From owner-freebsd-security@FreeBSD.ORG Sun Jan 29 15:43:01 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B620E16A420 for ; Sun, 29 Jan 2006 15:43:01 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id F115143D49 for ; Sun, 29 Jan 2006 15:43:00 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5DAD2.dip.t-dialin.net [84.165.218.210]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.1/8.13.1) with ESMTP id k0TFY04W062260; Sun, 29 Jan 2006 16:34:01 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) by Andro-Beta.Leidinger.net (8.13.3/8.13.3) with ESMTP id k0TFgtp6063962; Sun, 29 Jan 2006 16:42:56 +0100 (CET) (envelope-from Alexander@Leidinger.net) Date: Sun, 29 Jan 2006 16:42:55 +0100 From: Alexander Leidinger To: Christian Baer Message-ID: <20060129164255.32d7722a@Magellan.Leidinger.net> In-Reply-To: References: <20060129022943.GJ2341@turion.vk2pj.dyndns.org> X-Mailer: Sylpheed-Claws 1.9.100 (GTK+ 2.8.11; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Mailman-Approved-At: Sun, 29 Jan 2006 15:59:01 +0000 Cc: freebsd-security@freebsd.org Subject: Re: Should I use gbde or geli? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2006 15:43:01 -0000 On Sun, 29 Jan 2006 12:10:34 +0100 (CET) Christian Baer wrote: > One of the aces we may have is the fact that noone (including the > employees) will know that the information is encrypted. This way a theft Too late now. You already revealed this information into the public. Google will be able to tell the well prepared burglar about this. > could look more promising and if it succeeds the thief will find out > that what he stole is worthless (apart from the hardware itself). > We have been talking of AES all the time. How secure is blowfish? It's > open source but not too well analysed so far. Can you say something > about that. I have a problem trusting something that the NSA suggests, > as there is always the possibility of a flaw in that. I know, some wild > conspiricy, but worth a consideration at least. AFAIR Blowfish was one the main algorithms which had a lot of potential to get the AES sign, but in the end Rijndael won. I think it won because of some resource aspects, not because of security aspects. But I may be wrong with this. > > You need to take into account the likelihood of the alarm system false > > triggering or a burglar stealing the computer without setting off the > > alarm. You might find it easier to protect the master keys with a > > (volatile) passphrase and rely on adequate protection of the > > passphrase. (You might also consider looking up "secret sharing" > > "threshold system"). > > I'm not really sure where you're going with this volatile pass-phrase. > Both gbde and geli (AFAIK) don't save the pass-phrase on the disc. So > they are by definition volatile. If some burglar were to steal the > computer it most likely would be cut off from power. This way the discs > would be "cold" and the information safe. The bigger risk would be the > burglar copying the information. > > Or am I missing the point here? Think about one-time passwords. Bye, Alexander. -- Actually, Microsoft is sort of a mixture between the Borg and the Ferengi. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 WL http://www.amazon.de/exec/obidos/registry/1FZ4DTHQE9PQ8/ref=wl_em_to/ From owner-freebsd-security@FreeBSD.ORG Sun Jan 29 18:35:15 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9F4416A420 for ; Sun, 29 Jan 2006 18:35:15 +0000 (GMT) (envelope-from freebsd-security@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7237743D46 for ; Sun, 29 Jan 2006 18:35:14 +0000 (GMT) (envelope-from freebsd-security@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1F3HO9-0005nM-WE for freebsd-security@freebsd.org; Sun, 29 Jan 2006 19:35:02 +0100 Received: from p508c1476.dip0.t-ipconnect.de ([80.140.20.118]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 29 Jan 2006 19:35:01 +0100 Received: from christian.baer by p508c1476.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 29 Jan 2006 19:35:01 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-security@freebsd.org From: Christian Baer Date: Sun, 29 Jan 2006 18:59:39 +0100 (CET) Organization: Convenimus Projekt Lines: 29 Message-ID: References: <20060129022943.GJ2341@turion.vk2pj.dyndns.org> <20060129164255.32d7722a@Magellan.Leidinger.net> X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: p508c1476.dip0.t-ipconnect.de User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Subject: Re: Should I use gbde or geli? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2006 18:35:16 -0000 On Sun, 29 Jan 2006 16:42:55 +0100 Alexander Leidinger wrote: >> One of the aces we may have is the fact that noone (including the >> employees) will know that the information is encrypted. This way a theft > Too late now. You already revealed this information into the public. > Google will be able to tell the well prepared burglar about this. Well, not really. Noone knows what company we are talking about and since my name is never mentioned in conjunction with this company, a possible thief may know that *I* am doing something but not for who. I'm not *that* thick. :-) > AFAIR Blowfish was one the main algorithms which had a lot of potential > to get the AES sign, but in the end Rijndael won. I think it won > because of some resource aspects, not because of security aspects. But > I may be wrong with this. Actually, it wasn't Blowfish but Twofish, which is supposed to be the successer. Too bad Serpant doesn't work with GELI (yet). :-) >> Or am I missing the point here? > Think about one-time passwords. That could limit the resources a little to much as those people with access require it at a regular basis. Regards Chris From owner-freebsd-security@FreeBSD.ORG Sun Jan 29 19:17:03 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B243816A422 for ; Sun, 29 Jan 2006 19:17:03 +0000 (GMT) (envelope-from arne_woerner@yahoo.com) Received: from web30313.mail.mud.yahoo.com (web30313.mail.mud.yahoo.com [68.142.201.231]) by mx1.FreeBSD.org (Postfix) with SMTP id 4B4CD43D49 for ; Sun, 29 Jan 2006 19:17:03 +0000 (GMT) (envelope-from arne_woerner@yahoo.com) Received: (qmail 36012 invoked by uid 60001); 29 Jan 2006 19:17:02 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=PfctjgNaXy+720p9Z4hmXLxAMHq/NsXLCGcB4l0ClBgn06UakyTMx8fE9Xe8JWStHiHTuSLTcHZFl/BVFf2CCEVrJCGsgHDjq8oLCdOVetNmeJ1aKqkXu99CIgwnqCxNqdQg1Q09w98fZ8lwoJod/syJFawGkKNh3/Ysgsrk69w= ; Message-ID: <20060129191702.36010.qmail@web30313.mail.mud.yahoo.com> Received: from [213.54.67.31] by web30313.mail.mud.yahoo.com via HTTP; Sun, 29 Jan 2006 11:17:02 PST Date: Sun, 29 Jan 2006 11:17:02 -0800 (PST) From: Arne Woerner To: Christian Baer , freebsd-security@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Re: Should I use gbde or geli? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2006 19:17:03 -0000 --- Christian Baer wrote: > The idea is to use a software similar to > truecrypt. The backups would be made in > some sort of container and then copied to > DVD-RAM. After that the backups would be > locked away. > Hiho Christian! I have heard of kidnapping in Altenholz, SH, F.Rep.GERM (the family was held as hostage and the father was supposed to open the safe of his bank but than he thought he was already there and exited the car and the robbers/kidnappers disappeared and then the state attorney looked like the kidnappers)... I wonder why the discs should not be protected like the backups... Can't u put the discs with sensitive data into a box, that can be locked down? I mean: Just trying to implement a physically safe environment should be enough... Passwords (the legislative of F.Rep.GERM likes/demands them) are not so funny, because the employees should be ordered to tell them everybody who wants to know them (this reminds me on my time in a formerly known to be state-owned building where we found an Operation Procedure about questions one should ask, if a bomb-threat enters via voice call through a german telecom net)... A former pölice officer or so might be good for physical security, too. It might be interesting to look at the protocols, that u use to access the sensitive data... I mean: When u use NFS just with IP-based authentication, nobody needs the discs, because one could put an evil NFS client with a specially crafted IP address into the network... Bye Arne __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-security@FreeBSD.ORG Mon Jan 30 07:39:39 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4391B16A420 for ; Mon, 30 Jan 2006 07:39:39 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8582C43D48 for ; Mon, 30 Jan 2006 07:39:38 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail11.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k0U7daMP029935 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 30 Jan 2006 18:39:36 +1100 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.4/8.13.4) with ESMTP id k0U7daFl000781 for ; Mon, 30 Jan 2006 18:39:36 +1100 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.4/8.13.4/Submit) id k0U7dabK000780 for freebsd-security@freebsd.org; Mon, 30 Jan 2006 18:39:36 +1100 (EST) (envelope-from peter) Date: Mon, 30 Jan 2006 18:39:36 +1100 From: Peter Jeremy To: freebsd-security@freebsd.org Message-ID: <20060130073935.GA702@turion.vk2pj.dyndns.org> References: <20060129022943.GJ2341@turion.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Subject: Re: Should I use gbde or geli? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2006 07:39:39 -0000 On Sun, 2006-Jan-29 12:10:34 +0100, Christian Baer wrote: >On Sun, 29 Jan 2006 13:29:43 +1100 Peter Jeremy wrote: >I am reading up on the basics of this subject. However, the theory >doesn't really cover too much of the practical sides like the real >differences between approaches or even gbde and geli. Unfortunately, no-one with that knowledge has popped up. You could try writing to the authors of gbde and geli and ask their opinions. >Human failure can never be ruled out, if you can call being forced to do >something at gunpoint a "failure". If an attacker gets away with the data, by whatever means, then the security system has failed. If you considered armed robbery a likely situation (which you've ruled out), then you would need to protect against it. >One of the aces we may have is the fact that noone (including the >employees) will know that the information is encrypted. Actually, even though you haven't mentioned the company, someone with the resources to consider breaking AES would probably not find it too difficult to find the company's name. You _have_ admitted that you are one of the people who knows the passphrase. >We have been talking of AES all the time. How secure is blowfish? It's >open source but not too well analysed so far. Can you say something >about that. I have a problem trusting something that the NSA suggests, >as there is always the possibility of a flaw in that. I know, some wild >conspiricy, but worth a consideration at least. The AES algorithm and its design principles are all public (and the algorithm was developed outside the US). It has been through a rigorous examination by the crypto community and the open community haven't found any problems. Obviously, we don't know what the NSA (and other spook agencies) found but NSA has two primary functions: Protecting US information from prying eyes (promoting strong, unbreakable crypto) and decrypting the rest of the world's secrets (promoting weak crypto). The crypto experts I've spoken to believe that AES is the result of the former group and if NSA found any weaknesses, they would have killed it. Keep in mind that (despite the paranoia) DES _was_ secure and the S-box construction was kept secret because it was designed to protect against differential crytanalysis - which was not a publicly known technique at the time. I suggest you look up the sci.crypt FAQ. >> alarm. You might find it easier to protect the master keys with a >> (volatile) passphrase and rely on adequate protection of the >> passphrase. (You might also consider looking up "secret sharing" >> "threshold system"). > >I'm not really sure where you're going with this volatile pass-phrase. You were talking about automatically destroying the master key (which makes recovering the data difficult). I'm suggesting that you rely on protecting the master key so it can't be recovered, even if the disc is stolen. > If some burglar were to steal the >computer it most likely would be cut off from power. If I knew that the computer had sensitive information that would be lost to me if the computer got powered off, I would ensure that the computer didn't lose power whilst I was stealing it. Maybe I can steal the UPS with the computer. If not, I could try opening the case and paralleling my own supply. -- Peter Jeremy From owner-freebsd-security@FreeBSD.ORG Mon Jan 30 20:39:56 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF95C16A420 for ; Mon, 30 Jan 2006 20:39:56 +0000 (GMT) (envelope-from duane@greenmeadow.ca) Received: from smtpout.eastlink.ca (smtpout.eastlink.ca [24.222.0.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F14D43D45 for ; Mon, 30 Jan 2006 20:39:56 +0000 (GMT) (envelope-from duane@greenmeadow.ca) Received: from ip04.eastlink.ca ([24.222.10.20]) by mta01.eastlink.ca (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0ITX001HQAPG7TC0@mta01.eastlink.ca> for freebsd-security@freebsd.org; Mon, 30 Jan 2006 16:39:16 -0400 (AST) Received: from blk-224-199-230.eastlink.ca (HELO [192.168.0.101]) ([24.224.199.230]) by ip04.eastlink.ca with ESMTP; Mon, 30 Jan 2006 16:39:55 -0400 Date: Mon, 30 Jan 2006 16:39:55 -0400 From: Duane Whitty To: freebsd-security@freebsd.org Message-id: <43DE799B.40103@greenmeadow.ca> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAQAAA+k= User-Agent: Thunderbird 1.5 (Windows/20051201) Subject: Is CVS security on topic for this list? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-security@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2006 20:39:56 -0000 Hi everyone, I'm wondering about the security implications of running a CVS server with group write permission on the repository and various other configuration details. Is this an appropriate discussion for this list? If it is I have a setup I'd like some feedback on. If this is not the appropriate list please accept my apologies for the distraction. Best Regards, --Duane Whitty duane@greenmeadow.ca From owner-freebsd-security@FreeBSD.ORG Tue Jan 31 05:37:52 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6757916A420 for ; Tue, 31 Jan 2006 05:37:52 +0000 (GMT) (envelope-from darren.pilgrim@bitfreak.org) Received: from mail.bitfreak.org (mail.bitfreak.org [65.75.198.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id 18F7743D49 for ; Tue, 31 Jan 2006 05:37:51 +0000 (GMT) (envelope-from darren.pilgrim@bitfreak.org) Received: from smiley (mail.bitfreak.org [65.75.198.146]) by mail.bitfreak.org (Postfix) with ESMTP id 96DE319F40; Mon, 30 Jan 2006 21:37:48 -0800 (PST) From: "Darren Pilgrim" To: Date: Mon, 30 Jan 2006 21:37:45 -0800 Message-ID: <003101c62628$79daaf40$672a15ac@smiley> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <43DE799B.40103@greenmeadow.ca> Importance: Normal Cc: freebsd-security@freebsd.org Subject: RE: Is CVS security on topic for this list? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2006 05:37:52 -0000 From: Duane Whitty > > I'm wondering about the security implications of running a CVS server > with group write permission on the repository and various other > configuration details. Is this an appropriate discussion for this > list? If it is I have a setup I'd like some feedback on. If this is > not the appropriate list please accept my apologies for the > distraction. If you're running on FreeBSD and want to discuss the security implications of your configuration, I would say yes. If it were, me, however, I'd probably try my luck on the GNU CVS mailing lists[1] first. Specifically, the info-cvs list. [1] http://savannah.nongnu.org/mail/?group=cvs From owner-freebsd-security@FreeBSD.ORG Tue Jan 31 06:10:43 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A53B816A420 for ; Tue, 31 Jan 2006 06:10:43 +0000 (GMT) (envelope-from duane@greenmeadow.ca) Received: from smtpout.eastlink.ca (smtpout.eastlink.ca [24.222.0.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19A0F43D46 for ; Tue, 31 Jan 2006 06:10:42 +0000 (GMT) (envelope-from duane@greenmeadow.ca) Received: from ip02.eastlink.ca ([24.222.10.10]) by mta01.eastlink.ca (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0ITY0013T14Q7V61@mta01.eastlink.ca> for freebsd-security@freebsd.org; Tue, 31 Jan 2006 02:10:02 -0400 (AST) Received: from blk-224-199-230.eastlink.ca (HELO [192.168.0.101]) ([24.224.199.230]) by ip02.eastlink.ca with ESMTP; Tue, 31 Jan 2006 02:10:42 -0400 Date: Tue, 31 Jan 2006 02:10:39 +0000 From: Duane Whitty In-reply-to: <003101c62628$79daaf40$672a15ac@smiley> To: freebsd-security@freebsd.org Message-id: <43DEC71F.1020101@greenmeadow.ca> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAQAAA+k= References: <003101c62628$79daaf40$672a15ac@smiley> User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060120 Subject: Re: Is CVS security on topic for this list? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2006 06:10:43 -0000 Darren Pilgrim wrote: > From: Duane Whitty > >>I'm wondering about the security implications of running a CVS server >>with group write permission on the repository and various other >>configuration details. Is this an appropriate discussion for this >>list? If it is I have a setup I'd like some feedback on. If this is >>not the appropriate list please accept my apologies for the >>distraction. > > > If you're running on FreeBSD and want to discuss the security implications > of your configuration, I would say yes. If it were, me, however, I'd > probably try my luck on the GNU CVS mailing lists[1] first. Specifically, > the info-cvs list. > > [1] http://savannah.nongnu.org/mail/?group=cvs > > > > > Hi everyone, Well my subject then probably is on topic but first I will familiarize myself with some of the GNU CVS mailing lists. Darren, thanks for the great link. --Best Regards Duane Whitty From owner-freebsd-security@FreeBSD.ORG Wed Feb 1 19:51:47 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E61B16A422; Wed, 1 Feb 2006 19:51:47 +0000 (GMT) (envelope-from security-advisories@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id F057143D5C; Wed, 1 Feb 2006 19:51:45 +0000 (GMT) (envelope-from security-advisories@freebsd.org) Received: from freefall.freebsd.org (cperciva@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k11Jpjxo008505; Wed, 1 Feb 2006 19:51:45 GMT (envelope-from security-advisories@freebsd.org) Received: (from cperciva@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k11JpjWo008503; Wed, 1 Feb 2006 19:51:45 GMT (envelope-from security-advisories@freebsd.org) Date: Wed, 1 Feb 2006 19:51:45 GMT Message-Id: <200602011951.k11JpjWo008503@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: cperciva set sender to security-advisories@freebsd.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Precedence: bulk Cc: Subject: FreeBSD Security Advisory FreeBSD-SA-06:08.sack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Reply-To: security-advisories@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2006 19:51:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-06:08.sack Security Advisory The FreeBSD Project Topic: Infinite loop in SACK handling Category: core Module: netinet Announced: 2006-02-01 Credits: Scott Wood Affects: FreeBSD 5.3 and 5.4 Corrected: 2006-01-24 01:16:18 UTC (RELENG_5, 5.4-STABLE) 2006-02-01 19:43:10 UTC (RELENG_5_4, 5.4-RELEASE-p11) 2006-02-01 19:43:36 UTC (RELENG_5_3, 5.3-RELEASE-p26) CVE Name: CVE-2006-0433 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background SACK (Selective Acknowledgement) is an extension to the TCP/IP protocol that allows hosts to acknowledge the receipt of some, but not all, of the packets sent, thereby reducing the cost of retransmissions. II. Problem Description When insufficient memory is available to handle an incoming selective acknowledgement, the TCP/IP stack may enter an infinite loop. III. Impact By opening a TCP connection and sending a carefully crafted series of packets, an attacker may be able to cause a denial of service. IV. Workaround On FreeBSD 5.4, the net.inet.tcp.sack.enable sysctl can be used to disable the use of SACK: # sysctl net.inet.tcp.sack.enable=0 No workaround is available for FreeBSD 5.3. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to 5-STABLE or to the RELENG_5_4 or RELENG_5_3 security branch dated after the correction date. 2) To patch your present system: The following patch have been verified to apply to FreeBSD 5.3 and 5.4 systems. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-06:08/sack.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-06:08/sack.patch.asc b) Apply the patch. # cd /usr/src # patch < /path/to/patch c) Recompile your kernel as described in and reboot the system. VI. Correction details The following list contains the revision numbers of each file that was corrected in FreeBSD. Branch Revision Path - ------------------------------------------------------------------------- RELENG_5 src/sys/netinet/tcp_sack.c 1.3.2.10 RELENG_5_4 src/UPDATING 1.342.2.24.2.20 src/sys/conf/newvers.sh 1.62.2.18.2.16 src/sys/netinet/tcp_sack.c 1.3.2.5.2.1 RELENG_5_3 src/UPDATING 1.342.2.13.2.29 src/sys/conf/newvers.sh 1.62.2.15.2.31 src/sys/netinet/tcp_sack.c 1.3.4.1 - ------------------------------------------------------------------------- VII. References http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0433 The latest revision of this advisory is available at ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-06:08.sack.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD4RCIFdaIBMps37IRAplNAJ9sEJf5VkMOJaWO7P/wNHEzzW1aqACfcAfL e95PJAa1af/klNC+fZEipnY= =yZbN -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Thu Feb 2 09:56:57 2006 Return-Path: X-Original-To: freebsd-security@FreeBSD.org Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C4C0E16A420 for ; Thu, 2 Feb 2006 09:56:57 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6250643D49 for ; Thu, 2 Feb 2006 09:56:56 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 53E6F46BC7 for ; Thu, 2 Feb 2006 04:56:46 -0500 (EST) Date: Thu, 2 Feb 2006 09:58:55 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: freebsd-security@FreeBSD.org Message-ID: <20060202095819.W87763@fledge.watson.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1265902628-1138874335=:87763" Cc: Subject: Re: HEADS UP: Audit integration into CVS in progress, some tree disruption (fwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2006 09:56:57 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1265902628-1138874335=:87763 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE FYI, since this is probably of interest to subscribers of this mailing list= =20 also. Robert N M Watson ---------- Forwarded message ---------- Date: Wed, 1 Feb 2006 22:55:40 +0000 (GMT) From: Robert Watson To: Julian Elischer Cc: trustedbsd-audit@TrustedBSD.org, K=F6vesd=E1n G=E1bor , current@freebsd.or= g Subject: Re: HEADS UP: Audit integration into CVS in progress, some tree disruption On Wed, 1 Feb 2006, Julian Elischer wrote: >>> I'll send out follow-up e-mail once the worst is past, along with=20 >>> information on what it all means, and how to try it out (for those not= =20 >>> already on trustedbsd-audit, who have been hearing about this for a whi= le). >>>=20 >> Do you plan to merge it to RELENG_6? If so, when? Maybe for the upcoming= =20 >> 6.1? Or only for 6.2 or later? >=20 > is there a website about all this stuff? "What's it for?" I'm sure I promised to answer exactly that question in my followup e-mail o= nce=20 the integration is done. :-) The quick answer is that this is an implementation of security event auditi= ng,=20 as required by the Orange Book C2 and later Common Criteria CAPP security= =20 evaluation/standard. These documents provide specifications for a set of= =20 functional requirements (and assurance requirements) regarding the behavior= of=20 operating systems with respect to security. One of the requirements is the= =20 fine-grained and configurable logging of security-relevant events.=20 Security-relevant turns out to be pretty all-inclusive, as CAPP requires th= e=20 ability to log the results of access control decisions associated with=20 discretionary access control, which means basically all file I/O, including= =20 path lookups. So what is present in our implementation is: - The introduction of a centralized kernel audit event engine, src/sys/security/audit, which includes various system calls, an event qu= eue, kernel worker thread to process the queue, interfaces to capture system = call information, a system call for user applications to submit audit records= , pre-selection mechanism, etc. - OpenBSM, an implementation of the Solaris/OpenSolaris Basic Security Modu= le API and file format for audit trails. This is derived from the BSM audi= t support found in the Apple Mac OS X and Darwin operating systems, althou= gh substantially reworked, cleaned up, and synchronized to recent BSM chang= es in Solaris, such as 64-bit records. - auditd, a daemon for managing audit event logs and the audit subsystem. - Modifications throughout the kernel and in many places in user space to generate audit records. Unlike existing logging and tracing mechanisms, audit has to meet a number = of=20 reliability, security, and functional requirements that basically drove the= =20 implementation of a new logging system rather than adaptation of an existin= g=20 one: - Only authorized processes can read and write to the audit log. - Detailed subject and object information, including file paths, full credential information for processes, etc. - Configurable log granularity by user, subsystem, operation, including the ability to control the logging of non-attributable events. - Audit log reduction tools and pre-selection mechanism. - Reliability requirements relating to maximum record loss in the event of power loss, configurable ability to fail-stop the system when the audit store is filled. - Portable log format based on the de facto industry standard BSM format (u= sed by Solaris, Mac OS X, and a moderate number of intrusion detection tools= , post-mortem tools, etc). The implementation is not yet fully complete, but it's now at the point whe= re=20 more broad exposure and testing would be very helpful. The hope is to have = much=20 of the current implementation merged in the next couple of days, and the=20 remainder over the next couple of weeks. Since I did the intro for this, I should take this opportunity to thank App= le=20 Computer for sponsoring the original development work as part of their Comm= on=20 Criteria CAPP evaluation for Mac OS X, and then releasing the results under= a=20 BSD license (announcement on this to follow), SPARTA for releasing extensio= ns=20 and additional work on the system, not to mention the team of people who ha= ve=20 been involved in porting over, adapting, and substantially enhancing the Da= rwin=20 audit support, including Wayne Salamon (part of the original audit developm= ent=20 team), who has done extensive development work on it, and Tom Rhodes, who h= as=20 written a lot of the new documentation including a new handbook chapter on= =20 configuring audit support. Robert N M Watson _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" --0-1265902628-1138874335=:87763-- From owner-freebsd-security@FreeBSD.ORG Sat Feb 4 20:14:46 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C08F916A420 for ; Sat, 4 Feb 2006 20:14:46 +0000 (GMT) (envelope-from ipfreak@yahoo.com) Received: from web52101.mail.yahoo.com (web52101.mail.yahoo.com [206.190.48.104]) by mx1.FreeBSD.org (Postfix) with SMTP id 4763B43D4C for ; Sat, 4 Feb 2006 20:14:46 +0000 (GMT) (envelope-from ipfreak@yahoo.com) Received: (qmail 48434 invoked by uid 60001); 4 Feb 2006 20:14:45 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Fx5u1E4I+mb8cFPAiZBJK0pcwB0/818A+rAr9k8iRVGg78AJxcdZ69h0p/Al66wsIY/spuqUf7KpyM6cFgMQabF87wUYnGkXZ8aEZ7/T12/Wli4Okiso03XHzdJKct0x+cs11U2WKPmb6Ij6G8oXIJ6zKjNV5xomL33JyQOBPOE= ; Message-ID: <20060204201445.48432.qmail@web52101.mail.yahoo.com> Received: from [200.78.5.14] by web52101.mail.yahoo.com via HTTP; Sat, 04 Feb 2006 12:14:45 PST Date: Sat, 4 Feb 2006 12:14:45 -0800 (PST) From: gahn To: freebsd security MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: nnamp question X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2006 20:14:46 -0000 Hi: I have a machine with four interfaces connecting four different networks. I am learning to use nmap and trying to force the nmap working only one interface. As nmap man page states, I use -e option and it would not work: nmap -e fx0 -v -sP 192.168.128.0/23 Starting Nmap 3.95 ( http://www.insecure.org/nmap/ ) at 2006-02-04 14:04 CST getinterfaces: Failed to open ethernet interface (el0) QUITTING! What did I do wrong? Thanks __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com