Skip to content

SecureDNS Quickstart Guide

About this Document

This document describes how AXS Guard's SecureDNS 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

In order to use the SecureDNS feature, 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.

secdnsconcept

Licensing & Feature Activation

  1. Log in to AXS Guard and start the license wizard to import your Premium Threat Protection license, then activate the SecureDNS feature.

    fa

  2. After activating the feature, navigate to Network > General and enable the SecureDNS option.

    secdnsoption

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

    secdnsrunning

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.

concept

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.

dhcp1

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.

dhcp2

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.

dnsfwd

Authenticated Users

The AXS Guard Single Sign-On (SSO) tool is designed to securely and transparently authenticate users with AXS Guard.

After successful authentication, users are granted firewall and web access rights based on their credentials.

Installation of this tool is recommended, as it provides critical host information in the SecureDNS 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 SecureDNS 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 SecureDNS 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 HiveHKEY_CURRENT_USER
Registry PathSoftware\Policies\Microsoft\Windows\Network Connections
Value NameNC_LanProperties
Value TypeREG_DWORD
Enabled Value0
Disabled Value1

Redirecting all DNS Traffic to AXS Guard

You can intercept all DNS traffic towards the Internet and redirect it via port forwarding to the LAN IP address of AXS Guard:

  1. Go to Network > NAT > Port Forwarding.
  2. Add a rule as shown in the example below and save your configuration.

dnsprtfwd

Handling DNS over HTTPS

DNS over HTTPS is problematic for the analysis and monitoring of DNS traffic for cyber security purposes. DoH can be used to bypass SecureDNS, as it uses encryption.

It is therefore recommended to disable DNS over HTTPS. See the KB article about DNS over HTTPS on this site for additional information.

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 by means of a Windows group policy or via the Windows registry.

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 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.

dnssinkhole

Testing SecureDNS

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

FDQN Category
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 SecureDNS categories.

You can quickly test SecureDNS on a Windows machine with nslookup or via the AXS Guard console with the dig command:

axsguard:~$ dig blacklist.secutec.be        

; <<>> DiG 9.16.24 <<>> blacklist.secutec.be
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56956
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: fc8af1a095b8b2b201000000639839e4592e46fed880b8d9 (good)
;; QUESTION SECTION:
;blacklist.secutec.be.      IN  A

;; ANSWER SECTION:
blacklist.secutec.be.   5   IN  CNAME   blacklist.sinkhole.secure-dns.eu.
blacklist.sinkhole.secure-dns.eu. 86400 IN CNAME blacklist.sinkhole.axsguard.com.
blacklist.sinkhole.axsguard.com. 5 IN   CNAME   blacklist.axsguard.cloud.
blacklist.axsguard.cloud. 300   IN  A   195.0.83.240

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

;; Query time: 260 msec
;; SERVER: 192.168.250.254#53(192.168.250.254)
;; WHEN: Tue Dec 13 09:37:56 CET 2022
;; MSG SIZE  rcvd: 290

Logging & Reporting

SecureDNS events are logged throughout the AXS Guard configuration tool.

Important

SecureDNS events related to clients which connect to the Internet via the AXS Guard proxy server are logged at the proxy level, not at the client level.

SecureDNS Logs

  1. Go to Network > DNS > SecureDNS Logs.
  2. Click on a date to view the logs.

SecureDNS Logs

Network Security Logs

  1. Go to System > Logs > Network Security.
  2. Click on the desired log file to open it.

Network Security Logs

Threat Reports

  1. Go to Reports > Threats > Malware Detection Report.
  2. Click on Show Statistics under "DNS queries to domains reported by SecureDNS grouped by category".

dnsprtfwd

SecureDNS Dashboard

The AXS Guard Cloud provides multiple dashboards allowing authorized administrators and MSSPs to remotely and securely monitor AXS Guard deployments, push configuration settings to large-scale installations, view license and operational status information, register new appliances, manage customer contracts, troubleshoot systems and consult threat intelligence data, such as SecureDNS events.

SecureDNS

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.