dmitri

dmitri

Distributed Deflect – project review

This is the fifth year of Deflect operations and an opportune time to draw some conclusions from the past and provide a round of feedback to our many users and peers. We fought and won several hundred battles with various distributed denial of service and social engineering attacks against us and our clients, expanding the Deflect offerings of open source mitigation solutions to also include website hosting and attack analytics. However, several important missteps were taken to arrive here and this post will concentrate on lessons learned and the way forward in our battle to reduce to prevalence of DDOS as an all too common technique to silence online voices.

Our reflections and this post were motivated by an external evaluation report of the Distributed Deflect service, which you can read in this PDF. The project itself was a technical long shot and an ambitious community building exercise. Lessons learned from this endeavor are summarized within. Its about a 10 minute read :)

During peak times on Deflect throughout 2012-2016 we were serving an average of 3 million unique daily readers and battling with simultaneous DDoS attacks against several clients. The network served websites continuously for the entire 3 1/4 years of project duration, recording less than 30 minutes of down time in total. The project had direct impact on over four hundred independent media, human rights and democracy building organizations.

final_report_graphWhat we did

eQualit.ie released 10 open source libraries, toolkits and frameworks including tools for network management and DDoS mitigation; a WordPress managed hosting framework; classification and analysis of malicious network behaviour; the Bundler library for website encryption and delivery across an untrusted network, which was also reused in the Censorship.NO project for circumventing Internet filtering infrastructure.

Over three hundred and fifty websites passed through the Deflect protection service. These websites ranged in size and popularity, receiving anything between a dozen daily readers to over a million. Our open door policy meant that websites who had changed their mind about Deflect protection were free to leave and unhindered in any way from doing so. Over the course of the project, we have mitigated over four hundred DDoS attacks and served approximately 1% of Internet users each calendar year (according to our records correlated against Internet World Statistics). Our work also appeared in topical and mainstream media.

Aside from the DDoS protection service, we trained numerous website administrators in web security principles, worked with several small and medium ISPs to set up their own Deflect infrastructure and enabled Internet presence for key organizations and movements involved in national and international events, including the ’13 election in Iran, ’14 elections in Ukraine, Iguala mass kidnapping, Panama papers, and Black Lives Matter among others.

Distributed Deflect

As attacks grew in size, we debated the long-term existence of the project, deciding to prototype an in-kind DDoS mitigation service, whereby websites receiving free protection and any volunteers could join and expand the mitigation network’s size and scope. We wanted to create a service run by the people it protected. The hypothesis envisioned the world’s first participatory botnet infrastructure, whereby the network would be sustained with around a hundred servers run by the Deflect project and several thousand volunteer nodes. Our past experience showed that the best way to mitigate a botnet attack was with a distributed solution, utilizing the design of the Internet to nullify an attack that any single end point/s could not handle by itself. Distributed Deflect brought together people of various background and competencies, blending software development and technical service provision, customer support and outreach, documentation and communications. We designed, prototyped and brought into production core components of a distributed volunteer infrastructure, only to realize that the hypothesis behind our proposal could not scale if we were to maintain the privacy and security of all participants in our network.

ddeflect

An infrastructure that would accept voluntary (untrusted) network resources had to introduce checks for content accuracy and confidentiality, otherwise a malicious node could not only see who was doing what on the Deflect network but delete or change content as it passed through their machine. Our solution was to encrypt web pages as they left the origin server and deliver them to readers as an encrypted bundle, with an additional authentication snippet being sent by another node for verification. Volunteer nodes would only be caching encrypted information and would not be able to replace it with alternative content.

bundler

All necessary infrastructure design and software tools to implement this model were built to specification. However, once ready for production and undergoing testing, we realized the error in hypothesis made at the onset. Encrypted bundles grew in size, as all page fonts and various third-party libraries – that make up the majority of web pages today and are usually stored in the browser’s cache – had to be included in each bundle.

This increased network latency and could not scale during a DDoS attack. We were worsening the performance of our infrastructure instead of improving it. Another important factor driving our deliberation was the low cost of server infrastructure. By renting our machines with commercial providers, and using their competitive pricing to our advantage, we have managed to maintain infrastructure costs below 5% of our overall monthly expenditure. Monetary support for a worldwide infrastructure of Deflect servers was not significant when compared with the resources required to service the network. By concentrating development efforts on encrypting and delivering website content from our distributed cache and performance load balancing on a voluntary node infrastructure, we held back work on improving network management and task automation. This meant that the level of entry to providing technical support for the network was set quite high and excluded the participation of technically minded volunteers protected by Deflect.

ddeflect-headers-response

After several months of further testing, deliberation and consultation with our funders, we decided to abandon the initiative to include voluntary network resources, in favour of continuing the existing mitigation platform and improving its services for clients. As attack mitigation became routine and Deflect successfully defended its clients from relentless DDoS offensives, the team began to look at the impunity currently enjoyed by those launching the attacks. Beginning with a case of a Vietnamese independent media website targeted by bots originating from a state-regulated and controlled Vietnamese ISP, we understood that a story could be extracted from the forensic trail of an attack, that may contain evidence of motivation, method and provenance. If this story could be told, it would give huge advocacy power to the target and begin to peel away at the anonymity enjoyed by its organizers. The cost for attacking Deflectees would raise as exposure and media attention around the event upended the attackers’ goals.

We began to develop an infrastructure that would capture a statistically relevant segment of an attack. Data analysis was achieved through machine-led technology for profiling and classifying malicious actors on our network, visualization tools for human-led investigation and cooperation with peer organizations for tracing activity in our respective networks. This effort became Deflect Labs and in its first twelve months we published three detailed reports covering a series of incidents targeting websites protected by Deflect, exposing their methodology and profiling their networks. Doing some open source intelligence and in collaboration with website staff, we identified a story in each attack exposing possible motivations and identity of the attackers. Following publication and media attention created by these reports, attacks against one of the websites reduced significantly and ceased altogether for the other one.

Bot behavior follows a certain pattern inside the seven dimensional space create by Bothound analytics

Bot behavior follows a certain pattern inside the seven dimensional space create by Bothound analytics

Challenges

Many difficulties and problems could be expected with running a high-impact, 24/7 security service for several million daily readers. Fatigue, lack of time for developing new features, round-the-clock emergency coverage and numerous instances of high-stress situations led to burnout and staff turnover. The resources invested in the Distributed Deflect model set back development considerably for other project ambitions.
At around the same time as Deflect was gaining popularity, free mitigation offerings from Cloudflare and Google were introduced in tandem with outreach campaigns targeting independent media and human rights organizations. This led to more options for civil society organizations seeking website protection but made it harder for us to attract the expected number of websites. We started a campaign to define differences in our distinctive approaches to client eligibility, respect for their privacy and clear terms of service, trying a variety of communications and outreach strategies. We were disappointed nonetheless to not have received more support from within our community of peers, as open source solutions and data ownership did not figure highly as criteria for NGOs and media when selecting mitigation options.

… we carry on

Deflect continues to operate and innovate, gradually growing and solidifying. Our ongoing ambitions include offering our clients broader hosting options and coming up with standards and systems for responsible data sharing among like-minded ISPs and mitigation providers. Look out for pleasant graphic user interfaces in our control panels and documentation platforms. We are also prototyping several different approaches to generating revenue in order to sustain the project for the foreseeable future. The goal is to get better without losing track of what we came here to do in the first place. As always, we are here to support our clients’ mission and their right to free expression. We are heartened by their feedback and testimonials.

Deflect Labs report #3

Botnet attack analysis of Deflect protected website blacklivesmatter.com

Seamus Tuohy and eQualit.ie

View the report with 3D rendering (5mb)

This report covers attacks between April 29th and October 15th, 2016. Over this seven-month period, we recorded more than a hundred separate denial-of-service incidents against the official Black Lives Matter website. Our analysis shows a variety of technical methods used in attempts to bring down this website and the characterization of these attacks point to a “mob” mentality of malicious actors jumping on board in response to callouts made on social media and covert channels. Our reporting highlights the usage of no-questions-asked-hosting and booter services used by malicious actors to carry out these attacks. We describe the ever growing trend of Internet vandals who, searching for a little bit of infamy, launch denial-of-service attacks against the Black Lives Matter (BLM) website. Our analysis documented attacks that could be accomplished for as little as $1 and, with access to public documentation and malicious software within easy reach, only required basic technical skill. Some of the larger attacks against BLM generated millions of connections without relying on huge infrastructure. Instead, traffic was “reflected” from legitimate WordPress and Joomla sites. We compare public attribution for some of the attacks with the data coming through our networks, and present the involvement of purported members of the Ghost Squad Hackers crew in these events.

Contents:

Introduction

“Black Lives Matter, a May First/People Link member that is supported by the Design Action Collective, is a central organization in the response movement against police abuse, brutality and misconduct.” The BLM website has been protected by Deflect since April 15th, 2016, following a spate of DDoS and hacking attacks.

In early July we published a prima facie bulletin expecting to write a comprehensive report of the attacks soon after. Since then the BLM website faced an increasing number of sizable attacks that we decided to include in our analysis and delayed publication. This report will explore these attacks, correlating open source research and publicly stated attribution with what we saw in the data.

The Deflect Labs infrastructure allows us to capture, process and profile each attack, analyzing unique incidents and intersecting findings with a database of profiled botnets. We define the parameters for anomalous behavior on the network and then group (“cluster”) malicious IPs into botnets using unsupervised machine learning algorithms.

 

Attacks & attribution

As a DDoS mitigation solution for blacklivesmatter.com, Deflect has access to all legitimate and malicious requests made to this website. However in almost all cases, attacks come via infected machines or as reflection attacks from unsuspecting websites. A semi-experienced attacker knows how to obfuscate and disguise their traces on the Internet. It is therefore incredibly difficult to attribute an action to a particular person or IP address with confidence. We rely on our analytic tooling, peers in the mitigation industry and social media research to test our hypotheses. Assumptions arising out of OSINT are then verified against the data on our systems and vice versa.

Technical analysis and social media research indicated that actions against the BLM website were launched by multiple attackers frequently acting in concert. Some methods, like Joomla & WordPress reflection attacks, appear to have been coordinated, whilst in other cases it was clear that many actors jumped on the bandwagon of a more powerful attack to claim some of the credit. These small, loosely organized mobs appear minutes to hours after the start of the original attack and lob a hodge-podge of various attack methods, often to no effect. These actions are often accompanied by a flurry of queries from various website downtime monitoring solutions, as attackers try to collect trophies for their participation in the mob. Furthermore, we noticed a sophisticated actor who was able to generate malicious traffic on a level beyond anyone else that we documented targeting BLM. Using bulletproof hosting to coordinate their attacks, they did not go to great lengths to obfuscate their identity, creating instead a complicated web of social media accounts, possibly fake public attribution claims, and general intrigue about their motivations and purpose.

The ‘Ghost Squad’

The first, and only, publicly attributed attacks began in late April, as _s1ege, a professed member of the Ghost Squad Hackers crew, began tweeting screenshots showing site defacement and reports from website up-time checkers that the BLM site was no longer reachable. The action was part of #OPAllLivesMatter, likely in response to the #AllLivesMatter slogan (and then hashtag) created in 2015. On May 2nd, 2016, a YouTube video uploaded by @anonymous_exposes_racism contained a warning from a group identifying themselves as Anonymous to leaders of the Black Lives Matter movement, asking them to also denounce anti-white racism.

This first set of attacks against BLM, beginning on April 29th, lasted a mere 30 minutes. They came from six IP addresses and generated a little under 15,000 connections. A single method of attack and very few resources were brought into play, making this small action only temporarily effective at best. That evening five different IP addresses conducted another attack against the BLM website that topped off at over 158,000 connections over a period of an hour.

Timelion expression tracking malicious connections, by attack method, on April 29th

During this attack @_s1ege posted Twitter comments taking credit. Alongside photos that showed the Black Lives Matter website had been temporarily taken down by this attack, _s1ege posted a photo of the software he was using, “BlackHorizon”.

Timelion expression tracking malicious connections, by attack method, on April 29th

During this attack @_s1ege posted Twitter comments taking credit. Alongside photos that showed the Black Lives Matter website had been temporarily taken down by this attack, _s1ege posted a photo of the software he was using, “BlackHorizon”.

BlackHorizon is a clone of a piece of HTTP DoS software called GoldenEye, which was written by Jan Seidl in 2014. It was itself an expansion on the 2012 HULK project by Barry Shteiman. Unlike Seidl’s thoughtful adaptation and expansion of HULK, the BlackHorizon codebase mainly changes the ASCII art and the author’s name. When examined, it was clear that the functional components of the code were almost entirely unaltered from GoldenEye.

Several media publications rushed to interview _s1ege, with the @ghostsquadhack Twitter and GhostSquadHackers Facebook account referencing these publications. Around 30 minutes after the second attack Waqas Amir published an article on HackRead describing both incidents alongside his conversation with a GSH member. Later that evening one member of the GSH came back reusing an earlier bot and creating an attack that generated well under 700 connections, before giving up after less than 20 minutes.

Shortly after the tweets and HackRead publication, we witnessed an increase in attack frequency and variety. Only a portion of these had a similar behavioral profile on the network to those attributed by _s1ege to GSH. The attackers were using well-known software and may have called out to others on the Internet to follow suit. On May 10th, @_s1ege announces @bannedoffline as a new member in the Ghost Squad crew and two days later stops tweeting from this account altogether.

Maskirovka

BLM began to face larger scale attacks on May 9th. The first one lasted a little over 90 minutes and consisted of 1,022,981 connections from legitimate WordPress websites. This was not the first WordPress pingback attack against the BLM website, but it was an indication that we were beginning to face adversaries prepared to deploy much greater resources than before.The level of severity and aggression continued to mount and on July 9th we witnessed a WordPress pingback attack that generated over 34 million connections to BLM in a single day. The attackers did not seem to be interested in obfuscating their provenance, allowing us to track these activities over the next few months. The attacks were coordinated from machines hosted at a “bulletproof” provider – so called because they offer servers for rent on a no-questions-asked basis. The incidents associated with these attacks were the largest faced by BLM during the reporting period.

On July 25th we received a subscription for Deflect protection from a “John Smith” asking us to enlist http://ghostsquadhackers.org. We traced this request and further conversation with this user to @bannedoffline on Twitter and Facebook, as well as the owner of the following domains: ghostantiddos.com; ghostsquadsecurity.com; bannedoffline.xyz; www.btcsetmefree.org, among others.

Our analysis of actions run from the “bulletproof” hosting provider identified several IP addresses that were used for command and control. These addresses were correlated by a peer mitigation provider who had dared @bannedoffline on a hackers forum to DDoS them and recorded the resulting activity. Two IP addresses, one belonging to the DMZhosting provider mentioned further on in this report and a Digital Ocean machine, were identified in our individual records – and correlated to eight separate incidents in our study.

  • 191.96.249.80 Dmzhost Limited https://dmzhost.co
  • 178.62.152.134 DigitalOcean https://www.digitalocean.com

It is hard to say with any certainty why there were no more public attributions for attacks on BLM after the first week of May, considering that the severity and sophistication increased several-fold. @bannedoffline deleted all of their social media postings in late September, just before we recorded the biggest attack against the BLM website. bannedoffline was also linked to a 665gbps attack (the largest attack of its time, before the Mirai botnets) against the Krebs on Security website. The Ghost Squad did not attribute or deny @bannedoffline’s continued participation in their crew. Attacks attributable to bannedoffline and _s1ege, who could very well be the same person, made up less than 20% of recorded DDoS activity against BLM.

Technical Analysis Of Attacks

