NinjaFirewall (WP/WP+ Edition)



The Overview page shows information about the firewall status. We recommend you keep an eye on it, because in case of problems, all possible errors and warnings will be displayed here.


Monthly stats:

Statistics are taken from the current log. It is rotated on the first day of each month. You can view the log by clicking on the Firewall Log menu.


Benchmarks show the time NinjaFirewall took, in seconds, to process each request it has blocked.

Firewall Options

Firewall protection:

This option allows you to disable NinjaFirewall. It has basically the same effect as deactivating it from the Plugins menu page. Your site will remain unprotected until you enable it again.

Use shared memory (!! WP+ edition only !!):

This feature allows NinjaFirewall to use Unix shared memory segments in order to speed up all operations. The firewall will no longer need to connect to the database and, instead, will retrieve its options and configuration directly from memory (RAM). On a very busy server (e.g., multisite network etc), this feature can dramatically increase the processing speed from 25% to 30%, prevent blocking I/O and slow queries.

This option requires that your PHP version was compiled with the --enable-shmop parameter, otherwise, if it is not compatible with your server/hosting environment, it will be disabled.
If you are using GB2312 character set (A.K.A GBK - simplified Chinese characters) for your database, we recommend to disable that option otherwise NinjaFirewall will not have access to the database and it may not be able to properly sanitise multi-byte characters used by that charset.

Debugging mode:

In Debugging mode, NinjaFirewall will not block or sanitise suspicious requests but will only log them (the firewall log will display DEBUG_ON in the LEVEL column).

We recommend to run it in Debugging Mode for at least 24 hours after installing it on a new site and then to keep an eye on the firewall log during that time. If you notice a false positive in the log, you can simply use NinjaFirewall's Rules Editor to disable the security rule that was wrongly triggered.

Error code and message to return:

Lets you customize the HTTP error code returned by NinjaFirewall when blocking a dangerous request and the message to display to the user. You can use any HTML tags and 3 built-in variables:

    %%REM_ADDRESS%% : the blocked user IP.

    %%NUM_INCIDENT%% : the unique incident number as it will appear in the firewall log "INCIDENT" column.

    %%NINJA_LOGO%% : NinjaFirewall logo.

Export/import configuration:

This options lets you export you current configuration or import it from another NinjaFirewall (WP edition) installation. The imported file must match the major version of your current version (e.g., v3.x) otherwise it will be rejected.
Note that importing will override all firewall rules, options and configuration, except your WP+ edition license.

Configuration backup:

NinjaFirewall will automatically backup its configuration (options, policies and rules) everyday for the last 5 days. If you want to restore its configuration to an earlier date, select the corresponding file in the list.

Firewall Policies

Policies overview:

Because NinjaFirewall sits in front of WordPress, it can hook, scan and sanitise all PHP requests, HTTP variables, headers and IPs before they reach your blog: $_GET, $_POST, $_COOKIE, $_REQUEST, $_FILES, $_SERVER in either or both HTTP & HTTPS mode.
Use the options below to enable, disable or to tweak these rules according to your needs.
Keep in mind, however, that the Firewall Policies apply to any PHP scripts located inside your WordPress directory and its sub-directories, and not only to your index page.

Scan & Sanitise:

You can choose to scan and reject dangerous content but also to sanitise requests and variables. Those 2 actions are different and can be combined together for better security.

    Scan: if anything suspicious is detected, NinjaFirewall will block the request and return an HTTP error code and message. The user request will fail and the connection will be closed immediately.

    Sanitise: this option will not block but sanitise the user request by escaping characters that can be used to exploit vulnerabilities (', ", \, \n, \r, `, \x1a, \x00, *, ?') and replacing < and > with their corresponding HTML entities (&lt;, &gt;). If it is a variable, i.e. ?name=value, both its name and value will be sanitised.
    This action will be performed when the filtering process is over, right before NinjaFirewall forwards the request to your PHP script.

    If you enabled POST requests sanitising, articles and messages posted by your visitors could be corrupted with excessive backslashes or substitute characters.


