Forum Replies Created

Viewing 15 replies - 166 through 180 (of 1,317 total)
  • Plugin Author Mark Maunder

    (@mmaunder)

    Hi there,

    Brian is correct in his assessment, but he’s asked me to investigate too. This is unrelated to Wordfence. To be clear, if you haven’t fixed the cause of the problem, you will see it in the next caching plugin you use and will probably start to see it corrupt operating system files. Basically you need to urgently find the cause and fix it or you’re going to have a very problematic system.

    I’m marking this resolved. I’m going to assume you’re going to investigate why your OS filesystem is experiencing corruption and fix that, then move forward and if you have any further questions related to Wordfence specifically please don’t hesitate to start a new threat and Brian or Tim will be happy to help.

    Regards,

    Mark.

    Plugin Author Mark Maunder

    (@mmaunder)

    Hi,

    For some reason your server is not able to fetch the following URL from our scanning servers:

    http://noc1.wordfence.com/malwarePrefixes.bin

    or

    https://noc1.wordfence.com/malwarePrefixes.bin

    This is a file that’s regularly updated with malware signatures. You can ask your hosting provider to try to investigate why your server is unable to fetch this file.

    The plugin tries to fetch this file, then once fetched, does a modulus 4 on the length of the file and expects zero as the result. It’s a light integrity check and it’s that check that is failing – so the file comes back with the wrong length. I’ve just verified that the file is the correct length on our servers by manually downloading it.

    You can stop the error from happening by disabling the following scan on your options page: “Scan for signatures of known malicious file”.

    But I’d suggest you ask your hosting provider to find out why your server is unable to download that file.

    Regards,

    Mark.

    Plugin Author Mark Maunder

    (@mmaunder)

    Hi,

    It looks like jQuery is completely missing. This is a core javascript library that WordPress should provide. So it looks like your WP installation may be corrupt or something else is causing jQuery to not load. Wordfence (and much of WordPress) won’t function without jQuery so you need to fix this. You may need to ask your hosting provider for help or ask a developer to look at your site. If this was caused by an existing infection then I’d recommend you try restoring rom backups if you can.

    Regards,

    Mark.

    Plugin Author Mark Maunder

    (@mmaunder)

    Hi Shawn,

    Tim brought this to my attention today in a meeting. I read the forum thread and I see what happened there. Someone got confused and thought we were part of the problem. And then the thread was updated as you said. I thought about responding on that forum, but it looks like it’s all been cleared up.

    So just to answer your most recent question: We do actually protect against exploits against the RevSlider plugin specifically. Whether or not you have the plugin installed and whether or not you’re running a vulnerable version, if someone tries to access a known exploit URL, they receive the message: “URL not allowed. Slider Revolution Hack attempt detected. #2”. I just reverified this and Tim verified it a few days ago by launching an attack on a website to test the feature.

    Hope that helps. Let us know if you have further questions.

    Regards,

    Mark.

    Hi, just thought I’d offer my 2c: If the sites you’ve mentioned are on the same server then check that it has not run out of disk space. If they’re using the same database server check that the DB server has not run out of disk space or is experiencing table corruption. Either of these would cause the WP app to try to write to the DB but the write would fail and so you would have these symptoms.

    Regards,

    Mark.

    Plugin Author Mark Maunder

    (@mmaunder)

    Hi there,

    Sorry you’re disappointed. We’ve put a message at the top of our forums regarding the xmass/new year level of support. There is also a message that you receive in an automated response. We are actually working during the holiday season and many companies are not. We’re just responding a little slower.

    We don’t offer 24/7/365 hands-on support. We don’t offer hands-on site cleaning. So what you’ve found is not a competitive solution. I’m sure it’s significantly more expensive than $39 per year which is what a Wordfence license costs.

    Sorry your site was hacked. Please work with the company you’ve found to clean the site. If you need any help with our product specifically, please log a support ticket and we will get to it. If you have discovered a new infection, please share it with our team at samples@wordfence.com and we’ll add detection for it.

    Regards,

    Mark Maunder – Wordfence Founder.

    Plugin Author Mark Maunder

    (@mmaunder)

    OK scratch that. As I was entering the bug I realized this isn’t a bug. So sure, Nginx doesn’t read .htaccess. But when you use Nginx with falcon and add the falcon rewrite rules to your nginx.conf, we do still block bad IP’s. We block it in the PHP application the way Wordfence normally does.

    So to be clear: When using Apache with falcon, we write IP blocking rules to your .htaccess and blocking happens that way.

    When using Nginx with Falcon, you set up your falcon rewrite rules in your nginx.conf and blocking happens at the application level which is not quite as performant, but it works great and you still get the benefit of fast caching and Wordfence security.

    Hope that makes sense. It’s midnight here, hence the fuzzy brain. Sorry about that.

    Again, I anticipate that Wordfence will work fine with Naxsi. So I think you’re all set.

    Regards,

    Mark.

    Plugin Author Mark Maunder

    (@mmaunder)

    Hi,

    Wordfence should work fine with Naxsi. Moving on to your question about Falcon cache:

    Looks like we might have a bug. We do provide config rules for Falcon to let you run it using Nginx and a PHP app server rather than Apache. However we write the blocked IP’s to .htaccess which Nginx ignores. This seems to be a rather serious bug. So we need to either remove Nginx support for Falcon. Or we need to update an nginx config file with the blocked IP’s.

    Honestly I’m tempted to yank Falcon support for Nginx because I’m not sure how many folks are using that config. Most are on hosting providers with apache and .htaccess files.

    For now I would recommend disabling Falcon with your configuration, but leaving Wordfence in place and it should work fine with the Naxsi WAF you have in Nginx.

    I’m filing a high priority bug to investigate this.

    Regards,

    Mark.

    Plugin Author Mark Maunder

    (@mmaunder)

    @louannpope This is awesome! Brian or Tim please add this to our docs wiki.

    We’ve seen exactly this kind of spam with Feedjit, our real-time analytics service and we’ve built what is essentially a volume filter that blocks anyone who spams their referrer more than X times on Y sites per Z time. Surprising that google analytics hasn’t automated this – they have so much data.

    So this would explain I think many of the “visits” that folks are seeing who have country blocking enabled where the visit is from a blocked country. They’re just spammers who are hitting Google Analytics directly and aren’t even visiting the website at all. And the IP they’re hitting Analytics from is in a blocked country, but we have no ability to block that because the spammer isn’t even touching the customer website. So it shows a visit in Google Analytics from a blocked website.

    This also explains why Wordfence can’t block this kind of referrer spam. Because it’s not traffic that’s hitting the site at all. It’s just someone exploiting your Google Analytics.

    Regards,

    Mark.

    Plugin Author Mark Maunder

    (@mmaunder)

    Hi,

    Thanks for reporting this. We’ve added detection for this infection and have verified in our lab that we now detect the file you posted.

    Regards,

    Mark.

    Plugin Author Mark Maunder

    (@mmaunder)

    Hi,

    If you’re defining your own functions or code then you shouldn’t have a problem. If you’re using an off-the-shelf geoIP package then I’d recommend you look at our own code for our geoIP routines which lives in lib/wfGeoIP.php

    You’ll see there a lot of function_exists calls and if your library uses any of those functions, it either needs to define them to match the same version of the GeoIP library that we’re using or not define them.

    Hope that makes sense. But based on what I think you’re trying to do you shouldn’t have a problem.

    Regards,

    Mark.

    Plugin Author Mark Maunder

    (@mmaunder)

    Hi,

    This is not a security hole. I understand that you’d rather have your cache file permissions set to exclude the execution bit on ‘group’ and ‘other’. So we’ve made that change to Falcon and have tested it without any adverse effects.

    This will be included in the next release.

    Regards,

    Mark.

    Plugin Author Mark Maunder

    (@mmaunder)

    Hi Michael,

    I’m not sure what the problem is here. I don’t think it’s a javascript error because this is server side code that blocks visitors based on their user-agent and appears to not be working.

    There are plugins that let you modify your user-agent. Can you try one of them and see if you can temporarily block yourself?

    Also I noticed all the patterns you tried are a prefix followed by a wildcard e.g. yandex*

    Please try a wildcard with the text in the middle like: *yandex* and see if that works. Perhaps it’s a problem specific to patterns that end with an asterisk – and you can test which is working by using that plugin that lets you change your own user agent.

    Regards,

    Mark.

    Plugin Author Mark Maunder

    (@mmaunder)

    Hi Erik,

    I have a theory of why this may be happening. To be clear: Wordfence is version sensitive so we know which version of core you have (along with themes and plugins) and verify against the correct version.

    If you are running a version of core that we don’t have in our repository, then we let you know with an error saying that you’re using a version of core that we don’t support. So you’ll see this if you’re running a Beta or Alpha version for example.

    But that’s not what’s happening here.

    I think what may have happened is that the websites this occurred on don’t get very much traffic. And the way WordPress scheduled jobs work, a website needs to get a “hit” or page-view before it will run any scheduled jobs.

    So in this case the website got a pageview and that kicked off any outstanding scheduled jobs. Both the Wordfence scan and the upgrade (which is also a scheduled job) kicked off at the same time.

    Then the core scan was running while the core files were being modified and so it alerted on some of the core files because it was halfway through the upgrade – meaning that half the core files were 4.0 and half were 4.0.1.

    Does that sounds like it’s a possible explanation?

    Regards,

    Mark.

    Plugin Author Mark Maunder

    (@mmaunder)

    None of the advanced blocks are currently exported. We’ll be fixing that in the next release which will be out in a few days.

    Regards,

    Mark.

Viewing 15 replies - 166 through 180 (of 1,317 total)