Guide Configure aaPanel Firewall Rules Without Losing SSH Access - Printable Version +- AdminsForum (https://adminsforum.com) +-- Forum: Free & open-source control panels (https://adminsforum.com/Forum-free-open-source-control-panels) +--- Forum: aaPanel (https://adminsforum.com/Forum-aapanel) +---- Forum: aaPanel Guides & Tutorials (https://adminsforum.com/Forum-aapanel-guides-tutorials) +----- Forum: aaPanel Security Guides (https://adminsforum.com/Forum-aapanel-security-guides) +----- Thread: Guide Configure aaPanel Firewall Rules Without Losing SSH Access (/Thread-guide-configure-aapanel-firewall-rules-without-losing-ssh-access)

Configure aaPanel Firewall Rules Without Losing SSH Access - DEV - 10-13-2026 A firewall should allow the services you use and block direct access to internal services. This walkthrough shows the rules checked on our Ubuntu aaPanel lab. Your panel, SSH and application ports may differ: inspect them before making changes. 1. Prepare a recovery route Keep the current SSH session and panel tab open. Make sure your VPS provider console works before changing SSH or panel rules. Record your actual SSH port and panel URL. Export or privately copy the existing firewall rules so you can restore the previous configuration. Do not publish that backup: it can include infrastructure details. 2. Inspect the existing firewall In aaPanel, open Security → Firewall. Look at protocol, port, Allow/Deny, direction and source. On Ubuntu, the following read-only commands help confirm the effective configuration: Code:Copy sudo ufw status verbose sudo ufw status numbered sudo ss -lntup A listening service is not necessarily reachable from the Internet. The listener report and firewall rules answer different questions. Check IPv6 rules as well as IPv4. Do not reset UFW simply to reproduce a tutorial. 3. Preserve management and application access Our lab uses SSH TCP 22 and panel port 18443. The panel also has a UDP listener on 18443, so its existing TCP and UDP rules were preserved. Do not copy this port number if yours differs. Preserve HTTP/HTTPS for websites and the mail or FTP ports you actually need. Passive FTP also needs its configured passive port range; opening port 21 alone is insufficient. Ports 887/888 were left unchanged because existing aaPanel applications use them. 4. Block direct backend and database access Our existing rules already denied TCP 7080, 8188–8190 and 8288–8290. We found backend UDP listeners too and added matching UDP denies. We also added explicit TCP denies for database port 3306 and Redis port 6379. Redis was already bound to localhost. These rules were added for IPv4 and IPv6, ahead of general rules. Important: A remote database application or deliberately public backend needs its own reviewed access plan. A broad deny can break it. Before adding a rule, check existing allows and identify the clients that depend on that port. Prefer a private network and specific trusted sources where remote database access is required. To create a rule in the panel, choose Add port rule, select the correct protocol, enter the port or range, choose Deny for unwanted inbound access, and review the source and direction before saving. Labels can vary by panel version. Apply one change at a time. Review ordering afterward: an earlier allow can defeat a later deny. 5. Verify the result     Original lab result: explicit backend/database denies in both address families, with SSH and panel rules preserved. Our post-change checks confirmed the SSH listener remained available and the panel still passed trusted certificate verification using TLS 1.3. Existing application allow rules were preserved. This evidence is a rules review and service check; it is not a comprehensive external penetration test or an external UDP reachability test. Open a second SSH connection and sign in to the panel before closing your original session. Check your websites, mail and FTPS from the clients that use them. A timeout on a blocked port is expected; a failed website or management login needs investigation. The overview's “Allowed ports” summary is less useful than the actual Allow/Deny table and effective operating-system rules. 6. Recovery and ongoing maintenance If access breaks, use the provider console and restore the reviewed previous rules. Remove or amend the specific conflicting rule rather than disabling the firewall indefinitely. Recheck rules after installing apps, changing service ports or enabling IPv6. Keep databases and internal backend services protected even when the panel reports them as listening. Related guides Enable secure FTPS Install trusted panel HTTPS Reference: Ubuntu firewall documentation. Screenshots and lab verification: © AdminsForum.