From owner-freebsd-security Thu May 31 9:29:44 2001 Delivered-To: freebsd-security@freebsd.org Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.121.85]) by hub.freebsd.org (Postfix) with ESMTP id 919AD37B423 for ; Thu, 31 May 2001 09:29:41 -0700 (PDT) (envelope-from dhagan@colltech.com) Received: from colltech.com (1Cust94.tnt2.clarksburg.wv.da.uu.net [63.21.115.94]) by gull.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id JAA29115; Thu, 31 May 2001 09:29:23 -0700 (PDT) Message-ID: <3B16712F.9DD3EC61@colltech.com> Date: Thu, 31 May 2001 12:28:31 -0400 From: Daniel Hagan X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: WebSec WebSec Cc: security@FreeBSD.ORG Subject: Re: Port 21 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 WebSec WebSec wrote: > Also, in my opinion it may not be a good idea to provide real IPs (at > least in this list) because you never know how you can tip someone. > Yes, this is "security" by obscurity, but.... That phrase has become so popular that people apparently forget what it actually *means*. Restricting information about an ongoing incident is not security by obscurity. That is information control, and is a critical component in "winning" any aggressor/defender scenario. (Just check something like the SANS Incident Handling guidelines, they make it clear that need-to-know and out-of-band communications are important.) Security by obscurity is designing a system that is hopelessly insecure from a technical viewpoint and assuming that someone will never notice (using xor as an encryption algorithm, for example). When designing a security infrastructure, you should have confidence that even given full knowledge of your system, an attacker would have a difficult time achieving a compromise. But it doesn't make much sense to actually give your attackers that information ahead of time, does it? (I'm not referring to special situations like red-team intrusion testing, I mean actually publishing it willy-nilly on the Internet.) Daniel - -- Consultant, Collective Technologies http://www.collectivetech.com/ Use PGP for confidential e-mail. http://www.pgp.com/products/freeware/ Key Id: 0xD44F15B1 3FA0 D899 4530 702F 72B0 5A17 C2A5 2C2B D22F 15B1 -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBOxZxJsKlLCvSLxWxEQK66ACcDetfPuCmklTymk9wXw0289b9VPgAoPeJ fUDW+WDHWHC9nLCQv3NsrCBs =qYfv -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message