May 14, 2020 linuxdnsossecurity

DNS Log Collection on Linux

By John Kirch

ALL SIEM STRATEGY SECURITY ANNOUNCEMENT DEPLOYMENT COMPLIANCE COMPARISON RSS

Be sure to read Part 1 and Part 2 of our series in case you missed them.

DNS Log Collection on Linux

In the third, closing part of our series on DNS log collection, we discuss DNS logging on Linux using open source software. From the numerous open source DNS server implementations available, we tried to include the more popular ones and summarized what is involved in collecting logs from them. Even though the software discussed here is available for Windows and other platforms like BSD and macOS, our primary focus here is on Linux-based, open source DNS server implementations. We only cover the general requirements based on the most recent information available at the time of writing. Always make sure to consult the documentation for your specific flavor of DNS server implementation.

Common Linux DNS Server Implementations

BIND 9 DNS Server: A large majority of Linux DNS servers are powered by BIND, making it the de facto standard DNS Server on this platform. Log messages are organized into categories and log destinations are configured as channels. To collect logs, the BIND configuration file named.conf needs to be edited, which is located in /etc/namedb (FreeBSD), /usr/local/etc (FreeBSD non-base install), or /etc (Unix/Linux).

To add channels (either a Syslog stream or file-based) and to determine which categories gets logged to which channel, see BIND Logging - some basic recommendations. For full details about BIND 9 configuration, see the ISC BIND 9.x Manuals. The NXLog User Guide also has a section on both file-based and Syslog implementations of BIND 9 logging.
NLnet Labs NSD Open Source DNS Server and Unbound: Unbound is a validating, recursive, caching DNS resolver maintained by NLnet Labs. It logs to Syslog by default, but can be configured to log to stderr by changing the log file setting in unbound.conf, which is located in either the /usr/local/etc/unbound, /etc/unbound, or /etc directory, depending on the distribution. For further configuration details, see the Manual Pages for nsd.conf and unbound.conf.
PowerDNS Authoritative Nameserver and Recursive Server: For the PowerDNS Authoritative Nameserver, the configuration settings for logging are contained in pdns.conf. It supports numerous logging options and ring buffers. By default, the PowerDNS Authoritative Nameserver does not log to Syslog on systemd-based operating systems. However, if enabled, Syslog can be used to separate files for the differing priorities—preventing lower priority messages from obscuring important ones. The PowerDNS Recursor can monitor its own performance and perform a configurable amount of operational logging. See Operating the PowerDNS Recursor for more details on logging.
Knot DNS Authoritative Name Server: The Knot DNS Server can be configured to log to Syslog or to the systemd journal if systemd is enabled. File-based logging is supported as well. Knot DNS is configured using the knot.conf file containing 12 main sections in a simplified YAML format. Six logging severity levels are available.
CoreDNS DNS Server: The CoreDNS DNS Server utilizes the log plugin to enable logging on the Corefile configuration that is used. See the Configuration section of the CoreDNS Manual for more details.
Dnsmasq DNS Network Infrastructure: Dnsmasq is a lightweight, easy to configure DNS forwarder, designed to provide DNS services on small-scale networks. Dnsmasq accepts DNS queries and either answers them using a small, local cache or forwards them to a recursive DNS server. Its logging options are all file-based.

DNS Log Sources

Regardless of which DNS server is deployed, DNS event logging is available from two types of sources:

Syslog daemon which listens on UNIX domain sockets like /var/log on Ubuntu.
File-based logging, a typical example being /var/log/auth.log on Ubuntu.

Changes to the DNS configuration files are of high value and be monitored by DNS audit logging, which provides details of changes to DNS configuration files and supports user-defined tags. DNS client queries can be collected directly from Syslog or from log files, as defined in the DNS server’s main configuration file(s).

Collecting DNS Logs from Syslog

Collecting DNS-specific events from Syslog is the preferred method, when applicable, as it offers some distinct advantages:

Syslog is ubiquitous for all Linux distributions and is already running by default, and thus does not add any performance overhead.
Syslog is an industry standard which offers strong cross-platform compatibility and is supported by almost every SIEM.

Note	Not every third-party application adheres closely to Syslog standards. In some cases, valuable metadata or subfields can be embedded in the generic `Message` field.

BIND 9 DNS Event Sample Collected from Syslog, in JSON Format.

{
  "EventReceivedTime": "2019-04-29T22:30:20.856069+01:00",
  "SourceModuleName": "syslog",
  "SourceModuleType": "im_uds",
  "SyslogFacilityValue": 3,
  "SyslogFacility": "DAEMON",
  "SyslogSeverityValue": 6,
  "SyslogSeverity": "INFO",
  "SeverityValue": 2,
  "Severity": "INFO",
  "Hostname": "debian",
  "EventTime": "2019-04-29T22:30:20.770000+01:00",
  "SourceName": "named",
  "ProcessID": "16373",
  "Message": "client @0x7f9b6810ed50 10.80.0.1#44663 (google.com): query: google.com IN A +E(0) (10.80.1.88)",
  "BINDSeverity": "info",
  "Category": "queries",
  "Client": "10.80.0.1#44663",
  "ClientID": "@0x7f9b6810ed50",
  "LocalAddress": "10.80.1.88",
  "OriginalQuery": "google.com",
  "QueryClass": "IN",
  "QueryFlags": "+E(0)",
  "QueryName": "google.com",
  "QueryType": "A"
}

