ubuntu-serverlinux-serversshfail2banserver-security

Ubuntu Server absichern: Linux Server sicher einrichten

By Piotr Rasiński
Picture of the author
Published on
Projektart
Linux Server Einrichtung für einen Kunden
System
Ubuntu Server
Fokus
SSH, sudo, Firewall, Fail2ban, systemd
Ziel
Sicherer und wartbarer Linux Server
Nutzen
Technische Basis für produktive Serverprojekte
Ubuntu Server Einrichtung und Linux Server Hardening

In diesem Kundenprojekt musste ich einen Ubuntu Server einrichten und einen Linux Server sicher einrichten, damit daraus eine belastbare Basis für den produktiven Betrieb wird. Genau darum geht es in diesem Beitrag: nicht um eine schnelle Testinstallation, sondern um eine saubere Serverstruktur mit Updates, Benutzerrechten, SSH-Härtung, Firewall, fail2ban, Swap und systemd.

Ein Ubuntu Server ist zwar schnell erstellt, aber erst die technische Nacharbeit macht ihn im Alltag stabil. Wenn Root offen bleibt, SSH zu locker konfiguriert ist oder Dienste später nur per Hand gestartet werden, entsteht schnell ein System, das zwar läuft, aber unnötig riskant bleibt. Deshalb habe ich den Server in diesem Projekt Schritt für Schritt sicher aufgebaut und so vorbereitet, dass er langfristig wartbar bleibt.

Ausgangslage: Ein Ubuntu Server als saubere Produktionsbasis

Der Kunde benötigte einen neuen Ubuntu Server, der später weitere Anwendungen, Hintergrundprozesse und Verwaltungsaufgaben zuverlässig tragen kann. Bevor zusätzliche Software auf den Server kommt, muss zuerst das Fundament stimmen. Genau dafür wurde der Server systematisch eingerichtet.

Wichtig waren dabei vor allem diese Punkte:

  • saubere Ubuntu-Server-Installation
  • direkter Sicherheitscheck nach dem ersten Login
  • System aktualisieren
  • Benutzer und sudo sauber einrichten
  • Root-Login deaktivieren
  • SSH absichern
  • Firewall-Regeln gezielt setzen
  • automatische Sicherheitsupdates vorbereiten
  • Schutz gegen Login-Angriffe aktivieren
  • technische Basis für produktive Dienste schaffen

Gerade bei solchen Projekten ist es sinnvoll, nicht alles auf einmal zu installieren. Zuerst wird die Kernstruktur sauber aufgebaut. Danach folgen zusätzliche Dienste und Deployments. So bleibt die Basis verständlich und kontrollierbar.

Ubuntu Server prüfen und direkt aktualisieren

Nach der Bereitstellung wurde zuerst geprüft, welche Ubuntu-Version tatsächlich läuft. Das ist ein kleiner Schritt, aber technisch wichtig, weil sich daraus spätere Paketstände, Dokumentation und die passende Update-Strategie ergeben.

lsb_release -a
cat /etc/os-release

Anschließend wurde das System direkt aktualisiert. Gerade auf einem neuen Server ist das wichtig, weil veraltete Pakete unnötige Risiken mitbringen.

apt update
apt upgrade -y
apt autoremove -y

Danach wurden nur die Werkzeuge installiert, die für Verwaltung, Fehlersuche und Absicherung wirklich gebraucht werden.

apt install curl git htop unzip ufw fail2ban unattended-upgrades -y

Dieser Abschnitt ist bewusst einfach gehalten. Genau das ist aber der Punkt. Ein Linux Server wird nicht durch möglichst viele Pakete besser, sondern durch eine saubere und kontrollierte Grundbasis.

Benutzer anlegen und sudo sauber nutzen

Ein produktiver Server sollte nicht dauerhaft direkt als Root verwaltet werden. Deshalb wurde ein eigener Benutzer erstellt und zur sudo-Gruppe hinzugefügt.

adduser deploy
usermod -aG sudo deploy

Danach wurde der Benutzer direkt geprüft:

su - deploy
sudo whoami
sudo apt update

Dieser Schritt wirkt simpel, ist aber zentral. Er zeigt, dass der Server nicht nur installiert, sondern auch für den Alltag vorbereitet wurde. Rechte werden bewusst und nachvollziehbar vergeben. Das macht die spätere Administration deutlich sauberer.

Root-Login deaktivieren und SSH absichern

Einer der wichtigsten Sicherheitsbausteine war die Entscheidung, den direkten Root-Login per SSH zu deaktivieren. Sobald ein normaler Benutzer mit sudo funktioniert, ist das in vielen Setups der bessere Weg. So wird der Zugang klarer begrenzt und die Angriffsfläche sinkt spürbar.

Zuerst wurde die SSH-Konfiguration geöffnet:

nano /etc/ssh/sshd_config

Danach wurden zentrale Punkte angepasst:

Port 2222
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers deploy

