Even if the overwhelming majority of syslog users still uses the old RFC3164 syslog protocol, there are some people who use RFC5424. This RFC only describes the protocol but not the actual transport. The next two RFCs after RFC5424 describe UDP and TLS transport. There is also a dead by birth RFC for plain, unencrypted TCP transport with a note:
“ TheIESG does not recommend implementing or deploying syslog overplain tcp, which is described in this document, because it lacks theability to enable strong security [RFC3365].”
No wonder, that there are multiple incompatible implementations for this transport both in syslog-ng and rsyslog. Luckily the situation is not as bad as it sounds, one just needs to find the appropriate configuration options for both sides.
So why is it still used:
it has the advantage of structured logging and more reliable transportation of TCP without the configuration or performance overhead of encryption.
There are two different ways to configure syslog-ng to receive RFC5424 syslog messages. The first one is using the syslog() source driver.
source s_syslog {
syslog(
transport("tcp")
port(1514)
);
};
destination d_syslog { file("/var/log/syslogprot"); };
log {source(s_syslog); destination(d_syslog); };
To send logs to this destination from rsyslog, use the following configuration example:
*.* @@(o)192.168.15.1:1514;RSYSLOG_SyslogProtocol23Format
Please note the following differences from regular TCP forwarding:
- “(o)” configures proper framing
- “;RSYSLOG_SyslogProtocol23Format” adds the RFC5424 template
If you miss “(o)”, you will run into similar messages in syslog-ng:
Apr 25 17:18:30 linux-4xb2.site syslog-ng[7552]: Syslog connection accepted; fd=’21’, client=’AF_INET(192.168.15.129:52593)’, local=’AF_INET(0.0.0.0:1514)’
Apr 25 17:18:30 linux-4xb2.site syslog-ng[7552]: Invalid frame header; header=”
Apr 25 17:18:30 linux-4xb2.site syslog-ng[7552]: Syslog connection closed; fd=’21’, client=’AF_INET(192.168.15.129:52593)’, local=’AF_INET(0.0.0.0:1514)’
Please note the middle message about “invalid frame header”.
The second way to configure syslog-ng uses the network source driver introduced in syslog-ng OSE 3.4.
source s_network {
network(
transport(“tcp”)
port(“1514”)
flags(syslog-protocol)
);
};
destination d_syslog { file(“/var/log/syslogprot”); };
log {source(s_network); destination(d_syslog);};
In this case, the configuration on the rsyslog side looks pretty similar to the previous one, except that there is no “(o)” in front of the target hostname:
*.* @@192.168.15.1:6514;RSYSLOG_SyslogProtocol23Format
If you use “(o)”, logs will still arrive, but will look a bit strange.