VPS ohne Logs einrichten: echtes No-Logs-Setup fuer dein VPN

Schwierigkeit: Mittel 8 Min. Lesezeit Aktualisiert: 18.07.2026 9
VPS ohne Logs einrichten: echtes No-Logs-Setup fuer dein VPN
Wenn du dein eigenes VPN betreibst, ist der Datenschutzgewinn, dass kein Unternehmen deinen Traffic protokolliert. Aber ein Standard-Linux-Server fuehrt trotzdem eigene Aufzeichnungen - System-Logs, SSH-Login-Historie, Shell-Historie. Diese Anleitung stutzt einen VPS Schritt fuer Schritt auf ein echtes No-Logs-Setup zusammen und bleibt ehrlich in Bezug auf die Grenzen.

Was auf einem Server tatsaechlich protokolliert wird

Der Reiz eines eigenen VPN ist einfach: Kein Unternehmen sitzt zwischen dir und dem Internet und notiert, was du tust. Aber ein Linux-Server im Auslieferungszustand fuehrt trotzdem seine eigenen Aufzeichnungen, und wenn du ein echtes No-Logs-Setup willst, musst du wissen, welche das sind:

  • WireGuard selbst fuehrt kein Verkehrsprotokoll. Standardmaessig schreibt es nichts ueber deine Verbindungen auf die Festplatte. Es haelt nur den letzten Handshake-Zeitpunkt und deinen aktuellen Endpunkt im Speicher, was du mit wg show siehst - und das wird beim Neustart geloescht. Die VPN-Schicht ist also bereits sauber.
  • Das Betriebssystem ist der laute Teil. Das Journal von systemd (journald) zeichnet Dienstereignisse auf. Wenn rsyslog installiert ist, schreibt es zusaetzlich Klartextdateien wie /var/log/syslog und /var/log/auth.log - und auth.log protokolliert jede einzelne SSH-Anmeldung. Separate Dateien (wtmp, btmp, lastlog) halten fest, wer sich wann angemeldet hat, und deine Shell fuehrt eine ~/.bash_history.
  • Und ein paar leisere Wege auf die Festplatte. Wenn der Server swap aktiviert hat, kann der Kernel Seiten des RAM - Schluessel inklusive - auf die Festplatte auslagern. Ein abstuerzendes Programm kann einen core dump seines Speichers hinterlassen. Und der Paketmanager schreibt Update-Protokolle unter /var/log/apt. Ein gruendliches Setup schliesst auch diese.
Diese Anleitung setzt voraus, dass du einen frischen Ubuntu-22.04- oder 24.04-Server hast und WireGuard bereits eingerichtet ist (siehe unsere Anleitung Wie du dein eigenes WireGuard-VPN auf einem VPS einrichtest). Fuehre alles Folgende als root aus.

Die ehrliche Grenze: was No-Logs kann und was nicht

Bevor du irgendetwas anfasst, sei dir klar darueber, was du tatsaechlich bekommst. Logs abzuschalten hindert deinen eigenen Server daran, Aufzeichnungen zu fuehren - wenn die Festplatte also jemals beschlagnahmt, abgebildet oder von jemandem gelesen wird, der eindringt, gibt es weit weniger zu finden. Das ist ein echter, lohnenswerter Gewinn.

Was es nicht tut, ist dich vor dem Unternehmen zu verbergen, das dir den Server vermietet. Dein VPS-Anbieter weiss immer, dass eine Maschine an dieser IP existiert, kann sehen, wie viel Bandbreite sie bewegt, und koennte prinzipiell den Verkehr auf Netzwerk- oder Hypervisor-Ebene beobachten - keine Einstellung innerhalb deines Servers aendert das. No-Logs geht darum, deinen eigenen Fussabdruck zu minimieren, nicht darum, fuer den Host unsichtbar zu werden. Waehle einen Anbieter, mit dem du dich wohlfuehlst, und betrachte die Schritte unten als Risikominderung, nicht als Ausloeschung.

No-Logs ist keine Garantie fuer Anonymitaet. Zwei Grenzen, die keine Servereinstellung aendern kann:

  • Dein Anbieter sieht die verbindenden IPs. Der Inhalt ist verschluesselt, aber er kann sehen, dass deine Heim-IP den WireGuard-Port erreicht hat, und wann.
  • Dein Anbieter kann den RAM als Snapshot erfassen. Ein VPS ist eine virtuelle Maschine; der Host steuert den Hypervisor und kann den aktiven Speicher erfassen (die aktiven WireGuard-Schluessel und verbundenen Peers) und kann auf eine gueltige rechtliche Anordnung hin gezwungen werden, ihn der Polizei zu uebergeben.

