Akeeba-Backup: Kein Backupverzeichnis außerhalb des Dokumenten-Root-Verzeichnisses nutbar

crazy-to-bike

Hallo,

ich bin mit meinen Joomla-Webseiten zu Netcup umgezogen. Beim alten Hoster hatte ich das Backupverzeichnis für die Akeeba Backups eine Verzeichnisebene höher als das Joomla-Dokumentenroot angegeben. Das geht bei Netcup (bslang) nicht. Ich komme, egal ob ich den absoluten Pfad manuell eingebe, oder den Directory Browser hinter dem Eingabfeld nutze, nicht in eine höhere Verzeichnisebene als das root-Verzeichnis von Joomla.

Wenn ich im Directory Browser "Up one level" klicke, kommt "The specified directory doesn't exist!". Wenn ich den Pfad manuell eintrage und ein Backup starte "The automatic backup can not be started because your output directory is not writable".

Die Backups innerhalb der Joomla Installation anzulegen, ist ja aber aus mehreren Gründen käse:

sind die Backups bei einer Kompromittierung von Joomla ebenfalls betroffen
wächst die Backupgröße exponentiell, da ja mit dem Dateibackup immer auch die vorhandenen Backups ins Backup gepackt werden

(Wie) kann ich erreichen, dass ich wieder ein Backupverzeichnis oberhalb des Dokumentenroot von Joomla angeben kann?

crazy-to-bike

Ok, mal getestet: Das Backupverzeichnis wird beim Backup ausgeschlossen. Das ist schon mal gut. Sinnvoll ist das Backupverzeichnis innerhalb des Joomla-Verzeichnisses aber definitiv nicht.

Rolf Dautrich

Hast Du Dein Joomla direkt im Hauptverzeichnis (Root-Verzeichnis, meist /www) installiert? Dann hast Du schlechte Karten.

ch erstelle mir immer für jede Joomla-Instanz ein Unterverzeichnis unter dem Root. Das bringt mehrere Vorteile:

Ich kann mir als ein Joomla in einem Webspace installieren.
Ich kann neben meinen Joomla-Verzeichnissen (also auf gleicher Höhe, unter dem Root-Verzeichnis) z.B. ein Verzeichnis "AkeebaBackup" einrichten, in das ich alle Backups schreibe (und von dort per FTP auf meine lokale Architektur hole).
Das würde Dein Problem lösen.
Ich kann weitere Verzeichnisse für besondere Anforderungen hier unterbringen oder sogar eine andere Webanwendung, z.B. eine kleine Nextcloud.

crazy-to-bike

Auf der obersen Verzeichnisebene, die ich auf dem Webspace erreichen kann (auf die serverseitige root-Verzeichnisebene kommt man ja nicht), habe ich - wie beim alten Hoster schon - eiinen Ordner www erstelt, darin Unterordner für mehrere verschiedene Installationen. Also

[nicht erreichbare Verzeichnisebenen]/www/joomla1
[nicht erreichbare Verzeichnisebenen]/www/joomla2
[nicht erreichbare Verzeichnisebenen]/www/wasauchimmer

Ich kann in Akeeba Backup keinen Pfad über Joomla1 bzw. Joomla2 angeben. Beim alten Hoster ging das problemlos.

SniperSister

Zitat von crazy-to-bike

sind die Backups bei einer Kompromittierung von Joomla ebenfalls betroffen

Das gleiche Problem hast du auch bei einer Platzierung des Backups außerhalb des Webroots: wenn Akeeba drauf zugreifen kann, kann's ein Angreifer der Joomla und somit Akeeba kontrolliert, auch.

crazy-to-bike

Zitat von SniperSister

Das gleiche Problem hast du auch bei einer Platzierung des Backups außerhalb des Webroots: wenn Akeeba drauf zugreifen kann, kann's ein Angreifer der Joomla und somit Akeeba kontrolliert, auch.

Stimmt. Wenn man darüber nachdenkt, ist das logisch.
Aber warum wird dann immer empfohlen, das Backupverzeichnis außerhalb des Joomla-Web-Root zu legen?

Am Besten also die Backups durch einen Cronjob mit cp wegkopieren und von Zeit zu Zeit alte Backups löschen. rsync würde das zwar mit der Löschung der alten Backups durch Akeeba "automatisieren", aber im Falle des Falles das Zielverzeichnis leer syncen.

ahotzler

Wenns in der Web-Root liegt, kann es theoretisch jeder herunterladen, der den genauen Pfad und den Dateinamen weiß, außer der Zugriff ist z.B. über .htaccess o.ä. geschützt, daher kann man es als "worst practise" bezeichnen, schützenswerte Daten, die man nicht zum Download bereitstellt, innerhalb der Web-Root zu speichern.

Nun haben wir also diese "Best Practise"-Überlegung: "Nicht in die Web-Root" - diese kann dann halt mit Einschränkungen im Webspace kollidieren. Neben fehlenden Schreibrechten gibts auch Einschränkungen durch PHP-Settings, die hier beschränkend wirken können.

Du hast halt immer das Problem: Wenn ein Angreifer einen Zustand erlangt, in dem er im Kontext der Webseite und damit beispielsweise des Akeeba Backups agieren kann, dann kann er auch die Backups lesen.

