What are we building?

By the end, UFW runs on your Debian 13 with the base rule “block all incoming”, with only SSH (your access) plus HTTP/HTTPS (ports 80/443, which you’ll need later for Traefik) open. Outgoing connections stay allowed. The key part: we proceed in a way that ensures you don’t lock yourself out.

Prerequisites

• A hardened server with a sudo user
• You know which port your SSH runs on (default: 22)

Step by step

Step 1: Install UFW

sudo apt update
sudo apt install -y ufw

Check the version – UFW is inactive at first, which is intended:

ufw version

Step 2: Define the base rules

First the default direction: deny everything incoming, allow everything outgoing.

sudo ufw default deny incoming
sudo ufw default allow outgoing

Default incoming policy changed to 'deny'
(be sure to update your rules accordingly)
Default outgoing policy changed to 'allow'
(be sure to update your rules accordingly)

These rules don’t take effect yet – UFW is still inactive. So the exceptions come now, before we switch it on.

Step 3: Allow SSH – first, or you’ll lock yourself out

If your SSH runs on the default port 22 (and openssh-server is installed), there’s a ready-made profile for it:

sudo ufw allow OpenSSH

If you changed the SSH port (e.g. to 2222), allow exactly that port instead:

sudo ufw allow 2222/tcp

Step 4: Allow HTTP and HTTPS

For the later reverse proxy with Traefik you need the web ports. Open them right away:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

UFW confirms each rule with Rules updated and Rules updated (v6) (the IPv6 variant).

Step 5: Activate the firewall and check it

Now switch it on:

sudo ufw enable

Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
Firewall is active and enabled on system startup

Check the result:

sudo ufw status verbose

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp (OpenSSH)           ALLOW IN    Anywhere
80/tcp                     ALLOW IN    Anywhere
443/tcp                    ALLOW IN    Anywhere
22/tcp (OpenSSH (v6))      ALLOW IN    Anywhere (v6)
80/tcp (v6)                ALLOW IN    Anywhere (v6)
443/tcp (v6)               ALLOW IN    Anywhere (v6)

Status: active and your three allowances – done. To be safe, test in a second SSH session that you can still connect before closing the first one.

When things go wrong

Maintenance & backups

• View and delete rules: sudo ufw status numbered numbers all rules; sudo ufw delete 3 removes rule 3. That’s how you tidy up when a service goes away.
• New services: For every additional public port, one targeted rule – never “just open everything”. What doesn’t need to be open stays closed.
• No backup needed, but note down your allowances (or keep them in the same document as your DNS records). The rule set is retyped in seconds.
• Know the limits: UFW protects the host, but not against the Docker gap above. An upstream perimeter firewall like the netcup firewall in the SCP complements UFW into two layers that secure each other – ideal once containers with open ports are running.

What are we building?

In the netcup SCP we build a network firewall from composable policy templates: a base template (that every server needs), one for SSH, and one for web (HTTP/HTTPS). You assign these building blocks to your server as needed – a web server gets base + SSH + web, a server without a website only base + SSH. By the end, everything inbound is blocked except what you deliberately allow.

A netcup-specific detail makes the difference: for UDP the firewall works statelessly – which is why services like DNS and NTP need their own inbound rule, otherwise they suddenly get stuck. Why that is and how the base template solves it is shown in step 2.

Prerequisites

• A netcup server, e.g. your first VPS.
• Your SCP credentials (customer number + SCP password from the netcup welcome email – different from your SSH login).
• Clarity about your SSH port: the default is 22, and it stays that way when hardening SSH. If you changed it elsewhere, use your real port – otherwise you lock yourself out when activating.

Step by step

Step 1: Open Firewall Policies in the SCP

Log into the Server Control Panel and open the Firewall Policies menu item at the top. Here you create reusable rule sets (“policies”) – independent of the individual server. You only assign them later.

Step 2: Build the base template

Click Create firewall policy, give it the name Serverküche Base and, via Add rule, create these four rules – all INBOUND and ACCEPT:

Two things that make the difference here:

