Date: Sun, 06 Jan 2002 12:01:39 -1000 From: "Arthur W. Neilson III" <art@pilikia.net> To: "Brett Glass" <brett@lariat.org> Cc: freebsd-stable@freebsd.org Subject: Re: Could someone commit the change suggested in PR bin/32420? Message-ID: <200201061201390130.478F5325@smtp> In-Reply-To: <4.3.2.7.2.20020105145152.01cbc100@localhost> References: <Message from Brett Glass <brett@lariat.org> <4.3.2.7.2.20020105005950.00db4f00@localhost> <4.3.2.7.2.20020105145152.01cbc100@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
recently we setup msyslog-1.08a on a number of freebsd and solaris
based boxes, syslogging to a mysql backend. this makes it easy to
setup notification mechanisms, do ad hoc queries and reporting.
a web front end to the database is easily done with php :^) for a help
desk to use for problem research.
On 1/5/02 at 3:21 PM Brett Glass wrote:
>
>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
--
__
/ ) _/_ It is a capital mistake to theorise before one has data.
/--/ __ / Insensibly one begins to twist facts to suit theories,
/ (_/ (_<__ Instead of theories to suit facts.
-- Sherlock Holmes, "A Scandal in Bohemia"
Arthur W. Neilson III, WH7N - FISTS #7448
Bank of Hawaii Network Services
http://www.pilikia.net
art@pilikia.net, aneilson@boh.com, wh7n@arrl.net
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?200201061201390130.478F5325>