Begrenzen Sie einen VPN-Listener auf die Schnittstellen, die Sie meinen

Ein VPN-Dienst ist von überall erreichbar, wo sein Socket gebunden ist und seine Firewall es zulässt. Das sind zwei getrennte Entscheidungen, und meist trifft man nur eine davon. Den tatsächlichen Listener zu lesen dauert zehn Sekunden und klärt eine Frage, die Raten nicht beantworten kann. Fangen Sie dort an, und ändern Sie dann jeweils eine Kontrolle.

Alles Folgende setzt voraus, dass Sie Befehle auf dem Host mit root oder sudo ausführen können.

Lesen Sie die Sockets, bevor Sie etwas ändern

Unter Linux listet ss -lunp UDP-Listener mit ihrer lokalen Adresse, ihrem Port und Prozess auf, und ss -ltnp tut dasselbe für TCP. Suchen Sie den Port des VPN und lesen Sie die Adressspalte sorgfältig. 0.0.0.0:51820 und [::]:51820 bedeuten jede Schnittstelle, während 10.0.0.5:51820 eine Adresse auf einer Schnittstelle bedeutet. Das ss-Handbuch dokumentiert die Spalten, wenn die Ausgabe ungewohnt ist. Fehlt der Prozessname, führen Sie denselben Befehl mit sudo aus, denn die Eigentümerspalte benötigt Berechtigungen.

Schreiben Sie die Adresse auf. Sie ist die Tatsache, von der der Rest dieses Runbooks abhängt.

Binden Sie an eine Adresse, nicht an einen Wunsch

OpenVPN bindet den Listener mit seiner local-Direktive an eine bestimmte Adresse, und das ist der unterstützte Weg, ihn auf Prozessebene einzugrenzen. Nicht jede Implementierung bietet ein Äquivalent, und ein Protokoll ohne Bindungsoption lässt sich so nicht einengen. Wenn Ihre keine hat, ist die Firewall Ihre einzige Kontrolle, und die Bereitstellungsnotizen sollten das klar sagen. Binden Sie auf einem Host mit mehreren Adressen an diejenige, die zum Tunnel zeigt; an eine schwebende Adresse zu binden ist meist ein Fehler.

Ein Dienst, der einen Adresswechsel überstehen muss, braucht einen Plan für die veraltete Bindung, nicht nur eine Konfigurationszeile.

Prüfen Sie die Adressfamilie getrennt

IPv4 und IPv6 sind getrennte Sockets. Ein an 0.0.0.0 gebundener Prozess kann IPv6 weiterhin über einen Dual-Stack-Socket annehmen oder auch nicht, je nach Socket-Option und Plattformstandard. Nur die IPv4-Zeile zu lesen hat schon mehr als eine Bereitstellungsprüfung getäuscht. Listen Sie beide Familien auf, bevor Sie schließen, dass der Listener eng ist.

Wenn IPv6 nicht Teil des Designs ist, ist es sauberer, es auf Socket-Ebene zu deaktivieren, als zu hoffen, dass die Firewall es abdeckt. Das ist eine Grundsatzentscheidung, also halten Sie sie zusammen mit den übrigen Schnittstellenentscheidungen fest.

Legen Sie die Firewall über die Bindung

Eine enge Bindung ersetzt keine Firewall-Regel, und eine Firewall-Regel verengt keine Wildcard-Bindung. Verwenden Sie beides: Binden Sie, wo die Implementierung es unterstützt, und erlauben Sie den Port dann nur aus den Quellen, die ihn erreichen sollen. Cloud-Sicherheitsgruppen stehen vor der Firewall des Hosts, prüfen Sie also beide, wenn der Pfad eine VPC-Grenze überschreitet. Die wirksame Regel ist die Schnittmenge beider, und jede Schicht kann nur Erreichbarkeit wegnehmen.

Testen Sie von einer erlaubten Quelle und von einer bewusst ausgeschlossenen. Eine Verbindung von localhost beweist nichts über die öffentliche Grenze.

Halten Sie fest, was Sie gewählt haben

Notieren Sie die gebundene Adresse, die Schnittstelle, die sie besitzt, die Firewall-Regel und ihren Zweck. Eine Ersatz-NIC oder eine neu zugewiesene Cloud-Adresse kann die Exposition ändern, ohne dass jemand das Profil bearbeitet. Datieren Sie die Notiz, denn Cloud-Adressen wandern zwischen Prüfungen häufiger, als man erwartet.

Diese Notiz macht die nächste Prüfung zu einem Vergleich statt zu einem Archäologieprojekt.