Tag Archive: DNS logging


How to improve Windows DNS logging (audit and analytics):

Resources:

DNS logging (audit and analytics): https://technet.microsoft.com/en-us/library/dn800669(v=ws.11).aspx

Free tool:

http://www.networkstr.com/dnscentric/dns_log_converter

Scripts to parse DNS debug logs:

https://gallery.technet.microsoft.com/scriptcenter/Get-DNSDebugLog-Easy-ef048bdf

http://www.adamtheautomator.com/microsoft-dns-debug-log-script/

http://poshcode.org/4509

http://xianclasen.blogspot.fr/2016/01/dns-logging-in-windows-with-powershell.html

Introduction

Anyone who has worked with Security Incident and Event Management (SIEM) or Intrusion Detection/Prevention System (IDS/IPS) alerts knows it can be very, very difficult to track down the actual source of the network traffic. Tracking the source becomes even more difficult when it comes to finding the machine that attempted resolution of a known bad or suspicious domain.

The Cause: DNS architecture

The Domain Name System (DNS) architecture is the primary reason why it can be so hard to find the machine attempting to resolve a bad or suspicious domain. Most organizations are Microsoft based and rely on their domain controllers to perform DNS resolution. These domain controllers are configured to act as recursive resolvers, meaning they perform resolution on behalf of the client. Because of this, when you get a SIEM or IDS/IPS alert, the source IP address will generally belong to the domain controller. This causes problems, as it usually is not the domain controller that is infected, but some client behind it. Even if you are not a Microsoft based organization, there is usually some form of a recursive resolver in place, which is at a lower level in the network than the edge IDS/IPS that detects the activity.

Why do most organizations use a recursive resolver? The answer is simple: so the internet does not see all the internal client addresses as they resolve domains. If you use NAT on your firewall, it limits what the world is able to see, but makes managing of the firewall rules for DNS more difficult. It also causes more network traffic as these recursive servers are generally caching as well. In addition, it puts more control around the name resolution service to help spot anomalies and control behavior.

The Solution: Implement DNS logging or network architecture approach

Performance considerations

DNS server performance can be affected when additional logging is enabled, however the enhanced DNS logging and diagnostics feature in Windows Server 2012 R2 and Windows Server 2016 Technical Preview is designed to have a very low impact on performance. The following sections discuss DNS server performance considerations when additional logging is enabled.

 

Prior to the introduction of DNS analytic logs, DNS debug logging was an available method to monitor DNS transactions. DNS debug logging is not the same as the enhanced DNS logging and diagnostics feature discussed in this topic. Debug logging is discussed here because it is also a tool that is available for DNS logging and diagnostics. See Using server debugging logging options for more information about DNS debug logging. The DNS debug log provides extremely detailed data about all DNS information that is sent and received by the DNS server, similar to the data that can be gathered using packet capture tools such as network monitor. Debug logging can affect overall server performance and also consumes disk space, therefore it is recommended to enable debug logging only temporarily when detailed DNS transaction information is needed.

 

Enhanced DNS logging and diagnostics in Windows Server 2012 R2 and later includes DNS Audit events and DNS Analytic events. DNS audit logs are enabled by default, and do not significantly affect DNS server performance. DNS analytical logs are not enabled by default, and typically will only affect DNS server performance at very high DNS query rates. For example, a DNS server running on modern hardware that is receiving 100,000 queries per second (QPS) can experience a performance degradation of 5% when analytic logs are enabled. There is no apparent performance impact for query rates of 50,000 QPS and lower. However, it is always advisable to monitor DNS server performance whenever additional logging is enabled.

 

DNS Server logging must be enabled to record events from all DNS server functions

Log on to the DNS server using the Domain Admin or Enterprise Admin account.

Press Windows Key + R, execute dnsmgmt.msc.

Right-click the DNS server, select Properties.

Click on the Event Logging tab. By default, all events are logged.

Verify “Errors and warnings” or “All events” is selected.

If any option other than “Errors and warnings” or “All events” is selected, this is a finding

Log on to the DNS server using the Domain Admin or Enterprise Admin account.

Open an elevated Windows PowerShell prompt on the DNS server to which event logging needs to be enabled.

Use the Get-DnsServerDiagnostics cmdlet to view the status of individual diagnostic events.

All diagnostic events should be set to “True”.

If all diagnostic events are not set to “True”, this is a finding

Use the Set-DnsServerDiagnostics cmdlet to enable all diagnostic events at once.

Set-DnsServerDiagnostics -All $true

Also enable debug log rollover.

