# Syslog file for remote system not getting data



## ProServ (Jan 30, 2020)

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 (Jan 30, 2020)

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 (Jan 30, 2020)

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 (Jan 30, 2020)

SirDice said:


> 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.
> 
> 
> ```
> ...


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 (Jan 30, 2020)

genneko said:


> 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 (Jan 30, 2020)

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 (Jan 30, 2020)

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 (Jan 30, 2020)

SirDice said:


> 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 (Jan 30, 2020)

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 (Jan 30, 2020)

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 (Jan 31, 2020)

Hi, let me add a bit more info.


genneko said:


> 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.



genneko said:


> 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).


----------

