Webmin auf dem VPS absichern: Port 10000 schließen

Webmin auf einem öffentlichen VPS absichern

Webmin auf einem öffentlichen VPS absichern heißt zuerst: die Oberfläche darf nicht länger auf Port 10000 für das ganze Internet antworten. Dafür gibt es zwei ehrliche Varianten. Entweder Webmin lauscht nur noch auf 127.0.0.1 und Sie erreichen es über einen SSH-Tunnel, oder nginx steht davor, beendet TLS (Transport Layer Security, die Verschlüsselung hinter HTTPS) mit einem echten Zertifikat, und Port 10000 bleibt in der Firewall geschlossen. Für einen einzelnen Administrator würde ich den SSH-Tunnel nehmen. Er kostet zwei Zeilen Konfiguration, und danach gibt es von außen keine Anmeldemaske mehr, die jemand ausprobieren kann.

Alle Befehle hier sind Beispiele für Ihren eigenen Server. Vergleichen Sie die Ausgaben bitte nicht mit einer Musterzeile, sondern lesen Sie sie: welche Adresse Webmin belegt und was Ihre Firewall wirklich durchlässt, hängt an Ihrer Installation und an Ihrem Anbieter.

Warum der Zustand nach der Installation gefährlich ist

Webmin läuft als root. Der Webserver dahinter heißt miniserv.pl, ein kleiner Perl-Server, der mit vollen Rechten startet, weil er Pakete installieren, Dienste neu starten und Benutzer anlegen können muss. Eine erfolgreiche Anmeldung an dieser Oberfläche ist damit gleichwertig zu einer Root-Shell. Ein offener Port 10000 ist also kein offener Webserver. Es ist eine öffentlich erreichbare Root-Anmeldung.

Dazu kommt das selbst signierte Zertifikat, das Webmin bei der Installation erzeugt. Ihr Browser kennt den Aussteller nicht und warnt. Sie klicken die Warnung weg, weil Sie es sind, und gewöhnen sich daran. Ab diesem Punkt können Sie einen echten Angriff auf der Leitung nicht mehr von der gewohnten Warnung unterscheiden, weil beide gleich aussehen. Wer Webmin gerade erst aufgesetzt hat und den Ausgangszustand nachlesen möchte, findet ihn in der Anleitung zu Webmin unter Ubuntu 24.04 installieren.

Schauen Sie einmal in /var/webmin/miniserv.log und /var/webmin/miniserv.error. Achten Sie darauf, welche fremden Adressen dort bereits auftauchen und wie oft. Port 10000 gehört zu den Ports, die flächendeckend gescannt werden, und ein VPS mit öffentlicher IP wird oft schon in der ersten Stunde gefunden.

Welche der beiden Varianten passt zu Ihnen?

Nehmen Sie den SSH-Tunnel, wenn Sie der einzige Administrator sind oder wenn alle Beteiligten ohnehin einen SSH-Zugang zum Server haben. Sie brauchen keinen DNS-Eintrag, kein Zertifikat und keinen zweiten Dienst, der gepflegt werden will.

Nehmen Sie den nginx-Weg, wenn mehrere Personen die Oberfläche benutzen, wenn Sie vom Telefon oder aus einem fremden Netz heran müssen, oder wenn auf dem Server ohnehin schon ein Reverse Proxy läuft. Der Preis dafür: Sie betreiben eine Login-Seite im offenen Netz, also brauchen Sie Zwei-Faktor-Anmeldung und eine Sperre für Anmeldeversuche, dazu weiter unten mehr.

Variante 1: Webmin an 127.0.0.1 binden und per SSH-Tunnel erreichen

Sichern Sie die Konfiguration, bevor Sie sie ändern. Die Kopie ist Ihr Rückweg, falls Sie sich aussperren.

sudo cp /etc/webmin/miniserv.conf /etc/webmin/miniserv.conf.bak
sudo nano /etc/webmin/miniserv.conf

Setzen oder ergänzen Sie diese Zeilen. bind ist die Adresse, auf der miniserv.pl zuhört. Ohne diese Zeile nimmt Webmin alle Adressen des Servers an, also auch die öffentliche.

