In last week’s blog post, I explained how Infoblox DNS Firewall works at the conceptual level. Here is an excellent example of its role in combatting the recent attack on the New York Times (NYT) and the ‘what-if’ this attack had been more sophisticated than what we saw. Within a few hours of this attack, Frank Hecker, Infoblox SE articulated the basic mechanics behind the attack that made its way in the customer newsletter.
- Normally the domain name www.nytimes.com maps to one or the other of the two IP addresses—126.96.36.199 or 188.8.131.52—the addresses for the New York Times web servers (or, to be accurate, the load balancers in front of the NYT web servers). This is how people going to the NYT web site get directed to the right servers.
- This mapping from www.nytimes.com to the correct IP addresses for the NYT web servers is maintained by the two NYT external DNS name servers, dns.sea1.nytimes.com (at IP address 184.108.40.206), and dns.ewr1.nytimes.com (at IP address 220.127.116.11). Anybody going to a *.nytimes.com domain is directed to those name servers in order to find the right IP addresses for the corresponding NYT servers.
- The Syrian Electronic Army (SEA) did NOT directly hack the NYT web servers. They also did NOT directly hack the NYT DNS name servers. What they did instead was to go up a level and attack the DNS registrar (IT Melbourne) at which the New York Times had registered the nytimes.com domain name. They hacked into an account at IT Melbourne (one that had fairly high privileges), and changed the IP addresses for the nytimes.com DNS name servers to the IP addresses of DNS name servers that the SEA controlled. Those malicious name servers then gave out IP addresses for www.nytimes.com that were for SEA-controlled systems.
- As a result, anyone attempting to browse to the New York Times web site was instead redirected to an SEA web server.
The hacked site had a banner indicating that the site was hacked. However…suppose an employee were in the regular habit of going to the New York Times web site to read the news. And suppose that the Syrian Electronic Army had that page configured to exploit a browser security vulnerability, and then used that to load advanced persistent threat (APT) malware onto the employee’s PC, that would impact hundreds or thousands of enterprise or government employees or military personnel all going to the NYT site.
How does DNS Firewall protect customers?
Obviously most IT security personnel want to prevent this from happening and that’s where Infoblox DNS Firewall comes in:
- Shortly after the attack occurred, the Infoblox DNS Firewall RPZ feed was updated to blacklist the SEA name server IP addresses.
- If our customer tried to surf to the New York Times web site, Infoblox DNS Firewall would get a response back directing it to the name servers controlled by the SEA. However, because the SEA name server IP addresses were blacklisted, the DNS firewall would block the query.
- As an alternative, the Infoblox DNS Firewall could have been configured to return a different IP address to redirect to the web page provided by IT security. For example, this site could have a warning page to tell users they were trying to surf to a malicious site.
- Note that since the Infoblox DNS Firewall RPZ feed blacklisted the SEA name servers, end users would also be protected against going to any other sites (such as some of the Twitter sites) hacked by the SEA: As long as those other domains have the SEA systems as name servers, they would be treated as malicious.
- This fix was made automatically via the feed as opposed to requiring manual updates to a traditional DNS blacklist.
- In the event that a customer PC had gotten infected during the brief window of vulnerability before the Infoblox DNS Firewall RPZ feed got updated, the DNS Firewall would still provide protection, since malware infecting the PC would then be unable to communicate out to its command-and-control network, as they would be blacklisted as well.
- Finally, if the Infoblox appliance were directly handling the DNS query (as opposed to having queries forwarded to it from Microsoft DNS servers), then IT security would have the true source IP address of the PC or other device accessing the malicious site. And if an Infoblox appliance were also handling DHCP (as opposed to having that done by Microsoft DHCP servers), then IT security could also easily look up the MAC address for the device and its device type (using DHCP fingerprinting) to identify the exact device at issue. If in addition the agency had an Infoblox Reporting server, then this information would be easily accessible through the reporting GUI, as opposed to looking through logs and different screens.
To summarize, even if Infoblox DNS Firewall would not prevent hacking attacks like that, which affected the New York Times; it can protect enterprises, government agencies, and others from the possible downstream effects of those attacks.