Date: Sat, 05 Jan 2002 15:21:53 -0700 From: Brett Glass <brett@lariat.org> To: Jordan Hubbard <jkh@winston.freebsd.org> Cc: Archie Cobbs <archie@dellroad.org>, stable@FreeBSD.ORG, re@FreeBSD.ORG Subject: Re: Could someone commit the change suggested in PR bin/32420? Message-ID: <4.3.2.7.2.20020105145152.01cbc100@localhost> In-Reply-To: <25228.1010266686@winston.freebsd.org> References: <Message from Brett Glass <brett@lariat.org> <4.3.2.7.2.20020105005950.00db4f00@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
At 02:38 PM 1/5/2002, Jordan Hubbard wrote: >Of course, collecting log data for analysis from syslog is pretty >low-tech when it comes to detecting and/or stopping attacks in >real-time and I'd hope this wouldn't be encouraged as a general >practice. I can't see any reason not to use syslogd, or something like it, as a source of information for an IDS or log monitor, though there may of course be other sources of input for these facilities too. >If that's your aim then you should be campaigning for a >/dev/audit device and the instrumenting of suitable logpoints in the >kernel and various utilities. Then your stuff just opens /dev/audit, >registers an event selection mask with it, and goes to sleep waiting >for events. The situation is a bit more complex than this. One will also want the ability to do remote auditing -- something that a /dev/audit wouldn't by itself allow. My personal opinion is that the architecture of syslogd itself was fine when Eric created it but is now probably out of date, and that a new backward compatible facility should be crafted. But for the nonce, other things can be layered on top of syslogd so long as the compression is disabled. This allows new ideas to be tested without unduly perturbing anything. The repeat counter causes log messages to be delayed for an indeterminate amount of time and so one should be able to disable it. Archie's new command line option does this. The only hitch I can foresee is that it is global; that is, it applies to every destination. I'd like even more to be able to disable compression on a per-line basis in syslog.conf. (The internal data structures of syslogd make this convenient to implement, because one struct is maintained per destination.) I've toyed, for example, with the idea of using a single character prefix to indicate that a file, remote machine, or piped app should not get log compression. For example, a file with log compression would be designated as before -- e.g. /var/log/foo.log -- while one with no compression would be specified as +/var/foo.log. Likewise, a piped app without compression would be +|/usr/local/bin/mylogmonitor, and a remote machine that didn't want compression (perhaps because it was running a log monitor at the other end) would be +@host.domain.tld. The plus character is unambiguous and so there wouldn't be problems with backward compatibility. --Brett --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4.3.2.7.2.20020105145152.01cbc100>