Hi everybody, I have implemented a new filter for syslog-ng. You can now filter log messages based on their sender's IP address like this: # match a single host filter f_noc21 { netmask("134.130.3.73"); }; # match a whole subnet filter f_noc { netmask("134.130.3.0/255.255.255.0"); }; I'll attach patches for syslog-ng versions 1.4.14 and 1.5.13. I have also made a small patch that fixes the behaviour of the emulated inet_aton function in utils.c. (It would not work with "255.255.255.255".) On some architectures you need this patch for my netmask-filter to work properly! Have fun and tell me what you think about it! Greetings Gert
I like it and all that it is missing is 1) A mechansim of proving delivery receipt - i.e. reliable delivery of syslog information 2) A mechanism of watermarking or timestamping with a reliable time abse so that the records can stand up to evidentiary use model reqyuirements. 3) A uniform Syslog Event Query Interface (XDAS or DOORS compliant would be nice too!). Todd ----- Original Message ----- From: "Gert Menke" <> To: <syslog-ng@lists.balabit.hu> Sent: Saturday, January 19, 2002 4:17 PM Subject: [syslog-ng][PATCH] netmask-filter
Hi everybody,
I have implemented a new filter for syslog-ng. You can now filter log messages based on their sender's IP address like this:
# match a single host filter f_noc21 { netmask("134.130.3.73"); };
# match a whole subnet filter f_noc { netmask("134.130.3.0/255.255.255.0"); };
I'll attach patches for syslog-ng versions 1.4.14 and 1.5.13.
I have also made a small patch that fixes the behaviour of the emulated inet_aton function in utils.c. (It would not work with "255.255.255.255".) On some architectures you need this patch for my netmask-filter to work properly!
Have fun and tell me what you think about it!
Greetings Gert
Hi!
I like it and all that it is missing is Thanks, but I don't see what those things have to do with my patch?
1) A mechansim of proving delivery receipt - i.e. reliable delivery of syslog information
Hm, using tcp insted of udp could improve things a bit, but not every syslogd supports that.
2) A mechanism of watermarking or timestamping with a reliable time abse so that the records can stand up to evidentiary use model reqyuirements.
Yes, that could be useful. I heard about a program called multilog a few days ago; IIRC it is able to do such things. (You would need to pipe your syslog data to multilog via destination{program("multilog...");}; or so.) Does anybody on this list know more about this? BTW: Is it possible to customize the logfile format of syslog-ng? I would like something like: <local timestamp><source ip><host><sender's timestamp><message>
3) A uniform Syslog Event Query Interface (XDAS or DOORS compliant would be nice too!).
Could you explain that a little more? Greetings Gert
I am sorry Gert - My fault for not explaining more , and I thought it was inherently obvious what it has to do with your filter. What I am looking for a stronger log maintanenece regimen from SyslogNG or the tools around its use. Let me ask "Gert what is the point of collecting logging information anyway?" So that we as a systems admin can prove what went on inside our systems - leaving us as the weak link in the evidentiary chain of custody for events taking place inside the audit envelope around your systems. Also - at least in the states here after the ENRON Debacle - look to auditors to have a much stronger profile in any audit and process walkthrough that we as Systems Admins will have to do for them. That has direct implications on the trustability and systenms that we erect to log our systems activities with. Todd Glassey ----- Original Message ----- From: "Gert Menke" <gert@menke.za.net> To: "todd glassey" <todd.glassey@worldnet.att.net> Cc: <syslog-ng@lists.balabit.hu> Sent: Sunday, January 20, 2002 7:27 AM Subject: Re: [syslog-ng][PATCH] netmask-filter
Hi!
I like it and all that it is missing is Thanks, but I don't see what those things have to do with my patch?
1) A mechansim of proving delivery receipt - i.e. reliable
delivery
of syslog information Hm, using tcp insted of udp could improve things a bit, but not every syslogd supports that.
2) A mechanism of watermarking or timestamping with a reliable
time
abse so that the records can stand up to evidentiary use model reqyuirements. Yes, that could be useful. I heard about a program called multilog a few days ago; IIRC it is able to do such things. (You would need to pipe your syslog data to multilog via destination{program("multilog...");}; or so.) Does anybody on this list know more about this?
BTW: Is it possible to customize the logfile format of syslog-ng? I would like something like: <local timestamp><source ip><host><sender's timestamp><message>
3) A uniform Syslog Event Query Interface (XDAS or DOORS
compliant
would be nice too!). Could you explain that a little more?
Greetings Gert
Hi,
I am sorry Gert - My fault for not explaining more , and I thought it was inherently obvious what it has to do with your filter. It still isn't obvious to me, sorry...
Let me ask "Gert what is the point of collecting logging information anyway?" So that we as a systems admin can prove what went on inside our systems - leaving us as the weak link in the evidentiary chain of custody for events taking place inside the audit envelope around your systems. Well, we cannot _prove_ what happened on our machines; as admin it is easy to fake logfiles so they "prove" anything we want. As you said, the admin is the "weak link" here. Instead, logging information gives us hints about misconfigurations or attempted (and possibly successful) intrusions into our machines. (Assuming that nobody can mess with the loghost...) I'm sure you can use or abuse a syslog daemon for lots of other useful things...
So, does anybody else on this list want to comment about my patch? Balazs, will you include it in future versions of syslog-ng? Greetings Gert
Am Dienstag, 22. Januar 2002 02:33 schrieb Gert Menke:
Hi,
Hi Gert!
...
So, does anybody else on this list want to comment about my patch?
I'd like to state, that I consider your patch (including the netmask stuff into syslog-ng) very useful. Especially if one thinks of log collectors it simplifies the creation of syslog-ng.conf files.
Balazs, will you include it in future versions of syslog-ng?
Greetings Gert
Cheers, Bernd
_______________________________________________ syslog-ng maillist - syslog-ng@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng
Gert - My fault for not making it clearer - I responded to the general group with the answer to this. Todd ----- Original Message ----- From: "Gert Menke" <gert@menke.za.net> To: "todd glassey" <todd.glassey@worldnet.att.net> Cc: <syslog-ng@lists.balabit.hu> Sent: Sunday, January 20, 2002 7:27 AM Subject: Re: [syslog-ng][PATCH] netmask-filter
Hi!
I like it and all that it is missing is Thanks, but I don't see what those things have to do with my patch?
1) A mechansim of proving delivery receipt - i.e. reliable
delivery
of syslog information Hm, using tcp insted of udp could improve things a bit, but not every syslogd supports that.
2) A mechanism of watermarking or timestamping with a reliable
time
abse so that the records can stand up to evidentiary use model reqyuirements. Yes, that could be useful. I heard about a program called multilog a few days ago; IIRC it is able to do such things. (You would need to pipe your syslog data to multilog via destination{program("multilog...");}; or so.) Does anybody on this list know more about this?
BTW: Is it possible to customize the logfile format of syslog-ng? I would like something like: <local timestamp><source ip><host><sender's timestamp><message>
3) A uniform Syslog Event Query Interface (XDAS or DOORS
compliant
would be nice too!). Could you explain that a little more?
Greetings Gert
_______________________________________________ syslog-ng maillist - syslog-ng@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng
On Sun, Jan 20, 2002 at 01:17:08AM +0100, Gert Menke wrote:
Hi everybody,
I have implemented a new filter for syslog-ng. You can now filter log messages based on their sender's IP address like this:
# match a single host filter f_noc21 { netmask("134.130.3.73"); };
# match a whole subnet filter f_noc { netmask("134.130.3.0/255.255.255.0"); };
I'll attach patches for syslog-ng versions 1.4.14 and 1.5.13.
I have also made a small patch that fixes the behaviour of the emulated inet_aton function in utils.c. (It would not work with "255.255.255.255".) On some architectures you need this patch for my netmask-filter to work properly!
Thanks for the patch. I'll include it in the next syslog-ng release. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
Gert Menke wrote:
I have implemented a new filter for syslog-ng. You can now filter log messages based on their sender's IP address like this:
# match a single host filter f_noc21 { netmask("134.130.3.73"); };
# match a whole subnet filter f_noc { netmask("134.130.3.0/255.255.255.0"); };
I'll attach patches for syslog-ng versions 1.4.14 and 1.5.13.
Have fun and tell me what you think about it!
Hi Gert, great idea. We are logging some Class-B's to syslog-ng. So handling source IP's is an absolute GREAT feature. But, if you can make it possible, to log source IP's via a template() variable (say SOURCE_IP or so) used by the file() destination, too ... ... that's the feature we want for! -- Best regards --Andreas Schulze [phone: +49.5246.80.1275, fax: +49.5246.80.2275] | I believe, it was Dennis Ritchie who said something like: | "C is rarely the best language for a given task, | but it's often the second-best". | The implication being that: "[...]" | | sh# cat>$$.c<<EOT | main(l,a,n,d)char**a;{for(d=atoi(a[1])/10*80-atoi(a[2])/5-596;n="@NK\ | ACLCCGZAAQBEAADAFaISADJABBA^SNLGAQABDAXIMBAACTBATAHDBANZcEMMCCCCAAhE\ | IJFAEAAABAfHJETBdFLDAANEfDNBPHdBcBBBEA_AL H E L L O, W O R L D! " | [l++-3];)for(;n-->64;)putchar(!d+++33^l&1);} | EOT | gcc -o$$ $$.c;clear;./$$ 52 8;rm -f $$*
Hi! On Sun, Jan 27, 2002 at 10:49:56AM +0100, Andreas Schulze wrote:
great idea. We are logging some Class-B's to syslog-ng. So handling source IP's is an absolute GREAT feature. Thanks...
But, if you can make it possible, to log source IP's via a template() variable (say SOURCE_IP or so) used by the file() destination, too ... ... that's the feature we want for! That sould not be too hard to do, but I don't think I will have time for it in the near future. If you want to try yourself, you should look into affile.c. How to get the source address of a log message should me quite obvious from my patch (look into filters.c).
Greetings Gert
... that's the feature we want for! That sould not be too hard to do, but I don't think I will have time for it in the near future. If you want to try yourself, you should look into affile.c. How to get the source address of a log message should me quite obvious from my patch (look into filters.c).
I implemented $SOURCEIP in my CVS tree, available RSN. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
Hi!
I implemented $SOURCEIP in my CVS tree, available RSN. Oops... That's what I just did, too. :-)
I also implemented extra Tokens R_FULLTIME etc. and R_FULLTIME etc.; R_* always give you the time the log message was received and S_* always gives you the time from the message's timestamp. I'll be sending you the patches ASAP. Greetings Gert
Hi! On Mon, Feb 04, 2002 at 05:12:20PM +0100, I wrote:
I implemented $SOURCEIP in my CVS tree, available RSN. Oops... That's what I just did, too. :-)
I also implemented extra Tokens R_FULLTIME etc. and R_FULLTIME etc.; R_* always give you the time the log message was received and S_* always gives you the time from the message's timestamp.
I'll be sending you the patches ASAP.
Here is the patch against 1.5.13. Balazs, feel free to remove my $SOURCEIP stuff, if you like yours better. Please tell me what you think about my patch. Greetings Gert
participants (5)
-
Andreas Schulze
-
Balazs Scheidler
-
Bernd Jucknischke
-
Gert Menke
-
todd glassey