# Server hardening

Server hardening is een belangrijk onderdeel van de Tulpencraft-infrastructuur.

Iedere nieuwe server wordt na de installatie van **Rocky Linux 10** volgens een vaste basisinrichting beveiligd voordat daarop Tulpencraft-software wordt geïnstalleerd.

Het doel is om het aanvalsoppervlak zo klein mogelijk te houden en tegelijkertijd een stabiele en beheersbare omgeving voor Minecraft en de bijbehorende netwerkdiensten te behouden.

Deze pagina beschrijft de algemene hardeningstandaard van Tulpencraft. Afhankelijk van de functie van een server kunnen aanvullende maatregelen of uitzonderingen noodzakelijk zijn.

> Hardening is geen eenmalige installatiehandeling. De beveiligingsconfiguratie wordt gedurende de levensduur van een server onderhouden en opnieuw gecontroleerd wanneer de functie, software of netwerkpositie verandert.

---

## 🎯 Doelstellingen

De Tulpencraft-hardening heeft de volgende doelstellingen:

* alleen noodzakelijke software installeren;
* alleen noodzakelijke netwerkpoorten openstellen;
* SSH veilig configureren;
* directe root-login voorkomen;
* SSH-sleutelauthenticatie gebruiken;
* SELinux ingeschakeld houden;
* firewalld gebruiken;
* Fail2Ban gebruiken waar dit relevant is;
* systemen regelmatig bijwerken;
* onnodige services uitschakelen;
* logbestanden beschikbaar houden;
* correcte tijdsynchronisatie gebruiken;
* rechten zo beperkt mogelijk instellen;
* serverconfiguraties reproduceerbaar maken.

---

# 🏗️ Hardening als basislaag

De hardening vindt plaats tussen de OS-installatie en de installatie van de Tulpencraft-software.

```text
┌──────────────────────────────┐
│       Tulpencraft software   │
│   Paper / Velocity / Java    │
├──────────────────────────────┤
│       Server hardening       │
│ SSH • Firewall • Fail2Ban    │
│ SELinux • Updates • Rights   │
├──────────────────────────────┤
│        Rocky Linux 10        │
├──────────────────────────────┤
│          Proxmox VE          │
└──────────────────────────────┘
```

Hiermee wordt voorkomen dat beveiligingsmaatregelen pas worden toegevoegd nadat de server al in productie is genomen.

---

# 🔐 SSH

SSH is de primaire beheerinterface voor Tulpencraft-servers.

De SSH-configuratie wordt zo ingericht dat alleen noodzakelijke toegang mogelijk is.

## Root-login

Directe root-login via SSH is niet toegestaan.

De beheerder logt in met een normaal gebruikersaccount en gebruikt vervolgens `sudo` voor beheertaken.

Bijvoorbeeld:

```bash
ssh rroethof@<SERVER>
```

Daarna:

```bash
sudo -i
```

of voor een afzonderlijke opdracht:

```bash
sudo <commando>
```

Hierdoor worden beheertaken aan een individuele gebruikersaccount gekoppeld.

---

## 🔑 SSH-sleutels

SSH-sleutelauthenticatie heeft de voorkeur boven wachtwoordauthenticatie.

De publieke sleutel wordt op de server geplaatst in:

```text
~/.ssh/authorized_keys
```

De private sleutel blijft uitsluitend bij de beheerder en wordt nooit op de server opgeslagen.

De sleutelbestanden moeten bovendien correct worden afgeschermd.

Bijvoorbeeld:

```bash
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
```

---

## 🚫 Wachtwoordlogin

Wanneer SSH-sleutelauthenticatie voor de betreffende beheeromgeving correct werkt, wordt wachtwoordauthenticatie uitgeschakeld.

Daarmee wordt voorkomen dat internetbereikbare SSH-diensten gevoelig zijn voor password spraying en brute-force aanvallen.

De SSH-configuratie wordt gecontroleerd voordat wachtwoordauthenticatie wordt uitgeschakeld.

