Date: Mon, 19 Feb 2001 23:11:22 -0500 From: Daniel Hagan <dhagan@colltech.com> To: "Edward W. M." <edward_wm@hotmail.com> Cc: cjclark@reflexnet.net, fbsdsec@killaz-r-us.com, freebsd-security@FreeBSD.ORG Subject: Re: Fw: Remote logging Message-ID: <3A91EE6A.82EBBC37@colltech.com> References: <LC4-LFD3tgx8VUkRacU0000021d@hotmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Edward W. M." wrote: > Exactly, so here's an idea. What if we moved syslogd into the > kernel and set up a sysctl knob for turning syslog on and off > (syslog.active for example). Each activity change would be > logged, of course. First, it doesn't seem that moving syslog into the kernel fits w/ my understanding of the UNIX design philosophy (separate programs for services, i.e. init, swapper, inetd, syslog, sendmail, etc.). Plus it brings up more code that would have to be severely audited for the base system to be considered 'secure' (for whatever criteria you decide to use). Keeping syslog separate lets you delete the binary and no longer have to worry about that code path for security reasons (if, for example, you replaced syslog w/ nsyslog). [snip discussion of sysctl knobs] It is my understanding (I could be wrong, it wouldn't even be the first time) that raw sockets operate below the firewall code on the network stack. If this is the case, then it would be trivial to forge status reports on the compromised host. There are also issues involving forging packets from a third host. Syslog uses UDP after all, so the source information can be forged from machines on at least the same subnet in many/most situations. You need MACs to prevent forging, which isn't available in the default syslog. Since UDP is unreliable, you also are spending a lot of effort on getting packets onto the wire even though you can't guarantee they will be delivered to the loghost. > Last, but not least, the kernel would prevent any attempts to bind > the syslog socket when syslogd would not be running, so syslog > spoofing to remote machines would become more difficult. The bottom > line is, regardless of whether the attacker would manage to make it > look as if syslog were still active on a certain host, you would know > for sure that a syslog status change has occurred, so you could set > up a script which would send you an SMS upon detecting any such > change. This is ignoring an important issue for security conscious sites: how do you replace the default syslog w/ something else. There are alternative syslogs out there that use crypto & TCP to resolve/mitigate many of the forging & delivery issues you're trying to address. If the kernel will block binding on syslog's port, how will you use one of these alternate implementations? You are also requiring securelevels to prevent an attacker circumventing all of the extra configuration you're adding. The difficulties in deploying securelevels has been beaten to death, so I won't reiterate them here. > Well, it was just an idea. Not a terribly bad one either, but I think there are lots of issues that aren't readily addressed. I would have to say that ACL's for signal delivery (which I believe actually falls under the capabilities work from TrustedBSD.org) would be a better way to go, perhaps w/ the addition of running syslogd from /etc/ttys in inittab mode (I'm not sure about the hurdles to doing that). Of course, remote logging depends on a lot of supporting infrastructure to work (what do you do if he takes out your loghost's switch or DDoSs it?). If we were going to rewrite the syslog code, I'd vote for doing it to add the crypto support (encryption & MACs) so it would be easily accessible for those who want that type of thing. Of course, that's just my $.04 ;-) Daniel 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?3A91EE6A.82EBBC37>