Whether to filter HTTP and/or HTTPS traffic.


    File Uploads: you can allow/disallow uploads, or* allow uploads but block scripts (PHP, CGI, Ruby, Python, bash/shell), C/C++ source code, binaries (MZ/PE/NE and ELF formats), system files (.htaccess, .htpasswd and PHP INI) and SVG files containing Javascript/XML events.

    Sanitise filenames: any character that is not a letter a-zA-Z, a digit 0-9, a dot ., a hyphen - or an underscore _ will be removed from the filename and replaced with the X character.

    Maximum allowed file size:* if you allow uploads, you can select the maximum size of an uploaded file. Any file bigger than this value will be rejected. Note that if your PHP configuration uses the upload_max_filesize directive, it will be used before NinjaFirewall.

* !! WP+ edition only !!


    Block attempts to modify important WordPress settings: enabling this policy will block any attempt (e.g., exploiting a vulnerability, using a backdoor etc) to modify some important WordPress settings. This policy will also send you an alert by email with all details regarding the issue. It is enabled by default.

    Block user accounts creation: enabling this policy will block any attempt (e.g., exploiting a vulnerability, using a backdoor etc) to create a user account. If you allow user registration, you should not enable it.

HTTP GET variable:

Whether to scan and/or sanitise the GET variable.

HTTP POST variable:

    Whether to scan and/or sanitise the POST variable.

    Decode base64-encoded POST variable: NinjaFirewall will decode and scan base64 encoded values in order to detect obfuscated malicious code. This option is only available for the POST variable.

HTTP REQUEST variable:

Whether to sanitise the REQUEST variable.


Whether to scan and/or sanitise cookies.

HTTP_USER_AGENT server variable:

Whether to scan and/or sanitise HTTP_USER_AGENT requests.

HTTP_REFERER server variable:

    Whether to scan and/or sanitise HTTP_REFERER requests.

    Block POST requests that do not have an HTTP_REFERER header: this option will block any POST request that does not have a Referrer header (HTTP_REFERER variable). If you need external applications to post to your scripts (e.g. Paypal IPN, WordPress WP-Cron etc), you are advised to keep this option disabled otherwise they will likely be blocked. Note that POST requests are not required to have a Referrer header and, for that reason, this option is disabled by default.

HTTP response headers:

In addition to filtering incoming requests, NinjaFirewall can also hook the HTTP response in order to alter its headers. Those modifications can help to mitigate threats such as XSS, phishing and clickjacking attacks.

    Set X-Content-Type-Options to protect against MIME type confusion attacks: sending this response header with the nosniff value will prevent compatible browsers from MIME-sniffing a response away from the declared content-type.

    Set X-Frame-Options to protect against clickjacking attempts: this header indicates a policy whether a browser must not allow to render a page in a <frame> or <iframe>. Hosts can declare this policy in the header of their HTTP responses to prevent clickjacking attacks, by ensuring that their content is not embedded into other pages or frames. NinjaFirewall accepts two different values:

    • SAMEORIGIN: a browser receiving content with this header must not display this content in any frame from a page of different origin than the content itself.
    • DENY: a browser receiving content with this header must not display this content in any frame.

    Set X-XSS-Protection (IE/Edge, Chrome, Opera and Safari browsers): this header allows browsers to identify and block XSS attacks by preventing malicious scripts from executing. It is enabled by default on all compatible browsers.

    If a visitor disabled their browser's XSS filter, you cannot re-enable it with this header.

    Force HttpOnly flag on all cookies to mitigate XSS attacks: adding this flag to cookies helps to mitigate the risk of cross-site scripting by preventing them from being accessed through client-side script. NinjaFirewall can hook all cookies sent by your blog, its plugins or any other PHP script, add the HttpOnly flag if it is missing, and re-inject those cookies back into your server HTTP response headers right before they are sent to your visitors. Note that WordPress sets that flag on the logged in user cookies only.

    Set Strict-Transport-Security (HSTS) to enforce secure connections to the server: this policy enforces secure HTTPS connections to the server. Web browsers will not allow the user to access the web application over insecure HTTP protocol. It helps to defend against cookie hijacking and Man-in-the-middle attacks. Most recent browsers support HSTS headers.

    Set Content-Security-Policy: this policy helps to mitigate threats such as XSS, phishing and clickjacking attacks. It covers JavaScript, CSS, HTML frames, web workers, fonts, images, objects (Java, ActiveX, audio and video files), and other HTML5 features. NinjaFirewall lets you configure the CSP policy separately for the frontend (blog, website) and the backend (WordPress admin dashboard).

    Set Referrer-Policy: this HTTP header governs which referrer information, sent in the Referer header, should be included with requests made.

    • no-referrer: The Referer header will be omitted entirely. No referrer information is sent along with requests.
    • no-referrer-when-downgrade: This is the user agent's default behavior if no policy is specified. The URL is sent as a referrer when the protocol security level stays the same (HTTP→HTTP, HTTPS→HTTPS), but isn't sent to a less secure destination (HTTPS→HTTP).
    • origin: Only send the origin of the document as the referrer in all cases. The document will send the referrer
    • origin-when-cross-origin: Send a full URL when performing a same-origin request, but only send the origin of the document for other cases.
    • strict-origin: Only send the origin of the document as the referrer to a-priori as-much-secure destination (HTTPS→HTTPS), but don't send it to a less secure destination (HTTPS→HTTP).
    • strict-origin-when-cross-origin: Send a full URL when performing a same-origin request, only send the origin of the document to a-priori as-much-secure destination (HTTPS→HTTPS), and send no header to a less secure destination (HTTPS→HTTP).
    • same-origin: A referrer will be sent for same-site origins, but cross-origin requests will contain no referrer information.
    • unsafe-url: Send a full URL when performing a same-origin or cross-origin request.

