Question Best Practices: Blocking A Large Number of IP Addresses

[tetrahall]

Server operating system version

Centos 7.7

Plesk version and microupdate number

Plesk OBSIDIAN 18.0.44

Hello,

I'm getting very suspicious visits from a large number of IP addresses - something like 3000 - 4000 on a daily basis. I've considered the following options:

.htaccess is an option, but I am advised against it because it slows the website due to processing overhead

Plesk Firewall Blocking Countries: It doesn't always work. For example, I had some suspicious IP addresses from Lithuania and Italy. I added LT and IT but it didn't work for me - still getting visitors from both countries.

IP Tables: It involved adding many "rules" and to be honest I'm not familiar with this method

I was just wondering if there is something more straightforwards, like a BLACK LIST, where I can copy and paste the list of IP address in some form field.

Please advise

 

[scsa20]

GeoIP blocking relies on a database to be up to date so some IPs assigned to a country could still slip by. Default database is by DB-IP but you can change it to Maxmind by following the instructions at https://support.plesk.com/hc/en-us/...urce-for-blocking-countries-in-Plesk-Firewall

As for IPTables, Plesk firewall basically uses IPTables anyways so you could technically block IP addresses by utilizing the Plesk firewall itself.

The other method is utilizing ModSecurity, you can refer to https://support.plesk.com/hc/en-us/...or-whitelist-specific-countries-through-Plesk for how to set it up.

 

[tetrahall]

scsa20, thank you for your reply.

I will try changing the database to Maxmind.

You mentioned "The other method is utilizing ModSecurit ..", but it looks like the same as blocking countries in Plesk's firewall, isn't it? And if one is to use IP addresses instead of countries, each address has to be entered individually.

I was wondering if there was a method where a list of addresses could be entered as a list - there are thousands of them?

 

[tetrahall]

In addition, one may need to block IP addresses from a certain country, not the country - some visitors might be genuine or useful, for example, Google from USA

 

[ChristophRo]

ipset is the way to go

can be used for (automated) geo-ip feeds as well as manually maintained csv/txt files with 100k+ IP addesses/subnets
and if you need to "whitelist" certain IPs, just put them in another ipset and put the ALLOW iptables rule for that ipset before the geo-ip/manual blocking

 

[tetrahall]

ChristophRo, thank you. This looks more like it.

I will try to learn ipset, hope it is not complex.

 

[tetrahall]

One last question, please:

Does/can it ever happen that the actual source of the visitor is from a country X, but when I check the country of the ip address I find it is from country Y?

In other words, can users fake their actual locations?

 

[scsa20]

Through a VPN sure, since it would be routed to the VPN service thus showing up that IP instead of their actual IP.

It's also possible that the IP was originally assigned for one country but was later reassigned to a different country so some IP look up tools will show one country whereas another lookup tool will show another.

Basically it's not going to be 100% accurate but it can overall help cut down noise/bad actors

 

[tetrahall]

scsa20, thanks a lot for your reply. It's very useful to know that.

I consider my post resolved now. But I cannot mark it myself.

All the best!

 

[mow]

I'm getting very suspicious visits from a large number of IP addresses - something like 3000 - 4000 on a daily basis. I've considered the following options:

Are those all from different networks or just a few rogue providers?
E.g. when I run grep "SASL LOGIN authentication failed" /var/log/mail.info |cut -f 5 -d ":"|sort|uniq -c, I get

...
   8580  unknown[158.94.210.39]
    177  unknown[158.94.210.86]
...

for which I block the whole net 158.94.210.0/24 because the provider lanedo.net is unresponsive and the attempts are still continuing:
route add -net 158.94.210.0/24 lo
and their other netblocks too:
route add -net 158.94.209.0/24 lo
route add -net 178.16.54.0/24 lo

 

[tetrahall]

In my case, they come from different networks and different countries,

 

[Kaspar]

I'm getting very suspicious visits from a large number of IP addresses - something like 3000 - 4000 on a daily basis. I've considered the following options:

What's suspicious about those visits exactly? Just their IP location or specific behavior on your site(s)?

If it's the later, why not create your own jail and filter for fail2ban and have these IP block automatically. (If you download the ipset action from the fail2ban repo you can even utilize ipset for blocking such a large number of IP's).

 

[tetrahall]

Hello again Kaspar

Thank you for your input. It is both, their ip addresses and the pattern of their visits. I know the normal pattern of genuine visitors.

You are right, as "ChristophRo" has already mentioned, ipset is the way to go.

The issue is now resolved. Thank you all very much.

 

[WebHostingAce]

This has become a daily battle for us lately.

From what you’ve described, it sounds very much like a botnet-style attack. I’m not sure who is behind it or what the end goal is, but in our case it mostly seems aimed at making the websites unavailable (resource exhaustion / overload) rather than exploiting anything.

What we tried first: Fail2Ban + ipset​

Our first approach was Fail2Ban with ipset. It worked for a while, but the blocklist quickly grew to 100,000+ IPs.
Then the attacker switched the User-Agent to a very common UA string, and at that point it became almost impossible to reliably separate attack traffic from real users based on UA patterns alone.

What finally worked: Cloudflare + Security Rules (JS Challenge)​

Our final approach was to put the sites behind Cloudflare and enforce a Custom Security Rule using JS Challenge (and/or Managed Challenge).

Cloudflare → Security → WAF → Custom rules

Rule 1 — Let’s Encrypt / ACME challenge (allow/skip)​

Expression:

• (http.request.uri.path contains "/.well-known/acme-challenge/")

Action:

• Skip → Skip all remaining custom rules (so renewals don’t get challenged)

Rule 2 — Traffic not from Australia (challenge)​

Expression:

• (ip.geoip.country ne "AU") and not cf.client.bot

Action:

• JS Challenge (or Managed Challenge)

This reduced the load massively, while still allowing legitimate AU traffic through normally, and letting known “good bots” pass (Google, etc.).

 

[WebHostingAce]

Is this an eCommerce website?

In our case, only eCommerce websites have been targeted. We have many non-eCommerce sites on the same infrastructure, and they are completely unaffected.

To write this post, I opened our Cloudflare dashboard, and to my surprise, within the last 24 hours alone, 51,000 requests were challenged by JS Challenge. Without Cloudflare in front, that volume would almost certainly have taken the this server down again.

 

[tetrahall]

No, it's not an eCommerce website. Thank you for mentioning Cloudflare. We will keep that in mind should the need arise.

 

[mow]

• JS Challenge (or Managed Challenge)

This reduced the load massively, while still allowing legitimate AU traffic through normally, and letting known “good bots” pass (Google, etc.).

cloudflare's challenge will also block legitimate users who don't have the most recent browser version installed or who block third-party scripts. Also, randomly API requests are blocked. And that's not counting the cases where cloudflare itself fails massively.

 

[WebHostingAce]

cloudflare's challenge will also block legitimate users who don't have the most recent browser version installed or who block third-party scripts. Also, randomly API requests are blocked. And that's not counting the cases where cloudflare itself fails massively.

I agree, but do we have any other practical solution to block 100,000+ IPs when we cannot reliably distinguish real users from attackers?