Caleb
Forum Replies Created
-
You should probably look to configure WP-Super-Cache, which actually send out those messages. 🙂
WP-Super-Cache sends out messages with the frequency you have asked it to rebuild cache items with, but it is up to you whether you actually bother to get emails at all. Turn the emails off.
I don’t use WP-Super-Cache anymore, but it tells you about emails on it’s config page.WordFence is not a caching plugin. It has nothing to do with rebuilding your caches.
Why would you think these emails are from WordFence?Not all hosting environments support .user.ini files. They are only supported and processed if you run the CGI/FastCGI SAPI. In other types, like suPHP, use .htaccess.
The auto_prepend config can generally be placed in either of php.ini, .user.ini, or with the different syntax, in .htaccess files. Just like other PHP config values.
IF the PHP environment you are using support that file. As mentioned, .user.ini is only supported by CGI/FastCGI/PHP-FPM. Not under others.One thing to check is where the original “auto_prepend = Wordfence WAF” config is in your site’s root directory. Did WordFence put it in php.ini, .user.ini, or ,htaccess? You should likely use the same to turn it off for the subdirectory..
Yes, to do the disconnect, it would have to go in the forums directory.
I would suggest you use either the .user.ini or the .htaccess file in the forum directory to tell PHP to STOP auto-prepending the WordFence WAF firewall file into there. It is catching and blocking some of the POSTs.
Since your forum is in a subdirectory of the main install, the WAF “auto_prepend” will extend into there.Put this option in the forum directory’s .htaccess file
php_value auto_prepend_file noneOr better, create a .user.ini file in that directory stating
auto_prepend=noneThe “none” tells PHP that you do not want an “auto_prepend_file” to be used there.
Forum: Plugins
In reply to: [Pods - Custom Content Types and Fields] Linking to Next and Previous PodsRead back through your post and saw the comments about 301’s and renaming.
Not sure I understand? You tried to rename the pod-type, and it did not take? ??
I am confused about what actually transpired over time.Notice again the queries I list up above.. They search for the ACTUAL value of the “post_type” field.
They take the “post_type” value from the current post, and search 1 step back and one step forward in time to find previous and next posts.
If you have changed the slugs, given the Pod a “Custom Rewrite Slug” in the Pods Advanced Options section, and even are 301 redirecting around because a “rename did not take”.. All that does not matter, because the Pod’s post_type is still the same, unless you changed it.
The “post_type” is what is shown under “Edit Pod” up top of your screen. The “post_type” field does not change value, no matter how many times a “Custom Rewrite” slug is changed, or how many redirects are done.
Now.. Since you renamed things in the middle, (changed pod-type maybe?) could it be that you have some Pod Postings in your post database that are stored with the older post_type value, and others that are stored with a new post_type value?
Then because the “rename did not take” as you call it, you instead redirect the older posts to land in the same space visually as the new ones?? That to you, because of the 301s it looks like they all come out under the same slug prefix (like ‘/alliance/’), but in reality, some of your Pods postings have a different ‘post_type’ stored in the database?To this query, all that visual prefixing and redirecting junk is irrelevant. It only knows to looks at the current post and try to find others of same type.
So.. 2 things.
a) looking at the actual queries in the Debug bar will tell you what specific post_type the query is looking for.
b) Looking at the posts table in the database will tell you, if all the posts within one of the non-working pods actually have the post_type you expect, or if there are old values in there. 🙂But if you actually have some Pods with intermixed post types, then they should not even show up in their spot in the Admin backend. When you go to that menu to edit a post, posts with odd values should be missing.
What am I missing?? 🙂
The query in the Debug Bar will tell. 🙂Forum: Plugins
In reply to: [Pods - Custom Content Types and Fields] Linking to Next and Previous PodsThere is another little interesting test one might do..
On your test or staging site install the plugin “Post Type Switcher”. It allows you to change the post type of a post (or Pod) on the fly. An alternate to munging the database directly. 🙂
I use it mainly when I write the initial text for a longer Pod, because I can then type everything in a Word 2016 Blog, post up the final Draft to the site (it becomes a Post), and then in WordPress simply flip the post-type to the Pod type.
The WordPress “Post” will then automagically jump over to the “Pod type” it now has and show up in that Admin list instead, where you can complete the Pod setup with all it’s additional fields. I do it that way, because Word can only handle “Post” types, but it gives me Word’s spell and grammar checks during initial writing.. 🙂Relevant in this case, because if you temporarily change the post_type on one or more of your Pods to ‘Post’ (or the pod-type that’s working), they should now suddenly show up in a different previous/next chain. 🙂
Since the query only looks for post_type and post_date, your “Pod” will suddenly show up in the “Post” sequence and have different Prev/Next links. What did not have Prev/Next before, might suddenly have it now. 🙂Just a fun test. 🙂
Just FYI.
While you wait for that to become a new WordFence feature, the plugin “iQ Block Country” does exactly that, beautifully, and in a quite detailed way. Including considering your front’s wp-login.php, xmlrpc.rpc part of the “back-end”, so you can eliminate anyone from outside Canada from even touching them.
In the action chain, it hangs behind WordFence, so it 100% blocks up up the wp-login/xmlrpc attempts that WordFence lets through on the front.See my reply in this thread from yesterday.
https://wordpress.org/support/topic/wordfence-waf-php-2/
Before deleting it, always make sure it is disconnected from your PHP first.
That’s why your site breaks.
GoogleBot IPs (66.249.* and such) are whitelisted, if you set the option to.
But that does not mean that all Google IPs are good, just because that IP-range is owned by Google. Unfortunately, Google runs both Cloud services and Proxy services, that can be used by bad guys to run decidedly bad apps (until caught).
Load up a bad app, and Google can have you running and scamming in minutes. 🙂Same for Amazon AWS (almost always bad), Microsoft Azure (almost always bad), and similar cloud services. Can’t by default white-list all of those, or we would all be in dire straits. (In fact, I block all the cloud services, as they are attacking me many times a day using fake User-Agent strings from random IPs.)
White-listing that single IP would be just as meaningless as blocking that individual IP permanently (except by blocking the whole range).
These IPs change constantly depending on which “door” the bots come out of at a given moment. Rarely are they fixed-assigned addresses.If you are displaying an RSS news-feed, that means YOU are pulling data.
Not that Google would “load content onto my site”, I would think.
It would be a pull, not a push.One would need to know what the blocked action is, to know what to do about it, if this is an action you actually want to let in.
As the heading above the table listing in your screen-capture says, these are simply tables the cleanup plugin knows are “not in a core WordPress installation”.
Which would be true about any plugin added tables. Any and all tables that were not added by that initial, fresh WordPress Core install, before ANY plugins were added.
So I think that clean-up plugin can be a little dangerous in the wrong hands.. 🙂DON’T DELETE THESE TABLES, if you intend for WordFence to keep running. 🙂
Not a password protection thing. Nor a “can’t we all just get along” thing. 🙂
WordFence is detecting a potentially dangerous XSS style pattern in the posted data formats, and hence blocking it.
I use a lot of ModSecurity rules, that essentially does what the WordFence firewall does, plus a lot more.
During initial setup, I have to create exceptions as “normal” things get blocked.
One has to turn some of those rules OFF for specific WordPress paths, such as wp-post.php, wp-post-new.php, or even form plugin POSTings, because some of the patterns being sent in those normal POSTs are in fact potentially bad patterns. When done outside these special cases. Even WordPress’ constant use of the ‘<–more’ tag in normal blog-postings get caught by some rules, which then block those postings.However, with ModSecurity, I have the option to turn a particular “rule” off. Not
across everything (which would be dangerous), but simply turn it off for that particular action.. That specific WordPress path, like wp-post.php.Not so in WordFence. It runs the same “potentially bad actions” patterns as used in typical ModSecurity rule-sets, but does not have the option to turn them off individually by a user.. Only the WordFence code can create such “rule exceptions” for specific paths.
For Ninja Forms and WordFence to “live together”, either the catching rule would have to be removed entirely (dangerous unless it is a badly formatted rule), or WordFence would need a programmed exception for Ninja Forms.
@leewaycreative, They would need the full content of the POST (or test it with Ninja Forms themselves) to see what is being caught as bad. The goofy URLencoded string you show above simply means
{"id":"3","fields":{"43":{"value":"<h3>PERSONAL Infowhich is not bad content. Just standard JSON formatted form stuff. There is a lot missing.
You might want to read this help page
Which explains the WordFence Option “How does Wordfence get IPs”.
The problem, as also described in the StackExchange discussion is, that REMOTE_ADDR is the only 100% trust-worthy address. It is coming from the incoming physical TCP connection.
The others are headers that might be sent in the transmission, and as such can be spoofed (set to fake values) by the caller. I can send any of those headers any time I want, if I wanted to fake you out. Unless you had a real proxy in front of you that would put REAL values (the REMOTE_ADDR they see) into that header and override me.
Using such a header to find the remote’s IP address should (and MUST) be picked only when you know you have a trust-worthy front-end. When you know that you will always have that header, and that it was always (re-)set by a trust-worthy source.Like if you are fronted by a reverse-proxy or caching server (a Nginx cache/proxy front comes to mind) that you KNOW is always setting the header “HTTP_X_FORWARDED_FOR” or “X-Real-IP” to what they see in all incoming calls. Or fronted by Cloud-Flare, setting CF-Connecting-IP to the IP they see.
In such cases, you cannot physically use your own local REMOTE_ADDR value, because that is always the same.
REMOTE_ADDR in such hosting configurations ALWAYS points to your own reverse proxy for all incoming calls. Which means the proxy (only one or at most a few IPs) would get blamed and blocked for everything. 🙂 Which would take your site down in a flash. No one could connect to it after your own, local proxy was blocked..In such cases, WordPress/WordFence must get the “bad action IP” from somewhere less reliable, open to spoofing, such as HTTP_X_FORWARDED_FOR, X_REAL_IP, or CF-Connecting-IP, if they are sent in the request.
But one of those header option should only be checked/selected on the options page, when you are sure that your local config requires it. Such as when you know that you have a reliable reverse-proxy front, that is always there and always controlling that particular header. NGinx proxy, Cloud-Flare, … In those cases, choosing the “Most secure, REMOTE_ADDR”, simply would not work, because REMOTE_ADDR as mentioned would always blame your own proxy. That’s the only connection you get.
If you KNOW, that outside users connect DIRECTLY to your web-server and that you are not fronted by anything, set the option “How does Wordfence get IPs” to always use REMOTE_ADDR, and there can be no spoofing. Because that value comes from your local operating system and the physical TCP connection. Not from a header. 🙂
The “fixed” referred to in the StackExchange discussion simply means that the option to set it by local needs was added.
There can be no fix for detecting “spoofing” of HTTP headers, unless they are known to be generated by your own trust-worthy front-end. It is not possible. Those faked out or spoofed headers might come from all the way out in the remote agent. That same user/bot/crawler that is also sending you fake User-Agent strings, fake calls, spam, hacks, and many others things you can’t necessarily trust. 🙂 Telling them to stop sending you bogus things simply do not work. 🙂
Also, in some cases, like when people connect to you from AT&T Wireless (think smart-phones, tablets, Mifis), those same headers are used. AT&T sets the headers because they are always passing the request through their proxy.
But that also means, that when WordFence blocks that IP as bad based on REMOTE_ADDR, it is really blocking AT&T (or other ISP). Because AT&T and other ISPs hide the real IP of the device behind their proxy.
Which to you means that the same bad “actor” can show up multiple times per day, just from different IPs.I for example travel a lot, and so I am always on either Verizon or AT&T using my hotspots. My IP(s) can change multiple times per day, even without me doing anything special. 🙂
(I am having one heck of a time having to punch new holes in my server firewalls to keep my SSH connections going every day. My server sees me as multiple IPs, and even as different IPs, depending on whether I connect to the web-server or though SSH/FTP/.. Since one sees the web-proxy, the other do not. )No problem.. Glad you got it working again. 🙂
I know what site downtime feels like.Think about it. 🙂
A Cafe IP.. Probably open network. Perfect anonymous place for hackers/attackers to hide and abuse. Sitting there with a laptop, drinking coffee, while your laptop is spamming or attacking away. 🙂
Heck, if the wireless is open, they can just park a car outside with the laptop running inside it, and go to the movies. 🙂
An IP highly likely to become blacklisted for so many reasons.That particular message is most likely coming from your hosting provider.
Having blacklisted that IP in their outer fire-walling for bad behavior.I know that for example BlueHost uses a similar type of message to cut off IPs that have been used for DDOS attacks or similar.
In that case, only contacting your hosting provider can tell you how to get it unlocked. If they would even consider that for a public access point.Deleting wordfence-waf.php manually was a mistake.
That particular file is hooked into PHP through auto_prepend, so it runs in PHP before the system even tries to start WordPress. That is the initial access check.Depending on your hosting setup, you will have a line in either php.ini or user.ini, that states something like
auto_prepend = wordfence-waf.php some path.
You can look at those files, primarily user.ini, through FileZilla or SSH, and delete that line. If you have a user.ini (or .user.ini) file, with only the auto_prepend line in it, you can simply delete the whole file, rather than editing it.
That might get the system back online.
On your original problem, the “was denying permissions to execute functions”..
You were obviously trying to use both Belt and Suspenders simultaneously.
To see that message, you must have been running both security plugins at the same time. You cannot assume that two security plugins can try to control the system simultaneously without interfering with each other; they are tightly wound into the system..
So it is very likely that one or both of them could complain that the other security plugin is preventing them from doing some of their “unsafe” things, if you run both at the same time.The daily problem email has no link back to the site. It has the domain name in the subject, but that is not the same as a link. Not clickable. Does not contain an http type URL.
All the WordFence individual alerts, such as Admin login, failed login, … follow a shared template file and they have several links back to the WordFence admin page, as I mentioned. Which of course makes @wfyann’s argument a little moot, since WordFence in fact already does what they “don’t want to do”. 🙂
Your email-client, browser, and others ONLY warn you against Phishing links, if you have the option to pass all clicks back to thosee companies for checking first.
Such as Chrome’s 2 options for protect from KNOWN dangerous sites.Many people have all that goob turned off, because that passes every click and page you see back through such as Google or Microsoft before allowing you to proceed. If you have all those options turned on, your click would then first be sent through Google, Microsoft, Symantec, all doing similar checks, before you are finally allowed to see the page-link you clicked on. 🙂 That’s a lot of tracking traffic on the Internet, just to finally see a page. 🙂
I have both those Google options turned off in Chrome for example. I am experienced enough to never click on bad links, and despite having “lived” on the Internet since before the WWW was invented on top of it, have never had a workstation infected with anything at all. I don’t follow links without being darn sure what they are, that they are unobscured, and where they take me. 🙂 But that’s just me. 🙂