Hi, Moxey, Joel, VF UK - Technology (TS) <Joel.Moxey@vodafone.com> [20070619 10:14:24 +0100]:

Hi!

I am trying to work out if syslog-ng can act as a relay without doing "noticeable" changes to the syslog message in terms of what the syslog server sees.

I would be more inclinded to probably consider using netcat[1]. You probably could do something like (I might have this wrong though, its called a 'netcat relay'): $ mknod transferpipe p $ nc -u <dest-ip> 514 < transferpipe | nc -u -l -p 514 > transferpipe Cheers Alex [1] http://www.securitydocs.com/library/3376

The problem:

1) The device sends non-standard syslog messages 2) The syslog needs to go to 2 end systems, the device supports 1 3) One of the end devices needs to receive the syslog in exactly the same for as originally sent by the device

So, I have been trying destinations as follows:

destination d_remote { udp("X.X.X.X" port(514) spoof_source(yes) template("$MESSAGE\n")); udp("Y.Y.Y.Y" port(514) spoof_source(yes) template("$MESSAGE\n")); };

I have also tried various combinations having "template" and adding FACILITY and LEVEL, but I am current failing to reproduce the original packet.

My results:

Template Result ========================================== None Relayed message has standard date and hostname added which weren't in original package. $MESSAGE\n Syslog facility and priority headers are stripped away from relayed messages.

Adding $FACILITY and $LEVEL/$PRIORITY doesn't seem to do what I need as they don't appear to go into the right fields, and syslog-ng appears to put KERN.EMERG in instead...

The version I am running on is 2.0.4.

If anyone has managed to get this working like this, I would be grateful of any pointers.

Thanks,

Joel

_______________________________________________ syslog-ng maillist - syslog-ng@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng Frequently asked questions at http://www.campin.net/syslog-ng/faq.html

Hi!

I am trying to work out if syslog-ng can act as a relay without doing "noticeable" changes to the syslog message in terms of what the syslog server sees.

The problem:

1) The device sends non-standard syslog messages

That might be a problem. You should try using the flags(no-parse); option in your source definition, however if you want to use macros then you'll be in trouble

2) The syslog needs to go to 2 end systems, the device supports 1

shouldn't be a problem

3) One of the end devices needs to receive the syslog in exactly the same for as originally sent by the device

might be tricky...

So, I have been trying destinations as follows:

destination d_remote { udp("X.X.X.X" port(514) spoof_source(yes) template("$MESSAGE\n")); udp("Y.Y.Y.Y" port(514) spoof_source(yes) template("$MESSAGE\n")); };

Instead of this you should use two different destination definitions: destination d_remote_one { ... }; destination d_remote_two { ... }; and later log { source(...); filter(...); destination(d_remote_one); destination(d_remote_two); };

I have also tried various combinations having "template" and adding FACILITY and LEVEL, but I am current failing to reproduce the original packet.

My results:

Template Result ========================================== None Relayed message has standard date and hostname added which weren't in original package.

that might happen even when you disable parsing of the message

$MESSAGE\n Syslog facility and priority headers are stripped away from relayed messages.

try using template("<$M_PRI> $MESSAGE\n");

Adding $FACILITY and $LEVEL/$PRIORITY doesn't seem to do what I need as they don't appear to go into the right fields, and syslog-ng appears to put KERN.EMERG in instead...

The first part of the message defines the facility/priority. Using macros you should use <$M_PRI> , however this depends on the parsing of the message... I think the really authorative answer to your questions might come from Bazsi, so you should wait for his answer :) Regards, Sandor -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.