Set up the Plesk Firewall extension without locking yourself out

The Plesk Firewall is a free extension that puts a UI and a CLI in front of iptables. It manages the packet filter — which ports are reachable, from where — and is a separate layer from Fail2Ban, which bans IPs by behaviour, and ModSecurity, which filters HTTP payloads. You want all three; this one is the outermost.

This covers installing and enabling the extension, the port set Plesk actually needs, writing custom rules by port, IP, and country, and — the part that matters most — the 60-second confirmation window that rolls a bad rule back before it strands you on a headless VPS.

Install and enable the extension

The extension ships in the Plesk catalogue. Add it under Extensions → Extensions Catalog → Firewall, or from the shell:

plesk bin extension --install firewall

Then turn on rule management. In the UI: Tools & Settings → Firewall → toggle Firewall protection to Enabled → Apply. From the CLI:

plesk ext firewall --enable

Enabling loads Plesk's predefined rules — the ports required for the panel, web, mail, and DNS to keep working — so switching it on does not immediately cut your own access.

Policies versus rules

The Plesk model has two levels, and the precedence between them is the thing people get wrong.

• Policies are broad. The System policy for incoming traffic can be set to allow everything, or to deny everything and let rules poke holes. Policies also exist for outgoing and forwarded traffic.
• Rules are narrow — one service or one port — and rules override policies. If the incoming policy is "deny all" but a rule allows TCP 8443 from your office, that rule wins.

The safe default for a hardened box is: incoming policy set to deny, then an explicit allow rule for every port you actually serve. Do not set the incoming policy to deny until you have added the allow rules below and confirmed you can still reach the panel — otherwise your next apply locks you out.

Open the ports Plesk needs

If you flip the incoming policy to deny, these are the ports that must have an explicit allow rule or the server stops working. Predefined Plesk rules cover most of them, but check the list before you tighten the policy.

Two easy misses. FTP needs its passive port range open, not just 21 — find the range in /etc/proftpd.conf (PassivePorts) and allow it, or passive transfers hang. And 8447 must be open outbound as well as inbound, or license checks and plesk installer updates fail silently. If the panel itself goes unreachable after a change, that's usually 8443 — the ports-not-accessible failure mode.

Add a custom rule

In the UI, click the + in the Firewall section and set four things:

• Match direction — Incoming or Outgoing
• Action — Allow or Deny
• Ports — protocol and port, e.g. TCP 22
• Sources — one or more IP addresses/CIDR ranges, or two-letter ISO country codes

To restrict SSH to your office and block it everywhere else: one Allow / Incoming / TCP 22 / 203.0.113.10 rule, and set the incoming policy for everything else. To block a hostile network outright: Deny / Incoming / any / 198.51.100.0/24.

Country codes let you geo-fence a service without maintaining IP lists by hand. Enter US,GB,DE in Sources on an allow rule to admit only those countries. Plesk resolves country codes to IP sets from a GeoIP database; on Obsidian you point it at a MaxMind GeoLite2 feed:

LICENSE_KEY=<maxmind-key> plesk sbin modules/firewall/ipsets \
  --configure --data-source maxmind --force

This is the Plesk-native equivalent of CSF's CC_DENY/CC_ALLOW on cPanel.

Apply changes with the rollback safety net

Nothing you do takes effect until you apply — and applying is where you can lock yourself out. Plesk builds in a dead-man's switch. When you click Apply Changes → Apply, the panel activates the new ruleset and starts a 60-second countdown. If you don't click Confirm in that window, Plesk assumes you lost connectivity and reverts to the previous ruleset. Click Confirm only after you've verified the panel still loads.

The CLI mirrors this exactly, which is why headless applies need two SSH sessions:

# session 1 — export current config, edit, re-import, apply
plesk ext firewall --export > /root/fw.json
# ...edit /root/fw.json...
plesk ext firewall --import --config /root/fw.json
plesk ext firewall --apply        # starts the 60-second timer

# session 2 — open a SECOND SSH session and confirm within 60s
plesk ext firewall --confirm

If session 2 can't connect — because your new rules just blocked SSH — you do nothing, the timer expires, and the firewall rolls back to the working state on its own. That's the whole point: a bad rule costs you 60 seconds, not a support ticket to the datacenter for console access.

Next steps

• Configure Plesk Fail2Ban jails to stop brute-force attacks — the behavioural layer that pairs with the packet filter
• Whitelist Plesk ModSecurity rules without breaking updates
• Plesk license tiers explained — and activate a Plesk license when you spin up the next node