DDoS protection for
Plesk Obsidian servers

Back to Blog

Plesk's Unique Position in the Panel Market

Plesk occupies a different niche than cPanel or DirectAdmin. While cPanel dominates North American shared hosting and DirectAdmin serves the budget segment, Plesk has a strong presence in European hosting, Windows Server hosting, and web agencies that manage client sites. Plesk Obsidian supports both Linux (Debian, Ubuntu, CentOS, Rocky, AlmaLinux) and Windows Server, making it the only major control panel that runs natively on both operating systems.

This cross-platform nature is relevant to DDoS protection because the tools and techniques available differ dramatically between Linux and Windows. Linux administrators have iptables, nftables, and a deep ecosystem of packet filtering tools. Windows administrators have Windows Firewall, which offers basic port filtering but lacks the programmable packet processing pipeline that makes Linux firewalls effective at high PPS rates. A DDoS protection strategy for Plesk must account for both platforms.

Plesk also has an extension ecosystem that is more mature than DirectAdmin's but more fragmented than cPanel's. Extensions for security, monitoring, and hardening exist, but they are developed by third parties with varying levels of quality and maintenance. Critically, no Plesk extension provides actual DDoS detection. The extensions that claim to address DDoS are firewall management interfaces, not traffic analysis tools.

Plesk-Specific Attack Surfaces

Port 8443: The Plesk Panel

Plesk's web interface runs on port 8443 over HTTPS. Like cPanel's ports 2083 and 2087, this is a full web application that renders on every request. The Plesk panel is built on a PHP backend with a JavaScript frontend, and each page load involves session management, database queries to Plesk's internal MySQL/MariaDB database, and template rendering. Under normal use, this is fine. Under a flood of thousands of requests per second, the panel's backend processes saturate and legitimate access becomes impossible.

Plesk's panel also serves the Plesk REST API on the same port. The API is used by automation tools, hosting billing systems (like WHMCS), and Plesk extensions. If your billing system's provisioning queue sends API calls to a Plesk server whose port 8443 is being flooded, provisioning fails and your billing system logs errors that require manual cleanup.

The Plesk Extension Ecosystem

Plesk extensions install additional functionality that often introduces new listening services and attack surfaces. Popular extensions like Docker support, Git integration, and Node.js management each add processes and sometimes ports. The WordPress Toolkit, one of Plesk's most popular features, makes API calls to WordPress installations during scanning and updates. An attacker who understands Plesk's extension architecture can target extension-specific endpoints for application-layer attacks.

Mail Services

Plesk on Linux uses Postfix for SMTP and Dovecot for IMAP/POP3. On Windows, it uses MailEnable or hMailServer. The mail stack exposes ports 25, 110, 143, 465, 587, 993, and 995. Connection floods against any of these ports create process spawning storms that consume system resources and can affect all other services on the server.

FTP and Database Ports

