redsand
Forum Replies Created
-
Hey @furtice,
I’m the dev of WP-SpamShield. It’s likely the server configuration on the new server doesn’t match your old server. The two plugins do work together, so it’s likely something specific to the new server. The good news is that it’s likely just a setting you need to tweak. If you don’t get it figured out, please check out the WP-SpamShield FAQs and Troubleshooting Guide, and then submit a support request. We’ll help you get squared away.
– Scott
Forum: Plugins
In reply to: [WP-SpamShield] does it work with visual composer formsOK. So… Let me get this straight…
LOL, too awesome. By far, one of the best responses we’ve received here on the forums in a while! 🙂
Thanks so much for the positive feedback and support. 🙂
We’ll keep working hard to keep spam away from your site!
– Scott
Forum: Plugins
In reply to: [WP-SpamShield] does it work with visual composer formsForum: Reviews
In reply to: [WP-SpamShield] One less thing to worry aboutHi @ginnywills,
Thanks for the great feedback! I’m glad we could help you worry about one less thing. 🙂 We’ll keep working hard to keep that spam away from your site.
Have a good one!
– Scott
You’re welcome. 🙂
If you only have a few users that need to access the admin, it’s a good idea to lock it down by IP, since no one else has any need to be in there. Caveat: As long as it doesn’t interfere with your ability to use the site. If it does, then it’s just a nuisance, not a security measure. 🙂
For a site with a large user base, it would not be practical to lock down by IP.
When you place an
.htaccessin a subdirectory, theDeny from Allpart is the firewall, and theAllow from 11.22.33.44(replace with IP Address) is where you’re poking a hole in the firewall to let yourself through. Using more than one .htaccess can get messy, like you just saw. So, the best way is to use the one in the root to place all your directives. It can get tricky though.The cleanest way to lock down your `/wp-admin/’ by IP, is to place the following code toward the end of the file, <em>AFTER the WordPress code</em>:
SetEnvIfNoCase Request_URI "(^|/)wp\-admin/" RESTRICTED_AREA SetEnvIfNoCase Request_URI "/wp\-admin/admin\-ajax\.php" !RESTRICTED_AREA SetEnvIf Remote_Addr "^11\.22\.33\.44$" !RESTRICTED_AREA <Files *> Order Allow,Deny Allow from all Deny from env=RESTRICTED_AREA </Files>This line sets the custom environment variable
RESTRICTED_AREA(name it whatever you like) for any request that includes/wp-admin/:
SetEnvIfNoCase Request_URI "(^|/)wp\-admin/" RESTRICTED_AREAThis unsets the
RESTRICTED_AREAvariable if the request is foradmin-ajax.phpby adding the “!” before theRESTRICTED_AREA:
SetEnvIfNoCase Request_URI "/wp\-admin/admin\-ajax\.php" !RESTRICTED_AREAThis unsets
RESTRICTED_AREAif the request comes from the IP address or range you specify (replace “11\.22\.33\.44” with whatever just be careful with regex, and write “.” as “\.”):
SetEnvIf Remote_Addr "^11\.22\.33\.44$" !RESTRICTED_AREAThis blocks the request and serves a 403 any time the
RESTRICTED_AREAvariable is set:
Deny from env=RESTRICTED_AREAUsing this method, you can add other conditions as well. It gives you a lot of options.
Just keep in mind that in
.htaccessthe order of processing becomes a big factor in how everything works, and where you place code in the file is really important.The different types of directives get processed in this order:
- mod_setenvif.c – SetEnvIf / SetEnvIfNoCase Directives – https://httpd.apache.org/docs/current/mod/mod_setenvif.html
Setting Environment variables based on a condition. (like the ‘RESTRICTED_AREA’ above. that’s an environment variable…you can rename that whatever you like. I recommend prefixing them to prevent collisions. (‘AA_RESTRICTED_AREA’, or ‘XY_RESTRICTED_AREA’, etc.) - mod_rewrite.c – RewriteRule Directives or paired RewriteCond/RewriteRule Directives – https://httpd.apache.org/docs/current/mod/mod_rewrite.html
Your rewrite rules will get processed after the SetEnvIf directives, so use them wisely. Any environment variables you set with rewrites will not be available for testing in the SetEnvIf directives. But, any environment variables you set using SetEnvIf, will be available in your rewrites. - mod_env.c – SetEnv Directives – https://httpd.apache.org/docs/current/mod/mod_env.html
Setting environment variables NOT based on a condition. These are processed last. So you can’t use these to test for in your SetEnvIf or RewriteRule directives.
It’s tricky, but really powerful.
- This reply was modified 9 years, 9 months ago by redsand.
I’m not related to this plugin, but I’ve dealt with this exact issue many times, so maybe I can help.
If a firewall restricts access to the
/wp-admin/directory, or this is blocked in the.htaccess, you will need to add an exception to your.htacess. I’ve seen this a number of times on websites that recommend people lock down their/wp-admin/directory, or sometimes in security plugins (this was more common several years ago though). They almost always forget to mention that an exception needs to be made for the/wp-admin/admin-ajax.phpfile. It’s good advice to keep the/wp-admin/locked down, as long as appropriate exceptions are made.Keep in mind that an
.htaccessfile will override any.htaccessin its parent directory (recursive), so there may be more than one…and it could cause issues. Look in the directory that is above/outside the web root, and check sub-directories as well.Try this… At the end of your .htaccess, add the following code:
<Files admin-ajax.php> Order Allow,Deny Allow from all </Files>If the above does not work, try checking if there is an
.htaccessin the actual/wp-admin/directory. If there is, it might be leftover from something else. You can either delete it, or add code to the file. (Probably the best move is to delete it…try to put your directives in the main.htaccess.) If you don’t want to delete it, the try placing the above code at the end of that.htaccess.Hope that helps.
Forum: Plugins
In reply to: [WP-SpamShield] Has the official website been hacked?I just wanted to follow up with a bit of additional info. I was able to isolate the incident in question.
We confirmed that IP address I mentioned before was indeed correct, and the one that malicious traffic came from:
167.XXX.0.XXX – Blocks B and D redacted for privacy
We ran a quick check of the IP against an array of DNSBLs (DNS Blacklists) and it came up as blacklisted on 4 of them.
Our server does not block website traffic based on DNSBLs (DNS Blacklists), but checking these may be helpful for you because it provides a separate, second opinion.
So, there has definitely been some malicious traffic from your network or computer to other websites as well, even before today. Please definitely follow my recommendation about securing your computer (and network).
There is an easy way you can check if your IP address is on a blacklist:
- Go to WhatIsMyIPAddress.com to see what your IP address is.
- Go to their blacklist check tool, and copy and paste your IP address into it. (From the previous step).
There are a number of other free tools on the web that can help you with this as well.
Seems to be working fine when we visited it.
If you get that kind of error, that’s a FeedBurner issue or a problem with the feed itself. That wouldn’t be caused by the plugin.
The FeedBurner service was known to be having issues for a bit, so that likely was it.
Forum: Plugins
In reply to: [WP-SpamShield] Has the official website been hacked?No, our website has not been hacked. If you have that happen, you’re triggering a firewall security countermeasure. Normal site visitors would never run into that.
You have to be doing something quite suspicious to trigger that. (As in, the site is detecting an attack.) What exactly were you trying to do at our site? Don’t be offended if you weren’t doing anything intentionally…I just have to ask. If you weren’t doing anything intentionally, then there may be malicious traffic on your network that you’re not aware of (aka malware).
Our records/logs indicate malicious behavior coming from an IP address, that based on timing and a few other factors, is likely yours. You may or may not be aware of it. I’m not going to go into further detail on a forum. You may need to do a deeper security audit of your computer/network.
I would recommend installing BitDefender or another good security+anti-virus on your system, and running a thorough scan. Also, and this is even more important…if you are using an expired operating system that is no longer supported, you should upgrade to a modern operating system. Windows XP is an example of an outdated OS. Microsoft stopped supporting it a couple years ago, which means no more security updates. It was released over 15 years ago and is a security nightmare for folks. Simply running an anti-virus/anti-malware won’t do much to protect you, because of the plethora of security holes that aren’t patched, and won’t be patched.
- This reply was modified 9 years, 9 months ago by redsand. Reason: Additional detail
Have you tried using WP_DEBUG to see if there are any hidden errors?
Forum: Fixing WordPress
In reply to: any plugin that prevents spam on disqus?Anti-spam plugins won’t work on Disqus because it uses a comment process outside of WordPress. Plugins use code hooks to interact with the core WordPress code. When a plugin goes outside the normal WordPress comment process by using a third-party system, such as Disqus does, this isn’t possible.
If you want to use WordPress anti-spam plugins you would need to switch away from Disqus and go back to the native WordPress comments.
Forum: Plugins
In reply to: [WP-SpamShield] Automatic update?Hi Paul,
WP-SpamShield works within the WordPress update API, so all of that is controlled and executed by WordPress, but settings can be set by the user.
WP-SpamShield’s default is to automatically update. (Users were frequently requesting that feature, so we added that default a while back.) Due to the nature of anti-spam and security, it is important to always keep the plugin up to date. Also, when any issues get reported that may affect multiple users, we fix them immediately.
The actual behavior on your specific site depends on your site’s settings. For more info, please see this article as it explains how to control the WordPress update API in a bit more depth:
WordPress Codex: Configuring Automatic Background UpdatesAlso, you can adjust the settings for each plugin, theme, and WordPress via the Easy Updates Manager plugin (which we highly recommend). It gives you granular control over everything.
I hope this info helps!
If you have any further questions, we’ll be happy to help. Just head on over the the WP-SpamShield Support page and drop us a line. (That is our main support venue, not the forums here.) Be sure to check out the Troubleshooting Guide and FAQs as well. Over 90% of issues that users come across are covered in those.
Have a good one!
– Scott
Forum: Plugins
In reply to: [WP-SpamShield] Javascript ErrorThe issue has been fixed in version 1.9.9.2.
Forum: Plugins
In reply to: [WP-SpamShield] Javascript ErrorHi mefistofelos,
Thanks for reporting that issue. That is a legitimate bug. We’ll have an update released quickly here with a fix.
After reviewing the PHP notes for the function, I can confirm that this would indeed happen for PHP versions below 5.5:
Note:
Prior to PHP 5.5, empty() only supports variables; anything else will result in a parse error.Although we do recommend users run PHP 5.5, 5.6 or 7.0, we want to make sure that everyone running PHP 5.3 and 5.4 are taken care of as well.
– Scott
Forum: Plugins
In reply to: [WP-SpamShield] Reverse DNS lookup (gethostbyaddr) via the wp-spamshieldIf you would like tech support, we’re happy to help. However, please be civil.
I’m not sure where all this negativity is coming from. We did not blow off tutakjj, and I’m not sure how our response could be taken as such.
What we did do, was:
- Respond quickly to their question
- Give an honest answer
- Provide accurate information on where the real problem is, so they could fix the real issue.
I’m not sure how any of that can be taken as “blowing them off”, or why you’re giving us such flak.
We never blow off users. I understand that not all plugin devs provide excellent support…but we do. Challenge us on that…take advantage of it.
If you’re having that kind of slowdown, it means that the web host hasn’t configured their system properly. The vast majority of web hosts don’t cause that kind of slowdown. If you’re running your own server, then you may need to make some tweaks.
Maybe you should listen to people and you could have an even better product, rather than insisting they are the problem.
When you say things like that, you make the assumptions that we are unaware of potential issues of a PHP function, that we are out of touch with our users, that we don’t care, and that we don’t like our plugin users. Nothing could be further from the truth.
You could see for your self, but I am sure your to arrogant and sure of yourself.
There is nothing arrogant or wrong about being sure of yourself. We are confident, not arrogant…there is a big difference. We are competent, experienced…and know what we’re doing…therefore we are confident.
However, there are times when we have to unfortunately deliver the cold hard facts, and that isn’t always pleasant. Unfortunately, there are web hosts out there that are not competent or honest.
We actually do know what we’re doing…give us a little credit.
Our development of this plugin goes back to its predecessor and earlier, over 10 years ago. 5-10 years ago, there were some issues on certain web hosts with
gethostbyaddr(). Because of that, it is something we had already looked into. We also have the plugin cache the results in memory when it does rungethostbyaddr(). We do run benchmarks on various PHP functions several times a year to test. It hasn’t been a problem in years. However, there are still some web hosts that in rare cases may not have things setup to industry standards.We do tech support on thousands of websites each year, so we are quite familiar with these types of issues.
There is an alternative method that allows you to set a timeout for the lookup, and it does work in WordPress. It would never take 20 seconds, but it will take longer than
gethostbyaddr()for 99.99% of users.We’ve benchmarked both on a variety of hosting setups, and PHP versions, and the alternative comes out significantly slower every time.
While it may work better when the web host does not have their system configured properly, it will only be better for less than .01 % of users (or less than 1 in 10,000)
The image you linked to definitely is proof that something isn’t working properly on your site, but unfortunately, that’s all it proves. It isn’t proof that the function is bad or that it’s not working for everyone. There is a difference and it’s important to understand that.
We have to make choices that are best for the vast majority of users. Unfortunately, there is always someone who won’t be happy with it. I wish we could make everyone happy…I really do.
That being said, whenever we find out that something starts to affect more than 1 in 10,000 users, we do look into it.
Keep in mind, as I said above… the PHP function
gethostbyaddr()is also used in the WordPress core code.If you want to contact us via the WP-SpamShield Support Page, we can help you with this, and show you how to use the alternative function if you want to test it out, and tweak your WP-SpamShield. We don’t officially support hacking the plugin, but in this case we’ll make an exception.
- mod_setenvif.c – SetEnvIf / SetEnvIfNoCase Directives – https://httpd.apache.org/docs/current/mod/mod_setenvif.html