More and more security-related devices are capable of sending syslog messages via an encrypted TLS channel. So does the well-known Meinberg LANTIME NTP server with its “LTOS” operating system. (And all the other LTOS-based NTP servers like the IMS or SyncFire series.) Here’s how you can configure it:
If you don’t have a TLS-capable syslog server: here’s my tutorial with syslog-ng. I’m using a LANTIME M200 with Firmware-Build 7.06.013 for the following tests. The syslog-ng server version 3.25.1-3 runs on a Ubuntu 20.04.6 LTS (GNU/Linux 5.4.0-148-generic x86_64).
Basic Configuration
The configuration is quite simple: Head to Notification -> External Syslog Server and select the “Transport Protocol” as TLS rather than UDP or TCP. Please note that the port changes to the TLS default of 6514 and that the “TLS Peer Verify” is checked by default as well:
You will get into trouble if you don’t have imported the (root) certificate of your TLS-capable syslog server yet. ;) If so, nothing will be logged but you will see errors like this when capturing the traffic:
Please note that this is a good thing! This is how security should always work: with untrusted connections, no data should be transferred.
Hence, you should upload the root or self-signed certificate at Security -> Certificates -> CA Certificates like this:
After that, you’ll see successful TLS connections, that is: change cipher spec, followed by randomly looking application data:
Some Notes
One thing I immediately noticed is, that syslog messages are sent over IPv4 though the configured hostname is dual-stacked with both, an A and AAAA record. This is in contrast to any modern OS, on which IPv6 is preferred over legacy IP. (Fun fact: This seems to be a syslog-ng thing because I recognized the same behaviour on a Palo Alto Networks firewall.) At least this is not security related.
Another little caveat I noticed is the following: There is no check whether the certificate’s name or any of the subject alternative names correlate to the hostname which is specified for the syslog server. E.g.: If the hostname is set to “foo.something.com” (which resolves to the actual IP address of the syslog server), while the uploaded certificate has its name and SAN set to “bar.something.com”. The “TLS peer verify” succeeds, though the certificate is not valid for this specified hostname. However, in my mind, this is not a big problem, since the crucial point is to validate the public key, rather than the name. Though I would have expected that the whole certificate, incl. the name, would be checked.
Luckily, Meinberg took care of those issues and dealt with them. Have a look at the next blog post. ;)
Further Reading
Photo by Max Harlynking on Unsplash.