banned IP’s consequences
-
What happens when an attack comes through a public-facing proxy/firewall, etc. front to potentially large number of users/customers? Just putting it on a deny list in
.htaccess
is denying access to a lot of people, no? How to handle this? Thanks.
-
BTW, don’t seen any IPv6 IP’s banned. Just coincidence?
1. IPv6 banning is in the next release.
2. What suggestions do you have to prevent ip addresses of proxied networks being banned?2. What suggestions do you have to prevent ip addresses of proxied networks being banned?
I’m not knowledgeable enough to give a meaningful technical suggestion. From an admin’s point of view though, think would be helpful to provide additional data to challenge the automated decision, and a button to become able to revert it.
For example, when I noticed the htaccess list growing, got looking up on each banned IP for their country of origin, trying to discern if coming from somewhere where most of our customers are, or was it from some ordinarily hosted IP, or if it looked like too important to keep it banned. Perhaps, getting a banned table already containing their respective countries, a link to an useful public resource to learn some more, and a button to eventually unban each of them, would make of an useful feature to mitigate potential over-banning. If you prefer to keep the minimalist approach of Pareto, then perhaps getting htaccess with at least the origin country near the IP’s, like
123.123.123.123 #<country>
, would suffice. Just my 2c.Thanks for the suggestions. Will look into it. BTW, one aspect of your suggestions, there is a way to delete individual IP addresses already via the log window in the admin settings.
2. What suggestions do you have to prevent ip addresses of proxied networks being banned?
Following up. Recently have enrolled with Cloudflare (Free) and learning about the various tools they offer to protect websites. Think a “softer” yet elegant alternative to IP-banning would be presenting a challenging question that requires a manually entered response to continue. Or as CF defines it:
Challenge Passage – when a visitor has a bad reputation with Cloudflare, they will need to complete a challenge. There is a pre-defined time the challenge expires, and a new challenge will be issued.
What do you think?
There is a difference in doctrine between someone having a reputation and an unacceptable HTTP request. The first is based on the reputation of an IP address, human errors, etc, the other is based purely on the request itself.
The trade-off is that the latter method can result in the odd occasion in an IP address being blocked that is used by multiple users, because of the actions of a single user in making a malicious request.
In the former method, noone is fully blocked, but a lot of people can be inconvenienced by having to continually fill out recaptchas because for example, they are behind a proxy, use VPN or Tor to access the internet, all of whom eventually end up with bad reputations.
What Pareto Security does is it bans the last 500 IP addresses, so once IP address 501 is banned, the first IP that was banned is unbanned. This is because it is not about making up a blacklist of IP addresses because that doctrine I believe is a flawed one, it is about temporarily banning an IP address to slow down the chances of an attacker sending the same request over and over again.
Perhaps one addition that could be made to Pareto Security is the ability to drop that limit from 500 ip addresses to a lower number, something for me to think about.
Interesting, thanks for the explanation. Is that 500 number statistically significant, or just a cut-off to save from server resources?
IMHO, even 500 feels kind of futile if a site has to take a coordinated attack from a large distributed network, probably commanding infected computers from all around the world.
Anecdotally, these days learned the hard-way how my online banking blocks IP’s by time (2h) when they may find something they don’t like (in my case got blocked by some setting of Vivaldi browser, as they explained it creates too much requests at once during login and their sec doesn’t like that). Was pissed off nonetheless, but their approach still feels more flexible and granular than waiting for 500+ IP’s to recycle and release, especially if a website is not that busy.
500 is the point at which an IP address list via .htaccess can start to have the slightest affect server performance. Keeping in mind that other plugins can add 500+ lines of entries as well. For most users then of PS, the 500 IP addresses works out to be about 1-2 weeks of blocking of any given IP address.
This number could now be increased to 1000 due to modern server systems being of much higher spec.
As for coordinated attacks/DDoS attacks, blocking those is not really the expressed purpose of this plugin, those are best blocked at the border, not by the time PHP is being executed.
The difference with banks is that their algorithms are purposefully over sensitive for obvious reasons, and so they unblock more because the false positive rate is very high.
With Pareto Security, there is NO ambiguity with the grounds for why an IP address was blocked. It will have had to have attempted to exploit the site code.
For most users then of PS, the 500 IP addresses works out to be about 1-2 weeks of blocking of any given IP address.
Hmm, that isn’t the case for my scenario. Have a been a PS user for 1+ years and my list is still below 200 IP’s atm. If 1-2 weeks of blocking is enough, then perhaps expiring by time would be appropriate as well?
As mentioned, there is no real reason to expire IP addresses from htaccess unless the list is too large, which can hamper the performance of Apache. This is because this plugin only adds IP addresses that have attacked your website code.
You can manually remove IP addresses if you feel to by resetting the plugin which will remove them all, or via the log screen, remove ip addresses that are displayed there.
- The topic ‘banned IP’s consequences’ is closed to new replies.