Until hackers figure out your new domain and attack it again.
Cloudflare has an “I’m under attack” mode for these situations. It does the Javascript challenge, not the captcha. It’s extremely effective for stopping automated attacks, without the user hostility of captchas.
That’s racist. You’re banning people by the billions because someone in their country is doing bad things.
You can’t mitigate a DDoS attack with PHP or Javascript. Javascript is executed in the browser and is typically not run by the attacker. And the PHP code itself would generate more load on the server than the DDoS attack would generate otherwise.
Many people from many countries can host a DDOS attack. But why being specular and racist. DDOS attacks come from the USA also, why not block that too, huh?
From which country most of the attacks come
does not mean that the state has something against you
rather it is the country with the most infected devices from there (botnet) controlled by someone from a completely different country.
In emergencies it is okay to block a country (and I assume the OP meant that)
because you don’t have time to analyze every ASN from China (or some other country) and there are hundreds of them
and then put the block only on ASN…it just takes you days and that’s not an option.
Great, use cloudflare on your domain. I have cloudflare on my domain, but not on my free subdomain because I can’t.
How do I go about blocking the IP address if it is changing?
Lastly, how would I implement a captcha and which one would you suggest?
EDIT: Would putting Require all denied in my .htaccess file block anything? Domain: smslaunch.epizy.com.
the best defense is if the attack doesn’t even touch the origin
if it attacks origin then there is really no help
because every REQs your hosting has to serve
and then it doesn’t matter if you have a reCAPTCHA or .htaccess block IP or IP range
because the purpose of the attack is to disable the normal functioning of the website.
The attacker doesn’t care if he sees the 404 page, or the text “blocked”
when it has already achieved an effect
this will block the display of the content of your website
does not mean it repel an attack
and I think it still counts as a hit
what you mentioned in previous posts is more useful if you want for example to prevent a brute force attack on login.php (unnecessary use of CPU and other resources) or some other file/path, also against spam.
It’s another thing when you have something between the visitor and the hosting (origin)
for example Cloudflare, then the CF can decide whether to allow traffic to your origin or block it.
CF has one advantage because it covers millions of domains
and their AI then easily learns to recognize the attack and quickly take countermeasures
For some basic actions on CF you can be guided by this
The problem is bigger when infected devices can store cookies and execute JS
and that trend is growing
For example on my CF 20% of unwanted traffic successfully passes the JS challenge
so there is no one rule that would cover everything
You need to have a few rings of defense
and know your website and its weaknesses and then well configure FW and the rest.
Layer 7 botneta usually have methods that bypasses thw captcha or the im under attack redirect. They can easy make cloudflare think they are a valid header
If the attacker knows your site is hosted with us, it’s also easy to bypass. All the attacker needs to do is lookup the origin IP from our nameservers, update a hosts entry and now the traffic is directed directly to your hosting account and away from Cloudflare.