To block something like this you need to determine what is botnet traffic vs legit traffic. It's hard.<p>Source IP doesn't work since it is random and changes. You need to look at things such as HTTP headers, TCP window and any odd flags that might be set. If you're lucky the botnet isn't capable of running a copy of Chrome or Safari or using a random sample template from legit traffic. Lots of botnets are made up of low power IOT devices so once these devices are capable of running a full headless chrome it will get harder.<p>Not to mention when you do figure out how to discriminate traffic you have to code it. And the code to determine valid traffic vs invalid better run fast because you are getting hit with 100k requests per second. Oh did I mention the attacker can change their algorithm whenever they want? Hope you have a full tensorflow ML/AI pipeline that configures your hardware based ingress of choice just in time. All this while making sure your current production traffic is being served at a speedy pace and not blocking legit customers.<p>These are some of the issues Cloudflare and companies like them have to deal with.
20 million requests per second from a single beefy AWS server is easy to detect and block.<p>20 million requests per second coming from a rotating list of hosts from generic IP addresses is a nightmare:<p>> However, we suppose the number to be higher – probably more than 200 000 devices, due to the rotation and absence of will to show the "full force" attacking at once.<p>If your site normally has 10,000 users per day and suddenly you’re flooded with 200,000 additional IP addresses hammering at your site, you have a problem.<p>To put it in perspective, the top post on HN most of yesterday was about someone benchmarking their personal server as being able to handle about 5 million requests per day (Granted, that’s quite slow, but it will suffice for making a point). This botnet can deliver 4X that server’s total daily capacity every second.
Original link: <a href="https://blog.qrator.net/en/meris-botnet-climbing-to-the-record_142/" rel="nofollow">https://blog.qrator.net/en/meris-botnet-climbing-to-the-reco...</a>
From the article:<p><i>What to do in such a situation?<p>Blacklists are still a thing. Since those attacks are not spoofed, every victim sees the attack origin as it is. Blocking it for a while should be enough to thwart the attack and not disturb the possible end-user.</i><p>Missing from the article: Links to lists of IPs that they recommend to be blacklisted. It's the same thing that's missing from pretty much every NetSec vendor.<p>We really need a recovery clinic for compulsive threat-data hoarders.
Here's a merisbot-detection script for real-time usage; it can filter attacks in real-time:<p><a href="https://github.com/craig/merisbot-detect" rel="nofollow">https://github.com/craig/merisbot-detect</a><p>Hope this helps.
"Connect to cloud by default" should be banned in any sensible network.<p>It's probably even more devastating that "default password by default" if exploited successfully.<p>A single stolen cert, or access to the device provisioning server instantly gets you "keys to the kingdom," and all of the devices online.<p>A default password, or a vulnerable API on the device, in contract, will still need the attacked to individually find, and hack each vulnerable device.
In other words, this entire botnet can perform the work of... a few dozen decent size AWS instances?<p>We used to push ~million request per second from each m4.10xl instance when running load tests.
Interesting name. "Mēris" in Latvian means "plague". I wonder if it is on purpose. Too lazy to read the article or look up, though.