Kort sagt: Den, der vil hærde sin server til PHP, sørger for, at en enkelt sårbarhed ikke åbner hele serveren. Vi adskiller websites fra hinanden, sætter PHP og webserver sikkert op, begrænser rettigheder og adgange og dokumenterer hver ændring. Så bliver skaden mindre, hvis der alligevel sker noget.
Hvorfor hærdning er blevet vigtigere efter PHP2Shell
PHP2Shell har vist, hvor hurtigt en sårbarhed i selve PHP bliver et problem for alle websites på en server. Med CVE-2026-109618 og CVE-2026-109619 kan angribere køre kode uden login. Rettelsen lukker denne dør. Hærdning besvarer et andet spørgsmål: Hvad kan nogen gøre, som alligevel kommer ind, via denne eller den næste sårbarhed?
På en uhærdet server kører alle websites ofte under samme bruger, PHP må udføre systemkommandoer, og adgangsdata ligger læsbare for alle processer. Et indbrud i en lille sideside rækker så helt til webshoppen. En god hærdning adskiller disse områder. Den er ikke en engangshandling, men en grundtilstand, som skal bevares ved hvert nyt website og hvert versionsskifte.
Hærd server til PHP: hvad vi konkret tilpasser
Isolation pr. website
Hvert website får sin egen systembruger og sin egen PHP-FPM-pool. Med open_basedir og passende filrettigheder ser en applikation kun sin egen mappe. Mere herom under open_basedir og isolation pr. website.
Sikker PHP-konfiguration
Vi sætter php.ini og poolkonfigurationen, så applikationer ikke selv kan overskrive sikkerhedsrelevante værdier. Et uddrag af, hvordan det kan se ud i en FPM-pool:
; Værdier fastlåses i FPM-poolen og kan ikke ændres med ini_set()
php_admin_flag[expose_php] = off
php_admin_flag[display_errors] = off
php_admin_flag[log_errors] = on
php_admin_value[open_basedir] = /var/www/kunde1/:/tmp/
php_admin_flag[session.upload_progress.enabled] = off
php_admin_flag[allow_url_include] = off
Hvilke funktioner der derudover kan spærres, afhænger af applikationen. Henvisninger står under Konfigurér php.ini sikkert og Brug disable_functions korrekt.
Filrettigheder og skriveadgang
Webserveren må kun skrive, hvor det er nødvendigt, f.eks. i upload-mappen. I upload-mapper forhindres udførelse af PHP. Programkoden tilhører en anden bruger end den, PHP kører under. Principperne forklarer Filrettigheder på webserveren.
Adgange, tjenester og logs
SSH kun med nøgle, administrationsflader med totrinslogin, ikke-nødvendige tjenester og porte lukket. Logs opbevares og sikres, så de stadig findes efter en hændelse. Backups kontrollerer vi for, om de kan genoprettes.
Webserver og sikkerhedsheadere
Også selve webserveren hører med til hærdningen: skjul versionsoplysninger, slå mappelister fra, spær adgangen til konfigurations-, backup- og versionsstyringsfiler, og sikr administrationsområder yderligere, f.eks. med IP-frigivelse. Sikkerhedsheadere som Content-Security-Policy eller HSTS beskytter jeres websites besøgende i browseren.
Hvad vi ofte finder ved opgørelsen
Mange svagheder gentager sig fra server til server. Typisk er flere websites under en fælles bruger, offentligt tilgængelige databasegrænseflader, gamle testinstallationer i undermapper, glemte PHP-versioner ved siden af den aktuelle og backups, der ligger i webmappen og kan downloades. Ofte mangler der desuden enhver logning af logins, eller logs slettes efter få dage.
Ingen af disse punkter er i sig selv opsigtsvækkende. Men sammen afgør de, om et indbrud forbliver begrænset til ét website eller rammer hele serveren.
Hvordan hjælper PHP SOS konkret?
- Opgørelse: Vi registrerer operativsystem, webserver, PHP-versioner, websites, brugere, åbne tjenester og eksisterende sikkerhedskopier.
- Handlingsplan: I får en prioriteret liste med omfang og mulige konsekvenser pr. punkt. I beslutter, hvad der gennemføres.
- Gennemførelse i trin: Vi ændrer konfigurationer efter aftale, tester websites efter hvert trin og noterer, hvordan hver ændring kan føres tilbage.
- Kontrol: Efter gennemførelsen kontrollerer vi virkningen, f.eks. om et website virkelig ikke længere kan læse fremmede mapper.
- Overdragelse: I får en dokumentation af den nye tilstand, som også jeres hostingudbyder eller bureau kan følge.
Hvad I får, og hvad vi har brug for
I får en hærdningsrapport med udgangssituation, gennemførte foranstaltninger, bevidst åbent lade punkter med begrundelse og en anbefaling til den regelmæssige kontrol. Ændringer i konfigurationsfiler er dokumenteret, så de kan følges.
Fra jer har vi brug for:
- root- eller administratoradgang til serveren, ved paneler desuden panel-adgangen
- en liste over applikationerne og deres særlige forhold, f.eks. uploads, grænseflader, cronjobs
- en teknisk kontaktperson, som kan bekræfte funktioner efter ændringer
- vedligeholdelsesvinduer til genstarter
- en aktuel backup eller opgaven at oprette en inden da
Hvad vi ikke lover
Hærdning gør ikke en server uangribelig. Den reducerer angrebsfladen og begrænser skader, men erstatter hverken opdateringer eller overvågning. En upatchet PHP-version forbliver sårbar, uanset hvor godt resten er indstillet. Derfor kombinerer vi hærdningen med PHP-patch-servicen og anbefaler bagefter en løbende betjening via en sikkerhedsvedligeholdelsesaftale.
Ved shared hosting kan meget ikke indstilles, fordi hostingudbyderen fastlægger konfigurationen. Så viser vi, hvad der er muligt inden for jeres pakke, og hvor et skifte til en egen eller administreret server vil være fornuftigt.
Ofte stillede spørgsmål
Hvad vil det sige at hærde en server?
At hærde betyder at slå alt fra eller begrænse alt, som ikke er nødvendigt for driften. Det gælder overflødige tjenester, for vide rettigheder, åbne porte og usikre standardindstillinger. Målet er, at en enkelt fejl ikke straks åbner hele serveren.
Ville hærdning have forhindret PHP2Shell?
Nej, mod en sårbarhed i selve PHP hjælper kun rettelsen. Hærdning begrænser til gengæld, hvad en angriber kan nå efter et vellykket indbrud, f.eks. om vedkommende kan få adgang til andre websites eller adgangsdata.
Ødelægger hærdningen mit website?
Risikoen består, hvis indstillinger ændres uden test. Vi gennemfører ændringerne trin for trin, kontrollerer funktionerne efter hvert trin og noterer, hvordan hver ændring kan føres tilbage.
Hvor ofte bør hærdningen gennemgås?
Senest efter større opdateringer, et skifte af PHP-version eller nye applikationer på serveren. Det er fornuftigt med en regelmæssig kontrol som led i den løbende vedligeholdelse.