[Feature Request] Allow WordPress and Common App Admin Access from User Definable Countries Only

[monitorlinux]

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, its a bit of a headache to configure (turn off or change for various users when they travel) plus wed 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).

Could this game changer be implemented as part of imunify360? In our preferred implementation wed love to see:

A cPanel and/or WHMCS plugin where users could configure:

1. Apps theyd wish to include (tick boxes?): WordPress, Joomla, Magento, PrestaShop, phpList, Drupal, WHMCS, etc.

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).

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.

4. Optionally, allow for server admin to set the default action to either Grey List or Black List in Imunify360 settings.

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.

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.)

7. Optionally, block XML-RPC WordPress requests as well.

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.

[apb]

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, its a bit of a headache to configure (turn off or change for various users when they travel) plus wed 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 wed love to see:

A cPanel and/or WHMCS plugin where users could configure:

1. Apps theyd 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?

[apb]

> 1. Should this module provision these frameworks to a customer or enable mod_security rulesets related to the chosen frameworks?

If I understand your question correctly it would apply the frameworks to the cpanel user (customer) because all of this cant be done with mod_security rules.

Ive attached an outline which may help in understanding the interface

[apb]

Forgot to answer this:

> Imunify360 uses GeoLite2 Free MaxMind engine for Geo IP (http://dev.maxmind.com/geoip/geoip2/geolite2/). Is it different from what you use?

No, thats what we use but when we block a country in " country, black list" IPs from that country can still show up "incidents" (see case: #19616) If you use the same database to apply "black" list as the "flag icons" on "incidents list" then this would seem impossible.

[apb]

> Ive attached an outline which may help in understanding the interface

I have added this outline to task DEF-3539 for further consideration

[steven]

I would like to add a thought to this thread. You state the following for #5:
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.

How about developing a imunify360 apache module (similar to mod_sec) that can determine which vhost is being accessed by the IP and then run the block rules for a country or what ever the user blocked. This would then not be server wide, as the apache module would know not only the IP but what URL/vhost is being accessed and apply the correct logic for blocking. Some code for this for example can be found here: https://github.com/maxmind/mod_maxminddb

[steven]

The way we do it now is, in an increasingly unwieldy way, is to:

Create a mod_security rule for a country combination and then exempt all users without that case from that rule. So if a client wants to access WordPress admin area from PE and the US we have to block that user from say, "US and UK" and "US and CA", and "US only" rulesets then write a rule for "US and PE" adding the new user case to that rule and then removing that ruleset for everyone else.

For IPs we just create an .htaccess rule. It works fine on a test production server with a handful of users but not something we can rollout to regular production servers