Module 10 · 10.4

English

Nederlands English Deutsch Français Español

Final check: putting your server to the test

Module 10: Staying secure · Reading time: 10 minutes

Learning objective: After this lesson you can assess your own server with a checklist and an automatic check from the outside, you know which points take priority, and you have a fixed maintenance routine and a short server file.

Key concepts: checklist, priority, external check, server file, maintenance routine (weekly, monthly, quarterly, yearly), end-of-life date of the release, restore test

From separate lessons to one whole

In this course you have set up a server step by step: secure login, permissions, updates, firewall, services, a website with https, backups, monitoring and containers. In this final lesson you put everything on one list. You go through your server, let the course program look at it from the outside, and record how you will maintain the server in the years ahead.

A server is never "finished". Software ages, certificates expire, disks fill up, releases go end of life. A fixed routine is therefore just as important as the initial setup.

The checklist, in order of importance

Not everything is equally urgent. Work through the list from top to bottom: the first blocks prevent most of the trouble.

Block 1: nobody just walks in (modules 2, 3, 5)

Login with keys only; PasswordAuthentication no and KbdInteractiveAuthentication no, checked with sudo sshd -T.
Root does not log in with a password; you work as a regular user with sudo.
Databases, caches and search clusters listen on 127.0.0.1; ports 3306, 5432, 6379, 9200 and 27017 are closed from outside, for IPv4 and IPv6.
A firewall that closes all incoming traffic by default; only the ports you need are open.
fail2ban is running for SSH (fail2ban-client status sshd).

Block 2: holes get patched (module 4)

Automatic security updates switched on and checked (log, apt list --upgradable).
A plan for reboots; /var/run/reboot-required is not left there for weeks.
The release is still supported; its end-of-life date is in your calendar.

Block 3: you can go back (module 8)

Encrypted backups outside the server, automatic, with monitoring.
A restore test done, and you know how long a restore takes.
You know how to make a snapshot and open the console.

Block 4: the outside is right (module 7)

A and AAAA records point to your server; the reverse DNS (PTR) points back to the same name.
https with a valid certificate that renews automatically; http redirects to https.
HSTS and a few security headers; a security.txt with a working contact address and an expiry date.

Block 5: you see what is happening (modules 6, 8)

The journal is persistent; you can read logs from before a reboot.
Monitoring from outside (availability, certificate) and from inside (disk, services), with alerts that actually arrive.
systemctl --failed is empty.

Block 6: containers under control (module 9, if you use Docker)

Container ports on 127.0.0.1 or behind the reverse proxy; no docker.sock in containers that do not really need it.
Volumes are included in the backup; images are updated regularly.
Secrets are kept in .env files with strict permissions, not in Git.

The external check

Part of this list can be checked by the course program from the outside, exactly as anyone on the internet sees your server. The final exercise (Z10.4) combines the checks from earlier exercises:

Part	What the program does	From lesson
SSH	Reads the version banner and asks which login methods your server offers for your username; does not log in	2.2
Database ports	Only tries to connect to 3306, 5432, 6379, 9200 and 27017; sends nothing	5.1
https	Checks the certificate (valid, trusted, correct name)	7.3
Headers	Reads HSTS and the other security headers	7.4
security.txt	Fetches `/.well-known/security.txt` and checks Contact and Expires	7.4
Container	Looks for the header with your code, set by your reverse proxy	9.4

The program runs nothing on your server, tries no passwords and scans no other ports. Each address can only be checked a few times per hour. A green result means: from the outside, the best-known mistakes are absent. It says nothing about what happens inside your server; that is the rest of the checklist, and you go through it yourself.

The server file

Write a short document for each server, stored outside the server (for example in your password manager or a shared folder):

name, IP addresses, provider, release and end-of-life date;
what runs on it (services, containers, websites) and why;
which ports are open and what for;
where the backups are, how to restore, when the last test was;
which secrets are on the server (not the secrets themselves, but which ones and where they are replaced);
what you deliberately did differently from the default (for example a Lynis suggestion you skipped, lesson 10.1);
who has access (which keys are in authorized_keys).

