Date: Mon, 19 Feb 2001 23:07:03 -0800 From: "Crist J. Clark" <cjclark@reflexnet.net> To: "Edward W. M." <edward_wm@hotmail.com> Cc: fbsdsec@killaz-r-us.com, freebsd-security@FreeBSD.ORG Subject: Re: Fw: Remote logging Message-ID: <20010219230703.R62368@rfx-216-196-73-168.users.reflex> In-Reply-To: <LC4-LFD3tgx8VUkRacU0000021d@hotmail.com>; from edward_wm@hotmail.com on Mon, Feb 19, 2001 at 11:30:09AM -0800 References: <LC4-LFD3tgx8VUkRacU0000021d@hotmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Feb 19, 2001 at 11:30:09AM -0800, Edward W. M. wrote: > Crist J. Clark <cjclark@reflexnet.net> writes: > >Not much point. You can always send a SIGKILL which cannot be caught > >by the process. The attacker would have to cooperate by sending > >syslogd(8) a SIGTERM or SIGINT, but why would he do that? > > Exactly, so here's an idea. What if we moved syslogd into the > kernel...[snip] Please pass along whatever crack you have been smoking. That stuff will mess your head good. Adding syslog to the kernel makes many, many more problems than it solves. I think one has to accept the idea that syslog can be killed on a remote host and that the host can send data to a logging server to and from abitrary ports. If a box is owned, it's owned. The attacker can do whatever he wants... almost. You have two chances, (1) the remote logging client will notify you before the box is completely taken or (2) you can recognize that the remote client has been tampered with. Problem (1) is hard. You have to account for any type of attack. (2) is not easy, but it probably easier. All I would want would be for syslogd on the client and server generate a shared, cryptographically strong secret when any of them is reset (HUPped) or restarted. The secret is forgotten at the slightest tampering. We use simple public key crypto, e.g. Diffie-Hellman, for the syslogd's to generate the secret. All subsequent messages can be signed (what I would typically prefer) or encrypted (some people might like this) using this number. We then watch for this number to change. The server syslogd will note this and log it. If the shared secret does not change, we have good reason to believe syslogd has not been tampered with. If it does change, we need to take a look at why. This approach is subject to a number of attacks. If you already have an intruder on your network, he may be able to perform a man-in-the-middle, bucket-brigade attack during the key exchange. Note this exchange is NOT authentication. However, an intruder cannot learn the key by listening passively on the network. The other challenge is for the attacker to alter syslogd without losing the secret or to retrieve the secret and then use his own syslogd that can load it (this syslogd would _NOT_ have an option to use a fixed secret). Assuming that your network is in a fairly secure initial state, the lack of authentication is not a problem (and adding authentication is "hard"). The challenge is making sure an attacker will have a hard time altering the running syslogd or getting the secret... Running at securelevel would really help there (since it would be hard to tamper with the kernel to get at syslogd's "raw" bits). syslogd would have to be written with a bit of a hair trigger to forget the secret, not core dump it, be hard to attach a debugger, etc. I'd have to think about how to do that... or if it is even practical. I would tend to think someone has already done this? But most the "improved" syslogds that I have seen are too overblown with features for my tastes and go too far away from the established protocols. I think these extensions could be done without back-compatibility issues. -- Crist J. Clark cjclark@alum.mit.edu 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?20010219230703.R62368>