Table of contents of the article:
In the last two weeks, some of our customers have also been targeted by what seems to be a trend destined to spread more and more, DDOS attacks to follow ransom demands in Bitcoin in order to end the attack.
What seemed like a sporadic case in fact that first hit the site of one of our customers, in the following days proved to be a recurrence, having in fact had to deal with 5 DDOS Layer 7 attack attempts and as many extortion requests and payments in Bitcoin.
In fact, comparing ourselves with our Webmaster customers and other Hosting operators, we were able to see that the trend of these attackers is steeply rising, having had confirmation of the same modus operandi with even the same amount to pay if you wanted to stop the attack, or 250 € in Bitcoin.
You can find in the photo below the threatening email with the ransom note:
As can be seen from the address of the Bitcoin portfolio, it is the same hacker who attacked another site of one of our customers trying to extort the same amount and even complaining that the manager (that is, we) was limiting the attack by excluding some attacking countries where presumably the attacker had large botnets and was able to generate a very high number of GET and POST requests to our client's site , causing a down which in technical terminology is defined as Denial Of Service or more simply DOS.
Hello,
I currently notice that your manager continues to obstruct me by trying to block incoming requests from other countries. Currently only Italy has access to your website. Which is a rather annoying thing for you, given that according to some of my research, your audience does not only embrace Italians: in fact 20% of visitors to your site DO NOT come from Italy.
What I recommend is to show this e-mail to your manager and let him understand that I can very well "play" with its poor protections (geoblock, ipban, recaptcha, jschallenge).For the rest I wish a good job NOT as always, and I am waiting for my sum of € 250 in my BITCOIN wallet at:
1HHFxKeVk35FCnd36bV7LYyk3CNT6avFRT
I require a response within 24 hours
PS: Cloudflare is useless to disguise the server IP: (78.47.XX)
I can easily find the backend. But I don't need it yet. I just stick to the frontend. Good luck!
The message was sent to us directly by one of our Webmaster customers via Whatsapp as you can see in the following screen:
Some hypotheses on the identity of the attacker.
The two messages, both the first and the second, seem to be written in perfect Italian, therefore it can be assumed that the attacker is Italian or at least mother tongue Italian. This is obviously not certain but it is reasonable and peaceful to think so.
Surely the fact that he explicitly asks for a payment by mentioning the Euros rather than dollars makes us even more think that we are facing a European striker almost certainly Italian.
The amount required while it may seem low, is an intelligently weighted cost, not too high to ignore, nor too low compared to the mitigation cost of a DDOS. Probably it is a well-weighted extortion that could invite the attacker to pay the indicated sum in order to see the DDOS attack cease and have the site online again.
The type of attack.
The attack launched is a Layer7 attack (at the application level therefore) focusing on the flooding of GET and POST requests to the victim site.
The source IPs had global geolocation with international and European countries, including Italy. The attack had many ADSL consumer providers so it is assumed that the alleged botnet was actually nothing more than a legitimate browser redirect of real users.
In fact, not being simple and trivial requests of the GET and POST type implemented by the "usual" toolkits of the Sunday hackers, they were able to overcome the challenge mode of the mode UNDER ATTACK by CloudFlare, our valued partner in DDOS mitigation.
This essentially means that the client making requests to the CloudFlare were able to execute Javascript code, given that CloudFlare's browser validation technology foresees a challenge (a resolution of a mathematical problem) through the Javascript interpreter of which all browsers are provided but very few or no tools to carry out the flooding of GET or POST requests.
Many requests came from referrers such as reddit.com, baidu.com, yahoo.com and similar, as you can see in this following screen by going to filter directly in the log of the webserver NGINX access.log
Don't give in to blackmail and never pay the ransom.
Although a down can be worrying due to the loss of income even in the short term (let's just think of the lack of monetization of advertising advertisements, banners or simple lost sales) and the sum to be paid, all in all, economic, we must always remember that giving in to blackmail means being from now available to be personal "ATMs" for the attacker.
If you pay once, be prepared to pay a second, and then a third and so on. You will always pay, because you have already done it once and you will be considered psychologically weak and always a person inclined to pay and to be blackmailed.
You must never pay or give in to blackmail, rather contact competent and qualified personnel like us to solve the problem once and for all.
In these cases the rule is simple: never bleed in front of sharks.
What is CloudFlare?
CloudFlare is reverse proxy with CDN (Content Delivery Network) functions. In practice, it is a server that interposes itself between the server where your site is hosted and the visitors, also performing caching functions, further speeding up the performance of your site. It is not limited to the distribution of static content (like a normal CDN), but offers numerous features to increase security, optimize a site, speed up DNS and protect against DDOS attacks.
When a request arrives from a user, CloudFlare (in a minimum amount of time), check first if the visitor is trustworthy, and if so, after taking the static contents (images, css, javascript) from the cache, it returns them to the visitor himself.
Leaving aside the functionality of CDN and optimization of content delivery through minification, webp image conversions and much more, in this article we will focus on using CloudFlare in order to mitigate a DDOS attack.
How to mitigate a Layer7 DDOS through CloudFlare?
The first thing to understand about level 7 attacks is that they require a greater understanding of the website and how it works. The attacker has to do some homework and create a specially crafted attack to achieve his goal. Because of this, these types of DDoS attacks require less bandwidth to take down the site and are more difficult to detect and block.
The best way to stop a Layer7 DDOS is to use a security service like CloudFlare that working in reverse proxy, offers us some important features to filter the upstream traffic.
In other words, as you can see from the image above, when the attacker tries to contact our site (or its malicious traffic) he will have to go through CloudFlare which allows us through a pleasant and convenient Web interface of set up rules to filter malicious traffic and thus block it returning error codes 500 and avoiding that random or parametric requests can literally crash our web server, PHP interpreter or Database until it crashes.
To do this you can safely rely on CloudFlare which also in the Free version (therefore free) allows you to have all the tools you need to do intelligent filtering on different factors.
Subsequently, once the free plan has been confirmed, the intelligent DNS record scanning system will reproduce the current DNS ZONE of our current authoritative nameserver for the domain in question (in this case for example pippo.it) in order to find all the records of the ZONE on the CloudFlare nameservers.
IMPORTANT NOTE : Attention, the intelligent system of CloudFlare although very advanced it is often unable to locate “hidden” records such as third-level domains and the like and therefore it is always your task and care to make sure that all the useful entries of the current DNS ZONE are also reported on the new ZONE of the CloudFlare nameservers, taking care to add any records that were not found.
You will be faced with a list of records of this type that reflects (or at least should) your current DNS ZONE.
The orange bubble that can be activated or deactivated with a simple click of the mouse means if for the type of record in question CloudFlare must grant direct access to the IP of the real site, thus performing a very normal nameserver function, or if the traffic has to go through CloudFlare and therefore work in Reverse Proxy mode.
In the mode of Reverse Proxy, the browser of a possible visitor will contact the IP of the CloudFlare server and according to certain rules that we will see later CloudFlare will have the right to contact the customer's site or refuse the connection with an error code.
It is therefore reasonable if the webserver is attacked via GET or POST requests, to filter all the records that lead back to the webserver itself, as we can see below the bare domain name without www, the one with www and the relative ftp aware that very often the FTP address matches that of the webserver and by leaving the FTP IP visible, the attacker could trace the original IP of the machine that is currently behind CloudFlare.
The configuration would therefore look like this:
Subsequently, by advancing in the configuration and clicking on continue, CloudFlare will invite the user to change the current nameservers of the current REGISTRAR with those provided by CloudFlare itself.
In the image above, for example, CloudFlare invites me to replace the current authoritative nameservers alicom.com with the two of cloudflare.com preceded by a name that are often unique for each individual user account.
To do this you must normally have access to the control panel of your provider where you registered the domain and choose to replace the original nameservers with these new ones, only once the new CloudFlare nameservers have been propagated worldwide can you be sure that the web traffic passes through the CloudFlare systems and does not arrive directly to your site without any intermediary able to protect you and filter the malicious traffic.
IMPORTANT NOTE : The change of nameserver although it is an extremely easy operation, it is not an immediate operation. Changing a nameserver in many configurations it can take hours or even days. For this reason it would be smart if you care about your website to immediately replace your provider's nameservers with those of CloudFlare, obtaining, among other things, a much greater response speed to DNS requests and having the possibility of immediately be ready to activate the filtering functions if an attack occurs, without having to wait for the propagation of the new DNS and avoiding all the procedure indicated up to now.
A wealth-producing website should only use CloudFlare's nameservers as its nameservers.
Using CloudFlare.
Filtering a DDOS attack in general, and in particular a Layer7 attack on a website means first of all having a good ability to analyze the attack in order to understand what to filter through CloudFlare only the malicious traffic, letting only the healthy one pass.
One of the biggest reasons for failure in DDOS mitigation is about adopting the right tool (CloudFlare) but just activating the Under Attack mode thinking that by clicking the "I am under attack" button CloudFlare will be able to protect you by doing everything by itself. Nothing more wrong.
The under attack mode is in fact a system that thinks in a rather crude way, thinking that if many GET or POST requests arrive to the website, these requests probably come from attack tools installed on various botnets that pretend to be a web browser but are not actually a web browser.
It expects a client to be able to communicate on TCP / IP protocol, perform a handshake via SSL or TLS protocol to establish HTTPS communication and then continue flooding the victim target with requests.
What these attack toolkits normally don't have is a Javascript interpreter and therefore proposing a CHALLENGE (a sort of question) in Javascript to a client who does not have the possibility to solve it as it does not have a Javascript interpreter means that the client cannot provide the correct answer and thus earn a TOKEN (which usually lasts 30 minutes but can be increased from the CloudFlare settings) in order to be whitelisted and therefore reach the site.
We can easily recognize a site that has UNDER ATTACK mode enabled from an introductory welcome screen like the following one and with a waiting time of a few seconds, time to solve the challenge.
But what if the requests are not generated by coarse clients, but by real web browsers like Firefox, Google Chrome, Internet Explorer, Safari, which without their knowledge are diverted in a very high number to the attacker's site? It happens that their browser being a full-fledged Javascript browser will be able to solve the challenge, get the token and be able to flood the victim's site with requests.
At this point, therefore, we can no longer limit ourselves to keeping theUNDER ATTACK mode by CloudFlare without doing anything else and then complaining that CloudFlare doesn't work. You just don't know how to use it. It is not enough to have the tool to be masters but above all to know how to use it. This rule is valid in every field of life, especially in the professional one.
What to filter though?
What you need to do is understand how the attack is taking place, where the requests come from, what are the referrals, the countries, the providers, the requests, the URLs that are called in order to surgically identify the malicious traffic from that legitimate and let only the latter pass.
To do this we need first of all some experience in analyzing the requests that arrive at the Webserver by going through the log which is normally called access.log or access_log.
It is through the analysis of these requests that we can visually perceive the anomalies of malicious traffic and of the attack and go to filter this traffic.
To do this we have CloudFlare's FIREWALL module which allows us to use some parameters to filter based on conditions using logical operators.
For example we could check (match) the traffic through the country and decide to block all IPs coming from Brazil, Iran and Russia, or maybe connect only IPs that come from Italy, San Marino and Switzerland.
Or we could decide to connect all European IPs that do not have the reddit.com site as their referral, or to connect all European countries except clients that are searching on the site with the parameter in the URL? S =.
Although the CloudFlare Free plan allows you to define only 5 Firewall rules, the combination of them through the use of the logical operators AND and OR allows us to surgically define any pattern in order to decide whether to block it or let it arrive at our site.
The possibilities of use and the possible combinations in real scenarios are so many that it would be impossible to examine all the possibilities in this article, but it is good to know that through appropriate analysis and adjusting the shot with a pinch of intuition, experience and skill it is always possible to stop a DDOS Layer7 managing to keep up a site that otherwise would have inevitably gone down.
Using CloudFlare as an application security solution allows us to obtain the following very important advantages and filtering methods:
1. Browser-level filtering via Under Attack Mode
Through theUnder Attack Mode of CloudFlare it is possible to challenge the visitors' browsers to verify whether they are real browsers or simply HTTP / S traffic of artfully packaged tools to bring DDOS to the application level and forge malicious GET or POST requests. In this phase we go to discern the browsers of real users to the tools of the attackers by blocking the latter.
2. Referral level filtering
In this mode used in some types of attack through the injection of content on very busy sites, we can decide to filter the attacker by determining the referral. In fact, if the real user comes from a referral used as an attack vector, blocking the referral with appropriate firewall rules will also block all users who come from that referral.
3. URL pattern filtering
If a botnet decides to call specific patterns in URLs in intense mode or use parametric ones to bypass any cache systems, we can identify the pattern and block its access.
4. Filtering at the geographical level.
We can enable a type of geographic filtering at the GeoIP level that allows us to block or challenge connections originating from suspicious countries via the Under Attack Mode. For example, if our business is Italian or perhaps European, we may decide to block or challenge Asian, African, American, Russian IPs and so on.
The accuracy of this solution is greater than 99% and allows you to implement very aggressive and restrictive filtering policies if you are faced with an extremely complex solution to be solved immediately.
5. Filtering on Autonomous System AS
Un autonomous system (In English Autonomous System), with reference to routing protocols, is a group of router e networks under the control of a single and well-defined administrative authority.
Should we be attacked by Dedicated Servers hacked and used as zombies to launch the attack on our customers, we may decide to filter out all those connections that do not belong to suppliers that offer consumer DSL services.
Why should a Digital Ocean or AWS or OVH server make requests to our webserver where we may be hosting a sporting goods e-commerce?
Since there are apparently no reasons for this and an attack is underway, another possibility is to block known Datacenter Autonomous Systems that can be hacked and used against.
6. A MIX of the above methods in combo
The use of logical inclusion and exclusion operators such as AND and OR allows us to use all the previous methods described by using very complex logical conditions that allow us to be surgical in the application of filtering rules, excluding false positives and traffic legitimate by the filtering and dropping policies that follow.
7. SEO Oriented
All filtering operations are SEO Oriented, i.e. adequate not to block the legitimate crawling activities of the main Search Engines such as Google and Bing.
If you want our help and our experience to better mitigate a DDOS attack, do not hesitate to contact us.
