BackWPup og 403 access denied

I forbindelse med noget troubleshooting på en af vores servere hvor en kunde havde problemer med at tage backups via WordPress plugins installerede vi BackWPup på et testsite. Vi lavede et nyt backup job, startede det - og vupti, så havde vi ikke længere adgang til hjemmesiden. Alle forsøg på at åbne websitet i browseren gav en 403 access denied fejl.

Vores første tanke var at et eller andet i BackWPup fik vores web application firewall til at gribe ind, men nej, ingenting i logfilerne. Vores .htaccess i roden af public_html mappen var der heller ikke noget i vejen med. Næste skridt var at gendanne vores testsite fra backup, men lige meget hjalp det - vi fik stadig 403 når vi prøvede at åbne det i browseren. Og så gik der en prås op for os:

En typisk måde at organisere filerne på en webserver er at give hver bruger en mappe som bruges til diverse filer som ikke skal være tilgængelige på nettet. Inde i denne mappe ligge der så en anden mappe som indeholder alle de filer som skal kunne åbnes udefra (html, php, stylesheets, billeder - og alt det andet som et website består af). På vores servere ser strukturen således ud:

/home/user/             - private filer
/home/user/public_html/ - filer som hører til hjemmesiden

Normalt er det mest hensigtsmæssigt at backups gemmes offsite. Den gratis version af BackWPup kan f.eks. sende backups til Dropbox og Amazon S3, men til vores test var det tilstrækkeligt at gemme backupfilerne lokalt på serveren.

Det er ikke en god ide at gemme backups i en mappe på serveren hvor de kan tilgås udefra - hvis en hacker får adgang til dem, står websitet pivåbent. BackWPup foreslog mappen /home/user/publichtml/wp-content/uploads/backwpup-abdf99-backups/ men vi foretrak at gemme dem udenfor /home/user/publichtml. Normalt ville vi lave en mappe til formålet, f.eks. /home/user/BackWPup-backups/, men til testformål var det OK at lægge dem i /home/user/. Quick & dirty for at spare lidt tid.

Udviklerne bag BackWPup ved selvfølgelig godt at det er problematisk at lægge backup-filerne offentligt tilgængeligt. For at minimere risikoen indsætter de derfor automatisk en .htaccess fil i backup-mappen med følgende indhold:

<Files "*">
<IfModule mod_access.c>
Deny from all
</IfModule>
<IfModule !mod_access_compat>
<IfModule mod_authz_host.c>
Deny from all
</IfModule>
</IfModule>
<IfModule mod_access_compat>
Deny from all
</IfModule>
</Files>

Her benytter de sig af en Apache feature til at forhindre download af alle filer i mappen hvor .htaccess-filen er oprettet. Dvs. hvis nogen gætter sig til navnet på backupfilen og forsøger at downloade den via browseren, så får de en "403 Access Denied"-fejl.

Desværre virker denne type restriktioner også i alle undermapperne til mappen hvor .htaccess-filen er oprettet. I vores tilfælde lagde BackWPup den sammen med backupfilerne i /home/user/ - dvs. ingen adgang til noget som helst i /home/user/public_html/. Ikke så godt.

Udviklerne har tydeligvis ikke tænkt på at man kunne finde på at gøre som vi gjorde - den slags specielle tilfælde overser man nogle gange. Det er imidlertid ikke særligt heldigt at standardindstillingen er at gemme backups i wp-content mappen - eller en hvilken som helst anden offentlig tilgængelig mappe på serveren. "Deny from all" i en .htaccess fil er ikke en sikker måde at forhindre adgang udefra til backupfilerne (systemadministratoren kan have valgt at konfigurere serveren så direktiver af denne type ignoreres, og visse webservere bruger slet ikke .htaccess filer).

Det er ikke så svært at regne ud hvorfor udviklerne af BackWPup har valgt at gøre som de gør - det er umiddelbart den mest brugervenlige løsning fordi man blot kan installere plugin'et uden at bekymre sig om mapper på serveren. I dette tilfælde er det imidlertid et valg som har nogle betydelige sikkerhedsmæssige implikationer - ikke noget man umiddelbart forventer at få med i købet når man vælger en backupløsning til sit website.