# Firewall and ports > Source: https://www.allsweb.com/sixpanel/docs/firewall > Markdown for agents: https://www.allsweb.com/sixpanel/docs/firewall.md > Publisher: AllsWeb (www.allsweb.com) Part of: SixPanel documentation **What this page is for:** open the three ports this server needs at your hosting provider, and — if you want — block everything else at their edge. **You need** - The login for your hosting provider's dashboard (Linode, AWS, Hetzner, DigitalOcean, Oracle, Google Cloud…). - Your panel port. Print it with `sudo sixpanel server firewall`, or read it in the middle of your panel link. ## Only three ports, ever | Port | What it is for | |---|---| | your panel port (a random high number) | the panel | | 80 | certificate renewal, and the redirect to https | | 443 | website, HTTPS and websockets | Nothing else on this server needs to be reachable from the internet. The database and the caches listen on the machine itself only — MariaDB through a local socket, and each project's Redis through a socket of its own that no other project may open. Neither has a network port at all, so there is nothing to open for them and no way to reach them from outside. To see the rules for **your** install, with your real port filled in: ``` sudo sixpanel server firewall ``` Two things people expect to need a port and do not: - **Live order updates (websockets)** run over port 443. No extra port. - **More projects on the same server** share the same 80 and 443. No extra port. A closed panel port at the provider is the most common reason a new panel will not open. Nothing on the server can detect that for you — the packets never arrive. ## Add the rules at your provider The names differ, the idea does not. - **Linode** — Cloud Firewalls - **AWS** — Security groups - **Oracle Cloud** — Security lists / Network security groups - **Hetzner** — Firewalls - **DigitalOcean** — Cloud firewalls - **Google Cloud** — VPC firewall rules Add three inbound rules: TCP 80, TCP 443, and TCP on your panel port. Keep the rule that allows **TCP 22 (SSH)** — your provider creates it for you, and it is your way back in. > **Do this first.** Never apply a firewall whose default is "drop" without an > SSH rule inside it. That locks you out of your own server, and no command on > the server can undo it. ## Optional: block everything else at the edge This part is for projects that already sit behind Cloudflare. It makes junk traffic cost you nothing at all, because the packets die in your provider's network before this server sees them. Not behind Cloudflare yet? Do that first — the panel sets it up for you from one page: **[Cloudflare](https://www.allsweb.com/sixpanel/docs/cloudflare)**. The panel builds the exact list for **your** install. Open the **Server** page in the **Panel** menu group and choose the **Firewall** tab. It shows: - the ruleset for this server, as a table; - **Cloudflare address lists** for IPv4 and IPv6, each with a **Copy** button; - whether your panel port still has to be allowed. The plan is: | Rule | Allow from | Why | |---|---|---| | TCP 80 + 443 | the two Cloudflare lists | visitors and certificate renewal both arrive through Cloudflare | | TCP 22 (SSH) | your own IP if it is stable, otherwise anywhere | your rescue door, and the `sixpanel` command | | TCP your panel port | your own IP — or leave it out entirely | see below | | everything else | — | drop | **Keep port 80 in that rule.** When the panel renews a certificate over plain HTTP it needs that port, and every name this panel puts on Cloudflare is **proxied** — so the request arrives from a Cloudflare address and the rule above covers it. Dropping 80 looks harmless today and quietly expires every certificate on the server about ninety days later. **The panel port row depends on your setup.** If you gave the panel its own domain and that domain has a certificate (see **[Security](https://www.allsweb.com/sixpanel/docs/security)**), the panel is reached through Cloudflare on 443 and the raw port answers nothing useful. The **Firewall** tab says so, and then you can leave that rule out. If you have no panel domain, the panel port must stay allowed or you lose the panel. Steps on Linode, as an example: 1. Linode dashboard → **Cloud Firewalls** → **Create Firewall**. Name it and set **Inbound policy: Drop** (outbound: Accept). 2. Add a rule: label `cf-http`, protocol TCP, port **80**, sources: paste the **IPv4** list, then the **IPv6** list. 3. Add a rule: label `cf-https`, TCP **443**, the same two lists. 4. Add a rule: label `ssh`, TCP **22**, source: your own IP as `x.x.x.x/32`, or `0.0.0.0/0` and `::/0` if your address changes. 5. Add the panel-port rule only if the **Firewall** tab says it is still needed. 6. **Linodes** tab → attach the firewall to this server → save. Other providers work the same way. On a server with no provider firewall, `ufw` can do something similar, but a provider firewall is better: it drops the traffic before your machine wakes up. ## How to check it worked Run these **from your own computer**, not from the server. Replace `SERVER-IP` with your server's address. Each of these must **time out** — no answer at all: ``` curl --max-time 6 http://SERVER-IP/ curl --max-time 6 -k https://SERVER-IP/ ``` And your real site must keep working exactly as before: ``` curl -I https://your-domain/ ``` If you only opened the three ports and did not add a drop rule, the check is simpler: open your panel link in a browser and open your site. ## If it went wrong - **The panel will not open after a firewall change** — allow your panel port again at the provider. Get the port with `sudo sixpanel server firewall`. - **Certificates stop renewing after months** — Cloudflare sometimes adds addresses. Open the **Firewall** tab again and update the two web rules from the fresh lists. - **SSH stopped working** — most providers offer a web console (Linode LISH, AWS Session Manager, Hetzner console). Use it to remove the firewall, then add it back with an SSH rule. The panel never edits your provider's firewall. A wrong rule there can lock you out, so a human always applies it.