By disabling config caching, you cause Wordfence to always fetch it's own data from the database which can solve any problems it may have with this temporary file.

By disabling config caching, you cause Wordfence to always fetch it's own data from the database which can solve any problems it may have with this temporary file.

−

If you would like to enable this option, change only this option on the Wordfence options page, then save, then reload the page and make any other changes you would like to make. This will ensure that you first disable config caching to fix any problem that may exist and then when the page reloads you can write data directly to the database without any problem with the cache file existing.

+

If you would like to enable this option, change only this option on the Wordfence Diagnostics page (near the bottom), then save, then reload the page and make any other changes you would like to make. This will ensure that you first disable config caching to fix any problem that may exist and then when the page reloads you can write data directly to the database without any problem with the cache file existing.

To be clear: The vast majority of WordPress installs have no problem with config caching, so we only provide this for those rare installations that do have a problem with it.

To be clear: The vast majority of WordPress installs have no problem with config caching, so we only provide this for those rare installations that do have a problem with it.

Revision as of 18:41, 15 April 2016

Welcome to the documentation for the Wordfence 'options' page. This document is fairly long and gives a comprehensive description of all the options shown on the Wordfence 'options' page. You can use this document as a reference by using the table of contents at the top of the page. Or you can read it from top to bottom.

Note that we make every attempt to keep this document updated as we release new features and new versions of Wordfence, so the document you see here should be current. However if you notice any errors or ommissions or if you have any suggestions, you are welcome to edit the document yourself (it is a wiki which is publicly editable) or you can contact us on our forums or via genbiz@wordfence.com.

Wordfence API Key

Your Wordfence API key is sent to our server API each time you take any action. It allows us to uniquely identify your WordPress installation as you perform scans and other functions that Wordfence provides.

When you first install Wordfence you are automatically configured to have the free version. Wordfence will contact our servers and automatically fetch a free API key which saves you having to come to our site and register. This gets you up and running with our product as fast as possible.

