Caleb

Here is how I look at it.

Yes, any hosting provider ALSO host legitimate “sites”. BUT… Those web-sites do not make a living crawling the web and causing trouble for others. And VERY, VERY few crawlers are legitimate in the sense that they pay you back with visitors.
So by blocking off a hosting provider’s IP range, you will rarely be blocking something worthwhile. None of OVH’s legitimate sites would ever try to visit you.. They also at times host SEO crawlers and scrapers like Ahrefs and others, who move their hosting from country to country. But those are also visitors that would NEVER pay you back for the bandwidth they steal. Unless you should be tricked into paying for their services. (My advice: DON’T. 🙂 )

Even otherwise legitimate companies, like AWS (Amazon EC2) is being used specifically by YATS (Yet Another Twitter Scraper) and many other negative scrapers, where they run anonymously using fake Agent-strings. Because they do not think anyone would block AWS.. I block EVERY AWS range I see. In many years, nothing valid has every come OUT from there.

My rule is simple.. If you are running out of server hosting, and you are arriving with fake Agent-strings (pretending to be human), then you are DEAD to me. 🙂

As long as these accesses are accessing URLs on your site that should exist for your users, there is little you can do other than blocking their whole hosting ranges as they appear.

If on the other hand they access invalid URLs (are hunting for vulnerabilities) you can add those paths to your banned URLs on the options page to get them banned immediately once they try one. But that is a temporary, time-limited single-IP block.

The “arrive from strange sites” is merely the referrer field in the HTTP request. Which the bot can set to whatever they want and means nothing in these illegitimate cases. That could be the last place they bothered before you, or it could mean nothing.

Note that blocking using “hostname” can slow down your web-site. As it warns on the Advanced Blocking page. To translate from the IP address to the host-name require doing a reverse DNS IP lookup on all IPs to find their hostname, which will slow down ALL accesses. Not merely the illegitimate ones. Even your normal users will then have their IP reversed to a hostname, BEFORE they get in.

That IP block seems to be another OVH hosting range. OVH is one of the worst at having no control on what garbage hacker/spammer bots they host. OVH sending traffic from France, Canada, everywhere. They have been one of the worst in all the approx 10 years I have been watching them.

If you want to block them, block by clicking “Block this network” on one of the accesses, and permanently block off the whole network block instead of using host-name. Blocking by IP require no reverse lookups and is fast.

BTW.. I just noticed in the image you posted, that the Add-On domains contain NON-Wordpress web-sites.

No.. WordFence cannot protect Non-WordPress sites. Even if it could, in your Cpanel structure, the traffic to the add-on domains is not even visible to the main web-site (in the root public_html). They are not related, despite the Add-On’s being contained “within” the physical public_html directory.
As I mentioned in the original response, that is a dumb Cpanel design “feature”.

And with the others being non-WordPress, my suggestion about using a WordPress “Network” instead is obviously irrelevant.

So, you forgot to check the option on the options page that states “Delete Wordfence tables and data on deactivation”? Yeah, that is unforgivable. You should have. 🙂

Can’t speak for Wordfence folks, but I would say that option is not set by default, because sometimes or most times a person actually WANT to be able to remove and reinstall a plugin, without losing all the existing configurations and history. So, tables are left behind for the reinstall or reactivation. Unless you ask the plugin to clean up after itself by setting that magic option. 🙂

@seoalien, if you go to your Google Search Dashboard for the site, look under “Crawl Errors”, where the 404 (do not exist) errors will show each bad link they have found.

When you click on a listed link, a window will pop up, where one of the tabs is “Linked From”. The “Linked from” will tell you which web-page GoogleBot found the goofy link on.

But as @wfalaa stated, apparently your site (likely a plugin or something from the hack) is generating these odd links. If you fix where the links are coming from, eventually GoogleBot will stop hunting them. (if they are still being generated.)
But that will of course not happen as long as you are generating them. 🙂
But looking at the source for the “Linked From” page on your site will tell.

If the links are merely a side-effect of the hack, now fixed, then GoogleBot likely found them while the site was hacked and is now running through it’s queued up links. If your site has stopped generating them, eventually Google’s queue of pending visits will run out.

Personally, I would not start rate-limiting GoogleBot, if they innocently find bad (404 return) links my site was feeding them. Lest they decide to slow down their visits by seeing block screens. GoogleBot keep their own friendly, slow pace, which under normal circumstances depends on how many new, fresh links you feed them. Even the bad ones.
But… That’s just me.

user_nicename is merely a url sanitized version of user_login. In general, if you don’t use any special characters in your login, then your nicename will always be the same as login. (check your users table.. If you use normal login names, there is NO difference between the user_login and user_nicename columns).
But if you enter for example email address in the login field during registration, then you will see a difference.

For instance, if your login is user@example.com then you will have userexample-com as the nicename and it will be used in author’s urls (like author’s archive, post permalink, etc). The only way to otherwise change the user_nicename”, is manual intervention in the database, or filtering.
(WordPress’ get_author_posts_url() function provides the filter “author_link” for changing the final, resulting URL to author pages before it is returned. (Of course filtering the link down to empty (href=””) would then effectively turn off author pages, as each author link would then point to the post page itself. 🙂
No where to go. 🙂

If you by chance are confusing “Nice name” with the user accounts “Display publicly as” choice, or the Nickname, they are NOT related to ‘user_nicename’, which is an internal thing normal users have no direct control over..

The URL-path for author archives cannot change every time someone change “nick name” or “Display As” name. The URL is supposed to stay stable, or GoogleBot would go nuts trying to keep up with your changing URL addresses and apparently moving locations.
And BTW, that is one reason that the login-/user-name is the ONE thing you cannot change in your user account info. Once set, your login name stays the same. And is used permanently in the author URL. (the “/author/username” path).
So also for the “user_nicename”, which is set when the user is created, and is as mentioned just a sanitized (URL capable) version of the login name, just in case users use weird characters in logins or use email addresses.

An htaccess file in (or controlling) the /wp-admin directory will not affect standard logins, only access to scripts with a path within the /wp-admin directory.

It will not affect logins, because the /wp-login.php file is located in the root of your site. See it by logging out and trying to log in again. Watch the URL path.

If you really wanted to have two-level access control on all your logins, you could add htaccess permissions to load the wp-login.php file. Then first the web-server would ask you one login to access /wp-login.php (stopping the WP login hacker scripts at the door), and then afterwards the actual WordPress login would appear.. Quite painful. 🙂