Plesk exposes FTP (port 21, ProFTPd on Linux, Plesk's own FTP on Windows) and database access (port 3306 for MySQL if remote access is enabled). On Windows deployments, MSSQL may also be accessible on port 1433. Each additional listening port is another target.

Plesk Firewall Extension: What It Actually Does

Plesk includes a Firewall extension that provides a GUI for managing firewall rules. On Linux, it generates iptables or firewalld rules. On Windows, it manages Windows Firewall rules. The extension allows you to define allow/deny rules by IP, port, and protocol, and to set default policies for incoming and outgoing traffic.

What the Firewall extension does not do:

• It does not monitor traffic rates or detect anomalies
• It does not provide connection rate limiting (no equivalent to CSF's PORTFLOOD or CT_LIMIT)
• It does not track PPS or bandwidth metrics
• It does not integrate with upstream mitigation providers
• It does not differentiate between legitimate traffic spikes and attack traffic

The Plesk Firewall is strictly an access control tool. It is the equivalent of hand-editing iptables rules, just with a GUI. For DDoS protection, it provides the same level of defense as any basic firewall: it can block specific IPs or ports, but it cannot detect or respond to volumetric attacks.

# On Linux Plesk, you can add rate limiting rules directly via iptables
# These bypass the Plesk Firewall extension but coexist with it

# Limit SYN rate to Plesk panel
iptables -A INPUT -p tcp --dport 8443 --syn -m connlimit --connlimit-above 15 --connlimit-mask 32 -j DROP

# Limit overall SYN rate
iptables -A INPUT -p tcp --syn -m limit --limit 100/s --limit-burst 200 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP

# Save rules (Debian/Ubuntu)
iptables-save > /etc/iptables/rules.v4

Fail2Ban Integration in Plesk

Plesk Obsidian includes built-in Fail2Ban integration, which is one of its advantages over DirectAdmin. Fail2Ban monitors log files for patterns indicating malicious activity (failed logins, exploit attempts, excessive requests) and creates temporary firewall rules to block offending IPs.

Plesk's Fail2Ban configuration is accessible through Tools & Settings > IP Address Banning (Fail2Ban). It comes with pre-configured jails for Plesk panel login, SSH, Postfix, Dovecot, ProFTPd, and other services. You can tune the parameters:

# Plesk Fail2Ban settings (via CLI)
plesk bin ip_ban --update -ban-period 3600 -max-retries 5 -find-time 600

# This means: ban for 1 hour after 5 failures within 10 minutes

# Add custom jail for Nginx rate limiting (if using Nginx)
# Create /etc/fail2ban/jail.d/nginx-limit.conf
[nginx-limit-req]
enabled = true
filter = nginx-limit-req
action = iptables-multiport[name=nginx-limit-req, port="80,443"]
logpath = /var/log/nginx/error.log
findtime = 60
maxretry = 10
bantime = 600

Fail2Ban is significantly better than DirectAdmin's brute force monitor and comparable to cPHulk, but it shares the same fundamental limitation: it is reactive and log-based. Fail2Ban waits for log entries to appear, parses them, counts failures, and then acts. This process takes seconds at minimum. During a high-rate attack, thousands of malicious requests are processed before Fail2Ban creates a block rule. And like all host-based tools, Fail2Ban does nothing about volumetric attacks that saturate the network before packets reach the application layer.

Fail2Ban also struggles with distributed attacks. Its per-IP tracking works well against single-source brute force, but a botnet spreading requests across 10,000 IPs will not trigger per-IP thresholds. Each IP sends only a few requests, but the aggregate is a denial of service.

Windows-Specific Challenges

Plesk on Windows Server presents DDoS protection challenges that do not exist on Linux. Windows Firewall (Windows Defender Firewall with Advanced Security) handles basic port-level allow/deny rules, but it lacks the programmable packet processing that iptables provides. There is no equivalent to iptables rate limiting (-m limit), connection limiting (-m connlimit), or advanced packet matching on Windows.

No iptables, No nftables

On Linux, you can build sophisticated packet filtering chains that drop malicious traffic early in the processing pipeline with minimal CPU cost per packet. On Windows, packet filtering happens through the Windows Filtering Platform (WFP), which is less configurable and less efficient at high PPS rates. Third-party tools like netsh advfirewall provide some rule management, but the underlying packet processing is still Windows Filtering Platform.

# Windows: Basic firewall rules via netsh
# Block a specific IP
netsh advfirewall firewall add rule name="Block Attacker" dir=in action=block remoteip=203.0.113.42

# Block a subnet
netsh advfirewall firewall add rule name="Block Subnet" dir=in action=block remoteip=203.0.113.0/24

# Restrict Plesk panel access
netsh advfirewall firewall add rule name="Plesk Panel Allow" dir=in action=allow protocol=tcp localport=8443 remoteip=198.51.100.0/24
netsh advfirewall firewall add rule name="Plesk Panel Block" dir=in action=block protocol=tcp localport=8443

Notice what is missing: there is no rate limiting. You can allow or block, but you cannot say "allow up to 50 SYN packets per second from this source." This makes Windows Plesk servers fundamentally more vulnerable to application-layer DDoS attacks than their Linux counterparts. On Linux, iptables can drop flood traffic at the kernel level with negligible CPU cost per packet. On Windows, every packet reaching a service consumes application-level resources before the service can decide to reject it.

Fail2Ban Is Not Available on Windows

Plesk's Fail2Ban integration is Linux-only. On Windows, Plesk provides a simpler "IP Address Banning" feature that monitors login failures, but it lacks Fail2Ban's flexibility, custom jail support, and log parsing capabilities. Windows administrators are limited to the built-in login failure tracking and manual IP blocking.

IIS Considerations

Plesk on Windows can use IIS (Internet Information Services) as the web server. IIS has Dynamic IP Restrictions, which provides some rate limiting at the web server level:

# Enable Dynamic IP Restrictions in IIS
# Via PowerShell (IIS 10+)
Import-Module WebAdministration

# Set rate limit: deny if more than 20 requests in 200ms from same IP
Set-WebConfigurationProperty -Filter "system.webServer/security/dynamicIpSecurity/denyByConcurrentRequests" -Name "enabled" -Value "True"
Set-WebConfigurationProperty -Filter "system.webServer/security/dynamicIpSecurity/denyByConcurrentRequests" -Name "maxConcurrentRequests" -Value "20"

Set-WebConfigurationProperty -Filter "system.webServer/security/dynamicIpSecurity/denyByRequestRate" -Name "enabled" -Value "True"
Set-WebConfigurationProperty -Filter "system.webServer/security/dynamicIpSecurity/denyByRequestRate" -Name "maxRequests" -Value "30"
Set-WebConfigurationProperty -Filter "system.webServer/security/dynamicIpSecurity/denyByRequestRate" -Name "requestIntervalInMilliseconds" -Value "200"

IIS Dynamic IP Restrictions is better than nothing, but it only protects web traffic (ports 80/443) through IIS. It does not protect Plesk panel (8443), mail, FTP, or any other service. And like mod_evasive on Apache, it operates inside the web server process, meaning requests still consume connection and memory resources before being rejected.

Why Plesk's Extension Model Cannot Solve DDoS

Plesk's extension marketplace includes security-focused extensions, but none provide real DDoS detection. The reason is architectural: Plesk extensions run within the Plesk application framework. They have access to Plesk's internal APIs, database, and UI components, but they do not have low-level access to the network stack. An extension cannot capture raw packets from the network interface, cannot monitor per-second PPS rates across all ports, and cannot integrate with upstream BGP-based mitigation systems.

The extensions that address "DDoS" typically provide one of these features: firewall rule management through a nicer UI, Fail2Ban configuration through the Plesk interface, or IP reputation blocking using third-party blacklists. These are useful features, but they are all reactive, host-based tools that operate after traffic has already arrived. None of them provide the two things that actually stop DDoS attacks: real-time traffic analysis for detection and upstream signaling for mitigation.

Practical Hardening for Linux Plesk

Restrict Panel Access

# Block public access to Plesk panel, allow only management IPs
iptables -A INPUT -p tcp --dport 8443 -s 198.51.100.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 8443 -j DROP

# Or use Plesk's built-in Firewall extension to set these rules via GUI

# Change Plesk panel port (security through obscurity, but reduces automated scans)
plesk bin admin --set-admin-port 9443

Kernel Hardening

# /etc/sysctl.d/99-plesk-ddos.conf
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_max_syn_backlog = 65536
net.ipv4.tcp_fin_timeout = 15
net.netfilter.nf_conntrack_max = 524288
net.netfilter.nf_conntrack_tcp_timeout_established = 600
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.all.rp_filter = 1
net.core.somaxconn = 65536

# Apply
# sysctl -p /etc/sysctl.d/99-plesk-ddos.conf

Nginx Rate Limiting (if using Nginx)

Plesk supports Nginx as a reverse proxy in front of Apache or as a standalone web server. If Nginx is active, add rate limiting in the Nginx configuration:

# Add to /etc/nginx/conf.d/rate-limit.conf
limit_req_zone $binary_remote_addr zone=general:10m rate=30r/s;
limit_req_zone $binary_remote_addr zone=panel:10m rate=5r/s;
limit_conn_zone $binary_remote_addr zone=connlimit:10m;

# Apply to default server block
# Plesk manages Nginx configs, so use custom templates:
# /usr/local/psa/admin/conf/templates/custom/nginxDomainVirtualHost.php

Tune Fail2Ban Aggressively

# Via Plesk CLI
plesk bin ip_ban --update -ban-period 7200 -max-retries 3 -find-time 300

# This bans for 2 hours after just 3 failures within 5 minutes
# More aggressive than defaults but appropriate for production

# Enable all available jails
plesk bin ip_ban --enable-jails
plesk bin ip_ban --list-jails

Practical Hardening for Windows Plesk

Windows Plesk has fewer options, but the basics still apply:

# Restrict Plesk panel access
netsh advfirewall firewall add rule name="Plesk Allow Office" dir=in action=allow protocol=tcp localport=8443 remoteip=198.51.100.0/24
netsh advfirewall firewall add rule name="Plesk Block All" dir=in action=block protocol=tcp localport=8443

# Enable SYN attack protection in Windows TCP/IP stack
# Registry: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
reg add "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" /v SynAttackProtect /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" /v TcpMaxHalfOpen /t REG_DWORD /d 500 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" /v TcpMaxHalfOpenRetried /t REG_DWORD /d 400 /f

# Enable IIS Dynamic IP Restrictions as shown earlier

# Disable unused services
# If not using FTP:
Stop-Service FTPSVC
Set-Service FTPSVC -StartupType Disabled

Windows Plesk servers benefit the most from upstream detection because the host-level tools are so limited. Without iptables rate limiting, the only effective defense against volumetric attacks is preventing the traffic from reaching the server in the first place. Detection and upstream mitigation are not optional on Windows; they are the primary protection layer.

Deploying Detection on Plesk Servers

# Linux Plesk deployment
pip install ftagent
ftagent init --server-id plesk-linux-01 --api-key your-key
systemctl status ftagent

# Verify coexistence with Plesk services
systemctl status psa  # Plesk main service
systemctl status sw-engine  # Plesk PHP handler
systemctl status ftagent

The agent runs independently of Plesk and its extensions. It does not require Plesk API access, does not interfere with Plesk updates, and survives Plesk version upgrades. Because it monitors the network interface directly, it provides coverage across all services on the server without per-application configuration.

The Complete Plesk Protection Strategy

The protection stack differs between Linux and Windows Plesk, reflecting the different tools available on each platform:

Linux Plesk

1. Upstream mitigation for volumetric attack absorption
2. Per-second traffic detection with automated mitigation signaling
3. iptables/nftables rules for SYN rate limiting, connection limiting, and port-specific protection
4. Kernel hardening with SYN cookies, conntrack tuning, and reverse path filtering
5. Fail2Ban with aggressive thresholds for all Plesk services
6. Nginx rate limiting for web traffic
7. Panel access restriction to management IPs only

Windows Plesk

1. Upstream mitigation (even more critical since host-level tools are limited)
2. Per-second traffic detection with automated mitigation signaling
3. Windows Firewall rules for basic port-level access control
4. TCP/IP stack hardening via registry settings for SYN protection
5. IIS Dynamic IP Restrictions for web traffic rate limiting
6. Panel access restriction via Windows Firewall rules

The difference is stark. Linux Plesk has six layers of host-based protection before you need upstream mitigation. Windows Plesk has three, and none of them provide rate limiting at the packet level. This is why the detection and upstream mitigation layers are absolutely essential for Windows Plesk deployments. Without them, a Windows Plesk server has no effective defense against any DDoS attack that exceeds what Windows Firewall's basic allow/deny rules can handle.

Regardless of platform, the pattern is the same: host-based tools handle access control and basic rate limiting; real-time detection identifies attacks as they start; and upstream mitigation absorbs the traffic before it saturates your network port. Plesk's extension ecosystem does not fill the detection gap. The Firewall extension manages static rules. Fail2Ban reacts to log entries. Neither provides the per-second traffic analysis needed to detect an attack in progress and trigger automated mitigation within seconds.

Back to Blog

Related Articles