Wednesday, October 12, 2016

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

In Part 1 of this post we walked through the basic process your computer or mobile device utilizes to translate “www” addresses into Internet Protocol (IP) addresses for communications over the Internet through the use of the domain name system (DNS). We posed the question, for a transaction seemingly as simple as asking a question and obtaining an answer, how insecure could it be? We highlighted a few of the ways the integrity of the DNS data could be compromised:

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.

We also broached the topic of a malware-infested device leveraging DNS for nefarious purposes, but we’ll discuss this vector in Part 3.
As for these vulnerabilities on legitimate queries, let’s examine each of these and highlight strategies to mitigate them. The first vulnerability relates to improper device configuration. Devices, particularly mobile devices, generally rely on another Internet standard mechanism, DHCP (dynamic host configuration protocol) to obtain not only an IP address for use on the network to which they are connecting (enterprise, home, wifi, etc.) but additional parameters including which local DNS server to query.

As long as the administrator of the network to which you are connecting is trustworthy, getting repointed to an imposter DNS server should be relative low risk. However, even with trustworthy networks, errors in configuration of the DHCP server could result in DNS responsiveness issues resulting in network unavailability more so than malicious activity through redirection. But malicious activity know as pharming is a known form of attack where your device installs a virus or Trojan which manipulates your DNS server settings, thereby directing queries to the attacker’s DNS servers. Anti-virus software on devices should help prevent such forms of malicious attack. You can check your DNS server settings within your device’s settings for the network to which you are connected or by typing ipconfig with a command line window on Microsoft Windows.

If you utilize a service provider’s DNS service, you should statically configure your DNS server IP addresses in accordance with instructions from your provider. When connecting through a virtual private network (VPN), e.g., to your enterprise network via a public wifi services, make sure your DNS server settings map to your enterprise DNS servers, not that of the local network to which you are connected.

Mitigating the second vulnerability, local DNS server misconfiguration, requires application of server hardware, operating system and application controls to minimize hacking vulnerabilities. This includes applying patches for operating system, kernel, and DNS application software as well as any other software running on your local DNS servers. This should be standard practice across all of your network and computing infrastructure as should denial of service mitigation approaches such as packet rate limiting.

Protection against misconfiguration requires disciplined configuration checking such as through the use of an IP address management (IPAM) system like IPControl™ from BT Diamond IP. This system greatly reduces the probability of configuration errors. Applying access controls on which users can access the servers and which systems (e.g., IPAM systems, DHCP servers) can update the DNS configuration will also reduce exposure to illicit update attempts.

The third vulnerability relates to security practices of those operating DNS servers on the Internet used to refer and resolve DNS queries for devices. This is where you have little to no control, though the root servers and most top level domain administrators exercise stringent security practices. For your own namespace, if you desire to register your domain name within a given top level domain (e.g., .bank, .diamonds, .pub, etc.), review the domain operator’s security policies to confirm a reasonable approach to mitigating attacks on their DNS servers on which you rely to accurately point to your DNS servers. Otherwise, if there are domains you don’t trust or are known malware domains that you don’t want your network users asking about, you may block them by configuring your recursive servers as DNS firewalls. We’ll discuss DNS firewalls more in Part 3.

The fourth vulnerability entails an attacker providing a seemingly valid answer to a query from your local recursive DNS server prior to the receipt of a valid legitimate answer. In this scenario, the recursive server applies a set of match criteria on the answer to map it to the original query based on parameter settings in the DNS response. If everything checks out, the recursive server will respond to the querying device and cache the answer to provide to others asking the same question. Due to the potential impact on multiple users by virtue of the caching of this data, this form of attack is known as cache poisoning. Most DNS server vendors have implemented basic steps to hinder cache poisoning, such as randomization of DNS parameters, but DNS security extensions (DNSSEC) provides the most effective protection against cache poisoning.

