Prior to the attack, Anonymous announced their intention to take down the websites of the UK Prime Minister, the UK Justice Department, the London City government, the Swedish Foreign Office, and others. The campaign was coordinated using Facebook and Twitter under the hashtag: #OpFreeAssange.
At the time of writing, the DDOS attacks are still going on and are expected to continue in the next few days.
Background
Julian Assange, the founder, and editor of the whistleblowing website WikiLeaks, had been ordered by Swedish authorities to be extradited from the UK, where he had been under house arrest. Fearing that being sent to Sweden would mean that he would be then extradited to the US to be tried for his role with WikiLeaks, Assange applied for and was granted political asylum in Ecuador. He is currently at the Ecuadorian embassy in London, but British authorities have refused to give Assange safe passage out of the city to travel to that country.
Last week, before Ecuadorian President Rafael Correa had approved the asylum bid, British authorities threatened to storm the embassy. This prompted supporters of Assange and WikiLeaks to surround the building overnight in hopes of deterring any attempt by the UK to follow through with the extradition. The current wave of online attacks against the UK government is an outgrowth of these events.
How The Attack Was Launched
The group uses a relatively new form of DDoS attack called Web LOIC (Low Orbit Web Cannon). Web LOIC leverages many end-user computers using pure browser technology (JavaScript) to launch the attack. Traditional DDoS attacks use dedicated bots to launch millions of requests to a website, which can be identified and blocked. Web LOIC instead uses modern web technology to allow anyone with a computer to open a browser, navigate to a web page that Anonymous built, and start an attack. For each attack request, the attack technology generates a random and legitimate user agent string, and a legitimate referer string (See below for an example). Browser-based attacks like this are much harder to identify and defend against.
The Result
Even though Anonymous announced the attack before it began, many government websites went down. Some of them went offline for more than 14 hours.
Websites that went down include:
- London Government site (see above) – offline for 14 hours and still offline at the time of writing
- UK Justice Department website
- UK Government Gateway Service site
- UK Foreign and Commonwealth Website
- Sweden Foreign Office site
How to Protect Against Browser-Based Attacks
Traditionally, DDoS attacks could be mitigated or stopped by blocking the bots carrying out the attacks once they are identified. But with Web LOIC attacks, the real browsers carry out the attacks, making the job of attack mitigation more difficult.
At Yottaa, we help many websites deal with performance, security, and scale challenges. Through our experience, our recommendation to deal with this kind of new browser-based DDOS attacks are:
1. Configure existing firewall services for blocking and throttling. Though traditional tools may not be as effective when it comes to modern browser-based DDOS attacks, configuring them to do blocking and throttling can still be helpful. With throttling, you set a limit on the number of times any client — be it a bot or a real browser — can hit your site in a given period of time. Any client that exceeds the limit will be cut off. For tips on finding your appropriate throttling limit, check out our blog post on
bot traffic.
2. Leverage cloud-based firewall services. The bottom line for mitigating a large-scale DDOS attack is to have enough capacity to handle the volume. In the not-so-distant past, building a large-scale infrastructure was prohibitively expensive and thus wasn’t feasible for most businesses. Then the cloud changed everything. Now, cloud-based firewall services are built to be elastic and are able to scrub and offload an influx of traffic onto a global network efficiently and automatically. A hybrid-cloud network that includes both cloud servers and terrestrial servers positioned around the globe is best for this.
3. Your defense mechanism needs to be highly flexible and configurable. You must be able to respond in real-time to attacks. You simply cannot pre-program defense for real-browser attacks, since the attacks are coming from what looks like legitimate traffic. For example, below is a typical HTTP request sent during the current attack:
The request is cleverly made to look like it’s from a Google query and is a regular user agent, making it impossible for an automated defense mechanism to distinguish it from normal traffic. What’s more, it disables caching by using a Cache-Control set to “no-cache,” meaning the web server needs to process and generate every request, adding much more pressure to the server.
A site owner who sees a pattern of requests that look like this (or, in this case, notices the “OpFreeAssange” hashtag in the GET request) should be able to configure the defense mechanism to respond to specific kinds of requests. For example, with the right defense arrangement, you can override the no-cache and set all requests that follow the pattern you’ve identified to be served from the cached “edge” rather than the server, neutering the attack even as it continues to happen.
Be Prepared
The bottom line: be prepared. Some of the UK government websites went down, but not all of those attacked did. Using methods and tools that are as current as the hackers can keep your site ahead of the curve.
