From owner-freebsd-security Mon Apr 23 18:50:32 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.kyx.net (s216-232-31-82.bc.hsia.telus.net [216.232.31.82]) by hub.freebsd.org (Postfix) with ESMTP id 5E7BD37B423 for ; Mon, 23 Apr 2001 18:50:28 -0700 (PDT) (envelope-from dr@kyx.net) Received: from smp.kyx.net (unknown [10.22.22.45]) by mail.kyx.net (Postfix) with SMTP id DC2951DC07; Mon, 23 Apr 2001 18:53:38 -0700 (PDT) From: Dragos Ruiu Organization: kyx.net To: "Crist Clark" , Domas Mituzas Subject: Re: Connection attempts (& active ids) Date: Mon, 23 Apr 2001 18:39:25 -0700 X-Mailer: KYX-CP/M [version core00-mail-92] Content-Type: text/plain Cc: scheidell@fdma.com, freebsd-security@FreeBSD.ORG References: <20010423231908.N574-100000@axis.tdd.lt> <3AE4A5F2.E52825EE@globalstar.com> In-Reply-To: <3AE4A5F2.E52825EE@globalstar.com> MIME-Version: 1.0 Message-Id: <01042318494515.00270@smp.kyx.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have to say that I disagree with most of the arguments espoused below. A carefully controlled and monitored auxilliary system is not only a good defensive measure, but unlikely an actual security risk unless you make it ridiculously easy to break into. Thankfully, most script kiddy intruders seem to be lazy and go for the honeypots and the path of least resistance most often.... But it's probably better to have the honeypot mirror your normal configs to get the most value out of it and to make it less obviously different from your production system. I would even go as far in differing as to say that I expect honeypot systems to become a standard practice not just a "best" practice. I'm not quite convinced about the "canned" honeypots though.... Like that movie said, "Every Jedi must build their own..." :-) If nothing else, a honeypot makes a great use for a hot standby spare... cheers, --dr On Mon, 23 Apr 2001, Crist Clark wrote: > Domas Mituzas wrote: > > [snip] > > > One of best practices is to build honeypots - early warning systems with > > great publicity and observed security. And software, with changed banners > > into older ones :) > > Most of what you said made sense up until this point. You are not saying it > is a "best practice" for everyone concerned with security to build honeypots? > Unless you are actively doing security research (i.e. your job description > goes beyond just protection computer and information assets, or you are doing > it on your own time), building and deploying honeypots is a very questionable > use of resources. > > You are most likely going to be capturing script kiddie tools you could > just go download off of any of a dozen h4x0r sitez. Building a secure > honeypot is harder than building a secure "legit" machine, and we all > make mistakes. That can actually reduce your security as a whole by > introducing compromised machines (and if you are building entire secure > extranets just to house honeypots, that's a lot of resources being > spent). Honeypots are also a potental legal liability. > > If you want "great publicity" to justify yourself to management, a simple > NIDS will give you just as much ammunition as a honeypot (would management > even understand the distinction?). And don't pretend that the kiddies or > crackers will just stop poking around your network once they find your > honeypot. We all see the scans walk methodically across our nets. We all > know most of them come from machines already compromised. Honeypots just > focus _more_ kiddie and cracker attention on you rather than distract > them from your real assets. > > Honeypots do have a place for those doing security research. For someone > working to protect a corporate, academic, or government network, energy > is better spent on other things... unless your network is already 100% > secure (heh-heh). > -- > Crist J. Clark Network Security Engineer > crist.clark@globalstar.com Globalstar, L.P. > (408) 933-4387 FAX: (408) 933-4926 > > The information contained in this e-mail message is confidential, > intended only for the use of the individual or entity named above. If > the reader of this e-mail is not the intended recipient, or the employee > or agent responsible to deliver it to the intended recipient, you are > hereby notified that any review, dissemination, distribution or copying > of this communication is strictly prohibited. If you have received this > e-mail in error, please contact postmaster@globalstar.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message -- Dragos Ruiu dursec.com ltd. / kyx.net - we're from the future gpg/pgp key on file at wwwkeys.pgp.net or at http://dursec.com/drkey.asc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message