DNSSEC enables the signing of DNS data by the answering DNS server. This enables the recursive server to validate the signatures to confirm that the DNS data indeed originated with the domain operator in question and that the data was not manipulated en route to the recursive server. Should an attacker provide a falsified answer including all matching parameters, DNSSEC validation will disqualify the answer as invalid, even if the attacker signed the answer, unless the attacker stole the private keys of the corresponding domain owner. This risk is non-zero but should be very small, assuming domain signers secure their private keys.
IT security is a complex discipline and requires a multi-faceted approach involving defenses at the network, software, hardware, and user level. Securing DNS likewise requires application of this disciplined approach. Securing your DNS infrastructure will provide your users confidence in network and DNS availability, integrity and security. But even with a secure DNS infrastructure, if an attacker infiltrates user devices with malware to gain a foothold within your network perimeter, the core function of DNS can be put to use by attackers to conduct illicit activity within your network. We’ll discuss how to protect your DNS and your network from such attacks in Part 3 of this post.

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. example.com, 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 “www.example.com” the local DNS server will first locate the DNS servers configured by the example.com DNS administrators, then query one of these servers for the IP address corresponding to “www.example.com.”

The local DNS server locates the example.com 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 example.com DNS servers. Your single question for www.example.com 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, 192.0.2.54 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.

Thursday, August 20, 2015

BT survey indicates movement on IPv6 deployments

We recently invited network engineers to participate in an online industry survey to characterize opinions and attitudes about IPv6 deployment in their networks. We’ve conducted this survey for five years running now, and we’ve observed a steady climb in the proportion of survey participants who have deployed or were actively deploying IPv6. This year’s survey didn’t disappoint, as we saw continued IPv6 deployment progress with over half of survey participants indicating they had deployed or were in the process of deploying IPv6. This tally represented a fifteen percent higher proportion that in last year’s survey.

Deploying IPv6 is necessary for organizations to continue to communicate with all users on the “total Internet,” which is slowly evolving from a homogeneous IPv4 Internet to a mixed protocol IPv4-IPv6 Internet. Evidence of such an evolution is visible from various industry measurements, such as the proportion of Google users accessing their sites via IPv6 and vyncke.org’s measurements of IPv6 use globally and by country for web and email servers and DNS.

In the face of evaporating of IPv4 address space availability, growth of the Internet is accelerating due to new Internet users, new and multiple mobile devices for Internet users, and non-user devices or “things” spurring the emergence of the Internet of Things (IoT). Internet accessibility for these users and things will by necessity require IPv6.

Unfortunately IPv4 and IPv6 are not interoperable, so organizations desiring to communicate with these users and things, members of today’s growing total Internet, must support both IPv4 and IPv6. In fact, three of four survey respondents agreed that continued global Internet presence was a key benefit to deploying IPv6. And most survey respondents deploying IPv6 use a dual stack approach to enable Internet reachability via either protocol for their web, email and other Internet-reachable application servers.

Survey results also yielded some interesting shifts in attitudes about IPv6. As the reality of IPv4 address space exhaustion materializes, organizations are becoming more accepting of the need for IPv6 and are increasingly bullish about IPv6’s benefits and value.  For example, survey respondents from organizations that have or are deploying IPv6 recognized as top benefits offering a competitive advantage, supporting IoT initiatives, spurring innovative applications, and enabling a continued global Internet presence.

This year’s survey once again signified that the inability to demonstrate a strong business case was the leading obstacle to IPv6 deployment, followed by the complexity of infrastructure upgrades, conversion of applications or middleware, and staff training. These concerns represent a shift away from networking focused issues from past surveys to those of practical implementation and support, another indicator of attitude shift favoring deployment.

