Zo beveilig je een Ubuntu-server

Om een Ubuntu-server te beveiligen, sta je SSH alleen met sleutels toe, draai je een firewall die standaard alles weigert, installeer je beveiligingsupdates automatisch, blokkeer je herhaalde mislukte logins, stel je alleen de services open die je nodig hebt en houd je geteste back-ups bij. Die zes stappen houden het overgrote deel van de aanvallen op een publieke server tegen.

De commando's zijn voor Ubuntu 24.04 LTS en werken met kleine verschillen ook op Debian 12. Voer ze uit als gebruiker met sudo. Heb je de basis nog niet gedaan, begin dan met eerste stappen op een nieuwe VPS.

1. Eerst patchen, daarna bijgewerkt blijven

sudo apt update && sudo apt full-upgrade -y
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

Controleer of de timer actief is:

systemctl list-timers | grep apt

Beveiligingsupdates worden nu elke dag geïnstalleerd. Kijk af en toe of er een reboot klaarstaat met cat /var/run/reboot-required.

2. SSH afschermen

Alleen sleutels

Zorg dat je sleutel werkt voor een sudo-gebruiker (zie SSH-sleutels). Daarna:

sudo tee /etc/ssh/sshd_config.d/10-hardening.conf >/dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 20
X11Forwarding no
AllowUsers deploy
EOF
sudo sshd -t && sudo systemctl reload ssh

• AllowUsers beperkt SSH tot de accounts die je noemt. Vervang deploy door je eigen gebruiker.
• sshd -t valideert het bestand; toont het niets, dan is de syntaxis in orde.

Test vanuit een nieuwe terminal voordat je de huidige sluit.

De werkelijke instellingen controleren

Drop-in-bestanden worden op volgorde gelezen en de eerste waarde wint. Controleer wat sshd echt gebruikt:

sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|allowusers'

Zet een cloud-init-bestand zoals 50-cloud-init.conf PasswordAuthentication yes, dan wordt je 10--bestand eerder gelezen en wint dat.

3. Firewall met standaard weigeren via UFW

sudo apt install -y ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw limit OpenSSH          # allow SSH, rate limit repeated attempts
sudo ufw allow 80,443/tcp       # only if you run a web server
sudo ufw enable
sudo ufw status numbered

ufw limit blokkeert een adres dat binnen 30 seconden zes of meer verbindingen opent, wat scanners afremt.

UFW dekt ook IPv6, zolang IPV6=yes in /etc/default/ufw staat (de standaard op Ubuntu).

SSH beperken tot je eigen adressen

Maak je verbinding vanaf een vast adres, sta SSH dan alleen daarvandaan toe:

sudo ufw delete limit OpenSSH
sudo ufw allow from 198.51.100.0/24 to any port 22 proto tcp   # example range

Waarschuwing voor Docker

Docker schrijft eigen iptables-regels, en gepubliceerde containerpoorten omzeilen UFW. Bind containers aan localhost (127.0.0.1:8080:80) en zet er een reverse proxy voor, of filter bij de cloudfirewall. De Docker Compose-handleiding laat het patroon zien.

4. Zet er een cloudfirewall voor

Een firewall buiten de server blijft werken, ook als iemand UFW uitschakelt, en één regelset kan veel servers dekken. Bij Wolkra zijn firewalls stateful, ondersteunen ze regels voor inkomend en uitgaand verkeer, gelden ze voor servers of labelselectors en kosten ze niets. Een typische regelset:

Zie firewalls in de documentatie voor de stappen.

5. Brute force blokkeren met Fail2ban

sudo apt install -y fail2ban python3-systemd
sudo tee /etc/fail2ban/jail.local >/dev/null <<'EOF'
[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 5
backend  = systemd

[sshd]
enabled = true
EOF
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

backend = systemd leest het journal rechtstreeks, en daar logt Ubuntu 24.04 SSH. Voeg je eigen adres toe aan ignoreip in [DEFAULT], zodat je jezelf nooit verbant.

6. Minder services laten luisteren

Elke open poort is iets wat je moet patchen. Toon ze:

sudo ss -tulpn

Vraag je bij elke regel af of die vanaf internet bereikbaar moet zijn. Databases, Redis en beheerpanelen meestal niet. Bind ze aan 127.0.0.1 of aan een adres in een privénetwerk, en verwijder pakketten die je niet gebruikt:

sudo apt purge --autoremove <package>

7. De kernel en de netwerkstack beschermen

De standaardinstellingen van Ubuntu zijn verstandig. Een paar extra instellingen helpen op een publieke server:

sudo tee /etc/sysctl.d/90-hardening.conf >/dev/null <<'EOF'
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.tcp_syncookies = 1
kernel.kptr_restrict = 2
kernel.dmesg_restrict = 1
EOF
sudo sysctl --system

Sla de redirect-instellingen over als de server verkeer routeert, bijvoorbeeld als VPN-gateway.

8. Ga zorgvuldig om met sudo

• Geef sudo alleen aan mensen die het nodig hebben: getent group sudo toont wie dat zijn.
• Zet nooit NOPASSWD: ALL op interactieve accounts. Beperk sudo zonder wachtwoord voor automatisering tot specifieke commando's.
• Geef je sudo-gebruiker een wachtwoord, ook als SSH sleutels gebruikt: sudo passwd deploy.

9. Logs en logins in de gaten houden

last -n 20                          # recent logins
sudo journalctl -u ssh --since today
sudo journalctl -p err -b           # errors since boot

Voor bestandsintegriteit en een snelle audit is Lynis een goed begin:

sudo apt install -y lynis
sudo lynis audit system

Het toont een hardening-index en een lijst met suggesties. Zie ze als ideeën, niet als bevelen.

De Wolkra-console toont per server grafieken van CPU, schijf en netwerk (monitoring). Een plotselinge piek in verkeer of CPU is vaak het eerste teken van een gecompromitteerde service.

10. Beveilig het account, niet alleen de server

Server-hardening is zinloos als iemand op je cloudaccount kan inloggen. In de Wolkra-console:

• zet tweestapsverificatie (TOTP) aan;
• bekijk actieve sessies en log oude sessies uit;
• geef teamleden de laagste rol waarmee ze uit de voeten kunnen;
• gebruik waar mogelijk API-tokens die alleen-lezen zijn, beperkt tot bepaalde IP's en met een vervaldatum.

Zie accountbeveiliging en API-tokens.

11. Maak back-ups en test het herstel

Beveiliging omvat ook herstel. Zet dagelijkse back-ups of snapshots aan en bewaar minstens één kopie buiten de server. Herstel daarna één keer naar een nieuwe server om te bewijzen dat het werkt. De handleiding voor een back-upstrategie bevat een volledig plan.

Checklist

• Automatische beveiligingsupdates aan
• Alleen SSH-sleutels, root-login uit, AllowUsers ingesteld
• UFW standaard weigeren, alleen benodigde poorten open
• Cloudfirewall ervoor, SSH beperkt tot bekende ranges
• Fail2ban draait
• Niets onverwachts in ss -tulpn
• Sysctl-hardening toegepast
• Sudo beperkt, 2FA op het cloudaccount
• Back-ups aan en een herstel getest

Gaat er iets mis terwijl je de regels aanscherpt, dan brengen de browserconsole en rescue mode in het serveroverzicht je zonder SSH weer binnen.