Why Not to Set Domains to Private IPs
Reading time: 8 minutes
"An ounce of prevention is worth a pound of cure."
― Benjamin Franklin
The concept of risk is ubiquitous across the cybersecurity landscape. In this day and age, it is difficult to envision any security-conscious organization not having alluded, hopefully more than once, to the serious consequences attached to avoiding the subject, particularly when it comes to protecting its most sensitive digital assets and personal data.
These repercussions, in both monetary and non-monetary terms, can be far-reaching in the amount of damage they can cause by the resultant corporate disarray and overall loss of reputation. Thus, entire governance structures are distinctly preconditioned with the relevant identification of the digital infrastructure as well as the adequate assessment of their threat ecosystem, prior to consigning any additional items onto the risk registers.
While modern businesses can't anticipate every possible threat there is, a few solutions have evolved over the years to become proficient at preventing, or altogether disallowing, the most common types of attack patterns and intrusion attempts known throughout the cyber milieu. The leading principle here is known as the information classification process— commonly assigned, in typical organizational fashion, to data owners and similar stakeholders in what is considered the initial step in the domain of business continuity planning and disaster recovery.
One of these approaches entails the concept of attack surface management (ASM), an overarching methodology capable of providing real-time discovery, classification, and continuous examination of an entity's digital assets whose misconfiguration or unintended exposure may lead to a serious breach scenario. The ability of techniques such as ASM to effectively shut the door in the face of threat actors seeking to leverage even the most sophisticated attack vectors is a significant testimony to its foregoing validity and importance.
This blogpost will highlight the risks associated with the use of private IP (Internet Protocol) addresses in public Domain Name System (DNS) records as they extend the possibility of a cyber attack on internal address spaces and attributed domains. It will briefly re-examine the historical prohibition set forth by RFC 1918 that sought to limit the use of these address blocks to within enterprise boundaries, as well as the unnecessary technical challenges that arise from their misuse.
Let's take a look.
- Private IP addresses in a nutshell
- DNS to the rescue?
- Risks of pointing public DNS records to private IP addresses
- Private infrastructure mapping
- Final words
Private IP addresses in a nutshell
IP addresses' long journey to present-day operations began in the 1970's when the Defense Advanced Research Projects Agency (DARPA) designed the first protocol specifications. The concept was shaped around the need to interconnect computer communication networks, called packet-switched networks, where sources and destinations were represented by hosts identified by fixed-length numerical addresses known as Internet Protocol addresses, or IPs for short. The protocol contained additional features such as the ability to fragment long datagrams to allow efficient data transmission through less capable network channels and, most importantly, an abstraction of the time-to-live (TTL) consistency mechanism to prevent data packets from circulating indefinitely.
According to the standards established by the Internet Engineering Task Force (IETF), IPv4 (IP version 4) was to define a set of private address spaces (see image below) to allow an ever-depleting subset of 232 possible IPs to be effectively routed as to not create ambiguity between publicly-connected enterprises. It was also IETF's decisive action that established that applications that did not require external connectivity should be confined to any one of these non-routable reserved classes without further intervention from Internet authorities.
| IP Class | Starting IP Address | Ending IP Address | Total Hosts |
|---|---|---|---|
| Class A | 10.0.0.0 | 10.255.255.255 | 16,777,216 |
| Class B | 172.16.0.0 | 172.31.255.255 | 1,048,576 |
| Class C | 192.168.0.0 | 192.168.255.255 | 65,536 |
As previously mentioned, in a race to put a stopgap to the problem of IP address exhaustion, RFC 1918 became the de facto reference declaring private IP addresses devoid of any global meaning. Routers, firewalls, and other NAT (Network Address Translation) devices were to be deployed to ensure proper segmentation and to establish perimeter and security boundaries. Consequently, this implied that organizations were ultimately responsible for the correct allocation of these private-use only IPs, in what also became the prelude to the arrival of a multitude of different techniques (think subnetting) to make efficient use of these networks.
DNS to the rescue?
As computer networks grew in size and complexity, researchers soon realized the limitations inherent to the IP protocol. Organizations were also changing in character. All of a sudden, time-shared devices were being replaced by scores of more sophisticated, general-purpose workstations and other dedicated endpoints—essentially, an administrative nightmare for anyone seeking to classify and maintain these hosts. As a result, several ideas emerged about the use of a consistent name space, having a one-to-one correspondence to IP addresses, that would not incur in any significant performance degradation of the underlying medium.
After several attempts and trial runs, a system evolved into the scheme we know today as the Domain Name System (DNS), accounting for the decentralization of both publicly and non-publicly known hosts. Structured in a hierarchical fashion, DNS became ultimately responsible for translating friendly domain names into their IP counterparts, properly directing trillions of web requests to their final destination. However, DNS was also beset with its own assortment of inherent weaknesses including the ability to share internal domain information with basically anyone who asks, or the potential for cache poisoning where users could be redirected to any site chosen by an attacker.
Risks of pointing public DNS records to private IP addresses
With the proliferation of the new technology, along came the best practices. Besides a handful of operational considerations and the potential for unpredictable network traffic behavior, the appearance of private IPs in domain areas, such as public DNS records, can be problematic from the security standpoint.
Once again, RFC 1918 would establish that routers were not to propagate private network addresses over inter-enterprise links. Henceforward, any internal host wishing to communicate to and from a private address space would require the assistance of a NAT function capable of replacing IP datagrams at the network boundary. This advice applied to both source and destination addresses—in turn, system owners and designers, especially those working on ISP (Internet Service Provider) premises, were instructed to filter out and reject direct references to them to prevent the leakage of any prominent network architecture.
In addition, address mapping records, also known as type A records in public DNS settings, were not to have their one-to-one correspondence of fully-qualified domain names to IPs pointing to any of these private ranges.
If an enterprise uses the private address space, or a mix of private
and public address spaces, then DNS clients outside of the enterprise
should not see addresses in the private address space used by the
enterprise, since these addresses would be ambiguous.Private infrastructure mapping
However debatable these recommendations are, the unpleasant reality is that exposing private IP addresses to public consumption via external DNS records can leave your organization vulnerable to a host of information gathering techniques.
It is not a question of whether internal hosts can be directly accessed from the public side of things; they simply can't be, or at least not without some assistance. In fact, certain DNS implementations like Split Horizon (see image below) go to great lengths to solve the particular challenge of a single endpoint (e.g., www.example.com) having both a private IP address on a local network and a public one reachable from the Internet, which will require a different set of responses, or "views", based on the source of the DNS request.
Regardless of use case, it is never a great idea to provide any potential threat actor with the sort of internal network visibility that can be used to stage further attacks.
Next time you're tasked with configuring or overseeing your public DNS zone records, think of the consequences of just handing out information about your subnets by carelessly listing any one of these resources. Always bear in mind that simple reconnaissance approaches, like DNS enumeration, can be used to compile a list of potential targets including hostnames, record types, and other useful data effortlessly—every penetration tester out there worth their salt can attest to the feasibility of such techniques. So, why make their job any easier?
Final words
DNS mishaps are anything but atypical. The protocol, along with its entire supporting apparatus, can be very susceptible to subtle changes and misconfiguration errors, albeit its carefully planned design and timeless quality.
In fact, when it comes to the inclusion of non-globally-unique addresses in public DNS records, such as those delineated in RFC 1918, an entire project has been established to provide a distributed sink for queries that are not answered locally. Commonly known as the AS112 Project, the idea behind it is to prevent reverse lookups to these private IPs, otherwise following the normal delegation path, from reaching and overloading IN-ADDR.ARPA authoritative servers, the domain dedicated exclusively to Internet infrastructure traffic as it relates to the mapping of IP addresses to hostnames.
Although, for some, the pointing of public-facing DNS records to private infrastructure may seem like a sound operational principle, the truth is that the liabilities far outweigh any potential benefits. Not only will you be forcing unnecessary traffic on often overburdened public DNS servers, but you will be exposing a sensitive part of your business to prying eyes.
You may be wondering, is there a simple way to stop exposing private IP addresses to public consumption?
Everything starts with uncovering whether you have DNS records pointing to local networks that may be exposing your internal network infrastructure to the Internet. This data can be obtained in mere seconds with Attack Surface Intelligence.
ASI maps all your Internet-connected assets including DNS records pointing local, remote access points, expiring certificates and more, and helps you make the right call when it comes to securing these assets.