Collecting File-based DNS Logs

Although file-based log collection may seem like a consolation prize when compared to the advantages of collecting DNS events from Syslog, it is the only game in town for some DNS server implementations.

Parsing: Syslog parsing is very generic and by design has limitations with regard to its parsing capabilities. It is not always possible to precisely extract exactly the fields needed.
Performance: DNS logs need to be parsed and reformatted into structured data, possibly on the fly, without needing to save the reformatted data to disk prior to sending over the network for further processing. This is a "must have" requirement in order to make sure the logging performance stays adequate, as writing files to disk could have a negative impact on performance.
Versatility: More often than not, log files on Linux systems are written as flat files. The same holds true for DNS servers running on Linux. Every DNS implementation examined here supports file-based logging. It is their lowest common denominator.

DNS logging should also include DNS Audit Logging an integral part of security monitoring. Being able to provide timely access to security analysts of any changes in the more than 40 types of resource records contained in DNS zone files can be pivotal when malicious DNS activity is occurring. Since Linux-based DNS server implementations use flat files for maintaining their server configuration and DNS zones, the only way to collect these events is file-based.

Event Sample of BIND 9 Configuration Change, in JSON Format.

{
  "type": "CONFIG_CHANGE",
  "time": "2020-02-21T01:30:36.027000+01:00",
  "seq": 31,
  "auid": 4294967295,
  "ses": "4294967295",
  "subj": "=unconfined",
  "op": 0,
  "key": "conf-change-bind",
  "list": "4",
  "res": "1",
  "EventReceivedTime": "2020-02-21T01:30:36.034819+01:00",
  "SourceModuleName": "audit",
  "SourceModuleType": "im_linuxaudit"
}

Performance Considerations

Administrators need to be aware of the performance implications of DNS logging. Some of these considerations include:

Logging queries received by a DNS resolver or logging all DNS requests can be problematic for high traffic sites.
DNS servers can be under high load from receiving queries, interpreting queries, performing lookups, sending responses back to clients, and creating event logs. Writing logs to disk could put an additional load on DNS servers which can have a negative impact on its overall performance.
In addition to requesting DNS servers to format log messages, additional log enrichment may be required. This is because logs are not normally structured for further processing.

What NXLog Can Do?

Standardize and normalize the logs: If you have had the opportunity to work with more than one DNS server implementation, you may notice the lack of standardized formats. This could be problematic when collecting and reading DNS logs, even after converting them to a portable and readable format. It is also problematic when it comes to processing the logs and trying to find a common way to treat log events. NXLog provides Syslog-compliant parsing of fields right out of the box. It can parse data into a more structured format such as JSON.
Integrate with multiple endpoints: In cases where you need to send a portion of the DNS logs to a log management solution, and the security logs to a SIEM, being able to use a single agent capable of integrating with multiple endpoints enhances performance and is better for infrastructure maintenance.
Reduce storage requirements: DNS events tend to be noisy and there is the additional challenge of managing the storage requirements for these logs. We have published a white paper, Reduce data size and cut SIEM licensing costs, which expands on this topic and introduces modules that can be used to reduce unnecessary log data.
Audit Logging: Linux DNS server configuration files may require audit logging. See DNS Audit Logging for configuration information and event samples, like the im_linuxaudit module for collecting Audit System logs directly from the kernel.
File Integrity Monitoring: See the section File Integrity Monitoring for more information on file integrity monitoring as another option to monitor DNS server configuration files.
Network Packet Capture Logging: You can set up packet capture and packet logging of DNS packets to monitor metadata.
Parsing: Since Linux servers follow basic logging formats, additional parsing can be implemented for establishing a consistent log format. For BIND 9, see the Parsing BIND 9 Logs section.

Conclusion

One of the challenges of DNS logging on Linux is the lack of standardization across the various implementations. These differences exist due to the decentralized nature of developing open source technologies. Logging severities, logging features, and log collection options will be different for each implementation. These differences can become a pain point for multi-platform deployments, consultancies, and MSSPs handling multiple DNS servers. However, with proper log collection configuration both on the log collector and on the DNS server, you can tackle such issues as reducing DNS alert fatigue, reducing breach impact by finding perpetrators faster, cutting back on data usage, and reducing licensing costs by filtering for important events. With the right tools and resources, you can widen your detection footprint of potential attacks by including DNS logging.

The Importance of DNS Logging in Enterprise Security is not to be underestimated. Reduce the cost of DNS security and increase efficiency by managing DNS logs via centralized log collection, both on Linux and Windows.