De effectieve configuratie kan worden gecontroleerd met:

```bash
sudo sshd -T
```

---

# 👤 Gebruikers en rechten

Tulpencraft gebruikt waar mogelijk het principe van **least privilege**.

Een applicatie krijgt niet standaard rootrechten.

Voorbeelden:

```text
Minecraft
   │
   └── eigen gebruiker

Velocity
   │
   └── eigen gebruiker

Database
   │
   └── eigen service-account
```

De exacte gebruikersstructuur kan per server verschillen.

Minecraft- en andere applicatieprocessen worden niet standaard uitgevoerd als `root`.

---

# 🔥 Firewall

De host-firewall wordt verzorgd door **firewalld**.

De firewall vormt een belangrijke eerste verdedigingslaag en bepaalt welke netwerkverbindingen naar een server zijn toegestaan.

Controle:

```bash
sudo firewall-cmd --state
```

Gewenst:

```text
running
```

De actieve configuratie kan worden bekeken met:

```bash
sudo firewall-cmd --list-all
```

---

## 🚪 Alleen noodzakelijke poorten

Het uitgangspunt is:

> **Default deny, expliciet toestaan wat noodzakelijk is.**

Een server krijgt dus niet standaard een groot aantal open poorten.

Een Velocity-proxy kan bijvoorbeeld de Minecraft-poort naar buiten aanbieden:

```text
TCP 25565
```

Een backendserver zoals Survival hoeft daarentegen niet rechtstreeks vanaf internet bereikbaar te zijn.

De netwerkarchitectuur van Tulpencraft zorgt ervoor dat spelers via de proxy naar de lobby en vervolgens naar backendservers worden geleid.

---

# 🌐 Backendservers

Backendservers worden niet bedoeld als rechtstreeks publiek toegangspunt.

De netwerkarchitectuur is:

```text
Internet
    │
    ▼
Velocity Proxy
    │
    ▼
Lobby
    │
    ├── Survival
    ├── Events
    └── toekomstige servers
```

Daarmee wordt voorkomen dat iedere Minecraft-server afzonderlijk aan het internet wordt blootgesteld.

De firewall van een backendserver kan bovendien worden gebruikt om netwerktoegang verder te beperken.

---

# 🛡️ SELinux

**SELinux blijft ingeschakeld.**

De gewenste status is:

```bash
getenforce
```

Resultaat:

```text
Enforcing
```

SELinux vormt een aanvullende beveiligingslaag bovenop de normale Linux-bestands- en gebruikersrechten.

SELinux wordt daarom niet simpelweg uitgeschakeld wanneer een applicatie problemen geeft.

Eerst wordt onderzocht:

1. welke toegang wordt geweigerd;
2. welke service dit veroorzaakt;
3. waarom die toegang noodzakelijk is;
4. of een correcte SELinux-context of policy-aanpassing mogelijk is.

SELinux-denials kunnen bijvoorbeeld worden onderzocht met:

```bash
sudo ausearch -m AVC -ts recent
```

of:

```bash
sudo journalctl | grep -i avc
```

---

# 🚫 Fail2Ban

**Fail2Ban** kan worden gebruikt als aanvullende beveiligingslaag tegen brute-force- en password-sprayingaanvallen.

Fail2Ban analyseert logbestanden en kan bij herhaaldelijke mislukte authenticatiepogingen automatisch een IP-adres tijdelijk blokkeren.

Fail2Ban is nadrukkelijk **geen vervanging voor goede SSH-beveiliging**.

De primaire maatregelen blijven:

* beperkte netwerktoegang;
* SSH-sleutels;
* geen directe root-login;
* geen wachtwoordauthenticatie zodra sleuteltoegang correct werkt;
* een correcte firewallconfiguratie.

Fail2Ban vormt daarbovenop een extra detectie- en blokkeerlaag.

---

## Installatie

Fail2Ban wordt via een geschikte Rocky Linux-repository geïnstalleerd.

Na installatie wordt de service ingeschakeld:

```bash
sudo systemctl enable --now fail2ban
```

Status controleren:

```bash
sudo systemctl status fail2ban
```

De algemene status:

```bash
sudo fail2ban-client status
```

---

## SSH-jail

De belangrijkste toepassing binnen de Tulpencraft-infrastructuur is het beschermen van SSH.

Lokale configuratie wordt bij voorkeur opgeslagen onder:

```text
/etc/fail2ban/jail.d/
```

Hierdoor worden standaardconfiguratiebestanden niet onnodig aangepast.

Een voorbeeld van een SSH-jail:

```ini
[sshd]
enabled = true
```

De exacte instellingen voor `bantime`, `findtime` en `maxretry` worden afgestemd op de betreffende server en beheeromgeving.

---

## Controle

Actieve jails:

```bash
sudo fail2ban-client status
```

Specifiek voor SSH:

```bash
sudo fail2ban-client status sshd
```

Hiermee kan onder andere worden gecontroleerd:

* hoeveel pogingen zijn gedetecteerd;
* welke IP-adressen momenteel geblokkeerd zijn;
* hoeveel adressen in totaal zijn geblokkeerd.

---

## Fail2Ban en firewall

Fail2Ban werkt samen met de firewall en vormt daarmee een dynamische beveiligingslaag.

Een IP-adres dat herhaaldelijk ongewenst authenticatiegedrag vertoont kan tijdelijk worden geblokkeerd.

De blokkering is standaard tijdelijk. Hierdoor wordt voorkomen dat een incidentele fout automatisch tot een permanente blokkade leidt.

Beheer-IP's kunnen indien noodzakelijk worden uitgesloten van blokkering.

---

# 📦 Minimale installatie

Een nieuwe server begint bij voorkeur met een **Minimal Install**.

Onnodige software wordt niet geïnstalleerd.

Dit beperkt:

* het aanvalsoppervlak;
* het aantal services;
* het aantal mogelijke kwetsbaarheden;
* onderhoud;
* resourcegebruik.

Software wordt alleen toegevoegd wanneer deze daadwerkelijk nodig is.

---

# 🔄 Updates

Servers worden regelmatig bijgewerkt.

Handmatig:

```bash
sudo dnf upgrade -y
```

Beschikbare updates kunnen worden gecontroleerd met:

```bash
sudo dnf check-update
```

Security-updates worden zo snel mogelijk beoordeeld en geïnstalleerd, waarbij rekening wordt gehouden met de impact op de betreffende Minecraft-server.

Updates worden bij voorkeur eerst getest wanneer een wijziging een directe impact op de Minecraft-stack kan hebben.

---

# 📚 Repositories

Alleen noodzakelijke repositories worden ingeschakeld.

De standaard Rocky Linux-repositories zijn leidend.

Controle:

```bash
sudo dnf repolist
```

Niet-productierepositories, developmentrepositories of repositories met experimentele software worden niet zonder duidelijke reden ingeschakeld.

Dit is belangrijk omdat extra repositories ook extra softwarebronnen en afhankelijkheden introduceren.

---

# ⚙️ Services

Actieve services worden gecontroleerd met:

```bash
systemctl list-units --type=service --state=running
```

Daarnaast kunnen alle ingeschakelde services worden bekeken met:

```bash
systemctl list-unit-files --state=enabled
```

Onnodige services worden uitgeschakeld.

Bijvoorbeeld:

```bash
sudo systemctl disable --now <service>
```

Een service wordt echter niet blind uitgeschakeld.

Eerst wordt gecontroleerd of deze onderdeel is van de Rocky Linux-basis of door andere software wordt gebruikt.

---

# ⏱️ Tijdsinrichting

Correcte systeemtijd is onderdeel van de beveiligingsbasis.

Controle:

```bash
timedatectl
```

Tijdssynchronisatie:

```bash
chronyc tracking
```

De server moet gesynchroniseerd zijn met een betrouwbare NTP-bron.

Een correcte systeemtijd is belangrijk voor:

