syslogd hack field

L

luckylucks

Hello everyone, here goes my first question!

I have got many distributed pfSense devices through the internet. Those machines use syslogd(8) to log events to a remote machine running rsyslog.

My server can not manage to identify the source of the messages, at least not from its host field, as many of those pfSense boxes have got dynamic public IP and my ISP would not let me fix a FQDN.

The point is, is it possible for syslogd(8) to prepend some text at the beginning of the MSG field (or any other field)?

That would solve my issue, as in the server I should but write a rule similar to

if $MSG contains "this prepended text" then "voilà"
 
An external program and *.* |exec thisprog collector. in syslog.conf could do it, if you can manage making that change to all the senders.

Juha
 
Juha Nurmela said:
It could be a netcat script, or this.

Juha
Click to expand...

Okay before thankfully examine the file you attached, let me bow before you, let me ask, did you wrote all those Linux commands yourself? I'll post later with questions for sure.

Thanks!
 
Last edited by a moderator:
It was an old program, which used to send syslog with multicast. I just stripped away the multicast part.

There's an irritating feature in netcat: below script fails to exit when input is closed (as syslogd likes to do occasionally). nc keeps on waiting for input from network.

Third option came to mind: could rsyslogd differentiate your senders by source port ? -b :sport option to syslogd(8).

Juha


Code: 
#!/bin/sh

aka=kuikka
dest=127.1
dport=3000
sport=3514

while read month mday hms hostname message
do
  case "$mday" in
  ?) mday=" $mday" ;;
  esac
  echo "$month $mday $hms $aka $message"
done | nc -up $sport $dest $dport > /dev/null
 
Juha Nurmela said:
It was an old program, which used to send syslog with multicast. I just stripped away the multicast part.

There's an irritating feature in netcat: below script fails to exit when input is closed (as syslogd likes to do occasionally). nc keeps on waiting for input from network.

Third option came to mind: could rsyslogd differentiate your senders by source port ? -b :sport option to syslogd(8).

Juha


Code: 
#!/bin/sh

aka=kuikka
dest=127.1
dport=3000
sport=3514

while read month mday hms hostname message
do
  case "$mday" in
  ?) mday=" $mday" ;;
  esac
  echo "$month $mday $hms $aka $message"
done | nc -up $sport $dest $dport > /dev/null
Click to expand...


About the third option, I believe it is not the best work out as long as it is poorly scalable. If the number of distributed devices would grow too much, that system would ran out of available ports.

Thanks!
 
SirDice said:
You could replace the standard syslogd(8) with sysutils/syslog-ng or sysutils/rsyslog.
Click to expand...

Hey thanks for the reply,
I did already tried to use rsyslog as a client, but those devices run pfSense which runs a customized version of FreeBSD. I could not manage to get it working pretending it is a full FreeBSD system. Maybe I will give it a try if I run out of other means.
By the way, are you sure rsyslogd(8) can hack some field so that the server may filter the packet yet without using anything about its port or IP?

Thanks again
 
Last edited by a moderator:
luckylucks said:
By the way, are you sure rsyslog(8) can hack some field so that the server may filter the packet yet without using anything about its port or IP?
Click to expand...
Not sure about rsyslog, I haven't used it much. But you should be able to do it with syslog-ng.

If you can't change the 'client' side perhaps it's possible to use syslog-ng server-side?
 
Ahh.... I did not realize that
Code: 
*.* @collector.com
*.* |command
*.* |nc -up 514 collector.com 514
create different messages. First one is missing the hostname and the second one has no <pri>. The third one, combined with syslogd -ssv might be all that's needed.

Juha

But of course, syslogd -v does
Code: 
snprintf(fp_buf, sizeof fp_buf, "<%s.%s> ", f_s, p_s);
with an extra blank, just for the amusement factor
 
You must log in or register to reply here.
Back
Top