Just to update on how this continued to unfold, following a detailed response by the OpenTofu team, this is the official statement by Matt Aasy the author of the article, apologizing and acknowledging that he was wrong to rush to conclusions:
Bad idea. I agree with others here saying that this is not enough to change minds at this point (either direction) but I think that SM platforms are in no position to censor news content from a trusted publication.
They should focus their efforts elsewhere. All of this feels like a publicity play to help with their current situation, which is yet to be resolved.
Good point but the release may not impact their license (OS and premium/business use option).
I hope they reach the goal. Amazing to see that this was a one-man-show
Couldn't agree more. One-size-fits-all approach to education, backed by "do as I say or else..." mentality, is outdated. We personalize everything, from cars to ads, we should be making the same effort to create options for kids to maximize their ability to get the most out of the education system.
Unbelievable, they enjoyed year of free publicity from association with him, and this is how they repay him. Its bad enough that they couldn't handle the attack, despite all the bragging about their multi-Tbps capacity...
Unbelievable, they enjoyed year of free publicity from association with him, and this is how they repay him. Its bad enough that they couldn't handle the attack, despite all the bragging about their multi-Tbps capacity...
Sorry but I have to disagree.
I have no prior experience with them, but in this case they very extremely responsive and banned the accounts in less than 48 hours.
I wish other companies were as decisive when dealing with "stressers"...
This comment is better than 99% of the media coverage I've seen so far. Who announces a crucial SSL vulnerability that affects Twitter, AWS, Steam, Yahoo and Dropbox without notifying them first? They are making a name for themselves by exposing private information of millions of internet users.
Also, I find it interesting that the vulnerability was discovered by Google's researcher and some of their main competitors weren't notified about it.
Love DDG but discovering your UA on SERP like that isn't very useful. If you're someone who needs to know your own UA, you`ll probably need it several times a day or more. Searching for "user agent" is the long way to do it, there are browser extension for that. Still, nice Easter Egg from the best Duck in town.
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.
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.
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.
This is a very good explanation but there is another side to this issue. (I`m talking about HTTP DDOS)
Basically, DDoS Attacks can be (roughly) divided in 2 categories:
1. Attacks on your server (which usually target your server IP or some other part of your network infrastructure)
2. Attacks on your site (which use bots to flood your site with fake HTTP requests)
As explained above, Network attack can only be countered with strong and flexible infrastructure. The most common solution is a combination of several high-powered servers and load balancing capabilities.
HTTP DDoS attacks are trickier because they're best mitigated by visitor profiling, a technology that can help identify bots from humans and block them while still allowing providing full access to all legitimate visitors.
Developing and maintaining such technology is arguably more complicated, simply because it's a software you need to create, not a hardware which you can buy.
Standard profiling solutions include CAPTCHAs and Delay Pages but these will also repel legitimate visitors. (because no one likes CAPTCHAs or waiting for 5-10 extra seconds for page load).
Advanced profiling solutions use a combination of behavior and signature recognition, coupled with seamless challenges (i.e. checking for JS support).
CF and Incapsula (where I work) both handle Network DDoS in a similar manner but we have a somewhat different approach to HTTP DDoS.
And yes, while under DDoS (or even without it), dynamic resources can be the "weakest link".
This is why WAFs are so important.
https://twitter.com/mjasay/status/1778454498664690108