Anschließend wurde der Dienst neu gestartet:

systemctl restart ssh

Diese Konfiguration geht bewusst über reine Basics hinaus. Der Server akzeptiert dadurch keinen Root-Login mehr, verzichtet auf Passwort-Login und erlaubt nur noch einen definierten Benutzer per SSH-Key.

SSH-Key-Struktur und Dateirechte richtig setzen

Damit ein Key-basierter Login stabil funktioniert, müssen auch die Dateirechte stimmen. Gerade bei SSH werden unsaubere Rechte schnell zum Problem. Deshalb wurde die Verzeichnisstruktur direkt sauber angelegt.

mkdir -p /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
nano /home/deploy/.ssh/authorized_keys
chmod 600 /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh

Dateirechte sind hier kein Detail, sondern ein Kernpunkt der Sicherheit. Wenn dieser Teil sauber gesetzt ist, bleibt der SSH-Zugang stabil und reproduzierbar.

Firewall aktivieren und nur notwendige Ports öffnen

Nach Benutzer- und SSH-Konfiguration wurde die Firewall eingerichtet. Für Ubuntu ist ufw dafür eine pragmatische Lösung, weil sich Regeln klar setzen und schnell prüfen lassen.

ufw default deny incoming
ufw default allow outgoing
ufw allow 2222/tcp
ufw allow 80/tcp
ufw allow 443/tcp

Danach wurde die Firewall aktiviert und kontrolliert:

ufw enable
ufw status verbose

Gerade bei neuen Servern ist das ein entscheidender Punkt. Statt alles offen zu lassen, werden nur die Ports freigegeben, die später wirklich gebraucht werden. So entsteht eine deutlich sauberere Grundabsicherung für den gesamten Server.

Fail2ban gegen wiederholte Login-Versuche einsetzen

Ein weiterer wichtiger Schritt war die zusätzliche Absicherung gegen wiederholte SSH-Login-Versuche. Dafür wurde fail2ban nicht nur installiert, sondern auch aktiv für den angepassten SSH-Port konfiguriert.

cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
nano /etc/fail2ban/jail.local
systemctl restart fail2ban

Die relevante Konfiguration für SSH sah vereinfacht so aus:

[sshd]
enabled = true
port = 2222
maxretry = 5
findtime = 10m
bantime = 1h

Danach wurde der Status geprüft:

fail2ban-client status sshd

Damit wird aus einer einfachen Server-Einrichtung ein deutlich robusteres System. Es geht nicht nur darum, Dienste zu starten, sondern Angriffsflächen bewusst zu verkleinern.

Automatische Sicherheitsupdates vorbereiten

Ein weiterer Schritt, der in vielen kurzen Tutorials fehlt, aber in der Praxis sehr wertvoll ist, sind automatische Sicherheitsupdates. Gerade bei Kundenservern ist das sinnvoll, weil wichtige Pakete nicht nur manuell gepflegt werden müssen.

dpkg-reconfigure unattended-upgrades
cat /etc/apt/apt.conf.d/50unattended-upgrades

Technisch ist das keine spektakuläre Einzelmaßnahme. Trotzdem unterscheiden genau solche Punkte einen kurz eingerichteten Testserver von einer soliden produktiven Basis.

Swap-Datei für kleinere Server ergänzen

Nicht jeder Ubuntu Server bringt von Haus aus genug RAM für Lastspitzen, Paketoperationen oder Hintergrundprozesse mit. Deshalb wurde zusätzlich eine Swap-Datei eingerichtet. Gerade bei kleineren VPS-Setups ist das sinnvoll, weil es mehr Stabilität bei kurzfristigen Lastspitzen schafft.

fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
free -h

Damit die Swap-Datei nach einem Neustart erhalten bleibt, wurde sie in /etc/fstab eingetragen:

/swapfile none swap sw 0 0

Auch dieser Schritt zeigt, dass der Server nicht nur oberflächlich eingerichtet wurde. Hier geht es bereits um den stabilen Betrieb unter realen Bedingungen.

systemd nutzen, um Prozesse sauber zu verwalten

Ein besonders technischer Teil des Projekts war die Vorbereitung für eigene Dienste über systemd. Statt Prozesse später nur manuell zu starten, ist es deutlich sauberer, sie als Dienst zu definieren. Das verbessert Neustarts, Logging und Wartbarkeit.

Ein vereinfachtes Beispiel für einen eigenen Dienst:

[Unit]
Description=Project Worker
After=network.target

[Service]
User=deploy
WorkingDirectory=/var/www/project
ExecStart=/usr/bin/node worker.js
Restart=always
Environment=NODE_ENV=production

[Install]
WantedBy=multi-user.target

Danach wird die Definition geladen und aktiviert:

systemctl daemon-reload
systemctl enable project-worker
systemctl start project-worker
systemctl status project-worker

