Caleb
Forum Replies Created
-
Definitely keep your opcache settings. You might even want to bump your interned_strings_buffer to 16.
You would only have a .opcache directory to delete/clear, if file based caching (persistent cache) is enabled, which is not likely. And it will then be wherever the config tells it to be, which is not necessarily (or likely) in your home directory.
I’d say, leave it alone. You probably don’t even have it.You can check your overall PHP config, by going to WordFence -> Tools -> Diagnostics, and down bottom on the page there is a link under “Other Tests” to view your system’s configuration. On that new page, search for opcache. There might be a lot of options shown.
Unless you see the “.file_cache” option and a location, you would not have file based cache enabled.
The benefit of opcache is keeping it in memory. File based cache is the secondary cache only, and helps when SHM memory is full or by reloading from it on startup when the server is restarted. That’s it.See more on opcache options here:
http://php.net/manual/en/opcache.configuration.phpBTW. WAF rules, such as catching bad POST content or other serious banned stuff is of course another place where a more permanent “NO” error code makes sense..
I did not check what WordFence actually sends in those cases, and I don’t see them fly by on my Apache access-log monitor, since my WordFence WAF never seem to get into action. I have never had a wordfence:waf type event logged. Likely because my ModSecurity rules drop those dead before they ever get as far as WordPress/WordFence.
(I see ModSecurity killing break-ins, injections, or wp-login/xmlrpc attempts usually every few minutes.)503 response on login failures can make sense. Indeed, a 503 response is designed to even include a header to tell the remote how long to back off. (WordFence already sends it.) For users blocked by a forgotten and retried password especially, it makes sense.
But sending a 503 as the response when a robot hits a permanent “NO” rule makes no sense at all. Such as when a bot hits on a URL-path I have manually banned in the Options config, or a permanently blocked IP/range through Advanced Blocking.
There is no chance that any robot or human trying to push their way through a permanent blocking rule would suddenly see a change, if they would just “be nice and try again later”. Which is what a 503 is telling them. 🙂And yes, that 403 might be cached by Varnish, but that has no importance when the access is hitting on a “permanent” configuration rule.
Should the site owner decide to “unban” a URL or unblock an IP range later, one can certainly wait for the Varnish or other cache to expire. If an unblock is really urgent, clear the caches. But if someone has added a permanent block on an IP range, there is rarely an “urgent” need to unblock it. 🙂What I am suggesting is not to entirely stop using 503s, but to use them only when they are appropriate. Send a 403, or 406, or something other meaningful.
It is a very minor change..
Duplicate the “do503()” routine into a “do4XX()” copy, and simply change a few places to send out the right code for the type of event being blocked. Rather than the current way, of simply calling do503() on every event, no matter what it is, or how “permanent” the violation is.I agree with @bluebearmedia. WordFence is not an email rule-engine, and no matter how much they add in “selections” there will still be things someone “don’t wanna know about”.
BUT.. There are many other types of rule-engines that allow you to apply whatever personal logic you want to the emails you receive. From Outlook’s Rules & Alerts manager, to Cpanel’s Email Filters.
Personally, I use Email Filters in the Cpanel account that holds my email accts to filter and deliver many of my emails.. From various of subscribed email lists to Server emails like from WordFence.. By setting up a set of rules on subject/body content/ and many other things, I control where emails go and how they are handled.
Lists and less important content server emails gets either deleted, sent directly into respective subject folders, delivered to my “server” email account, or even forwarded to my personal Inbox if deemed “important” or “Unknown”.
With filters, you could even trigger certain body aspects (such as if a “changed file report” included files in important paths) to go straight to you immediately, while lessor areas are ignored or dumped into a folder.
By using a combination of multiple sets of filter rules, I get to see exactly what I want to see. Immediately, save for later bulk-reading, or simply automatically file/ignore/delete the rest.. No rocket-science involved. But it keeps my main email-box clean of clutter, 7×24.
So check out your Cpanel “Email Filters” functionality, y’all. 🙂
See this thread.
https://wordpress.org/support/topic/scans-not-starting-automatically/#post-9435971
If WordFence servers cannot be reached would also mean, that the same Connectivity section in Tools – Diagnostics should also show those failures. In addition to the failing call back to itself.
BTW.. I see that you are using PHP-7.0.22.. That version is known to be the default PHP7 and to be acting goofy to down-right failing on some hosting environments.
You might want to flip up to a later version.
Probably not related to your 499s, though.You are running under a Nginx web-server..
499 is used by Nginx to tell you that the client closed the connection before the web-serve could manage to respond. Which is in itself unusual.It could be that the client is ACTUALLY closing, or that you have separate security in front of your web-server that catches the attacks and closes the back-end connection to your site. All depending on your configuration.
If front-end security is setup correctly though, your web-server should never even see a connection. I do it that way myself. I do NOT want to even waste time “talking” to these hacker-bots, so I simply slam the door (close the connection) on them with no other response. (Same method I use on Tele-Marketers when they call. 🙂 )
On why NGinx has to be restarted/rebooted, something in your site is stopping your NGinx server from closing the connection probably. Back-end processing in NGinx, a plugin or even WordFence logging that haven’t happened yet, MemCached not responding (if used), got stuck waiting on the DB server, …, … An endless list of things could slow down your server’s response the the remote closure. Need to be debugged.
If the brute force attack comes in fast enough, the server can end up using up all it’s available TCP connections, and hence cannot respond anymore. No more free rooms (connection entries) at the inn.
If you do a ‘netstat’ or ‘netstat -a’ from the command line, you will likely see all these open connections.
Watch the State column.. If the TCP State is ‘CLOSE_WAIT’, that means that the remote end sent a FIN to close the connection, but your operating system is waiting for your local process (Nginx I assume for now) to close it before the records can be freed up.
Depending on how many available connections are configured, you can as mentioned run out of space for new connections, and you will see that as no response from the server.
One of the ways to take down a web server if it cannot respond and clean up fast enough. 🙂
The firewall normally only blocks actions that are considered invalid/illegal/dangerous.
So 10,000 IPs can try to access your wp-login, or scan for various vulnerable URLs, but as long as they are not doing something known to be illegal or invalid (like trying to login with invalid usernames), WordFence would not know to block them.It will not block actions that are valid, of which there can be hundreds/thousands of robotic visits every day. Scammers/hackers abound in the world. But how would it know that you don’t like them, without being told. What is an invalid country to you can be perfectly valid to other sites.
If you mean block certain countries in their entirety, that is for WordFence only a “Premium” feature. There are other things that can block countries, tho.
Personally, I like my Live traffic to stay more quiet, so I block many bad visitors, such as all the incessant wp-login.php or xmlrpc.php visitors before they ever reach WordPress/WordPress and show up in Life Traffic. Earlier in the connection path.
But that requires using other methods. Further “left” in the path. Firewall, Apache mod_security, Apache htaccess, ..
The word “Idle” is probably a poor choice of words. It simply means waiting, running.
@bluebearmedia, if Live Traffic is disabled, it will say “Disabled”, not “Idle”.
@bluesteam, you will notice, that it states that “Live Activity” is idle.
It is not WordFence that is idle. Just the status screen.The “Live Traffic” screen will default update itself by re-reading the log every 2 seconds (you can change that interval in Options)..
In between each “update” it just claims to be “Idle”. It means nothing.
If your option “Pause live updates when window loses focus” is set, when you click into another window, Live Traffic will stop updating itself.
The status will then show as “Paused” instead of “Idle”.Just forget about the word “Idle”. It does not mean that WordFence is idle. Only that the updating Live Traffic screen is waiting for it’s next update to happen.
Good to hear it is now working as expected. 🙂
Life without the ability to “Call Home” sometimes.. Much less fun. 🙂
There is one more level of security you can turn back on first, if you now know that it is overall working.
As mentioned, that particular block message “Blocked by login security setting”, can ONLY be seen under a combination of two conditions.
a) Login Security (which is a global switch for all login sec) must be on.
b) WordFence under Login Security checks multiple things. That message can only happen, when WordFence for some reason thinks it has hit a user name in your
“Immediately block the IP of users who try to sign in as these usernames”
setting.
From that, it would logically follow, that if you first clear that user-name list, make sure that field is completely empty, you can turn back on the “Login Security”, to regain all the other checks. It then still could/should not be able to find banned usernames to produce the “Blocked by login security setting” on. 🙂
If you see that message again, but with an empty blocked users list, something is going VERY haywire, since PHP would seems to have stopped executing logically. 🙂
Before you clear it, please save a copy, so you can tell us what was in it. 🙂
Nothing with authentication issues in your plugins list, that I can see.
That’s how I run it. I would never want WP-Cron to run during user-visits.
No direct effect to WordFence.
Of course, if you set your cron script to only call in every 6 hours to start WP-Cron, then there is a side-effect to every part of WordPress and plugins that schedule things in WP-Cron. 🙂 They will get behind schedule. 🙂
But no. No side-effects.
Well,, as I wrote in the other case, the only thing that can produce the “blocked by login security setting” message, is when WF thinks it is seeing banned usernames.
And turning off just “Login Security”, stops that message.So you would not have to turn off all the other WF security features, while they figure this out. Just the basic login security it adds on top of WordPress standard security.
The root question is still, why WordFence thinks it is seeing banned users.
Might wanna read this one for comparison.
https://wordpress.org/support/topic/wordfence-blocking-all-users/
Let us know, when they figure it out. 🙂
It all depends on how they set up the server.
For example, it also depends on priority of name resolution. If it ALWAYS checks DNS first, and /etc/hosts next, hen obviously /etc/hosts cannot be used to override the DNS result, like we are doing here. It would find your public address first, and look no further. But that is not too normal a setup.In either case, they should know how to make their server call itself. 🙂