VNC-Port-Anleitung: Remote-Desktop-Zugriff auf Port 5900

Mit VNC kann ein Betrachter einen entfernten grafischen Desktop über das Netzwerk steuern. Der Viewer stellt eine Verbindung zu einem VNC-Server her, handelt das RFB-Protokoll aus, authentifiziert sich und tauscht dann Bildschirmaktualisierungen, Tastatureingaben, Mauseingaben, Zwischenablagedaten und manchmal auch Dateiübertragungsfunktionen aus, abhängig von der Serverimplementierung.

VNC wird für Linux-Desktops, macOS-Bildschirmfreigabe, eingebettete Systeme, Labormaschinen, Jump-Hosts und Remote-Support verwendet. Verschiedene Implementierungen wie TigerVNC, TightVNC, RealVNC, UltraVNC, x11vnc und noVNC können unterschiedliche Standardeinstellungen und Sicherheitsoptionen verwenden. Überprüfen Sie daher immer den tatsächlichen Listener und die Konfiguration.

Der übliche VNC-Port ist TCP 5900 für die Anzeige :0. Bei der herkömmlichen VNC-Anzeigenotation wird die Anzeigenummer zu 5900 hinzugefügt, was bedeutet, dass :1 zu 5901, :2 zu 5902 usw. zugeordnet wird. Bei einigen Viewern können Benutzer je nach Client-Schnittstelle entweder host:5901 oder host:1 eingeben.

Gehen Sie nicht davon aus, dass jeder VNC-Server der Anzeigekonvention folgt. Viele Server können mit einem benutzerdefinierten TCP-Port, einem umgekehrten Verbindungsmodus, einem Web-Proxy oder einem SSH-Tunnel konfiguriert werden. Verwenden Sie Servereinstellungen, Firewall-Regeln und Listener-Prüfungen, um den tatsächlichen Port zu bestätigen.

VNC, RDP und SSH lösen verschiedene Fernzugriffsprobleme. VNC gibt einen grafischen Desktop frei oder erstellt ihn mithilfe des RFB-Protokolls, normalerweise auf Port 5900. RDP ist Microsoft Remote Desktop und verwendet üblicherweise Port 3389. SSH ist ein sicheres Shell-Protokoll auf Port 22 und wird häufig zum Erstellen von Tunneln für VNC verwendet.

Für Windows-Remotedesktop-Workflows ist RDP normalerweise stärker integriert. Für den plattformübergreifenden grafischen Zugriff ist VNC flexibel. Für eine sichere Verwaltung ist SSH häufig der sicherere äußere Zugriffspfad, insbesondere wenn VNC selbst an localhost gebunden ist und über einen SSH-Tunnel erreicht wird.

Öffnen Sie VNC nur, wenn ein vertrauenswürdiger Benutzer, ein Support-Tool, ein Automatisierungsworkflow, ein Labornetzwerk oder ein privater Verwaltungspfad grafischen Remote-Desktop-Zugriff benötigt. Zu den häufigsten Fällen gehören Remote-Linux-Desktop-Support, Kioskwartung, eingebettete Geräteverwaltung und Zugriff auf private Labore.

Vermeiden Sie es, VNC für das gesamte Internet zu öffnen. Ein öffentlicher VNC-Port kann zu Brute-Force-Versuchen, Angriffen mit schwachen Passwörtern, Desktop-Übernahmeversuchen und der Suche nach älteren Servern führen. Wenn ein Fernzugriff erforderlich ist, platzieren Sie VNC hinter einem VPN, einem SSH-Tunnel, einer Zero-Trust-Zugriffsschicht, einer Bastion oder einer Quell-IP-Zulassungsliste.

Bestätigen Sie zunächst, welcher VNC-Server ausgeführt wird, welche Schnittstelle er überwacht und welchen Anzeige- oder TCP-Port er verwendet. Lassen Sie dann den genauen Port nur von vertrauenswürdigen Quellnetzwerken zu. Für display :0 ist das normalerweise TCP 5900; für display :1 ist es oft TCP 5901.

Leiten Sie auf einem Router den externen Port nur dann an den internen VNC-Host weiter, wenn Sie einen triftigen Grund und eine enge Quellrichtlinie haben. Richten Sie auf Servern die Host-Firewall, die Cloud-Sicherheitsgruppe, die VPN-Richtlinie und die VNC-Server-Bindungsadresse so aus, dass der Dienst nur über den vorgesehenen Pfad erreichbar ist.

Beginnen Sie mit einer externen Portprüfung anhand des öffentlichen Hostnamens oder der IP-Adresse und Port 5900 oder des von Ihnen konfigurierten benutzerdefinierten VNC-Ports. Wenn der Port geöffnet ist, kann ein Remote-Client einen TCP-Listener erreichen. Testen Sie dann mit einem echten VNC-Viewer, um Protokollaushandlung, Authentifizierung, Desktop-Zugriff und Bildschirmaktualisierungen zu bestätigen.

Überprüfen Sie auf dem Server die Listener mit ss, netstat, lsof, PowerShell oder der VNC-Serverstatusseite. Wenn VNC über SSH getunnelt ist, testen Sie zuerst die SSH-Verbindung und bestätigen Sie dann den lokalen weitergeleiteten Port und das Viewer-Ziel.

Wenn der VNC-Port geschlossen ist, ist der Server möglicherweise gestoppt, nur an localhost gebunden, lauscht auf einem anderen Display oder wird von der Host-Firewall blockiert. Wenn bei der Prüfung eine Zeitüberschreitung auftritt, kann es sein, dass ein Router, eine Cloud-Firewall, eine VPN-Richtlinie, ein ISP-Filter oder eine Quell-IP-Einschränkung Pakete verwirft, bevor sie den Host erreichen.

Wenn der Port geöffnet ist, der Viewer aber keine Verbindung herstellen kann, überprüfen Sie die Anzeigenummer, die Protokollversion, die Passwortrichtlinie, die Verschlüsselungsanforderung, die serverseitigen Zugriffsregeln, den Desktop-Sitzungsstatus und ob der VNC-Server Verbindungen vom Viewer-Netzwerk zulässt. Einige Server lehnen Clients ab, wenn keine Desktop-Sitzung verfügbar ist.

Verlassen Sie sich für den Internetzugriff nicht allein auf ein VNC-Passwort. Bevorzugen Sie VPN, SSH-Tunnel, private Netzwerke oder Zero-Trust-Zugriff und binden Sie VNC beim Tunneln an localhost. Verwenden Sie starke, eindeutige Anmeldeinformationen, deaktivieren Sie nicht verwendete Konten und sorgen Sie dafür, dass der VNC-Server gepatcht ist.

Aktivieren Sie die Verschlüsselung, wenn der Server und der Viewer dies unterstützen, beschränken Sie Quell-IPs, überwachen Sie fehlgeschlagene Anmeldungen und prüfen Sie, ob die Zwischenablage, die Dateiübertragung oder der unbeaufsichtigte Zugriff deaktiviert werden sollten. Behandeln Sie VNC als vollständigen Desktop-Zugriff und nicht als einfachen Statusendpunkt.