Incidents using a similar attack method were distinguished through an iterative process of identifying possible behavioral characteristics that distinguish one type of attack from others. First we identified combinations of behaviors and features that distinguished possible attacks from normal traffic. These profiles were then matched to existing types of attacks by looking for signatures from other reports and known codebases of these attacks to create an attack method profile. At this point secondary characteristics of the attack were examined to see if they distinguished individual attacks. This ranged from the hosting provider used for botherders, to the collection of innocent websites used as reflectors, and the methods used to check the status of the website, among others. If one or more of these characteristics overlapped for a specific set of attacks, those attacks were flagged for further investigation. Once we clustered these attacks, we looked across the entire set of attacks and attempted to reject any characteristic that could clearly differentiate that subset of attacks from similar attacks.

The most common category of attacks against the BLM website has been “application level” (layer 7) HTTP flood attacks. These bots mimic human behavior by connecting to a website and requesting a large amount of content until the server crashes for lack of resources. In this report we will only be looking at this type of attacks.

The capability of individual attackers has ranged greatly. As the BLM website faced more resourced and effective attackers, the mob became a persistent background noise.

Attack type (including variants and clones) April May June July Aug Sept Oct
WordPress pingback 5 6 4 4 5
Joomla pingback 1 6 6 4 3 3
Slow Loris 2 5 3 1
Fully Randomized NoCache Flood 6 14 11 5 7 2 4
Cache Bypass flood 1 1 2 2
Python script flood 2 2

You can view the entire attack portfolio on Google Docs


Slowloris

Aliases/Tools Slowloris, Pyloris, Torloris
Attack Type Layer 7 Denial of Service
Exploits Connection exhaustion
Obfuscation None
Attack Class Single-source
Attack Rate Low

The first attack identified against the Black Lives Matters website occurred on April 18th, just a few days after it had switched over to Deflect. A single address made between 5 and 30 connections per second to the main BLM web page. This lasted for 28 seconds. In total it made only 168 connections. Usually, this type of behavior would not raise any flags. But in this case, the user agent of this client matched the user agent used in the original proof of concept code for “Slowloris – the low bandwidth, yet greedy and poisonous HTTP client!”

Slowloris is a DoS tool that was originally released in 2009. It is unique among the other Layer 7 attacks we will be discussing in this report because it does not focus on flooding the network with traffic. Instead, it attempts to use up all the connections to a web server leaving none left for legitimate users. This low number of connections allows Slowloris to attack a website without drawing the same attention that a flood of traffic would. There have been 12 identified attacks using the original Slowloris codebase since the BLM website has been protected by Deflect. All but one of these attacks were under 1000 connections. The largest Slowloris attack occurred on July 10th from 0:50 to 3:20 and from 6:00 to 7:20, making over 40,542 connections and clearly misusing this tool or not understanding its original purpose.

In the initial code release Slowloris used a single user agent. Today, many of the custom versions of Slowloris have changed the user agent [pyloris.py] or added source client obfuscation by randomly picking from a list of user agents [slowloris.py]. It is not surprising to see someone using an unmodified version of such an arcane tool even when the server used on the BLM website is protected against that attack. Many of the actors conducting DoS attacks are not building upon existing tools. While Slowloris was elegant at the time, the DoS space is dominated by attackers using simplistic measures. This is because one does not need a highly complex tool to take down most sites on the Internet.

Slowloris attacks on the BLM website have a tendency to overlap with or occur around the time of two low-skill “basic HTTP flood” attacks: [Blank] and [Python], as well as (Blank+WordPress) WordPress attacks.

HTTP Floods

HTTP floods are easy to implement and hard to identify attacks. Generally, they attempt to exhaust a system’s application resources or the network bandwidth. They do this by either creating a large amount of connections to the website or by continuously downloading a large amount of files. Because they only require an attacker to create many legitimate connections to a server, HTTP floods are quite easy to implement. Since these connections are legitimate, it can be very difficult for a defender to differentiate these connections from those of real users.

Simple HTTP Flood

Aliases/Tools None
Attack Type Layer 7 Denial of Service
Exploits None
Obfuscation None
Attack Class Single-source
Attack Rate Low

A simple example of this type of attack can be seen on April 30th. For just under ten minutes one lone address conducted a low sophistication HTTP GET request attack against the Black Lives Matter website. Over a five-minute period this attacker made 1503 connections from a single address using an Internet Explorer user agent. The BLM website only received a few of these connections as the attacker was banned within a second.

 


Basic Python

Aliases/Tools None
Attack Type Layer 7 Denial of Service
Exploits None
Obfuscation None
Attack Class Single-source
Attack Rate Low

Just a few hours after the previous HTTP Flood concluded, two different attacks started and subsided. They missed each other by just two minutes. The first was a “Fully Randomized NoCache Flood” and connected 2,000 times in its two minutes of attack. The second was a test run of an even simpler HTTP Flood attack than the previous example. The code behind this attack was written without any attempt to make it look like a legitimate user. Over the six minute attack, this script made around 400 connections. There were also 23 connection from a Chrome browser at the same IP address during this period, as the attacker frantically refreshed the web page to check on their impact. As in the previous attack, it took under a second for this IP address to be banned.

While a DoS attack does not need much sophistication to be effective, we mention it here because its unique signature shows that this attack was written by an inexperienced programmer. To explain how basic this attack is, the Deflect Labs researchers have recreated a working version of it below.

import urllib
while True:
   urllib.urlopen("http://www.blacklivesmatter.com")

This attacker came back again after a few hours using a different address. As in many single-source attacks, they were likely using a proxy to disguise the original IP of their attacks as they conducted these test runs. Before running the python script, they ran the same “Fully Randomized NoCache Flood” attack for about a minute and then quickly switched back to their python script. The python script made another 429 connections during the approximately six minute long attack. It was, like before, stopped within seconds.

This testing behavior continued over the next few days. With another small attack on the morning of May 1st that made up to 700 connections in just under 10 minutes and one with just over 1000 connections in just under 20 minutes. By the end of that week this attacker had concluded their experiment in attempting to build their own script. Its simple nature made it automatically blocked almost as soon as it connected. At its peak, it could only create a hundred or so connections per minute, which is far too little for a machine conducting a DoS attack.

HTTP Flood DDoS

Aliases/Tools None
Attack Type Layer 7 Denial of Service
Exploits None
Obfuscation None
Attack Class Multi-Source
Attack Rate High

The HTTP floods we have described so far in this section have only come from a single source. In this section we will explore how a botnet can leverage thousands of machines to conduct a distributed HTTP Flood and how we can identify these floods among regular traffic.

HTTP floods that involve many sources (DDoS attacks) are difficult to identify because they can look very similar to regular traffic. But because the BLM website, like every other, has traffic patterns that show the general behavior of their usual readership, there are some clear examples of DDoS HTTP Floods that we can explore.

Unsurprisingly, people in the US visit the BLM website far more often than other groups. This also impacts traffic patterns to the site. Traffic to the BLM website follows a daily cyclical pattern. There is a peak in its traffic between 12:00 and 14:00 EST. (The numbers in our screenshots reflect UTC+0 timestamps.) After that, the traffic slows until around 07:00 EST, when it spikes for the evening and then slows for the night.

Between August 5th and August 9th the hourly pattern changed from a smooth usage pattern like the above into this.

That week between 11:00 and 13:00 EST there was a surge of traffic from China, Indonesia, Turkey, and Slovenia. While the Deflect Labs team is not surprised that BLM receives international attention, it is a bit odd to see it occurring during the same period worldwide. When looking for HTTP Floods that have multiple sources, knowing these usage patterns can make it far easier to identify possible attacks like this one.

The anomaly we can see above was an HTTP POST Flood attack on August 8th. Based upon the dozens of countries per minute that are seen making higher than average connections, it seems plausible that this attack was using a botnet of infected machines.

Over a period of just over an hour, 11,514 machines attempted to upload (POST) a series of large files to the BLM website. This created a flood of large content-length requests that the BLM website had to process.

 



Fully Randomized NoCache Flood

Aliases/Tools Hulk, GoldenEye, BlackHorizon
Attack Type Layer 7 Denial of Service
Exploits KeepAlive, NoCache
Obfuscation Source Client Obfuscation, Reference Forgery
Attack Class Multi-Source
Attack Rate High

Websites that are protected by DDoS mitigation services – such as Deflect – use a “caching” system to store commonly requested pages and provide them to users so the protected website’s server does not have to. This “cache” of recently requested web pages allows Deflect to further limit the requests made to the protected server. Even if simple bots, like those in the last section, evade blocking, they often are just receiving responses from Deflect’s caches of recently requested URLs and not impacting the origin server at all.

DoS providers responded to the use of caching by creating a bot that tricks the cache into thinking that they are requesting a page that was never requested before. These “Cache-bypass” HTTP Floods are bots that add a randomized query at the end of their requests. These randomly generated queries cause a cache to view each request as a new request, even though the bots we are examining in this report only ever requested the main BLM URL “blacklivesmatter.com”.

GoldenEye is a Layer 7 DoS tool. It allows a single computer to open up multiple connections to a website, each of which pretends to be a different device. To do this, GoldenEye provides a different user agent string for each connection. Over the combined hour and a half of attacks, these 11 bots pretended to be hundreds of different types of users to avoid detection.

 

Later in the evening of April 30th another attack consisting of just under 11,000 connections was attempted. This attack used an improved “Fully Randomized NoCache Flood.” While the attack starts with 9 bots using something similar to the code used by GSH, a single address joins a minute into the attack and quickly dwarfs the other attackers in both number of connections and variety of user agents that it employs.

If it were not for the variety of intensity and method used by the individual addresses, attacks like this would look like they involved a single actor. But as is common for attacks against the BLM website, this attack starts slowly with one or two initial actors, who are then joined by a small mob of “bandwagon bullies.” As was seen in the early GSH attacks, they share the tools used in their attacks with the other attackers. Whoever this late attacker is, they are clearly not just another member of the team. This attacker has considerably different network resources and likely software that allows them to have far more impact than all the participating GSH team members.

Reflection DDoS

Joomla! Reflection DDoS

Aliases/Tools DAVOSET, UFONet
Attack Type Layer 7 Denial of Service
Exploits None
Obfuscation None
Attack Class Reflected
Attack Rate High

In 2013 a series of vulnerabilities were discovered in a Google Maps plugin for the Joomla! CMS. One of them made it possible for anyone to request a Joomla! site to make an HTTP request to remote websites. By June 2013 this vulnerability had already been weaponized and included in an existing DDoS framework called DAVOSET (DDoS attacks via other sites execution tool). In 2014 this same vulnerability was included in the UFOnet DDoS framework.

Each of these DDoS frameworks have easy-to-use web-based point-and-click interfaces and a built-in list of vulnerable Joomla! websites. This makes them ideal for a low-resourced or unsophisticated attacker looking to amplify another attack. Of the 23 WordPress attacks made against the BLM website, only 7 of them were not paired with a Joomla! attack.

Initially, it was difficult to identify Joomla! attacks because most of the connections do not provide a user agent string. Empty user agents are somewhat common on the Internet. Many non-malicious, but quickly made, bots do not provide a user agent. As such, when we initially saw these spikes of traffic, we assumed that they were from another sloppily made DoS bot.

After we saw this bot accompanying attacks from a variety of different attackers, we investigated further and noticed a fingerprint hidden in the traffic that led us to the Joomla! attack. Although most of the user agents used by Joomla! sites to make these requests are blank, a small subset of these machines include the version of PHP language that was used to run the request. While blank user agents are somewhat common, many of the attacks that included them were combined with user agents that contained PHP versions. Given the relative rarity of PHP, we realized that the odd increase in empty user agents alongside other attacks was because they were being combined with Joomla! attacks.

 


Introduction to WordPress XMLRPC Floods

Aliases/Tools WordPress Pingback
Attack Type Layer 7 Denial of Service
Exploits NoCache
Obfuscation Spoofing
Attack Class Reflected
Attack Rate High

By default, WordPress has a “pingback” feature that was built to allow WordPress sites to alert other blogs when they linked to their content. On a high level, this works similarly to a mention in Twitter. When a WordPress site publishes a post that links to another website, it sends out a “pingback” to that site with a link to the post containing the original link. If the receiving site is also based on WordPress, it responds to the original site to confirm that it received the pingback.

Pingbacks have been a part of WordPress sites since Version 1.5, which came out in 2005. It wasn’t until 2012 that Christian Mehlmauer released a working implementation of code that took advantage of this feature to ask WordPress sites to verify “pingbacks” from spoofed URLs. Two years later, in March 2014, Akamai released a post that described a “pingback” attack consisting in over 162,000 WordPress sites. In September 2015 they announced that WordPress pingback attacks made up 13% of all Layer 7 attacks they faced.

At 22:00 on May 1st a WordPress pingback attack began targeting the Black Lives Matter website. In just 13 minutes it made 181,301 connections. As this WordPress attack subsided, a Joomla! attack took its place. The moment the WordPress attack started, the second attacker began to use free online services dozens of times a minute to check if the Black Lives Matter website had gone down. As the second attack began, the attacker increased the frequency at which they monitored the state of the website. Four minutes into the attack, when it had obviously succeeded, the attacker stopped checking the site. Altogether, this attack consisted of around 350,000 connections in a period of less than an hour.

 

As was mentioned in the original bulletin, the most intense attacks against the Black Lives Matter website have been WordPress pingback attacks. The first large-scale attack against the BLM website was a WordPress attack on May 9th. This attack made over 1,130,000 connections in just under three hours. It was a mix of over 1,000,000 connections from a WordPress pingback attack alongside 100,000 connections from a “Fully Randomized NoCache Flood.”

 

The following WordPress sections will provide some illustrative examples to show how we explored the relationships between these bots. But we will not examine every attack. Nor will we try to attribute attacks to their source.

WordPress pingback & Botherder Addresses

While WordPress attacks work similarly to Joomla! attacks they are far easier to identify. These attacks clearly list their WordPress version as their user agent. Because these attacks started to become more widespread, a new feature was released in version 3.9 of WordPress. This version updated pingbacks to include the IP address that made the original pingback request.

WordPress/4.6; http://host.site.tld; verifying pingback from 127.0.0.1

We call these IP addresses “botherder” addresses. Some of these addresses correspond to globally addressable IP addresses that one can reach over the Internet. Others are addresses that should never appear on the public Internet. These bogon addresses are private/reserved addresses and netblocks that have not been assigned to a regional Internet registry. The bogon address seen in the example above is called localhost. It’s the IP address used by a computer to refer to itself.

While adding the address of the botherder was implemented to de-anonymize the true source of an attack, most attackers are very adept at concealing their true IP address through the use of spoofed packets, proxies, virtual private servers (VPSs), and the use of compromised machines to conduct the original requests. When we started looking into the botherder addresses, we assumed that we would only find spoofed addresses. To our surprise, the botherder addresses exposed far more than we expected them to. By clustering the botherder IPs exposed in an attack, we were able to develop behavioral profiles that helped us link different attacks together to understand which attacks were likely conducted by the same attacker.

The first thing we looked at were the botherder IPs used in WordPress attacks against the BLM website. Our exploration of bogon addresses showed clear relationships between the attacks that could be exposed by looking at the botherder addresses.

The large blue ball of shared IP addresses on the left side of the bogon graph above surrounds two small incidents that occurred on August 8th and 9th. This massive ball of shared IP addresses consists of over 500 addresses from the private IP address spaces. Specifically, they include 382 addresses from the 172.16.0.0/12 address range and 177 addresses from the 10.0.0.0/8 address range. Private address ranges are not entirely uncommon for WordPress pingback attacks. They can appear when the botherder is on the same hosting provider as the WordPress sites they are exploiting and can also be created when a botherder is spoofing random addresses. What is unusual is how clearly the overlapping bogon IP addresses link these two attacks.

There were also globally addressable botherder IP addresses that linked each of the individual attacks against BLM together. It is likely that areas of sparse overlapping IPs exist because many botherders were clearly spoofing IP addresses. But the areas with many connections showed relationships that were worth exploring.