bind=127.0.0.1
port=10000
ssl=1

sudo systemctl restart webmin
sudo ss -tlnp | grep 10000

In der Ausgabe von ss interessiert Sie nur die linke Adressspalte. Steht dort 127.0.0.1:10000, hört Webmin nur noch auf die Loopback-Adresse. Steht dort 0.0.0.0:10000, *:10000 oder [::]:10000, wurde die Datei nicht gelesen oder der Neustart ist fehlgeschlagen. Prüfen Sie dann systemctl status webmin.

Den Tunnel bauen Sie von Ihrem Arbeitsrechner auf, nicht auf dem Server:

ssh -N -L 10000:127.0.0.1:10000 admin@203.0.113.10

-L 10000:127.0.0.1:10000 bedeutet: was lokal an Port 10000 ankommt, wird durch die SSH-Verbindung geschickt und dort an 127.0.0.1:10000 zugestellt. -N sagt, dass keine Shell geöffnet werden soll, die Verbindung transportiert also nur den Tunnel. Solange dieses Fenster offen bleibt, erreichen Sie Webmin im Browser unter https://127.0.0.1:10000/.

Die Zertifikatswarnung bleibt, und sie wird sogar deutlicher, weil der Browser jetzt 127.0.0.1 sieht und das Zertifikat auf einen anderen Namen lautet. Das ist in dieser Variante kein Sicherheitsproblem: die Strecke ist bereits durch SSH verschlüsselt und authentifiziert, TLS läuft nur noch innerhalb des Tunnels. Wichtig ist, dass Sie die Warnung genau einmal prüfen und nicht dauerhaft blind wegklicken.

Jetzt schließen Sie den Port. Wenn Sie beim Installieren eine Freigabe angelegt haben, entfernen Sie sie wieder:

sudo ufw status numbered
sudo ufw delete allow 10000/tcp
sudo ufw status

Funktioniert der Tunnel nicht und die SSH-Sitzung selbst schon, dann sehen Sie in /etc/ssh/sshd_config und in /etc/ssh/sshd_config.d/ nach AllowTcpForwarding nach. Steht dort no, lehnt der Server die Weiterleitung ab, und genau das setzen viele Härtungsanleitungen. Was dabei sinnvoll ist und was nicht, steht im Beitrag über einen gehärteten SSH-Zugang auf dem VPS.

Variante 2: nginx davor, Port 10000 bleibt zu

Hier terminiert nginx TLS mit einem echten Zertifikat und spricht intern mit Webmin über die Loopback-Adresse. Voraussetzung ist ein DNS-A-Eintrag, zum Beispiel webmin.example.com, der auf Ihren VPS zeigt. Das Zertifikat holen Sie sich mit Certbot, beschrieben in der Anleitung zu Let's-Encrypt-Zertifikaten für nginx unter Ubuntu 24.04.

In /etc/webmin/miniserv.conf:

bind=127.0.0.1
ssl=1
redirect_ssl=1
redirect_host=webmin.example.com

In /etc/webmin/config, das ist eine andere Datei:

referers=webmin.example.com

Danach sudo /etc/webmin/restart oder sudo systemctl restart webmin.

redirect_host und redirect_ssl sind der Teil, den man leicht übersieht. Webmin baut nach einer Anmeldung absolute Weiterleitungs-URLs. Ohne diese beiden Zeilen setzt es dabei seinen eigenen Namen und Port ein, der Browser folgt der Weiterleitung, landet auf 127.0.0.1:10000 und die Anmeldung endet im Leeren. referers löst das zweite Problem: Webmin vergleicht den Referer-Header mit dem eigenen Hostnamen, und hinter einem Proxy passt der nicht mehr, solange der Proxy-Name nicht eingetragen ist.

Der nginx-Server-Block, angelehnt an die offizielle Webmin-Anleitung zum Proxy-Betrieb:

server {
    listen 443 ssl;
    server_name webmin.example.com;

    ssl_certificate     /etc/letsencrypt/live/webmin.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/webmin.example.com/privkey.pem;

    location / {
        proxy_pass https://127.0.0.1:10000/;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection Upgrade;
        proxy_set_header Host $host;

        proxy_buffering off;
        proxy_request_buffering off;
        client_max_body_size 64g;
    }
}