Fazit: Dir gehoert die Software, nicht die Maschine. No-Logs senkt dein Risiko, es loescht es nicht aus.

Was ist mit einem dedizierten (Bare-Metal-)Server? Er entfernt den Hypervisor, es gibt also keinen stillen Speicherauszug per Einzelbefehl - eine echte Verbesserung. Aber es ist trotzdem keine Garantie: Dem Anbieter gehoert die physische Maschine und das Netzwerk. Er sieht weiterhin die verbindenden IPs, und weil er physischen Zugriff plus Out-of-Band-Management hat (IPMI / BMC, ein separater Controller mit eigener Netzwerkverbindung), ist der laufende RAM weiterhin erreichbar - zum Beispiel ueber einen Cold-Boot- oder DMA-Angriff. Ein dedizierter Server erhoeht den Aufwand, er beseitigt nicht die Notwendigkeit, deinem Host zu vertrauen.

Schritt 1: Das systemd-Journal in den RAM verlegen

Sage zuerst journald, sein Journal nur im Speicher zu halten, damit es nie auf der Festplatte landet und bei jedem Neustart verschwindet. Oeffne seine Konfiguration:

nano /etc/systemd/journald.conf

Setze im Abschnitt [Journal] diese beiden Zeilen (entferne das fuehrende #, falls vorhanden):

[Journal]
Storage=volatile
RuntimeMaxUse=16M

Wende es an, und das Journal liegt nun in /run (RAM), begrenzt auf 16 MB und beim Neustart verschwunden:

systemctl restart systemd-journald

Schritt 2: Das gesamte /var/log in den RAM legen

Das Journal liegt nun im Speicher, aber mehrere Werkzeuge legen weiterhin Klartextdateien in /var/log ab - rsyslog, das auth.log, das SSH-Anmeldungen aufzeichnet, die apt-Update-Protokolle und die Anmeldeaufzeichnungen wtmp/btmp/lastlog (die bei jeder Anmeldung neu geschrieben werden, sodass ein einfaches Loeschen nichts bringt). Die saubere Rundumloesung ist, das gesamte Verzeichnis /var/log als tmpfs einzuhaengen - ein RAM-gestuetztes Dateisystem, das bei jedem Neustart geleert wird. Fuege eine Zeile zu /etc/fstab hinzu:

echo "tmpfs /var/log tmpfs defaults,noatime,nosuid,nodev,mode=0755,size=50M 0 0" >> /etc/fstab

Jetzt liegt alles unter /var/log im Speicher und leert sich bei jedem Neustart. Starte einmal neu, damit laufende Dienste ihre Logdateien innerhalb der neuen RAM-Disk erneut oeffnen:

reboot
Ein Vorbehalt: Weil /var/log beim Neustart geleert wird, kann Software, die du spaeter hinzufuegst und die ihren eigenen Log-Unterordner erwartet (etwa ein Webserver), es noetig haben, dass dieser Ordner neu angelegt wird. Fuer eine Maschine, die nur dein VPN betreibt, ist das kein Problem.

Schritt 3: Swap abschalten

Wenn der Server Swap aktiviert hat, kann der Kernel bei Speicherknappheit Seiten des RAM - moeglicherweise inklusive aktiver Schluessel - auf die Festplatte schieben. Auf einer No-Logs-Maschine soll der Speicher im Speicher bleiben. Schalte Swap jetzt ab und halte ihn ueber Neustarts hinweg abgeschaltet:

swapoff -a
sed -i.bak '/\sswap\s/s/^/#/' /etc/fstab

Viele kleine VPS werden ganz ohne Swap ausgeliefert - in diesem Fall tut swapoff -a einfach nichts, was in Ordnung ist.

Schritt 4: Core Dumps abschalten

Wenn ein Programm abstuerzt, kann systemd-coredump einen Core Dump - eine Momentaufnahme des Programmspeichers - auf die Festplatte unter /var/lib/systemd/coredump/ schreiben. Schalte es ab:

mkdir -p /etc/systemd/coredump.conf.d
printf '[Coredump]Storage=none' > /etc/systemd/coredump.conf.d/99-nolog.conf
systemctl daemon-reload

Schritt 5: Shell- und Editor-Verlauf abschalten

Deine Shell speichert jeden Befehl in ~/.bash_history, und Editoren hinterlassen ihre eigenen Spuren (~/.viminfo, ~/.lesshst). Leite sie alle nach /dev/null um, damit nie etwas geschrieben wird. Fuer den aktuellen Benutzer:

ln -sf /dev/null ~/.bash_history
ln -sf /dev/null ~/.viminfo
ln -sf /dev/null ~/.lesshst

Hindere dann bash daran, fuer jede Login-Shell auf dem System eine Verlaufsdatei zu fuehren, damit auch andere Konten abgedeckt sind:

printf 'unset HISTFILEexport HISTSIZE=0' > /etc/profile.d/00-nohistory.sh

Wenn du weitere Benutzerkonten hast, wiederhole die drei ln -sf-Zeilen auch fuer jedes ihrer Home-Verzeichnisse.

Schritt 6: Einbruchsschutz aktiviert lassen - du bist nicht blind

Ein verbreiteter Mythos ist, dass das Abschalten von Logs dich wehrlos macht. Das muss nicht sein. fail2ban - das Werkzeug, das eine IP nach wiederholten fehlgeschlagenen Anmeldungen sperrt - kann direkt aus dem systemd-Journal lesen, das jetzt im RAM liegt. So behaeltst du automatischen Brute-Force-Schutz und schreibst dennoch nichts auf die Festplatte. Installiere es:

apt install fail2ban -y

Richte es auf das Journal aus, indem du /etc/fail2ban/jail.local mit folgendem Inhalt erstellst:

[DEFAULT]
backend = systemd

Starte es dann neu und schliesse zusaetzlich die offensichtlichen Tueren:

systemctl restart fail2ban
  • Nur SSH-Schluessel. Deaktiviere die Passwort-Anmeldung in /etc/ssh/sshd_config (PasswordAuthentication no) und starte ssh neu. Ein Schluessel laesst sich nicht erraten, wie es bei einem Passwort geht.
  • Firewall standardmaessig geschlossen. Lass ufw nur SSH und deinen WireGuard-Port (51820/udp) zu, alles andere verweigert.
  • Automatische Sicherheitsupdates. Installiere unattended-upgrades; seine Protokolle liegen jetzt im RAM-gestuetzten /var/log, verschwinden also ebenfalls beim Neustart.
Die Reihenfolge zaehlt: Bring schluesselbasiertes SSH zum Laufen und teste es in einem zweiten Terminal, bevor du irgendetwas verschaerfst. Wenn du dich aussperrst, hast du jetzt nur sehr wenige Logs zum Debuggen.

Schritt 7: Pruefen, dass nichts erhalten bleibt

Starte noch einmal neu, melde dich wieder an und pruefe die vier Dinge, die du geaendert hast:

mount | grep /var/log
swapon --show
journalctl --no-pager | wc -l
ls -lh /var/log

Du solltest /var/log als tmpfs eingehaengt sehen, keinen aktiven Swap, ein nahezu leeres Journal und ein frisches, fast leeres /var/log. Von hier an behaelt der Server im Wesentlichen nichts auf der Festplatte darueber, was durch ihn hindurchgeht.

Wann du vielleicht doch einige Logs behalten willst

No-Logs ist nicht automatisch fuer jeden das Richtige. Wenn der Server mehr tut, als dein persoenliches VPN zu betreiben - eine Website hostet, den Verkehr anderer Leute abwickelt - moechtest du vielleicht ein wenig Verlauf, um Probleme zu erkennen. Gute Nachricht: Das Setup oben behaelt bereits kurzfristige Logs im RAM (im Journal und im tmpfs /var/log), sodass du Einsicht innerhalb derselben Sitzung bekommst, ohne dauerhaft etwas auf die Festplatte zu schreiben. Wenn du mehr brauchst, erhoehe RuntimeMaxUse in Schritt 1 oder die tmpfs-size in Schritt 2. Passe die Konsequenz daran an, wie du die Maschine tatsaechlich nutzt.

Tags: vps no logs privacy hardening self-hosted wireguard linux anonymity