If you decide to upgrade to a paid version of Wordfence, you will need to go to www.wordfence.com and sign up using the link on our home page. You can then enter your card information and purchase as many keys as you need. Once you've purchased a key, you need to copy it into your clipboard and then return to your own website. Once you've signed into your own WordPress website (if you aren't signed in already) you need to go to your Wordfence options page, paste the key into the API key field at the top of the page and hit save. You will then be upgraded to Wordfence Premium.

Purchasing a Premium Key

To purchase a premium Wordfence API key, you need to simply visit www.wordfence.com, click the link on our home page to get Wordfence Premium. Then fill out the form and sign-up. Please note that we offer substantial bulk discounts when you buy more than one API key and the price drops dramatically per key. So make sure you try different numbers of keys and select different durations for their validity. You'll be able to see how much you pay per key and can make an informed choice about how many keys you would like to purchase.

It's important to note that we start the "clock" on Wordfence Premium API keys from the first time they are installed on a website. That means you can buy an API key today that is valid for one year, and if you start using it 2 years from now, it will still be valid for 1 year from the date of first use.

Downgrading your API Key

If you decide you want to use your premium API key on another website or you want to discontinue your use of Wordfence Premium, you can downgrade your premium key using the link below the API key field. This removes your premium API key from the database and automatically fetches a free API key for your site from our servers. Premium features will be disabled immediately if you choose this option.

Basic Options

The Wordfence Basic options are the most important options in Wordfence that we want to emphasize and that most admins need to be aware of.

Enable Rate Limiting and Advanced Blocking

This option lets you enable or disable the rate limiting and advanced blocking features. If this box is unchecked the following items are disabled:

Country Blocking (if you are a premium customer)

Throttling

IP blocking

Brute force protection

Two factor authentication (cellphone sign-in)

All other firewall rules including the rules under advanced blocking where ranges of IPs are blocked and user-agent patterns are blocked

Enable login security

This option is a global enable-disable switch for all the items that appear under the heading "Login Security" further down on the options page. These include:

Enforce strong passwords

Locking users out after a defined number of login failures

Locking out users after a number of forgot password attempts

Locking out invalid usernames

Preventing WordPress from revealing valid usernames in login errors

Preventing username discover through author scans

Immediate blocking of IP's who try to sign in as a defined list of usernames.

Enable Live Traffic View

This option enables or disables the Live Traffic View. On most servers that have sufficient resources, Live Traffic in Wordfence works flawlessly. In fact we enable Live Traffic on our own production servers which receive a significant amount of web traffic. However if you are using a low cost hosting plan that severely limits the resources you have available, you may consider disabling live traffic to reduce the load on your web server.

Advanced Comment Spam Filter

Wordfence free version already includes excellent comment spam filtering. If you are a premium customer, we provide an additional feature that does a further check to prevent comment spam. This feature does an additional check on the source IP of inbound comments and any URLs that are included. We have found this feature has a high likelihood of reducing spam that has been known to slip through traditional spam filters.

Check if this website is being "Spamvertized"

If your website has been hacked, spammers will often include a small script on your site that redirects any visitors who hit that script's URL from your site to a malicious or pornographic website. The reason they do this is because the site they are redirecting to is a known bad site and spam filters will block any emails containing links to their own site. So instead of emailing links to their own site, they will email out links to another site which is "clean" and which redirects to their bad site.

This is a common tactic they use to defeat spam filters. The problem is that developing a clean site and its reputation takes time. So what spammers do is they hack your site and place a script on your site that does the redirection described above. The result is that links to your own website appear in thousands or hundreds of thousands of spam emails.

So Wordfence offers the additional check to our premium customers which checks if your website is being included in spam emails (Spamvertized). Checking if your site is being spamvertized is an important step in early detection of infection. If this comes up as positive then it means that you are either currently infected with malware or you were in the past. Another possible reason is that your own emails campaigns have been too aggressive or have tripped spam filters from another reason and your website has been listed as a URL that often appears in spam email.

Checking if your site is being spamvertized using regular Wordfence Premium scans is an excellent way to preserve the integrity of your website and email reputation.

Check if this website IP is generating spam

It is important that your website's own IP address has not been blacklisted for sending spam or hosting malware. If your IP address has been blacklisted, then any email originating from your website IP address will either disappear and not even reach an inbox or spam filter (be black holed) or will land in your customer's spam folders.

Your IP can become blacklisted if you are on a shared hosting program and another website on your site is infected with malware or is engaging in malicious activity. This feature does a check to see if your IP address is clean or if it is listed as malicious. If you find that your IP address is listed as malicious, log a support call with your hosting provider to have your site moved to a different IP address or have them work to clean the IP you are hosted on.

Enable automatic scheduled scans

This option must be enabled for scheduled scans to occur. If you would like to disable all scheduled scans in Wordfence, simply uncheck this box and hit save.

If you are a free Wordfence customer, then scans occur once a day and we choose the time that the scan occurs during a 24 hour period.

If you are a Wordfence Premium customer, then you can schedule your own scans as often or as seldom as you'd like.

Both our free and Premium customers can manually perform a Wordfence scan any time they like.

Update Wordfence Automatically when a new version is released

New vulnerabilities and infections appear daily. Keeping Wordfence up to date is a critical part of keeping your website secure. This ensures that you have the latest protection, detection and removal technology that Wordfence provides and you have a better chance of maintaining a secure website. We introduced auto updates in mid 2014 to ensure that our customers sites stay secure.

Where to email alerts

This is the email address where Wordfence security alerts are emailed. This should usually be your WordPress site administrator's email address. You can add multiple email addresses here and separate them using commas.

Security Level

This drop down list lets you select pre-configured security levels that automatically set Wordfence advanced options to an appropriate setting depending on the threat level you're experiencing.

How does Wordfence get IPs

Wordfence needs to determine each visitor IP address to provide security functions on your website. Most websites will work fine using the Wordfence default configuration. It's important that you set this option correctly because if Wordfence is not receiving IP addresses and thinks and external visitor originates from a private address, it will whitelist that visitor and bypass security protocols. You can read more about which addresses Wordfence considers private here

Let Wordfence use the most secure method to get visitor IP addresses. Prevents spoofing and works with most sites.

This is the default mode of operation for Wordfence. Wordfence will try to get a valid IP address from PHP and if that doesn't work, it will look at data that a firewall or reverse proxy sends in case your website uses this configuration.

This option provides a good balance between security and compatibility.

Use PHP's built in REMOTE_ADDR and don't use anything else. Very secure if this is compatible with your site.

If you know that you definitely don't use a reverse proxy, cache, Cloudflare, CDN or anything else in front of your web server that "proxies" traffic to your website, and if you are sure that your website is just a standalone PHP web server, then using this option will work and is the most secure in a non-proxy or load balancer configuration.

You may also want to select this option for other reasons - for example to force Wordfence to use the

$_SERVER['REMOTE_ADDR']

variable in PHP.

Use the X-Forwarded-For HTTP header. Only use if you have a front-end proxy or spoofing may result.

If you are using Nginx or another load balancer as a front-end-proxy or load balancer in front of your web server, and the front-end server sends IP addresses to the web server that runs WordPress using the HTTP X-Forwarded-For header, then you should enable this option.

Be careful about enabling this option if you do not have a front-end-proxy or load balancer (or CDN) configuration because it will then allow visitors to spoof their IP address and you will also miss many hits that should have been logged.

Use the X-Real-IP HTTP header. Only use if you have a front-end proxy or spoofing may result.

As with the X-Forwarded-For option above, only use this option if you are sure that you want Wordfence to retrieve the visitor IP address from the X-Forwarded-For HTTP header and do not enable this if you don't have a front-end proxy or load balancer that is sending visits to your real webserver and adding the X-Real-IP header.

Use the Cloudflare "CF-Connecting-IP" HTTP header to get a visitor IP. Only use if you're using Cloudflare.

Wordfence is fully compatible with CloudFlare and in some configurations Cloudflare will send the real visitor IP address to your web server using the CF-Connecting-IP HTTP header. If the CloudFlare support personel have advised you that this is the case, then enable this option on Wordfence to ensure that Wordfence is able to get your visitor IP address.

Note that Cloudflare has several configurations including their own web server module that takes care of detecting the visitor IP address, so be sure to work with their technical support staff and read their documentation to determine which configuration you're using.

Advanced Options

Advanced options are for site administrators who want to get "under the hood" of Wordfence or who want to change an option to customize Wordfence for their specific needs. We also offer some useful options for debugging Wordfence at the bottom of the advanced options.

Alerts

Wordfence sends email alerts on certain events if you have enabled the alerts in this section. The alerts are sent to the email address provided under "Basic Options" in the field titled "Where to email alerts".

You can limit the number of email alerts received per hour to prevent being flooded with emails. You can also disable alerts if you are experiencing a brute force attack and the email alerts you are receiving are becoming overwhelming.

Remember that the idea behind Wordfence is that you configure it to protect your site and you should only be emailed if there is a critical problem that requires your attention. Wordfence does a pretty good job of protecting your website without your involvement. So don't configure your alerts to tell you absolutely everything that is happening on your website. Configure them so that you are alerted of critical issues - only items that should require your hands-on intervention.

Email Summary

This feature lets you enable an email activity summary. Wordfence will email you using the selected frequency a summary of all activity.

The summary includes top IP's blocked, top countries blocked, top failed logins and recently modified files on your filesystem. It also includes any plugins, themes or core updates that need to happen on your system.

You can exclude directories of your choosing from the recently changed files report. This lets you exclude directories where files often change like your cache directories, backup directories and so on. We have pre-selected several common
directories for you.

We encourage you to send a test email to yourself to ensure that you are receiving your weekly report.

This feature also includes a dashboard widget that comes with Wordfence which contains the same output but it excludes recently changed files. You can enable or disable whether this appears on the dashboard.

Live Traffic View

If you have live traffic enabled (the checkbox to enable/disable is under Basic Options) then this gives you a few more items you can customize including ability to ignore specific users or specific IP addresses or browsers. You may want to use this to ignore a monitoring system that monitors your website performance or uptime and would otherwise generate a lot of traffic logged by Wordfence.

Scans to Include

Scan public facing site

This option triggers an external scan during your normal Wordfence scans. What happens it that when you do a Wordfence scan, as one of the scan steps our external servers will connect to your website and examine your website's rendered HTML. What this means is that we look at your site HTML that is produced once all your PHP code has executed, fetched your data from the database, that data has been combined with any templates and other content and the data is sent to the browser. We examine this final rendered version of your site for malware, malicious URL's and known malware signatures. The advantage of doing this is that even if we miss an item while doing a scan of your website source code, this gives us an additional chance to catch malicious code that is being sent to your users by malware installed on your website. It's one more way to catch an infection.

Scan for the HeartBleed vulnerability

This checks the integrity of your website SSL installation and will alert you if you suffer from the infamous HeartBleed vulnerability.

Scan for publicly accessible configuration, backup, or log files

This scan will check for configuration and other files that could be accessed remotely, such as old WordPress settings in a file name wp-config.old. Preventing access to these files can keep your database password or other important information secure.

Scan for Full Path Disclosure

Full Path Disclosure is when a remote user can see the full location of your website files, such as "/home/user/htdocs/". Some vulnerabilities require an attacker to know the full path to a file, so this scan can help you detect if your site shows this information publicly in some situations.

Scan for Directory Listing

Web servers may show a listing of files in a directory if there is no index file. The specific risks and consequences vary depending on which files are listed and accessible, so this scan shows if directory listing is enabled. It is recommended that you disable it unless it is needed for a specific reason.

Scan core files against repository version for changes

This scan checks if your core files match what exists in the official WordPress core repository. If your files have changed then it's likely that either you have modified them yourself, which is highly unusual and not recommended, or your WordPress installation has been infected by malware which has modified your core files.

If changes have occurred, Wordfence gives you the opportunity to see what those changes are being doing a "diff" which is short for "differences". We will show you a syntactically highlighted display of the differences between your core files and the official WordPress core files that are distributed.

Note that this automatically detects which version of WordPress you are running and will compare your core files to the appropriate version. This version detection and comparison with a the correct version in the repository also applies to theme and plugins below.

Scan theme files against repository versions for changes

As with the core file change detection above, this compares any themes that you have installed on your site with those in the official WordPress theme repository. Note that we automatically detect which theme version you're running and do the comparison with the correct version. This scan applies to all themes installed on your WordPress installation, not just the active theme.

Also note that this scan does not apply to commercial themes or themes that are not in the official WordPress repository. If you do have any commercial themes on your system, we will scan those for malware, malicious URL's, backdoors and many other items. However we don't have the ability to see if your theme files have changed from the original distributed by the vendor. However please note that many websites heavily customize their commercial themes so this check in many cases is pointless because we will detect those customizations as changes to the theme files.

Scan plugin files against repository versions for changes

As with the core file change detection above, this compares your plugins with what is in the official WordPress repository and will alert you to any changes. Most WordPress websites don't customize their plugins, and most plugins installed on a WordPress website are from the official repository, so this is an excellent way to verify file integrity of your plugins.

Note that some developers do not follow the official guidelines that WordPress provides for plugin developers and will modify a "tag" or a version of their plugin that has already been released by adding new code to an existing release. They do this by checking in code into a "tag" into the repository. The result is that this leaves customers with a released version with code that does not match what is in the repository. The customers are also not alerted by WordPress that there is new code and they need to upgrade. In cases like this Wordfence will alert you to the fact that the plugin code you have does not match what is in the repository. That is why we recommend you always use the feature that Wordfence provides to view changes in your plugin files before take any action - because it may just be a case of a developer who is not managing their code correctly.

In this case, you can simply ignore the plugin file that Wordfence flagged and send the developer a friendly note asking them to no check code into existing "tags" or releases.

However if you do see a plugin file that changed and you see long lines with lots of strange characters, it's likely that the plugin file has been infected by something.

Scan for signatures of known malicious files

This scan will look at entire files and compare their hashes with a large database of known malicious files that we maintain and that is continually updated on a daily basis. If we detect a file that is known to be malicious, we'll alert you.

Scan file contents for backdoors, trojans and suspicious code

This scan option provides an excellent level of detection. Wordfence maintains a continually updated list of patterns that match common code and patterns that we see in malicious files. When you perform a scan, any files that we don't recognize as known good files (like core files or known theme and plugin files) we do a deep scan looking for these patterns. If we find a pattern you'll receive a critical alert telling you that we found something malicious in a file.

One of the common patterns we look for is several techniques that are used by hackers to hide their malicious code including encoding their code using base64, URL encoding, hex encoding and others. We also look for patterns that indicate a file contains code that is downloading and executing something without the normal security patterns that you see in WordPress development.

Scan database for backdoors, trojans and suspicious code

This scan checks your site’s options table for known patterns that could be inserted by a malicious user. It's an effective way to prevent a hacker or infection from hiding malicious data in your options table. The options table in WordPress is a kind of miscellaneous storage dump for plugins and themes which is why we pay special attention to what is in this table.

Scan posts for known dangerous URLs and suspicious content

This scan goes through all your website posts by directly accessing your database (rather than doing a site crawl which is slower) and checks if they contain known dangerous URLs that are linked to phishing or hosting malware. It also checks for suspicious content that may have been generated by an infection or a hack.

Note that when we do this scan, we scan all your posts every time we do a scan, rather than only checking new posts. The reason we do this is because the list of known dangerous URLs is constantly changing, so a post that is unchanged may not have a problem today, but a few days from new a URL that it contains may be hosting malware and you will need to remove this URL from your post or risk being blacklisted by Google.

This scan is extremely valuable to preserve your site reputation and avoid a search penalty in Google. The links that appear in each of your posts are indexed by Google and if you are linking to a site that is blacklisted by Google then your site will likely fall in the search rankings and your own site may be blacklisted for acting as an intermediary in the distribution of malware. So we strongly recommend that site owners enable this scan.

Scan comments for known dangerous URLs and suspicious content

This scans all your comments by directly accessing your database and scanning the comments table. It checks comments that are in a published state for known malicious URLs and other patterns that indicate an infection. As with the posts scan above, we do a full scan every time this scan is performed because the list of known dangerous URLs is constantly changing so even if a comment has not changed, we need to re-verify that any URLs it contains are clean.

This is an important scan because it prevents your site from linking to known dangerous URLs that have been blacklisted by Google. If you link to these URLs you may incur a search penalty or be blacklisted yourself.

Note that this function is extremely fast and even if your site has many thousands or tens of thousands of comments, this will execute very quickly because it's operating directly on your database and using an efficient algorithm.

Scan for out of date plugins, themes and WordPress versions

This simply alerts you via email if you are using any out of date themes or plugins. We strongly recommend you leave this enabled because upgrading as soon as possible to new versions of WordPress core, or themes and plugins is the most effective way to keep your site secure.

Scan for admin users created outside of WordPress

This scan checks for admin users that were created by an alternate method, such as through a vulnerable plugin, instead of through the WordPress Users page.

Check the strength of passwords

This scan will inspect user passwords and admin passwords to check if any of your users are using very common passwords. We perform an extended check on admin level accounts and a cursory check on user level accounts.

Monitor disk space

If you are using a hosting provider, it is their responsibility to keep an eye on your server disk space and if your provider is reliable then you won't run out. However we do provide this option for users who are using Linode or another self-hosted service and it's an excellent way to get an email alert if your server is getting close to running out of space.

Scan for unauthorized DNS changes

This scan will alert you to any changes to your website DNS. What that means is that if your website domain name is suddenly pointed to a different IP address or if another more subtle change is made to your website DNS we will alert you. The reason we monitor this is because it's possible that a hacker can access your DNS administration system e.g. by hacking into your GoDaddy account. They can then point your website to their own IP address and hijack your site. This check helps provide an early warning if your DNS changes.

Scan files outside your WordPress installation

This is a very powerful option that lets you broaden your Wordfence scan to also include files outside your WordPress installation. A regular Wordfence scan looks at the following:

wp-admin directory

wp-content directory

wp-includes directory

All subdirectories of the above directories.

All files in your base WordPress directory

When you enable this option, we scan all subdirectories of your WordPress installation even if they aren't part of WordPress. So if you have a directory that is a phpmyadmin installation or a Drupal installation, we will dive down into those directories looking for malicious code and infections too.

You should note two caveats: Firstly enabling this may cause scans to take significantly longer and in some cases they may never finish because they consume too many resources on the server and are killed by the hosting company. Secondly, in rare cases we see circular symbolink links, device directories and other files or directories that are not designed to be read as normal files or can lead Wordfence on a circular path and cause it to scan infinitely. If you are having trouble with your scans taking too long or not finishing, make sure you disable this option.

In general we recommend you leave this option disabled unless you are trying to clean an already infected site or we have suggested you turn this on for another reason.

Scan image files as if they were executable

We occasionally see malicious code hidden inside files that have an image extension. This is rare, but if you're using Wordfence to clean a stubborn infection and suspect you may have image files that are actually PHP code, you can enable this option and it will help you find the malicious code.

Enable HIGH SENSITIVITY scanning

This will enable several options internally in Wordfence that causes it to do a more thorough scan. It will cause Wordfence to scan filetypes like log files and backup files that we would normally ignore. It will also cause us to include in our search patterns that normally give false positives.

We recommend you normally leave this option off. However if you are using Wordfence to clean a site and don't mind seeing several false positives, then you can enable this and it may help you find a stubborn infection.

Exclude files from scan that match these wildcard patterns.

This lets you exclude certain file extensions from your scan. You can use this if Wordfence is getting stuck on large files that you know are not malicious like certain kinds of backup files.

Firewall Rules

Wordfence includes a rate limiting Firewall that controls how your site content can be accessed.

Immediately block fake Google crawlers:

If you are having a problem with people stealing your content and pretending to be Google as they crawl your site, then you can enable this option which will immediately block anyone pretending to be Google.

The way this option works is that we look at the visitor User-Agent HTTP header which indicates which browser the visitor is running. If it appears to be Googlebot then we do a reverse lookup on the customer IP address to verify that the IP does belong to Google. If the IP is not a Google IP then we block it if you have this option enabled.

Be careful about using this option because we have had reports of it blocking real site visitors, especially for some reason visitors from Brazil. It's possible, although we haven't confirmed this, that some internet service providers in Brazil use transparent proxies that for some reason modify their customer user-agent header to pretend to be Googlebot rather than the real header. Or it may be possible that these providers are engaging in some sort of crawling activity pretending to be Googlebot using the same IP address that is the public IP for their customers. Whatever the cause is, the result is that if you enable this you may block real customers in some cases.

How should we treat Google's crawlers

Google crawlers are special. Usually you want Google's crawlers to visit and index your site without interruption and you want to ensure that they have unlimited access to your site. So we have created this option so that you can ensure that Google is treated differently and given greater access than normal site visitors.

Verified Google crawlers have unlimited access to this site

If you would like to use a strict setting you can set this to only give verified Google crawlers unlimited access to the site. This uses a reverse DNS lookup to verify that a visitor claiming to be a Google crawler is actually who they say they are. If a visitor arrives pretending to be Google by faking a Googlebot header, they won't have unlimited access because they will fail the reverse lookup (PTR) test.

Anyone claiming to be Google has unlimited access

This option gives unlimited access to any visitor that has a Googlebot User-Agent header identifying them as a Google crawler. This will ensure that Google is never rate limited on your website and can consume as much content as it likes. However if a visitor claims to be Google by changing their User-Agent header to emulate Googlebot, they will also have unlimited access.

Treat Google like any other Crawler

We do not recommend you use this option unless you have very loose (not strict) settings in your rate limiting. If you treat Google like any other crawler and you are limiting the number of requests per minute to a low number, you may temporarily block Google from crawling your site. Note that the default HTTP response when someone is blocked is to return a 503 temporarily unavailable response. So if you do accidentally block Googlebot, you are telling it to "come back later" rather than "go away permanently" so the damage to your SEO is not as great as it might otherwise be.

If anyone's requests exceed:

This is a global limit on all requests. If anyone breaks this limit they will receive the Wordfence HTTP 503 temporarily unavailable response with a user-friendly explanation. Note that if you have give Googlebot special treatment using the options above then this limit does not apply to Googlebot. In general 240 per minute is a good global request-per-minute setting which allows even fast (but friendly) crawlers to access your site without overloading it. That is 4 requests per second which crawlers like Bing can easily generate. If they try to crawl your site faster than that they will be given an HTTP 503 response which has the effect of telling them to slow down. Use the "throttle" option in most cases which will rate limit rather than block crawlers and visitors.

If a crawler's page views exceed

If we detect a visitor is not a human and is a bot that is crawling your site, then this limit will apply. This is very useful to limit the amount of traffic robots can generate on your website. However some good robots tend to crawl your site quickly, so setting this to 240 per minute is a good setting unless you're having a problem with robots overloading your site. Use the "throttle" option in most cases which will simply rate limit crawlers.

If a crawler's pages not found (404s) exceed

If your site is well configured and designed then you can set this as low as 30 per minute or even 15 per minute. If a crawler is generating many page not found errors on a well configured website, then they are usually up to no good. For example, the may be scanning your website for vulnerabilities and you may want to block them. Setting this to 30 per minute and using the "block" rather than "throttle" option is an effective way to block IP addresses that are scanning your site for vulnerabilities.

However, please read the following caveat: If your site is NOT well designed or configured, then it may during the normal course of operations experience many page not found (404) errors. For example if you include many images that don't exist in your web pages then your pages will generate a lot of 404's on your site. Those 404's can cause Wordfence to block the crawler who is crawling a page if they exceed the limit you've set. So before setting this to a low number and setting the action to "block" make very sure that you don't get a lot of page not found (404) errors on your site during normal operations. One way to do this is to look at your browser error log or console which often displays 404 errors on a page in red.

If a human's page views exceed

If we detect a visitor is human, then this limit will apply. What you set this limit to depends on your website. In general we recommend you keep this high, especially if you are using AJAX on your website. 240 per minute is a healthy setting unless you have many static pages with no AJAX and are sure that the normal traffic pattern that humans generate on your site is much lower.

If a human's pages not found (404s) exceed

If your site is well configured and well designed then you can set this as low as 30 per minute or even 15 per minute.

However, please read the following caveat: If your site is NOT well designed or configured, then it may during the normal course of operations experience many page not found (404) errors. For example if you include many images that don't exist in your web pages then your pages will generate a lot of 404's on your site. Those 404's can cause Wordfence to block the visitor who is viewing a page if they exceed the limit you've set. So before setting this to a low number and setting the action to "block" make very sure that you don't get a lot of page not found (404) errors on your site during normal operations. One way to do this is to look at your browser error log or console which often displays 404 errors on a page in red.

If 404's for known vulnerable URL's exceed

If we detect a visitor who is sending a request that matches a known vulnerability scan or exploit and has other heuristics that match a hack attempt, then this counter is used. In general you can set this to a low number like 15 per minute and set the option to "block".

How long is an IP address blocked when it breaks a rule

Remember, there are two different actions you can choose from when someone breaks a firewall rule. You can either "block" them which immediately removes access from the site for a predetermined amount of time, which is defined by this setting: "How long is an IP address blocked when it breaks a rule".

Or, you can throttle them, which means that their site access will be temporarily blocked until they reduce their request frequency to below the limit you have set.

The option "How long is an IP address blocked when it breaks a rule" controls how long an IP is blocked if you have set the option to "block". We use a duration of between 5 minutes and 1 hour on our own production websites. This is enough time to limit the malicious activity an IP can engage in. However the duration you use is up to you. If you would like to be very aggressive you can set the duration to 24 hours or longer. However it is important to note that IP addresses are dynamically assigned on the Internet. So if you block someone using a certain IP address, they may switch to using a different IP in a day or two and a new user who is not engaging in malicious activity who is assigned the IP you have blocked may then be prevented from accessing your site if you have set this duration very long.

Login Security Options

Enforce strong passwords?

You can use this to either "Force admins and publishers" or "force all members" to use strong passwords. We recommend you force admins and publishers to use strong passwords. When a user on your WordPress site changes their password, Wordfence will check the password against an algorithm to make sure it is strong enough to give you a good level of protection. If the password fails this check then it's rejected and the user must enter a stronger password.

Wordfence checks that the password is a minimum length, that it doesn't match any known obvious passwords and it then uses a point system to allocate points based on things like whether it contains a number, if it has upper and lower case letters and so on. If the point score does not exceed a required level then it will reject the password the user entered.

Lock out after how many login failures

This will lock out an IP address for a specified amount of time if that visitor generates the specified number of login failures.

Note that it is common for real users to forget their passwords and generate up to 5 or more login attempts while trying to remember their username and/or password. So we recommend you set this to 20 which gives real users plenty of opportunity to sign-in but will block a brute force attack after 20 attempts.

Lock out after how many forgot password attempts

This limits the number of times the forgot password form can be used. This protects you against having your forgot password form used to flood a user with email or to try to guess user accounts on your system. Setting this to 5 should be sufficient for most sites.

Count failures over what time period

This specifies the time frame we count failures over. So if you specify 5 minutes and 20 failures then if someone fails to sign in 20 times during a 5 minute period, they will be locked out from login.

Brute force attacks usually send one login attempt every few seconds. So if you have set the number of login failures to 20 then 5 minutes is plenty of time to catch a brute force hack attempt. You do have the option to set it higher.

Amount of time a user is locked out

This specifies how long an IP address is locked out for when Wordfence brute force protection locks them out. Remember, the goal is to prevent a remote attack from having many opportunities to guess your website usernames and passwords. If you have reasonably good passwords then it will take thousands of guesses to guess your password correctly.

So if you have your failure count set to 20, your time period set to 5 minutes and you set this option to 5 minutes, then an attacker will only get 20 guesses every 5 minutes and then they have to wait 5 minutes while they're locked out. So the effect is that they only get 20 guesses every 10 minutes or 2880 guesses per day, assuming they realize that they can restart their attack exactly 5 minutes after being locked out. If you feel this is not long enough, then you can increase the lock-out time to 60 minutes which drastically reduces the number of daily guesses an attacker has.

Immediately lock out invalid usernames

This is an excellent security option and was requested by many members of our community. It will immediately lock out someone who enters an invalid username. However please note that your real users may mis-type their username and be locked out for however long you've specified. Being locked out of a website is a major inconvenience. So while this feature does an excellent job of instantly locking out someone trying to guess passwords, it also runs the risk of locking our real users. This is only recommended for sites with one or two users who don't often make typing mistakes. If you have a staff of publishers, they may show up at your door with torches and pitchforks if they often mistype their usernames.

Don't let WordPress reveal valid users in login errors

By default when you enter a valid username but incorrect password, WordPress will tell you that you entered a good username but the password is wrong. If you enter a bad username and bad password, WordPress will tell you that the username does not exist. This is a serious security problem because it lets users easily find out which users exist on your WordPress site and target those for attacks.

This option gives a generic message of: "The username or password you entered is incorrect." thereby protecting your usernames and not revealing if the hacker guessed a valid user. It's strongly recommended that you enable this feature. We strongly recommend you enable this option.

Prevent users registering 'admin' username if it doesn't exist

If you disable and remove the 'admin' account in Wordpress and you have the option "Anyone can register" enabled in WordPress "General" settings next to "membership" then it is possible for users to register the 'admin' account which can cause confusion on your system and may allow those users to persuade other users of your system to disclose sensitive data.

Enabling this feature prevents the above from happening. We recommend you enable this option.

Prevent discovery of usernames through '?/author=N' scans

On a WordPress system it's possible to discover valid usernames by visiting a specially crafted URL that looks like example.com/author=2

Enabling this option prevents hackers from being able to discover usernames using this exploit. We recommend you leave this enabled.

Immediately block the IP of users who try to sign in as these usernames

This was also a feature that was very much requested by our community. If you, for example, add the user 'admin' without quotes to this list, and you have removed the real 'admin' user from your system, then anyone who tries to sign-in as admin is immediately locked out. This is an excellent way to instantly lock out hackers who are trying to guess passwords. Make sure that the usernames you add to this list are not similar to real usernames on your system.

Other Options

Whitelisted IP addresses that bypass all rules

If you have a static IP address in an office or on a permanent Internet connection and you want to configure Wordfence to always allow that IP address to bypass any rules, then you can enable this option.

Please note that this feature is often misunderstood and we have site admins who try to whitelist their home IP address on a broadband connection. Your broadband IP address is not a permanent IP address because it is dynamically assigned and will change after several weeks or months - or sometimes over a shorter period. So we don't recommend you try whitelisting your home address if you're using ADSL or cable modem because your IP will inevitably change after time making this whitelisting ineffective and potentially causing whoever is assigned the IP address after you lose it to have unlimited access to your website.

Only use this feature if you are sure you have a permanent IP address. Most people don't.

You can whitelist whole networks if needed (Bing for example). To enter these you need to input them in the xxx.xxx.xxx.[x-x] format.
For example 65.52.104.0/24 would be entered as 65.52.104.[0-255]
This page can help you translate CIDR formats to ranges - http://www.ipaddressguide.com/cidr

Immediately block IP's that access these URLs

This allows you to set a kind of trap for bad guys. You can enter a URL that does not exist, for example: /vulnerabilityLivesHere

Then if someone tries to access that URL they are instantly locked out. You have to specify a relative URL, in other words it must start with a forward slash. It also must be a page that does not exist on your website.

We only recommend this feature if you are trying to catch a specific hacker and block them or if you are trying to catch hackers that are trying to exploit a known vulnerability or page on your site.

Whitelisted 404 URLs

URLs in this whitelist will not be counted against the throttling rules that are used to limit crawlers. The default list includes site icons like “favicon.ico” and retina versions of images, which some browsers request even if they are not listed in your site’s HTML.

Enter one URL per line. URLs should begin with a slash, such as “/favicon.ico”.

Hide WordPress version

WordPress by default discloses what its version is. This will hide it from outsiders. we recommend you enable this.

Block IP's who send POST requests with blank User-Agent and Referer

Many badly written brute force hacking scripts send login attempts and comment spam attempts using a blank user-agent (in other words, they don't specify which browser they are) and blank referer headers (in other words they don't specify which URL they arrived from. Enabling this option will not only prevent requests like this from reaching your site, but it will immediately block the IP address the request originated from.

Hold anonymous comments using member emails for moderation

In WordPress it's possible for someone who is not a member on your website to post a comment and to specify an email address of a real member on your site. This behavior is suspicious and may be incorporated into a more sophisticated attack. So we suggest that you leave this option enabled which will hold those comments for moderation before they're published.

Filter comments for malware and phishing URL's

This runs all comments through the Google Safe Browsing list which is the list that Google uses to alert you that you're visiting an unsafe website in Chrome, their web browser. We use that same list and if you enable this we will check any comments posted for malware of phishing related URLs that Google have published. We strongly recommend you enable this. When enabled any comments with a bad URL will be held for moderation.

Check password strength on profile update

If you enable this option it will not alert a user that they have a weak password, unlike the "force strong passwords" feature above. However what this does is it will send the site admin an email alert telling that admin that a user has specified a weak password during a profile update. It simply lets you know who is using a weak password so that you can contact them and let them know that they may want to improve the password strength.

If you do contact one of your users or customers, make sure that you are clear that you do not actually know what their password is. You are only alerted that the password does not meet your site password strength requirements. That way they know you have not violated any reasonable expectation of privacy that they may have.

Participate in the Real-Time WordPress Security Network

Enabling this feature causes your site to anonymously share data with Wordfence on hack attempts. In return your WordPress site receives IP address information of hackers that are currently engaged in malicious activity so that your site can immediately block those hackers before they are able to attempt to break into your website.

When enabled Wordfence reports page not found errors, attempts by blocked IP addresses to access your site, attempts by hackers to access known malicious URLs that do not exist on your site but are clearly a hack attempt and login failure attempts. No personally identifiable data is sent and we also don't associate any of the data we do receive with your specific website. The data is aggregated on a real-time platform to determine which IP addresses are currently engaged in the most malicious activity and need to be blocked by our community. That data is then used by your site and other Wordfence protected sites to block those malicious IP addresses.

How much memory should Wordfence request when scanning

Most WordPress websites have a fixed amount of memory allocated by the hosting provider to perform the various functions that WordPress and it's themes and plugins provide.

In some cases a WordPress website has the ability to request an increase in the maximum allowed amount of memory by changing a PHP configuration setting while WordPress is executing. It does this by changing a php.ini configuration setting at run-time.

If your site is running out of memory while Wordfence is performing its various tasks and you would like to try to ask PHP to increase the maximum allowed memory when Wordfence executes, then you can set the amount of memory you want to request here. On our own site we have this set to '256' without quotes, which will request 256 megabytes of memory when Wordfence executes.

Note that Wordfence won't actually use that amount of memory, but setting this will ask PHP to increase the memory limit to whatever you specify so that in case Wordfence does use that amount of memory, PHP will only throw an error if the new maximum you have requested is reached.

On sites that have limited memory, this option does not always work to increase the memory limit. If you have tried to use this option and are still running out of memory, it is best to open a support ticket with your hosting provider to ask them for more memory.

Maximum execution time for each scan stage

Wordfence scans can take several minutes or longer on very large websites. Wordfence runs as a PHP application on your web server. Web servers are not designed to run long-running processes like Wordfence. So the way we have designed Wordfence to work is it runs a scan as a series of requests.

The web server will connect to itself and kick off a new web request to start a scan.

The scan will run for a few seconds and do some work.

After an amount of time determined by this setting (Max execution time per scan stage) Wordfence will pause the scan, save the data and again cause the web server to reconnect to itself to kick off the next stage.

The scan will make more progress and do more work.

After an amount of time specified by this setting the web server will again pause the scan, save the data and connect back to itself to do the next stage.

This series of loopbacks continues until the Wordfence scan is complete.

This setting controls how long a scan stage will run until it pauses, saves the scan data and causes the web server to connect back to itself to kick off the next stage.

If this value is not set, then Wordfence will use the max_execution_time in your PHP.ini configuration file divided by two. This ensures that Wordfence does not run longer than the allowed maximum by PHP.

If you are having trouble completing scans, then we suggest you try several different values. The value you specify here must be greater than 10 or Wordfence will use its own default values.

First try 30, save and do a scan. If the scan does not complete, then try 15, save and do a scan. If it still doesn't complete then try 12. If you still don't have any luck getting a scan to complete, then there may be another problem or you may have to ask your hosting provider to increase the amount of time a web server process is allowed to execute.

The goal is to find a value that is long enough to allow Wordfence to do some work, but short enough so that it does not exceed the maximum allowed time that a web server process is allowed to execute.

Update interval in seconds

This option specifies how often the view in your admin interface for Wordfence is updated. This applies specifically to real-time views like Live Traffic and the Scan page. On both pages, data appears in real-time as progress is occurring.

Wordfence will cause your web browser to repeatedly send a request to check if new data is available. Those requests consume CPU and on web hosting providers that don't provide many resources you may receive complaints from your host about the resources you are using when viewing Live Traffic and leaving your web browser window open.

By changing this setting which controls how often the live data is refreshed, from the default of 2 seconds to something like 10 or 15 seconds, you dramatically reduce the amount of processing power that viewing Live Traffic or the Scan page will consume.

Please note that this setting does not control how much resources performing a Wordfence scan consumes. Only how often your web browser connects to your site to refresh Wordfence data so that you can see the changes. Increasing this value which decreases the frequency can help reduce resource usage on resource limited sites.

Enable debugging mode (increases database load)

This will enable verbose logging in Wordfence. A lot more will be written to the log which you can see on the 'Scan' page in the lower yellow box.

More of the additional activity written to the log can be seen when you perform a scan. However during many other operations we do additional logging if this option is enabled.

Note that when this option is enabled, a significant amount of additional data is written to the database, so it increases your site's database, network and CPU load significantly. We recommend you only enable this option for short periods of time (an hour at a time) while you are trying to solve a specific problem with Wordfence.

Delete Wordfence tables and data on deactivation?

By default if you disable Wordfence, the database tables will remain in place with their data. This is to ensure that if you accidentally or temporarily disable Wordfence you won't lose your configuration or the data you have accumulated like the live traffic data.

If you would like to remove all Wordfence data when you deactivate the plugin, check this box and when you disable the plugin all tables, entries in the WordPress options table, scheduled jobs and any other stored data associated with Wordfence will be removed.

If you then reactivate Wordfence it will appear as if it has been activated on your website for the first time.

Disable Wordfence Cookies

Wordfence uses cookies for three tasks:

To uniquely identify visitors shown in Wordfence Live traffic.

To track a user who was previously logged into WordPress but has logged out to ensure that Falcon cache does not show that user cached pages.

If a user has visited a unique page that allows them to bypass country blocking a cookie is set to identify that user so that country blocking does not prevent them from viewing the site.

If you enable this option cookies will be disabled in Wordfence. For the most part, Wordfence will function normally. The only effect is:

All page views in live traffic will appear as new visits.

Falcon may show previously logged in users cached pages.

Country blocking bypass by visiting a special hidden URL will not function correctly.

Start all scans remotely

Wordfence usually starts scans by having the server connect to itself to launch another long running web request which performs the scan. Some servers are unable to connect to themselves correctly so we have created a mechanism which causes your Wordfence installation to connect to our servers which then connect back to your servers to start the scan.

Note that this uses a secure token which prevents any user on the public Internet from starting a scan.

Enable this option if you are having trouble starting scans.

Disable config caching

Enabling this option fixes several problems we have seen reported with Wordfence options not saving, scans complaining about an incorrect cron key and a few other issues.

Wordfence has configuration data, mostly what you see on the Wordfence options page, which is saved in the database. During a normal web request when Wordfence is enabled it requires a certain amount of work to fetch that data from the database. PHP, the programming language that WordPress and Wordfence use, is able to fetch data from files faster than it can from the database under certain conditions. So Wordfence, as a performance enhancement, stores a temporary copy of it's own configuration data in a file. Then it fetches it from that file.

When you make a configuration change, or when something in Wordfence's data changes, it updates that file and the database so that they remain synchronized.

Sometimes the file that Wordfence stores the data in is not changeable. This can occur for a variety of reasons, but most often it's a file permissions issue.

By disabling config caching, you cause Wordfence to always fetch it's own data from the database which can solve any problems it may have with this temporary file.

If you would like to enable this option, change only this option on the Wordfence Diagnostics page (near the bottom), then save, then reload the page and make any other changes you would like to make. This will ensure that you first disable config caching to fix any problem that may exist and then when the page reloads you can write data directly to the database without any problem with the cache file existing.

To be clear: The vast majority of WordPress installs have no problem with config caching, so we only provide this for those rare installations that do have a problem with it.

Add a debugging comment to HTML source of cached pages

Enabling this option will add a small HTML comment to the end of all pages that are cached by Falcon Engine in Wordfence. This allows you to view the source of any of your HTML pages, scroll to the bottom and if you see the comment that Falcon added, it confirms that the page you are viewing was served from the cache.

Disable Code Execution for Uploads directory

Enabling this option will place a .htaccess file in your wp-content/uploads/ directory which prevents any PHP code in your uploads directory from executing. This is an added level of protection against a hacker managing to upload PHP code into your uploads directory. Even if they manage to do that, the code won't execute if you have this option enabled. The contents of the .htaccess at the time of this writing is:

Enable SSL Verification

SSL verification should normally be enabled, but it can be disabled if you are consistently unable to connect to the Wordfence servers. You can test your site’s connection to Wordfence using the link “Click to test connectivity to the Wordfence API servers” near the bottom of the Options page.

Click to test connectivity to the Wordfence API servers

This connects to noc1.wordfence.com and shows you the status of the connection attempt. It is a way to verify that your server is able to communicate with our scanning server on both port 80 and the secure port 443.

If this test fails, please open a support ticket with your hosting provider and ask them to ensure that your server is able to connect to noc1.wordfence.com on port 80 and port 443. They may have to allow your server to connect through a firewall or configure a proxy to allow this connection.

Click to view your system's configuration in a new window

This shows you a large amount of useful configuration information about your web server. Internally this calls a function called phpinfo() and sends the output to your web browser. It also ensures that only site administrators are able to view this information.

Click to view your system's scheduled jobs in a new window

This shows you what jobs are scheduled to run in the WordPress cron job system. This is used for debugging and our support personnel may ask you to send them this information as part of a troubleshooting process. We show all scheduled jobs, not just jobs related to Wordfence.

Click to see a list of your system's database tables in a new window

This shows you all tables in your WordPress database. This is also used for diagnostics by our team and they may ask you to send them this data. The page shows all tables including additional information about each table.

Test your WordPress host's available memory

This test will create a data structure that contains approximately 80 megabytes of memory to test if your web server allows you to allocate at least that much memory. We consider this the absolute minimum for Wordfence operation. If this test fails you should contact your hosting provider and ask them to allocate more memory to your WordPress server.

Send a test email from this WordPress server to an email address

This is a way to test if email from your WordPress system is working. Enter your own email address and hit the send button. If you don't receive an email (and remember to check your spam folder) then log a support ticket with your hosting provider to investigate why your WordPress server is unable to successfully send email.

Exporting and Importing Wordfence Settings

Many of our customers run hundreds or thousands of websites that are protected by Wordfence. We provide a way for you to set up Wordfence on a single site and then export those settings to be imported on one or thousands of other sites. We've made this very easy and secure.

Your settings are exported to our servers - the same servers that help scan your website. They are stored there and are only accessible via a unique secret token which we give you when you export your settings. The token is a long alphanumeric string and is impossible to guess, so as long as you keep it secret, no one else can access your settings and you can use that token to import your Wordfence settings to as many other WordPress servers as you would like.

Exporting your Wordfence Settings

To export your Wordfence settings, simply scroll to the bottom of your Wordfence options page and click the button to export your settings. You will be given a secure token which is an alphanumeric string approximately 128 characters long. Please keep this secure because if anyone else gains access to this string they will be able to import your Wordfence settings (excluding your API key). You should think of your token like a password. Currently Wordfence does not expire these tokens, so your exported settings will be available indefinitely. This policy may change in future.

Importing your Wordfence Settings into another website

Once you've exported your Wordfence settings you're ready to import them on another site. Sign into the website where you would like to import your Wordfence settings. Go to your Wordfence options page and scroll to the bottom. Paste the token into the text field next to the "Import Settings" label. Then click the "Import Settings" button provided.

Your settings should be instantly imported. You will be shown a message telling you how many Wordfence options were imported and you will be asked to reload the current page. You can simply click the button provided to reload the page and see your new settings.

Got thousands of sites where you need to import settings? No problem.

If you are a hosting provider or developer who administers thousands of Wordfence websites, you can use our API to import your settings. We've provided a PHP function which you can call from inside WordPress if the Wordfence plugin is enabled:

Just set the $token variable to be equal to your secret token you were assigned when your settings were exported. You'll notice we've enclosed the call in a try/catch block. If a problem occurs Wordfence will throw an error with a helpful explanation which you can access via the exception mechanism.