Dateiberechtigungen für von openssl erstellte Dateien für den https-Webserver (lighttpd)

572
ikwyl6

Ich habe die folgenden Dateien für meinen lighttpd-Webserver für https-Verbindungen erstellt:

$ ls -al /etc/lighttpd/ssl drwxr-xr-x 2 root root 4096 Oct 21 12:51 . drwxr-xr-x 4 root root 4096 Oct 20 16:04 .. -rw-r--r-- 1 http http 1663 Oct 20 15:49 server.crt -rw-r--r-- 1 root root 1062 Oct 20 15:48 server.csr -rw------- 1 root root 1704 Oct 20 15:48 server.key -rw-r----- 1 alarm http 3367 Oct 20 16:02 server.pem -rw------- 1 root root 1751 Oct 20 15:48 rootCA.key -rw-r--r-- 1 root root 1330 Oct 20 15:48 rootCA.pem -rw-r--r-- 1 root root 41 Oct 20 15:49 rootCA.srl

Wo server.*sind meine offensichtlichen Webserver-Dateien und rootCA.*Dateien sind meine Zertifizierungsstellen-Dateien (CA-Dateien), mit denen ich mein selbstsignierendes Zertifikat erstellt habe ( https://alexanderzeitler.com/articles/Fixing-Chrome-missing_subjectAltName-selfsigned-cert-openssl/ ). Damit lighttpd mein Zertifikat (CRT) verwenden kann, musste ich meine PEM-formatierte Datei erstellen.

sudo cat server.crt server.key > server.pemeine PEM-formatierte Datei erstellen. Ich habe meine rootCA.pem-Datei in Chrome installiert (also würde sie die Zertifizierungsstelle erkennen und sich nicht darüber beklagen, dass die Website "nicht sicher" ist).

Also meine fragen sind

  1. Sind meine Dateiberechtigungen aus Sicherheitsgründen in Ordnung oder sollte ich Besitzer- / Gruppen- und Dateiberechtigungen in etwas anderes ändern?
  2. Was ist mit den Verzeichnisberechtigungen / etc / lighttpd / ssl?
  3. Wenn ich den sudo cat server.crt server.key > server.pemBefehl oben durch Hinzufügen von my server.keyzur Pem-Datei ausführen musste, macht dies meinen privaten Schlüssel nicht sichtbar, indem er diese server.pemDatei durch http lesbar macht?

Mein server.pem muss von meinem lighttpd-Server lesbar sein, da der Benutzer, der lighttpd ausführt, 'http' ist.

0

2 Antworten auf die Frage

0
Michael Wojcik

Dies hat möglicherweise noch keine Antworten erhalten, da dies ein schwieriges Problem ist und es keine richtige Antwort gibt.

Der Schlüsselzugriff für Server beruht auf einem Kompromiss zwischen beaufsichtigtem und unbeaufsichtigtem Start. Sie können eine Interaktion mit einem Administrator anfordern (z. B. die private Schlüsseldatei verschlüsseln und die Passphrase beim Start manuell eingeben). Dies schützt den Schlüssel im Ruhezustand (auf der Festplatte) vor der Belichtung, verhindert jedoch den unbeaufsichtigten Start. Oder Sie können den Key-at-Rest für den Server verfügbar machen, so dass ein unbeaufsichtigter Startvorgang möglich ist, der Angreifer jedoch möglicherweise ausgesetzt wird.

Daher muss die Hygiene des Schlüssels in Ruhe Ihrem Bedrohungsmodell entsprechen. Lohnt sich der Aufwand (Zeit, Unannehmlichkeiten, Verzögerung beim Start), Interaktion zu verlangen? Oder ist das Risiko der Offenlegung von Schlüsseln (die Wahrscheinlichkeit, dass es für Sie zeitlich teuer ist) so gering, dass Sie einen unbeaufsichtigten Start erlauben können?

Angenommen, Sie halten den privaten Schlüssel des Servers weiterhin für den unbeaufsichtigten Start bereit (dh, er kann vom Server ohne Administratorinteraktion gelesen werden), hier einige Überlegungen:

  1. Holen Sie sich den Stammschlüssel dort ab. CA-Schlüssel sollten nicht auf Systemen aufbewahrt werden, die der Außenwelt ausgesetzt sind. In diesem Fall ist es Ihre eigene Zertifizierungsstelle, keine große öffentliche, aber dies ist grundlegende PKIX-Schlüsselhygiene.

  2. Es gibt wahrscheinlich keine zusätzlichen Informationen, wenn der Serverschlüssel in zwei Formen vorliegt, aber es bietet auch keinen Vorteil. Server.key loswerden.

  3. Das Verzeichnis könnte auch im Besitz von root.http sein und auf 750 gesetzt sein (root-fähig, http-Gruppenlesbar, keine Weltberechtigungen). Die wahrscheinlichsten Angriffsvektoren laufen über den HTTP-Server, aber es gibt noch andere. könnte auch einige von ihnen entmutigen, indem sie das Lesen / Durchqueren der Welt blockieren.

Zu Ihrer letzten Frage: Ich habe lighttpd noch nie verwendet, aber einige Server unterstützen einen Keying-Prozess, bei dem der Server den Schlüssel beim Start liest und die Berechtigungen so löscht, dass er ihn später nicht lesen kann. Zum Beispiel kann der Server als root gestartet werden (wie es unter UNIX / Linux erforderlich ist, wenn er an die Ports 80 und 443 binden möchte), liest dann die Schlüsseldatei und führt dann eine setuid für http (oder was auch immer) durch. Andere haben möglicherweise die Möglichkeit, den Schlüssel aus einer Pipe oder ähnlichem zu lesen.

Mit lighttpd kann es auch möglich sein, den Schlüssel von einer temporären Kopie zu lesen, die der Startvorgang nach dem Start des Servers löscht.

Die erste Verteidigungslinie besteht jedoch darin, sicherzustellen, dass auf das Verzeichnis, das die Schlüsseldatei enthält, nicht über eine der Webroots zugegriffen werden kann, und dass Sie das Beste tun, um Schwachstellen in Bezug auf Pfaddurchquerungen in dem Server zu vermeiden. Und das Betriebssystem generell sperren.

Ich mag Ivan Ristićs Bulletproof-SSL- und TLS- Buch, das auf feistyduck.com erhältlich ist, um Rat bei der Verwendung von SSL / TLS im Allgemeinen und mit HTTPS im Besonderen zu erhalten. Für Webserver spricht er hauptsächlich über Apache, aber ein Großteil des Materials ist allgemein anwendbar.

Ich hoffe das ist hilfreich.

0
Nobody

root: root, chmod 400. Idealerweise sollten Ihre Root-CA-Dateien nicht auf Ihrem Webserver gehostet werden. Andernfalls gefährden Server-Kompromisse auch Ihre Root-Berechtigung.

https://redmine.lighttpd.net/projects/1/wiki/docs_ssl Berechtigungen Achten Sie darauf, dass Ihre .pem-Datei privat bleibt! Lighttpd liest alle Pem-Dateien beim Start, bevor die Berechtigungen gelöscht werden. Es ist daher am besten, die PEM-Datei im Besitz von root zu machen, die nur von root lesbar ist: $ chown root: root /etc/lighttpd/ssl/example.org.pem $ chmod 400 /etc/lighttpd/ssl/example.org.pem

Verwandte Probleme