* logging;
* authenticatie;
* TLS-certificaten;
* monitoring;
* incidentonderzoek;
* correlatie van gebeurtenissen tussen servers.

---

# 📝 Logging

Logs worden niet onnodig verwijderd of genegeerd.

Belangrijke bronnen zijn onder andere:

```text
systemd journal
SSH
firewalld
SELinux / audit
Fail2Ban
Minecraft
Velocity
```

Voor systeemlogs:

```bash
journalctl
```

SSH-gerelateerde gebeurtenissen:

```bash
journalctl -u sshd
```

Firewall:

```bash
journalctl -u firewalld
```

Fail2Ban:

```bash
journalctl -u fail2ban
```

SELinux/audit:

```bash
ausearch -m AVC
```

De loggingconfiguratie kan per server worden uitgebreid.

---

# 🧪 Security-controles

Na de basis-hardening worden minimaal de volgende controles uitgevoerd.

## OS

```bash
cat /etc/os-release
```

## Kernel

```bash
uname -r
```

## SELinux

```bash
getenforce
```

Verwacht:

```text
Enforcing
```

## Firewall

```bash
sudo firewall-cmd --state
```

Verwacht:

```text
running
```

## SSH

```bash
sudo sshd -T
```

Controleer hierbij onder andere:

* root-login;
* wachtwoordauthenticatie;
* public-key-authenticatie;
* toegestane gebruikers.

## Fail2Ban

```bash
sudo fail2ban-client status
```

Wanneer SSH door Fail2Ban wordt beschermd:

```bash
sudo fail2ban-client status sshd
```

## Updates

```bash
sudo dnf check-update
```

## Tijd

```bash
timedatectl
```

## Actieve services

```bash
systemctl list-units --type=service --state=running
```

---

# 🔎 Luisterende netwerkpoorten

Openstaande netwerkpoorten worden gecontroleerd met:

```bash
sudo ss -tulpn
```

Hiermee kan worden vastgesteld welke services daadwerkelijk op netwerkpoorten luisteren.

Dit is een belangrijke controle omdat zowel de firewallconfiguratie als de daadwerkelijke applicatieconfiguratie moeten kloppen.

Voorbeeld:

```text
Internet
    │
    ├── TCP 25565 → Velocity
    │
    └── overige poorten → geblokkeerd
```

Op een backendserver worden alleen de poorten geopend die voor de interne werking noodzakelijk zijn.

---

# 🧱 Bestandsrechten

Configuratie- en applicatiebestanden moeten de juiste eigenaar en permissies hebben.

Voorbeeld:

```bash
ls -la /srv/minecraft/
```

Gevoelige configuratiebestanden worden niet wereld-leesbaar gemaakt.

Bijvoorbeeld:

```bash
chmod 600 <bestand>
```

waar passend.

Private keys en credentials mogen nooit onnodig toegankelijk zijn voor andere gebruikers.

---

# 🔑 Secrets

Wachtwoorden, API-tokens, private keys en andere secrets worden niet opgenomen in:

* de wiki;
* openbare GitHub-repositories;
* screenshots;
* scripts die publiek beschikbaar zijn.

Gebruik in documentatie uitsluitend placeholders:

```text
<SERVER_IP>
<DOMAIN>
<API_TOKEN>
<DATABASE_PASSWORD>
```

---

# 📋 Hardening-baseline

Iedere nieuwe Tulpencraft-server moet minimaal voldoen aan onderstaande baseline.