BT’s IPv6 survey findings and public IPv6 measurements corroborate increasing IPv6 deployment worldwide. We’d recommend that organizations that rely on Internet communications for ubiquitous Internet access to resources, collaboration, or commerce start planning for IPv6 deployment if they haven’t done so already. And BT can help along the way, with Advise services to assist with IPv6 deployment planning, execution and management and IP address management (IPAM) solutions from Diamond IP to enable IPv4-IPv6 address planning, discovery and management.  We invite you to review our full survey results and analysis in our survey report.

Monday, July 27, 2015

IPv6 deployments growing steadily though not exponentially (yet)

The percentage of users of google's websites accessing via IPv6 has reached 8% for the first time last week, essentially doubling up the percentage from only a bit more than a year ago. It was then, a year ago that I had last blogged about predicting future IPv6 adoption trends based on "curve fitting" historical measurements. At that time, the predictions for the end of 2014 indicated 6.2% for the exponential growth model, while the polynomial model predicted 5.6%. The actual measurement was 5.7%.

As illustrated in the graph below with curve fits based on the most recent data, the exponential curve, the top (green) curve is certainly the most ambitious as it was last year. It predicts the percentage of IPv6 users accessing google's sites at 11.4% by the end of this year and over 25% by the end of next. Meanwhile the polynomial curve fits are more conservative predicting 8-9% by the end of this year and 12-15% by the end of next.


While IPv6 adoption growth hasn't "gone exponential" just yet, could the exhaustion of IPv4 space most recently within the ARIN region  (mostly N. America), following RIPE (Europe) and APNIC (Asia) serve as the catalyst to drive IPv6 deployment growth exponentially? Further requirements for IP address space must by necessity be filled by IPv6 address space, unless an IPv4 address exchange can be brokered.

But even if no additional IP space is needed, the population of IPv6 capable Internet users is clearly growing. Are they able to access your website? Where do you stand with IPv6 deployment? You can make your opinions known by completing our annual IPv6 survey.   They survey takes only five minutes to complete and you can register to win a $100 Visa gift card, the winner of which will be selected randomly among participants. Hurry, the survey closes at the end of July.

Tuesday, March 3, 2015

Will the IoT be the IPv6 killer app?

The Internet of Things (IoT) refers to the extension of today’s Internet beyond connectivity and interaction among traditional user-operated devices like PCs, tablets, phones and like types of devices into the realm of connectivity and interaction with non-user operated devices such as sensors, monitors and remotely controllable devices. Internet-enabling such “unmanned” devices allows these devices to autonomously report updates, status changes, events, or to perform actions commanded by users or other devices via the Internet. Examples of such “things” commonly in use today range from consumer goods to devices supporting business initiatives such as those in support of the following example applications.
  • Smart initiatives – providing a centralized view of yet unrealized volumes of data for more intelligence resource management and customer service such as:
    • Smart Grid – Dynamic matching of electricity, water, gas, etc. supply with demand, reducing resource waste and saving consumers on utility bills.
    • Smart Cars – Diagnostic and usage sensors within an automobile for performance reporting, troubleshooting and customer notification of worn components and recommended service check-ups as well as automated crash detection and reporting.
    • Smart Homes – Remote monitoring of premises, smart appliances, remote control of power, heating/cooling, lighting, entertainment, and access.
  • Municipal (smart cities) and industrial surveillance and monitoring – physical access control and monitoring, environmental monitoring for extreme conditions (e.g., natural disaster, fire, floods), structural monitoring and traffic monitoring.
  • Field applications – fleet management, dispatch, tracking and vehicle telematics.
  • Healthcare – fitness tracking, remote monitoring of patients’ vital signs, diagnostics and medication administration, “body area networks,” monitoring of storage environments, e.g., for plasma, organs.
  • Industrial – factory line monitoring, diagnostics, resource control, supply chain management, process monitoring and control leveraging improved accessibility that wireless provides.
  • Military – battlefield ad hoc networks with various soldier sensors reporting status updates to military command.
