nintechnet

You can try to manually make the change:

1. Click on the “Activate Full WAF mode” button.
2. Make your selection (or use the default one preferably).
3. Select “I want to make the changes myself”.
4. Follow the instructions and click the “Finish the installation” button.

Can you run the troubleshooter script and show me the results?

1. Download https://nintechnet.com/share/wp-check.txt
2. Rename it to “wp-check.php”.
3. Upload it into your WordPress root folder.
4. Go to https://YOUR WEBSITE/wp-check.php
5. Delete it afterwards.

Can you check the firewall log when you get the 403 Forbidden error, and paste the corresponding line here?

That is the logo on the page displayed to the blocked user. You can adjust its path in the “Firewall Options” page: scroll down to the bottom and simply click the “Save Firewall Options”. That will adjust the path to match the new server/site.

Can you try to run this script and paste the results here: https://nintechnet.com/share/ninja-connect.txt

1. Rename it to ninja-connect.php
2. Upload it over FTP into your WordPress root folder.
3. Go to https://your-website/ninja-connect.php
4. Delete it afterwards.

We can’t replace session_start as that would require to rewrite the whole plugin.
There’s no problem to run 50 or 100+ HTTP requests with NF, many applications use session_start without any issue as well (Magento etc). But in your case, there’s a problem/conflict with an application (plugin or theme) and, due to the way PHP sessions work, it hangs and subsequent requests are queued. You would need to find which plugin/theme it is:
* With a profiler: disable NF from the plugin page and, if it was loaded via the PHP INI file, comment out the auto_prepend_file directive as well. Then run the xhprof or xdebug.
* Without a profiler: keep NF enabled, disable your plugins one by one and, each time, open/edit a post to see if it is still slow or not, until you find the right plugin. Don’t forget to try to switch the theme too, as it could be it.
As soon as you narrow to one plugin or theme, tell me which one it is and we’ll make some tests to see what’s going on.

You can’t because it has to be the real script (SCRIPT_NAME), not a permalink. The main goal of the brute-force protection is to work before WordPress and the DB load.
But there are plenty of WordPress Captcha plugins available here in the repo that will likely work with your configuration.

Do you see any warning or error in the “Tools > Site Health” page ?
Could you paste here the list of your plugins/theme that use PHP sessions ? You can scan the whole /wp-content/plugins and the main theme folder, and search for session_start.

I don’t know why they consider it a security issue, but if they disabled it, you can’t use the profiler.
Did you try to install a copy of your website on your local computer? That way, you could use the profiler.

Your PHP interpreter doesn’t have the register_tick_function function. That function is available in all PHP versions since 4.x.
Did you disable it? Or maybe your host did it?

I can’t reproduce the problem. As there’s no error or log, the only way to find out if there’s a conflict with another plugin would be to disable them one by one and, each time, check if that resolves the problem. Hopefully, that would narrow the search to one plugin.

You should be able to upload your ZIP and ask NinjaScanner to compare its content to the files installed on your blog. See this post: https://blog.nintechnet.com/ninjascanner-powerful-antivirus-scanner-for-wordpress/?#integrity
Make sure to respect the naming convention.
Even if it is a free plugin available in the www.remarpro.com repo, the scanner will still use the uploaded ZIP file to check for its integrity.

We’ll add a function_exists call in the next release, but test it on your server because it may not always work as it depends on how the function was disabled.

Unfortunately, it only uses mail() because File Guard works before WordPress loads.
Maybe an alternative would be to try to load PHPMailer, which is included in WordPress. I will add that to our suggestions list so that we’ll make some tests.

Click the “Firewall Policies > Advanced Polices” tab and check the “Set Content-Security-Policy for the website frontend” and “Set Content-Security-Policy for the WordPress admin dashboard” policies. You likely have a script-src 'self' directive that is causing the problem. If it’s in the backend, then remove it from the “Set Content-Security-Policy for the WordPress admin dashboard” field.