The release candidate of version 3.7 of Turris OS – the OpenWRT-based operating system of Turris Omnia routers – is now available. Among many other changes, this updates syslog-ng from version 3.0 to 3.9, so it adds about seven years’ worth of new syslog-ng features, including new parsers, filters, formatting options, destinations, and performance enhancements.
Some of the new features didn’t make the cut of course, since they require extra dependencies, which do not make sense on a tiny ARM box. These are either too resource intensive – Java-based destinations, like Elasticsearch – or are simply rarely used. If you really need them, you can still forward log messages to another syslog-ng server and process or store log messages there. That’s the method I recommended in my earlier blogs.
Even just listing all new features since version 3.0 would fill up many pages. So instead of listing everything, I highlight a few new features that are particularly useful on the Turris Omnia.
Performance and reliability
The syslog-ng application was designed for performance right from the beginning, and we improved on that solid foundation ever since, like with the introduction of multi-threading.
Support for disk-based buffering, which was added recently, is another handy improvement. Here’s what it does: if you send your logs to a remote machine or a cloud service like Loggly, you can make sure that no messages are lost, even if the service is temporarily down.
Parsers
Over the years, many different parsers were added. These help to extract information from log messages and create new name-value pairs from them, which later on can be used for:
- filtering messages – for example, based on the user name in the log message,
- reformatting messages as required by the destination – for example, the fields of an ssh login message could be formatted as a JSON message.
New parsers in syslog-ng include:
- PatternDB: Using an XML database of log messages, this parser can find important information in unstructured log messages – for example, an ssh login message on the Turris.
- JSON: Without parsing, a JSON message is treated as a single text field by syslog-ng. Parsing the message creates name-value pairs from fields in the message. For example, if you install Suricata Intrusion Detection System (IDS) you could use this parser to filter on the content of Suricata logs, as these logs are formatted as JSON.
- CSV: Parses columnar data, like Apache access logs.
- key=value: Most firewall logs are in this format so this parser has a pretty wide range of uses.
Formatting
You could use templates already in version 3.0 but with the introduction of template functions, there is a whole new level of possibilities. Template functions work on name-value pairs. There are many of these, I would name only a couple here:
- format-json: Creates a JSON string from name-value pairs. Many applications expect JSON as input.
- hash: Creates a hash of the name-value pair. It can be used, for example, for anonymization.
Filtering
The inlist() filter can compare a value from a name-value pair with a list of values in a text file. There are many different IP or hostname lists on the Internet about known spammers, malware command and control machines, and others. A poor man’s SIEM can be created using syslog-ng message parsing and the inlist() filter combined with one of the freely available lists.
Destinations
Many of the new destinations need some weird dependencies, so they are not available on the Turris Omnia (and are also missing from most Linux distributions). However, a few new destinations are available on the router. First of all, encrypted network connections are now supported, so logs can be sent securely even over the Internet. Then, there is the syslog-ng configuration library (SCL), which makes it possible to use many different logging-as-a-service providers easily, hiding the complexity of their configuration.