We crafted a few mod_security rules to limit all traffic to the admin logins to popular apps like WordPress, Joomla, PrestaShop and phpList except for traffic from specified countries. We have a few sets of these to cover common groups of countries (like, US only, US and CA only, US and UK only, etc.). These rules are our biggest deterrent to brute force by far. They are not a source of false positives. They turn any hit into near honeypot certainty that the IP can be black listed and not even grey listed. They cut down brute force attempts by somewhere near 80%. However, it's a bit of a headache to configure (turn off or change for various users when they travel) plus we'd like to see it expanded to include cPanel and WHM login ports as well (we have been completely unsuccessful in writing rules for this as it seems these ports are not addressable via mod_security).
Please refer to the answer in p. 2
Could this game changer be implemented as part of imunify360? In our preferred implementation we'd love to see:
A cPanel and/or WHMCS plugin where users could configure:
1. Apps they'd wish to include (tick boxes?): WordPress, Joomla, Magento, PrestaShop, phpList, Drupal, WHMCS, etc.
Should this module provision these frameworks to a customer or enable mod_security rulesets related to the chosen frameworks ?
2. Interface similar to Firewall->Black list->Add->Add Country box except it would be to enable login access from selected countries (not a white list just not black list by default).
We have created a task with internal id DEF-3539 to develop this feature
3. Ports to include similar to Firewall->Blocked ports->Add Port so that the deny all with exception could be setup for cPanel, WHM and any other custom service as well.
We have created a task with internal id DEF-3356 to redesign port blocking
4. Optionally, allow for server admin to set the default action to either Grey List or Black List in Imunify360 settings.
The default action in Imunify360 is always graylisting - by design. This is contrary to Imunify360 black list which is always local and manual-only.
5. Optionally, it could allow for IP addresses to be added (including CIDR ranges) which would free us up from having to write .htaccess files for some clients who are having particular problems or need a more robust second or third factor as is the case with ecommerce admin access.
It is already possible to blacklist single IP, subnet or even the whole country. However, blacklisting works server-wide, so you cannot create such lists only for specific customers.
6. Optionally, brute force functionality could be added in the future for the allowed countries limiting login attempts by IP, username misses applied to IP etc.)
Bruteforce (DoS) protection is already in the product. However, it works on the transport (TCP/UDP), not the application layer.
7. Optionally, block XML-RPC WordPress requests as well.
XML-RPC attack mitigation is already a part of Imunify360 mod_security ruleset
Handling all of this on the level of the firewall is so much better than those pesky, resource intensive app plugins and custom .htaccess files.
Note: We would add that it seems that the Geo IP Database that we (and nearly everyone else) use seems to be vastly different from the Geo IP Database that you employ for country blocking. It is very incorrect. It seems to be vastly different from the Geo IP Database used to display the flags in the incidents window. This would need to be rectified to have this work out.
Imunify360 uses GeoLite2 Free MaxMind engine for Geo IP (
http://dev.maxmind.com/geoip/geoip2/geolite2/). Is it different from what you use?
