Date: Sun, 19 Sep 1999 22:29:36 -0600 (MDT) From: Jobe <jobe@attrition.org> To: Brett Glass <brett@lariat.org> Cc: Nate Williams <nate@mt.sri.com>, Wes Peters <wes@softweyr.com>, "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>, Warner Losh <imp@village.org>, security@FreeBSD.ORG Subject: Re: Real-time alarms Message-ID: <Pine.LNX.3.96.990919193527.13128E-100000@forced.attrition.org> In-Reply-To: <4.2.0.58.19990919175752.04577a20@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 19 Sep 1999, Brett Glass wrote: > At 01:33 PM 9/19/99 -0600, Nate Williams wrote: > > >Email is trivial to forge > > With strong encryption? > > >and/or snarf, > > Depends how it's done. > How about the fact that even a not so bright hacker given access to implement ip filtering rules can(and probably will) notice the encrypted SMTP traffic and just 'turn it off' in the filters, so to speak. Using any high level internet protocol, especially a widely known established protocol like SMTP, to transmit security sensitive information pertaining to potential copromises is a _bad_ idea, as I have stated in previous messages. You are better off designing a new one-way communication protocol based on shared secret keys, with some sort of hashing to verify the contents of the packet. If the hash is off, or the packet is not recieved as sent, then an alert can be generated at the remote host, so you will either get the alarm, or get an alarm that states that someone is mucking with your transmitted alerts. Here's another idea though, if you guys are insistent upon using a high level protocol, why not use https? It's already designed for encrypted data transmission, it's fairly fast, and can most likely be configured to use non-standard ports. Not to mention the fact that you can bundle this with easily configurable auttenticated http. > >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. > > >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. > 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. > Both of you are wrong here, tripwire merely serves as a frontline defense to thwart an unskilled hacker from attempting to backdoor the filesystem. I mean if I am given access to load an lkm, all I would then really have to do is write myself up an lkm that wraps stat() to return old filesizes, and not only will tripwire _not_ pick up the fact that the filesizes have changed but to the normal user the filesizes will still look the same as well. Also if a 'script kiddie' attacks your machine tripwire does you no good if he/she doesn't try to backdoor any of the binaries. Not to mention the fact that it's very visible on the installed system. Granted I'm not advising that people not use this software, however I'm merely pointing out that it's not a real means of break-in detection. > 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. > I think that perprocess capabilities would solve the need for an application like tripwire very nicely. If you can prevent processes from doing things they were never meant to do in the first place, software like tripwire would not be needed. For example, should login ever need to open connections to remote machines, or write to files? Granted tripwire is useful but I think it leaves the overlying problem in OS security design unresolved. The major security problem related to the *nix OS design is that arbitrary processes running as uid/euid 0 are given the ability to access any libc routine, any kernel system call, any ioctl(), load any code into the working environment etc. If people are really interested in the integrity of a working environment these are all issues that need to be addressed. OS security should not be defined in userland policies end of story. The problem is that most people(Sorry R. Watson) will not take the initiative to work on in kernel security policies, either out of lack of time, lack of ambition, or lack of skill. --Jobe > --Brett > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.96.990919193527.13128E-100000>