wfasa
Forum Replies Created
-
Hi @backpages,
Sorry for the late reply. Yes, this would indicate that the latest Wordfence update did not complete successfully. It’s hard to say why that would happen but if you have PHP error logs available on the site, you could check those to see if you can find any clues. We have seen a few reports of that happening lately but most have been on GoDaddy hosting and it doesn’t look like that’s where you’re hosted. Reasons for a plugin update to fail can be that the disk is full or that the server is running out of resources during the update.Hi @hitechcobra,
It means your site is having trouble recognizing that you are logged in when it sends requests to admin-ajax.php. It’s not something we’re seeing on other site so something in your WordPress installation must be causing it.Have you tried swapping to a default WordPress theme?
Hi @cucocreative! We are indeed chatting with Heart now which I’m super happy about and I’m optimistic that we’ll find a solution. Thanks for the update!
Hi @goldies2005,
Wordfence scans from within your site which means it’s able to see a lot more about what’s going on in your system than an online (remote) scanner can. If you have any questions about scan results, please post in our support forum for free customers here on the WordPress.org forums and we’ll be happy to help!Hi @singingcyclist!
Heart have reached out to me now so I’ll be chatting with them to see if we can find a solution. If I have any updates later on, I’ll let you know!/wp-content/upgrade/ is the only one that wouldn’t result in a 404 and to protect that one you should have directory indexing disabled on the server. A hacker can’t “access” /WP-content/upgrade/ because it doesn’t exist. The “banned URLs” feature can effectively be used as a honeypot for URLs that bad scanners are likely to request but I wouldn’t recommend you try to block all URLs that would result in a 404.
That’s good news. Thanks for the update @kvm1!
Hi @psamathe,
The feature that blocks URLs is not part of brute force protection. The feature discussed in this thread is one that blocks users when they try to visit specific URLs on your website. A username would not be considered a URL. To achieve blocking of logins with strange usernames you can enable the option in Wordfence to block all invalid usernames.@yet-another-wp-user, @mountainguy2,
Some people may be using the case sensitivity in banned URLs to block certain things and not others. If we implement this it would likely be a separate option where you can choose if it’s case sensitive or not. The thread is marked as resolved because we don’t have anymore information we can give you at this time. Your feature request has been noted and we may implement this at some point.Thanks for the feedback. Hope you have a great week!
Hi @markmadedesign,
I would recommend you demand that your webhost explains what http://atl4.violin.web.com/services/wpplat/getchecksum is. It’s their domain. They are literally hosting that. They need to go look and find out what it is. (Network solutions is owned by web.com).Hi @cleanpagedesign!
Thanks for reaching out. I is correct that our scanning server does not support TLS 1.3 yet. Is your server only able to make outbound connections with TLS 1.3? This is an outbound connection, just wanted to make sure we got that right.Hi @markmadedesign!
That change struck me as odd initially but when doing a lookup on your domain spaindifference.com the owner of the network shows up as Web.com, Inc. Your WordPress API URL was changed to violin.web.com so therefore I suspect this change may have been made by your host? It seems strange that they wouldn’t be aware of it though.I would recommend you download the affected files so you have a record of what changed in them, then I’d recommend you reach out to your host and ask what atl4.violin.web.com/services/wpplat/getchecksum is and if they’ve recently implemented some customization of the WordPress update functions on your site.
Hi!
There are two possibilities. Either the files in wflogs have become corrupt for some reason, or there is a permissions error on the files because multiple server users are writing to the files. Please follow these two steps1. Download the wflogs folder, zip it up as a backup.
2. Delete the wflogs folder. It will now be recreated automatically.If the site works now, it means some of the files were likely corrupt. If the issue reappears after this please
1. Try adding this constant define(‘WFWAF_LOG_FILE_MODE’, 0660); to the beginning of wordfence-waf.php on the line after <?php
2. Does it work now?If it works after that, it means you have several server users writing to the folder and you have a permissions conflict. The constant allows group write access to the files in the wflogs folder. We prefer if you can keep the permissions to owner read/write only, but you can use the above constant to diagnose the issue.
Please do these two tasks one at a time and not all at once, so you can get to the bottom of why this is happening on your site. It won’t be the same problem on all sites, it can be different.
Thanks!
Hi @maxmulf,
This was an issue that affected Wordfence 7.1.14. If you use FTP or any file manager your web host provides to remove the wordfence folder completely from wp-content/plugins and reinstall the newest version of Wordfence, the problem should be resolved.Hi @kickthefog,
“Error 502 – Bad Gateway” typically comes either from your server itself or a proxy that might be sitting in front of the server.If you had blocked an IP incorrectly, that would likely have affected all your pages and not just the Firewall page in Wordfence.
What does the “Error 502 – Bad Gateway” page look like? Is there any indication on it where it was served from?
Hi @britand!
Sorry for the delay. We try to answer free support requests within 2 days during business days.To find out why the error is happening you’ll need to find the sites PHP error logs. When a 500 error happens, there will be an actual error message logged there. If you don’t have error logs available, you can enable WordPress debug via wp-config.php which will then create an error log here: wp-content/debug.log.
If you have define( ‘WP_DEBUG’, false ); in wp-config.php remove that and add this instead:
define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false );Once you know what the actual error is, let me know and I’ll hopefully be able to tell you something more about what’s happening with the site.