Set-DnsServerDiagnostics – EnableLogFileRollover $true

Advertisements

How to improve Windows DNS security (hardening):

Resources:

DNS logging (audit and analytics): https://technet.microsoft.com/en-us/library/dn800669(v=ws.11).aspx

Secure DNS Deployment Guide: https://technet.microsoft.com/en-us/library/ee649266%28v=ws.10%29.aspx

DNS security part 1: http://www.windowsecurity.com/articles-tutorials/misc_network_security/DNS-Security-Part-1.html

DNS security part 2: http://www.windowsecurity.com/articles-tutorials/windows_server_2008_security/DNS-Security-Part2.html

Understand man in the middle attack: http://www.windowsecurity.com/articles-tutorials/authentication_and_encryption/Understanding-Man-in-the-Middle-Attacks-ARP-Part2.html

External DNS Server Hardening: https://technet.microsoft.com/en-us/library/ee649266%28v=ws.10%29.aspx

Note: Root hints are used to let the DNS server know where to start the recursion process. Root hints normally point to the Internet root DNS servers so that you can resolve public host names using recursion.

However, if you don’t need to resolve public host names, you can edit the root hints file so that it only contains DNS servers on your intranet. By doing this, you can avoid sending private information about possible internal host names to public DNS servers.

Securing DNS with DNSSEC: http://www.windowsecurity.com/articles-tutorials/misc_network_security/Securing-DNS-Connections-Windows-Server-2008-R2-DNSSEC.html

 

Mitigating DNS security weakness :

Low-Level Security

Low-level security is a standard DNS deployment without any security precautions configured. You should deploy this level of DNS security only in network environments where there is no concern for the integrity of your DNS data or in a private network where there is no threat of external connectivity:

  • The DNS infrastructure of your organization is fully exposed to the Internet.
  • Standard DNS resolution is performed by all DNS servers in your network.
  • All DNS servers are configured with root hints pointing to the root servers for the Internet.
  • All DNS servers permit zone transfers to any server.
  • All DNS servers are configured to listen on all of their IP addresses.
  • Cache pollution prevention is disabled on all DNS servers.
  • Dynamic update is allowed for all DNS zones.
  • User Datagram Protocol (UDP) and TCP/IP port 53 is open on the firewall for your network for both source and destination addresses.

Medium-Level Security

Medium-level security uses the DNS security features that are available without running DNS servers on domain controllers and storing DNS zones in Active Directory:

  • The DNS infrastructure of your organization has limited exposure to the Internet.
  • All DNS servers are configured to use forwarders to point to a specific list of internal DNS servers when they cannot resolve names locally.
  • All DNS servers limit zone transfers to servers that are listed in the name server (NS) resource records in their zones.
  • DNS servers are configured to listen on specified IP addresses.
  • Cache pollution prevention is enabled on all DNS servers.
  • Dynamic update that is not secure is not allowed for any DNS zones.
  • Internal DNS servers communicate with external DNS servers through a firewall with a limited list of allowed source addresses and destination addresses.
  • External DNS servers in front of the firewall are configured with root hints that point to the root servers for the Internet.
  • All Internet name resolution is performed by using proxy servers and gateways.

High-Level Security

High-level security uses the same configuration as medium-level security. It also uses the security features that are available when the DNS Server service is running on a domain controller and DNS zones are stored in Active Directory. In addition, high-level security completely eliminates DNS communication with the Internet. This is not a typical configuration, but it is recommended whenever Internet connectivity is not required:

  • The DNS infrastructure of your organization has no Internet communication by means of internal DNS servers.
  • Your network uses an internal DNS root and namespace, where all authority for DNS zones is internal.
  • DNS servers that are configured with forwarders use internal DNS server IP addresses only.
  • All DNS servers limit zone transfers to specified IP addresses.
  • DNS servers are configured to listen on specified IP addresses.
  • Cache pollution prevention is enabled on all DNS servers.
  • Internal DNS servers are configured with root hints that point to the internal DNS servers that host the root zone for your internal namespace.
  • All DNS servers are running on domain controllers. A discretionary access control list (DACL) is configured on the DNS Server service to allow only specific individuals to perform administrative tasks on the DNS server.
  • All DNS zones are stored in Active Directory. A DACL is configured to allow only specific individuals to create, delete, or modify DNS zones.
  • DACLs are configured on DNS resource records to allow only specific individuals to create, delete, or modify DNS data.
  • Secure dynamic update is configured for DNS zones except the top-level zones and root zones, which do not allow dynamic updates at all.