Caleb

a) Remove the robots.txt stuff.. That is in most cases irrelevant. What will kill off the old stuff is the redirects, which will eventually make Google forget the bad URLs. After a year, that should have happened a long time ago. (Except, see b.)

b) Despite a), if your site still on some locations/pages/…show links to the bad paths, that means that GoogleBot will still find them. Over, and over, and over. So you need to figure out where these links to the bad area might still be appearing. Potentially the links section in Google webmaster can tell you. Or a search in your database. But pages are likely still containing or generating bad links and sticking them on your pages. Which causes GoogleBot to retry them over and over, while then hitting the redirect.
Removing the /hacked_foldername is not enough to clean. That just means that no one can actually get there anymore. It does not mean that you do not still have pages that point to that location.

b) If the Redirects show the hacked file in the URL, you did the redirect wrong in .htaccess. You probably have a “RewriteRule” line with $1 at the end or similar.. Otherwise, all the bad paths would redirect to a clean “http://homepage/”. The “hacked_file” part would have vanished, unless you have a redirect to something like “http://homepage/$1” or a different way of transferring the “hacked_file” part from the input- to the output-part of the redirect rule..

If only admin/editing screens are affected, then you could be seeing actual false hits in the firewall.. The “actions” taken in WordPress’ post-editing screens have a tendency to be blocked as unsafe in various blocking mechanisms.
Even using ModSecurity, I have to target-disable 4-6 “rules” in ModSecurity for such things as post.php, post-new.php to even function. Same or similar rules are for the most part also used in WordFence’ firewall. When using Opera data saving, the actions observed on editing screens could be seen slightly different from when going direct.
I have never tested with Opera.

Opera in data serving modes works by your local Opera browser no longer connecting directly to the sites you visit, but instead uses Opera owned servers around the world as proxies. In those proxy servers is where the various data/html/image transformations (data saving) happen.

In essence, the Opera proxy servers browse on your behalf, and they afterwards send the user’s browser transformed (compressed sort of) versions of the pages requested.

That of course can have various side-effects on a monitoring plugin, like WordFence.

For one, the visiting servers will be seen as crawlers. They do not behave like a human visitor would, or like a normal proxy-user would. The transformation is not a simple proxy server use, where there are a 1-to-1 relationship in both request and speed between what files the Browser and the proxy calls for. The data transforming servers actually interpret the whole page and makes independent loading and caching decisions.

Second, depending on rate-limiting settings, these servers can much more easily get caught up in rate limiting or even deemed to be scraper proxies, then blocked manually.
Read-ahead page loading, multiple users using Opera savings modes, and arriving through the same Opera proxy server. WordFence (and your site) could see them IP-wise as ONE visitor, not as separate visitors. Confusing the heck out of rate-limiting. Also, since rate-limiting blocks only for a “period”, the “evidence” of the failures by rate-limiting, so to speak, can vanish into the blue when the period expire. 🙂
What fails at some points or in some cases, depending on speed of browsing, can look to work perfectly when testing it later. Hence there is not necessarily a way to compare @wfsupport’s test with what site-local users are seeing. Maybe not in the busy timezone for this particular site, where they are more likely to see the accidental rate-limiting. Imaging a new tour group, for some reason more likely to have multiple Opera users suddenly visiting in bulk. Maybe sitting on similarly configured church/library computers looking at the “Bible tour” they are all going on. 🙂 All seen as one, if using Opera data-saving.. 🙂

Third, you can see visits from many “mysterious” places depending on where the particular Opera server chosen by Opera is located. Originally, most visits would be seen as “Iceland”, where they were located, but these days it can be sort of anywhere. A human Opera user in the UK, visiting his own site in the UK, have seen his own visits as coming from Nairobi, Kenya or similar odd places.

Fourth, as a side-effect of the above, the “visits” from local users might suddenly appear to be from a country that is otherwise blocked on the site, if some kind of country blocking is enabled. There is absolutely no guarantee, that the Opera servers doing the data transformation will operate out of the same country as your browser would with data-saving turned off. So Country blocking turns kinda useless when directed at Opera users. Or generally proxy users, which is really what Opera’s data-saving is.

BTW, This is principally similar to how Chrome’s Data Saver mechanism works for Chrome by running all content through Google’s servers (much more likely to be in the US probably).

@wfasa/@irisslesley,

It is not enough to merely change BLOG_ID_CURRENT_SITE to 3 to test the impact.
There are more changes to it, when moving the controlling domain on a multi-site.

In WordPress, ‘BLOG_ID_CURRENT_SITE’ is not even used at all (in ms-load.php), unless your wp-config.php also define both of ‘DOMAIN_CURRENT_SITE’ and ‘PATH_CURRENT_SITE’.
That is (part) of how the controlling (network admin) domain of the multi-site installation moves to a new domain.

With the following in wp-config.php:

define('DOMAIN_CURRENT_SITE', 'thenewdomain.com');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 3);

running your test code on blog-id “3”, (not as normal “1”) gives this:

