Responding to DoS attacks at the web layer

Are you ready to respond to DoS attacks at the web layer? In this article, Kevin Beaver shares an anecdote from his own experience whilst highlighting some important steps to take.

First things first; responding to DoS attacks at the web layer starts with ensuring you have a solid incident response plan in place. But what else do you need to be thinking about? Are DoS attacks at the web layer simple to thwart? Many believe it’s just a matter of getting on the phone with your Internet or hosting provider and have them block the attacks for you. Well, it’s not always that simple. It can be downright impossible if you’re experiencing a distributed DoS (DDoS) attack. Every DoS attack is unique and so are the web environments they’re attempting to exploit.

During a recent project, I learned first-hand what a seemingly benign DoS attack can do to a business’s web presence.

I have a client who hosts numerous high-visibility websites for various enterprise customers. Over 10 years ago, one of the hosted websites had a vulnerable page that effectively served as an open HTTP proxy. Even though the file was long gone, it somehow made it to an underground list of known vulnerable web pages. Criminal hackers then decided to try and take advantage of this vulnerable page by making numerous requests that evolved into an outright distributed denial of service situation for my client.

My client started to notice high utilization in their web server farm and tons of requests for this page that no longer existed. Once I got involved they were getting approximately 12,000 requests for this page every minute. The attack quickly grew to around 20,000 page requests per minute. The cloud service providers wouldn’t want you to know this but this website and phantom page was being hosted in one of the prominent cloud environments that everyone has heard of – a provider who could (presumably) handle such an attack. That certainly wasn’t the case.

It got to the point where my client was about to lose its biggest customer because their website was becoming non-functional. Thanks to some niche players with content delivery and cloud-based WAF technologies that can help offload such nasty traffic (namely Imperva, CloudFlare and Incapsula), my client has since seen some relief.

During this project, we learned a lot about web-based DoS attacks and what does and doesn’t work. Here are some findings you may find beneficial:

1. You might not know a DoS attack is occurring unless/until someone tells you about it. I suspect my client’s problem was ongoing for a while. They just started noticing it once their customer pointed out the problem. This issue is underscored by the recent Verizon 2013 Data Breach Investigations Report finding that 69% of attacks/intrusions are discovered by external parties. That in itself is not good for business.
2. You can reach out to your ISP and your hosting provider to see if they can do anything to help block the attacks. If it’s a DDoS attack from hundreds or thousands of hosts, this could prove difficult
3. If you experience a situation similar to my client’s and you believe that the pages (whether real or phantom) are being discovered/listed by the search engines, you can reach out to Google, Bing, and others to request link removal.
4. You can also send an email to the ‘abuse’ contact listed in the attacking host’s DNS records. It may prove futile, especially during a distributed attack, but it’s something to keep in mind.
5. You can experiment with various web server configuration and page setups. For example, my client created a bogus page on their website that mimicked the vulnerable page being requested. This ended up reducing their traffic by a considerable amount. We assumed this was because the systems doing the requesting were getting an HTTP 200 OK versus an HTTP 404 Not Found or HTTP 403 Forbidden – the latter two of which could’ve been forcing secondary requests for the file and thus generating the extra traffic.
6.  You can use a cloud-based WAF provider such as Imperva, CloudFlare or Incapsula for near immediate relief without having to make any internal network infrastructure changes. However, if the attacker knows the IP address of your web server he can just try connecting to it directly rather than taking the route of traditional DNS lookups and redirects so that the traffic can be filtered before it gets to your network. This begs the question: How long are these DoS mitigation technologies going to be able to hold out? Given enough DoS attacks coming through their systems, one would think that even they will get bogged down at some point.
7.  Attacks like this may be completely automated with numerous zombie computers on the other end making the requests so don’t take it too personally and automatically assume it’s a targeted attack.

Again, every situation is going to be unique, but it pays to think about how you’re going to address such issues before they arise.

Keep in mind that these types of vulnerabilities are not going to be uncovered by traditional web security scanning and testing. This fact underscores the importance of 1) understanding your network and web application environment 2) knowing what’s “normal”, and 3) having the means to detect, track down, and block such attacks.

THE AUTHOR

Kevin Beaver

LinkedIn

Kevin Beaver, CISSP is an independent information security consultant, writer, and professional speaker with Atlanta, GA-based Principle Logic, LLC. With over 32 years in IT and 26 years in security, Kevin specializes in vulnerability and penetration testing, security program reviews, and virtual CISO consulting work to help businesses uncheck the boxes that keep creating a false sense of security.