Content Delivery Network (CDN)

• A content delivery network or content distribution network (CDN) is a system of computers containing copies of data placed at various nodes of a network. When properly designed and implemented, a CDN can improve access to the data it caches by increasing access bandwidth and redundancy and reducing access latency.

http://en.wikipedia.org/wiki/Content_delivery_network

• Akamai

Akamai Web Application Acceleration and Performance Management, Streaming Media Services, and Content Delivery help companies build better web
http://www.akamai.com/

• limelight

http://www.limelight.com/

• Bypassing the CDN protection

In this article, you are going to learn how to skip the protection layer of a CDN. First of all, a CDN (Content Delivery Network), a service which acts as a reserve proxy
Many users use a CDN to shield their servers against DDoS attacks, as it receives all the traffic’s website and blocks these kind of requests before they deliver at the website’s server.
You need to know that the CDN supports protocols like HTTP and HTTPS, so if you have any other services like SSH or FTP, they will be obfuscated behind the CDN
An attacker will need to know the IP if they want to access to any of this services.

1. Subdomains
By using online tools like Dnsdumpster or similar, you can obtain a list of the indexed subdomains.
If you check them, you will find two ways to discover the IP.

The first one consists of looking for the services which are pointing to the CDN and it does not accept it. Some of these services may be on the same machine, so you can discover the IP. For example:
ftp.sitio.com
smtp.sitio.com
dns.sitio.com


1.1.Subdomains not indexed
If you want to find more subdomains, you need to use more tools which work by brute force. They are very useful when there are “private” subdomains with uncommon names, and they are not indexed to search engines. In these kind of searches it is reccomended to use tools like our own Fast Subdomain Scanner.
Once you have obtained all the subdomains, you can analyse which IP’s point at these subdomains.


The second way, you need to check all the IP’s which are pointing to the differents subdomains. Sometimes, a bad configuration might disclose the real IP by avoiding the CDN protection.
2. DNS track
Your servers might be pointing to the same IP direction after starting to work with the CDN. If you use any online tool to obtain the DNS track of your domain, then you will discover the IP. Some tools like Dnstrails or Viewdns can help you in this task.

3. IOT Tools
3.1. Shodan
the ssl filter by Shodan, as it lets you look for the strings in the certifications stored at the scanned IP.
3.2. Censys
Censys scans servers and saves related information of the server’s certificates.
it has a historical section where past results are stored.
3.3. Zoom Eye

4. Email headlines
Checking email headlines is another way to find the IP of a server.
https://opendatasecurity.io/how-to-bypass-cdn/

• What is CloudFlare? What does CloudFlare do with my website after I activate my website on CloudFlare?

CloudFlare is a Content Delivery Network which builds up a wall between the website and the visitor. Only visitors are allowed to go through CloudFlare and even search engine crawlers are allowed but not attackers. CloudFlare covers the real IP address of the website with their IP address. Mostly CloudFlare IP(s) starts with 104.x.x.x.

https://theshadowpress.com/configuring-cloudflare-website-to-avoid-getting-it-bypassed/

• A typical TCP connection is established through a process known as a three-way handshake. In it, a client sends out a connection request (SYN), receives an acknowledgment (SYN/ACK) and then responds with an acknowledgment of its own (ACK). This closes the loop and establishes the connection.

negotiating a SSL/TLS connection requires a few additional back-and-forths. This is because the browser and server now also need to:

    Agree upon a mutually-compatible method of encryption.

    Go through a process of mutual verification.

    Generate symmetric keys, used to encode and decode all information exchanged during the session.

These extra interactions add overhead to the process, resulting in two additional round trips—or more, depending on your server’s configuration.

Solution:

Use a CDN to Reduce Round Trip Time

Shortening round trip time is a core function of CDN—a service specifically designed to improve response speeds by reducing the physical distance between your website and its users.

What is a CDN

Content delivery networks (CDN) are the transparent backbone of the Internet in charge of content delivery.

To understand why CDNs are so widely used, you first need to recognize the issue they’re designed to solve. Known as latency, it’s the annoying delay that occurs from the moment you request to load a web page to the moment its content actually appears onscreen.

In all cases however, the delay duration is impacted by the physical distance between you and that website’s hosting server

A CDN’s mission is to virtually shorten that physical distance, the goal being to improve site rendering speed and performance.

points of presence, or PoPs

How a CDN Works

To minimize the distance between the visitors and your website’s server, a CDN stores a cached version of its content in multiple geographical locations (a.k.a., points of presence, or PoPs). Each PoP contains a number of caching servers responsible for content delivery to visitors within its proximity.

For example, when someone in London accesses your US-hosted website, it is done through a local UK PoP. This is much quicker than having the visitor’s requests, and your responses, travel the full width of the Atlantic and back.

Specifically, if you are running a strictly localized website, with the vast majority of your users located in the same region as your hosting, having a CDN yields little benefit. In this scenario, using a CDN can actually worsen your website’s performance by introducing another unessential connection point between the visitor and an already nearby server.