* [ ] Rocky Linux 10 geïnstalleerd
* [ ] Systeem volledig bijgewerkt
* [ ] Alleen noodzakelijke repositories actief
* [ ] Alleen noodzakelijke software geïnstalleerd
* [ ] Beheerdersaccount aangemaakt
* [ ] `sudo` correct ingericht
* [ ] SSH-sleutel geïnstalleerd
* [ ] Directe root-login via SSH uitgeschakeld
* [ ] Wachtwoordlogin via SSH uitgeschakeld nadat sleuteltoegang is getest
* [ ] SELinux actief in `Enforcing`
* [ ] firewalld actief
* [ ] Alleen noodzakelijke netwerkpoorten geopend
* [ ] Fail2Ban geïnstalleerd indien van toepassing
* [ ] Fail2Ban-service actief indien van toepassing
* [ ] SSH-jail actief wanneer SSH publiek bereikbaar is
* [ ] Onnodige services uitgeschakeld
* [ ] Tijdssynchronisatie actief
* [ ] Hostnaam correct ingesteld
* [ ] Logging gecontroleerd
* [ ] Luisterende netwerkpoorten gecontroleerd
* [ ] Bestandsrechten gecontroleerd
* [ ] Minecraft/servicegebruikers zonder rootrechten
* [ ] Back-upstrategie vastgesteld
* [ ] Monitoring ingericht indien van toepassing

---

# 🛡️ CIS en security frameworks

De Tulpencraft-hardening is een **eigen praktische baseline** en moet niet worden geïnterpreteerd als formele CIS-, DISA-STIG-, ISO 27001- of andere compliance-certificering.

Voor Rocky Linux 10 bestaat een specifieke **CIS Benchmark** met beveiligingsrichtlijnen. Deze kan in de toekomst worden gebruikt om de Tulpencraft-baseline verder te toetsen en aan te scherpen.

Het uitgangspunt blijft dat beveiligingsmaatregelen proportioneel moeten zijn voor de functie van de server.

Een Minecraft-server moet bijvoorbeeld niet zodanig worden gehard dat noodzakelijke Minecraft-functionaliteit of beheerbaarheid wordt beperkt zonder dat daar een aantoonbaar beveiligingsvoordeel tegenover staat.

---

# 🔧 Uitzonderingen

Niet iedere server heeft exact dezelfde configuratie.

Een uitzondering kan noodzakelijk zijn vanwege:

* Minecraft;
* Velocity;
* databases;
* monitoring;
* backups;
* netwerkfunctionaliteit;
* toekomstige diensten.

Een uitzondering moet waar mogelijk worden **gedocumenteerd**.

Daarbij wordt vastgelegd:

| Onderdeel    | Beschrijving                                |
| ------------ | ------------------------------------------- |
| Server       | Welke server                                |
| Maatregel    | Welke hardeningmaatregel                    |
| Uitzondering | Wat wijkt af                                |
| Reden        | Waarom                                      |
| Risico       | Welk risico ontstaat                        |
| Mitigatie    | Welke aanvullende maatregel wordt toegepast |
| Datum        | Wanneer vastgesteld                         |

---

# 🔄 Onderhoud

Hardening is geen eenmalige installatiehandeling.

Bij wijzigingen aan een server wordt opnieuw gekeken naar:

* software;
* services;
* firewall;
* SELinux;
* Fail2Ban;
* SSH;
* netwerkpoorten;
* gebruikers;
* rechten;
* logging;
* updates.

Bij grote wijzigingen wordt de hardening opnieuw gecontroleerd.

---

# 📚 Gerelateerde documentatie

* [[technische-infrastructuur:overzicht|Technische infrastructuur – Overzicht]]
* [[technische-infrastructuur:os-installatie|OS-installatie]]
* [[technische-infrastructuur:rocky-linux-10|Rocky Linux 10]]
* [[technische-infrastructuur:java|Java]]
* [[technische-infrastructuur:firewall|Firewall]]
* [[technische-infrastructuur:selinux|SELinux]]
* [[technische-infrastructuur:systemd|systemd]]
* [[technische-infrastructuur:monitoring|Monitoring & logging]]
* [[technische-infrastructuur:backups|Backups]]

---

> **Tulpencraft security baseline**
>
> Nieuwe servers worden niet beschouwd als productieklaar zodra Rocky Linux is geïnstalleerd. De server moet eerst volgens de Tulpencraft-hardeningbaseline worden ingericht, gecontroleerd en gedocumenteerd.