One commonality between all the attacks was that while every attack has hundreds of spoofed botherder addresses that appear only once or twice, there are also a small number of botherder addresses that account for a majority of the bots herded for the attack. In the August 8th and 9th attacks, which can be seen at the bottom of the globally addressable IP graph, three IP addresses accounted for 95% (13,963 / 14,585) of the WordPress connections that identified a botherder.

Because Deflect’s primary purpose is DDoS mitigation, Deflect Labs’ investigations often happen days or weeks after the fact. This means that we often have to rely on our logs and open source intelligence. In this case one of the first things we looked at was who owned the three primary botherder IP addresses. These IP addresses belong to Digital Ocean, a VPS provider based in New York. Digital Ocean does not provide multiple IP addresses per machine, and so we know that this attack was herded by three separate Digital Ocean “droplets.” Hourly pricing for Digital Ocean droplets runs between $0.007 USD/hour and $0.119 USD/hour. With each of these attacks lasting under half an hour, the cost to run this attack was well below a single dollar.

 


“Bulletproof” Hosting

By far the largest cluster of associated WordPress attacks occurred between July and October. This set of attacks includes the five largest attacks over that four-month period.

Among the 206 globally addressable IPs used by those attacks, 5 botherder IP addresses make up 65% (41,030 / 62,488) of the botherder IPs identified in the attack. Each of these botherders were hosted on an “offshore” hosting provider called DMZHOST. The two most connected botherder IPs in our attacks are mentioned countless times on a variety of IP address reputation websites, forums, and even blog posts as the source of a variety of similar attacks.

“Bulletproof hosting” providers like DMZHOST provide VPSs that advertise themselves as outside of the reach of Western law enforcement. DMZHOST offers its clients “offshore” VPSs in a “Secured Netherland datacenter privacy bunker” and “does not store any information / Log about user activity.” At the same time, DMZHOST’s terms of service are just as concise. “DMZHOST does not allow anything (related) to the following content: – DDos – Childporn – Bank Exploit – Terrorism – NO NTP – NO Email SPAM”.

Conclusion

Silencing online voices is becoming ever easier and cheaper on the Internet. The biggest attacks presented in this report did not require expensive infrastructure, they were simply reflected from other websites to magnify their strength. We are beginning to see authorities pursue and shut down “bulletproof” hosting and booter services that enable a lot of these attacks, yet more needs to be done. In the coming age of IoT botnets, when we begin to witness attacks that can generate over a terabyte of traffic per second, the mitigation community should not guard their intelligence on malicious activity but share it, responsibly and efficiently. Deflect Labs is a small project laying the groundwork for open source community-driven intelligence on botnet classification and exposure. We encourage you to get in touch if you would like to contribute.


 

Deflect is a website security project working with independent media, human rights organizations and activists. It offers DDoS mitigation, secure hosting and attack analytics, free of charge to qualifying organizations. All of our tools are open source and we operate according to strict terms of service and principles promoting the privacy of our clients. Deflect is a project of eQualit.ie, a Canadian not-for-profit organization working to promote and defend human rights in the digital age.

TA3M, December 19th – the Cryptmas edition

Our techno activism 3rd Mondays events are back! This time with a focus on mobile security and anonymity. As recent reporting highlighted once again the dangers to personal privacy from modern day surveillance, we are offering an overview of current possibilities for improving your mobile privacy, just in time for Christmas! We will discuss:

– Surveillance on cellular and data networks
– Tools for secure and anonymous communications
– Communicating without the network
– Smartphone security
– Android without Google

As usual this will be an informal presentation with a lively discussion and refreshments. This is a public event but please RSVP as space will be limited.

Location: 5445 de Gaspé, suite 602

When? December 19th, 18:00-20:00

Yes, I want to come! Please RSVP below…

  • TA3M Montreal - Dec '19




To see a history of past TA3M Montreal events please refer to our archive.

Deflect Labs Report #2

Botnet attack analysis of Deflect protected website bdsmovement.net

This report covers attacks between February 1st and March 31st of six discovered incidents targeting the bdsmovement.net website, including methods of attack, identified botnets and their characteristics. It provides detailed technical information and analysis of trends with the introduction of the Bothound library for attack fingerprinting and botnet classification. We cluster malicious behaviour on the Deflect network to identify individual botnets and employ intersection analysis of their activity throughout the documented incidents and further afield. Our research includes discovered patterns in the selection of targets by the actors controlling these attacks.

Deflect is a website security project working with independent media, human rights organizations and activists. It offers DDoS mitigation, secure hosting and attack analytics, free of charge to qualifying organizations. All of our tools are open source and we operate according to principles promoting the privacy of our clients. Deflect is a project of eQualit.ie, a Canadian not-for-profit organization working to promote and defend human rights in the digital age.

Navigation links: Attack Profile; Botnet profile; Botnet target selection; Botnet behaviour comparison; In-depth incident analysis; Report conclusions

General Info

The Boycott, Divestment and Sanctions Movement (BDS Movement, bdsmovement.net) is a Palestinian global campaign, initiated in 2005. The BDS movement aims to nonviolently pressure Israel to comply with international law and to end international complicity with Israel’s violations of international law. Their website has been protected by Deflect since late 2014 and has frequently been attacked.

Graph 1. Timelion graph showing the average hits per day in the period of February 1 to March 31 (in red) and the moving average + 3 standard deviation (in blue).

Graph 1. Timelion graph showing the average hits per day in the period of February 1st to March 31st (in red) and the moving average + 3 standard deviation (in blue).

Attack Profile

During February and March of 2016, there were 6 recorded incidents against the target website. The Deflect Labs infrastructure allows us to capture, process and profile each attack, analysing unique incidents and intersecting findings with a database of profiled botnets. We define the parameters for anomalous behaviour on the network and then group (“cluster”) malicious IPs into botnets using unsupervised machine learning algorithms.

Graph 2. Total hits to the website, by country of origin. The spikes represent attacks investigated in this report

Graph 2. Total hits to the website, by country of origin. The spikes represent attacks investigated in this report

Graph 3. Prevalence of WordPress pingback attacks during the six incidents

Graph 3. Incidents where the WordPress pingback attack is used against the target site

We define each incident by wrapping it inside a given time frame, record the total number of hits that reached the website during this time and use our analytic tool set to separate malicious requests made by bots from genuine everyday traffic.

Table 1. Attacks Summary, including start/end date, duration, size of the incident, size and number of the botnets detected

id Incident Start Incident Stop Duration Total hits Unique IPs No. of bots identified Identified botnets
29 2016-02-10 21:00 2016-02-11 01:00 ~5hrs 879,634 14,773 12,921 3
30 2016-02-11 10:30 2016-02-11 12:30 ~2hrs 321,203 11,108 9,023 3
31 2016-03-01 15:00 2016-03-01 19:30 ~6h30 3,597,689 5,918 3,243 3
32 2016-03-02 12:30 2016-03-02 16:00 ~3h30 13,559,169 19,851 2,748 2
33 2016-03-04 09:00 2016-03-04 09:30 ~30min 2,058,710 9,613 8,844 1
34 2016-03-08 14:20 2016-03-08 16:40 ~2h20 5,017,045 7,937 7,151 1

The number of unique bots and their grouping into specific botnets is the result of clustering work by BotHound. This toolkit classifies IPs by their behaviour, and allows us to determine the presence of different botnets in the same incident (attack).

Botnet profile

Using BotHound, we have calculated the percentage of unique IPs (classified as bots) that recur in separate incidents. A substantial percentage of previously seen bots would be one way to identify whether a botnet was re-used for attacking the same target. It would reveal a trend in botnet command and control behaviour. This intersection of botnet IPs also creates an opportunity to compare activity between several target websites, whether protected by Deflect or on one of our peers’ networks. Taken together, we begin to build a profile of activity for each botnet, helping us make assumptions about their motivation and target list.

Table 2. Intersection of identical bots across the incidents

Incident #

No. of identical bots
in both incidents

The portion of identical bots
(of the smallest incident)

29, 30 6,928 76.8%
31, 32 1,450 91.0%
33, 34 4,249 59.4%
32, 33 438 17.9%
Graph xx. Hits from bots, by the identified botnet, by the country of origin

Graph 4. Hits from bots and their country of origin, grouped by identified botnets. Update your software and malware cleaners please!

Table 3. Identified botnets and the incidents they appear in

Botnet ID Seen in incident Unique bots Top 10 countries of bot origin Attack method
1 29, 30 13,857 Russian Federation; Ukraine; China; Lithuania; Germany; Switzerland; Gibraltar; United Kingdom; Netherlands; France POST
2 29, 30 8,913 Russian Federation; China; Ukraine; Germany; Lithuania; United States; Switzerland; United Kingdom; France; Gibraltar POST
4 31, 32 2,589 United States; Germany; United Kingdom; Netherlands; China; Japan; Singapore; Ireland; France; Spain; Australia Pingback
5 31, 32 772 United States; United Kingdom; Germany; Netherlands; Italy; France; Russian Federation; Singapore; Canada; Japan; China Pingback
6 31 971 United States; China; Germany; Japan; United Kingdom; Singapore; Netherlands; France; Ireland; Canada; Australia Pingback
7 33, 34 11,746 United States; United Kingdom; Germany; France; Netherlands; China; Canada; Russian Federation; Ireland; Spain; Turkey Pingback

Botnet target selection

Deflect protects a large number of qualifying human rights and independent media websites the world over. Our botnet capture and analytic tool set allows us to investigate attack characteristics and patterns. We consider the presence (intersection) of over 30% of identical bots as originating from a similar botnet. During our broader analysis of the time period covered by this report, we have found that botnet #7, which targeted the bdsmovement.net website on March 3rd, also hit the website of an Israeli Human Rights organisation under our protection on April 5th and April 11th. In each incident, over 50% of the botnet IPs hitting this website were also part of botnet #7 analysed in this report. Furthermore, a peer website security organization reviewed our findings and concluded that a substantial amount of IPs belonging to this botnet were targeting another Israeli media website under its protection, on April 7th and April 12th. Organisations targeted by this botnet do not share a common editorial or are in any way associated with each other. Their primary similarities can be found in their emphasis on issues relevant to the protection of human rights in the Occupied Territories and exposing violations in the ongoing conflict. Our analysis shows that these websites may have a common adversary — the controller or renter of botnet #7 — that their individual work has aggrieved. We will present our findings on this investigation in more detail in an upcoming report.

Botnet behaviour comparison

BotHound works by classifying the behaviour of actors on the network (whether human or bot) and clustering them according to a set of pre-defined features. Malicious behaviour stands out from the everyday trend of regular traffic. On the picture below the RED spots refer to attacker sessions, while BLUE spots refer to all other (regular traffic). The graphic displays all the 6 incidents combined. We chose the following 3 dimensions to visually represent a projection from a 7-dimensional space (where BotHound clustering is calculated):

  • HTTP request depth
  • Variance of HTTP request interval
  • HTML to image ratio

Graph 5. Clustering of bot behaviour from the six incidents covered in this report. The graphic illustrates that malicious behaviour, no matter the botnet characteristics, follows a determined pattern which resembles automated machine-driven properties of a botnet attack.

In-depth incident analysis

We have captured, analysed and now profiled each botnet witnessed in the 6 incidents. We break down incidents into three groups, by similarity of attack characteristics and the time of occurrence.

Incidents #29 & #30