CDN BUILDING BLOCKS

PoPs(Points of Presence)

CDN PoPs (Points of Presence) are strategically located data centers responsible for communicating with users in their geographic vicinity. Their main function is to reduce round trip time by bringing the content closer to the website’s visitor. Each CDN PoP typically contains numerous caching servers

Caching Servers

Each CDN caching server typically holds multiple storage drives and high amounts of RAM resources.

SSD/HDD + RAM

Inside CDN caching servers, cached files are stored on solid-state and hard-disk drives (SSD and HDD) or in random-access memory (RAM), with the more commonly-used files hosted on the more speedy mediums

START USING A CDN

For a CDN to work, it needs to be the default inbound gateway for all incoming traffic. To make this happen, you’ll need to modify your root domain DNS configurations (e.g., domain.com) and those of your subdomains (e.g., www.domain.com, img.domain.com).

For your root domain, you’ll change its A record to point to one of the CDN’s IP ranges. For each subdomain, modify its CNAME record to point to a CDN-provided subdomain address (e.g., ns1.cdn.com). In both cases, this results in the DNS routing all visitors to your CDN instead of being directed to your original server.

START USING A CDN

For a CDN to work, it needs to be the default inbound gateway for all incoming traffic. To make this happen, you’ll need to modify your root domain DNS configurations (e.g., domain.com) and those of your subdomains (e.g., www.domain.com, img.domain.com).

For your root domain, you’ll change its A record to point to one of the CDN’s IP ranges. For each subdomain, modify its CNAME record to point to a CDN-provided subdomain address (e.g., ns1.cdn.com). In both cases, this results in the DNS routing all visitors to your CDN instead of being directed to your original server.

Why isn’t a CDN a Default Part of my Website Hosting?

In an ideal world, a CDN would be an integral part of any website hosting. However, when CDNs were first established in the late 1990s, they were far too expensive and only accessible to the largest organizations.

THE EVOLUTION OF CDNs

1st Gen Static CDN

2nd Gen Dynamic CDN

3rd Gen Multi-Purpose CDN

REVERSE PROXY LIVING ON THE EDGE

Content delivery networks employ reverse proxy technology. Topology wise, this means CDNs are deployed in front of your backend server(s).

the reverse proxy topology is being leveraged by multi-purpose CDNs to provide the following types of solutions:

Website Security

Deployed on the edge of your network, a CDN is perfectly situated to act as a virtual high-security fence and prevent attacks on your website and web application. The on-edge position also makes a CDN ideal for blocking DDoS floods, which need to be mitigated outside of your core network infrastructure.

Load Balancing

Load balancing is all about having a “traffic guard” positioned in front of your servers, alternating the flow of incoming requests in such a way that traffic jams are avoided.

Clearly, a CDN’s reverse proxy topology is ideal for this, as is the default recipient of all incoming traffic.

https://www.imperva.com/learn/performance/what-is-cdn-how-it-works/

• As of 2015, the last version of SSL (3.0) was officially deprecated. It has been replaced by TLS (Transport Layer Security), which provides stronger encryption while serving a similar function. However, the original name has stuck; many still refer to TLS as “SSL/TLS” or simply “SSL”.

How A CDN Can BOLSTER SSL/TLS PERFORMANCE

let’s first review how an SSL connection differs from it regular TCP counterpart.

A typical TCP connection is established through a process known as a three-way handshake. In it, a client sends out a connection request (SYN), receives an acknowledgment (SYN/ACK) and then responds with an acknowledgment of its own (ACK). This closes the loop and establishes the connection.

the time it takes to complete the handshake should be exactly equal to a single round trip time (RTT)

negotiating a SSL/TLS connection requires a few additional back-and-forths. 

This is because the browser and server now also need to:

Agree upon a mutually-compatible method of encryption.

Go through a process of mutual verification.

Generate symmetric keys, used to encode and decode all information exchanged during the session.

These extra interactions add overhead to the process, resulting in two additional round trips

For example

If the round trip time from San Francisco to your London server is 50 ms, then establishing a SSL/TLS handshake will take at least 150 ms.

Solution:

Use A CDN To Reduce Round Trip Time

Shortening round trip time is a core function of CDN—a service specifically designed to improve response speeds by reducing the physical distance between your website and its users.

CDN also speeds up all interactions during the SSL/TLS negotiation process

What is important here is to ensure that your CDN has a keep-alive functionality, also referred to as a persistent connection. With a keep-alive, a CDN maintains an open connection with the server between different user sessions for a few minutes at a time.

as long as your website is visited once every few minutes, the CDN and origin server won’t have to reengage in additional SSL/TLS negotiations. All of your visitors benefit from faster handshake times.

For example

After the SSL connection with the LA proxy is established, in the absence of a keep-alive functionality, the CDN has to re-open the connection with the origin server in London.

The round trip time between LA and London is 30 ms, so it will take 90 ms to negotiate the second SSL connection. This brings the total handshake time back to 150 ms.

