webado
Forum Replies Created
-
I’m guessing we will have another update of Wordfence soon 😉
You won’t see a file with that name anywhere because it’s autogenerated by the plugin.
Forum: Plugins
In reply to: [XML Sitemap Generator for Google] Where is Sitemap.xml file installedIt’s the same idea as the robots.txt file which is autogenerated by WordPress. It’s not a physical file. You can of course override that by uploading your own robots.txt file.
Forum: Plugins
In reply to: [XML Sitemap Generator for Google] Data collection/GDPRNot relevant at all. The plugin simply produces a sitemap which is basically a list of urls.
Forum: Plugins
In reply to: [XML Sitemap Generator for Google] Lot of Calls to other sitesYou specifically asked the plugin to NOTIFY Google and Bing about EVERY change to the sitemap. A change happens every time you make any modification to any page or post.
So remove that request to notify Google and Bing and your issue will be solved. But you may end up having to submit your sitemap manually every so often to Google’s Search Console, especially if you made many changes to the site and don’t want to wait until Google is good and ready to pick up the sitemap again.
The plugin simply produces a list of urls from the website. GDPR compliance is irrelevant.
So yeah, if you insist, it is compliant. Because there’s nothing about it which can be non-compliant.I received such an email as well. I feel it must have been sent in error. The 3 plugins mentioned in my email (Add Categories to Pages, Akismet Anti-Spam and Official Statcounter Plugin) have all been deemed compatible with version 4.9.6 of WordPress and that’s the latest version. ANd it’s obvious they’ve not been removed by ww.wp.xz.cn either.
Sit tight, it should get resolved soon.
Forum: Plugins
In reply to: [Simple Calendar - Google Calendar Plugin] SIte down after updateThe updated plugin clashed with my homepage layout and the layout of another page where the plugin is used. The /wp-admin/ page responded with an error 500.
I re-uploaded by FTP an older version I had on my PC and it’s back to normal.
I have to say that I’ve stopped using what would have been the more useful function of this plugin a long time ago because it doesn’t work. At this time I am only using it to embed the grid calendar only.
From this latest update I have no idea what exactly got changed and how but obviously it’s screwing up majorly.
I got an email from WF also saying: Unknown WordPress core version: 4.6.1
I suppose it will get sorted soon. It looks like this WP version came fast with no pre-announcement.
I had no opportunity to see what the changes may have been so soon after 4.6 .Some new vulnerability may have been discovered by hackers and they keep trying.
Whether it’s for core WP or some plugin I don’t know,but I guess we’ll find out soon, as another flurry of upgrades get announced.Don’t screw up your .htaccess file or you may mess up the website.
Always keep a backup copy.Ask your hoster for help with trickier things.
If it’s for a WordPress site there’s a specific setting that applies to all WP sites.
Some plugins also add their own specific directives.
Basic WP (installed in the root) with Wordfence firewall has this:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule># END WordPress
# Wordfence WAF
<Files “.user.ini”>
<IfModule mod_authz_core.c>
Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
Order deny,allow
Deny from all
</IfModule>
</Files># END Wordfence WAF
I usually add at the top, outside the If modules this:
Options All – Indexes
There are other directives such as to prevent POST requests which I’m not using yet as I don’t understand them that well and I don’t know how they may affect a WP site with its login and other situations when one posts (e.g. comments).
As I said they are not necessarily bots. They are mostly proxies. I’d love to block all proxies because I see no valid reason for anybody to use a proxy to access any of my sites, ever, but detecting programmatically what’s a proxy and what’s not a proxy is not definitive.
Also there’s no reason to block countries in general. Some of my sites are of universal interest. The site for which I am enduring this onslaught right now is in a scientific niche of sorts.
The worst offender from what I see is an IP from the US, with over 200 attempts in a short period of time.
My server is fast enough, but hackers are faster and very determined, that’s the bottom line.
Many are from IPs located in Russia, Ukraine or the middle-east. But there are also plenty from the UK, Germany, Austria, Italy, US and Canada, some from seemingly around the block. Lots of bored script kiddies and maybe this all will die down when they get back to school in the next few days. Of course since most of the IPs are disused servers exploited as proxies, you cannot really know where they come from.
Anyway, enough of this. My head is splitting. Thank you for a challenging discussion.
I don’t have direct access to my server’s firewall and yes loads of IPs are blocked there for brute force attacks on the server overall. My server admin has occasionally had to unblock some IPs that were blocked because legitimate users made too many mistakes in the user ID or password required to access their Cpanel or FTP. Eventually these legitimate IPs get whitelisted and those people get a slap on their hand.
With Wordfence it’s about direct attacks on a particular website, such as attempting to log in with stupid user ids like “admin” or “test” or part of the site’s name, attempting to request a password reset for that as well, or else attempts at accessing specific urls that don’t exist but if they did they are not supposed to be publicly accessible just in case the protection fails. I do check those and I know they are would be hackers. I have no pity blocking them forever. I don’t believe in rehabilitation of IPs used by hackers. The site would have long ceased to even exist by the time that may happen.
I don’t have to block in WF the IPs that are already blocked in the server’s firewall or in my .htaccess files. They won’t get that far.
I am only careful not to block Googlebot IPs, and to a lesser extent other genuine search engine IPs. WF is configured to handle this.
As for the particular site I am dealing with right not, it has very little legitimate human or search engine robots traffic. Compared to the flurry of hack attempts that are getting blocked that’s an astounding difference.
I don’t care who tries to access the site to read its content, but I draw a line to those who try to persistently hack it.