Re [syslog-ng] Ignoring previously handled/filtered messages

Hamilton, Andrew Mr. HamiltonA@hq.5sigcmd.army.mil
Fri, 26 May 2000 07:16:15 +0200


I like the configuration option as well.  I would like to be able to
duplicate some but not others.   Of course we all want as fine a grain of
control as we can get.  I do all the filtering and parsing and reporting on
a considerable amount of log information, and while several places need to
see some of the same logs, for the most part only the sysadmins are
interested in it.  I make the reports I generate from the logs available on
the local intranet for whoever is interested, but I don't get to make all of
it available.  The security people are funny about that.  For the stuff I
want duplicated I can easily add a second or a third or a ... destination()
to a log function and get my duplication that way.  Matter of fact I prefer
to do this as it gives ME the control over the logging.

Anyway just my $.02 worth.

Thanks
Drew

> -----Original Message-----
> From:	offset [SMTP:offset@privacyx.com]
> Sent:	Thursday, May 25, 2000 7:31 PM
> To:	syslog-ng@venus.terrasoft.hu
> Subject:	Re [syslog-ng] Ignoring previously handled/filtered messages
> 
> I like the idea of having syslog messages duplicated.
> 
> In a very large enterprise you have multiple groups wanting access to
> the same information.
> 
> System administration is looking for availability related logs
> Security administration is looking for security related logs.
> Groups above may having overlapping facility and level requirements.
> 
> Such as SysAdmins needing kern.notice for kernel output, and SecAdmins
> needing this log to catch Solaris stack executable buffer overflow
> attempts.
> 
> If I were in security parsing syslog output, I would not want the system
> administration group grabbing all the content with nothing left for the
> security administrators to pull from.  This is especially true for
> environments where system administration and security administration for
> a server has been separated into different groups with different
> management reporting structures.
> 
> Perhaps as a compromise, a configuration setting in syslog-ng that
> controls fall-through.
> 
> -- offset --
> 
> John Goggan wrote:
> 
> > ger wrote:
> > > try
> > >   filter f_daemon { facility(daemon) and not program(name);};
> > >
> > > where "name" is whatever program you're trying to filter out.
> >
> > Thanks to Ger and Ilya for their responses.  While this does work, it
> really
> > seems like a poor way to do it to me -- and, I believe, is also quite a
> bit
> > different from the way standard syslog handles things.  The problem is
> that it
> > should just be easy to make it so that messages are handled only ONCE
> and then
> > not sent to additional logs unless specifically desires.  How many
> people
> > really want the same syslog message sent to multiple logs most of the
> time?
> > It just seems that the default (which does this) is the opposite of what
> most
> > would want.
> >
> > Plus, what needs to be done to get around this just doesn't make any
> sense.
> > This means that if I want separate logs for imapd, named, telnetd, and
> ftpd
> > (to name just a few common daemons) -- and I want any other daemons that
> pop
> > up to still go to a daemon.log, I have to do this in my filter section:
> >
> > filter f_imapd { program("imapd"); };
> > filter f_named { program("named"); };
> > filter f_telnetd { program("telnetd"); };
> > filter f_ftpd { program("ftpd"); };
> > filter f_auth { facility(auth)
> >                 and not program("imapd")
> >                 and not program("named")
> >                 and not program("telnetd")
> >                 and not program("ftpd"); };
> > filter f_daemon { facility(daemon)
> >                 and not program("imapd")
> >                 and not program("named")
> >                 and not program("telnetd")
> >                 and not program("ftpd"); };
> > filter f_messages { level(info..warn)
> >         and not facility(auth, authpriv, mail, news);
> >                 and not program("imapd")
> >                 and not program("named")
> >                 and not program("telnetd")
> >                 and not program("ftpd"); };
> >
> > That just seems like a really bad design!  I have to make sure that I
> keep all
> > of the names updated in several different locations.  If I want to add a
> log
> > for just one more daemon, I have to add it to at least 3 other filters
> besides
> > its own filter!
> >
> > Aren't other people experiencing such problems?  Or is no one out there
> using
> > syslog-ng to filter out specific daemons while still catching the
> unlisted
> > daemons in a daemon.log file?
> >
> > There must be a better way...
> >
> >  - John...
> >
> > _______________________________________________
> > syslog-ng maillist  -  syslog-ng@lists.balabit.hu
> > http://lists.balabit.hu/mailman/listinfo/syslog-ng
> >
> >    ----------------------------------------------------------------
> >
> >
> >
> >
> >
> >
> >              Link is external to the Privacyx.com System
> >
> 
> _______________________________________________
> syslog-ng maillist  -  syslog-ng@lists.balabit.hu
> http://lists.balabit.hu/mailman/listinfo/syslog-ng