Bei Plesk werden die Ports 8443 und 8447 häufig in einem Atemzug genannt. Für mich sind sie aber zwei unterschiedliche Dinge: 8443 gehört zur Panel-Oberfläche, 8447 zum Plesk-Installer und zu Plesk-Updates. Keiner dieser Ports ist der normale Webzugang meiner Website.
Wofür die Ports gedacht sind
Die offizielle Plesk-Dokumentation führt TCP 8443 für die administrative HTTPS-Oberfläche und TCP 8447 für Plesk-Upgrades und den Installer auf. Besucher meiner Website benötigen dagegen HTTP/HTTPS über 80 und 443. Das ist die erste wichtige Trennung: Eine öffentlich erreichbare Website braucht nicht automatisch ein öffentlich erreichbares Panel.
In meiner Konfiguration nutze ich für das Panel eine eigene Zugangs-Domain über HTTPS. Das macht die Bedienung über 443 möglich, ändert aber nicht die interne Funktion der Plesk-Dienste. Ein Dienst kann lokal auf 8443 lauschen, während die vorgeschaltete IONOS-Firewall den Port von außen blockiert oder nur für eine vertrauenswürdige Quelladresse freigibt.
Was beim Schließen beachtet werden muss
8443 würde ich nicht unüberlegt abschalten, wenn die Panel-Oberfläche oder eine Plesk-Migration darüber benötigt wird. Sicherer ist eine kontrollierte Freigabe: nur über die benötigte Quell-IP, nur für die notwendige Zeit und mit einer zweiten administrativen Zugriffsmöglichkeit. Das schützt vor dem klassischen Fehler, sich mit einer Firewall-Änderung selbst aus dem Panel auszusperren.
8447 ist ebenfalls kein Port, über den normale WordPress-Anfragen laufen. Er wird für Installer- und Update-Vorgänge verwendet. Ob er dauerhaft eingehend erreichbar sein muss, hängt daher von der konkreten Plesk-Konfiguration und vom gewählten Updateweg ab. Plesk kann Pakete und Updates auch ausgehend über HTTPS beziehen; die Firewall-Regel sollte sich an der tatsächlich genutzten Funktion orientieren und nicht an einer pauschalen Liste.
Meine praktische Regel
- Webzugriff auf 80/443 für die veröffentlichten Websites offen lassen.
- Panelzugriff über 443 bevorzugen und 8443 nicht weltweit freigeben.
- 8447 nur dann eingehend erlauben, wenn ein konkreter Installer- oder Migrationsablauf ihn benötigt.
- Vor einer Änderung prüfen, ob der Dienst lokal lauscht, welche Firewall-Regeln bei IONOS und Plesk gelten und ob ein Rückweg per SSH vorhanden ist.
- Nach der Änderung von einem externen Netz testen – nicht nur vom Server selbst.
Diese Vorgehensweise ist kein Ersatz für eine individuelle Firewall-Prüfung. Sie verhindert aber, dass ein technischer Verwaltungsport mit einem normalen Website-Port verwechselt wird. Für mich ist das die sinnvollere Sicherheitsfrage als „offen oder geschlossen“: Wer muss von wo und wann auf welchen Dienst zugreifen?
Mein Fazit: 8443 und 8447 sind Verwaltungs- und Updateports, keine Besucherports. Ich lasse sie nicht pauschal weltweit offen, sondern richte die Freigabe nach dem tatsächlichen Plesk-Arbeitsablauf und einer möglichst kleinen vertrauenswürdigen Quelle aus.
Wie ein konkretes Plesk-Sicherheitsupdate ablief, beschreibe ich in meinem Beitrag zu Plesk 18.0.81.4 und der PHP-Sicherheitslücke.
