DNS (Domain Name System) protection differs from content filtering in some aspects: For DNS, we inspect the entire domain and that is quite fast but not accurate because it is an All-or-nothing approach. When it comes to content filtering, we analyse it´s URL then we can have a more precise and granular result once we are able to split several services into subdomains and folders. It demands a longer response time because usually SSL/TLS inspections is involved but that´s usefull for security and productivity as well.

In this project, the DNS protection feature we rely on is part of a SASE (Secure Access Service Edge) solution deployed inline with the client(s). Then the Internet traffic from the brach is monitored as shown at the topology:

Before digging into the feature, let´s check how a legit website traffic occurs:

 

 

We notice a client DNS querying cookpad.com website against 10.254.254.1 IP address that happens to be the SASE´s DNS server´s IP. This specific IP address will always be queried regardless a different DNS server configured on branch´s router or client´s network´s adapter. That´s because SASE also acts as a cloud embedded DNS service that intercepts, inspect and resolve DNS queries in order to protect the branch´s assets. Then HTTP (HyperText Transfer Protocol) content is delivered once it is legit.

Now we can jump into the first DNS protection case: when we try to visit hsdps.cc web site, SASE´s DNS server choose not to resolve that domain, instead it gives a “no such name” response back to the DNS query and an “ERR_NAME_NOT_RESOLVED” message goes the web browser.

 

 

From DNS protection, it happens that SASE cloud had matched the domain to a known signature called “cis_dns_feed_malware_vt_domain” (related to Command & Control tactic from MITRE Attack´s framework) then  blocking occurs during the DNS query´s stage. Traffic flows only towards WANBOUND direction and no packet other than UDP/DNS is noticed.

 

 

For the second case, we tested foreignabnormality.com website which had matched DNS´s rule for “Phishing” and that sort of protection is configured for Sinkhole traffic.

 

 

The packet capture shows that DNS query´s response points to 10.254.254.107 IP address as seen by packet # 2587. That refers to Sinkhole´s IP address aka “blackhole”. That´s the reason why there are several retransmission packets (from # 2611 on) which brings “This frame is a (suspected) retransmission” TCP flag as a typical behavior for Sinkhole scenarios. The client expects to have the website´s content; instead he/she gets a forged IP address to connect to. That fake IP address is meant (by SASE cloud) to ignore the content delivery or simply drop it. Then the client keep asking it for retransmission.

 

 

 

We usually choose Sinkhole as a way of analysing unknown or stealthy threats so we may have a broader visibility by exposing the internal IP address for the client who was the source of compromise.

At the same time Phishing rule matches, we also notice Malicious Domains´ rule as an event which triggers a Block action. Anyways, Sinkhole had already made the web browser inform “ERR_CONNECTION_TIMED_OUT” for the client in the first place.

 

---