How to Audit and Harden Plesk Against Automated Vulnerability Scanners

Last Reviewed and Updated on August 1, 2024

Introduction

Automated vulnerability scanners like Nikto, OpenVAS, and skipfish are commonly used by both security professionals and malicious actors to probe web servers for known vulnerabilities. While these tools can be helpful in ethical testing, they can also be leveraged in reconnaissance attacks.

This guide focuses on auditing and hardening a Plesk server against such automated scanners using logging analysis, rate limiting, Web Application Firewall (WAF) configuration, and access control mechanisms—all tailored for Linux-based environments.

1. Identifying Automated Scanner Activity

Common Scanner Signatures

Scanners often leave identifiable footprints:

User-Agent Headers: Tools like Nikto and skipfish use unique user-agent strings.
URL Patterns: Repeated, systematic access to non-existent or outdated resources.
High Request Frequency: Scanners usually hit endpoints at abnormal speed.

Log Analysis in Plesk

Apache and NGINX logs in Plesk are stored in:

/var/www/vhosts/system/<domain>/logs/

To detect suspicious user agents:

grep -iE "Nikto|skipfish|OpenVAS" /var/www/vhosts/system/*/logs/access_log

To detect IPs generating high-frequency traffic:

awk '{print $1}' /var/www/vhosts/system/*/logs/access_log | sort | uniq -c | sort -nr | head

Consider automating this process using tools like GoAccess or Fail2Ban.

2. Setting Up Rate Limiting

Rate limiting helps mitigate scanners by restricting the number of requests an IP can make in a given period.

NGINX Rate Limiting (If Used)

Edit your NGINX config (or use custom directives via Plesk):

limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;

server {
    location / {
        limit_req zone=one burst=5 nodelay;
    }
}

Apache Mod_Ratelimit

For Apache, enable and configure mod_ratelimit:

<IfModule mod_ratelimit.c>
    SetOutputFilter RATE_LIMIT
    SetEnv rate-limit 400
</IfModule>

This limits download rates but is less effective for request-based rate limiting. Consider alternatives like ModSecurity or fail2ban for behavioral limits.

3. Enabling and Configuring ModSecurity WAF

Plesk supports ModSecurity out of the box. Ensure it is enabled and configured with a robust rule set such as OWASP CRS or Atomicorp.

Steps:

Go to Tools & Settings > Web Application Firewall (ModSecurity).
Choose a rule set (recommended: OWASP ModSecurity Core Rule Set).
Set the security level to “Advanced” or higher.
Enable detection and blocking.

Custom Rules for Scanners

You can add custom ModSecurity rules to block known scanner signatures:

SecRule REQUEST_HEADERS:User-Agent "@rx Nikto|skipfish|OpenVAS" "id:1001,phase:1,deny,status:403,msg:'Scanner blocked'"

Rules can be placed in:

/etc/modsecurity.d/rules/custom_rules.conf

4. Restricting Access to Sensitive Endpoints

Scanners often target well-known endpoints (e.g., /phpmyadmin, /wp-login.php, /cgi-bin/). Locking down these endpoints minimizes your exposure.

Best Practices:

Remove unused applications and default files.
Use .htaccess or NGINX rules to restrict access to specific IPs.
Move login panels to custom URLs.

Example .htaccess for IP restriction:

<Files "wp-login.php">
    Order Deny,Allow
    Deny from all
    Allow from 192.0.2.1
</Files>

5. Hardening Plesk Configuration

A few system-wide settings can greatly reduce your attack surface.

Disable Directory Listing

Make sure directory browsing is turned off in Apache or NGINX.

Enable Fail2Ban

Fail2Ban monitors log files and bans IPs that show malicious behavior. Plesk integrates Fail2Ban with useful jail templates.

Enable via:

Tools & Settings > IP Address Banning (Fail2Ban)

Add custom filters for scanner patterns in:

/etc/fail2ban/filter.d/

6. Ongoing Monitoring and Maintenance

Monitor with GoAccess or Logwatch

Tools like GoAccess offer real-time log analysis that can help identify new threats.

Run Regular Security Audits

Run vulnerability scans against your own server to verify the effectiveness of your configurations:

Ensure that your mitigation techniques are not overly aggressive and do not impact legitimate users.

Conclusion

Auditing and hardening your Plesk server against automated vulnerability scanners is a crucial step in maintaining a secure hosting environment. By detecting scanner patterns, implementing rate limiting, enabling a WAF, and locking down sensitive endpoints, you can significantly reduce your exposure.

While no single method is foolproof, a layered defense strategy ensures that even if one protection fails, others are in place to mitigate risk.