Das erste Anzeichen ist meist eine Warnung und kein Ausfall. Ein Client weigert sich, einen Schlüssel zu laden, weil die Datei für die Gruppe oder für alle lesbar ist, oder eine Sicherheitsprüfung findet client.key mit Modus 644 in einem Profilverzeichnis, das auch exportierte Pakete enthält. Noch ist nichts ausgefallen, und genau deshalb wird die Warnung verworfen. Der Schlüssel funktioniert, der Tunnel kommt hoch, und die Datei ist für jedes Konto auf dem Rechner lesbar.

Das Symptom ist eine Berechtigungswarnung, kein Ausfall

Auf einem Unix-ähnlichen System sollte ein privater Schlüssel nur für das Konto lesbar sein, das den Dienst ausführt. Modus 600 mit dem richtigen Eigentümer ist die übliche Regelung. Modus 644 bedeutet, dass jeder lokale Benutzer den Schlüssel kopieren kann, und auf einem gemeinsam genutzten Build-Host ist das ein echtes Publikum.

Clients, die das prüfen, tun Ihnen einen Gefallen. Die es nicht tun, sind kein Beweis dafür, dass die Datei sicher ist, und eine erfolgreiche Verbindung sagt nichts darüber, wer sonst das Material lesen kann, das sie möglich gemacht hat. Behandeln Sie die Warnung als den gesamten Befund. Sie ist zutreffend und kam, bevor jemand die Datei kopiert hat.

Passen Sie den Modus an die Dienstidentität an

Zugriff nur für den Eigentümer passt zu einem Schlüssel, den dieser Eigentümer verwendet. Ein Dienst mit einer bewusst geteilten Gruppe kann eine andere kontrollierte Regelung brauchen, etwa Gruppenlesen auf einem Schlüssel eines Dienstkontos. Jede Datei blind auf einen numerischen Modus zu setzen, bricht unterstützte Clients, und chmod -R 777 ist keine Lösung für irgendetwas.

Prüfen Sie Eigentümer und Dienstkonto, bevor Sie etwas ändern. Öffentliche CA-Zertifikate und private Identitätsschlüssel haben unterschiedliche Geheimhaltungsanforderungen, selbst wenn sie im selben Verzeichnis liegen, daher behandelt ein rekursiver Modus für den ganzen Ordner beide wie dasselbe Objekt.

ls -l /etc/openvpn/client/
stat -c '%U %G %a %n' /etc/openvpn/client/*.key
id openvpn

Nutzen Sie auf anderen Plattformen den dokumentierten Schlüsselspeicher oder das Zugriffskontrollmodell, statt Unix-Modi in eine Vermutung zu übersetzen. Ein Dateiname, der auf private endet, ist eine Bezeichnung, kein Durchsetzungsmechanismus.

Finden Sie die Kopien, die der Modus nicht abdeckt

Editoren, Sicherungsarchive, exportierte Profile und temporäre Pakete können jeweils dieselbe Identität behalten. Schützen Sie diese Kopien nach ihrem Inhalt, denn das Anziehen der Originaldatei bewirkt nichts für die im Tarball des letzten Monats.

Eine Passphrase auf einer Schlüsseldatei ist für gespeichertes Material nützlich und rechtfertigt nicht, die verschlüsselte Datei neben ihrem Passwort zu veröffentlichen. Berechtigungen schützen das aktuelle Dateisystemobjekt; sie sagen nichts über einen bereits anderswo kopierten Berechtigungsnachweis.

Suchen Sie die Kopien, bevor Sie die Aufgabe für erledigt erklären: grep -rl die Kopfzeile des Schlüssels in wahrscheinlichen Verzeichnissen und ein Blick auf Sicherungsausschlüsse. Das Ergebnis ist meist interessanter als die Datei, mit der Sie angefangen haben.

Nach der Korrektur: prüfen und austauschen

Testen Sie, dass der vorgesehene Dienst sich noch authentifiziert, und bestätigen Sie dann, dass kein unnötiges Konto Zugriff erhalten hat. Beschränken Sie die Diagnoseausgabe auf Metadaten, denn das Ausgeben des Schlüssels ist nicht nötig, um zu belegen, dass die Datei lesbar ist und es bringt das Material in ein Protokoll.

Wenn der Schlüssel offengelegt wurde, ziehen Sie den Modus an und ersetzen Sie dann den Berechtigungsnachweis und widerrufen Sie den alten. Die POSIX-chmod-Spezifikation erklärt, was jedes Modusbit bedeutet, was man wissen sollte, bevor die nächste Prüfung Sie bittet, die gewählte Zahl zu begründen.

Ähnliche Artikel