Und dass Du über Rsync nachdenkst zeigt ja, dass Du schon erweiterte Kenntnisse hast bzw. Dir sowas zutraust. Da würde ich an Deine Stelle lieber die Zeit darin investieren, ein Backup auf Webspace-Ebene zu etablieren, sofern Deine Webhosting-Umgebung dies zulässt.

Dann hat man eine gescheite Lösung und kann sich das irre Gefrickele sparen.

Sieger66

Standardmässig wird bei Akeeba-Backup diesbezüglich ein Dateiordner dort

administrator/components/com_akeebabackup/backup

verwendet welcher per .htaccess und web.config in diesem Dateiordner vor dem Zugriff von "außen" geschützt ist. Siehe auch:

https://www.akeeba.com/documentation/…figuration.html

Inhalt dieser .htaccess ist:

Code

<IfModule !mod_authz_core.c>
Order deny,allow
Deny from all
</IfModule>
<IfModule mod_authz_core.c>
  <RequireAll>
    Require all denied
  </RequireAll>
</IfModule>

Inhalt von web.config für Microsoft Internet Information Services (IIS) web server, version 7 or later im Spoiler:

Spoiler anzeigen

Code

  <?xml version="1.0" ?> 
- <!-- 
This file was generated automatically by the Akeeba Backup Engine
DO NOT REMOVE THIS FILE
This file makes sure that your backup output directory is not directly accessible from the web if you are using the
Microsoft Internet Information Services (IIS) web server, version 7 or later. This prevents unauthorized access to your
backup archive files and backup log files. Removing this file could have security implications for your site.
As noted above, this only works on IIS 7 or later.
See https://www.iis.net/configreference/system.webserver/security/requestfiltering/fileextensions
You are strongly advised to never delete or modify any of the files automatically created in this folder by the
Akeeba Backup Engine, namely:
* .htaccess
* web.config
* index.html
* index.htm
* index.php
  --> 
- <configuration>
- <system.webServer>
- <security>
- <requestFiltering>
- <fileExtensions allowUnlisted="false">
  <clear /> 
  <add fileExtension=".html" allowed="true" /> 
  </fileExtensions>
  </requestFiltering>
  </security>
  </system.webServer>
  </configuration>

Alles anzeigen

ahotzler

Zitat von Sieger66

verwendet welcher per .htaccess und web.config in diesem Dateiordner vor dem Zugriff von "außen" geschützt ist.

Das stimmt, aber so wie Du es schreibst "geschützt sind", wirkt das so, dass das immer so ist, aber damit beispielsweise eine .htaccess überhaupt geladen wird, müssen bestimmte Bedingungen erfüllt sein. Ein weiterer Fallstrick sind deaktivierte Apache-Module für diese Direktive.

Wenn beispielsweise beim Apache: "AllowOverride AuthConfig" (in AllowOverride ALL enthalten) nicht gesetzt ist oder im Vhost andere Direktiven stehen, ist das Ganze ungültig.

Daher macht es Sinn, das Ganze mal zu prüfen. Aber wir sind schon wieder am Herumfrickeln und Basteln

Sieger66

Kann er ja leicht prüfen. Wohl am besten und einfachsten wenn er im Backend angemeldet ist per aufruf von

administrator/components/com_akeebabackup/backup/index.html

Da sollte dann sowas auftauchen wie:

Zitat

Forbidden
You don't have permission to access this resource.

flotte

Zitat von crazy-to-bike

...Aber warum wird dann immer empfohlen, das Backupverzeichnis außerhalb des Joomla-Web-Root zu legen?...

Ob das immer überall empfohlen wird denke ich mal nicht. Netcup würde es sicher nicht empfehlen

Wir empfehlen das beispielsweise und wir haben auch ein spezielles Systemverzeichnis für Backups. Auch ist es so, das wir automatisch je Domain ein eigenes Webroot einstellen und damit sicherstellen, das es keine verschachtelten Scriptinstallationen gibt, sondern die Installationen parallel liegen. Dann kann man auch sauber sichern/rücksichern.

Einer der weiteren Gründe warum wir die Backups außerhalb des Webroots empfehlen ist, damit das Joomla/Wordpress etc.pp schlank bleibt. Dann lässt es sich in wenigen Sekunden mit unserer internen Backup/Restore-Funktion sichern/wiederherstellen und muss keine tonnenweise Backupdaten auch noch mal sichern/wiederherstellen.

Sieger66

Außerdem sind die Backups auch dann, wenn ein Laie z.B. die

administrator/components/com_akeebabackup/backup/.htaccess

aus Unwissenheit löscht oder umbennent und auch keine diesbezüglich wirksame entsprechende .htaccess in administrator/ nutzt,

vor dem Zugriff von "außen" geschützt wenn das Backupverzeichnis außerhalb des öffentlich zugänglichen Dateiverzeichnispfades liegt. Selbiges wenn #9 vorliegt...

Auch wenn ein Laie die kickstart.php im Joomla-root liegen läst kann man z.B. einfach den Standard-Dateipfad administrator/components/com_akeebabackup/backup/ in kickstart.php angeben und die aktuelle Website damit gegebenenfalls mit einem altem Backup kaputt machen usw...