Introduction
Welcome to the fourth part of this series on DNS and domain logging. The aim of this post is to focus on covering log collection on Linux and other Unix-like platforms. While enterprise environments nowadays are hybrid, rather than completely homogenous, I decided to use this post to focus on another telemetry event standard- syslog daemon (syslogd) and Syslog message logging.
This post will start with a sample of log collection deployment featuring a Linux DNS server, followed by a brief overview of the meaning of these log source samples, and then finished off with Linux auditing. If you are working with Windows Event Log data and Microsoft deployments, please see part 3 of this series.
Linux Log Deployment Scenario
List of DNS Servers that support Linux/Unix-like platforms:
- BIND 9 ISC DNS Server.
- NLnet Labs (created the implementation of DNSSEC) NSD DNS Server and Unbound.
- PowerDNS Authoritative Nameserver and Recursive Server (includes a NOD or Newly Observed Domains feature).
- KnotDNS Auth Name Server.
- CoreDNS DNS Server.
- Dnsmasque DNS Forwarder.
From Source to SIEM
The following is a Linux DNS server example deployment, featuring one infrastructure source – the BIND 9 DNS Server.
From Source (BIND 9 DNS Server and auditd Events)
Starting with a BIND 9 DNS server, two main sources of telemetry are defined—audit logging rules and the DNS server configuration file which is used to define a variety of logging rules.
Example Source 1: Audit Logging Rules
These define the rules for collecting auditing logs, which can inform potential infrastructure attacks such as unauthorized DNS server configuration changes. Changes attacking file or folder permissions to the configuration file, deleting logs, and disabling logging are other forms of infrastructure attacks. A lack of visibility with these events form the breeding ground for lateral movement attacks originating from the DNS server and other associated infrastructure.
Example Source 2: DNS Server Configuration File
A portion of the DNS server configuration file covers the server logging criteria, such as:
- The types of DNS events to log (query only, query and response)
- How detailed the events are (such as verbose)
- The types of events to collect (such as warning only events or all events ranging from informational to warning)
The actual logging criteria and configuration will differ for each DNS server implementation. For BIND 9, here is one such example of the logging statement grammar from their user manual:
logging {
category string { string; ... };
channel string {
buffered boolean;
file quoted_string [ versions ( unlimited | integer ) ]
[ size size ] [ suffix ( increment | timestamp ) ];
null;
print-category boolean;
print-severity boolean;
print-time ( iso8601 | iso8601-utc | local | boolean );
severity log_severity;
stderr;
syslog [ syslog_facility ];
};
};
To SIEM
Within the BIND DNS configuration file, one can specify certain events to write to disk, or and instead to be sent via TCP/UDP stream directly to a log management server. In the BIND 9 DNS server, this is defined in the channel portion of the configuration file. This informs the destination of the messages selected for the channel—either to go to a file, to a particular syslog facility, to the standard error stream (stderr), or to null (discarded). The events in this deployment sample, just the security events, are sent to the Syslog stream and written to disk (/var/log/security_events.log).
The events should be written in a standard format. There are various ways to write and transport event data. For Syslog, these are BSD Syslog, IETF (implementation that precedes BSD) Syslog, CEF (or Common Event Format, an ArcSight implementation), LEEF (Log Event Extended Format, a proprietary format in relation to IBM QRadar), Snare Syslog. There are also other accepted formats, like JSON.
The appropriate way to enrich and write events are detailed in your SIEM and log collector documentation. Regardless, enrichment happens as part of the log collection process on the DNS server as well as the log centralization server instance depending on the deployment requirements. Potentially on the SIEM, the events may be consumed and presented as “raw” events if it has not been correctly enriched. There may also be additional rules to route these logs as not all logging may have an immediate security value, such as logging for debugging purposes.
From the SIEM side, further work is to be done to enrich the logs for analysis, automation rules, and more. For example, it needs to be clear that a key-value pair for domain metadata exists as it forms the basis for DomainTools App for Splunk, and the metadata source should be relevant regardless of the platform source.
BIND DNS Server Event Sample
About BIND 9 DNS Server
BIND is a widely-used DNS open source software, BIND 9 is currently maintained by the ISC (Internet Systems Consortium). BIND software includes a Domain Name Resolver which resolves queries about names via communicating these to appropriate servers and responding to the servers’ replies. The BIND Domain Name Authority server answers requests from resolvers. Below is an example from the Resolver.
BIND 9 named.conf Example
The configuration files for BIND 9 logging cover the how, what, and where. Below is an example to log queries into a file.
logging {
channel query {
file "/var/log/queries.log";
print-severity yes;
print-time yes;
};
category queries { query };
};
BIND 9 DNS Resolver Snippet
As a semi-structured log message, below is a sample log from a test environment for example.com query:
30-May-2020 11:11:11.553613 queries: info: client @0x7f39604b8660 127.0.0.1#50587 (example.com): query: example.com IN A +E(0)K (127.0.0.1)
While the above is human-readable, it is not necessarily consumable in your SIEM and may be presented as a raw log and not usable for further processing. With parsing and enrichment taking place, then the unstructured message is split up into this type of key value pair:
EventTime: 2020-05-30T11:11:11.533613+01:00 Category: queries Severity: info Client: 127.0.0.1#50587 Address: 127.0.0.1 Query: example.com Type: A Class: IN Flags: +E(0)K
Therefore, the metadata residing in important fields, such as in the Query field, has value for additional processing. For example, one of the DomainTools integrations revolves around the ability to process domains that arise within the network perimeter. In which case, you will want each Query to be processed as part of this work since after all, it is part of an event that has taken place in the perimeter. Also, you may notice that event timestamp is already set to log in high-precision timestamps and not only that, the EventTime is in the ISO8601 standard, with milliseconds and timezone added at the end (UTC+01:00), to ensure consistency and accuracy in timestamps.
Linux DNS Audit Logging
Apply audit logging to your DNS server in order to track security-relevant events. Applying audit logging rules allows for more targeted security events to be tracked. Knowing more about the auditing system in your platform is useful as you set up audit logging rules and read the events but below is an example.
BIND 9 Linux Audit Logging Sample:
Please see your platform documentation for the auditing rules (if you don’t have one at hand, you can refer to the RHEL documentation on Linux Audit Logs).
To watch /etc/bind/ for modifications and add a tag:
-w /etc/bind/named.conf -p wa -k conf-change-bind9
Result snippet in key value pairs (not raw log) format:
type: CONFIG_CHANGE UID: 0 comm: nano exe: /bin/nano Key: conf-change-bind9 EventTime: 2020-05-30T12:19:20.055718+01:00
A rule to watch /etc/bind is added to create logs should there be write access to, and every attribute change of the file named.conf in the BIND 9 server. When this is observed, a log is recorded with the tag conf-change-bind9.
The result snippet should be human-readable. The CONFIG_CHANGE is the audit record type observed. The uid code, which is 0, indicates that it was a superuser account that changed the configuration file with the nano editor (and invoking the nano command).
When there is audit logging set up for these and other events, the administrator can refer to their own platform documentation to read the audit rules. One can also observe the trail of audit logs; for example, they can see which utility was used to change the configuration file.
Final Questions
With this post, you have been introduced to a sample BIND 9 DNS log collection deployment on a Linux/Unix-like platform, with an event sample of both a resolver event and an auditing event of a server configuration change. Feel free to go back to the beginning and check whether your deployment has covered the following:
- What monitoring information on DNS and domain activity can be obtained from your existing sources?
- Which areas need to be expanded in order to improve your logging visibility, in particular for metadata containing domain and DNS logs?
- What other opportunities are there to increase your log collection scope overall?
- Which of these sources lead to better intelligence for your own use cases?
- Is your current log deployment meeting your final phase needs in terms of intel for threat hunting, incidence response, orchestration, automation, etc.
While it is out of the scope to dive deep into actual deployment details (such as more configuration samples, DNSSEC logging, and more), you can check your platform and DNS server documentation, as well as your own collector and SIEM documentation, to see what configurations need to be applied and what options are available.
Use DomainTools integrations and APIs to further enrich relevant events with DNS and domain intelligence—Domain Risk Score—as well as use domain IOCs with the Iris platform. Use DomainTools as part of your proactive and reactive defense, in addition to targeted logging.
