DNS Security Quickstart Guide

About this Document

This document describes how AXS Guard's DNS security feature should be deployed to guarantee optimal results for networks where clients do not rely on AXS Guard for DHCP and DNS, e.g. Microsoft environments using Active Directory Domain Services.

Requirements

The DNS security feature encompasses two essential components: SecureDNS and DNS filtering. Each of these components can be used separately.

DNS filtering requires a Comfort Threat Protection Pack. To combine both components, a Premium Threat Protection Pack and license are required. Contact sales@axsguard.com if you wish to learn more about this feature or to upgrade your existing license.

Licensing & Feature Activation

1. Log in to AXS Guard and start the license wizard to import your license, then activate the desired DNS security features.

   

2. After activating the feature, navigate to Network > General to configure your DNS security options.

   

3. Verify if the dns-internal and dnscache services are both running by navigating to System > Status > Services (look for dns).

   

Preparation

To have full visibility of malicious DNS requests originating from devices in your network, the secure LAN IP address of AXS Guard should be configured as their preferred DNS Server. You can manually set a preferred DNS server for devices in your network or automatically via DHCP (a.k.a. DHCP option 6).

Note that only AXS Guard is able to handle DNS requests via Secutec's internet-facing SecureDNS servers; they cannot be accessed directly, unlike open DNS resolvers.

It is therefore crucial to configure your own DNS servers so they always use AXS Guard to resolve hosts and IP addresses on the Internet.

Equally important is that reverse DNS resolution is also correctly configured. Especially for Active Directory environments which rely heavily on forward and reverse DNS resolution to correctly locate and use resources on a network, e.g. when using Kerberos authentication.

Steps to take:

• Make a list of all your internal domains, especially those configured for Active Directory.
• Make a list of all internal reverse lookup zones, e.g. 192.168.250.0/24 matches the following reverse DNS lookup zone: 250.168.192.in-addr.arpa.
• Make a list of all your internal DNS servers. More often than not, these are the same as your Microsoft Domain Controllers (DC).
• Configure DNS forwarding on AXS Guard:
  • Internal zones -> use your internal DNS server.
  • Internal reverse zones -> use your internal DNS server.
• Once DNS forwarding is set up correctly, update the configuration of your internal DNS server(s) so they use AXS guard as their primary DNS server to resolve hosts on the Internet.
• Add the sec-dns-tcp firewall rule to the AXS Guard stat-sec firewall policy to allow retransmission, i.e. DNS queries which exceed the UDP size limit of 512 bytes.
• Change the configuration of your DHCP server, so clients automatically use AXS Guard as their preferred DNS server (option 6).

Note

In small networks, AXS Guard itself often functions as the internal DHCP and DNS server. In this case, there is nothing to prepare.

Just configure your devices and computers to use AXS Guard as their preferred DNS server. This can be achieved manually by configuring the advanced TCP/IP Settings for each device or automatically through DHCP.

Once resolving via AXS Guard runs smoothly, make sure that no devices in your network can bypass AXS Guard to resolve hosts on the Internet. One way to achieve this, is by redirecting rogue DNS traffic (UDP port 53) going through AXS Guard.

DNS is a critical component for network security and stability. It can be made more robust through the installation of an AXS Guard High Availibility cluster, where devices and computers must be configured to use the virtual IP address of the AXS Guard HA cluster as their preferred DNS server.

Configuring your Clients and Servers

AXS Guard DHCP Server

Configure DHCP option 6 on AXS Guard, so it can pass the correct DNS server IP address to all the hosts in your network. Note that this is only required if you are using AXS Guard as your DHCP server.

Third-party DHCP Server

If you are not using AXS Guard for DHCP services, configure DHCP option 6 on your DHCP server, so it passes the LAN IP address of AXS Guard to all the hosts in your network, e.g.

Manual IP Address Configuration

For optimal results and protection, you want your internal DNS server(s) to forward all DNS lookups for external domains and IP addresses to AXS Guard.

