From owner-freebsd-security Sun Sep 19 18:55:44 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 9A01B15A12 for ; Sun, 19 Sep 1999 18:55:38 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id SAA56892; Sun, 19 Sep 1999 18:54:51 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199909200154.SAA56892@gndrsh.dnsmgr.net> Subject: Re: Real-time alarms In-Reply-To: <4.2.0.58.19990919175752.04577a20@localhost> from Brett Glass at "Sep 19, 1999 06:11:52 pm" To: brett@lariat.org (Brett Glass) Date: Sun, 19 Sep 1999 18:54:50 -0700 (PDT) Cc: nate@mt.sri.com (Nate Williams), wes@softweyr.com (Wes Peters), imp@village.org (Warner Losh), security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > At 01:33 PM 9/19/99 -0600, Nate Williams wrote: > > >Email is trivial to forge > > With strong encryption? Lets see, we are trying to secure on OS, so lets go out and use one of the most common ways to break into the system as a means of conveying our security informatin. NOT!! > > >and/or snarf, > > Depends how it's done. And it is easy to cause it to be delayed and or lost by continual injection of bad IP data into the network stream. > > >and is not > >secure by any stretch of the imagination. > > More strides have been made toward good security for e-mail than for > any other type of computer facility. Why? because e-mail is the thing > that people, overall, MOST want to be secure. > > That's the reason why I suggest it. It's not always the ideal method > for secure notification, but the ways of authenticating and securing it > are better developed than for other methods. So, it may be the best bet, > at least to start. Before we can even think about this far flung idea we need need to get it secured locally on the box that is creating the audit data. Your talking about a consumer of the implementation, which needs to come after the implementation is done. > > >Case in point. Tripwire is *NOT* a breakin-avoidance system, it's a > >breakin-detection system. Breakin detection systems are at best poor > >and at worst useless, and so far no-one has found a way to make them any > >better. :( > > Break-in detection systems work very well in the physical world, where -- > as we all know -- it's ultimately possible to break into nearly > anything if you employ sufficient force or defeat a perimeter defense. If you say ``nearly anything'' you haven't been around the security business very long, the correct wording is ``all things''. > They're especially valuable in multi-layered security systems, where > they can detect a breach of an outer perimeter and report it before > an intruder can get through an inner perimeter. And you surely don't want you notification mechanism to be a something that lives in that ``outer permiter'' now do you. That is where e-mail, particularly sendmail, lives. > > I think they're a valuable asset in the virtual world, too, especially > if used in conjunction with multi-layered security. In BSD UNIX, > "securelevels," immutable files, etc. are the as-not-yet-perfected > inner layer. and /dev/audit is also part of the inner layer and can not depend upon mechansims in the outer layer to operate correctly. -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message