Our CDN service is designed to deliver content around the world in a secure and efficient manner. This is achieved through the following security measures:
Security Measure | Overview |
---|---|
Our CDN architecture is designed to:
|
|
Our sophisticated software is designed to quickly detect and mitigate volumetric DDoS attacks that target the network layer (layer 3)This layer in the OSI model is responsbile for routing data across the network.. |
|
This product secures an origin server against malicious attacks that target the application layer (layer 7)This layer in the OSI model is responsible for providing network service to software. through real-time threat detection and mitigation. Ensure the uninterrupted flow of legitimate traffic by defining a threat detection profile tailored to match business requirements. |
|
Additional protection may be applied to sensitive content. This type of protection ranges from HTTPS support to request-based rules. |
It is strongly recommended to cloak your origin to protect it against attacks that directly target your web servers and thereby bypass the security provided by our CDN service.
The following diagram illustrates the various levels of security that CDN traffic must undergo before it reaches an origin server. These security mechanisms are designed to filter malicious requestsBlack bars represent malicious requests that were identified and mitigated by our security measures., even if they pose as legitimate traffic, before they can reach an origin server. In the following diagram, requests flow from clients (bottom) to origin servers (top).
A base security layer that provides generic protection against malicious attacks is derived from the following core CDN design principles:
Our CDN leverages a reverse proxy system to deliver content around the world. The flow of data in our reverse proxy system is described below.
If the requested content has not been previously cached in that POP, then an edge server will act as a proxy server between the requester and the CAN Gateway server. In other words, it will forward the request to the CAN Gateway server as if the edge server were requesting it.
This reverse proxy system does not expose information on a customer origin's web servers (e.g., IP addresses) and prevents requesters from engaging directly with them. Preventing traffic from bypassing the CDN ensures that our security measures may be used to detect and mitigate malicious attacks on your origin server.
An origin server's firewall should be configured to only allow traffic from our network. This type of setup makes a direct attack on the origin server ineffectual.
All CDN traffic must be directed to authorized ports (as described below). All non-standard port traffic will be automatically blocked. This measure simplifies our security setup and reduces the entry points for a malicious attack.
Protocol | Authorized Port |
---|---|
HTTP |
80 |
HTTPS |
443 |
Our CDN's capacity combined with its distributed nature allows it to absorb a DDoS attack that would easily overwhelm a site's origin servers. However, absorbing an attack is an inefficient use of our resources. For this reason, we have developed a variety of other security measures through which DDoS and other malicious attacks may be mitigated.
Historically, volumetric DDoS attacks have targeted the network layer (layer 3), since it is responsible for routing data across the network. For this reason, we have developed intelligent, real-time monitoring and detection software that is designed to mitigate 99% of DDoS attacks directed at the network layer within 60 seconds of identification. This layer of protection takes place at each POP's point of entry for network traffic. This ensures optimal edge server performance by diverting malicious traffic before it has a chance to infiltrate our network and your origin servers. As a result, our customer's sites are always accessible and available to legitimate visitors.
Due to our commitment to secure and efficient data delivery performance, we provide network layer security free of charge for all CDN traffic.
Malicious traffic is identified through the analysis of network traffic for anomalies. Examples of network traffic anomalies are listed below.
Anomalies in network traffic are detected by finding trends in global traffic patterns. A trend may range from either a significant increase in SYN packets to a slow and steady rise in persistent connections. Either way, our system will detect the anomaly, mitigate it via automatic rate limitingRefers to the practice of controlling the rate of traffic. This practice is typically used when malicious traffic cannot be segregated from legitimate traffic without human intervention. This stopgap measure prevents malicious traffic from significantly impacting network traffic without blocking legitimate traffic. and black holingRefers to the practice of silently discarding packets. strategies, and alert our 24/7/365 monitoring staff for further analysis/action.
Our system is also designed to perform additional analysis on malicious traffic with the goal of crafting signature filters. These filters facilitate more efficient mitigation of similar attacks in the future by allowing quicker identification, verification, and segregation of malicious traffic.
The application layer (layer 7), which is responsible for providing network services to software, is increasingly under attack by SQL injections, cross-site scripting, trojans, and other similar malicious traffic. These types of attacks mimic legitimate traffic and therefore are not mitigated by our network layer security. The intended targets of these attacks are web sites, web applications, and web servers. Our WAF solution provides a layer of security between these security threats and your infrastructure. This service monitors, detects, and prevents application layer attacks by inspecting HTTP/HTTPS traffic against reactive and proactive security policies and blocking malicious activity in-band and on a real-time basis.
An additional layer of security may be applied to sensitive content in an effort to preserve the confidentiality of data delivered over the CDN. Our CDN offers the following services through which content may be secured:
Service | Description |
---|---|
Provides the ultimate amount of flexibility for determining what type of content should be secured. Setup involves defining a rule that identifies content by one or more factors (e.g., origin, edge CNAME, URL, file extension, etc.). All matching requests may then be secured by:
|
|
Requires request for secured content to include a token that defines the set of requirements that must be met before access will be granted. Content may be secured by:
|
|
Allows content to be secured by the region from which the request originated. |
|
Transmit encrypted data via Transport Layer Security (TLS) to ensure secure end-to-end data transmission through the HTTPS protocol. HTTPS data delivery requires the installation of a TLS certificate on our network. Our support for OCSP stapling allows our CDN service to combine secure communication with optimal performance. |
Edgecast CDN