IP (WP edition only):

    Block localhost IP in GET/POST requests: this option will block any GET or POST request containing the localhost IP ( It can be useful to block SQL dumpers and various hacker's shell scripts.

    Block HTTP requests with an IP in the HTTP_HOST header: this option will reject any request using an IP instead of a domain name in the Host header of the HTTP request. Unless you need to connect to your site using its IP address, (e.g., enabling this option will block a lot of hackers scanners because such applications scan IPs rather than domain names.

    Scan traffic coming from localhost and private IP address spaces: this option will allow the firewall to scan traffic from all non-routable private IPs (IPv4 and IPv6) as well as the localhost IP. We recommend to keep it enabled if you have a private network (2 or more servers interconnected).


    Block PHP built-in wrappers: PHP has several wrappers for use with the filesystem functions. It is possible for an attacker to use them to bypass firewalls and various IDS to exploit remote and local file inclusions. This option lets you block any script attempting to pass a expect://, file://, phar://, php://, zip:// or data:// stream inside a GET or POST request, cookies, user agent and referrer variables.

    Block serialized PHP objects: Object Serialization is a PHP feature used by many applications to generate a storable representation of a value. However, some insecure PHP applications and plugins can turn that feature into a critical vulnerability called PHP Object Injection. When this option is enabled, NinjaFirewall will block serialized PHP objects found in GET, POST, COOKIE, HTTP_USER_AGENT and HTTP_REFERER. By default, it is disabled.

    Hide PHP notice & error messages: this option lets you hide errors returned by your scripts. Such errors can leak sensitive informations which can be exploited by hackers.

    Sanitise PHP_SELF, PATH_TRANSLATED, PATH_INFO: this option can sanitise any dangerous characters found in those 3 server variables to prevent various XSS and database injection attempts.


    Block the DOCUMENT_ROOT server variable in HTTP requests: this option will block scripts attempting to pass the DOCUMENT_ROOT server variable in a GET or POST request. Hackers use shell scripts that often need to pass this value, but most legitimate programs do not.

    Block ASCII character 0x00 (NULL byte): this option will reject any GET or POST request, COOKIE, HTTP_USER_AGENT, REQUEST_URI, PHP_SELF, PATH_INFO variables containing the ASCII character 0x00 (NULL byte). Such a character is dangerous and should always be rejected.

    Block ASCII control characters 1 to 8 and 14 to 31: in most cases, those control characters are not needed.

    Block localhost IP in GET/POST requests : this option will block any GET or POST request containing the localhost IP ( It can be useful to block SQL dumpers and various hacker's shell scripts.

    Block HTTP requests with an IP in the HTTP_HOST header: this option will reject any request using an IP instead of a domain name in the Host header of the HTTP request. Unless you need to connect to your site using its IP address, (e.g., enabling this option will block a lot of hackers scanners because such applications scan IPs rather than domain names.


    Whether to block direct access to PHP files located in specific WordPress directories.

    Block user accounts creation: enabling this policy will block any attempt (e.g., exploiting a vulnerability, using a backdoor etc) to create a user account. If you allow user registration, you should not enable it.

    WordPress AJAX: many vulnerabilities in plugins are exploited via the admin-ajax.php script. This policy will try to detect and immediately block bots and malicious scanners trying to access it. The server IP address and private IP addresses will not be blocked.

    Protect against username enumeration: it is possible to enumerate usernames either through the WordPress author archives, the REST API or the login page. Although this is not a vulnerability but a WordPress feature, some hackers use it to retrieve usernames in order to launch more accurate brute-force attacks. If it is a failed login attempt, NinjaFirewall will sanitise the error message returned by WordPress. If it is an author archives scan, it will invalidate it and redirect the user to the blog index page. Regarding the WP REST API, it will block the request immediately.

    WordPress REST API: it allows you to access your WordPress site's data through an easy-to-use HTTP REST API. Since WordPress 4.7, it is enabled by default. NinjaFirewall allows you to block any access to that API if you do not intend to use it.

    WordPress XML-RPC API: XML-RPC is a remote procedure call (RPC) protocol which uses XML to encode its calls and HTTP as a transport mechanism. WordPress has an XMLRPC API that can be accessed through the xmlrpc.php file. Since WordPress version 3.5, it is always activated and cannot be turned off. NinjaFirewall allows you to immediately block any access to that file, or only to block an access using the system.multicall method (often used in brute-force amplification attacks). If you are using applications that need to access that API such as the JetPack plugin or the WordPress Androis/iOS app, enable only the system.multicall protection otherwise your application will be blocked.

    Block POST requests in the themes folder /wp-content/themes: this option can be useful to block hackers from installing backdoor in the PHP theme files. However, because some custom themes may include an HTML form (contact or search form etc), this option is not enabled by default.

    Force SSL for admin and logins FORCE_SSL_ADMIN: enable this option when you want to secure logins and the admin area so that both passwords and cookies are never sent in the clear. Warning: ensure that you can access your admin console from HTTPS before enabling this option, otherwise you will lock yourself out of your site !

    Disable the plugin and theme editor DISALLOW_FILE_EDIT: disabling the plugin and theme editor provides an additional layer of security if a hacker gains access to a well-privileged user account.

    Disable plugin and theme update/installation DISALLOW_FILE_MODS: this option will block users being able to use the plugin and theme installation/update functionality from the WordPress admin area. Setting this constant also disables the Plugin and Theme editor.

    Disable the fatal error handler WP_Fatal_Error_Handler: this option will disable the WSOD protection introduced in WordPress 5.1.

Access Control (!! WP+ edition only !!)

Access Control is a powerful set of directives that can be used to allow or restrict access to your website based on many criteria.
To make better use of them, it is important to understand NinjaFirewall's directives processing order:

    Incoming HTTP request:

    1. .htninja file.
    2. Login Protection.
    3. Access Control (except User Input Access Control):
      1. Role-based Access Control.
      2. Allowed IPs.
      3. Blocked IPs.
      4. Allowed URLs.
      5. Blocked URLs.
      6. Bot Access Control.
      7. Geolocation.
      8. Rate Limiting.
    4. File Guard.
    5. NinjaFirewall built-in rules and policies + User Input Access Control.

    Response body:

    1. HTTP response headers.
    2. Web Filter.

Role-based Access Control:

By default, any logged in Administrator will not be blocked by NinjaFirewall. This applies to all Access Control directives listed below, as well as the Antispam, the Web Filter and the Firewall Policies, except FORCE_SSL_ADMIN, DISALLOW_FILE_EDIT, DISALLOW_FILE_MODS and the Login Protection options which, if enabled, will always be enforced.
You can also add other users to the whitelist, depending on their role.

Source IP:

    IP-based access control directives should use: this option should be used if you are behind a reverse proxy, a load balancer or using a CDN, in order to tell NinjaFirewall which IP it should use. By default, it will rely on REMOTE_ADDR. If you want it to use HTTP_X_FORWARDED_FOR or any other similar variable, it is absolutely necessary to ensure that it is reliable (i.e., setup by your own load balancer/reverse proxy) because it can be easily spoofed. If that variable includes more than one IP, only the left-most (the original client) will be checked. If it does not include any IP, NinjaFirewall will fall back to REMOTE_ADDR.

    Scan traffic coming from localhost and private IP address spaces: this option will allow the firewall to scan traffic from all non-routable private IPs (IPv4 and IPv6) as well as the localhost IP. We recommend to keep it enabled if you have a private network (2 or more servers interconnected).

HTTP Methods:

This option lets you select the HTTP method(s). All Access Control directives (Geolocation, IPs, bots and URLs) will only apply to the selected methods.
It does not apply to the Firewall Policies options, which use their own ones.

Geolocation Access Control:

You can filter and block traffic coming from specific countries.

     Retrieve ISO 3166 country code from: this is the two-letter country code that is used to define a country (e.g., US, UK, FR, DE etc), based on the visitors IP. NinjaFirewall can either retrieve it from its database, or from a predefined PHP variable added by your HTTP server (e.g., GEOIP_COUNTRY_CODE).

     Block visitors from the following countries: you can add/remove any country from the two listboxes. For more information about some specific ISO 3166 codes (A1, A2, AP, EU etc), you may want to consult the MaxMind GeoIP online help. By default, no country is blocked.

     Geolocation should apply to the whole site or specific URLs only: whether geolocation should apply to the whole site or to specific URLs only (e.g., /wp-login.php, /xmlrpc.php etc). Leave all fields empty if you want it to apply to the whole site.

     Append NINJA_COUNTRY_CODE to PHP headers: after retrieving the two-letter country code, NinjaFirewall can add it to the PHP headers in the $_SERVER["NINJA_COUNTRY_CODE"] variable. If you have a theme or a plugin that needs to know your visitors location, simply use that variable.

    If NinjaFirewall cannot find the two-letter country code, it will replace it with 2 hyphens (--).

    PHP code example to use in your theme or plugin to geolocate your visitors :

    NinjaFirewall includes GeoLite data created by MaxMind

IP / URL / Bot Access Control:

     IP Access Control: you can permanently allow/block an IP or a whole range of IP addresses. IPv4 and IPv6 are fully supported by NinjaFirewall:

    • Full IP:
    • IP ranges using CIDR notation: (IPv4) or 2c0f:f248::/32 (IPv6).

     Rate Limiting : this option allows you to slow down aggressive bots, crawlers, web scrapers or even small HTTP attacks. Any IP reaching the defined threshold will be banned from 1 to 999 seconds. Note that the purpose of this feature is not to permanently block an IP but rather to temporarily prevent it from accessing the site and abusing your system resources. If you want to permanently block an IP, use the blacklist instead. Also, do not rely on this option to block brute force attacks on the login page, use the more suitable Login Protection for that purpose. By default, Rate Limiting is turned off.

    IPs temporarily banned by the Rate Limiting option can be unblocked immediately by clicking either the "Save Access Control Directives" or "Restore Default Values" buttons.
    Because NinjaFirewall can handle thousands of HTTP requests per second and block IPs even before your blog is loaded, we strongly recommend that you disable the rate limiting/throttling option of any other WordPress plugin that you may have installed and only use NinjaFirewall's one instead. It will drastically speed up your site and reduce the server load on a busy site or during an attack.

     URL Access Control: you can block any access to one or more PHP scripts based on their path, relative to the web root (SCRIPT_NAME). You can enter either a full or partial path (case-sensitive).

    • /foo/bar.php will block any access to the bar.php script located inside a /foo/ directory or sub-directory.

    • /foo/ will block access to all PHP scripts located inside a /foo/ directory.

    Note that the Firewall Policies page already includes restrictions to some WordPress directories.

     Bot Access Control: you can block bots, scanners and various crawlers based on the HTTP_USER_AGENT variable. You can enter either a full or partial name (case-insensitive).

User Input Access Control:

You can select to ignore or block some specific user input. It applies to the GET, POST and COOKIE global variables, for instance $_GET["foo"] or $_POST["bar"]:

  • When an input is added to the "Unfiltered input" list, it will not be filtered or sanitised. All other input present in the request will be filtered.
  • When an input is added to the "Blocked input", NinjaFirewall will block the request and close the connection if that input is found in the request.

Log Event:

You can enable/disable firewall logging for each access control directive separately. All but the "Allow the following IPs" directive have this option enabled by default.

File Guard

File Guard can detect, in real-time, any access to a PHP file that was recently modified or created, and alert you about this.
If a hacker uploaded a shell script to your site (or injected a backdoor into an already existing file) and tried to directly access that file using his browser or a script, NinjaFirewall would hook the HTTP request and immediately detect that the file was recently modified/created. It would send you a detailed alert (script name, IP, request, date and time). Alerts will be sent to the contact email address defined in the Event Notifications menu.

Modifications detected by NinjaFirewall include mtime (saved or updated content of a file) and ctime (inode change, e.g., permissions, ownership etc).

If you do not want to monitor a folder, you can exclude its full path or a part of it (e.g., /var/www/public_html/cache/ or /cache/ etc). NinjaFirewall will compare this value to the $_SERVER["SCRIPT_FILENAME"] server variable and, if it matches, will ignore it.

File Guard real-time detection is a totally unique feature, because NinjaFirewall is the only plugin for WordPress that can hook HTTP requests sent to any PHP script, even if that script is not part of the WordPress package (third-party software, shell script, backdoor etc).

File Check

File Check lets you perform file integrity monitoring upon request or on a specific interval (hourly, twicedaily, daily).
You need to create a snapshot of all your files and then, at a later time, you can scan your system to compare it with the previous snapshot. Any modification will be immediately detected: file content, file permissions, file ownership, timestamp (ctime and mtime) as well as file creation and deletion.

Create a snapshot of all files stored in that directory:

By default, the directory is set to WordPress ABSPATH.

Exclude the following files/folders:

You can enter a directory or a file name (e.g., /foo/bar/), or a part of it (e.g., foo). Or you can use an extension (e.g., .css).
Multiple value must be comma-separated (e.g., /foo/bar/,.css,.png).

Do not follow symbolic links:

By default, NinjaFirewall will not follow symbolic links.

Web Filter (!! WP+ edition only !!)

If NinjaFirewall can hook and scan incoming requests, it can also hook the response body (i.e., the output of the HTML page right before it is sent to your visitors browser) and search it for some specific keywords. Such a filter can be useful to detect hacking or malware patterns injected into your HTML code (text strings, spam links, malicious JavaScript code), hackers shell script, redirections and even errors (PHP/MySQL errors). Some suggested keywords as well as a default list are included.
In the case of a positive detection, NinjaFirewall will not block the response body but will send you an alert by email.

Search HTML page for keywords:

You can enter any keyword from 4 to 150 characters and select whether the search will be case sensitive or not.

Email Alerts:

You can use the notification throttling option to limit the frequency of alerts sent to you (and written to the firewall log) and select whether you want NinjaFirewall to send you the whole HTML source of the page where the keyword was found. Alerts will be sent to the contact email address defined in the Event Notifications menu.

Response body filtering can be resource-intensive. Try to limit the number of keywords to what you really need (<10) and/or, if possible, prefer case sensitive to case insensitive filtering.

Network (multi-site only)

Even if NinjaFirewall administration menu is only available to the Super Admin (from the main site), you can still display its status to all sites in the network by adding a small NinjaFirewall icon to their admin bar. It will be visible only to the administrators of those sites.
It is recommended to enable this feature as it is the only way to know whether the sites in your network are protected and if NinjaFirewall installation was successful.
Note that when it is disabled, the icon still remains visible to the Super Admin.

Event Notifications

NinjaFirewall can alert you by email on specific events triggered within your blog. They include installations, updates, activations etc, as well as users login and modification of any administrator account in the database. Some of those alerts are enabled by default and it is highly recommended to keep them enabled. It is not unusual for a hacker, after breaking into your WordPress admin console, to install or just to upload a backdoored plugin or theme in order to take full control of your website.

Login Protection

By processing incoming HTTP requests before your blog and any of its plugins, NinjaFirewall is the only plugin for WordPress able to protect it against very large brute-force attacks, including distributed attacks coming from several thousands of different IPs.

You can choose two different types of protection: a password or a captcha. You can enable the protection only if an attack is detected or to keep it always activated.

Yes, if under attack:

The protection will be triggered when too many login attempts are detected, regardless of the offending IP. It blocks the attack instantly and prevents it from reaching WordPress, but still allows you to access your administration console using either the predefined username/password combination or the captcha code.

Always ON:

NinjaFirewall will always enforce the HTTP authentication or captcha implementation each time you access the login page.

Type of protection:

Password: It password-protects the login page. NinjaFirewall uses its own very fast authentication scheme and it is compatible with any HTTP server (Apache, Nginx, Lighttpd etc).

Captcha: It will display a 5-character captcha code.

Bot protection: NinjaFirewall will attempt to block bots and scripts immediatly, i.e., even before they start a brute-force attack.

AUTH log:

NinjaFirewall can write to the server AUTH log when the brute-force protection is triggered. This can be useful to the system administrator for monitoring purposes or banning IPs at the server level.
If you have a shared hosting account, keep this option disabled as you do not have any access to the server's logs.
On Debian-based systems, the log is located in /var/log/auth.log, and on Red Hat-based systems in /var/log/secure. The logline uses the following format:

ninjafirewall[AA]: Possible brute-force attack from BB on CC (DD). Blocking access for EEmn.

    AA: the process ID (PID).

    BB: the offending IPv4 or IPv6 IP address.

    CC: the blog (sub-)domain name.

    DD: the target: it can be either wp-login.php or XML-RPC API.

    EE: the time, in minutes, the protection will remain active.

Sample loglines:
Be careful if you are behind a load balancer, reverse-proxy or CDN because NinjaFirewall will always record the REMOTE_ADDR IP. If you have an application parsing the AUTH log in order to ban IPs (e.g. Fail2ban), you must setup your HTTP server to forward the correct IP (or use the .htninja file), otherwise you will likely block legitimate users.

Antispam (!! WP+ edition only !!)

NinjaFirewall can protect your blog against spam without user interaction (e.g., CAPTCHA, math puzzles etc). The protection is totally transparent to your visitors.

Protection level:

Select the level of protection. In most cases, Low should be enough.

Apply protection to:

Whether to protect comment and/or registration forms.

If you are using a caching plugin, ensure you follow these steps:

  1. Set the Protection Level to "Low" only. Do not use another value, otherwise the antispam could behave erratically after a while.
  2. Flush/clear your cache immediately after enabling or disabling the antispam.

NinjaFirewall antispam feature works only with WordPress built-in comment and registration forms. If you are using third-party plugins to generate your forms, they will not be protected against spam.

Firewall Log

Firewall Log:

The firewall log displays blocked and sanitised requests as well as some useful information. It has 6 columns:

    DATE : date and time of the incident.

    INCIDENT : unique incident number/ID as it was displayed to the blocked user.

    LEVEL : level of severity (critical, high or medium), information (info, upload) and debugging mode (DEBUG_ON).

    RULE : reference of the NinjaFirewall built-in security rule that triggered the action. A hyphen (-) instead of a number means it was a rule from your own Firewall Policies or Access Control page.

    IP : the blocked user remote address.

    REQUEST : the HTTP request including offending variables & values as well as the reason the action was logged.


Allows you to export the log as a TSV (tab-separated values) text file.


Allows you to delete the currently viewed log.

Enable firewall log:*

You can disable/enable the firewall log from this menu.

Brute-force attacks will still be written to the firewall log, even if you disable it.

Auto-rotate log:*

NinjaFirewall will rotate its log automatically on the very first day of each month. If your site is very busy, you may want to allow it to rotate the log when it reaches a certain size (MB) as well.
By default, if will rotate the log each month or earlier, if it reaches 2 megabytes.
Rotated logs, if any, can be selected and viewed from the dropdown menu.

Syslog logging:*

In addition to the firewall log, events can also be redirected to the syslog server (LOG_USER facility). Consult our blog for more info.

* !! WP+ edition only !!

Log encoding:

By default, NinjaFirewall encodes the log using hexadecimal characters. You can disable the encoding or change it to base64 encoding by adding a specific constant to the .htninja configuration file:
  • define('NFW_LOG_ENCODING', 'none'); : This will disable the encoding.
  • define('NFW_LOG_ENCODING', 'b64'); : The firewall will use base64 encoding instead of hexadecimal encoding.

Centralized Logging (!! WP+ edition only !!)

Centralized Logging lets you remotely access the firewall log of all your NinjaFirewall protected websites from one single installation. You do not need any longer to log in to individual servers to analyse your log data. There is no limit to the number of websites you can connect to, and they can be running any edition of NinjaFirewall: WP, WP+, Pro or Pro+.

Secret key:

The secret key will be used to generate your public key. Enter at least 30 ASCII characters, or use the one randomly created by NinjaFirewall.

This server's IP address:

As an additional protection layer, you can restrict access to the remote website(s) to the main server's IP only. You can use IPv4 or IPv6. If you do not want any IP restriction, enter the * character instead.

Public key:

This is the public key that you will need to upload to each remote website (consult our blog for more info about it).

Remote websites URL:

Enter the full URL of your NinjaFirewall protected website(s) that you want to remotely access from the main server.

Centralized Logging will keep working even if NinjaFirewall is disabled. Use the "Centralized Logging" menu if you want to disable it.

Live Log

Live Log:

Live Log lets you watch your blog traffic in real time, just like the Unix tail -f command. Note that requests sent to static elements like JS/CSS files and images are not managed by NinjaFirewall.

You can enable/disable the monitoring process, change the refresh rate, clear the screen, enable automatic vertical scrolling and change the log format. You can also apply filters to include or exclude files and folders (REQUEST_URI).

Live Log does not make use of any WordPress core file (e.g., admin-ajax.php). It communicates directly with the firewall without loading WordPress bootstrap. Consequently, it is fast, light and it should not affect your server load, even if you set its refresh rate to the lowest value (5 seconds).

If you are using the optional .htninja configuration file to whitelist your IP, the Live Log feature will not work.

Rules Editor

Besides the Firewall Policies, NinjaFirewall includes also a large set of built-in rules used to protect your blog against the most common vulnerabilities and hacking attempts. They are always enabled and you cannot edit them, but if you notice that your visitors are wrongly blocked by some of those rules, you can use the Rules Editor below to disable them individually.

    Check your firewall log and find the rule ID you want to disable (it is displayed in the RULE column).

    Select its ID from the enabled rules list below and click the "Disable it" button.

Note: if the RULE column from your log shows a hyphen - instead of a number, that means that the rule can be changed in your Firewall Policies page.

Rules Update

To get the most efficient protection, you can ask NinjaFirewall to automatically update its security rules. It can check for updates hourly, twice daily or daily.
Each time a new vulnerability is found in WordPress or one of its plugins/themes, a new set of security rules will be made immediately available to protect against such vulnerability.
Only security rules will be downloaded. If a new version of NinjaFirewall (including new files, options and features) was available, it would have to be updated from the dashboard plugins menu as usual.

We recommend to enable this feature, as it is the only way to keep your WordPress secure against new vulnerabilities.