The complete guide to enabling DTTS® on your adam:ONE® gateway

David · January 26, 2022, 1:37am

Intended audience

This guide is intended for experienced system administrators that are applying network-wide Zero Trust Connectivity, with DTTS® as a core component.
Managed clients experience this process transparently during official onboarding.

What is DTTS® (Don’t Talk To Strangers®)?

DTTS® is a process whereby outbound connections through an adam:ONE® security gateway are allowed only to destinations first resolved via allowed or non-blocked FQDN DNS query.

For example, if you attempt to ping 8.8.8.8 without first resolving it via something like dns.google or google-public-dns-a.google.com, it will fail as shown here.

blink> ping -c 2 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
Request timeout for icmp_seq 0

--- 8.8.8.8 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss

However, if I can resolve the destination by an allowed DNS query, then the outbound connection is open for the period of the DNS TTL (Time to Live):

blink> ping -c 2 google-public-dns-a.google.com
PING google-public-dns-a.google.com (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=113 time=27.634 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=113 time=25.885 ms

--- 8.8.8.8.nip.io ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 25.885/26.760/27.634/0.874 ms

Why would you want DTTS®?

While DNS filtering is a powerful technique for privacy, security and content filtering, it is inherently very leaky. Any application, proxy or VPN service available on the Internet can generally be reached without using DNS. This is how DNS filtering is being circumvented or bypassed completely. DTTS® prevents DNS filtering from being circumvented.

This turns out to protect against a large number of modern-day threats which use C2 (Command&Control) communications direct-by-IP address, and rarely use DNS.

Requirements for DTTS® to operate

A valid subscription (on your dashboard → Billing Settings → Choose the appropriate Subscription or above for each network/location that will require DTTS® functionality)
A supported ASUS router, pfSense® gateway (Community Edition and pfSense+ are both supported) or VyOS gateway that acts as a router for internal network(s) to reach the Internet
Currently-supported adam:ONE® version 4+ software installed and service running
All endpoints using the gateway as its DNS, and no other DNS server
Avoid using any other DNS resolvers at endpoints (e.g. don’t use 8.8.8.8 or 1.1.1.1 as secondary DNS resolvers)
Take special care on Active Directory controllers by using only DNS resolver 127.0.0.1 with Windows Server DNS Manager using the gateway (and only the gateway) as a Forwarder
Optionally create 127.0.0.2/8 localhost alias, bind it to adam:ONE® and hijack outgoing UDP/TCP port 53 queries to 127.0.0.2 to have the impact of offering compatibility even if endpoints are using legacy DNS via public DNS resolvers

Steps to prepare your network for DTTS®-readiness

Review your DHCP server settings
- If DNS servers offered are the same as the gateway, proceed to the next step
- If DNS servers offered are public servers, simply change DHCP to offer the gateway as DNS instead
- If DNS servers offered are your Active Directory controllers, follow adamnet.io/dttsad first
- If your TTL is more than a day, change it to 1440 seconds
  - If the TTL was a week, for example, as is Microsoft Server default, and it was just changed to 1440 (measured in seconds), you will need to wait one week before proceeding, so that DHCP clients can be renewed with shorter TTL
Review all of your statically-assigned endpoints and change their DNS to the gateway (and gateway only)
Make a list of mission-critical applications that must operate in spite of security controls
Make a list of critical service hosts by name or IP address
For each device noted with critical services, enable “View own logs” on dashboard → Devices → Edit settings
on pfSense®, if enabled, comment out disable-packet-monitor on /usr/local/etc/adamone/anmuscle.conf and run service anmuscle.sh restart (this will enable the Traffic Log feature on mytools.management/log for devices able to see their own logs)
Consider retaining more files with log-files-rotate=9 addition to /usr/local/etc/adamone/anmuscle.conf followed by a service anmuscle.sh restart (this comes in handy later for passive DNS log inspection)
Choose a cutover period outside of normal business hours
Notify all technology users of security implementation and a best point of contact method to report any unexpected behaviours. Ask for the following per-incident details:
- MAC or IP address of device / service failing
- Timestamp of incident
- Application or FQDN service that appears to have failed

Turn on DTTS®

For pfSense, ASUS and VyOS, navigate to your dashboard → Manage Network → Advanced → Enable DTTS
Pre-stage your desired policies along with Official Enablers
Prepare any other Enablers you may require, feel free to use adamnetworks.dev/pub/fwaliases for maintained IPv4/IPv6 address space used by various providers
For pfSense® additional steps may be required:
- Compare your pfSense rules on each adam:ONE-protected network to adamnet.io/pfsenserules and make adjustments if necessary
- If necessary, run adamone-setup configure wizard if it has not been run before to create required rules
Run a test similar to the beginning of this article to confirm DTTS® is blocking direct-by-IP communication to the outside, unless first resolved by a permitted FQDN DNS query

Verify full functionality

For each device and critical service listed above, confirm all aspects are functional
For any service that is not operational, determine which Enablers are required by observing mytools.management/log from the device with a failing service or application (alternatively, setup an administrative device with “View All Logs” permission, and filter traffic log as required to identify strangers that may need to be facilitate via an Enabler)

Troubleshooting

If a mission critical service is failing, some troubleshooting options are available:

Create a policy, and choose “Bypass DTTS” as an Enabler: this will disable DTTS only for devices under such a policy, allowing the remainder of hosts to remain protected
- Research and determine if the device/service can be reconfigured to use FQDNs rather than IP addresses
- Only as a last resort, if the device requires direct-by-IP address communication, create an Enabler
- Move device back to a protected policy
For gradual migrations to use DTTS®, a DNSharmony-only policy can optionally be setup temporarily to bypass DTTS®, while a new “DNSharmony with DTTS” policy can be created and assigned to some devices at a time