To forward these lookups, add the LAN IP address of AXS Guard as a DNS forwarder in the Windows DNS management console.

For security and privacy reasons, we advise you not to add any open DNS resolvers to your server configuration.

Authenticated Users

The AXS Guard Single Sign-On (SSO) tool is designed to securely and transparently authenticate users against AXS Guard. After successful authentication, users are granted firewall and web access privileges based on their credentials.

Installation of this tool is recommended, as it provides critical host information in the DNS Security dashboard, which can be used to get insights into malicious DNS activity and easily isolate devices from your network for further investigation and troubleshooting.

Computers

Hostnames of computers that have been registered on AXS Guard and that are generating potentially malicious DNS requests, will also appear on the DNS Security dashboard.

Note that assigning AXS Guard security policies at the computer level is only appropriate for servers with a static IP address. In all other instances, Able recommends assigning security policies at the user or group level and to enforce user authentication.

Blocking Rogue DNS Requests

It is important to note that DNS security by itself doesn't prevent users from manually changing DNS server settings on their device and using an open resolver.

Therefore, it is recommended to prohibit user access to properties of LAN connections, client proxy settings and to redirect all rogue DNS traffic, so no queries can slip through the cracks.

Prohibiting Access to Properties of a LAN Connection

The following configuration determines whether the Windows Network Properties menu item is enabled, and thus, whether the Local Area Connection Properties dialog box is available to regular users.

Disable this setting and enable Network Connections settings for Administrators in order to disable the Network Properties menu items for all users, which will also prevent them from changing their DNS settings:

Registry Hive	HKEY_CURRENT_USER
Registry Path	Software\Policies\Microsoft\Windows\Network Connections
Value Name	NC_LanProperties
Value Type	REG_DWORD
Enabled Value	0
Disabled Value	1

Redirecting all DNS Traffic to AXS Guard

To intercept all DNS traffic directed towards the Internet, system administrators can use port redirection or port forwarding in order to redirect DNS traffic to the AXS Guard appliance.

Port redirection is the preferred method because it avoids the need to update IP addresses in DNS NAT rules when modifying the secure LAN IP address of the AXS Guard appliance.

Port Redirection

1. Log in to AXS Guard and go to Network > NAT > Port Redirection.
2. Add a rule as shown in the example below and save your configuration.
3. Repeat the same steps for TCP port 53.

Port Forwarding

1. Log in to AXS Guard and go to Network > NAT > Port Forwarding.
2. Add a rule as shown in the example below and save your configuration. The Destination IP shown in the screenshot below corresponds to the secure LAN IP address of your AXS Guard appliance.
3. Repeat the same steps for TCP port 53.

Important

In some cases, applications may try to use TCP instead of UDP for DNS requests. For example, if the DNS response is too large to fit in a single UDP packet (which has a maximum size of 512 bytes).

Following are 2 examples of apps that may use TCP for DNS requests:

• Google Chrome: In some cases, Chrome may use TCP instead of UDP for DNS lookups. This behavior can be controlled with the dns_over_https flag in Chrome.

• Mozilla Firefox: Like Chrome, Firefox may use TCP for DNS requests if UDP is blocked or if the response is too large for a single UDP packet. Firefox also supports DNS over HTTPS (DoH), which encrypts DNS requests and responses using HTTPS.

Overall, while it is not common for apps to use TCP for DNS requests, it is possible under certain circumstances.

Handling DNS over HTTPS

DNS over HTTPS or DoH is problematic for the analysis and monitoring of DNS traffic for cyber security purposes. DoH uses encryption and can be used to bypass SecureDNS or other DNS controls in your network.

There are several methods to prevent the use of DNS over HTTPS: blacklisting the IP addresses of public DoH servers in the AXS Guard firewall, disabling DoH options in web browsers or disabling DNS encryption in Windows.

By blacklisting the IP addresses, traffic to and from these servers will be blocked. Disabling the DoH options in web browsers and in Windows will ensure that traditional DNS is used instead of DoH.

