The Plesk Firewall extension is the supported way to manage iptables rules from the Plesk GUI on a Linux VPS. This guide installs the extension, adds rules for web, mail, FTP and any custom ports your apps use, applies the rule set, and verifies it — without locking yourself out of SSH.
Before you start
- A Linux VPS with Plesk installed and a root or admin login. If Plesk is not installed yet, see how to install Plesk on a Linux VPS.
- SSH access, plus the browser console in your VPS provider's control panel open in a second tab. If a rule blocks port 22, the console is how you get back in.
- A list of the ports your server actually listens on. You collect this in step 2.
- A decision about who owns the firewall. Plesk Firewall writes iptables directly. Do not run UFW or firewalld at the same time — two managers editing the same chains make rules disappear. Pick one. If you prefer UFW, read UFW on Ubuntu and Debian and skip this guide.
Warning: Applying a firewall rule set can cut off your own SSH session. Keep your VPS provider's console open before you press Apply.
Step 1: Install and open the Plesk Firewall extension
In Plesk, open Extensions in the left menu and search the catalog for Firewall. Install it, then open it — it appears under Tools & Settings > Firewall, or as its own menu entry depending on your Plesk version.
Confirm from the command line:
plesk bin extension --list | grep -i firewallYou should see the firewall extension listed as enabled. If it is missing, install it from the Extensions catalog in the GUI.
Step 2: Find out which ports are in use
Never guess. List every listening socket:
ss -tulpnRead the output like this: LISTEN lines show the protocol (tcp or udp), the local address and the process. 0.0.0.0:80 and [::]:80 mean the port is open to the world. 127.0.0.1:3306 means MySQL is reachable only from the server itself and needs no public rule.
Write down the public ports. A typical Plesk server needs:
- 80 and 443 — web
- 22 — SSH, or your custom SSH port
- 8443 — the Plesk panel
- 25, 465, 587, 110, 995, 143, 993 — mail, if you host mail
- 21 plus the passive range — FTP, if you use it
- 53 — DNS, if the server runs its own resolver
Step 3: Set the system policy
Open the Firewall extension and select System policy for incoming traffic. The safe default is to allow only what you need:
- Set incoming traffic to Deny.
- Add explicit allow rules for the ports from step 2.
- Leave outgoing traffic at Allow unless you have a reason to restrict it.
On the same page, set System policy for ICMP traffic. Allowing ping helps monitoring; blocking it hides the host from casual scans. Either choice works — just match your monitoring setup.
Tip: Add the SSH rule before anything else. A deny-all policy with no SSH rule blocks every new connection.
Step 4: Turn on the module rules
The extension ships with modules that open the standard ports for you. Enable the ones you use and leave the rest off:
- Web server — 80 and 443.
- Mail server — SMTP, IMAP and POP3 ports, including the TLS variants.
- FTP server — port 21 and the passive data range. If FTP clients hang after login, the passive range is almost always the cause. Check the FTP settings in Plesk for the range in use and add it as a custom rule if the module does not cover it.
- MySQL — keep this closed to the world. Reach databases over SSH tunnels or from the same host.
- DNS server — only if Plesk runs DNS for your domains.
Each module has its own allow and deny lists. A deny inside a module beats the module default, so you can keep a module enabled and still block a single port.
Step 5: Add custom rules
For anything the modules do not cover — a Node or Go app on 3000, a game server, a monitoring agent — add a custom rule:
- Click Add custom rule.
- Choose the direction (incoming), the protocol (TCP, UDP or both) and the port or range.
- Set the action to Allow.
- Restrict the source address if the port is only for your office or a partner. Leaving the source blank means "anywhere".
Example: allow TCP 3000 from one address only.
Direction: incoming
Protocol: TCP
Port: 3000
Source: 203.0.113.10
Action: AllowWarning: Do not open a database port (3306, 5432, 27017) to the internet to "make it work". Use an SSH tunnel or a private network instead.
Step 6: Apply the rules
Click Apply. Plesk writes the rule set to iptables and reloads it. The GUI shows a green status when the rules are active.
Before you close the tab, open a second SSH session and confirm you can still log in. If the connection hangs, use the browser console in your VPS provider's control panel to fix the rule set from the command line.
Check it works
Confirm the rules are loaded:
iptables -S | head -40You should see your allow rules and a final -P INPUT DROP or a catch-all reject at the end of the INPUT chain.
Check that the ports you expect are reachable from outside:
nc -zv 203.0.113.10 443
nc -zv 203.0.113.10 22From another machine, test a port you deliberately blocked — the connection should time out or be refused. Then load a site in the browser and send a test mail if you enabled the mail module.
Troubleshooting
- SSH drops the moment you press Apply. The deny policy has no rule for your SSH port. Reconnect through your VPS provider's console, add the SSH rule and apply again. See firewall lockout recovery.
- Rules vanish after a reboot or after another tool runs. UFW, firewalld or Docker is writing iptables too. Disable the other manager and keep Plesk Firewall as the single source of truth. Docker publishes ports by editing the nat table directly — see Stop Docker from bypassing your firewall.
- FTP connects but directory listings hang. The passive port range is blocked. Add the range as a custom rule and confirm it in the Plesk FTP settings.
- Mail clients cannot send but webmail works. Port 587 or 465 is blocked. Enable the mail module or add the port manually.
- A site works on the server but not from outside. Something is listening on
127.0.0.1only. Check withss -tulpnand fix the service binding before touching the firewall.
Next steps
- Harden the web layer on top of the firewall with ModSecurity on Nginx.
- Test risky rule changes with an automatic rollback.
- Compare firewall options in UFW vs firewalld vs nftables vs iptables.
- If the server is still new, start with first steps after your Linux VPS is ready.
