Mēris botnet, climbing to the record
blog.qrator.net
blog.qrator.net
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.
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.
These are some of the issues Cloudflare and companies like them have to deal with.
E.g.: the handshake can be made more expensive choosing a "harder" function for the handshake and giving clients that behaves "good" the possibility to reuse the connections. Bots are penalised because they constantly have to make new handshakes.
But the economic incentives of a botnet are very different from those of a bot farm.
Can you manage as many TLS handshakes as they can throw at you?
The compromised hosts that are part of the botnet look exactly like normal traffic.
* Port 2000 open
* Port 5678 open
* SOCKS proxy on port 80 (maybe)
Most likely most of the visitors to your website won't have those ports open and exposed to the Internet. That is a really easy way to filter traffic based on the network fingerprint. Especially when you're under attack it's a great way to reduce a majority of the impact without requiring any AI/ ML - just filter traffic from IPs that have TCP port 5678 open. That same technique was also used to identify Mirai bots and it worked well.
But the problem that still exists is the initialization traffic -- there are still up to 200k hosts that may hit your site (essentially, a syn flood). Depending on your infrastructure, that can still hurt your firewall or single server. But it is unlikely to hurt as much as having to actually respond (through a request stack) to those requests.
20 million requests per second coming from a rotating list of hosts from generic IP addresses is a nightmare:
> 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.
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.
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.
Although I really need to commit the final version as that one isn't quite what I use.
Given the amount of misinformation in infosec, we should not be linking to intermediate sources for this kind of story.
HTTP Pipelining: instead of simplistic one-request-one-resource requests to a server the botnet supports HTTP 1.1 pipelined requests. A single request can ask for multiple files meaning even more demand on target servers. Request resources not cached in memory can see the server eat up its IOPS trying to read files.
Otherwise the bullet points are about the functionality in place in the infected clients. The port is likely a detection metric for infected clients.
What's different about this attack is that it appears to not be PCs but network devices (routers) that are being taken over and used to launch attacks.
People are much less likely to catch that this is occurring and as a result there's concerns that this botnet is going to persist as a threat for a much longer time than is typical. Additionally, network devices may have access to a greater amount of bandwidth than a PC increasing the threat.
One more thing: when the botnet makes a request (attack) against a site it's using a modern performance optimization technique of "pipelining" where instead of a GET to "/index.html" just interacting with the index.html file it's holding a connection open to also then request all the other assets from the site. In normal usage this is great as it makes a site feel more responsive and reduces network overhead. However, in the context of this botnet it also increases the number of requests that each bot can make (which is bad).
I wonder what should happen to that fine company to make them stop running all the potentially vulnerable system configuration services on all interfaces by default. IP > Services is one of the locations anyone should check ASAP to make sure unneeded ones are disabled, but it's actually misleading. These are just preconfigured wrappers for some components, and others, like DNS or bandwidth test server mentioned in the article, are not shown even if they are running. There isn't even a netstat-like command to check which ports are open.
1. While reaching a record number, the attack against something on the scale of Yandex and Cloudflare is more of a maximum capacity test not limited by target's connectivity, and/or an advertisement for someone's DDoS services.
2. Still, it's an application-level DDoS, so you have to have a swift application-level detection in place if you don't want to just ban IP addresses (and potentially cut legal users from HTTP(S) APIs and other services that might be shared on the server or network).
3. Some skill was demonstrated in finding no-trivial weak points to amplify the server load.
What to do in such a situation?
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.
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.
We really need a recovery clinic for compulsive threat-data hoarders.
https://github.com/craig/merisbot-detect
Hope this helps.
It's probably even more devastating that "default password by default" if exploited successfully.
A single stolen cert, or access to the device provisioning server instantly gets you "keys to the kingdom," and all of the devices online.
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.
We used to push ~million request per second from each m4.10xl instance when running load tests.
A botnet is probably coming from hundreds, if not thousands of IPs, sprinkled in with normal user requests and often with similar frequency.