proxy_pass https:// ist kein Tippfehler: Webmin behält ssl=1, spricht also auch auf der Loopback-Adresse HTTPS. Die beiden Upgrade-Zeilen brauchen das eingebaute Terminal und der Dateimanager, die über WebSockets laufen. Ohne sie lädt die Oberfläche, aber das Terminalfenster bleibt leer. Ubuntu 24.04 liefert nginx 1.24 (Stand September 2026), dort gehört HTTP/2 als listen 443 ssl http2; in die listen-Zeile; ab nginx 1.25.1 schreiben Sie stattdessen http2 on; als eigene Direktive. Was die übrigen proxy_set_header-Zeilen bewirken, ist im Beitrag zu einer nginx-Reverse-Proxy-Konfiguration Zeile für Zeile auseinandergenommen.

sudo nginx -t
sudo systemctl reload nginx
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw delete allow 10000/tcp

nginx -t prüft die Syntax und nennt Datei und Zeilennummer, wenn etwas nicht stimmt. Laden Sie erst neu, wenn dieser Test durchläuft, sonst arbeitet der alte Stand weiter und Sie suchen den Fehler an der falschen Stelle.

Webmins eigene Zugriffskontrolle in miniserv.conf

Eine Firewallregel und eine Webmin-Regel sind zwei verschiedene Kontrollen, und sie scheitern unterschiedlich. Das ist der Grund, warum beide gesetzt gehören: wer nur eine davon macht, hält sich für fertig.

In /etc/webmin/miniserv.conf begrenzt allow die Adressen, von denen miniserv.pl Anfragen überhaupt beantwortet. Mehrere Einträge werden durch Leerzeichen getrennt, Netze schreiben Sie mit Maske:

allow=127.0.0.1 198.51.100.24 192.168.10.0/255.255.255.0

Setzen lässt sich das auch in der Oberfläche unter Webmin, Webmin Configuration, IP Access Control, dort heißt die passende Auswahl Only allow from listed addresses. Der Vorteil des Weges über die Oberfläche: Webmin schreibt die Zeile im eigenen Format und Sie vertippen sich nicht in der Maske.

Der Unterschied zur Firewall ist gut zu sehen, wenn etwas blockiert. Eine ufw-Regel verwirft das Paket, bevor Webmin davon erfährt, der Browser wartet und läuft in eine Zeitüberschreitung. Eine allow-Regel greift erst nach dem Verbindungsaufbau, Sie bekommen also sofort eine Fehlerseite von Webmin. Ein Timeout zeigt damit auf die Firewall, eine schnelle Fehlerseite auf miniserv.conf.

Ein Sonderfall, der viele Leute täuscht: hinter nginx kommen alle Anfragen von 127.0.0.1, weil nginx die Verbindung aufbaut. Die allow-Liste sieht dann nie die echte Adresse des Besuchers und kann niemanden mehr aussperren. Wenn Sie in Variante 2 nach Herkunft filtern wollen, gehört der Filter in den nginx-Block, nicht in miniserv.conf.

Referer-Prüfung, Zwei-Faktor und Sitzungsdauer

Diese drei Einstellungen finden Sie unter Webmin, Webmin Configuration. Ändern Sie sie in der Oberfläche, dann schreibt Webmin die passenden Zeilen selbst in /etc/webmin/config beziehungsweise /etc/webmin/miniserv.conf.

Trusted Referers steuert die Referer-Prüfung. Sie existiert gegen CSRF (Cross-Site Request Forgery), also gegen den Fall, dass eine fremde Seite in Ihrem angemeldeten Browser eine Webmin-Aktion auslöst. Die Option Trust links from unknown referers entscheidet, wie Webmin mit Anfragen ohne Referer-Header umgeht. Schalten Sie sie nicht aus Bequemlichkeit an, wenn eine Warnseite über einen Aufruf aus unbekannter Quelle erscheint. In der Proxy-Variante ist die richtige Antwort auf diese Warnung der referers-Eintrag mit Ihrem Proxy-Hostnamen.

