Hi,
The cPHulk feature is pretty good, but it does not make blocks in iptables, it only manages access to a service. This makes it, in my opinion, not very powerful. I prefer using methods that are inclusive to all services. IE: If you get blocked for trying to brute a cPanel login I don't want you on my website either. cPHulk also stores its data in mysql which to me makes it far too likely to become corrupt. If your server is being attacked by a flood of bots causing mysql to crash while the table is open then it is likely that the table will be marked as crashed and the data not available.
CSF actually has a feature that allows you to block IP addresses based on country code, however it is utterly useless for a VPS. The reason for this is that the massive number of iptables rules that are placed cause iptables/CSF to crash. I have a script that matches IP's found in domlogs against those in stopforumspam.com's RBL and have noticed iptables starting to throw errors at around 7k blocks. The error that I see in this instance is something like "iptables: Too many levels of sybolic links". KH-Jonathan told me before that blocking by CC would not work and cause iptables to crash before I tried that, but of course I had to test it for myself. On a server with 2.5G of RAM and 4 2GHz processors CSF started crashing after about 1 hour. Chksrvd never could get CSF back up. Removing the CC block immediately solved the issue. Those were the results of my test. Seems like the default of 100 max deny rules in CSF is there for good reason.
While I understand the alarm caused when seeing all of the alerts generated by CSF (especially the high number that are concentrated from one region) the fact that you are getting those alerts means that the firewall is doing its job. Even with a large number of ip's to burn through the amount of time that it would take to brute force a strong password when getting blocked on every fifth try is way up there. For basic site traffic there are other ways of handling this. Here is my short list of proactive steps that you can take:
1. Use CloudFlare. Targets for bot networks are normally found using techniques that rely on DNS (Google dorking and such). CloudFlare blocks much of this traffic at
the DNS level for you.
2. Of course use good access control in your coding. Using rewrite rules, allow/deny directives etc. Redirecting or denying traffic that should not access a script such as
wp-login will go a long way in saving resources if you are swarmed by a bot net. If you only use wp-login for administrating a site and don't have customers logging in
through it then it should be locked down to only the admin's address on the webserver level using .htaccess.
3. Use modsec if access control is especially important to you. While this does add another layer of complexity for the administrator it may be worth it to you.The downside is normally accidental blocks and false alarms. Usually things like google bot can cause false alarms and/or get blocked unintentionally. Reading up on
modsec and carefully planning for welcomed bot traffic such as google bot and any bots that may be performing analytics for you is important. There is a free plugin for WHM at
http://configserver.com/cp/cmc.html provided by ConfigServer. It integrates with CSF firewall and will create perm blocks based on recurring modesec infractions.
4. Check into CMS plugins that can be used to combat "bad" traffic.
5. Use cPanel's Host Access Control or for terminal junkies go straight to hosts.allow and control access to services there. If you are the only one that should be accessing WHM then don't give anyone the opportunity to even try.
http://docs.cpanel.net/twiki/bin/view/AllDocumentation/WHMDocs/DenyAccess.
6. If you don't use it, turn it off. I don't use FTP, so I don't run an FTP daemon. Since I am the only person with sites on my server cPanel accounts don't have shellaccess. I can work as root. Some may call that taking the name of root in vain, but it is my preference. I leaves me with only one ssh account that requires a key.
7. Use shared keys for SSH. Password protect them.
8. Use strong passwords. You would be amazed at how many people use things like "bobby123" as a root password for a VPS with 300 sites on it. That is not an exaggeration. I use
http://www.random.org/passwords/ to generate passwords.