Monday, July 18, 2016

Ask a Question, Get an Answer; How insecure can that be? (Part 1 of 3)

The domain name system (DNS) was invented nearly thirty years ago to serve as the Internet directory. As you browse the Internet using your computer, tablet, mobile phone, or other device, you navigate by entering names of websites, typically “www” addresses. But your device connects to the intended Internet destination by sending Internet Protocol (IP) data packets, which are addressed using IP addresses, not www addresses. DNS provides the vital linkage in looking up www addresses that people use and translating them to IP addresses that devices use.

The basic concept of DNS is very simple:  ask a question (www address) and get an answer (IP address). But the mechanics involve a number of DNS entities, many of which lie outside of your organization. And this could expose your network to security compromise. By its very nature, the global Internet DNS system serves as a distributed data repository containing www names (and others of course but let's keep it simple) and corresponding IP address information. The distributed nature of DNS applies not only to the global geographic distribution of DNS servers housing this repository, but to the distribution of administration of the information published within respective domains of this repository. Each organization desiring an Internet presence obtains a domain name, e.g., under which its IT administrators publish www-to-IP address translation information in their DNS servers.

When you enter a www address in your browser, your device will issue a DNS query to your local DNS server as configured by the administrator of the network to which you are connected. For example, your enterprise IT staff configures local DNS servers for your use when on the enterprise network, your service provider operations team configures a local DNS server for your use when on broadband, and the wifi network administrator likewise provides a local DNS server for use when on their wifi network. The job of this local DNS server is to fetch the answer to your www query on the Internet. If you desire to browse to “” the local DNS server will first locate the DNS servers configured by the DNS administrators, then query one of these servers for the IP address corresponding to “”

The local DNS server locates the DNS servers by querying other DNS servers on the Internet corresponding to your entered domain name. For example, it will query the Internet root DNS servers, which will refer to the .com DNS servers which will in turn refer to the DNS servers. Your single question for therefore generated three queries from the local DNS server to locate the information source and to answer the question as illustrated in the figure below. The local DNS server is generally referred to as a recursive DNS server given its function of recursively querying other servers to track down an answer. Upon receiving an answer, the local DNS server will provide the answer back to your device so your browser can connect to the corresponding IP address, in this case. The local DNS server also caches this answer so should another device on the network ask the same question, it may respond immediately without having to reissue the three Internet queries each time.

Question asked, answer received, what can go wrong? A sufficiently paranoid security analyst may point out the following basic exposure points in this process:
  • Your device could be misconfigured and attempt to contact an attacker’s local DNS server.
  • The local DNS server could be misconfigured or hacked rendering it unable to process queries, rendering name translation unavailable and thus the Internet unavailable.
  • An Internet DNS server could be misconfigured or hacked, leaving it in a state of providing incorrect answers, possibly misdirecting device connections or rendering Internet connections unavailable.
  • An imposter Internet DNS server could falsify and answer and redirect your device to an attacker website. And the local DNS server could provide this cached falsified answer to other devices that attempt to connect.

Now consider that a single web page likely contains numerous DNS names requiring lookup to load images, videos, scripts, ads, and other resources. Your browser issues a query for each unique name resulting in numerous queries of this sort for a single web page. So the exposure to what can go wrong is amplified.  

And that exposure results merely from legitimate users making legitimate queries. Imagine an attacker having successfully installed malware on a device within your network which can also use DNS to locate its command and control center for instructions, software updates, or to export retrieved corporate information.

How can you protect your devices, your DNS infrastructure and your network? Stay tuned for part 2 of this series to find out.

Wednesday, July 6, 2016

IPv6 Deployments Continue Acceleration

IPv6 momentum continues to build in the face of global IPv4 address exhaustion. All major Regional Internet Registries but Afrinic have officially exhausted their available IPv4 address space. Internet Service Providers (ISPs) requiring additional IPv4 address space now must rigorously justify their requests. ISP subscriber growth can be satisfied with available though diminishing IPv4 address space, through the use of carrier grade NATs, or with IPv6. Given ever broadening end user device IPv6 support, the ultimate growth strategy requires IPv6 implementation. Many enterprises are actively engaged in deploying IPv6 as well.

Google has been measuring the percentage of IPv6 users accessing their websites for a number of years. Just recently the percentage of users accessing via IPv6 topped 12%. This data represents one perspective though probably a good indicator for the Internet at large. Extrapolating this metric per the chart below, we see the IPv6 density of the Internet doubling to nearly 25% according to our third order polynomial extrapolation. The second order extrapolation predicts 22% in two years.

How does this impact you? If your universe of Internet users to whom you invite access to your website, email servers, or other Internet applications mirrors that of Google, i.e., the whole Internet, it may behoove you to begin deploying IPv6 if you have not already. If one in five Internet users cannot access your website in two years, consider the lost opportunity in terms of commerce, communications, or information sharing. In all fairness, dual stack devices should still be able to access your site given the Internet standard approach of attempting IPv6 connections first, following by IPv4. But at some point it's likely that devices will no longer have access to an IPv4 address and will be only able to communicate via IPv6. Major ISPs have pervasively deployed IPv6 already and Android and ios mobile platforms require support of IPv6-only networks. 

If you have not yet deployed or even considered IPv6 implementation, I invite you to access our free online tools to help you familiarize yourself with business drivers for IPv6, your return on investment (ROI) for deploying IPv6, as well as IPv6 addressing and subnetting.These tools can help you understand the implications both of deploying IPv6 and of not deploying in terms of upside opportunity versus cost.

Our business needs assessment tool provides qualitative feedback based on the relative importance of key IPv6 attributes, while the IPv6 ROI calculator enables you to quantify your revenue upside against your cost to deploy IPv6 for your web presence. This tool also enables you to tweak cost parameters to more finely evaluate your ROI. Our subnet calculator allows you to experiment with IPv6 subnetting and our address planner enables you to try hierarchical address allocation models to determine which approach might work best for your network. All tools include basic help but if you need more details or have feedback, please don’t hesitate to comment on this post or contact me directly.