Handling DNS over TLS

DNS over TLS, or DoT, is a standard for encrypting DNS queries to keep them secure and private.

DoT uses TLS to encrypt and authenticate communications. This ensures that DNS queries are not visible to third parties, protecting user privacy and security. Like DNS over HTTPS, this also means DoT can be used to bypass SecureDNS or other DNS controls in your network.

DoT uses TCP port 853 by default, although it is also possible to use UDP port 853. Some popular DoT servers include Cloudflare, Google and Quad9.

System administrators can easily block the specific ports and protocols used by DoT in the AXS Guard firewall with a static policy.

Preventing Users from Changing Proxy Settings

The AXS Guard proxy server adds an additional layer of security between your internal network and the Internet. It can securely relay requests from computers and devices in your network, acting as a buffer against cybersecurity threats.

When using the AXS Guard proxy, users should not be allowed to change their system's proxy settings, as the proxy itself also relies on SecureDNS. This can be achieved with a Windows group policy or by editing the Windows registry.

Creating DNS Filters

System administrators have the flexibility to enhance the existing SecureDNS filters by incorporating additional ones as per their specific requirements.

These supplementary filters are built upon existing web access filter categories, e.g. predef-porn, predef-phishing, etc.

The factory default blacklist provides comprehensive coverage for the majority of DNS security requirements. Categories can be viewed or created by navigating to Web Access > Filters > Categories.

To enforce DNS blocking for a web access category, system administrators must navigate to Network > General and then select the appropriate domain filter.

Important - DNS Filters vs. Web Access Filters

• DNS filters, while rooted in established web access filter categories, require a level of granularity for effective blocking. At a minimum, they should incorporate top-level domains (TLDs) and, ideally, second-level domains (SLDs). For instance, merely inputting example into a custom DNS filter would prove inadequate in preventing access to specific domains like example.com. This precision ensures that unwanted content is accurately blocked, enhancing the efficiency and reliability of DNS filtering mechanisms.

  

• DNS filters can also be created via the AXS Guard Cloud. See the various configuration options in the system administration guide.

Creating DNS Sinkholes

DNS sinkholing is a mechanism aimed at protecting users by intercepting DNS requests initiated by clients that are attempting to connect to unwanted domains. If configured, AXS Guard will return a controlled IP address which points to a sinkhole server defined by an AXS Guard system administrator.

This technique can be used to prevent hosts from connecting to or communicating with unwanted destinations, e.g. legitimate domains and subdomains which aren't blocked by SecureDNS.

1. Go to Network > DNS > Forwarding.
2. Create a new entry as shown in the example below.
3. Save your configuration.

Important

DNS sinkholing can be a useful tool for preventing access to certain websites, but it should be implemented carefully and with consideration for the potential risks and limitations.

• False positives: One of the main risks of DNS sinkholing is the possibility of false positives, where legitimate websites are incorrectly blocked. This can be particularly problematic in environments where access to certain sites is critical, such as in corporate or government settings.
• Incomplete coverage: DNS sinkholing is not a foolproof solution and may not catch all instances of malicious activity. Various techniques exist to bypass DNS sinkholes, such as using IP addresses instead of domain names or using alternative DNS servers, e.g. open DNS resolvers.
• Increased network latency: DNS sinkholing can add latency to DNS queries, especially if the sinkhole server is located far from the user. This can result in slower browsing and network performance.
• Maintenance overhead: Maintaining a DNS sinkhole requires ongoing effort and resources to ensure that it remains up-to-date and effective. This can include updating blacklists, monitoring for new threats, and managing the sinkhole infrastructure.
• Legal and ethical concerns: DNS sinkholing can raise legal and ethical concerns, particularly in terms of privacy and censorship. In some cases, blocking access to certain websites may be seen as a violation of free speech or civil liberties, and could result in legal challenges or public backlash.

DNS Security Test

