dwinden

@patriweb

It is impossible to answer your question without proper investigation of your WordPress site.

It sounds like your site was already infected before the iTSec plugin was installed. You may think to have removed the infection from your site while in fact it is still infected or the vulnerability which is being used to infect your site is still present. Security plugins like iTSec will probably not protect you against such vulnerabilities.

You need to make sure your site is clean and you need to find out which vulnerability allowed attackers to infect your site.

So in short clean your site and plug the hole that allowed attackers to infect your site in the first place.

dwinden

@novawebse

Please show some respect for the solution provided and mark this topic as ‘resolved’.

dwinden

@eic2010

To restore all the default settings simply deactivate & delete the iTSec plugin. Then reinstall the plugin.

If an iTSec plugin feature is causing problems for your site you can disable the feature while trying to figure out a solution. Use the iTSec plugin Logs page to get an idea of what effect/impact enabled features have to your site.

The idea behind the iTSec plugin is to enable only those features that won’t cause your site any troubles.
But keep in mind with every feature that you disable your site becomes less secured. So ideally you would want to enable as much features as possible. For some features not to cause troubles for your site you may need to do some required tweaking first.

Yes, in case you are not allowing visitors to login (like not providing a login link on the frontend) Hide Backend is a very effective feature to prevent bots from doing automated login attempts.

dwinden

@eic2010

You can disable XMLRPC and then wait and see whether anything breaks on your site. If some functionality breaks then enable XMLRPC again.
You can disable/enable XMLRPC in the WordPress Tweaks section of the iTSec plugin Settings page.

Also verify you are using nginx web server from the iTSec plugin Dashboard page, System Information, Server Information, Server Type.

No, running your site on a nginx web server is not a problem.
Just a slight complication because any settings saved in the iTSec plugin specific nginx.conf file are by default not picked up by nginx.
You need to include the iTSec plugin specific nginx.conf file in the main nginx.conf configuration file (this is an extra manual configuration step for proper functioning of the iTSec plugin on a nginx web server) AND reload the nginx configuration after every iTSec plugin setting changed that is also written to the iTSec plugin specific nginx.conf file.

To compare with, if your site would be running on Apache web server, some iTSec plugin settings are saved to a .htaccess file. Since Apache by default processes the content of a .htaccess file on a http request the saved settings are picked up immediately.

File change detection simply scans all files in the WordPress install. If a .htaccess file is found it will be scanned no matter what web server you are running on. And if there were any changes to that file (for whatever reason) it will be reported as changed. This might indicate your site is actually not running on nginx but perhaps on Apache. Again verify this from the iTSec plugin Dashboard page. Or contact your hosting provider.

dwinden

@the Hack Repair Guy

Any idea which User Agent entry in the blacklist could cause this issue ?

dwinden

@aehageman

Indeed this issue is probably not related to this plugin.

I ran into the same error in my Apache web server error_log file.
Simply accessing any post or page from the frontend resulted in an internal server error 500 and a Request exceeded etc msg in the Apache error_log file.

And it was me that caused the issue.
Fixed it eventually in the .htaccess file.

This scenario may not apply to your env but it’s worth mentioning. There may be many other scenario’s leading to the same web server error.

I had this WordPress env set up locally using localhost and installed in a subfolder. So I was accessing it’s frontend as:

http://localhost/subfolder

The content of the .htaccess file looked like this:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /subfolder/
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /subfolder/index.php [L]
</IfModule>

# END WordPress

Then I decided to change my Apache web server config and add a virtual host so I would be able to access this env by simply using:

http://www.myvirtualhostdomain.nl

(Did the necessary search & replace in the database. Also added the necessary entry to my local hosts file in order to get http://www.myvirtualhostdomain.nl resolved to 127.0.0.1).

However I forgot to change the .htaccess file.

After changing the content of the .htaccess file to:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

the issue was resolved.

dwinden

@spielerinternet

Ok, I see.

There is a known minor issue with the Exclude Files and Folders and Ignore File Types settings as described in this topic.

Excluded Files & Folders & File Types will only be reported once incorrectly as deleted.
The next scan no incorrect deletions are reported.

Check the logs page (Select Filter: File Change History) and try and find the answer to my previous question:

Are the reported file changes related to excluded files & folders deletions only (or also Added & Changed) ?

dwinden