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.