Network security technology alone, while vitally necessary, cannot defeat the ever-changing distributed denial of service (DDoS) toolkits and DDoS attack vectors of sophisticated cyber criminals.
The following best practices for DDoS protection can give you a much needed edge to defend your organization’s network infrastructure and web applications.
DDoS protection for the network layer: bandwidth and filtering systems
Defending against volumetric denial of service attacks occurring at the network layer requires two components: a resilient network architecture that can absorb large blasts of traffic and a system to detect and filter network traffic so that only legitimate traffic is permitted onto the network.
The following are DDoS protection best practices for the network layer.
1. One of the ways traffic is filtered for DDoS protection is called positive protection, where traffic is dropped from ports other than 80 and 443 (HTTPS) to eliminate excessive TCP SYN packets, floods of ICMP packets and UDP packets without application payloads.
2. Not all DDoS attacks target web applications or web services, however. Some DDoS attacks will attempt to sneak in through FTP or non-web ports and may attempt to bring down network access to a call center, for example. Some organizations will need DDoS protection for network infrastructure.
3. DDoS protection security controls only serve your web site or application when they are on. IDG Research found that on average, a DDoS attack isn’t detected until 4.5 hours after its commencement, and an additional 4.9 hours passes before mitigation commences. Always-on DDoS protection provides the fastest DDoS defense. A service level agreement can help to ensure promised DDoS protection levels.
4. While an organization may not be able to purchase enough excess capacity on its own, a DDoS protection provider may have access to the bandwidth needed. Ask the provider what peak flows they can accommodate.
5. Even if your cloud service provider is capable of protecting your site, you may not be able to afford the cost of all the extra traffic generated by a DDoS attacker. Look for a service provider that caps service fees.
6. Cloud solutions are designed to stop an attack before it ever reaches your data center, so you need not be concerned about DDoS attacks impacting that resource. On premise devices, however, require the attack traffic first invades your data center.
7. Determine your site performance requirements and look for a solution that’s architected for both performance and security.
8. When determining total cost of ownership (TCO), consider device costs, redundant system costs, management costs, the costs of failure, and system effectiveness against innovative and zero-day DDoS attacks.
Many attacks at the application layer that seek to deny service or steal data look like legitimate requests and start with a simple application request. DDoS protection for web applications requires two components: closing down vulnerabilities in the applications and front-ending applications with a web application firewall (WAF).
1. A WAF can be targeted and overwhelmed just like any other network component so it needs DDoS protection itself.
2. Know what will happen to network performance when using stateful inspection, such as SYN cookies, versus stateless blocking.
3. A firewall will usually offer only limited DDoS protection against UDP and ICMP floods and no protection against a 2 or 3 Gbps SYN flood and application layer attacks.
4. Firewalls provide little or no DDoS protection against low speed application layer attacks that involve HTTP and HTTPS requests through the firewall.
5. Cloud-based ISP firewalls provide limited DDoS protection. Not every type of ISP firewall can handle every type of DDoS attack and ACLs can fail.
6. An on-premise firewall or ACLs at the ISP layer will require a lot of complex rule changes during a DDoS attack. A cloud-based DDoS protection service eliminates these time-consuming tasks.
7. While most solutions come can block well-understood attacks, attacks are constantly evolving. Cloud service providers see significant amounts of traffic and can therefore detect new types of attacks as they appear, create new rules to diagnose these attacks, and make them available to all their customers globally.
8. Organizations should always install new versions and patches of their software. However, these patches must be tested before they can be installed, which can take time. A solution that allows you to create custom rules can serve as virtual patches to prevent attackers from exploiting the vulnerability until a patch is put in place.
9. You may want the ability to permit someone who’s performed a Google search, but block someone who searched on nurl:basket.php.
10. Black lists, white lists and geo (geographical) blocking allow you to selectively allow or filter IP addresses.
11. Behavior-based rules allow you to look at how many requests a user is making per given time period and block users who make too many requests or generate too many 404 page-not-found error messages.
12. Does it offer origin cloaking?
13. Origin cloaking shields a website or application server from the Internet, preventing users from directly connecting to it unless they are on the provider’s own network.
14. You can address DDoS attacks against DNS servers and DNS reflection and amplification attacks using the same security controls that mitigate any other network-based DDoS attacks. But dealing with cache poisoning and registrar hijacking requires two capabilities: support for DNSSEC and use of a registry service with tight controls to prevent social engineering attacks.
The State of the Internet site provides resources to help enterprises understand, detect and stop DDoS attacks:
1. DDoS threat advisories
2. DDoS white papers
3. DDoS trends and statistics
4. Blogs: Insight into current cybersecurity issues
5. Global map of DDoS attacks
6. About DDoS protection
7. FAQs and best practices.