wfasa

Hi @donquicky,
This can happen if the user was created before Wordfence was installed or while Wordfence was deactivated. Could that have been the case here?

Hi @fotske,
It’s not possible to give a blanket statement here because it will depend on how you’re using your site.

DISALLOW_FILE_EDIT
Could stop an admin from editing files they shouldn’t be editing, but an admin can just as well install a plugin containing malicious code so it doesn’t stop a hacker from owning your site. You’d need DISALLOW_FILE_MOD to stop that, but then you’d be in a situation where are plugins need to be auto updated or manually updated. Could be inconvenient but it depends on how you are using your site.

WP_DEBUG
If you have PHP error logging enabled on the server already, you usually don’t need WP_DEBUG so it can be disabled. However, if you don’t have PHP error logs available, I’d recommend keeping WP_DEBUG on and keep it to log PHP errors. Else it’s near impossible to figure out what happened if your site crashes one day.

Hide the WordPress login error
The vast majority of brute force attackers don’t check or care about error messages. It’s just not worth their time. It’s faster to just keep trying a few hundred or thousand times on each site. If nobody but you will be logging in and you see zero problems with this for yourself, then it won’t hurt. However, if you have a shop or something where lots of people will be logging in, it could cause trouble for your customers and thus would not be worth implementing.

To sum up: It’s your call, depending on what’s reasonable for your site specifically.

Hope that helps!

Hi @weekendize,
Wordfence doesn’t use any cookies that affect regular visitors anymore. Cookies are only used for admins/editors and those can not be disabled. If you don’t already have it, please update to the most recent version of Wordfence. Thanks!

Hi @birdiedesign,

The code change you sent in a sample of causes database errors to be printed out to the browser instead of logged and handled within the WordPress environment.

My first suspicion would be that this was done by someone who was trying to fix something on the site, like a developer you have hired, someone you’re managing the site with or your web host. It is also possible that it was done by a malicious actor but it doesn’t strike me as typical malware.

The unknown files could be your original files without the modifications which whomever made the change created as a backup in case they broke the site.

I’d advise you to check last modified timestamp on the files so you can pin point an exact time when it happened and then review who has access to your site and could have made these modifications.

Hi @dlynch027,
The Wordfence scan has a time limit of 3 hours by default, so having it run infinitely shouldn’t be possible. By default scans run once per day and a full scan runs every three days.

Are you logging all database requests in that file, regardless of whether an error happens or not?

Are you using some kind of database cache on this site? If so, that could potentially cause queries to run that shouldn’t be running.

Hi again,
It’s possible that there is some cache on the server. Your host should know if that is the case, so you could try checking that with them.

When you update Wordfence and get the 404 errors, you should also be able to check if those files exist or not which may help narrow it down a bit. For example, if you install 7.1.16 this file should exist:

/wp-content/plugins/wordfence/css/wf-colorbox.1539704326.css?ver=7.1.16

If you use FTP/SSH or any file browser your web host provides, you’d find it in wp-content/plugins/wordfence/css folder.

If you can find the file there I’d recommend you try to load the URL in your browser to see what happens then.

• This reply was modified 7 years, 6 months ago by wfasa.

Hi @levdesign,
It’s possible that there is some other problem which would then likely be a config or performance problem with writing to disk. But unless you’ve changed anything on the server recently, that doesn’t seem more likely.

We did change the default permissions on files in wflogs in Wordfence 7.1.14 which is a fairly recent release. We changed it from allowing group read/write to owner only (by default).

The alternative to setting the constant that allows group write would be to try to figure out which process is causing the issue. You should then look in PHP error logs to determine when exactly the error started occurring and then check raw access logs to see which requests were happening at the time. Then you have to try to figure out why that request would have been running with a different user (could be a custom setup cron job possibly?).