the amount of round trips required for a SSL/TLS handshake depends on your server’s configuration. For example, extra round trips occur when your server isn’t optimized to handle TLS records above a certain size, resulting in additional back-and-forth interactions.

some server configurations can accelerate SSL/TLS communications, including:

False Start Enables the browser to send encrypted application data even before the SSL negotiation is complete.

Session Resumption Caches a visitor’s and server’s information to reduce negotiation times for repeat visitors.

SL/TLS communications rely on the existence of SSL certificates. These contain information about your domain and organization, in addition to the public key used to initiate the encrypted communications.

there is a difference between those SSL certificates purchased from an official certificate authority (CA), and free (self-signed) ones that can be generated using the OpenSSL toolkit.

a CA certificate is clearly a much better and more trusted option

using a self-signed certificate causes all of your visitors to get an alarming message every time they try to access your HTTPS assets. This can result in a huge dent in your traffic.

all SSL/TLS certificates are graded based on the quality of their individual implementation, usually based on the following criteria:

Protocol support – Preference is given to implementations that enforce the latest and most secure protocols.

Key exchange support – Preference is given to implementations using stronger cryptography when encoding session keys (e.g., Diffie-Hellman 2048-bit parameter).

Cipher support – Preference is given to implementations enforcing ciphers having stronger encryption (e.g., 256-bit).

CDN For An No-Hassle Grade A+ Certificate

Using a CDN means that the first leg of your SSL/TLS connection is always established using the provider’s own certificate, hosted on a CDN proxy. This has the benefit of auto-optimizing the security aspects of your SSL communications.

when new SSL vulnerabilities emerge—as they sometimes do—your CDN provider is likely to respond to them much more quickly than you can, updating its SSL implementation as part of your managed service.

This was the case with Heartbleed and POODLE vulnerabilities. CDN users were among the first to be protected

Two Are Better Than One

Even with a CDN auto-optimizing the first leg of your SSL connection, it’s still advisable to improve the implementation on the second leg by tweaking the SSL configuration on your origin server.

CDNs for Easy HSTS Activation

HTTP Strict Transport Security (HSTS) is a security feature that ensures that your domain are only accessed via a SSL/TLS connection. HSTS is particularly useful to websites having multiple subdomains, since it can be used to effortlessly manage SSL/TLS across all of of them in bulk.

https://www.imperva.com/learn/performance/cdn-and-ssl-tls/

Change the (S)Channel! Deconstructing the Microsoft TLS Session Resumption bug

https://blog.cloudflare.com/microsoft-tls-downgrade-schannel-bug/

Speeding up HTTPS with session resumption

https://calendar.perfplanet.com/2014/speeding-up-https-with-session-resumption/

A cosa serve TLS Session Resumption – Session Reuse

https://www.evemilano.com/tls-session-resumption/

• CDN uses DNS CNAME record to hide your origin (source) server. 

the SOA or primary DNS server 

SOA stands for Start Of Authority

CDN can also protect your primary/master DNS server (SOA)

CDN have the ability to “pull” content from their origin server during HTTP requests in order to cache them

GET request, CDN can also proxy POST requests.

check with your CDN provider to block PUT, TRACE, DELETE, CONNECT, which are unsafe HTTP methods.

WAF is not possible to protect all layer 7 attacks

 E.g. Application business logic bypass

WAF uses regular expressions to block matching attack patterns

WAF regex needs to be constantly fine tune and improve to block clever attacks

WAF can be bypassed given the attack enough time to figure out

Example: Blind SQL Injection WAF regular expression bypass

CDN WEAKNESS

your origin server's IP address is no longer advertised over DNS, it's still connected to the internet

If your IP address is not kept secret, attackers can bypass the CDN to attack your servers directly

CDN Security Protection Best Practices

Don’t use guessable origin domain name. The attacker can guess the origin system DNS record to bypass the controls. Or using Shodan (http://shodanhq.com)

Disable CDN debugging features. The debugging information can be used by attacks to design a DDoS attack.

Only allow your Origin server to communicate with your CDN servers by white-listing the CDN servers on your firewall.

Only allow your Primary DSN server to communicate with your CDN DNS servers by white-listing the CDN DNS servers on your firewall.

To prevent Direct-to-Origin attacks Subscribe to your ISP Clean-Pipe service or to a Scrubber service provider.

https://www.slideshare.net/AndrewChong7/content-delivery-network-and-web-application-firewall-v12

CDN Debugging Tips: Part 1

When using curl to debug CDN behavior, don't ever use curl -I. Using the I flag results in sending a HEAD request and that is often pointless and unintended. Your users will send GET requests not HEAD requests and the CDN may treat HEAD requests very differently from GET requests. So remember: don't use curl -I, ever

Don't test against just one POP

To send a request to a specific target endpoint (e.g. a CDNetworks server in Amsterdam), use the -H flag to add a Host header with your domain:

curl -svo /dev/null -H 'Host: cdn.yourdomain.com' 'http://91.194.205.21/path/to/file'

https://www.cdnplanet.com/blog/cdn-debugging-tips-part-1/