As implied by this list of applications, the key benefit of deploying such things is to extend the visibility, reach and control of a user or organization, providing more information for better insights and control with minimal incremental costs. These applications and others like them may require deployment of hundreds, thousands, even millions of sensor devices whose measurements and status information must be communicated to a centralized application server for processing, analytics and presentation. The confluence of advancements in wireless communications and networking, device miniaturization, battery technology, big data analytics, and application innovations has fueled seemingly limitless possibilities for Internet-connected things, and is constrained only by the imagination of device manufacturers and application developers.

IPv6 is likewise an enabler of IoT in one sense by its sheer address capacity in supporting millions of things (tens of billions by 2020 according to many analysts). When IoT devices are deployed within the confines of an enterprise network for use in internal network applications such as factory automation, surveillance, etc., use of private IPv4 space could provide sufficient address capacity depending on the quantities of things and existing allocations of private space. When public IP addresses are required by things, to literally connect to the Internet, IPv6 addressing may become necessary if not the default, given the general lack of available public IPv4 address space.

Beyond address capacity, certain applications may require ad hoc networking capabilities where things may require address autoconfiguration to “self-initialize” on the IP network or Internet based on local access connectivity. If Dynamic Host Configuration Protocol (DHCP) servers are not provisioned, the stateless address autoconfiguration (SLAAC) feature of IPv6 enables things to detect local network addressing and to auto-assign their IPv6 addresses.

The IPv6 SLAAC feature provides automation with agility for ad hoc Internet access, though it raises potential network access control concerns from a network manager’s perspective. In such cases, provision for security, access control and IP address management (IPAM) solutions becomes critical. IPAM solutions that can detect IPv6 addresses provide visibility into ad hoc IoT devices for network managers, while corresponding security solutions enable qualification and access control for connected things. I’ll discuss these topics in more detail in a future post.

Tuesday, December 16, 2014

DNSSEC Survey Report

BT Diamond IP just published its latest report detailing results of its DNSSEC industry survey, conducted in November, 2014. This year’s survey yielded strong participation from active DNSSEC deployers, meaning those who have already deployed or are deploying DNSSEC. While not likely representative of overall industry deployment status, opinions regarding complexity and business case as obstacles and lack of interest in high security module (HSM) appliances for private key storage prove insightful.

Among the key findings of the survey:

  • Nearly all respondents agreed with the statement that DNSSEC can or does provide value to their organization and over 85 percent likewise agreed that DNSSEC technology is mature and can be reliably deployed.
  • Forty-seven percent of respondents agreed that deploying and maintaining DNSSEC is very complex, 12 of the 47 percent strongly. Only 22 percent disagreed. This is rather telling in that DNSSEC is not only considered complex to the uninitiated, but that experience shows this to be the case.
  • Nearly half of respondents disagreed with the statement that only external (Internet-facing) zones need be signed, while 28 percent agreed with the statement. This majority position debunks the theory that internal name spaces are of little concern when it comes to DNSSEC.
  • Only 20 percent of respondents agreed that dedicated hardware security module (HSM) appliances or cards are required to store private keys.
  • Over 75 percent of respondents assign their DNS groups as responsible for DNSSEC implementation and management, sometimes alone or often in conjunction with other groups. It’s interesting to note that about 25 percent of respondents do not involve the DNS group in the process!
  • As an industry, simplifying the deployment process to reduce complexity and therefore costs to some degree could help spur further DNSSEC deployments.

The survey report documents participants' opinions about the level of concern for securing DNS via DNSSEC, their stage of DNSSEC deployment if any, the perceived value of DNSSEC, deployment obstacles, other DNS security concerns, which groups internally are responsible for DNSSEC management, and even which DNSSEC vendor implementations respondents use.

The full report is available in pdf format at http://www.globalservices.bt.com/static/assets/pdf/products/diamond_ip/BT-Diamond-IP-2014-DNSSEC-Survey.pdf.

If you have any comments regarding the report please don't hesitate to contact me.