Akamai Diversity

The Akamai Blog

Make Your Infrastructure Vanish

Are you delivering or thinking of delivering your web presence or application through a CDN? The many reasons to do so are well documented. Your site will be faster, more reliable, and you will require less data centre bandwidth and infrastructure. All this leads to a better user experience, which affects profitability, customer retention, conversation rates, etc. But this post isn't about why you should use a CDN. We're going to examine why you should hide your hosting presence (the Origin as we refer to it) from the Internet and how to do it.

Performance aside, a major benefit of using a CDN is it takes the hit in the event of an application level or Distributed Denial of Service (DDoS) attack. Let's be clear, you want attacks directed at your CDN instead of your Origin. A CDN like Akamai is distributed by nature, has significant Internet capacity to absorb the largest attacks, and can dynamically change it's behavior based on the type and amount of traffic. However if can attacker can communicate directly with your Origin, your servers would receive the attack directly without any protection from your CDN. This bypasses the CDN security controls which can cause your Origin's Internet or computing capacity to max out, get compromised, or leak data. Not only is it beneficial for users to communicate with a CDN, they should never communicate directly with your Origin. To accomplish this, they shouldn't know how to get to your Origin. If they don't know the IP address of your Origin, they can't attack it directly and attacks must be routed through your CDN.

Let's go over some common places where your Origin can be exposed how to hide (or "cloak") it. 

Generic Hostnames

Your CDN needs to know how to get to your Origin so it can retrieve content. This is typically done by configuring the Origin's hostname with your CDN. Don't create a hostname that is easy to discover. For example the website www.acme.com shouldn't use the Origin hostname origin.acme.com. Try using a nondescript hostname that isn't easy to guess. Maybe knowonewillguessthislonghostname.acme.com. Your Origin's hostname doesn't even need to be on the same domain name as the website it is serving!

DNS History

Has the DNS for your site ever mapped directly to the Origin? Maybe during a maintenance? Or before you used a CDN? This information is like an announcement on the radio. Once it's out, you don't know who heard it, and need to assume it's gotten into the wrong hands. DNS history tools track what IP addresses your hostnames have resolved to in the past. Best practice is to also change the IP address of your Origin when you onboard to a CDN. Already using a CDN? It's not too late to change your Origin's IP address.

Other easy to find services

Are there other, non web, services that reside in the same data centre or hosting provider as your Origin? Maybe VPN, FTP, or Mail? Are these services discoverable? Maybe through a skim of your website, DNS scanning tool, or MX record? Even if these services are provided by completely different systems, it's possible for an attacker to attack these systems (which you don't want either) which could flood the same network pipes your Origin uses.

Lock down your Origin

Best practice is to have ALL traffic go through your CDN. This means users shouldn't communicate directly with your Origin. When you're at this point, use a service like Akamai's Site Shield to lock out connections that don't come from your CDN. This will effectively cut the cord between your Origin and the rest of the Internet. This is an extremely effective means of preventing direct-to-origin application attacks.

Disable visitor initiated outbound connections

Are you running WordPress (or another CMS) that supports automated XML-RPC requests? It's possible for an attacker to uncover your origin by forcing it to make an outbound connection to a server they control through a Pingback attack. Earlier versions of WordPress with XML-RPC enabled may also be vulnerable to DDoS attacks. 

Root domain redirects

Let's assume a user is navigating to your website www.acme.com. However instead of typing www.acme.com, they only type acme.com. Time to get a little technical. Hostnames are connected to a DNS based CDN like Akamai via a CNAME, which is a type of DNS entry that aliases the IP address resolution of one hostname to another hostname. For example www.acme.com could CNAME to webserver.acme.com and when resolving www.acme.com, DNS would follow the resolution chain of webserver.acme.com. For a fully qualified hostname like www.acme.com, you create a CNAME that will resolve to a hostname your CDN controls, which intern directs users to a CDN server that will serve your user. However it's not possible to create a CNAME for a root domain like acme.com. It must have an A record, which resolves to an IP address. To get around this, many websites resolve their root domain to the IP address of their origin, and then have their origin server perform a HTTP redirect to their www hostname. This is another place your Origin can be revealed.

There are several options allow users to visit your root domain name and still visit your website: 

1. Leverage a third party hosting provider to perform the HTTP redirect of acme.com to www.acme.com

2. As an Akamai customer, leverage our FastDNS product. FastDNS is our high performant and highly reliable authoritative DNS service. It is also integrated with the Akamai Intelligent Platform and can resolve your root domain name directly to Akamai's CDN.

Leave a comment