Auf welchen Ports lauscht OpenVPN Access Server tatsächlich?

Sie führen ss -lntup auf einem Access-Server-Host aus und erhalten eine Liste, die doppelt so lang ist wie erwartet. Die Hälfte der Einträge sind daemonförmige Ports, die bei der Einrichtung niemand erwähnt hat. Der Reflex ist, alles zu schließen, was nicht 443 oder 1194 ist, und genau so zerstören Leute ihr eigenes Kundenportal.

Access Server ist nicht ein einziger Listener. Es ist ein VPN-Dienst, ein Webdienst und ein Cluster-Teilnehmer, und es kann je nach Anzahl der konfigurierten TCP-Daemons zusätzliche daemonspezifische Ports und Firewall-Weiterleitungen erzeugen.

Gehen Sie das Inventar der Reihe nach durch: Lesen Sie die Sockets, ordnen Sie die bekannten zu, klassifizieren Sie den Rest nach Besitzer und Bindung, und prüfen Sie dann, was sie tatsächlich veröffentlicht.

Beginnen Sie mit einem einzigen Lesebefehl

sudo ss -lntup liefert Ihnen Transport, lokale Adresse, Port und besitzenden Prozess für jeden lauschenden Socket. Die Flags sind wichtig: -l lauschend, -n numerisch, -t TCP, -u UDP, -p Prozess. Ohne root erhalten Sie Sockets, aber keine Prozessnamen, und genau diese Spalte brauchen Sie zur Klassifikation.

Notieren Sie vor jeder Meinungsbildung vier Felder pro Zeile: Protokoll, Bindungsadresse, Port und Befehl. Halten Sie die Access-Server-Version und die konfigurierte Daemon-Anzahl neben dieser Liste fest, denn beides verändert, was zu erwarten ist.

Zwei Zeilen, die identisch aussehen, sind es nicht. TCP und UDP auf derselben Nummer sind getrennte Sockets mit getrennter Exposition, und 0.0.0.0 und :: sind getrennte Bindungen für getrennte Adressfamilien. Ein Dienst, der nur an 127.0.0.1 gebunden ist, ist von einem anderen Host nicht direkt erreichbar, obwohl eine lokale Weiterleitung ihn weiterhin veröffentlichen kann.

Die Listener, die Sie erkennen sollten

Diese Standardwerte decken die meisten Installationen ab und geben Ihnen eine Vergleichsbasis. Sie sind Standardwerte, keine vollständige Zulassungsliste.

Alles darüber hinaus braucht eine Erklärung, keine Annahme. Sie werden oft nur lokal gebundene Listener sehen, die zu Komponenten gehören, die das Produkt für sich selbst installiert. Bestätigen Sie sie über PID und Dienstkonfiguration statt über eine gemerkte Portnummer, und behandeln Sie einen unbekannten Port nicht allein wegen der Unbekanntheit als feindlich.

Ein Socket außerhalb des bekannten Paars ist auch nicht automatisch ein Überbleibsel. Wenn mehrere TCP-Daemons konfiguriert sind, legt Access Server Listener pro Daemon an und leitet Datenverkehr dorthin weiter, sodass Anzahl und Portwerte dieser Konfiguration folgen.

Klassifizieren, bevor Sie etwas schließen

Beantworten Sie für jede unklare Zeile drei Fragen in dieser Reihenfolge.

1. Besitzer und Zweck. Ordnen Sie die PID einer Unit oder einem Prozess zu und lesen Sie die Konfiguration dieses Dienstes. Wenn Sie den Besitzer nicht benennen können, sind Sie nicht bereit, irgendetwas über den Socket zu entscheiden.
2. Bindungsumfang. Loopback ist lokal zum Namensraum. Eine Wildcard-Bindung ist nur erreichbar, wenn Routing, Host-Filterung und etwaige Regeln auf Cloud-Ebene es zulassen, die Bindungsadresse ist also notwendig, aber nicht ausreichend. Prüfen Sie IPv4 und IPv6 als getrennte Entscheidungen.
3. Veröffentlichter Pfad. Suchen Sie nach Dienstweiterleitung, daemonspezifischen Weiterleitungen, einem externen Proxy und der effektiven Firewall-Richtlinie. Das ist der Schritt, den Leute überspringen, und er ist es, der einen harmlos wirkenden Backend-Port in einen erreichbaren administrativen Pfad verwandelt.

Dieselbe Frage liest sich von außerhalb des Hosts anders. Ein Port ohne Host-Firewall-Regel kann dennoch von einer Cloud-Sicherheitsgruppe geschlossen werden, und ein Port mit einer freizügigen Host-Regel kann unerreichbar sein, weil nichts dorthin routet. Betrachten Sie beide Enden, bevor Sie das Fazit des Inventars schreiben.

Wo der veröffentlichte Pfad von der Socket-Liste abweicht

Die eigene Dokumentation von Access Server behandelt den Fall, der die meiste Verwirrung stiftet: Wenn mehrere TCP-Daemons laufen, leitet der Front-Port an daemonspezifische Ports weiter, und das sichtbare Layout passt nicht mehr zur Socket-Liste. Das Tutorial zur Filterung der Weboberfläche beschreibt diese Regeln und warum ein Filter, der nur für den offensichtlichen Port geschrieben wurde, den weitergeleiteten Pfad vollständig verfehlen kann.

Cluster-Steuerung ist der zweite Ort, an dem die Version zählt. Ab 3.0 teilt sie sich 943; ältere Cluster-Konfigurationen nutzten 945. Einen davon zu öffnen oder zu blockieren, ohne die Version zu prüfen, erzeugt ein Inventar, das ordentlich aussieht und falsch ist.

Die von außen sichtbare Oberfläche ist also die Vereinigung dreier Dinge: lauschende Sockets, Weiterleitungsregeln, die sie erneut veröffentlichen, und die Netzwerkkontrollen vor dem Host. Jedes Inventar, das nur das erste erfasst, ist unvollständig, und jede Änderung, die nur das erste betrachtet, lässt entweder einen Pfad offen oder schneidet einen Dienst ab.

Nach jeder Änderung überprüfen

Ändern Sie Listener-Einstellungen über den unterstützten Konfigurationseigentümer und halten Sie dabei eine Wiederherstellungskonsole offen. Der Verlust des administrativen Zugriffs auf eine Weboberfläche auf einem entfernten Host ist über das VPN, das Sie gerade deaktiviert haben, nicht wiederherstellbar.

Validieren Sie dann die vier Dinge, die eine Installation normalerweise braucht: Ein VPN-Client verbindet sich, das Kundenportal lädt, der administrative Zugriff funktioniert und die Cluster-Kommunikation funktioniert weiterhin, wenn Sie mehr als einen Knoten betreiben. Ein reiner VPN-Test besteht bequem, während das Portal defekt ist.

Schließen Sie ab, indem Sie den erlaubten Pfad für jeden Dienst notieren: welcher Socket, welche Bindung, welche Weiterleitungsregel, welche Netzwerkkontrolle. Dieses Dokument ist das nützliche Sicherheitsergebnis. Eine minimale Socket-Anzahl ist es nicht, und ein Massen-Reset, der Listener schließt, die niemand fertig identifiziert hat, ebenso wenig.