When assessing cyber security, one of the key technologies that many security professionals may overlook is DNS. The Domain Name System resolves names to addresses (e.g., google.com = 220.127.116.11), which provides much of the functionality required for typical internet usage. Without relying on any pen-testers, FISMA auditors, tools or scripts, we will easily explore the current state of your DNS and hopefully provide security insights.
Let’s go ahead and test the importance of DNS by purposely breaking your own DNS with these commands (be sure to type: ipconfig /all | findstr DNS to save your settings before breaking it, ALSO another way to reverse this is to set it to DHCP netsh interface ip set dns "Local Area Connection;" dhcp) . Try the following commands (be sure to replace your Interface name with the appropriate one):
Now attempt to go to http://google.com in a new tab or do any of your normal internet based activities (you may need to do ipconfig /flushdns to clear any caching). Most likely you will find its not functioning properly, but before fixing it, let’s explore some of the bypasses that insider threats or adversaries may perform to bypass a secured/hardened DNS to see if your network will prevent it.
One can bypass the need for DNS by knowing the IP address of the destination, for example we can still go to Google by visiting http://18.104.22.168 or even more deceptively by visiting http://3627735438/ or http://0330.0072.0331.0216 or http://0xD83AD98E and http://[2607:f8b0:4006:80a::1008]/ (if this IPv6 link worked, you will want to investigate your Proxy settings to see if there is a reason it is working and if IPv6 is secured, as you could have just found a security flaw).
Another way of bypassing DNS, especially if that DNS is black-holing, or not resolving the IP addresses of malicious domains or policy violation is that the adversary can temporarily switch to a new DNS to manually look it up. The following command, Name Server lookup is modified to explicitly use the DNS server 22.214.171.124 (which is Google’s public DNS) to find the IP address of google.com. Once this IP address is obtained, it can be visited by pasting it in the URL bar of the browser.
IF this command worked, then already you have found a major security flaw in your network’s DNS architecture. By allowing external DNS queries, it allows insider threats; adversaries and malware to bypass any Domain Black-hole lists and DNS query logging. To put this in context, when thinking of the Cyber-Kill-Chain for example, Ransomware (malware that encrypts your data, holding it hostage for money) will often use DNS to query its Command & Control server (C2) to generate the encryption key. If your DNS security can prevent a successful DNS resolution, then it can’t contact the C2 server for the key, and then your data is never encrypted.
Before going deeper into the security of DNS, it is advisable to fix this problem by tightening down DNS queries to local resolvers only. This requires the following steps:
1. An inventory list of all your organizations DNS servers
2. Logs of all DNS traffic (port 53) sorted by IP
3. A sanity check against the inventory list versus the devices performing DNS queries
4. Applying a perimeter Firewall DNS whitelist rule (deny everything else)
An initial step to solve this is to implement this rule in your IDS devices, which will generate a list of IP addresses conducting DNS:
alert udp $HOME_NET any -> $EXTERNAL_NET 53 (msg:"ONE DNS SOURCE Traffic Alert"; content:"|01|"; offset:2; depth:1; threshold:type limit,track by_src,count 1, seconds 60; classtype:misc-activity; sid:100000x; rev:1;)
Another option is to query the EINSTEIN-1 appliance monitoring your network for all port 53 traffic (for a full year if possible).
In addition, another quick way to discover internal DNS servers is to use this command, which will offer a verbose debugged trace of your DNS query path (it may require requesting a domain that would not be cached on your enterprise resolver):
nslookup -d -d2 google.com
Querying your own name servers to find other name servers will assist, for example, in finding some Google DNS servers its possible by setting the type record to NS
For many organizations these four steps are easier said than done, so we encourage readers to reach out to 1-Source for more information and consultation regarding implementing cyber security in their organization.