This object is in archive!
World centralize sharing cPHulk Brute Force Protection IP database
Needs Feedback
Every WHM admin always get Large Number of Failed Login Attempts from the hackers. They use open public IP lists.
We can share this information across the world. By checking which IPs are often use to attempts login to many servers. We ban them for a whole day or week.
I like this idea 
cPanel, WebHost Manager and WHM are registered trademarks of cPanel, L.L.C. for providing its computer software that facilitates the management and configuration of Internet web servers.
This is an interesting feature to pose. There are definitely a lot to consider.
Based on what you're posing, the expectation would be for cPanel, Inc. to host this centralized database. Let me ask some questions as a result.
[1] Would you be willing to pay a subscription fee for access to this centralized database? This is not to say this feature would involve monetary fees. However, something like this may necessitate deploying a CDN and other infrastructure on cPanel's part. Knowing if the users requesting this feature would be willing to contribute to the involved costs may affect its consideration.
[2] To avoid abuse of the system, cPanel, Inc. would need to maintain control over who is listed, why, and when they are delisted. Are you okay with cPanel, Inc. maintaining this level of control?
Beyond that, there are just some basic considerations that I would appreciate some community comments on.
- How do you see/prefer false positives being handled?
- How do you see/prefer delist requests being handled?
- I assume you would expect this feature to be opt-in at the server level?
- Is it important to you to be able to also run your own centralized block list/database instead of only having the option to use cPanel's? (This would increase complexity significantly by requiring we build and package software to allow the list to be hosted).
Other items like that warrant further discussion. I'd like to hear more opinions and thoughts on this.
This is an interesting feature to pose. There are definitely a lot to consider.
Based on what you're posing, the expectation would be for cPanel, Inc. to host this centralized database. Let me ask some questions as a result.
[1] Would you be willing to pay a subscription fee for access to this centralized database? This is not to say this feature would involve monetary fees. However, something like this may necessitate deploying a CDN and other infrastructure on cPanel's part. Knowing if the users requesting this feature would be willing to contribute to the involved costs may affect its consideration.
[2] To avoid abuse of the system, cPanel, Inc. would need to maintain control over who is listed, why, and when they are delisted. Are you okay with cPanel, Inc. maintaining this level of control?
Beyond that, there are just some basic considerations that I would appreciate some community comments on.
- How do you see/prefer false positives being handled?
- How do you see/prefer delist requests being handled?
- I assume you would expect this feature to be opt-in at the server level?
- Is it important to you to be able to also run your own centralized block list/database instead of only having the option to use cPanel's? (This would increase complexity significantly by requiring we build and package software to allow the list to be hosted).
Other items like that warrant further discussion. I'd like to hear more opinions and thoughts on this.
This is an interesting feature to pose. There are definitely a lot to consider.
Based on what you're posing, the expectation would be for cPanel, Inc. to host this centralized database. Let me ask some questions as a result.
[1] Would you be willing to pay a subscription fee for access to this centralized database? This is not to say this feature would involve monetary fees. However, something like this may necessitate deploying a CDN and other infrastructure on cPanel's part. Knowing if the users requesting this feature would be willing to contribute to the involved costs may affect its consideration.
[2] To avoid abuse of the system, cPanel, Inc. would need to maintain control over who is listed, why, and when they are delisted. Are you okay with cPanel, Inc. maintaining this level of control?
Beyond that, there are just some basic considerations that I would appreciate some community comments on.
- How do you see/prefer false positives being handled?
- How do you see/prefer delist requests being handled?
- I assume you would expect this feature to be opt-in at the server level?
- Is it important to you to be able to also run your own centralized block list/database instead of only having the option to use cPanel's? (This would increase complexity significantly by requiring we build and package software to allow the list to be hosted).
Other items like that warrant further discussion. I'd like to hear more opinions and thoughts on this.
This is an interesting feature to pose. There are definitely a lot to consider.
Based on what you're posing, the expectation would be for cPanel, Inc. to host this centralized database. Let me ask some questions as a result.
[1] Would you be willing to pay a subscription fee for access to this centralized database? This is not to say this feature would involve monetary fees. However, something like this may necessitate deploying a CDN and other infrastructure on cPanel's part. Knowing if the users requesting this feature would be willing to contribute to the involved costs may affect its consideration.
[2] To avoid abuse of the system, cPanel, Inc. would need to maintain control over who is listed, why, and when they are delisted. Are you okay with cPanel, Inc. maintaining this level of control?
Beyond that, there are just some basic considerations that I would appreciate some community comments on.
- How do you see/prefer false positives being handled?
- How do you see/prefer delist requests being handled?
- I assume you would expect this feature to be opt-in at the server level?
- Is it important to you to be able to also run your own centralized block list/database instead of only having the option to use cPanel's? (This would increase complexity significantly by requiring we build and package software to allow the list to be hosted).
Other items like that warrant further discussion. I'd like to hear more opinions and thoughts on this.
Great to hear that this feature is powerful. I am not expert in technical.
[1] I think most admins don't want to pay for an extra cost of service since they already paid for the license.
[2] It's good that cPanel Inc. maintain the list because it's world centralized database for all cPanel customers.
In case it's really false positive, admin of each server can do whitelist/blacklist like the current cPHulk Protection. User can contact directly to the server's admin. A normal user have only a few accounts.
Ban the IP with interval steps such as 30 mins, 3 hrs, 3days, 3 months until those IP stop attack to many servers. And use some complex formula to analyze and delist. Most attacks came from open proxy and cable modem.
Great to hear that this feature is powerful. I am not expert in technical.
[1] I think most admins don't want to pay for an extra cost of service since they already paid for the license.
[2] It's good that cPanel Inc. maintain the list because it's world centralized database for all cPanel customers.
In case it's really false positive, admin of each server can do whitelist/blacklist like the current cPHulk Protection. User can contact directly to the server's admin. A normal user have only a few accounts.
Ban the IP with interval steps such as 30 mins, 3 hrs, 3days, 3 months until those IP stop attack to many servers. And use some complex formula to analyze and delist. Most attacks came from open proxy and cable modem.
One way to avoid false positives could be to use an IP for the global blacklist only if it was reported by over X (say one hundred) participants. So if you accidentally end up on the list yourself (e.g. 5 mistyped passwords on another keyboard layout), then you are not on that blacklist, as it would count only as one IP from one source.
One way to avoid false positives could be to use an IP for the global blacklist only if it was reported by over X (say one hundred) participants. So if you accidentally end up on the list yourself (e.g. 5 mistyped passwords on another keyboard layout), then you are not on that blacklist, as it would count only as one IP from one source.
Replies have been locked on this page!