This file is worth its weight in gold during an incident (lesson 10.3), a release upgrade (lesson 4.3) and when someone else takes over the administration.

A maintenance routine

Without a routine, things slip. Here is an example for a small server; adapt it to your own situation.

When	What
Every week	Review monitoring and alerts; `systemctl --failed`; reboot if `/var/run/reboot-required` is present (or check that the automatic reboot worked)
Every month	`apt list --upgradable` (is anything held back?); `docker compose pull` and `up -d` for your containers, with the release notes; disk space; `fail2ban-client status`; logs for notable errors (`journalctl -p err --since "1 month ago"`)
Every quarter	Restore test of a backup; review `authorized_keys` and users (remove anyone who should no longer have access); run Lynis again; repeat the external final check (exercise Z10.4)
Every year	Update `security.txt` (Expires); check the release's end-of-life date and plan an upgrade; update your server file and emergency plan

Put these moments in your calendar. You can automate a large part with the monitoring from lesson 8.3, but you still need to take a look yourself.

In practice

Whether your server is with WebOké or another provider: the provider takes care of the hardware, the network and the ability to make snapshots and backups, and you take care of everything inside the server. This course is self-help: nobody is watching your server with you. With this checklist, the server file and the routine, you have everything you need to do that administration well and on your own.

Summary

Go through your server in blocks: nobody just walks in, holes get patched, you can go back, the outside is right, you see what is happening, containers under control.
The external check looks at SSH login methods, database ports, https, headers, security.txt and your container header; you check the rest yourself.
Keep a server file, outside the server.
Work to a fixed routine: weekly, monthly, quarterly and yearly.

Quiz

Exercise

Exercise Z10.4: Final exercise: your server from the outside. Let the course program check your server from the outside in one go: the SSH login methods for your username, the five database ports, https and the headers of your site, your security.txt, and the header X-Weboke-Cursus with your code on the name where your container runs. In addition, fill in the checklist for blocks 1 to 6 for everything the program cannot see.

Exercise Z10.4: Final exercise: your server from the outside

We don't log in and we don't try any password or key. First you show that the server is yours: click "Show my code" and put a file /.well-known/weboke-cursus-<code>.txt containing only that code on the web server of your hostname. We fetch it directly from every IP address we check (IPv4 and IPv6 separately); a TXT record doesn't count here. The check comes from heavy.webawere.nl (185.158.167.16 and 2a07:ae80:100:0:185:158:167:16), not from our web server. Only for registered students; at most 6 checks per server per hour. The final check runs the checks of Z2.2, Z5.1, Z7.3, Z7.4 and Z9.4 one after the other. SSH, ports and https must be green; headers, security.txt and the header line are advisory.

Hostname of your server (for example web1.yourdomain.example), not an IP address

SSH port (empty = 22) (optional)

The username you log in with yourself (not root)

Name of your site (empty = the hostname above) (optional)

Name on which your reverse proxy sets the X-Weboke-Cursus header (optional)

I don't use Docker (optional)

Do you allow SSH only from your own IP address? (optional)

What you enter and what we find isn't stored. Your browser remembers your answers and whether you've passed the exercise. If you're signed in, we only save that you got the exercise (almost) right in My courses; you can delete that there too.

Exercise O10.4: Your maintenance routine. Create your own server file and maintenance routine: what you do weekly, monthly, quarterly and yearly, and put those moments in your calendar.

Exercise O10.4: Your maintenance routine

You do this exercise yourself; no one checks it. Tick off what you've done and mark the exercise as done.

Server file created and stored off the server
Maintenance routine in the calendar
End-of-life date of the release in the calendar
Yearly reminder for the Expires of security.txt

What do you do weekly, monthly, quarterly and yearly?

Where is your server file kept (don't enter any secrets)?

What do you deliberately do differently from the checklist?

Your ticks and notes only stay in this browser; we don't send them anywhere. If you're signed in, we only save in My courses that you've done the exercise.

Cookies at WebOké

Cookie settings

Necessary

Marketing