Firewall (UFW)

Pro plan

Firewall management is part of the Pro plan.

MyPanel manages UFW (Uncomplicated Firewall) visually in the Firewall menu:

• Overview tiles — see at a glance whether the firewall is on/off, the incoming policy, the rule count, and whether the SSH/panel ports are open.
• Enable / disable UFW. On enable, the panel prevents lockout: if the SSH or panel port isn’t open yet, it asks “Open & enable” or “Enable anyway” instead of letting you lose access.
• Default policy — set incoming to Deny so only explicitly opened ports are reachable (the core of a secure firewall).
• Add a rule with quick chips for common ports (SSH, HTTP, HTTPS, MySQL, PostgreSQL…) that pre-fill the form in one click. Each rule has:
  • Action: Allow / Deny / Limit (connection rate-limit — slows SSH password-guessing).
  • Port + protocol (TCP/UDP/both).
  • Source (optional): open the port only to a specific IP/CIDR (e.g. allow SSH only from your office IP).
• Edit a rule — load it back into the form; saving deletes the old rule and creates a new one (UFW can’t edit in place).
• Delete a rule. Rules opening the SSH/panel port are tagged Critical with a stronger confirmation before deletion.

Matching IPv4 and IPv6 rules are merged into one row (labelled v4·v6) to keep the list tidy.

Caution

Before enabling the firewall, make sure you’ve allowed the SSH port (default 22) and the panel port (default 8888), or you may lock yourself out. The panel guards against lockout, but check first anyway.

Tip

MyPanel opens the ports websites need (80/443) and Docker containers automatically — you mainly use the Firewall to tighten other ports.

Cloudflare — restore real visitor IP

Right on the Firewall page there’s a Cloudflare — restore real visitor IP card. Enable it when your sites sit behind Cloudflare’s proxy: nginx will read the real visitor IP from the CF-Connecting-IP header instead of Cloudflare’s IP.

This is required for rate limiting & brute-force protection to work correctly — otherwise every request carries a Cloudflare IP, making rate limiting block all visitors and Fail2ban potentially ban Cloudflare’s ranges. The panel fetches the latest Cloudflare IP ranges (with a built-in fallback list) and runs nginx -t before applying; a bad config is rolled back automatically.

Tip

For real DDoS/scan protection, put your site behind Cloudflare (enable the “orange cloud” proxy) and turn on this card. Cloudflare filters attacks at the edge while MyPanel sees the correct visitor IP for logs, analytics and filtering.

What about domains NOT behind Cloudflare?

Safe — no impact. The config applies at the http level (all domains), but nginx only replaces the visitor IP with the CF-Connecting-IP header when the connection comes from one of Cloudflare’s IP ranges:

• A visitor hitting a non-Cloudflare domain directly → their source IP isn’t a Cloudflare range → nginx ignores the header and keeps the real IP as usual.
• Requests to non-CF domains also don’t carry a CF-Connecting-IP header (Cloudflare adds it), so there’s nothing to substitute.
• Spoof-proof: someone connecting directly and faking a CF-Connecting-IP header has no effect, because their source IP isn’t in the trusted list.

So enabling this card is safe on mixed servers (some domains behind Cloudflare, some not). This is also Cloudflare’s recommended approach.

Caution

This feature only restores the correct IP; it does not stop an attacker who finds your origin IP and connects directly (bypassing Cloudflare’s WAF). To block direct access you’d also need to lock the origin to Cloudflare IPs only.

See also

• Brute-force & flood protection (Fail2ban, rate limit)
• Panel security (2FA, IP whitelist)