DDoS Attack Used 'Headless' Browsers In 150-Hour Siege(darkreading.com)
darkreading.com
DDoS Attack Used 'Headless' Browsers In 150-Hour Siege
http://www.darkreading.com/attacks-breaches/ddos-attack-used-headless-browsers-in-15/240162777
7 comments
I was entirely wrong when I thought that I understood DDoS attacks fairly well. There's actually at least three different types of attacks:
"Layer 3 and Layer 4 DDoS attacks are types of volumetric DDoS attacks on a network infrastructure. Layer 3 (network layer) and 4 (transport layer) DDoS attacks rely on extremely high volumes (floods) of data to slow down web server performance, consume bandwidth and eventually degrade access for legitimate users. These attack types typically include ICMP, SYN, and UDP floods."
"A Layer 7 DDoS attack is an attack structured to overload specific elements of an application server infrastructure. Layer 7 attacks are especially complex, stealthy, and difficult to detect because they resemble legitimate website traffic. Even simple Layer 7 attacks – for example those targeting login pages with random user IDs and passwords, or repetitive random searches on dynamic websites – can critically overload CPUs and databases. Also, DDoS attackers can randomize or repeatedly change the signatures of a Layer 7 attack, making it more difficult to detect and mitigate."
This glossary proved to be quite useful: http://www.prolexic.com/knowledge-center-dos-and-ddos-glossa...
"Layer 3 and Layer 4 DDoS attacks are types of volumetric DDoS attacks on a network infrastructure. Layer 3 (network layer) and 4 (transport layer) DDoS attacks rely on extremely high volumes (floods) of data to slow down web server performance, consume bandwidth and eventually degrade access for legitimate users. These attack types typically include ICMP, SYN, and UDP floods."
"A Layer 7 DDoS attack is an attack structured to overload specific elements of an application server infrastructure. Layer 7 attacks are especially complex, stealthy, and difficult to detect because they resemble legitimate website traffic. Even simple Layer 7 attacks – for example those targeting login pages with random user IDs and passwords, or repetitive random searches on dynamic websites – can critically overload CPUs and databases. Also, DDoS attackers can randomize or repeatedly change the signatures of a Layer 7 attack, making it more difficult to detect and mitigate."
This glossary proved to be quite useful: http://www.prolexic.com/knowledge-center-dos-and-ddos-glossa...
It raises interesting questions about how companies like Incapsula will integrate with their customers in the future.
Fairly easy for them to sit and monitor the low level networking kit dealing with Layer 3 + 4 attacks, but that's the wrong place to focus on Layer 7, right? They need to understand the web app and infrastructure it touches.
I'm sure they exist in some form or another, but it's likely we'll see more design patterns emerging to deal with mitigating application attacks. Combined with the network/protocol control you'd have application logic feeding down suspected attack data to block
Fairly easy for them to sit and monitor the low level networking kit dealing with Layer 3 + 4 attacks, but that's the wrong place to focus on Layer 7, right? They need to understand the web app and infrastructure it touches.
I'm sure they exist in some form or another, but it's likely we'll see more design patterns emerging to deal with mitigating application attacks. Combined with the network/protocol control you'd have application logic feeding down suspected attack data to block
You raise an excellent point.
We have a lot of application awareness configurations and our signature pool (which is one of the tools we use for traffic profiling) holds over 10M variant, sometime as much as ~20,000 per user-agent type, to cover all scenarios.
We have a lot of application awareness configurations and our signature pool (which is one of the tools we use for traffic profiling) holds over 10M variant, sometime as much as ~20,000 per user-agent type, to cover all scenarios.
Fair warning - I just got pinged from corporate security that this site triggered an alert on our IDS: "the IDS reported the machine accessed a site containing a JavaScript known to contain hidden iFrames and malware redirects". He said it was named "tongji.js". Can't investigate further as I'm still on said network and don't want to re-ping it...
>Incapsula was able to mitigate the attack.
I wonder how considering the packets would not necessarily be similar.
I wonder how considering the packets would not necessarily be similar.
I'd assume the HEADERs would be the same, e.g. basic stuff like UAS could be the same, or more low-level like Accept-* headers.
Note that this doesn't seem like a DDoS focused on high-bandwidth but rather focused on causing application load by triggering some server action and abusing the CPU/RAM, etc. In this case, Level7 analysis, is very effective and usually simple.
Note that this doesn't seem like a DDoS focused on high-bandwidth but rather focused on causing application load by triggering some server action and abusing the CPU/RAM, etc. In this case, Level7 analysis, is very effective and usually simple.
Very true. As far as headers concerned, we actually dig very deep. For instance, we will look at little encoding-related nuances, which can help identify spoofed headers (ua and IPs are fakeable, after all) :)
Also, we look for abnormalities in header order while being aware of variants that can derive from using various devices, proxies, etc.
Hence the 10M signature pool, which grows as new variants are spotted across our network.
Maybe they're using another form of pattern recognition. Time of day for the originating traffic vs. area of site being visited or particular type of stock etc...
Hi, I actually work for Incapsula. For Layer 7 mitigation we use a multi-vector approach which' among other things, consists of:
Client Classification - comparing visitor's user-agent, IP, header parameters and etc to our pool of 10M signatures. Suspects will get CAPTCHA. (~0.01% false positives)
Visitor Reputation - we use crowd-sourcing to compile a list of suspected IPs. The list is updated in real time. Combined with other signals, this data allows us a better understanding of the incoming traffic.
Progressive Challenges - We check visitor's ability to retain cookies, execute JS and so on. In this case, the browser-based bots were able to evade those defenses. (These are also the most commonly used Layer 7 mitigation methods.)
Behavior Monitoring - We look at abnormal access rates, visiting patterns, etc. Here we also look for correctional of signals, to help us pinpoint suspicious behavior.
And so, by collecting and cross-referencing different types of data, the system is designed to distinguish between humans and bots. The process is mostly automated and is always seamless.
Client Classification - comparing visitor's user-agent, IP, header parameters and etc to our pool of 10M signatures. Suspects will get CAPTCHA. (~0.01% false positives)
Visitor Reputation - we use crowd-sourcing to compile a list of suspected IPs. The list is updated in real time. Combined with other signals, this data allows us a better understanding of the incoming traffic.
Progressive Challenges - We check visitor's ability to retain cookies, execute JS and so on. In this case, the browser-based bots were able to evade those defenses. (These are also the most commonly used Layer 7 mitigation methods.)
Behavior Monitoring - We look at abnormal access rates, visiting patterns, etc. Here we also look for correctional of signals, to help us pinpoint suspicious behavior.
And so, by collecting and cross-referencing different types of data, the system is designed to distinguish between humans and bots. The process is mostly automated and is always seamless.
This is a great & informative answer. PhantomJS allows an attacker to get past any progressive challenge but it is nice that there is something else to go on. A properly-executed PhantomJS DDoS is a scary thing, it's great that you have some methods of mitigation.
How would you differentiate the traffic coming form headless browsers from normal users ? with a proper user-agent and javascript enabled, isn't it almost impossible ?
No, it's not impossible. Basically, you detect anomalies, i.e. gather statistical information about your users and their behavior in advance and apply that as a filter during attacks. For example, if you have like 10 new refererless users per hour, i.e. without a cookie and a referrer, but suddenly there are 1000 of them and backend is already slow - you should probably drop their requests. Same with specific referrers and any other information you have about your users. But this is kind of preventative only approach, it won't work if your site is already under attack.
The Referer header is just one more thing that a sophisticated attacker will spoof. I think the GP is correct - with enough preparation, a concentrated PhantomJS attack will look exactly like users accessing the website en masse, and it can be very, very difficult to tell who is real and who is not. That is why they use a tool as heavy as PhantomJS, which (from experience) is not very quick compared to more traditional methods. It is because it spoofs a real browser quite completely that it is so good for these methods.
For example, some pages might do a trick where they set a cookie, load another page, and redirect / drop based on whether or not that cookie is present in exactly the form it should be present. Maybe they set two, one expires immediately and the other contains some complex data. PhantomJS can handle that easily (as it is just Webkit + QT) but traditional tools do not.
For example, some pages might do a trick where they set a cookie, load another page, and redirect / drop based on whether or not that cookie is present in exactly the form it should be present. Maybe they set two, one expires immediately and the other contains some complex data. PhantomJS can handle that easily (as it is just Webkit + QT) but traditional tools do not.
> The Referer header is just one more thing
> that a sophisticated attacker will spoof.
Of course you could make it very precise by using a lot more data points for each user: where users usually go after which URL, how long do they stay on each URL, how many requests do they usually make, do they have your cookie, how long, etc. And I'm talking about cookies as a sign of a user, who already visited your website in the past.
- Like mentioned above; banning IPs / IP-ranges originating from countries normally not associated with traffic to the site (i.e. build a statistical knowledge beforehand)
- Simple request counting, per ip, and IP-ban users who are overly active (again based on the sites statistical profile)
- More advanced request counting, trying to create a fingerprint of the users behaviour (time between requests, etc) - and comparing this to the sites average fingerprint.
- Keep a global request-per-time-count and use this to measure the current load of the site - the mitigation techniques will only be activated if the site is under heavy-load / attack.
Any other ideas?