Base prefix: string(6) "ftrav_" 
Just prefix: string(8) "ftrav_3_" 
Network prefix: string(8) "ftrav_0_" 
get_blog_prefix(0): string(8) "ftrav_0_"

Confusion abound. 🙂

In the end maybe also a bug in WordPress’ get_blog_prefix(), since it assumes that only blog #0 and #1 can be “special” (because of the initial fresh install). It tests specifically for ‘0’ and ‘1’.

if ( defined( 'MULTISITE' ) && ( 0 == $blog_id || 1 == $blog_id ) )
        return $this->base_prefix;

But with a different BLOG_ID_CURRENT_SITE activated (using ‘DOMAIN_CURRENT_SITE’ and ‘PATH_CURRENT_SITE’), that test is just no longer true..

Calling get_blog_prefix() is meant for plugins/themes that do not install GLOBAL private tables. It is how they find their tables, if installed at the “blog level private” level. 🙂

But, as I mentioned in earlier explanations, the logic to use is actually really, really simple..

WordFence Install code (wfSchema.php, CreateAll(), and RunInstall()) ALWAYS/unconditionally/hard-coded, install all WordFence tables to live off “$wpdb->base_prefix”. All table installs and updates use a hard-coded “base_prefix” directly.
Independent from whether you are on a single- or a multi-site installation.
Because WordFence is always network/multi-site global.

Since the tables are not likely to suddenly move anywhere else afterwards, that by mere logic means that any and all later accesses to these tables should also unconditionally and always be off “base_prefix”.
No need to ever call get_blog_prefix() to ask WordPress where your private tables might be have been (re-)located to. Such a move ain’t gonna happen. 🙂
The tables stay where you put them. 🙂 Living off “base_prefix”. 🙂
Likewise about ever using $wpdb->prefix (including a blog prefix).. Your tables will not be found there.

@irisslesley,
If you notice, the fact that WordFence stops counting statistics is what I originally reported.. It is caused by most of the stats/hits DB updates failing miserably, when WordFence tries to use table names that do not exist. With numbered prefixes that do not exist. 🙂

Depending on which of it’s 3 methods gets called in each update case to “find the table”, you will see some DB calls fail against “prefix_3_tablename” and other cases fail against “prefix_0_tablename”.. Neither of which will ever exist, since all WordFence tables are installed directly as “prefix_tablename”.. No blog numbering prefix involved. Ever.

🙂 🙂

This is caused by this BUG in WordFence

https://wordpress.org/support/topic/activity-report-email-bad-guys-have-left-the-internet/

which so far has not gotten fixed (and my forum incident even marked as “resolved” to better the statistics), because supposedly I am the only site-owner in the whole world that is seeing that issue. 🙂

So, per the WordFence guys, you cannot be seeing what you and I are seeing. (But it is supposedly in their internal systems as case “FB5929”.)

As you can see in my explanations down below in that other incident, it is caused by faulty (very confused) handling of table prefixes in WordFence.

This (non-existing) issue has caused me to not download any of the last three WordFence updates, because I am tired of cleaning up the code manually to make it work and stop the bad table accesses when my fixes get replaced by bad WordFence updates with still unfixed code. 🙂

Cpanel’s (and WHM’s) IP Blocker functionality is very simplistic.
It does NOT interface with any Firewall software, like IpTables, APF, or CSF, or anything like that, since such features are not available to users on Shared Hosting.

All the Cpanel/WHM functionality does is to edit your .htaccess file for you, and insert a
deny from that-Ip-Address-Here
line, which would make the web-server (Apache) block the access for that IP when seen.
Cpanel actually runs through the .htaccess files for ALL domains you might be hosting in your account and inserts the same line in all of them.
Everything after that, Cpanel is completely oblivious to. Cpanel does NOT partake in any actual blocking of that IP.

So check your main .htaccess file in the root of the web-site..
If there is no longer a “deny from” line with that bad IP address, then the Cpanel line at some point has been deleted from that .htaccess file, and the IP is now unblocked as far as Apache is concerned (leaving the IP to hit in WordFence).

Your host should have explained that.. It is true, that as long as .htaccess is blocking it, WordFence would not be seeing it.
But that requires the .htaccess line to actually be there (still). 🙂

Note also, that all this also depends on how your WordFence “How to get IPs” is set up.
For example, if you are behind a caching- or reverse-proxy service, WordFence would be getting it’s IP addresses from the proxy headers to get at the true IP address, and those are what you see in it’s logs.

The .htaccess Deny line, used by Cpanel’s IP blocker, ONLY works on ips found in REMOTE_ADDR, which in the case of a caching front-end would be false. REMOTE_ADDR would for all accesses be pointing to the caching server:-) The bad IP would never be seen.

IN YOUR CASE, they ARE running a Nginx caching proxy server in front of you. Your site headers show that. Depending on their setup and other local changes, that could have left any and all “Denies” in .htaccess/Cpanel totally non-functional. Your host should also have told you that.

In summation.. That IPs are getting as far inside your walls as WordFence has everything to do with your hosting setup, and nothing to do with WordFence. 🙂