Genau an solchen Stellen wird technisches Verständnis sichtbar. Ein Server ist nicht erst dann gut eingerichtet, wenn Pakete installiert sind, sondern dann, wenn Prozesse sauber, kontrolliert und reproduzierbar laufen.

Logs und Fehleranalyse von Anfang an mitdenken

Ein weiterer Punkt, der in echten Serverprojekten wichtig ist, ist die Kontrolle von Logs. Dazu wurden nicht nur Dienste gestartet, sondern auch direkt geprüft, wie sich Fehler und Zustände sauber auslesen lassen.

journalctl -u ssh -n 50
journalctl -u fail2ban -n 50
journalctl -p 3 -xb

Solche Befehle sind nicht kompliziert, aber enorm wichtig. Denn gerade bei SSH, Firewall, fail2ban oder eigenen systemd-Diensten zeigt sich Qualität nicht nur in der Einrichtung, sondern auch darin, wie schnell ein Problem sauber gefunden werden kann.

Dateirechte und Besitz für Projekte bewusst setzen

Sobald Anwendungen, Websites oder Deployments auf einem Linux Server laufen, müssen Rechte und Besitzverhältnisse klar gesetzt werden. Statt unsauberer Schnelllösungen wurde hier mit festen Benutzer- und Gruppenstrukturen gearbeitet.

chown -R deploy:www-data /var/www/project
find /var/www/project -type d -exec chmod 755 {} \;
find /var/www/project -type f -exec chmod 644 {} \;

Das ist ein weiterer Punkt, der zeigt, dass das Projekt über reine Installationsschritte hinausgeht. Rechte, Besitz und Verantwortlichkeiten wurden bewusst so gesetzt, dass spätere Wartung und Sicherheit zusammenpassen.

Warum genau diese Server-Bausteine wichtig sind

Die Stärke eines guten Ubuntu Servers liegt nicht in möglichst vielen installierten Paketen, sondern in einer sauber aufgebauten Grundstruktur. Genau deshalb wurden in diesem Projekt die technischen Entscheidungen bewusst gestaffelt.

BereichTechnischer Nutzen
Ubuntu Server Installationstabile Systembasis
Benutzer und sudosichere Administration
Root deaktivierenweniger Risiko beim Remote-Zugriff
SSH-Key-Onlystärker abgesicherter Zugang
Firewallnur notwendige Ports offen
Fail2banSchutz gegen wiederholte Login-Versuche
unattended-upgradeslaufende Sicherheitsupdates
Swapmehr Stabilität bei Lastspitzen
systemdreproduzierbarer Dienstbetrieb
Log-Prüfungbessere Fehleranalyse

Gerade diese Kombination macht aus einem einfachen Linux Server eine Struktur, die auch unter realen Bedingungen sinnvoll betreibbar bleibt.

Ergebnis: Ein Ubuntu Server mit sauberer technischer Basis

Am Ende stand ein Ubuntu Server, der nicht nur installiert, sondern Schritt für Schritt auf produktiven Betrieb vorbereitet wurde. Die wichtigsten Grundlagen wurden bewusst nicht übersprungen, sondern technisch sauber umgesetzt.

Die Ergebnisse im Überblick:

  • Ubuntu Server installiert und aktualisiert
  • neuen Benutzer angelegt und sudo eingerichtet
  • Root-Login deaktiviert
  • SSH auf Key-Only und eigenen Port umgestellt
  • Firewall mit klaren Regeln aktiviert
  • fail2ban für SSH eingerichtet
  • automatische Sicherheitsupdates vorbereitet
  • Swap-Datei ergänzt
  • systemd für eigene Dienste sauber vorbereitet
  • Logs, Rechte und Besitz strukturiert gesetzt

Fazit: Ubuntu Server einrichten und Linux Server sicher konfigurieren

Dieses Projekt zeigt, wie ich einen Ubuntu Server einrichten und einen Linux Server sicher konfigurieren konnte, ohne die Wartbarkeit aus dem Blick zu verlieren. Installation, sudo, Root-Login deaktivieren, SSH absichern, Firewall und Rechteverwaltung gehören zur Grundlage. Wirklich spannend wird der Server aber dort, wo zusätzliche technische Entscheidungen dazukommen: fail2ban, automatische Sicherheitsupdates, Swap, systemd und saubere Log-Kontrolle.

Genau dadurch entsteht aus einem frischen Linux Server keine bloße Testumgebung, sondern eine belastbare technische Basis. Und genau das macht solche Projekte interessant: Sie zeigen nicht nur, dass ein Server läuft, sondern dass er mit Blick auf Sicherheit, Wartbarkeit und echten Betrieb eingerichtet wurde.

Fehler-Radar abonnieren

Verpasse keine Tech-Insights mehr

Die neuesten Beiträge, erprobte Best Practices und technische SEO-Strategien aus meinem Entwickler-Alltag – regelmäßig und kompakt direkt in dein Postfach. Kein Spam, nur echte Erfahrungswerte.