Several organizations maintain and publish free blocklists of malicious URLs, systems and networks that can be used to test your DNS security. Please note that some of these lists have usage restrictions. You can also use the following FQDNs to test your configuration:

FQDN	Category
test.sinkhole.secure-dns.eu	Test
blacklist.secutec.be	Blacklist
malware.secutec.be	Malware
spam.secutec.be	Spam

See the system administration guide on this site for additional information about the various categories listed in the table above.

You can quickly test your DNS security on a Windows machine or via a Linux terminal with nslookup or by using the dig command.

Replace 10.200.32.254 in the examples below with the LAN IP address of your AXS Guard appliance, then check its DNS security logs or log in to the AXS Guard Cloud to view the test results.

nslookup example:

Linux:~$ nslookup test.sinkhole.secure-dns.eu 10.200.32.254
Server:     10.200.32.254
Address:    10.200.32.254#53

test.sinkhole.secure-dns.eu canonical name = test.sinkhole.axsguard.com.
test.sinkhole.axsguard.com  canonical name = test.axsguard.cloud.
Name:   test.axsguard.cloud
Address: 195.0.83.250

dig example:

Linux:~$ dig test.sinkhole.secure-dns.eu @10.200.32.254

; <<>> DiG 9.18.12-0ubuntu0.22.04.2-Ubuntu <<>> test.sinkhole.secure-dns.eu @10.200.32.254
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31938
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 170cecf59d8d9d830100000064cb75601fdf4539129ccdc9 (good)
;; QUESTION SECTION:
;test.sinkhole.secure-dns.eu.   IN  A

;; ANSWER SECTION:
test.sinkhole.secure-dns.eu. 86400 IN   CNAME   test.sinkhole.axsguard.com.
test.sinkhole.axsguard.com. 5   IN  CNAME   test.axsguard.cloud.
test.axsguard.cloud.    951 IN  A   195.0.83.250

;; ADDITIONAL SECTION:
secutec.rpz.zone.   1   IN  SOA dns1.sinkhole.axsguard.com. hostmaster.sinkhole.axsguard.com. 3 5 5 5 5

;; Query time: 27 msec
;; SERVER: 10.200.32.254#53(10.200.32.254) (UDP)
;; WHEN: Thu Aug 03 11:37:36 CEST 2023
;; MSG SIZE  rcvd: 241

Logging & Reporting

DNS security events are logged in the AXS Guard configuration tool and can be viewed through the DNS Security dashboard by logging into the AXS Guard Cloud.

Important

DNS security events associated with clients connecting to the Internet through the AXS Guard proxy server are logged specifically at the proxy level rather than the client level. This means that in the event of DNS-related activities, only the proxy IP address will be visible in the logs.

DNS Security Logs

1. Log in to your AXS Guard appliance.
2. Go to Network > DNS > DNS Security Logs.

3. Click on the appropriate date to view the log entries.

   

Network Security Logs

1. Log in to your AXS Guard appliance.
2. Go to System > Logs > Network Security.

3. Click on the desired log file to open it.

   

Threat Reports

1. Log in to your AXS Guard appliance.
2. Go to Reports > Threats > Malware Detection Report.

3. Click on Show Statistics under "DNS queries to domains reported by SecureDNS grouped by category".

   

DNS Security Dashboard

1. Log in to the AXS Guard Cloud and navigate to DNS Security.

2. Select the appropriate organization (top right).

   

3. Select the internal FQDN of your AXS Guard appliance, e.g. axsguard.example.com.

   

Statistics

System statistics like CPU usage, memory usage, and disk space are crucial for understanding a system's health. See our system administration guide for additional information.

Notes

While it is possible to keep your current DNS flow where clients solely use your internal (Windows) DNS server, which must be reconfigured to use AXS Guard SecureDNS for upstream resolving, it will limit AXS Guard's ability to link malicious DNS requests to individual hosts, which is required for effective troubleshooting and isolation of affected devices. It may also cripple host logs and reporting options.