Kort sagt: Ved filrettigheder på webserveren gælder et grundprincip: Den bruger, som PHP kører under, må læse sin egen kode, men ikke ændre den. Skriverettigheder får kun upload-, cache- og temp-mapper, og dér udføres ikke PHP. Rettigheder som 777 har intet at gøre på en produktionsserver.
Hvorfor filrettigheder gør forskellen efter et indbrud
Når angribere via en sårbarhed kører kode på en server, kører denne kode med PHP-processens rettigheder. Hvad denne bruger må, må angriberen også. Netop her afgøres det, om et indbrud bliver til en varig bagdør.
Med PHP2Shell er dette scenarie blevet meget konkret i oktober 2026. Sårbarhederne CVE-2026-109618 og CVE-2026-109619 muliggør kørsel af skadelig kode uden login. De er rettet siden 21.10.2026 i PHP 8.5.12, 8.4.27, 8.3.36 og 8.2.35. Gode filrettigheder forhindrer ikke et angreb, men de forhindrer, at indsmuglet kode omskriver jeres applikation varigt.
I mange installationer tilhører al koden webserverens bruger, så opdateringer virker med et tryk på en knap. Det er bekvemt, men netop den konstellation, som angribere leder efter.
Grundprincippet: adskil ejer og kørselsbruger
Fornuftigt er en opdeling i to roller. En ejer, f.eks. en deploy-bruger, ejer filerne og indspiller opdateringer. PHP-processen kører under en anden bruger og har kun læseadgang via gruppen.
| Område | Ejer : gruppe | Rettigheder filer | Rettigheder mapper |
|---|---|---|---|
| Programkode | deploy : seite1 | 640 | 750 |
| Konfiguration med adgangskoder | deploy : seite1 | 640 | – |
| Uploads, cache, temp | seite1 : seite1 | 640 | 750 |
| Logs | root eller seite1 | 640 | 750 |
Selve webserveren, f.eks. Nginx, har ved PHP-FPM kun brug for læseadgang til statiske filer som billeder og CSS. Den får I via gruppen eller en målrettet adgangsregel. Den, der driver flere websites, giver hver en egen kørselsbruger; hvordan det spiller sammen med pools, står i vejledningen open_basedir og isolation pr. website.
Kontrollér filrettigheder på webserveren
Før I ændrer noget, så skab jer et overblik. De følgende kommandoer ændrer intet.
# Under hvilken bruger kører PHP-processerne?
ps -eo user,cmd | grep -E "[p]hp-fpm|[a]pache2|[h]ttpd" | sort | uniq -c
# Filer og mapper, der kan skrives af alle
find /var/www -perm -o+w -ls
# Filer, der tilhører webserverens bruger (eksempel www-data)
find /var/www -user www-data -type f -name "*.php" | head -50
# Konfigurationsfilernes rettigheder
ls -la /var/www/*/wp-config.php /var/www/*/.env 2>/dev/null
Poster, der kan skrives af alle, er næsten altid en fejl. PHP-filer, der tilhører kørselsbrugeren, viser, at denne kan ændre sin kode. Påfaldende er desuden enkelte filer, hvis ejer eller rettigheder afviger fra nabofilerne. Det kan være et tegn på indsmuglede filer, som beskrevet i vejledningen Opdag og fjern webshells.
Ret rettighederne: trin for trin
Ændr kun rettigheder efter en sikkerhedskopi og helst først i et testmiljø. Hvis der er mistanke om et indbrud, så sikr spor først, for ejer og tidsstempler er da bevismidler.
SITE=/var/www/seite1
# Ejer: deploy-bruger, gruppe: kørselsbruger
sudo chown -R deploy:seite1 "$SITE"
# Mapper 750, filer 640
sudo find "$SITE" -type d -exec chmod 750 {} +
sudo find "$SITE" -type f -exec chmod 640 {} +
# Kun disse mapper må PHP skrive i (tilpas stierne til applikationen)
sudo chown -R seite1:seite1 "$SITE/public/uploads" "$SITE/var/cache"
Kontrollér derefter websitet fuldstændigt: forside, login, formularer, billedupload, caches. Hvilke mapper en applikation skal kunne skrive i, står i producentens systemkrav på dennes officielle side.
En chmod -R 777 for hurtigt at løse et problem åbner serveren for enhver lokal bruger og enhver indsmuglet proces. Ret i stedet ejer og gruppe.
Forhindr PHP-kørsel i skrivbare mapper
Skriverettigheder er kun halvt så farlige, hvis der ikke kan køre kode dér. Spær kørsel af PHP i upload- og cachemapper på webserverniveau. For Apache i VirtualHost-konfigurationen:
<Directory "/var/www/seite1/public/uploads">
<FilesMatch "\.(php|phtml|phar)$">
Require all denied
</FilesMatch>
</Directory>
For Nginx er en location-blok nok, der afviser forespørgsler til PHP-filer i disse mapper. Reglen hører hjemme i serverkonfigurationen, ikke i en .htaccess i upload-mappen, som en angriber med skriverettigheder kunne ændre igen.
Som supplement er det værd at se på deploy-brugerens umask, så nye filer ikke automatisk oprettes for åbne. En værdi på 027 giver 640 for filer og 750 for mapper. På egne servere ligger dette ansvar fuldt ud hos jer; hvad der ellers hører til, beskriver Sikr root-server og vServer selv.
Særtilfælde: hostingpaneler, shared hosting og deployments
Ikke enhver server kan sættes op efter lærebogen. Hostingpaneler som Plesk eller cPanel opretter egne brugere og rettigheder og nulstiller dem ved nogle handlinger. Ændr rettigheder dér helst via panelets funktioner, eller kontrollér efter panelopdateringer, om jeres indstillinger stadig gælder.
Ved shared hosting har I som regel kun én bruger til alt. En adskillelse af ejer og kørselsbruger er så ikke mulig. Desto vigtigere er knappe rettigheder på konfigurationsfiler, ingen 777-rettigheder og at slå PHP-kørsel fra i upload-mapper, så vidt hosteren tillader det.
Den, der arbejder med automatiske deployments, bør sætte rettighederne i selve deployment-scriptet. Ellers genskaber hver ny version den gamle, for åbne tilstand. En kort kontrol til sidst i deploymentet, f.eks. med kommandoen for skrivbare filer ovenfor, fanger sådanne tilbageskridt pålideligt og kan bygges ind i enhver pipeline uden større arbejde.
Hvordan hjælper PHP SOS konkret?
- Vi kortlægger ejer, rettigheder og kørselsbruger for alle websites på serveren.
- Vi fastlægger et rettighedskoncept, der passer til jeres applikation og jeres opdateringsvej.
- Vi gennemfører rettigheder og kørselsspærringer og tester websitet fuldstændigt bagefter.
- Vi dokumenterer konceptet, så deployments og opdateringer ikke udvander det igen.
Hvordan det er indlejret i en varig sikring, beskriver ydelsen Serverhærdning til PHP-webservere.
Ofte stillede spørgsmål
Er 777-rettigheder nogensinde i orden?
På en produktionsserver praktisk talt aldrig. Med 777 må enhver bruger i systemet oprette og ændre filer. Hvis en applikation ikke kører uden 777, er ejeren som regel sat forkert, ikke rettighederne for knappe.
Hvorfor må webserveren ikke ændre sine egne filer?
Fordi indsmuglet kode kører med webserverens rettigheder. Må webserveren skrive PHP-filer, kan en angriber manipulere eksisterende scripts eller oprette nye bagdøre. Adskiller man ejer og kørselsbruger, forbliver koden skrivebeskyttet.
Hvordan opdaterer jeg et CMS, når webserveren ikke må skrive?
Opdateringer kører så via ejeren, f.eks. med WP-CLI, Composer eller deployment, ikke via opdateringsknappen i backend. Det er lidt mere omstændeligt, men til gengæld kan indsmuglet kode ikke ændre programfiler.
Hvilke rettigheder skal konfigurationsfilen med databasekodeordet have?
Så få som muligt: læsbar for PHP-brugeren, for ingen andre. Sædvanligt er 640 med passende gruppe eller 400, hvis PHP-brugeren selv er ejer.