The server firewall
This page turns the firewall on, lists exactly which ports it opens and why, opens one of your own, narrows the panel to your office, and blocks an address that will not stop knocking. It also says which mistakes the panel refuses to let you make.
Before you start
Check it is installed.
The firewall is ufw, which is on Ubuntu by default. Open Server, then Firewall. If the panel says No firewall is installed, that is not the same as nothing being blocked: no rules and no firewall look identical in a list and mean opposite things, so the panel refuses to show you an empty ruleset that would suggest everything was closed.
Step 1
Turn it on.
Use Turn the firewall on. You are not asked to enumerate ports: the policy already knows what this server hosts, and a panel that needed a port opened by hand before it could serve a website would be a firewall nobody leaves on.
Two things happen that are worth knowing in advance. The ruleset is reset first, which drops anything added by hand outside Dashmox. And the rules are applied in an order chosen so that everything letting you back in is allowed before anything is denied, so there is no moment during which the machine is unreachable.
What opens by itself
Every port the policy opens, and why.
| Port | For | When it is opened |
|---|---|---|
22/tcp, or whichever port SSH answers on |
SSH | Always, and rate limited rather than merely allowed, because an open SSH port on a public address is knocked on constantly and limiting it costs nothing. The port is read from the server rather than assumed to be 22: an operator who moved SSH and then enabled a firewall that only knew about 22 would lose the machine. |
80/tcp, 443/tcp |
Websites | Always. 80 is needed as well as 443, both for redirecting to HTTPS and for certificate issuance. |
| The panel’s own port | This panel | Always. It is listed explicitly even when it is 443, because asking an operator to take on trust that turning the firewall on will not cost them the panel is not good enough. |
53/tcp, 53/udp |
Authoritative DNS | Only where this server runs DNS. Both protocols: a reply too large for UDP falls back to TCP, and a nameserver reachable only over UDP fails in ways that are hard to diagnose. |
25, 465, 587, 143, 993, 110, 995, all TCP |
Only where mail is enabled. 25 for mail arriving from other servers; 465 and 587 for sending; 143 and 993 for IMAP; 110 and 995 for POP3. | |
| The file transfer control port and its passive range | File transfer | Only where that service is running. The passive range matters: a firewall that did not know about it would refuse every client behind a router. |
Outbound connections are allowed. Incoming is denied by default, so anything not in the list above or added by you is closed.
Step 2
Open a port of your own.
Under Extra allowances, add the port, choose TCP or UDP, and either give an address or leave it empty for anywhere. A note is for your own benefit later.
Two worked examples. A game server the public is meant to reach:
Port 27015 Protocol udp Source (empty, meaning anywhere) Note Game server
And a database you want reachable from one application server and nowhere else:
Port 3306 Protocol tcp Source 203.0.113.40 Note App server only
Use a range to mean a network rather than one machine. 203.0.113.0/24 is an office; 203.0.113.40/32 or just 203.0.113.40 is one address.
Step 3
Narrow the panel to the addresses you use.
Under Panel access, listing one or more addresses closes the panel’s port to everything else. This is the single most useful rule here: the panel is the whole server, and most installations are reached from two or three known places.
Loopback is always allowed, whatever you list. Something on the machine has to be able to reach the panel: it is how a change is checked afterwards, and it is a way back in through an SSH tunnel on the day the list turns out to be wrong.
ssh -L 8443:127.0.0.1:443 you@server.example.com # then open https://127.0.0.1:8443 in a browser
Step 4
Block an address.
Under Blocked addresses, an address or range is refused outright. These are applied before everything else, because ufw takes the first rule that matches: a block written after the SSH allowance would never be reached for SSH, and SSH is usually the port somebody blocking an address is trying to protect.
A block is a blunt instrument and not a substitute for the per-website protections. It is the right answer for one address generating noise, and the wrong answer for a distributed problem.
The fields
What each input means, and what it refuses.
| Field | What it is for | Limits and refusals |
|---|---|---|
| Port | The port to open. | 1 to 65535. Anything outside is refused. |
| Protocol | TCP or UDP. If a service needs both, add two allowances. | Only those two. |
| Source | Who may reach it. An address for one machine, a range for a network, empty for anywhere. | A real address or range. 203.0.113.40 and 203.0.113.0/24 are both accepted; something that is neither is refused rather than guessed at. |
| Note | Why this rule exists, for whoever reads the list in a year. | Up to 120 characters. Line breaks are refused. |
| Panel access | The addresses that may reach the panel. Empty means anywhere. | Each must be a real address or range, and none may exclude the address you are connected from. |
| Blocked addresses | Addresses refused before any other rule is considered. | Up to 250. The same address twice is refused. So is a range covering everything, and so is loopback. |
| Extra allowances | Your own open ports. | Up to 100. The same port, protocol and source twice is refused. |
What is refused
The mistakes the panel will not let you make.
- A restriction that excludes the address you are connected from. This is the one mistake that cannot be undone from a browser, because the moment it takes effect you are on the wrong side of it. If you genuinely mean to lock yourself out, you will need the server’s console.
- Blocking every address. A range covering everything is refused: that is not a firewall rule, it is turning the server off, and there are better ways to do that.
- Blocking loopback. The machine talks to itself over it, so blocking it breaks the server from the inside while looking like a security measure.
- Covering your own address with a block. Checked before the rules are built, so a block cannot achieve what a restriction is refused for.
Turning it off
Read the consequence first.
Turning the firewall off makes every port this server listens on reachable from anywhere, including ones meant only for this machine. A development port left open, or a database listening on a public interface, is exactly what the firewall was standing in front of. The panel says so before confirming rather than treating it as an ordinary setting.
What it is not
Not a substitute for the per-website protections.
A firewall decides who may open a connection. It does not decide what a request may do once it arrives, so it is not what stops a scanner probing for backup files, and it is not what rate-limits a sign-in page. Those are per-website protections and they work whether the firewall is on or off.
Run both. The firewall keeps the machine’s own services private; the website protections handle the traffic you intend to accept.