• DNS/NTP via the Src Port, not the destination port. Your server queries DNS/NTP (outbound); the reply comes back from port 53 or 123. Because UDP is stateless, you need this inbound rule – otherwise there’s no name resolution and no time synchronization, even though “everything else” seems to work.
• Never forget ICMPv6. Without Neighbor Discovery, IPv6 breaks completely. ICMP (v4) on top is useful for ping and path MTU discovery. netcup’s default policy “Ping allow” does already cover ICMP – it’s deliberately in the base template again so your foundation stays complete even if you ever remove the netcup defaults.

Step 3: Small building blocks for SSH and web

Instead of one big rule monolith, you create atomic templates that you freely combine. Create two more policies following the same pattern:

• Serverküche SSH – one rule: INBOUND, TCP, ACCEPT, destination port 22.
• Serverküche Web – two rules: INBOUND, TCP, ACCEPT, destination port 80 and 443.

The gain: the base rules appear only once, not duplicated in every policy. If a service is added later (e.g. a mail server or WireGuard), you build another small template for it and plug it in – without touching the existing ones.

Step 4: Assign templates to the server

Switch to Server → your server → “Firewall” tab and click Edit firewall policies. Move the appropriate ones from Available firewall policies to Selected: for a web server Serverküche Base + Serverküche SSH + Serverküche Web.

Confirm with Apply and then Save. Check that the “Firewall active” switch is turned on. The assigned rules now appear in the list – together with netcup’s default policies (more on those below).

Step 5: Ready-made templates for common services

Exactly following the pattern from step 3, here are ready-made templates for the most common self-hosting services. Each is its own small template, all rules are INBOUND and ACCEPT. Build only the ones you really need and plug them, as in step 4, into Serverküche Base + Serverküche SSH.

Mail server (mailcow & co.)

Two things that additionally belong to a mail server:

• Web UI and certificates: mailcow needs 80/443 for the web interface and the Let’s Encrypt retrieval – just assign the Serverküche Web template along with it.
• Enable outbound SMTP: a mail server must be able to deliver on port 25 outbound. netcup blocks that with the default policy “netcup Mail block” – you have to remove it on the server (see “When things go wrong”). And without a correct PTR/reverse-DNS entry your mails land in spam.

WireGuard VPN

51820 is the usual default – use the value from your ListenPort. Only this one inbound rule is needed; the replies to the clients go out outbound.

OpenVPN

The default is UDP 1194. The TCP rule only if you deliberately run OpenVPN over TCP (some additionally put it on TCP 443 to get through restrictive foreign networks) – otherwise leave it out.

Zabbix monitoring

Here it depends on the server’s role:

The Zabbix server additionally needs 80/443 for the web frontend (Serverküche Web). If you run active checks, the agent connects outbound to the server on 10051 – for that, no inbound rule is needed on the agent host.

Checkmk

In the default pull mode, the Checkmk server fetches the data actively – so it connects outbound to 6556 of the agents. Inbound, therefore, only the monitored host needs port 6556. The Checkmk server itself gets by with 80/443 (Serverküche Web); 8000 and 6557 only if you use push mode or distributed monitoring.

Coturn / TURN server (Nextcloud Talk, Matrix)

The large UDP relay range is the default – the actual audio/video streams run over it. You can narrow it in the coturn configuration (min-port/max-port) and then set the firewall rule to the same, smaller range.

Your own DNS server (AdGuard Home, Pi-hole, Unbound)

Careful, this is exactly the opposite direction to the base template: there Src 53 allows the replies to your own DNS queries; here Dst 53 allows the queries of foreign clients to your DNS server. Both exist side by side without problems.

Remote database access (emergency only)

When things go wrong

Maintenance & backups

• Test access after every change. Firewall rules are the classic way to lock yourself out. Keep a second session open, check a new connection, only then finish.
• New services = new template. If you later need another port (game server, WireGuard VPN over UDP, database), create a small template of your own and assign it additionally. The existing building blocks stay untouched.
• Mind the order. netcup evaluates the rules top to bottom; the first matching rule wins. For pure ACCEPT rules that doesn’t matter – but as soon as you use your own DROP rules, watch the order relative to the ACCEPTs.
• Know netcup’s default policies. “netcup Mail block” (outbound SMTP on ports 25/465/587 blocked) and “netcup Ping allow” are predefined. Via Restore default policies you can, in an emergency, get back to a known, working baseline if you locked yourself out with your own rules – together with the VNC console, your second safety net.