Two-Factor Authentication aktiviert einen zweiten Faktor per TOTP (zeitbasiertes Einmalkennwort, das eine App auf dem Telefon erzeugt). Der Ablauf besteht aus zwei Schritten: erst schalten Sie den Anbieter serverweit ein, danach meldet sich jedes Benutzerkonto einzeln an und registriert seine App. Ohne den zweiten Schritt ändert sich für dieses Konto nichts. In Variante 2 ist das die wichtigste einzelne Maßnahme, weil dort ein gestohlenes Passwort sonst direkt zum Root-Zugriff führt.

Unter Authentication stehen die Sitzungseinstellungen. Interessant sind zwei davon: die automatische Abmeldung nach einer Zeit ohne Aktivität, und die Sperre eines Hosts nach mehreren Fehlversuchen für eine einstellbare Dauer. Die erste begrenzt den Schaden durch ein offen stehendes Browserfenster, die zweite macht das geduldige Durchprobieren von Passwörtern unbrauchbar. Nach dem Speichern sehen Sie in miniserv.conf die passenden Zeilen und können den Stand später ohne Anmeldung per SSH prüfen.

Prüfen, was von außen wirklich erreichbar ist

Testen Sie nie vom Server selbst. Über die Loopback-Adresse antwortet Webmin auch dann, wenn von außen alles dicht ist. Nehmen Sie einen zweiten Rechner oder einen zweiten Server.

• Auf dem Server: sudo ss -tlnp | grep -E ':(10000|443)'. Lesen Sie die linke Spalte und nur die.
• Von außen: nc -vz 203.0.113.10 10000. Achten Sie darauf, ob die Verbindung hängt und dann abbricht, oder ob sofort eine Ablehnung kommt.
• Von außen, für den Proxy: curl -I https://webmin.example.com/. Interessant ist, ob ein Zertifikatsfehler gemeldet wird.
• Im Panel Ihres Anbieters: viele VPS-Produkte haben eine eigene Netzwerk-Firewall vor der Maschine. Sie ist unabhängig von ufw und muss getrennt gepflegt werden.

Zwei Fälle, in denen eine ufw-Regel nicht das tut, was sie soll. Erstens IPv6: wenn Webmin auch auf [::]:10000 hört, Ihre Regeln aber nur die IPv4-Seite abdecken, bleibt der Port über die IPv6-Adresse offen. Das Muster und seine Lösung stehen im Beitrag zu offenen IPv6-Ports trotz passender ufw-Regel. Zweitens Docker: veröffentlichte Container-Ports tragen sich in eine Kette ein, die vor den ufw-Regeln greift, sodass ufw deny wirkungslos bleibt. Warum das so ist, zeigt der Beitrag über Docker-Ports, die ufw umgehen. Wenn Sie ufw gerade erst in Betrieb genommen haben, lohnt vorher ein Blick auf die Grundregeln von ufw auf einem VPS.

Wenn nach der Umstellung nichts mehr antwortet

Der Browser meldet eine abgelehnte Verbindung auf 127.0.0.1:10000. Der Tunnel steht nicht. Sehen Sie im Terminalfenster mit dem ssh -N nach, ob die Verbindung noch läuft. Nach einem Neustart des Servers oder einem Netzwechsel des Notebooks ist sie weg und muss neu aufgebaut werden.

Die Seite lädt gar nicht, aber ss zeigt Webmin auf 127.0.0.1. Prüfen Sie, ob Sie http:// statt https:// aufgerufen haben. Bei ssl=1 spricht Webmin nur TLS, ein Klartext-Aufruf führt zu einer unleserlichen oder leeren Antwort.

nginx antwortet mit 502. Der Proxy erreicht Webmin nicht. Häufigste Ursache ist ein falsches Schema in proxy_pass, also http:// gegen ein Webmin mit ssl=1. Sehen Sie in /var/log/nginx/error.log nach der jüngsten Zeile, die 127.0.0.1:10000 nennt, und lesen Sie, was dort als Grund steht.

Die Anmeldung gelingt, danach landen Sie auf einer nicht erreichbaren Adresse. redirect_host fehlt oder enthält einen anderen Namen als den, über den Sie hereinkommen. Beide müssen zeichengenau übereinstimmen.

