• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Question Custom rules for Mod Seruity 3.0 Nginx - WordPress protection

brother4

Basic Pleskian
Server operating system version
Ubuntu 22.04
Plesk version and microupdate number
Plesk Obsidian 18.0.64 Web Host Edition
Hey!
I would like to block an IP if any of the following URLs are accessed three times. Essentially, if a bot tries to access these files multiple times, it should be automatically blocked:
  • /wp-content/plugins/index.php
  • /admin/function.php
  • /wp-admin/user/network.php
  • /wp-content/plugins/core-plugin/include.php
Below is the code I came up with. I want to confirm if this setup will work correctly for Plesk with NGINX v3.0 and ModSecurity (Comodo) and if this implementation makes sense. Specifically, I'd like to know if this approach effectively logs the attempt and then silently drops the connection, eventually leading to IP blocking after repeated suspicious requests. I don't want to give any specific status codes back to the client to avoid tipping off attackers.

Code:
# Custom rule to monitor and block IP addresses for specific file requests
SecRule REQUEST_URI "@streq /wp-content/plugins/index.php" \
    "id:20001,phase:2,log,drop,msg:'Suspicious access detected to /wp-content/plugins/index.php',t:none,tag:'security',setvar:'ip.block_counter=+1',expirevar:'ip.block_counter=3600'"

SecRule REQUEST_URI "@streq /admin/function.php" \
    "id:20002,phase:2,log,drop,msg:'Suspicious access detected to /admin/function.php',t:none,tag:'security',setvar:'ip.block_counter=+1',expirevar:'ip.block_counter=3600'"

SecRule REQUEST_URI "@streq /wp-admin/user/network.php" \
    "id:20003,phase:2,log,drop,msg:'Suspicious access detected to /wp-admin/user/network.php',t:none,tag:'security',setvar:'ip.block_counter=+1',expirevar:'ip.block_counter=3600'"

SecRule REQUEST_URI "@streq /wp-content/plugins/core-plugin/include.php" \
    "id:20004,phase:2,log,drop,msg:'Suspicious access detected to /wp-content/plugins/core-plugin/include.php',t:none,tag:'security',setvar:'ip.block_counter=+1',expirevar:'ip.block_counter=3600'"

# Rule to automatically block an IP after multiple suspicious access attempts
SecRule IP:block_counter "@ge 3" \
    "id:20005,phase:1,log,drop,msg:'IP blocked due to multiple suspicious requests',t:none,setvar:'ip.block=1',expirevar:'ip.block=86400'"

  1. Will this setup work correctly with Plesk NGINX v3.0 and ModSecurity (Comodo Ruleset)?
  2. Does the use of drop (instead of deny) ensure that attackers do not receive any hints about why their connection was blocked?
  3. Is there anything I need to adjust or be aware of for this configuration to work smoothly in Plesk with NGINX as the web server?
Thank you!
 
Unfortunately I don't know the exact answers to your three questions as I don't have much experience with custom ModSecurity rules. However if your objective is to ban/block any IP address which tries to access any of the URL's, you could also create a custom fail2ban filter and jail to accomplish that. Which I think is probably a bit more straight forward as it function independently from Nginx or Apache and any ModSecurity ruleset you're using,
 
@Kaspar Unfortunately, for a few days now, thousands of such bots have been sending corresponding requests to the web urls within a few hours, which places a heavy load on the CPU. These requests are contained in each of these bot IPs. And are apparently not recognized by the previous Fail2Ban rules or ModSecurity filters (Comodo).

The plan was to include this in the custom instructions in the Plesk backend in the Mod Secuirty settings (/admin/web-app-firewall/settings)
 
Back
Top