Date: February 10-11, 2016
Duration: approximately 28 hours
Identified botnets: 2 (botnet id: #1 #2)
IP intersection between botnets: 76%
Attack type: HTTP POST


image11

Attack analysis

After doing extensive cluster analysis to separate “good” from “bad” IPs based on their behaviour during the incident time frame, we applied a novel secondary clustering method which identified two different patterns of behaviour spanning both incidents. The first attack pattern was using bots to hit the target very fast, with similar characteristics (session length, request intervals, etc.). The second botnet was hitting slower, but more consistently. The session length was varying, likely to evade our mitigation mechanisms. However, the request interval between hits was zero, which helped us identify them. It is easy to distinguish two different botnets from the graphs below.

Identified botnet #1
Members: 13,857
Observations:

  • Session length = 314 sec
  • Payload average = 521 byte
  • Hit rate = 0.04 /minute
  • Requests: 500,000
  • Host header: accurate
  • Method: POST (> 99.9%)
  • URI path: / (> 99.9%)
  • UA: low variation, with most major UAs represented

Deflect Response: Moderate blocking success, origin was affected.


Identified botnet #2
Members: 8,913
Observations:

  • Session length = 429 sec
  • Payload average = 447 byte
  • Hit rate = 0.05 /minute
  • Requests: 600,000
  • Host header: accurate
  • Method: POST (> 99.9%)
  • URI path: / (> 99.9%)
  • UA: low variation (slightly higher than botnet 1), most major UAs represented

Deflect Response: Moderate blocking success, origin was affected.

Attacks results primarily in response code 502 (bad gateway) and 504 (gateway timeout) codes.

The botnet utilises several hundred unique IPs and a few dozen rotating user agents

The botnet attacks with several hundred unique IPs (purple) and rotates through a few dozen user agents (yellow)

The botnet attacks with several hundred unique IPs and rotates through a few dozen user agents. Graph tallies at 15 second intervals.

IP geo-reference

The IP address requesting a site can be geo-located. Another way we visualize botnet behavior is by cross-referencing the country of bot origin. We can easily see attack intensity (number of hits) versus bot distribution (unique IPs) in the diagrams below.

Graph 6. Hits against target website, by their geographic origin.

Graph 6. Hits against target website, by their geographic origin.

Graph 7. The same timespan as per the previous graph, only this time showing a count of unique IPs, per country geoIP

Graph 7. The same timespan as per the previous graph, only this time showing a count of unique IPs, per country geoIP

User agent and device

Every website request usually contains a header with identifying information about the requester. This can be faked, of course, but in any case stands out from the general pattern of traffic to the website. These incidents had a high consistency of “Generic Smartphone” and “Other” devices – describing the hardware unit from which the request was supposedly made. It is common for botnets to spoof a user agent device or, at least, share a common one.

Graph 8. Shows the devices used in the February botnet attack. As we can see, the majority comes from “Generic Smartphone” or “Other” device. Such consistency shows that these are part of an attack, rather than regular visitors.

Graph 8. Shows the devices used in the February botnet attack. As we can see, the majority comes from “Generic Smartphone” or “Other” device. Such consistency shows that these are part of an attack, rather than regular visitors.

Conclusions on incident #29 and #30 attacks
  • These attacks were distinguished by the relatively large number of participating bots, but were smaller in intensity (number of hits on target) compared to incidents #31-34. Three attacks were launched during the period of these incidents, requesting the same url ( /- ), as well as using the same “device” in the user agent of the request.
  • There were two and possibly three botnets in these incidents. They can be differentiated by the geographic location of their bots and hit rates during attack. What is interesting is that the attack method between the different botnets and attack times is the same. Also the two botnets share a high percentage of intersecting bot IPs (76.8%). This may be an indication that they are subnets of a larger malicious network and are being controlled by the same entity.

Incidents #31 & #32

Date: March 1-2, 2016
Duration: approximately 21.5 hours
Identified botnets: 3 (botnet id: #4 #5 #6 )
IP intersection between botnets: 91%
Attack type: Reflection – WordPress Pingback[1]

Attack Analysis

Attackers utilised the same botnet (91% intersection) during incidents #31 and #32 within a time range of 22 hours. Incident #32 is the biggest in terms of hits out of the entire period covered by this report – counting over 13.5 million total hits in 6 hours. These incidents have a very similar UA (device) characteristic, the majority of which are identified as “Spider” (we are making an intersectional analysis on the UA further down in this report).

Identified botnet #4

Members: 2,589
Observations:

  • Session length = 2,971 sec
  • Payload average = 8,217 byte
  • Hit rate = 1.7 /minute
  • Requests: 10.8 million
  • Host header: accurate
  • Method: GET (> 99%)
  • URI path: / (> 99%)
  • UA: high variation, all WordPress pingback

Deflect Response: Successfully blocked. 91% of responses to botnet processed by edge within 20ms

Comparison of unique IPs versus unique user agent strings at 30 second intervals

Comparison of unique IPs versus unique user agent strings at 30 second intervals

Identified botnet #5
Members: 772
Observations:

  • Session length = 3,587 sec
  • Payload average = 10,221 byte
  • Hit rate = 0.48 /minute
  • Requests: 3 million
  • Host header: accurate
  • Method: GET (> 99%)
  • URI path: / (> 99%)
  • UA: high variation, all WordPress pingback

Deflect Response: Successfully blocked. 85% of responses to botnet processed by edge within 20ms

Comparison of unique IPs versus unique user agent strings at 30 second intervals. Note the probing attack before escalation

Comparison of unique IPs versus unique user agent strings at 30 second intervals. Note the probing attack before escalation

Identified botnet #6
Members: 971
Observations:

  • Session length = 583 sec
  • Payload average = 31,317 byte
  • Hit rate = 0.49 /minute
  • Requests: 145,000
  • Host header: accurate
  • Method: GET (> 99%)
  • URI path: / (> 99%)
  • UA variation: high variation, all WordPress pingback

Deflect Response: Relatively small incident – some attackers did not trigger our early detection with around 15% getting through to origin (22,000 requests returned an HTTP 200). Successfully blocked.

Error codes showing blocked request versus those that got to the origin site in incident #31

Error codes showing blocked request versus those that got to the origin site in incident #31

User agent and device

The “UA” parameter in our logging system identifies the user agent string in the request header made to the target website. It usually represents the signature (or version) of the program used to query the website, for example “Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko” means that the request was made from Internet Explorer version 11, running on the Windows 7 operating system [2]. The “device” parameter in our logging system identifies the hardware (device) the user agent is running on, for example “iOS Device” or “Nexus 5” or “Windows 7”. In this case, the vast majority of IP addresses hitting the site were categorised as “spiders”. A spider, or web crawler, is software used by search engines to index the web. User agent strings are just text and can be changed (faked) to say anything – including copying a user agent string commonly used by some other software.

Graph 9. Hit count from various devices throughout incidents 31-32

Graph 9. Hit count from various devices throughout incidents 31-32

Graph 10. Unique IP count from various devices throughout incidents 33-34

Graph 10. Unique IP count from various devices throughout incidents 33-34

Conclusions on incident #31 and #32 attacks
  • These incidents stand out for their common attack and attacker characteristics, with an intersection of 91% of bots used in both instances (of the smaller incident). Botnet #4 and #5 behaviour differs only in their hit rate. Botnet #5 and #6 have a similar number of bots and an almost identical hit rate. Interestingly, they differ greatly in the number of hits each one of them launched at the target site. It seems that all three botnets had strong presence on computers in the United States. All botnets used the same attack method – WordPress pingback – in both incidents.
  • The similarities between bot IP addresses and the attempts to vary the attack pattern from very similar botnets indicates human lead efforts to adapt their botnet to get past Deflect defences. It appears that the botnets used in these two incidents have the same controller behind them.

Incidents #33 & #34

Date: March 4, March 8, 2016
Duration: 30 mins, 2 hours and 20 minutes
Number of bots: 8,844 and 7,151
Identified botnets: 1 (botnet id: #7)
Attack type: Reflection – WordPress Pingback[1]


Identified botnet #7
Members: 11,746
Observations:

Graph XX. Comparable values of unique IPs and unique UAs. We see a huge difference from other botnets in this report

Graph 11. Comparable values of unique IPs and unique UAs. We see a huge difference from other botnets in this report

  • Session length = 2,665 sec
  • Payload average = 15,572 byte
  • Hit rate = 0.30 /minute
  • Requests: 7.9 million
  • Host header: accurate
  • Method: GET (> 99%)
  • URI path: / (> 99%)
  • UA variation: high variation, mostly WordPress pingback (92%)

Deflect Response: Moderate blocking success. 75% of requests dealt with in <200ms, 5% origin read timeouts

Graph 10. Unique IP count from various devices throughout incidents 33-34

Graph 12. Unique IP count from various devices throughout incidents #33-34

Conclusions on incident #33 and #34 attacks
  • Incident #33 comes across as a probe (or a first attempt) before a much stronger attack with similar characteristics is launched in incident #34. This is backed up by the use of a single botnet in both incidents.
  • Botnet #7 appears in other attacks against Israeli websites, on our network and on the network of one of our peers. The attack pattern used in these incidents is similar to the previous two incidents, and we have found a 17.9% intersection between bots used in incidents #32 and #33, possibly linking #31-34 together. Along with the prevalence of bots originating from the United States, there is some justification that botnets 4-7 originate from a similar larger network.

Report conclusions

Attempts to bring down the bdsmovement.net website were made using several (at least two distinct and relatively large) botnets and varied in their technical approach. This shows a level of sophistication and commitment not generally seen on the Deflect network. The choice of attack method allowed us to see which website was being targeted, which may have been a conscious decision. However, we did not find anything linking attacks in incidents #29-30 with attacks in incidents #31-34. Relative success with affecting the origin in the first two incidents was not built upon in the next four. Furthermore, other effective methods to swarm the network with traffic or overwhelm our defence mechanisms could have been used, had the attackers had enough resources and dedication to achieve their aims.

The creation of historical profiles for botnet activity and the ability to intersect our results with peer organizations will lead to better understanding of trends, across a greater swath of the Internet. Adapting botnet classification tooling to automated defense mechanisms will allow us to notify peers about established and confirmed botnets in advance of an attack. By slowly chipping away at the impunity of botnet controllers, we hope to reduce the prevalence of DDoS attacks as a method for suppressing online voices.

eQualit.ie is inviting organizations interested in this collaboration to reach out.

 



[1] A WordPress pingback attack uses a legitimate function within WordPress, notifying other websites that you are linking to them, in the hope for reciprocity. It calls the XML-RPC function to send a pingback request. The attacker chooses a range of WordPress sites and sends them a pingback request, spoofing the origin as the target website. This feature is enabled by default on WordPress installations and many people run their websites unaware of the fact that their server is being used to reflect a DDoS attack.
[2] http://www.useragentstring.com/index.php

Deflect Stats April 2016

April 2016 was noticeable for the amount of attacks launched against Deflect protected websites. Most of them were using the WordPress Pingback reflective attack method. Ukrainian readers topped our statistics this month, with readers from the United States, Ecuador and Russia also generating several million daily hits.

april-16-stats

 

Daily hits on the Deflect network, by country

Daily hits on the Deflect network, by country

 

april-16-bandwidth-country

Bandwidth, measured hourly and summed by country of requesting IP

 

april-16-OS-pie

Windows 7 is the most common operating system among Deflect readers this month

An interesting set of data regards our cache response: as shown in the pie chart below,  in April around 70% of the pages we served were cached in our servers, while we had to get a copy from your websites for approximately 20% of the requests we received.

 

Deflect's caching system responses for the month

Deflect’s caching system responses for the month of April

 

Attacks on the Deflect network in April 2016

Around a dozen separate incidents were recorded on the network in April.  It’s important to note that the statistics represented here are from requests that triggered our banning mechanisms. In reality there may have been many more malicious requests. As per last month’s stats, the majority of bots were originating from the United States.

april-16-swabber-by-country

 

The majority of botnets captured by Deflect were using the WordPress Pingback attack mechanism, masquerading themselves with a “spider” user agent device. The “Ua_Device” parameter is a finding by our system, which recognises the user-agent strings used by many different devices, and categorises traffic accordingly. In this case the vast majority of IP addresses hitting the site were categorised as “spiders”. A spider, or web crawler, is software used by search engines to index the web. In order to index pages, however, a spider would usually visit each page of a website only once. In this case each IP address claiming to be a “spider” was requesting pages a very large number of times. User-agent strings are just text and this can be changed by clients to anything they like – including copying a user-agent string commonly used by some other software. We conclude that this was malicious traffic from a botnet masquerading as web-crawler traffic.

april-16-swabber-by-ua-device

Bots taking part in a WordPress pingback attack identifying themselves with a “spider” user agent device

 

april-16-swabber-ua-spider

Most of the “spider” bots were originating from the United States

 

 

TA3M APRIL ’16 – a Basic Internet Service in Canada?

Should Canada do more to encourage broadband adoption? The CRTC is currently debating whether to define a basic Internet service and whether to subsidize Internet access to rural, remote or low income communities. For people interested in the information superhighway, this hearing is when the rubber hits the road. Concordia professor Fenwick McKelvey will introduce the hearing to attendees, discuss his work in Internet Measurement and workshop ideas. A response to the CRTC making recommendations about Internet Measurement and defining basic service will be forthcoming for May 5th.

Location: GareMTL

When: April 18th 18:00

Yes, I want to come! Please RSVP below…

  • TA3M Montreal - April '16




To see a history of past TA3M Montreal events please refer to our archive.

Deflect stats March 2016

This is the first in a monthly series of posts sharing and discussing statistics on the Deflect network. March 2016 was a busy month for us. We began to publish analytic reports on DDoS attacks against some of the clients we protect on the network. Our aim is to help the target’s advocacy efforts and begin strip away at the impunity currently enjoyed by botnet operators. As our analytic tooling and understanding of these attacks improve, so will the reports.

In terms of people served and traffic on the network, this was our busiest month to date. We averaged around 20 million daily hits, a significant percentage of which came from readers in Mexico. Around ten separate DDoS incidents were recorded during the month, of various strength and sophistication.

 

Total hits this month, unique IPs we banned; unique IPs we served

Total hits this month, unique IPs we banned; unique IPs we served

 

Daily hits on the Deflet network

Daily hits on the Deflect network

 

Daily count of unique IPs by country of origin

Daily count of unique IPs by country of origin

 

This month's share of unique IPs by country of origin is a tortilla!

This month’s share of unique IPs by country of origin is a tortilla!

 

Most popular operating systems on the network

 

Attacks on the Deflect network in March 2016

Around a dozen separate incidents were recorded on the network in March. It’s important to note that these are requests that triggered our banning mechanisms. In reality there may have been many more malicious requests.

IP-Bans_by_country_date_histogram

Daily unique IP bans by country

 

Geographical bot distribution

Geographical bot distribution

We are also beginning to track botnets as anomalies on the network. Herein a graph built using the Timelion toolkit for ElasticSearch. It consists of time-series based representation of total hits on the network (red line) and a moving average (blue line) – specific browsing patterns as generated by readers behavior week upon week. We then multiply the blue line values by 3 so we can clearly see when an anomaly is happening on the network. Most of the time, although not every-time, the anomaly represents a spike in traffic or hits on websites – an attack.

timelion

We have also been contributing towards the development of a tool called GreyMemory. It is an anomaly detection tool which accepts any multi-dimensional time series as input, then predicts the next state of the system, measures the error of prediction and generates an anomaly rate. It uses predictive algorithms to evaluate what might happen next on the network, and compares this evaluation with the eventual result. If the quality of prediction drops, it alerts the anomaly. On the following diagram GRAY is the ratio of successful HTTP requests divided by the total # HTTP requests; BLUE is the anomaly rate, as calculated by GreyMemory and ORANGE is the anomaly Alert, where we should create incidents. Alerts are triggered when anomaly rate exceeds a threshold, which is currently on 95%

GreyMemoryReportMarch2016_2

Deflect Labs – fighting impunity with analytics and advocacy

For the last four years, the Deflect DDoS mitigation system has protected independent online voices from the onslaught of cyber-attacks aiming to silence them. We have grown, learning our lessons as we took the punches. One aspect of this work stood out as particularly interesting during this time: there were stories to be told in the sea of data brought on by each attack. Those stories could shine a light in the direction of the provenance of the attacks and the motivations of the actors behind them. Most importantly, it would aid the advocacy efforts of the targeted website and begin to strip away the impunity for launching these attacks, raising their cost in the long run. The more they attack us, the smarter we’ll get.

Deflect Labs is a new effort to collect and study distributed denial of service (DDoS) attacks launched against the websites we protect. It is built on a variety of open source tools, utilizing machine learning, time-series anomaly detection and botnet classification tools, many of which have been contributed to or wholly developed by eQualit.ie’s Deflect team. We aim to responsibly share news and our analysis of the attacks in a series of ongoing reports, the first of which is released today.

infogram

TA3M MARCH ’16 “WHO BYTES YOUR BITS”

We’re all familiar with the idea of a search warrant — but how else can the government access your private information in Canada? This informal TA3M workshop will explore this question—whether in the context of a criminal investigation or otherwise. We’ll also discuss the implications for businesses and organizations that hold private data for their clients, and the circumstances in which they might be forced to hand over records about their clients, users or communities. Together, we’ll think about how to mitigate risk and work through questions like:

  • How can law enforcement and intelligence agencies access private information about you? Do they always need a warrant? Should activists and community groups be particularly concerned?
  • If you’re hosting data for others, or holding private information that belongs to your users, what are your obligations as custodian of that data?
  • What are the situations in which you might be required to share or disclose data about others? What are your responsibilities to your users and clients in these situations?

Following a brief talk, attendees will be invited to bring share their own thoughts, experiences and questions. Presenters are happy to answer questions in English and French.

Presenters

Lex Gill is a researcher for the Canadian Civil Liberties Association’s Privacy, Surveillance and Technology Project and an affiliate to the Berkman Center for Internet and Society. She studies at McGill’s Faculty of Law.

Jillian Friedman is a technology lawyer. Her views on privacy law, and other technology law issues have been published in legal, academic and news media. Jillian has spoken before the Senate Committee on Banking, Trade and Commerce where she testified about digital currency, consumer protection and pseudo-anonymity. She is currently writing a book on financial technology law.

Location

We have moved!! Tonight’s TA3M will be held at GareMTL

When? March 21st, 18:00

Yes, I want to come! Please RSVP below…

  • TA3M Montreal - March '16




To see a history of past TA3M Montreal events please refer to our archive.

CryptoClasses – encryption for the masses!

In 2016 eQualit.ie is relaunching the Techno Activism 3rd Monday (TA3M) events in Montreal. To celebrate this occasion we are offering the inaugural Crypto Class – a rotating smörgåsbord of local digital security experts teaching the public about encryption. This will be a free event concentrating on practical skills and knowledge about encrypting (and decrypting) your email communications. Refreshments will be provided. Stick around to discuss our new project DSS514!

What is it? A practical workshop in an informal setting to teach participants about encrypting their webmail with Mailvelope.

Why? Should you be worried about pervasive Internet surveillance? Do you want to rebuild privacy for your online communications? It’s not that difficult at all! CryptoClasses are regular events built around practical workshops teaching modern and open source methods for online encrypted communications. We will demonstrate why you need this, how to do it, and you will leave the workshop with the skill and confidence to regain some privacy in your digital letters.

Where? The event will be held at StationC

When? January 18th, 18:00 (3rd Monday of the month)

This evening will be held in English. Future events will also be held in French and will cover a broader range of topics to include encrypted messaging and disk storage. Those interested in supporting future CryptoClass events are invited to come and discuss possibilities.

Who? CryptoClass will be lead by eQualit.ie with over a decade experience teaching activists around the world digital security basics and authors of numerous self-learning guides.

Yes, I want to come! Please RSVP below…

  • TA3M Montreal - CryptoClass




To see a history of past TA3M Montreal events please refer to our archive.

np1sec challenge

The challenge involve partially implementing some of our XMPP test client event handlers for namely join, receive and send. The result will be a client that people can use to join and chat securely. Note that the purpose of the challenge is for the EQ team to get to know the candidates and be comfortable with their C++ competence before commencing our interview process. Please reach out if you get stuck somewhere – this is not considered against you.

Step 1: Get the code and get it compiled:

You need our fork of libgrypt for it:

https://github.com/equalitie/libgcrypt

Then you need to get the code

https://github.com/equalitie/np1sec

and follow the README. Finally test with the mock client:

./libnp1sec_test

If you link to original libgcrypt you’ll get some kind of grypt related
error.

Step 2: Run the xmpp test client. It is implemented in

https://github.com/equalitie/np1sec/blob/master/test/xmpp_test.cpp

Login to two different accounts. try
to chat, etc.
Step 3: Implement the join/send and receive handler

Look at the example at:
https://github.com/equalitie/np1sec/blob/master/test/chat_mocker_np1sec_plugin.cc#L54

and

https://github.com/equalitie/np1sec/blob/master/test/chat_mocker_np1sec_plugin.cc#L127

Notes that in case of mock client join and receive handler both are being handled by chat_mocker_np1sec_plugin_receive_handler but it happens in different function in case of libpurple.

Step 4: Implement the call backs:

You need to give some call backs to np1sec library. You can find the
association in case of chat mocker here:

https://github.com/equalitie/np1sec/blob/master/test/session_test.cc#L62

mockops->send_bare = send_bare;
mockops->join = new_session_announce;
mockops->leave = new_session_announce;
mockops->display_message = display_message;
mockops->set_timer = set_timer;
mockops->axe_timer = axe_timer;
They are implemented here:

https://github.com/equalitie/np1sec/blob/master/test/chat_mocker_np1sec_plugin.cc#L135

You only need to implement send_bare and send a do nothing functions for set_timer/axe_timer.

Step 5: Test your client:

Follow the lines in

https://github.com/equalitie/np1sec/blob/master/test/session_test.cc#L189

to initiate the np1sec UserState and see if you can join and talk to yourself.

Creating a Hosts File Entry

If you wish to access your domain before your DNS has been updated, you can update your local ‘hosts file’, which will allow your computer to view your new site. Follow the appropriate instructions below.

Please note that this will work only with HTTPS and not with HTTP.

If you need any help with this procedure (for example because nslookup is not installed in your system and you can’t figure out what the IP of your SFTP server is), we are ready to help: please contact us through the Dashboard or send us an email.

OS X:

  1. Open Terminal
  2. Launch the following command (replacing SFTP_host with the address of your SFTP host you received in your activation email):

    $ nslookup SFTP_host

  3. The result will be something like the following output. The last line contains the IP address of your SFTP host, which you will need to add to your hosts file (numbers arranged in this form: XX.XX.XX.XX).

    Server:        YY.ZZ.XX.ZZ
    Address:    YY.ZZ.XX.ZZ#53

    Non-authoritative answer:
    Name:    grwtrcweg.deflect.ca
    Address: XX.XX.XX.XX

  4. Type ‘sudo nano /private/etc/hosts’
  5. Press Ctrl+Shift+V to take you to the end of the file
  6. Enter the text ‘XX.XX.XX.XX <yourdomain>’ (replacing `XX.XX.XX.XX` with the actual IP of your SFTP host and <yourdomain> with the URL of your website).
  7. Press Ctrl+x to exit
  8. Press y to save

Alternatively you can download the Hosts preference pane helper from here: https://github.com/specialunderwear/Hosts.prefpane/downloads

Windows:

  1. Launch the Command Prompt and enter:

    C:\>nslookup example.com

    whereby you need to replace example.com with your SFTP host address.

  2. The result will contain the IP address of your SFTP host, which you will need to add to your hosts file (numbers arranged in this form: XX.XX.XX.XX).

    Address: XX.XX.XX.XX

  3. Click “Start” button
  4. Click “All Programs”
  5. Click “Accessories”
  6. Right-click on Notepad and then click Run as administrator.
  7. If you are prompted for an administrator password or for a confirmation, type your password, or click Allow/Yes.
  8. Open the Hosts file. Discover the location for your version of windows here (https://en.wikipedia.org/wiki/Hosts_(file)#Location_in_the_file_system)
  9. Enter the text ‘XX.XX.XX.XX <yourdomain>’ (replacing `XX.XX.XX.XX` with the actual IP of your SFTP host and <yourdomain> with the URL of your website).
  10. Click Save on the Edit menu. (If using Windows 7, you will need to click Save on the File menu.)

Linux:

  1. Open a terminal.
  2. Launch the following command (replacing SFTP_host with the address of your SFTP host you received in your activation email):

    $ nslookup SFTP_host

  3. The result will be something like the following output. The last line contains the IP address of your SFTP host, which you will need to add to your hosts file (numbers arranged in this form: XX.XX.XX.XX).

    Server:        YY.ZZ.XX.ZZ
    Address:    YY.ZZ.XX.ZZ#53

    Non-authoritative answer:
    Name:    grwtrcweg.deflect.ca
    Address: XX.XX.XX.XX

  4. Open the file /etc/hosts with vim or your favourite editor as root:

    $ sudo vim /etc/hosts

  5. Add the following line, replacing `XX.XX.XX.XX` with the IP address of your SFTP host, `example.com` with the URL of your website and `example` with the name of your website:

    XX.XX.XX.XX example.com example

  6. Ensure that the nsswitch.conf file is correct. The nsswitch.conf file controls in which order services will be consulted for name service lookups, in our case we are looking for the “hosts” service:

    $ grep host /etc/nsswitch.conf hosts: files dns

    Check that “files” comes before “dns”. If it doesn’t, edit the file to obtain the above result.

  7. Check that your changes produced the wanted effect with this command:

    $ ping -c 1 example.com

    The result should be something like this (with XX.XX.XX.XX being replaced by the IP of your SFTP host):

    PING example.com (XX.XX.XX.XX) 56(84) bytes of data.

Migrating Your WordPress Site to Us

If you already have a working WordPress site that you wish to move to eQPress, the first thing you need to do is sign up with Deflect and specify that you would like to move your existing website to eQPress, providing us with the first and last name of your admin (they don’t have to be the official ones!). It would be also helpful to know if your WordPress instance contains a single website or is a multi-site with subdomains (http://sub.example.com) or subdirectories (http://example.com/sub).

This post contains information for migrating your website to eQPress. If you need any help, don’t hesitate to ask for our support.

What we need:

  1. A database dump of your existing WordPress site. You may need to request this from your existing hosting provider if you do not have the facilities to make a database dump yourself, or you can follow these instructions.
  2. The complete backup of your existing WordPress site files, which you can easily obtain by following this guide.

If you want, you can use a plugin to obtain your database dump and website backup. There are many such plugins for WordPress, and you can pick the one you prefer from this list.

How to Flush Your Local DNS Resolver’s Cache

If your computer cannot reach a certain website this could be because your local DNS resolver’s cache contains an outdated record. For example, you updated your DNS records to point to eQPress but instead you are seeing your old website. This is when flushing your DNS cache will speed things up.

Mac (OS X)

In the Command Terminal, type one of these commands:

sudo killall -HUP mDNSResponder
sudo discoveryutil udnsflushcaches

sudo dscacheutil -flushcache
sudo lookupd -flushcache

Windows

Run the following command in a Command Prompt window:

ipconfig /flushdns

Deflect – 2014 in numbers

The Deflect projects protects human rights and independent media websites from distributed denial of service (DDoS) attacks. It is a free service for qualifying organisations and the source code is publicly available on the project wiki. In our third year of operations we protected websites from over 60 countries and present herein some interesting facts and figures from 2014.

deflectpartners2014

 

2014 AVERAGES

MONTHLY VISITORS (UNIQUE): 3.14 MILLION

PAGES SERVED (DAILY): 1.44 MILLION

DAILY TRAFFIC (MB): 193374.54

 

2014 ATTACKS

DDOS ATTACKS MITIGATED: 100%

HIGHEST TRAFFIC LEVEL*: ~50GBPS

LARGEST BOTNET: ~15000 MEMBERS

 

* These measurements do not include UDP layer attacks, which are known to generate the biggest traffic levels

 

The Deflect network is attacked all the time by various botnets. These attacks can often be measured by a spike in bandwidth, connections to our servers and number of banned IPs. The following diagram represents network bandwidth in 2014.

bandwidth_2014_zoom

And now the same diagram but zoomed out so as to capture traffic levels generated by large DDoS attacks against Deflect protected websites.

Bandwidth (http level attacks)

We have developed various botnet identification and banning toolkits. They are publicly available from the project wiki. The following diagram displays malicious bot IPs we identified and banned in 2014. Note that this diagram would not line up with the generated traffic levels since banned IPs cannot request data from the network.

 

malicious_bots_banned_by_deflect

 

TOP 5 COUNTRIES VISITING DEFLECT PROTECTED WEBSITES

1. ua Ukraine 116,736,778 pages

2. us United States 79,519,912 pages

3. ru Russian Federation 32,841,316 pages

4. de Germany 19,842,609 pages

5. it Italy 15,610,504 pages

 

2014 IN DETAIL

 
https://deflect.ca/stats/2014.html
 

Deflect

(n+1)sec = privacy on the Net

In advance of this year’s Human Rights Day, eQualit.ie is proud to release the first public draft of a provably secure protocol for group messaging on the Internet.

np1sec-web

The protocol provides for end­-to­-end security of synchronous communications between any number of people. It is efficient and builds on recent advancements in cryptographic research. Security properties of (n+1)sec include:

  • Confidentiality: the conversation is not readable to an outsider
  • Forward secrecy: conversation history remains unreadable to an outsider even if participants’ encryption keys are compromised
  • Deniable authentication: Nobody can prove your participation in a chat
  • Authorship: A message recipient can be assured of the sender’s authenticity even if other participants in the room try to impersonate the sender
  • Room consistency: Group chat participants are confident that they are in the same room
  • Transcript consistency:  Group chat participants are confident that they are seeing the same sequence of messages

The protocol is being implemented as a FLOSS libpurple plugin and will find its first home in crypto.cat. We anticipate wide adoption in other instant messaging platforms. Contact us, join the conversation or check out the code on Github.

Moving Your Site to HTTPS

HTTPS (adding an S for “secure” to HTTP) is an internet communication protocol that protects your users’ connections to your website. Data sent using HTTPS is secured in that HTTPS provides 3 layers of protection:

  1. Encryption: while the user is browsing a website, nobody can see their conversations, track their activities in the website, or steal their information.
  2. Integrity: data cannot be tampered with as it travels from your website to the user’s computer and vice versa.
  3. Authentication: ensuring that your users are really communicating with your website. This layer of protection prevents man-in-the-middle attacks and stops attempts at attracting your users to connect to a fake site or to download falsified files.

While the purpose of enhancing security is certainly a very good reason to move your website to HTTPS, consider that this could also slightly improve your website’s ranking.

TL;DR – How to activate HTTPS on eQPress

If you already have generated an HTTPS certificate for your website, you can install it via the Deflect dashboard. By following the procedure to install your TLS certificate, your website will be accessible on HTTPS.

If you don’t have an HTTPS certificate yet, you can contact us through the Deflect dashboard or send us an email and we will generate it for you.

Keys and Certificates

For TLS (formerly SSL) to work, you need a private key and a public key. After the public key is signed by a certificate authority, your public key becomes your certificate. The private key and the certificate need to live on the server that your website is hosted on, so the web server software that sends your web pages to your visitors can also create the secure (TLS) connection to the browser to secure the link. If you know how, you are free to generate your keys and then send them to us through the Deflect dashboard. Otherwise, we are happy to generate the key pair for you.

Certificate Authority

To generate a free certificate signed by a certificate authority, the easiest way is to use Let’s Encrypt, a free, automated, and open certification authority run for the public’s benefit.

If you prefer to have your HTTPS certificate signed by a different certification authority, here’s a short list of services that will sign it for you:

RapidSSL
NameCheap

Analytics and Tracking

If you use analytics tools like Google Analytics, you will want to update the URL that you are tracking from HTTP to HTTPS. Make sure you do this both in analytics and Google Webmaster Tools.

Recommendations for Improving Your WordPress SEO

When it comes to search engine optimization (SEO), choosing the right WordPress theme framework becomes critical. Genesis does a great job of doing all the right things for search engine optimization (SEO). You will want to add some kind of analytics tracking to your site so you can gain insight about who is visiting your site and how your site is being used. Typically most people use Google Analytics, but if you are considering to use it in your website, please consider that eQPress Console already shows you some statistics and that Google Analytics, as well as other tools for website statistics, track users and can violate your readers’ privacy. If you decide to use one of these tools, Genesis provides a field on the Theme Settings page (wp_footer) to enter your analytics tracking code.

There are other great theme frameworks that are just as effective as Genesis, but if you choose not to use a framework or prefer to build your own theme, then you should use a plugin such as wordpress-seo by Yoast and use that to further optimize your pages and posts for SEO. The plugin has a ton of options which can be a bit overwhelming, but typically the defaults are fine. The plugin will also analyse your pages and give you recommendations on how to improve your content, title and other aspects of the page to make it better for SEO. There are lots of tutorials on using the plugin and of course the author of the plugin is a great source for learning about SEO: https://yoast.com

A couple more recommendations: in addition to a Google Analytics account for your site, you should also create a Google Webmaster Tools account and link it to your analytics account. And the other thing is to create a sitemap.xml file. The search engine crawlers look for that to more accurately index your site. The wordpress-seo plugin will create one for you, but there are simpler plugins to get this task done such as google-sitemap-plugin.

Choosing a Canonical Website Address

Canoni-what?

Canonical is the word used to describe the one address that you want the world to go to when they look you up. The typical choices are whether to use www in front of your domain or not. The classic example follows:

http://www.example.com/

or

http://example.com/

Choosing what your canonical website address (URL) will be is totally up to you. It’s a preference and there’s no right answer. As you can see by looking up at your browser’s location bar now, eQualit.ie has chosen a URL without www. If you start taking notice of the other websites you visit, you’ll probably see that there’s no regular pattern. Google chooses www. The wordpress.org team chooses non-www. It really doesn’t matter. What does matter is making that choice early and sticking with it.

Considering the Apex

One unique factor (with respect to hosting on) in your decision-making process is whether or not your domain will be hosted by a DNS company that supports pointing the non-www (officially called the apex record) address to a CNAME. If your DNS host does not support this feature, we recommend you choose www to be your canonical website address.

References

Here’s an article at Google Webmaster Tools called Use Canonical URLs that will help you to learn more about their view of canonical URLs.

Also, Matt Cutts provides some very helpful insight and a FAQ about SEO and URL canonicalization.

Standing strong in August

awstats_august14Ongoing conflicts in Ukraine and the Middle East saw a stream of independent media and human rights organizations turn to Deflect for DDoS protection. The network delivered over 75 million pages to legitimate readers in August, our highest numbers to date. One week in particular stood out as we brought on-board two websites in the midst of ongoing DDoS attacks against them.

One of the sites was getting hit by a botnet built on a newer version of the Dirt Jumper malware. We had previously trained our edges to recognize and protect against Dirt Jumper bots but this network displayed different behaviour to which we had to adapt. Their attacks did not bypass our caching network.

The other site came on board in the midst of a sophisticated and prolonged attack using various methods to bring them down. One notable vector of attack was using a Pingback DDoS from infected hosts running WordPress software. This is a type of reflection attack exploiting WordPress code built-in to the core package to improve a website’s SEO rankings. Furthermore, attackers were using their entire 14,000 hosts network in concert and hitting the target from each bot once or twice at a time. This is unusual behaviour as botnets usually try to overwhelm the website by hitting it often and hard (thereby giving away their malicious intention). In this particular case, the botnet was tailored to attack targets behind a caching infrastructure such as ours. Initial pattern recognition was difficult for the IPs in question. The sysops team quickly caught up though and isolated all hosts from accessing the network. Herein an example of a log entry from this attack.

SOURCE_IP – [DATE_AND_TIME] “GET /PAGE HTTP/1.0” http SITE_DOMAIN 200 158580 “WordPress/3.9.2; http://ATTACKERWORDPRESS; verifying pingback from PINGBACKURL” TCP_MISS text/html ORIGIN_SERVER 5621

Readers running websites on WordPress software are advised to install the Disable XML-RPC Pingback plugin to prevent their instance being abused by this attack.

traffic_report_0814

Traffic report from a single edge on August 8th, in gigabytes

Due to the nature of our infrastructure we do not see lower network level DDoS traffic – relying on numerous providers around the world hosting our caching servers to absorb them. This makes it difficult for us to judge precisely the size of an attack. In such cases we rely on our providers’ statistics and emails warning us about huge traffic loads. Between August 7-8 simultaneous attacks against Deflect clients generated traffic levels somewhere in-between 8 to 10 Gbps.

Both websites were initially protected by Cloudflare. One organization was even paying the 200USD per month account fee promising advanced DDoS mitigation. Deflect’s mandate is to protect and enable online voices for qualifying independent media and human rights organizations and operate on a strict policy to never deny or terminate a service simply for being the target of a large attack.

We do not usually disclose our clients to the public. This time we sought their permission, as we believe our service and principles are exemplified by standing up for an organization that defends the human rights of all, even when it is against popular opinion in their own country. B’Tselem, the Israeli Information Center for Human Rights in the Occupied Territories, monitors and documents human rights abuses, conducts research into human rights issues, promotes accountability for human rights abuses and media, advocacy and public education.

As an organization dedicated to safeguarding human rights in the occupied West Bank and Gaza Strip, we have faced many attempts to silence our voice. During the latest fighting in the Gaza Strip, attempts by opponents of free speech escalated, including stepped-up DDoS attacks which our previous hosting providers failed to repel. Deflect proved itself extremely helpful in protecting our website, and has allowed us to carry on with getting our information out to the public here in Israel, Palestine, and abroad.
Hagai El Ad, Executive Director, B’Tselem

B’Tselem is a winner of the 2014 Stockholm Human Rights Award and nominee for this year’s Václav Havel Human Rights Prize.

Secure Hosting Guide available now

We are pleased to announce the launch of our Secure Hosting Guide, available now on learn.equalit.ie. The guide has been produced in collaboration with our friends at Huridocs and will be useful for anyone who wants to know the key factors involved when looking for a good hosting provider. It has been written for users of all technical abilities and budgetary constraints and is tailored specifically to focus on the issues that matter most to our partners: Concerns over data security, server reliability and technical support are priorities when you are running a website that attracts the attention of hackers, botnets, social engineers and the local surveillance services.

In addition to hosting, the document has sections on choosing a name registrar, dealing with threat mitigation and the considerations regarding legal and contractual issues. This is an evolving document in a fast-changing field, so we welcome feedback and contributions from users and other knowledgeable parties.

Finally, there is a set of reviews for the ISPs that eQualitie uses with Deflect. We invite you to add to this list of trustworthy (and not so trustworthy) hosting providers.

DDoS mitigation on a network of principles and openness

Yesterday saw the public launch of Project Galileo, a CloudFlare initiative that partners with reputable international advocacy and civil society organizations to offer free DDoS mitigation services to human rights and independent media groups. As with our support for Google’s Project Shield last year, we welcome all attempts to bring DDoS mitigation to a wider audience of at-risk users around the world and would like to take this opportunity to encourage serious consideration of the ethical and operational standards as followed by eQualitie and our peers. There are both moral and technical obligations that we feel bound by in this industry, from combating hate speech to respecting our client’s privacy.

To this end, eQualit.ie is today putting forward a set of principles which we hope will receive the support of commercial and non-profit providers alike, as well as any partner organizations endorsing these services. Websites signing on for Internet hosting and content distribution services should have a sound understanding of how their providers operate and what motivates each of us to do this work. We strongly agree with CloudFlare’s stated aims:

…to build a better Internet. Fundamental to that is ensuring that bullies cannot use attacks to censor content simply because they disagree with it. We knew we needed to do something to stop this troubling trend.

However, we would add that to engage in activism you have to take a stand and you have to pick sides. By standing firmly against censorship, we cannot also protect groups which would misuse our network for political censorship or as a launchpad for the very same attacks we are trying to stop. Equally, we cannot accept websites which propagate hate speech and advocate for the disenfranchisement or even outright destruction of their adversaries. Such malicious actors are welcome to find a solution elsewhere but it is not accepted practice within our corner of the digital security field to defend rights defenders and rights deniers at the same time. There is no way for us to reconcile protecting both an LGBT site and an anti-LGBT site on our network without, at the very least, disrespecting the values of the former and enabling the latter.

For this reason we ask every organization entering this field to consider the harm done in protecting all sides which operate within a given conflict. To make no choice at all about who your customers are serves only to perpetuate each conflict, breed mistrust among activists and journalists involved and undermine our common aims.

That CloudFlare has chosen to join the fight against censorship-by-DDoS is a huge benefit to groups on the frontline who struggle every day to keep their voices heard. We see our partners face enormous financial, legal, political and personal risks by speaking out for what they believe is right and we understand it is our shared responsibility as protectors of their websites to perform our small part in their work without any ambiguity of operation and purpose.

Signed

The Deflect team

Take Back The Net!

This week eQualitie will be attending Take Back The Net, a two-day conference in which “human rights advocates and transformative technology providers will meet to discuss what civil society organisations and individuals can do to restore trust in communication infrastructure”. We are attending as guests of the Association of Progressive Communications, organisers of the conference and we are grateful to them for this opportunity to speak directly with many at-risk activists and to understand these vital issues from frontline perspectives.

Training in the Ukraine

eQualit.ie undertook two missions during the last month to work with independent media workers and aspiring digital security trainers from across the Ukraine. Over one hundred news media workers were trained in secure communications and a very capable group of future trainers were taken through the advanced training so that this valuable knowledge can continue to spread. We are grateful to the organisers for bringing us on board and to all the participants for their attendance. If your organisation is interested in digital security training, please get in contact with us at the address below

Sweden gets eQualitie

Last week eQualitie attended the Stockholm Internet Forum 2014, an annual gathering of multi-stakeholders from internet governance, global civil society, freedom of expression networks, independent media and even some progressive-minded government types. We spent three days meeting with activists, journalists and policy makers to listen to their concerns and discuss the best ways forward for the Internet Freedom movement. We championed open source principles and distributed solutions as the best way to engage and mutually benefit users from across the spectrum in the fight against censorship, surveillance and exclusion on the Net. Our gratitude goes out to the organisers for the invitation and particularly to our friends at Civil Rights Defenders for introducing us. Skol!

Feeling Insecure? Try some Digital Self-Help

We’re launching a free guide for teaching yourself Digital Security which can be accessed right here.

Over the last 8 years, eQualitie has been leading Digital Security trainings in dozens of countries for hundreds of activists and journalists, as well building two Digital Security schools and training many others to become trainers themselves. Every year we’ve seen the demand for trainings increase and while we are always interested in working with whomever requires our services, (please contact us if you’d like to talk about that), we understand that there are many more groups across the world we cannot easily get to for a variety of reasons, such as lack of funds, travel restrictions or scheduling conflicts. So we want to help anyone who would like to learn these skills and tools and has the motivation to teach themselves.

This is the latest in a series of guides we have made freely available, following on from the Digital Security Manual and Trainer’s Curricula. Next up, we’re putting together a guide on secure website hosting.

Mid-May in Tunisia

We are in Tunis this week leading a series of “training of trainers” sessions at DSS 216 , the Digital Security School set up by eQualitie in conjunction with our friends at Alternatives, the long-established Montreal NGO. The school is staffed by co-ordinators from across the Middle East and North Africa and operates in Arabic and French. It has been created as a permanent hub for digital security trainers to share cybersecurity tools and best practices with activists and journalists from the Maghreb region and beyond, with a particular focus on Women, Youth, Citizen Journalists and legal practitioners from Iraq, the Palestinian Territories, Tunisia, Sudan and Syria. You can read the press release here (en francais)

This is the second in a series of digital security schools which eQualitie are creating across the world. Our first one was started in Vilnius, Lithuania three years ago and in that time has trained hundreds of activists, journalists and trainers from Belarus. Please get in touch if you’re from that region and interested in trainings. Stay tuned for announcements on school number 3 later in the year

 

 

 

 

Q1 2014 Traffic Report: DDoStoyevsky’s Crimean Punishment

In the last 12 months we have seen steady growth in many aspects of the Deflect project, particularly with respect to membership, traffic, localisation and network capacity. The most significant contributing factors have been the uptake of more partners, the efficacy of our new banning software and the continued rise in DDoS attacks as a form of censorship.

To this end, we have more than doubled the number of our partners, so Deflected sites now operate in 17 languages and focus on affairs in 55 countries across the world. In addition, we have taken on more sites that report news or advocate for issues from a transnational perspective, resulting in a more even distribution of traffic from around the world.

A comparison between the first quarters of 2013 and 2014 shows this clearly.

Selection_021

Selection_020

 

We see that unique visitors have nearly tripled, the number of visits has more than doubled, page requests have all multiplied, hits are between four and five times as many and we are dealing with at least twice the amount of bandwidth as this time last year. The figures continue to grow as we move into March and April because of the current Ukraine situation. In the wake of the Euromaidan protests, the fall of the Yanukovich government and the annexation of the Crimea, we brought onto the network a number of key independent news sites operating in the region that have brought with them a large amount of traffic and a comparable amount of DDoS attacks.

The figures above are only for the legitimate traffic served. With respect to malicious requests, we saw an average of around 8MBps across the network for the month and when we first took on the Ukranian sites in March we saw spikes of 200 bots per edge.

DBP: Our Philosophy

The Deflect team has spent the last two years mitigating DDoS attacks against independent media and human rights websites. We’ve learnt a thing or two along the way and have put a lot of effort into developing open source software to make our lives (and weekends) a bit easier. The BotnetDBP project consists of four components to detect and ban malicious bots.

Banjax: responsible for early stage filtering, challenging and banning of bots, identified via regular expression matching

Learn2Ban: introduces intelligent, adaptive features to botnet detection and banning by using a machine-learning approach.

Botbanger: uses the support vector machine model constructed by Learn2Ban to test HTTP traffic and determine the legitimacy of the requester.

Swabber: is responsible for managing the actual banning of IP addresses identified by either Banjax or Learn2ban

GitHub repo

Notably, current Learn2Ban accuracy has been determined at 90% and above (i.e. both false positives and true negatives amounted to less than 10%). In several cases, accuracy of 99% was achieved. We continue to develop models based on larger attacks the network receives

We rely on our community of peers and invite you to take a look at the code. Your commentary and analysis are essential to seeing this open source initiative mature and become of relevance to anyone running a web server. For reference, all components are built modularly and can be adapted to any web service environment, albeit Banjax was written as an Apache Traffic Server plugin.

Changing Your Database Password

We are serious about our passwords here at Deflect. You might have noticed our 23 random character passwords for your WordPress admin user we generated during the installation of your site. That’s the kind of password that will keep your site safe from brute force and dictionary attacks. The random.org site provides some tools for generating super long passwords.

So why would you ever want to change your database password? Typically you won’t ever need to because we set it initially during installation to another unique 23 random character string. But there might be a good reason to change it. The one that comes to mind is Heartbleed. So, here we go…

Changing Your Database Password

Warning: Changing your database password can disable your site. Make sure you know what you are doing or send us an email if you need help

  1. Log into adminer. For example, if your site is example.com then go to https://example.com/adminer/.
  2. You can get your DB username and current DB password by SFTP’ing to your site and looking in your wp-config.php file which is located in the wordpress directory.
  3. Click on the “Privileges” link.
  4. Click on the “Edit” link beside “localhost”.
  5. Make sure the “Hashed” checkbox is unchecked.
  6. Use KeePassX or random.org to generate a long random password. Copy it and paste it into the Password field, then scroll to the bottom and click the Save button while simultaneously…
  7. Pasting the password you just set in adminer into your wp-config.php file on the line with define(‘DB_PASSWORD’, ‘password’); by replacing “password” with the new password.

First Steps with Your eQPress Site

Your shiny new eQPress site is ready to go! Now what? Here are some recommendations.

  1. Enable “pretty” permalinks under “Settings” -> “Permalinks”.
    Typically “Post name” is a good option, but you can choose whichever setting you prefer other than “Plain”. The reason for doing this is two-fold: on the one hand, your URLs just look nicer, on the other hand this could also increase your performance because this type of URL has better chances of getting cached.
  2. Next install a plugin to protect your website against comment spam. Anti-spam is easy to use, needs no configuration and just works.

Now that you’ve made some initial steps, you can take some time to read the official guide: First Steps with WordPress

The Best Options for Email Subscriptions with WordPress

The best option is to use MailChimp to manage your subscriber lists and also to send the emails. There are plugins that can integrate with your MailChimp account but even that is unnecessary if all you want is to add email addresses and then send emails when you write a new blog post. The way it works is MailChimp will check your RSS feed every day for new posts and when one is found it will automatically send it to everyone on your list.

MailChimp is very powerful and easy to use. Here are some articles that will help you get started.

The next best option is to use the Subscription feature that’s part of the JetPack plugin. You will need a WordPress.com account to use it but it’s very easy to sign up for one. The plugin will guide you through the process. Click this lovely link to read more about JetPack Subscriptions

Deflect Labs Report #3 (3D rendering)

Botnet attack analysis of Deflect protected website blacklivesmatter.com

Seamus Tuohy and eQualit.ie

This report covers attacks between April 29th and October 15th, 2016. Over this seven-month period, we recorded more than a hundred separate denial-of-service incidents against the official Black Lives Matter website. Our analysis shows a variety of technical methods used in attempts to bring down this website and the characterization of these attacks point to a “mob” mentality of malicious actors jumping on board in response to callouts made on social media and covert channels. Our reporting highlights the usage of no-questions-asked-hosting and booter services used by malicious actors to carry out these attacks. We describe the ever growing trend of Internet vandals who, searching for a little bit of infamy, launch denial-of-service attacks against the Black Lives Matter (BLM) website. Our analysis documented attacks that could be accomplished for as little as $1 and, with access to public documentation and malicious software within easy reach, only required basic technical skill. Some of the larger attacks against BLM generated millions of connections without relying on huge infrastructure. Instead, traffic was “reflected” from legitimate WordPress and Joomla sites. We compare public attribution for some of the attacks with the data coming through our networks, and present the involvement of purported members of the Ghost Squad Hackers crew in these events.

Contents:

Introduction

“Black Lives Matter, a May First/People Link member that is supported by the Design Action Collective, is a central organization in the response movement against police abuse, brutality and misconduct.” The BLM website has been protected by Deflect since April 15th, 2016, following a spate of DDoS and hacking attacks.

In early July we published a prima facie bulletin expecting to write a comprehensive report of the attacks soon after. Since then the BLM website faced an increasing number of sizable attacks that we decided to include in our analysis and delayed publication. This report will explore these attacks, correlating open source research and publicly stated attribution with what we saw in the data.

The Deflect Labs infrastructure allows us to capture, process and profile each attack, analyzing unique incidents and intersecting findings with a database of profiled botnets. We define the parameters for anomalous behavior on the network and then group (“cluster”) malicious IPs into botnets using unsupervised machine learning algorithms.

 

Attacks & attribution

As a DDoS mitigation solution for blacklivesmatter.com, Deflect has access to all legitimate and malicious requests made to this website. However in almost all cases, attacks come via infected machines or as reflection attacks from unsuspecting websites. A semi-experienced attacker knows how to obfuscate and disguise their traces on the Internet. It is therefore incredibly difficult to attribute an action to a particular person or IP address with confidence. We rely on our analytic tooling, peers in the mitigation industry and social media research to test our hypotheses. Assumptions arising out of OSINT are then verified against the data on our systems and vice versa.

Technical analysis and social media research indicated that actions against the BLM website were launched by multiple attackers frequently acting in concert. Some methods, like Joomla & WordPress reflection attacks, appear to have been coordinated, whilst in other cases it was clear that many actors jumped on the bandwagon of a more powerful attack to claim some of the credit. These small, loosely organized mobs appear minutes to hours after the start of the original attack and lob a hodge-podge of various attack methods, often to no effect. These actions are often accompanied by a flurry of queries from various website downtime monitoring solutions, as attackers try to collect trophies for their participation in the mob. Furthermore, we noticed a sophisticated actor who was able to generate malicious traffic on a level beyond anyone else that we documented targeting BLM. Using bulletproof hosting to coordinate their attacks, they did not go to great lengths to obfuscate their identity, creating instead a complicated web of social media accounts, possibly fake public attribution claims, and general intrigue about their motivations and purpose.

The ‘Ghost Squad’

The first, and only, publicly attributed attacks began in late April, as _s1ege, a professed member of the Ghost Squad Hackers crew, began tweeting screenshots showing site defacement and reports from website up-time checkers that the BLM site was no longer reachable. The action was part of #OPAllLivesMatter, likely in response to the #AllLivesMatter slogan (and then hashtag) created in 2015. On May 2nd, 2016, a YouTube video uploaded by @anonymous_exposes_racism contained a warning from a group identifying themselves as Anonymous to leaders of the Black Lives Matter movement, asking them to also denounce anti-white racism.

This first set of attacks against BLM, beginning on April 29th, lasted a mere 30 minutes. They came from six IP addresses and generated a little under 15,000 connections. A single method of attack and very few resources were brought into play, making this small action only temporarily effective at best. That evening five different IP addresses conducted another attack against the BLM website that topped off at over 158,000 connections over a period of an hour.

Timelion expression tracking malicious connections, by attack method, on April 29th

During this attack @_s1ege posted Twitter comments taking credit. Alongside photos that showed the Black Lives Matter website had been temporarily taken down by this attack, _s1ege posted a photo of the software he was using, “BlackHorizon”.

BlackHorizon is a clone of a piece of HTTP DoS software called GoldenEye, which was written by Jan Seidl in 2014. It was itself an expansion on the 2012 HULK project by Barry Shteiman. Unlike Seidl’s thoughtful adaptation and expansion of HULK, the BlackHorizon codebase mainly changes the ASCII art and the author’s name. When examined, it was clear that the functional components of the code were almost entirely unaltered from GoldenEye.

Several media publications rushed to interview _s1ege, with the @ghostsquadhack Twitter and GhostSquadHackers Facebook account referencing these publications. Around 30 minutes after the second attack Waqas Amir published an article on HackRead describing both incidents alongside his conversation with a GSH member. Later that evening one member of the GSH came back reusing an earlier bot and creating an attack that generated well under 700 connections, before giving up after less than 20 minutes.

Shortly after the tweets and HackRead publication, we witnessed an increase in attack frequency and variety. Only a portion of these had a similar behavioral profile on the network to those attributed by _s1ege to GSH. The attackers were using well-known software and may have called out to others on the Internet to follow suit. On May 10th, @_s1ege announces @bannedoffline as a new member in the Ghost Squad crew and two days later stops tweeting from this account altogether.

Maskirovka

BLM began to face larger scale attacks on May 9th. The first one lasted a little over 90 minutes and consisted of 1,022,981 connections from legitimate WordPress websites. This was not the first WordPress pingback attack against the BLM website, but it was an indication that we were beginning to face adversaries prepared to deploy much greater resources than before.The level of severity and aggression continued to mount and on July 9th we witnessed a WordPress pingback attack that generated over 34 million connections to BLM in a single day. The attackers did not seem to be interested in obfuscating their provenance, allowing us to track these activities over the next few months. The attacks were coordinated from machines hosted at a “bulletproof” provider – so called because they offer servers for rent on a no-questions-asked basis. The incidents associated with these attacks were the largest faced by BLM during the reporting period.

On July 25th we received a subscription for Deflect protection from a “John Smith” asking us to enlist http://ghostsquadhackers.org. We traced this request and further conversation with this user to @bannedoffline on Twitter and Facebook, as well as the owner of the following domains: ghostantiddos.com; ghostsquadsecurity.com; bannedoffline.xyz; www.btcsetmefree.org, among others.

Our analysis of actions run from the “bulletproof” hosting provider identified several IP addresses that were used for command and control. These addresses were correlated by a peer mitigation provider who had dared @bannedoffline on a hackers forum to DDoS them and recorded the resulting activity. Two IP addresses, one belonging to the DMZhosting provider mentioned further on in this report and a Digital Ocean machine, were identified in our individual records – and correlated to eight separate incidents in our study.

  • 191.96.249.80 Dmzhost Limited https://dmzhost.co
  • 178.62.152.134 DigitalOcean https://www.digitalocean.com

It is hard to say with any certainty why there were no more public attributions for attacks on BLM after the first week of May, considering that the severity and sophistication increased several-fold. @bannedoffline deleted all of their social media postings in late September, just before we recorded the biggest attack against the BLM website. bannedoffline was also linked to a 665gbps attack (the largest attack of its time, before the Mirai botnets) against the Krebs on Security website. The Ghost Squad did not attribute or deny @bannedoffline’s continued participation in their crew. Attacks attributable to bannedoffline and _s1ege, who could very well be the same person, made up less than 20% of recorded DDoS activity against BLM.

Technical Analysis Of Attacks

Incidents using a similar attack method were distinguished through an iterative process of identifying possible behavioral characteristics that distinguish one type of attack from others. First we identified combinations of behaviors and features that distinguished possible attacks from normal traffic. These profiles were then matched to existing types of attacks by looking for signatures from other reports and known codebases of these attacks to create an attack method profile. At this point secondary characteristics of the attack were examined to see if they distinguished individual attacks. This ranged from the hosting provider used for botherders, to the collection of innocent websites used as reflectors, and the methods used to check the status of the website, among others. If one or more of these characteristics overlapped for a specific set of attacks, those attacks were flagged for further investigation. Once we clustered these attacks, we looked across the entire set of attacks and attempted to reject any characteristic that could clearly differentiate that subset of attacks from similar attacks.

The most common category of attacks against the BLM website has been “application level” (layer 7) HTTP flood attacks. These bots mimic human behavior by connecting to a website and requesting a large amount of content until the server crashes for lack of resources. In this report we will only be looking at this type of attacks.

The capability of individual attackers has ranged greatly. As the BLM website faced more resourced and effective attackers, the mob became a persistent background noise.

Attack type (including variants and clones) April May June July Aug Sept Oct
WordPress pingback 5 6 4 4 5
Joomla pingback 1 6 6 4 3 3
Slow Loris 2 5 3 1
Fully Randomized NoCache Flood 6 14 11 5 7 2 4
Cache Bypass flood 1 1 2 2
Python script flood 2 2

You can view the entire attack portfolio on Google Docs


Slowloris

Aliases/Tools Slowloris, Pyloris, Torloris
Attack Type Layer 7 Denial of Service
Exploits Connection exhaustion
Obfuscation None
Attack Class Single-source
Attack Rate Low

The first attack identified against the Black Lives Matters website occurred on April 18th, just a few days after it had switched over to Deflect. A single address made between 5 and 30 connections a second to the main BLM web page. This lasted for 28 seconds. In total it made only 168 connections. Usually, this type of behavior would not raise any flags. But, in this case, the user agent of this client matched the user agent used in the original proof of concept code for “Slowloris – the low bandwidth, yet greedy and poisonous HTTP client!”

Slowloris is a DoS tool that was originally released in 2009. It is unique among the other Layer 7 attacks we will be discussing in this report because it does not focus on flooding the network with traffic. Instead, it attempts to use up all the connections to a web server leaving none left for legitimate users. This low number of connections allows Slowloris to attack a website without drawing the same attention that a flood of traffic would. There have been 12 identified attacks using the original Slowloris codebase since the BLM website has been protected by Deflect. All but one of these attacks were under 1000 connections. The largest Slowloris attack occurred on July 10th from 0:50 to 3:20 and from 6:00 to 7:20, making over 40,542 connections and clearly misusing this tool or not understanding its original purpose.

In the initial code release Slowloris used a single user agent. Today, many of the custom versions of Slowloris have changed the user agent [pyloris.py] or added source client obfuscation by randomly picking from a list of user agents [slowloris.py]. It is not surprising to see someone using an unmodified version of such an arcane tool even when the server used on the BLM website is protected against that attack. Many of the actors conducting DoS attacks are not building upon existing tools. While Slowloris was elegant at the time, the DoS space is dominated by attackers using simplistic measures. This is because one does not need a highly complex tool to take down most sites on the Internet.

Slowloris attacks on the BLM website have a tendency to overlap with or occur around the time of two low-skill “basic HTTP flood” attacks: [Blank] and [Python], as well as (Blank+WordPress) WordPress attacks.

HTTP Floods

HTTP floods are easy to implement and hard to identify attacks. Generally, they attempt to exhaust a system’s application resources or the network bandwidth. They do this by either creating a large amount of connections to the website or by continuously downloading a large amount of files. Because they only require an attacker to create many legitimate connections to a server, HTTP floods are quite easy to implement. Since these connections are legitimate, it can be very difficult for a defender to differentiate these connections from those of real users.

Simple HTTP Flood

Aliases/Tools None
Attack Type Layer 7 Denial of Service
Exploits None
Obfuscation None
Attack Class Single-source
Attack Rate Low

A simple example of this type of attack can be seen on April 30th. For just under ten minutes one lone address conducted a low sophistication HTTP GET request attack against the Black Lives Matter website. Over a five-minute period this attacker made 1503 connections from a single address using an Internet Explorer user agent. The BLM website only received a few of these connections as the attacker was banned within a second.

 


Basic Python

Aliases/Tools None
Attack Type Layer 7 Denial of Service
Exploits None
Obfuscation None
Attack Class Single-source
Attack Rate Low

Just a few hours after the previous HTTP Flood concluded, two different attacks started and subsided. They missed each other by just two minutes. The first was a “Fully Randomized NoCache Flood” and connected 2,000 times in its two minutes of attack. The second was a test run of an even simpler HTTP Flood attack than the previous example. The code behind this attack was written without any attempt to make it look like a legitimate user. Over the six minute attack, this script made around 400 connections. There were also 23 connection from a Chrome browser at the same IP address during this period, as the attacker frantically refreshed the web page to check on their impact. As in the previous attack, it took under a second for this IP address to be banned.

While a DoS attack does not need much sophistication to be effective, we mention it here because its unique signature shows that this attack was written by an inexperienced programmer. To explain how basic this attack is, the Deflect Labs researchers have recreated a working version of it below.

import urllib
while True:
   urllib.urlopen("http://www.blacklivesmatter.com")

This attacker came back again after a few hours using a different address. As in many single-source attacks, they were likely using a proxy to disguise the original IP of their attacks as they conducted these test runs. Before running the python script, they ran the same “Fully Randomized NoCache Flood” attack for about a minute and then quickly switched back to their python script. The python script made another 429 connections during the approximately six minute long attack. It was, like before, stopped within seconds.

This testing behavior continued over the next few days. With another small attack on the morning of May 1st that made up to 700 connections in just under 10 minutes and one with just over 1000 connections in just under 20 minutes. By the end of that week this attacker had concluded their experiment in attempting to build their own script. Its simple nature made it automatically blocked almost as soon as it connected. At its peak, it could only create a hundred or so connections per minute, which is far too little for a machine conducting a DoS attack.

HTTP Flood DDoS

Aliases/Tools None
Attack Type Layer 7 Denial of Service
Exploits None
Obfuscation None
Attack Class Multi-Source
Attack Rate High

The HTTP floods we have described so far in this section have only come from a single source. In this section we will explore how a botnet can leverage thousands of machines to conduct a distributed HTTP Flood and how we can identify these floods among regular traffic.

HTTP floods that involve many sources (DDoS attacks) are difficult to identify because they can look very similar to regular traffic. But because the BLM website, like every other, has traffic patterns that show the general behavior of their usual readership, there are some clear examples of DDoS HTTP Floods that we can explore.

Unsurprisingly, people in the US visit the BLM website far more often than other groups. This also impacts traffic patterns to the site. Traffic to the BLM website follows a daily cyclical pattern. There is a peak in its traffic between 12:00 and 14:00 EST. (The numbers in our screenshots reflect UTC+0 timestamps.) After that, the traffic slows until around 07:00 EST, when it spikes for the evening and then slows for the night.

Between August 5th and August 9th the hourly pattern changed from a smooth usage pattern like the above into this.

That week between 11:00 and 13:00 EST there was a surge of traffic from China, Indonesia, Turkey, and Slovenia. While the Deflect Labs team is not surprised that BLM receives international attention, it is a bit odd to see it occurring during the same period worldwide. When looking for HTTP Floods that have multiple sources, knowing these usage patterns can make it far easier to identify possible attacks like this one.

The anomaly we can see above was an HTTP POST Flood attack on August 8th. Based upon the dozens of countries per minute that are seen making higher than average connections, it seems plausible that this attack was using a botnet of infected machines.

Over a period of just over an hour, 11,514 machines attempted to upload (POST) a series of large files to the BLM website. This created a flood of large content-length requests that the BLM website had to process.

 



Fully Randomized NoCache Flood

Aliases/Tools Hulk, GoldenEye, BlackHorizon
Attack Type Layer 7 Denial of Service
Exploits KeepAlive, NoCache
Obfuscation Source Client Obfuscation, Reference Forgery
Attack Class Multi-Source
Attack Rate High

Websites that are protected by DDoS mitigation services – such as Deflect – use a “caching” system to store commonly requested pages and provide them to users so the protected website’s server does not have to. This “cache” of recently requested web pages allows Deflect to further limit the requests made to the protected server. Even if simple bots, like those in the last section, evade blocking, they often are just receiving responses from Deflect’s caches of recently requested URLs and not impacting the origin server at all.

DoS providers responded to the use of caching by creating a bot that tricks the cache into thinking that they are requesting a page that was never requested before. These “Cache-bypass” HTTP Floods are bots that add a randomized query at the end of their requests. These randomly generated queries cause a cache to view each request as a new request, even though the bots we are examining in this report only ever requested the main BLM URL “blacklivesmatter.com”.

GoldenEye is a Layer 7 DoS tool. It allows a single computer to open up multiple connections to a website, each of which pretends to be a different device. To do this, GoldenEye provides a different user agent string for each connection. Over the combined hour and a half of attacks, these 11 bots pretended to be hundreds of different types of users to avoid detection.

 

Later in the evening of April 30th another attack consisting of just under 11,000 connections was attempted. This attack used an improved “Fully Randomized NoCache Flood.” While the attack starts with 9 bots using something similar to the code used by GSH, a single address joins a minute into the attack and quickly dwarfs the other attackers in both number of connections and variety of user agents that it employs.

If it were not for the variety of intensity and method used by the individual addresses, attacks like this would look like they involved a single actor. But as is common for attacks against the BLM website, this attack starts slowly with one or two initial actors, who are then joined by a small mob of “bandwagon bullies.” As was seen in the early GSH attacks, they share the tools used in their attacks with the other attackers. Whoever this late attacker is, they are clearly not just another member of the team. This attacker has considerably different network resources and likely software that allows them to have far more impact than all the participating GSH team members.

Reflection DDoS

Joomla! Reflection DDoS

Aliases/Tools DAVOSET, UFONet
Attack Type Layer 7 Denial of Service
Exploits None
Obfuscation None
Attack Class Reflected
Attack Rate High

In 2013 a series of vulnerabilities were discovered in a Google Maps plugin for the Joomla! CMS. One of them made it possible for anyone to request a Joomla! site to make an HTTP request to remote websites. By June 2013 this vulnerability had already been weaponized and included in an existing DDoS framework called DAVOSET (DDoS attacks via other sites execution tool). In 2014 this same vulnerability was included in the UFOnet DDoS framework.

Each of these DDoS frameworks have easy-to-use web-based point-and-click interfaces and a built-in list of vulnerable Joomla! websites. This makes them ideal for a low-resourced or unsophisticated attacker looking to amplify another attack. Of the 23 WordPress attacks made against the BLM website, only 7 of them were not paired with a Joomla! attack.

Initially, it was difficult to identify Joomla! attacks because most of the connections do not provide a user agent string. Empty user agents are somewhat common on the Internet. Many non-malicious, but quickly made, bots do not provide a user agent. As such, when we initially saw these spikes of traffic, we assumed that they were from another sloppily made DoS bot.

After we saw this bot accompanying attacks from a variety of different attackers, we investigated further and noticed a fingerprint hidden in the traffic that led us to the Joomla! attack. Although most of the user agents used by Joomla! sites to make these requests are blank, a small subset of these machines include the version of PHP language that was used to run the request. While blank user agents are somewhat common, many of the attacks that included them were combined with user agents that contained PHP versions. Given the relative rarity of PHP, we realized that the odd increase in empty user agents alongside other attacks was because they were being combined with Joomla! attacks.

 


Introduction to WordPress XMLRPC Floods

Aliases/Tools WordPress Pingback
Attack Type Layer 7 Denial of Service
Exploits NoCache
Obfuscation Spoofing
Attack Class Reflected
Attack Rate High

By default, WordPress has a “pingback” feature that was built to allow WordPress sites to alert other blogs when they linked to their content. On a high level, this works similarly to a mention in Twitter. When a WordPress site publishes a post that links to another website, it sends out a “pingback” to that site with a link to the post containing the original the link. If the receiving site is also based on WordPress, it responds to the original site to confirm that it received the pingback.

Pingbacks have been a part of WordPress sites since Version 1.5, which came out in 2005. It wasn’t until 2012 that Christian Mehlmauer released a working implementation of code that took advantage of this feature to ask WordPress sites to verify “pingbacks” from spoofed URLs. Two years later, in March 2014, Akamai released a post that described a “pingback” attack consisting in over 162,000 WordPress sites. In September 2015 they announced that WordPress pingback attacks made up 13% of all Layer 7 attacks they faced.

At 22:00 on May 1st a WordPress pingback attack began targeting the Black Lives Matter website. In just 13 minutes it made 181,301 connections. As this WordPress attack subsided, a Joomla! attack took its place. The moment the WordPress attack started, the second attacker began to use free online services dozens of times a minute to check if the Black Lives Matter website had gone down. As the second attack began, the attacker increased the frequency at which they monitored the state of the website. Four minutes into the attack, when it had obviously succeeded, the attacker stopped checking the site. Altogether, this attack consisted of around 350,000 connections in a period of less than an hour.

 

As was mentioned in the original bulletin, the most intense attacks against the Black Lives Matter website have been WordPress pingback attacks. The first large-scale attack against the BLM website was a WordPress attack on May 9th. This attack made over 1,130,000 connections in just under three hours. It was a mix of over 1,000,000 connections from a WordPress pingback attack alongside 100,000 connections from a “Fully Randomized NoCache Flood.”

 

The following WordPress sections will provide some illustrative examples to show how we explored the relationships between these bots. But we will not examine every attack. Nor will we try to attribute attacks to their source.

WordPress pingback & Botherder Addresses

While WordPress attacks work similarly to Joomla! attacks they are far easier to identify. These attacks clearly list their WordPress version as their user agent. Because these attacks started to become more widespread, a new feature was released in version 3.9 of WordPress. This version updated pingbacks to include the IP address that made the original pingback request.

WordPress/4.6; http://host.site.tld; verifying pingback from 127.0.0.1

We call these IP addresses “botherder” addresses. Some of these addresses correspond to globally addressable IP addresses that one can reach over the Internet. Others are addresses that should never appear on the public Internet. These bogon addresses are private/reserved addresses and netblocks that have not been assigned to a regional Internet registry. The bogon address seen in the example above is called localhost. It’s the IP address used by a computer to refer to itself.

While adding the address of the botherder was implemented to de-anonymize the true source of an attack, most attackers are very adept at concealing their true IP address through the use of spoofed packets, proxies, virtual private servers (VPSs), and the use of compromised machines to conduct the original requests. When we started looking into the botherder addresses, we assumed that we would only find spoofed addresses. To our surprise, the botherder addresses exposed far more than we expected them to. By clustering the botherder IPs exposed in an attack, we were able to develop behavioral profiles that helped us link different attacks together to understand which attacks were likely conducted by the same attacker.

The first thing we looked at were the botherder IPs used in WordPress attacks against the BLM website. Our exploration of bogon addresses showed clear relationships between the attacks that could be exposed by looking at the botherder addresses.

The large blue ball of shared IP addresses on the left side of the bogon graph above surrounds two small incidents that occurred on August 8th and 9th. This massive ball of shared IP addresses consists of over 500 addresses from the private IP address spaces. Specifically, they include 382 addresses from the 172.16.0.0/12 address range and 177 addresses from the 10.0.0.0/8 address range. Private address ranges are not entirely uncommon for WordPress pingback attacks. They can appear when the botherder is on the same hosting provider as the WordPress sites they are exploiting and can also be created when a botherder is spoofing random addresses. What is unusual is how clearly the overlapping bogon IP addresses link these two attacks.

There were also globally addressable botherder IP addresses that linked each of the individual attacks against BLM together. It is likely that areas of sparse overlapping IPs exist because many botherders were clearly spoofing IP addresses. But the areas with many connections showed relationships that were worth exploring.

One commonality between all the attacks was that while every attack has hundreds of spoofed botherder addresses that appear only once or twice, there are also a small number of botherder addresses that account for a majority of the bots herded for the attack. In the August 8th and 9th attacks, which can be seen at the bottom of the globally addressable IP graph, three IP addresses accounted for 95% (13,963 / 14,585) of the WordPress connections that identified a botherder.

Because Deflect’s primary purpose is DDoS mitigation, Deflect Labs’ investigations often happen days or weeks after the fact. This means that we often have to rely on our logs and open source intelligence. In this case one of the first things we looked at was who owned the three primary botherder IP addresses. These IP addresses belong to Digital Ocean, a VPS provider based in New York. Digital Ocean does not provide multiple IP addresses per machine, and so we know that this attack was herded by three separate Digital Ocean “droplets.” Hourly pricing for Digital Ocean droplets runs between $0.007 USD/hour and $0.119 USD/hour. With each of these attacks lasting under half an hour, the cost to run this attack was well below a single dollar.

 


“Bulletproof” Hosting

By far the largest cluster of associated WordPress attacks occurred between July and October. This set of attacks includes the five largest attacks over that four-month period.

Among the 206 globally addressable IPs used by those attacks, 5 botherder IP addresses make up 65% (41,030 / 62,488) of the botherder IPs identified in the attack. Each of these botherders were hosted on an “offshore” hosting provider called DMZHOST. The two most connected botherder IPs in our attacks are mentioned countless times on a variety of IP address reputation websites, forums, and even blog posts as the source of a variety of similar attacks.

“Bulletproof hosting” providers like DMZHOST provide VPSs that advertise themselves as outside of the reach of Western law enforcement. DMZHOST offers its clients “offshore” VPSs in a “Secured Netherland datacenter privacy bunker” and “does not store any information / Log about user activity.” At the same time, DMZHOST’s terms of service are just as concise. “DMZHOST does not allow anything (related) to the following content: – DDos – Childporn – Bank Exploit – Terrorism – NO NTP – NO Email SPAM”.

Conclusion

Silencing online voices is becoming ever easier and cheaper on the Internet. The biggest attacks presented in this report did not require expensive infrastructure, they were simply reflected from other websites to magnify their strength. We are beginning to see authorities pursue and shut down “bulletproof” hosting and booter services that enable a lot of these attacks, yet more needs to be done. In the coming age of IoT botnets, when we begin to witness attacks that can generate over a terabyte of traffic per second, the mitigation community should not guard their intelligence on malicious activity but share it, responsibly and efficiently. Deflect Labs is a small project laying the groundwork for open source community-driven intelligence on botnet classification and exposure. We encourage you to get in touch if you would like to contribute.


 

Deflect is a website security project working with independent media, human rights organizations and activists. It offers DDoS mitigation, secure hosting and attack analytics, free of charge to qualifying organizations. All of our tools are open source and we operate according to strict terms of service and principles promoting the privacy of our clients. Deflect is a project of eQualit.ie, a Canadian not-for-profit organization working to promote and defend human rights in the digital age.

Creating Your New WordPress Site

Whether you are a first time WordPress user or not you may need to build your new site while your existing site continues to run. If you immediately update your DNS settings to point to eQPress without having migrated your website yet, what you’ll see is a default installation of WordPress. That’s probably not what you want. So, you have a few options when it comes to building your new site.

  1. You can update you local computer’s hosts file during the migration so your browser loads the site at eQPress. Here’s an article that will help.
  2. If you can withstand a bit of downtime then putting up a “coming soon” page is by far the simplest. Just point your DNS to the IP address supplied in the Welcome email and read this guide.
  3. If neither of these options suit you, send us an email or contact us through the Dashboard, and we’ll change the settings of your eQPress site so it will respond to dev.example.com. This will let you work on it and keep your current site active. When you are ready to switch, we can make the necessary changes to the database so the site responds to example.com.

We have written a follow-up to this article which explains the whys and hows of migrating your WordPress data. There’s also a more in-depth section on the WordPress Codex about moving a WordPress site.

Learning WordPress

Here are some great resources for learning how to use WordPress.

The Official WordPress User Manualhttps://make.wordpress.org/support/user-manual/
This is a living document created and maintained by the amazing and dedicated WordPress.org team.

Easy WP Guidehttp://easywpguide.com/
You won’t find any talk of HTML, PHP or creating WP Themes here. What you will find is an easy to follow WordPress manual that will help you understand the basics of editing your site content.

Codex for the WordPress Projecthttp://codex.wordpress.org/
The online manual for WordPress and a living repository for WordPress information and documentation.

WordPress TVhttp://wordpress.tv/
Videos from WordCamps and more about our favourite CMS and blogging platform.

WP 101http://www.wp101.com/
Some free but mostly pay access video tutorials about learning the ins and outs of WordPress.

Restricting Access to Your Website

There are times when you want to prevent the world from seeing your website. One reason might be that you are in the process of designing and developing and don’t want to share your progress with the world, since it might not be ready for all eyes. Another reason might be that you only want registered users to have access to view your content. The following plugins can help restrict access to your WordPress website:

Ultimate Coming Soon Page – http://wordpress.org/plugins/ultimate-coming-soon-page/

Restrict Site Access – http://wordpress.org/plugins/restricted-site-access/

Removing the WordPress admin User

Brute-force login attempts are typically carried out against the “admin” user. “Admin” used to be the default username of the first administrator created when installing WordPress, but now the installation asks you what you want to name it, and on eQPress it will be your administrator’s name and surname (not necessarily the “official” ones!).

If you have an old WordPress installation that you have migrated to eQPress, though, your website could still have an “admin” user. By removing this user, you will force the malicious hackers out there to guess not only your password but also your username. Here’s how to rename your “admin” user:

  1. Sign into your wp-admin as the admin user.
  2. Use the “Users->Add New” screen to create a new user.
  3. Provide a new username that’s not “admin”.
  4. The new user’s role must be set to “administrator”.
  5. Specify a super long passphrase. You can follow this guide to create a secure one.
  6. Click “Add new user”.
  7. Sign out as the “admin” user.
  8. Sign in as the new user.
  9. Delete the old “admin” user and assign all posts, pages and comments to your new admin user.

Protecting Your WordPress Website

Hosted behind the Deflect network, eQPress is designed to prevent your site from getting attacked or hacked. Security is best practiced as a series of countermeasures against known vulnerabilities or threats. We provide the essential underlying protective layers and the rest is up to you. There is no protection against a weak password, so…

The single most effective way to keep your WordPress website secure is to use strong passphrases. Use a password manager such as KeePassX, so you don’t need to remember those crazy long passwords. Alternatively, you can use your brower’s built in password manager (but keep in mind that if you don’t use a Master Password to protect it, all your passwords will be visible to anybody who may access your computer). To generate a long and random passphrase that is secure enough, you can use KeePassX itself or just click here to have 5 passwords generated automagically.

eQPress Console plugin provides a feature to put your site into lockdown mode, which makes all files and directories unwritable by the web server.

If you want to check your website for known malware, blacklisting status, website errors, and out-of-date software, you can use one of these third-party scanners:

Debugging the Dreaded “White Screen of Death”

If you are here because you recently installed a plugin, then take a look at this flow chart.

Both PHP errors and database errors can manifest as a white screen, a blank screen with no information, commonly known in the WordPress community as the WordPress White Screen of Death (WSOD).  Here are some basic steps you can follow to begin debugging this problem if it’s not been caused by a new plugin that you’ve just installed:

  1. SFTP to your document root (contact us through the Dashboard or send us an email if you’ve lost your SFTP credentials).
  2. Change into the wordpress directory.
  3. View or download the php-errors.log file.
  4. Take a look at the last few lines of the error log to determine the cause of the white screen.

You might see a very specific PHP error which will provide a line number in the file that’s causing the problem. At this point you can:

  1. Download the file that’s causing the problem.
  2. Go to the line that was listed in the error log.
  3. Fix the issue.
  4. Upload the file back to the server.
  5. Test your website.

If the white screen does not go away, repeat all of the steps above. Sometimes there could be more than one error.

How often is my site backed up?

Backup are important so we take a multi-layered approach. The first is an enterprise level solution which encrypts all data and transfers the archives to Amazons S3. We retain 30 daily backups, and 15 weekly backups which will allow you to restore from archives that are up to 3 months old.

The next layer of backups is done at the virtual machine level. We take full image snapshots every night which includes all website data. The 3rd layer is live replication. That’s happening in real time at the database level and on a regularly scheduled basis for files.

In the event of a catastrophic failure it’s possible that you could lose some recently uploaded files. Your content will be replicated immediately so any blog posts or pages you create would not be affected by a server failure unless you were in the middle of creating it when the failure happened.

When will my WordPress core get updated?

WordPress periodically releases maintenance updates. These are typically for significant bug fixes or security issues. Since these upgrades might have security implications, and because WordPress’s popularity makes it susceptible to an exploit being quickly released, we attempt to apply these upgrades as quickly as possible.

Here’s what the different versions look like:

  • Major release: 4.1
  • Maintenance and/or security release: 4.1.1

Our goal is to upgrade all websites within 6 hours of when a version addressing security issues is made publicly available. All sites will be upgraded no later than 24 hours from the time when the official announcement is made on the WordPress Project’s News blog.

Major releases provided by WordPress can significantly affect its compatibility with plugins and themes. Typically there are no security patches applied therefore the urgency to upgrade is lower. We will provide guidance via our announce mailing list of how the upgrades will eventually be applied to all websites hosted on the platform.

Antispam Recommendations

Spam is a bummer, as we’re sure most of you agree. Here are some antispam tools we’ve personally used. This first one is great.

Anti-spam

Pros

  • super simple, no configuration
  • integrates seamlessly with any theme
  • free

So far no cons. Crazy, right?

Another strategy is to use 2 plugins together. For example, we’ve had excellent results using Antispam Bee and Spam Free WordPress. Antispam Bee alone sometimes misses spam posted by a spambot and since a blog can receive thousands of these per month, even a small percentage can mean quite a lot of spam removal to deal with. By adding Spam Free WordPress into the mix, you can pretty much eliminate automated (spambot) comment spam. Unfortunately, this plugin fails to catch some of the manual spam added by real people, which is where Antispam Bee shines, since it’s using the Project Honeypot which publishes a list of the top URLs, domains, and keywords being promoted by comment spammers. Project Honey Pot also publishes a list of the top IP addresses being used by comment spammers.

Plugins

Antispam Bee

Pros

Cons

  • doesn’t always work against automated (spambots) comment spam
  • support seems to be non existent or only in German

Spam Free WordPress

Pros

  • blocks 100% of automated (spambots) comment spam
  • free

Cons

  • may need some work to fit in with your theme
  • can be tricked by human spammers (actual people paid to add spam manually)

Service

Akismet

Pros

  • free for personal use
  • integrates seamlessly with any theme

Cons