Eine Warnseite spricht von einem Aufruf aus unbekannter Quelle. Das ist die Referer-Prüfung. Tragen Sie Ihren Proxy-Hostnamen in referers ein und starten Sie Webmin neu.

Sie haben sich komplett ausgesperrt. Genau dafür bleibt SSH der Rückweg. Spielen Sie die Sicherungskopie zurück und starten Sie den Dienst neu, dann sind Sie wieder im Ausgangszustand und können in Ruhe suchen.

sudo cp /etc/webmin/miniserv.conf.bak /etc/webmin/miniserv.conf
sudo systemctl restart webmin

Ist zusätzlich das Passwort weg, hilft der Weg über die Kommandozeile, beschrieben unter Webmin-Anmeldedaten und Passwort zurücksetzen.

Was danach noch zu tun bleibt

Halten Sie Webmin aktuell. Die Installation über das offizielle Paketrepository bedeutet, dass ein sudo apt update && sudo apt upgrade neue Versionen mitnimmt, und bei einer Oberfläche mit Root-Rechten ist das kein Punkt, den man aufschiebt. Legen Sie außerdem für jede Person ein eigenes Webmin-Konto an, statt ein gemeinsames root-Konto zu benutzen: nur so sagt Ihnen das Protokoll später, wer eine Änderung gemacht hat. Wenn der Server neu ist, gehört das alles in dieselbe Runde wie die übrigen Schritte aus den ersten zehn Minuten auf einem neuen VPS.

FAQ

Muss Webmin überhaupt aus dem Internet erreichbar sein?

Für einen einzelnen Administrator mit SSH-Zugang: nein. Binden Sie Webmin mit bind=127.0.0.1 an die Loopback-Adresse und arbeiten Sie über ssh -N -L 10000:127.0.0.1:10000 benutzer@server. Die Oberfläche bleibt vollständig nutzbar, aber von außen ist kein Port 10000 mehr sichtbar, den jemand scannen oder durchprobieren könnte. Einen öffentlich erreichbaren Zugang brauchen Sie erst, wenn mehrere Personen ohne SSH-Zugang heran müssen.

Reicht es nicht, den Port von 10000 auf etwas Unauffälliges zu ändern?

Nein. Ein anderer Port in port= schützt nur gegen Scans, die genau eine Portnummer prüfen. Wer einen vollständigen Portscan fährt, findet den Dienst trotzdem, und die Antwort ist als Webmin erkennbar. Ein geänderter Port senkt den Lärm in den Protokollen, er ersetzt aber weder die Bindung an 127.0.0.1 noch einen Proxy mit Zwei-Faktor-Anmeldung.

Was mache ich mit dem selbst signierten Zertifikat von Webmin?

Hinter einem SSH-Tunnel dürfen Sie es behalten, denn die Strecke ist bereits durch SSH geschützt und TLS läuft nur noch innerhalb des Tunnels. In der Proxy-Variante gehört das echte Zertifikat auf nginx, während Webmin sein eigenes intern weiterbenutzt, weil proxy_pass nur bis 127.0.0.1 reicht und diese Strecke den Server nicht verlässt. Ein öffentlich erreichbares Webmin mit selbst signiertem Zertifikat ist der Fall, den Sie vermeiden wollen, weil die Dauerwarnung im Browser echte Warnungen unsichtbar macht.

Warum brauche ich Firewall und allow in miniserv.conf gleichzeitig?

Weil sie an verschiedenen Stellen greifen und verschieden scheitern. Die Firewall verwirft Pakete, bevor Webmin sie sieht, sie schützt also auch, wenn der Dienst falsch konfiguriert neu startet. Die allow-Liste wirkt erst in miniserv.pl, dafür bleibt sie bestehen, wenn jemand eine Firewallregel löscht oder ein Dienst wie Docker eigene Regeln davor setzt. Hinter einem Reverse Proxy ist zusätzlich zu beachten, dass allow nur noch 127.0.0.1 sieht, der Herkunftsfilter gehört dort in die nginx-Konfiguration.