Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
Can the software ModSecurity defend from Brute Force Attacks on PHPmyadmin and WordPress as well?
A particular hosting company providing shared hosting told me that ModSecurity should cover PHPmyadmin and WordPress as well as their Admin area and Cpanel area.
Does it sound plausible to you?
mod_security sits in the Apache webserver to offer some level of security for applications hosted on that webserver. Assuming you're talking about shared hosting (as opposed to dedicated or VPS providers), there's no reason their mod_security installation wouldn't be able to protect against attacks against any application installed on their webserver.
That being said, mod_security is highly configurable, so you'd need to check that there's brute force protection for the login pages you care about, and you'll also want to check if mod_security is even enabled for those paths.
Also note that some mod_security rulesets (those looking for SQL injection) are likely to have a very high false positive rate on PHPmyadmin, as they'll look for strings similar to the SQL queries legitimate users might enter into PHPmyadmin.
cPanel already uses modsecurity with OWASP CRS that will do all you are asking and more, if is your own cooking then just add ModSecurity with OWASP CRS v3.0 or later as previous may have lot's of false positives and CRS 3.0 and later already have WP exceptions available and paranoia level 1 to reduce false positives.
For two of the installations I manage (so the more talented coders don't have to delve into more time-consuming server administration), I have some web-facing phpMyAdmin installs locked to IP addresses. When we first installed mod_security, we had the issue of phpMyAdmin triggering the SQL injection mechanisms, because that's how it works: it provides mass updates that change a lot of records at once, and typically not necessarily "safe" operations because it works directly with the database (because that's its job).
Our solution was to lock the installation to the IP addresses of the devs, but we still have an ongoing problem with bots scanning for phpMyAdmin on our server. Rest assured that unless they spoofed the IP address in the Apache file (which isn't impossible, but would take some doing), my bosses ultimately just turned off the SecRuleEngine for the main phpMyAdmin directory and relied on the IP address limitation combined with HTTPS (on a couple of the machines, courtesy of certbot).
While this shouldn't be "the" answer, it's at least a workable one that shouldn't leave you too exposed while you read up on options for mod_security. On my most-hit (but amazingly, least-compromized) Centos 7 machine:
<Directory /usr/share/phpMyAdmin>
<IfModule mod_security.c>
SecRuleEngine off
</IfModule>
<IfModule mod_authz_core.c>
<RequireAny>
Require ip xxx.xxx.xxx.xxx
Require ip 127.0.0.1
Require ip ::1
</RequireAny>
</IfModule>
<IfModule !mod_authz_core.c>
Order Deny,Allow
Deny from All
Allow from xxx.xxx.xxx.xxx
Allow from 127.0.0.1
Allow from ::1
</IfModule>
</Directory>
Just replace xxx.xxx.xxx.xxx with your own IP address, and it won't allow access to anyone that doesn't have that IP address. And yes, you can call it multiple times, as shown, for other IP addresses.
I'm sure a similar solution is workable on other *nix flavors.
As far as Wordpress, keeping the engine active will prevent SQL injection, but if you have a plugin that triggers it, it's probably because it's not using "safe" inserts such as PDO, and is thus very much more prone to SQL injection itself. I'd recommend disabling those.
But it shouldn't have a problem with installing Wordpress itself, provided the permissions are correct and things like SELinux aren't preventing access.
