In a default-deny world, where only verified sources and verified destinations are allowed, which require a successful policy-allowed DNS resolution, many modern threats are mitigated, and there’s demonstrable value in choosing this path, including being able to enforce “My network, my rules” approach to egress control.

However, in this world where existing applications need to keep functioning, applications that fail in this approach can be provisioned by trusting IP address destinations that are well-known, with the granular control of protocol and port number constraints. Microsoft ZT DNS offers this exemption capability and adam:ONE® offers it by a feature called “Enablers”. The order of operations for adam:ONE’s Don’t Talk to Strangers (DTTS)® in this constrained portion is as follows:

When this violation occurs, a traffic log shows such endpoints attempting a connection and failing (in red):

As a contrast, when an endpoint passes a policy check and is able to resolve the destination correctly, the traffic log passes (in green) like this:

The purpose of this article is to summarize the 3 types of Applications that fall into this category.

LEGACY apps

Any direct-by-IP connection, typically legacy processes that ignore network-designated DNS server usage:

• Legacy application or bookmarks with hard-coded IPs in endpoint configurations will fail unless they fall into the local subnet

  

• Hard-coded DNS servers (sometimes, administrators, sometimes manufacturer such as Chromecast, e.g. Business Insider article on Chromecast | Paul Vixie)

  

• Hard-coded NTP servers (this one is of particular concern because of UDP amplification attack surface)

  

• Apps designed to circumvent protective DNS filtering (e.g. Telegram, Retail VPNs, P2P, Psiphon, etc.)

  

  Rather than this being a problem, in most cases this is actually a beneficial property as endpoints should not be able to circumvent network security unless explicitly allowed to.

As for the other examples, a legacy approach of static assignments is possible to remain in place, but an inventory of required legacy apps helps make a migration to DTTS without disruption. The reality in most environments is that such an inventory does not exist, is incomplete, but will absolutely surface in the post-migration violation logs. Incidentally, a quick correction can be made at such discovery time.

VOIP/Messaging/P2P (Purposefully no DNS usage for voice/video)

Any modern application that includes connections to IP addresses that were not discovered via DNS – breaks some, but not all functionality.

• Video and voice apps using hard-coded IPs for SIP, RTP, STUN, TURN, etc. This includes WhatsApp Voice/Video/Media and Snapchat Audio calls and in the case of Signal, only Group calls fail.

• Online collaboration tools like Teams, zoom, Google Meet

  

  Note however, that Teams and Zoom are not prevented from VoIP video functions. However, the UDP-based anycast relay falls back to a less efficient TCP-based connection. Google Meet, on the other hand, does not make a video/audio connection at all.

• P2P apps such as torrent clients cannot connect to peers. This is probably obvious, and a nice side effect of DTTS is that blocking P2P now happens by default.

• Cellular phone calls over VoIP/SIP: Mobile Carriers make use of [mobilecarrierID].pub.3gppnetwork.org domain to make IKEv2 connections over which SIP traffic is carried. These connections persist but on re-connection attempts do not always re-query DNS even after TTL has expired.

• Rich Communications Services (RCS) is a cross-platform protocol for end-to-end encryption. Google’s free RCS hub service called Jibe is used by cellular carriers worldwide. This is a current list of IPs that Google uses over TCP port 443. iOS devices reach out to these IPs without a preceding DNS:

  74.125.88.128
  74.125.88.129
  74.125.88.135
  74.125.88.134
  74.125.88.131
  74.125.88.130
  74.125.88.133
  74.125.88.132
  216.239.36.132
  216.239.36.133
  216.239.36.130
  216.239.36.131
  216.239.36.136
  216.239.36.137
  216.239.36.134
  216.239.36.135
  216.239.36.138
  216.239.36.139
  216.239.36.127
  216.239.36.129
  216.239.36.128
  216.239.36.154
  216.239.36.157
  216.239.36.150
  216.239.36.153
  216.239.36.145
  216.239.36.144
  216.239.36.143
  216.239.36.142
  216.239.36.141
  216.239.36.140
  216.239.36.149
  216.239.36.148
  216.239.36.202
  216.239.36.200
  216.239.36.203
  216.239.36.205
  216.239.36.204
  216.239.36.201
  2001:4860:4802:36::7f
  2001:4860:4802:36::83
  2001:4860:4802:36::8b
  2001:4860:4802:36::8f
  2001:4860:4802:36::9d
  2001:4860:4802:36::95
  2001:4860:4802:36::96
  2001:4860:4802:36::91
  2001:4860:4802:36::85
  2001:4860:4802:36::87
  2001:4860:4802:36::c8

Note that this is a managed subscription list that auto-updates our clients’ deployments when new IPs are discovered.

TIME BOUND expiry

Any application that uses DNS results beyond the TTL of two (2) minutes.

• Legacy Internet Explorer browser. Thank goodness that most of the web is now broken on IE so its only use is in legacy applications that have some IE-only support such as ActiveX dependency.
• Outlook caches IMAP beyond TTL. It appears that once Outlook IMAP profiles are launched, the cached DNS answer is used for a very long time.

ADAMnetworks calls trusted destinations/protocols/ports by the label of Enablers. A joint effort between Tommy Jensen, John Todd and myself, David Redekop is a draft RFC for IETF standardization to allow developers and administrators to publish Enabler data via SVCB DNS records.

In the mean time, adam:ONE facilitates Enablers in two forms:

Official Enablers

These are centrally managed and maintained by ADAMnetworks and automatically become available to any platform subscriber. Here’s a partial list of what’s included at time of this publication:

• Apple Services (required for Apple products/iCloud, etc)
• Cellular WiFi Calling
• Google Meet and Duo
• Microsoft Teams Relay
• zoom
• RC Messaging
• WhatsApp
• Telegram
• Snapchat calling

“My Enablers”

These are per-tenant rules that look like this as an example where you may want an endpoint to connect to 23.43.242.122 or 23.43.242.137 where www.example.com is hosted, but it needs to be reachable without a DNS resolution first:

Closing Note

In spite of the common occurrence of DTTS/ZTDNS violations, every circumstance can be mitigated with careful consideration of trusting destinations. The traffic log surfaces blocked traffic which can be correlated back to an app launch or a URL visit. When the further constraint of protocol and port constraints alongside per-policy assignment, the Principle of Least Privilege integrity can continue to bring peace of mind.

1 post – 1 participant

Read full topic

*** This is a Security Bloggers Network syndicated blog from The ADAM Blog - ADAMnetworks authored by David. Read the original post at: https://support.adamnet.works/t/dtts-zero-trust-dns-enforcement-policy-violation-management/1488