Syslog file for remote system not getting data

[ProServ]

Hi, configured a FreeBSD internal server to be a syslog server for a remote device. The file /var/log/client.log is still 0 bytes. I ran a tcpdump in the FreeBSD syslog server to see if any packets were coming in. The pcap file has plenty of data but for some reason /var/log/client.log is not getting it. Have tried restarting services and rebooting the server to no avail

syslog.conf has:
.
.
.

+xxx.137.209.230
*.*                                             /var/log/client.log
include                                         /etc/syslog.d
include                                         /usr/local/etc/syslog.d

rc.conf has:
.
.
.

syslogd_enable="YES"
syslogd_flags="-4 -a xxx.137.209.230 -vv"

newsyslog.conf has:

/var/log/client.log                      640             5       100             *       JC
<include> /etc/newsyslog.conf.d/*
<include> /usr/local/etc/newsyslog.conf.d/*

Thanks.

 

[SirDice]

Run a tcpdump(1) and see if you actually get some traffic on port 514/UDP. Also verify with sockstat(1) to see if the port is opened.

+xxx.137.209.230

Seriously reconsider throwing this over the internet. Syslog is unencrypted and UDP, easy to spoof and capture.

% cat /etc/syslog.d/remote.conf
*.*     @192.168.11.197:5000

 

[genneko]

Hello,
if the remote device uses the source port other than 514(syslog), changing syslogd_flags's -a option from -a xxx.xxx.xxx.xxx to something like -a xxx.xxx.xxx.xxx/32:* or -a xxx.xxx.xxx.xxx/32:SRCPORT (replace SRCPORT with the actual port number) might help.

 

[ProServ]

Run a tcpdump(1) and see if you actually get some traffic on port 514/UDP. Also verify with sockstat(1) to see if the port is opened.

+xxx.137.209.230

Seriously reconsider throwing this over the internet. Syslog is unencrypted and UDP, easy to spoof and capture.

% cat /etc/syslog.d/remote.conf
*.*     @192.168.11.197:5000

This is for a remote ATA that cannot register. The tcpdump ran on our syslog definetly shows data. Nothing in the data that would be useful to an attacker. Since the ATA IS sending out REGISTER packets,. that means the clients meraki (the king of JUNK routers) located at the place with the ATA most likely is blocking it.

 

[ProServ]

Hello,
if the remote device uses the source port other than 514(syslog), changing syslogd_flags's -a option from -a xxx.xxx.xxx.xxx to something like -a xxx.xxx.xxx.xxx/32:* or -a xxx.xxx.xxx.xxx/32:SRCPORT (replace SRCPORT with the actual port number) might help.

Hi Genneko, thanks for your info. Changed the line in /etc/rc.conf and rebooted now waiting to see if the data gets in the file.

 

[ProServ]

So far nothing getting into the file -rw-rw-rw- 1 root wheel 0 Jan 29 21:02 /var/log/client.log
I made the file 666 to be sure it can get written to.

I will run a tcpdump and see what it shows.

 

[ProServ]

Yeah the tcpdump definitely shows the information in the packets. The /var/log/file.log is still 0 bytes though.
Ran tcpdump as:

# tcpdump -i em0 udp port 514 -c 500 -w /tmp/client.pcap

 

[ProServ]

Run a tcpdump(1) and see if you actually get some traffic on port 514/UDP. Also verify with sockstat(1) to see if the port is opened.

# sockstat |grep 514
root syslogd 785 6 udp4 *:514 *:*

 

[genneko]

I suspect that the following line in /etc/syslog.conf doesn't work.

+xxx.137.209.230

Does the remote device have a resolvable hostname?
If so, how about replacing the IP address with the hostname?

+hostname

Or, according to syslogd(8), adding '-n' to syslogd_flags might let you continue to use +xxx.137.209.230.

As an aside, everytime I have trouble with syslog configuration, I temporarily stop the syslogd service and manually run syslogd in the forground (-F) with debugging (-d) and verbose modes (-v) on. (Or it might be better to just add "-d -v" to syslogd_flags and restart the service.)
Then I generate some logs with logger(1) and see how syslogd handles them by watching its debug messages.

 

[genneko]

Another side note.
According to syslogd(8), -a x.x.x.x doesn't mean a single peer x.x.x.x.

If ipaddr is IPv4 address, a missing masklen will
be substituted by the historic class A or class B netmasks if
ipaddr belongs into the address range of class A or B, respectively,
or by 24 otherwise. Ifipaddr is IPv6 address, a missing
masklen will be substituted by 128.

For example, -a 10.10.10.100 seems to be treated like -a 10.0.0.0/8 !
Specifying /32 ( -a 10.10.10.100/32) lets me avoid allowing an unintentionally wider range.

 

[genneko]

Hi, let me add a bit more info.

Does the remote device have a resolvable hostname?

I mean that the remote device's IP address has a DNS PTR record or an /etc/hosts entry.

Then I generate some logs with logger(1) and see how syslogd handles them by watching its debug messages.

It seems that logger(1) uses a random source port by default. So a remote syslogd(8) has to have -a (allowed peer) option values suffixed with :* (from any source port), or logger has to be run with -S :514 (source address/port with the address omitted here).