Share with Your Network
I was recently invited to speak at one of my favorite security conferences, SecTor in Toronto. Many thanks to Risk I/O for giving me some official time to work on this side project over the last month (side note: we are hiring!). This blog post will summarize my SecTor presentation on application Denial of Service attacks.
Application DoS has seen a rise in popularity over the past few years. One of the primary advantages for attackers is that they don’t need a particularly fast connection or an army of drones to successfully knock a target offline. These attacks are directed at either the web server software, or the application you have written to handle user requests.
Application DoS that is directed at web server software has proven to be particularly effective against Apache and similar styles of software. They are configured with a maximum threshold for simultaneous requests, and once that number has been exceeded, no further requests will be serviced. This is intended to limit resource exhaustion on the host, but if a malicious host can make a large number of connections, no legitimate requests will be processed.
Additional attack opportunities come from expensive or slow queries in your application. Any operation that doesn’t return quickly has the potential to tie up the web server, backend resources like a database, or both. If an attacker can find a page that takes 10 seconds to render, requesting that page thousands of times may slow your server or infrastructure to a crawl.
At SecTor, I launched a simple mitigation framework called Bouncer that helps with mitigation of these attacks. Bouncer consists of a proxy server, a log aggregation server, and a set of consumers that read proxy events and make decisions based on these events.
When a request is accepted by a proxy, a JSON string containing relevant information is sent to the aggregator. The aggregator is a very simple pub/sub service that facilitates communication between proxies and consumers. Consumers are individual processes that monitor various parameters across multiple requests and make decisions such as blocking a host that has exceeded a threshold. Consumers are how most implementors will customize Bouncer for their website. A small collection of example consumers is included with Bouncer, such as one that looks for too many connections from a single IP address. Once this number is exceeded, the host is blocked for a set number of seconds.
You can check out the node.js source code for Bouncer, along with a number of example Python based consumers at its GitHub project page. This project is very new, so ideas and contributions are appreciated. Blocker has already seen interest from a number of people with deep knowledge of slow DoS, and I look forward to collaborating with these people in the future.
Thanks again to both Risk I/O and SecTor for allowing me to present on this subject. It was my first opportunity to speak in front of a security focused audience, and the experience was excellent. If you have a similar idea, I encourage you to develop and release it to the security community, who has been welcoming and generous with their time.
