ubuntuusers.de

Apache: Sicherheitsgewinn durch Daten außerhalb von Document-root

Status: Gelöst | Ubuntu-Version: Server 18.04 (Bionic Beaver)
Antworten |

Rechnungstore

Anmeldungsdatum:
18. Februar 2011

Beiträge: 164

Hallo zusammen,

ich habe mir gerade eine nextcloud aufgesetzt und bin jetzt in der offiziellen Dokumentation auf folgenden Satz gestoßen:

It is highly recommended to place your data directory outside of the Web root (i.e. outside of /var/www). It is easiest to do this on a new installation.

Wo genau liegt der Sicherheitsgewinn? www-data muss doch dann auch an dem Verzeichnis außerhalb des Webroot entsprechende Rechte haben.

Darüber hinaus wird empfohlen, um die Datenbank nicht zu beschädigen, bei einer bestehenden Installation einfach einen symlink von /var/www/html/nextloud/altes_data_direcory auf /irgendein/neuer/pfad/außerhalb/webroot zu setzen. Die Daten sollen natürlich vorher in den neuen Pfad verschoben werden. Auch hier denke ich mir, wenn ein Angreifer irgendwie Zugriff auf den alten Pfad erhält müssten ihm durch den Symlink doch auch die Daten des neuen Pfades zugänglich sein. Also was kann ich hierdurch sicherheitstechnisch gewinnen?

ChickenLipsRfun2eat Team-Icon

Anmeldungsdatum:
6. Dezember 2009

Beiträge: 12067

Hallo!

Ist das in der Dokumentation sicherheitsrelevant markiert, im Sinne von „angreifbar von außen“? Es ist einfacher mit den Upgrades, weil du einfach den alten Ordner löschen kannst, ohne data vorher kopieren/verschieben zu müssen. Ansonsten sehe ich da keinen Sicherheitsgewinn. Und ja, der Webserver braucht mindestens Leserechte, um Dateien anzuzeigen. Für read-only-Sachen nutze ich einen mount --bind oder ein mount mittels sshfs mit PubKey, um die Rechte entsprechend zu setzen.

Rechnungstore

(Themenstarter)

Anmeldungsdatum:
18. Februar 2011

Beiträge: 164

Hallo ChickenLipsRfun2eat.

Soweit ich das sehe, geht es um "angreifbar von außen". Viel steht da nicht zu: https://docs.nextcloud.com/server/latest/admin_manual/installation/harden_server.html#deployment

Ich habe gestern noch etwas recherchiert und einen Kumpel gefragt. Das Problem, welches adressiert wird betrifft wohl hauptsächlich nginx, da dieser keine htaccess interpretiert und Pfade unterhalb vom Webroot somit direkt aufgerufen werden können. Allerdings hilft die symlink-Geschichte dagegen auch nicht. Was das Data-Verzeichnis von der nextcloud betrifft, benötigt www-data sogar Schreibrechte darauf, weil ja dort auch die hochgeladenen Dateien landen.

Naja, ich benutze zwar Apache, habe das Data-Directory aber trotzdem mal aus dem Document-Root verschoben (kein symlink!). Falls jemand das auch machen will/muss, dann geht es wenn mariadb/mysql genutzt wird ungefähr so:

1. Apache stoppen

2. Verzeichnis verschieben

3. Passende Berechtigungen für neues Verzeichnis setzen

4. In der "config.php" den neuen Pfad eintragen

5. In der Nextcloud-Database die Tabelle "oc_storages" suchen und dort den alten Pfad durch den neuen ersetzen.

ChickenLipsRfun2eat Team-Icon

Anmeldungsdatum:
6. Dezember 2009

Beiträge: 12067

Richtig. Die Nutzer brauchen Schreibrechte auf ihren Teil der Cloud, ich binde auch nur sowas wie Hörbücher und eBooks als read only ein. Ich habe die Daten-NC nur lokal, d.h. nicht von außen erreichbar und zudem als Docker-Instanz, da ist ein paralleles Datenverzeichnis sowieso „dabei“, weil einfacher wartbar.

Um Nginx habe ich bislang einen Bogen gemacht, was ich mir aber in dem Zusammenhang vorstellen kann: Ggf. kann man dann per https://meine.cloud/../../../../../../var/www/data/ direkt auf die Dateien zugreifen. Vielleicht lässt sich das unterbinden, wenn der Pfad außerhalb der erlaubten Pfade liegt.

Rechnungstore

(Themenstarter)

Anmeldungsdatum:
18. Februar 2011

Beiträge: 164

Ggf. kann man dann per https://meine.cloud/../../../../../../var/www/data/ direkt auf die Dateien zugreifen. Vielleicht lässt sich das unterbinden, wenn der Pfad außerhalb der erlaubten Pfade liegt.

Genau das scheint wohl der Fall zu sein. Beim Apache beseht diese Gefahr aber eigentlich nicht, weil in den ganzen Pfaden htaccess Dateien liegen, die dann "403" sagen.

Antworten |