Enhancing Data Understanding
Rocco Gagliardi
Log messages are generated on many system components and applications on said systems. To collect them centrally for management and analysis purposes, transmission over the net is necessary.
It is vital to expose the message and involved components as little as possible in order to assure Confidentiality/Integrity/Availability.
Log messages are normally transmitted using syslog protocol. By default, syslog uses UDP packets to fire and forget messages from client to one or multiple servers. UDP packets can easily be spoofed, delivery is not guaranteed and information is transmitted in clear text.
For many years, syslog daemons offer the possibilities to use TCP as transport protocol. TCP has many advantages over UDP: it is harder to spoof and delivery is guaranteed but information is still transmitted in clear text.
To solve the clear text problem, some syslog daemons offer the possibility to encrypt the message using TLS: just deploy certificates and encrypted transmissions between syslog daemons supporting TCP/TLS will start.
Easy.
Too easy!
The solution above requires that all involved syslog daemons:
The requirements can be satisfied by syslog daemons like rsyslog, syslog-ng, Snare and others. But what’s about a syslog daemon in a switch? Does it support TLS?
If we cannot use TLS, it is reasonable to use at least TCP. A large number of devices offer the option to send syslog using TCP packets. Experience shows that even if a syslog daemon offers TCP support, the server polling feature is not always offered! That means: if the server goes down or isn’t – for any reason – reachable, the client may stop sending messages and may require a restart to start sending messages again!
This behaviour is still hard to monitor and a correction takes time. If you have 100 of these clients you must restart each client.
After many implementations, we ended up with a design balancing the security and the manageability of the systems:
The following picture shows the setup:
Keep in mind that many syslog daemons use also the best effort principle, so the generation of messages is not guaranteed.
syslog is a great protocol but each implementation may be different, supports different features and may create unexpected behaviours. To avoid surprise, use the KISS principle at least for network devices, carefully test the client and use the advanced features only with well know daemons.
Our experts will get in contact with you!
Rocco Gagliardi
Rocco Gagliardi
Rocco Gagliardi
Rocco Gagliardi
Our experts will get in contact with you!