Kort sagt: Den som vill härda sin server för PHP ser till att en enskild sårbarhet inte öppnar hela servern. Vi skiljer webbplatser åt, sätter upp PHP och webbserver säkert, begränsar rättigheter och åtkomster och dokumenterar varje ändring. Så blir skadan mindre om något ändå händer.
Varför härdning har blivit viktigare efter PHP2Shell
PHP2Shell har visat hur snabbt en sårbarhet i PHP självt blir ett problem för alla webbplatser på en server. Med CVE-2026-109618 och CVE-2026-109619 kan angripare köra kod utan inloggning. Patchen stänger den dörren. Härdning besvarar en annan fråga: Vad kan någon göra som ändå kommer in, via den här eller nästa sårbarhet?
På en ohärdad server körs ofta alla webbplatser under samma användare, PHP får köra systemkommandon och inloggningsuppgifter ligger läsbara för alla processer. Ett intrång i en liten sidosajt räcker då ända till webbutiken. En bra härdning skiljer dessa områden åt. Den är ingen engångsåtgärd utan ett grundtillstånd som måste bevaras vid varje ny webbplats och varje versionsbyte.
Härda server för PHP: vad vi konkret anpassar
Isolering per webbplats
Varje webbplats får en egen systemanvändare och en egen PHP-FPM-pool. Med open_basedir och lämpliga filrättigheter ser en applikation bara sin egen katalog. Mer om det under open_basedir och isolering per webbplats.
Säker PHP-konfiguration
Vi ställer in php.ini och poolkonfigurationen så att applikationer inte själva kan skriva över säkerhetsrelevanta värden. Ett utdrag av hur det kan se ut i en FPM-pool:
; lägg fast värden i FPM-poolen, kan inte ändras 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
Vilka funktioner som dessutom kan spärras beror på applikationen. Anvisningar finns under Konfigurera php.ini säkert och Använd disable_functions rätt.
Filrättigheter och skrivåtkomst
Webbservern får bara skriva där det behövs, till exempel i uppladdningsmappen. I uppladdningskataloger förhindras körning av PHP. Programkoden tillhör en annan användare än den som PHP körs under. Principerna förklaras i Filrättigheter på webbservern.
Åtkomster, tjänster och protokoll
SSH bara med nyckel, adminytor med tvåfaktorsinloggning, tjänster och portar som inte behövs stängda. Loggar förvaras och säkras så att de finns kvar efter en incident. Säkerhetskopior kontrollerar vi med avseende på återställbarhet.
Webbserver och säkerhetsheaders
Även webbservern själv hör till härdningen: dölja versionsuppgifter, stänga av kataloglistor, spärra åtkomst till konfigurations-, säkerhetskopierings- och versionshanteringsfiler och skydda adminområden ytterligare, till exempel med IP-godkännande. Säkerhetsheaders som Content-Security-Policy eller HSTS skyddar besökarna på er webbplats i webbläsaren.
Vad vi ofta hittar vid inventeringen
Många svagheter upprepar sig från server till server. Typiska är flera webbplatser under en gemensam användare, offentligt nåbara databasgränssnitt, gamla testinstallationer i underkataloger, bortglömda PHP-versioner vid sidan av den aktuella och säkerhetskopior som ligger i webbkatalogen och går att ladda ned. Ofta saknas dessutom all loggning av inloggningar, eller så raderas loggar efter några dagar.
Ingen av dessa punkter är spektakulär i sig. Tillsammans avgör de ändå om ett intrång förblir begränsat till en webbplats eller drabbar hela servern.
Hur hjälper PHP SOS konkret?
- Inventering: Vi kartlägger operativsystem, webbserver, PHP-versioner, webbplatser, användare, öppna tjänster och befintliga säkerhetskopior.
- Åtgärdsplan: Ni får en prioriterad lista med arbetsinsats och möjliga konsekvenser per punkt. Ni beslutar vad som genomförs.
- Genomförande i steg: Vi ändrar konfigurationer efter överenskommelse, testar webbplatserna efter varje steg och dokumenterar hur varje ändring kan backas.
- Kontroll: Efter genomförandet kontrollerar vi effekten, till exempel att en webbplats verkligen inte längre kan läsa främmande kataloger.
- Överlämning: Ni får en dokumentation av det nya läget som även ert webbhotell eller er byrå kan följa.
Vad ni får och vad vi behöver
Ni får en härdningsrapport med utgångsläge, genomförda åtgärder, medvetet öppet lämnade punkter med motivering och en rekommendation för regelbunden kontroll. Ändringar i konfigurationsfiler är spårbart dokumenterade.
Från er behöver vi:
- Root- eller administratörsåtkomst till servern, vid paneler dessutom panelåtkomst
- en lista över applikationerna och deras särdrag, till exempel uppladdningar, gränssnitt, cronjobb
- en teknisk kontaktperson som kan bekräfta funktioner efter ändringar
- Underhållsfönster för omstarter
- en aktuell säkerhetskopia eller uppdraget att skapa en först
Vad vi inte lovar
Härdning gör inte en server oangripbar. Den minskar angreppsytan och begränsar skador men ersätter varken uppdateringar eller övervakning. En opatchad PHP-version förblir sårbar oavsett hur väl resten är inställt. Därför kopplar vi härdningen till PHP-patchtjänsten och rekommenderar därefter löpande bevakning via ett säkerhetsunderhållsavtal.
Vid delat webbhotell går mycket inte att ställa in, eftersom webbhotellet bestämmer konfigurationen. Då visar vi vad som är möjligt inom ramen för ert paket och var ett byte till en egen eller managed server vore meningsfullt.
Vanliga frågor
Vad innebär det att härda en server?
Att härda betyder att stänga av eller begränsa allt som inte behövs för driften. Dit hör överflödiga tjänster, alltför vida rättigheter, öppna portar och osäkra standardinställningar. Målet är att ett enskilt fel inte genast öppnar hela servern.
Hade härdning förhindrat PHP2Shell?
Nej, mot en sårbarhet i PHP självt hjälper bara patchen. Härdning begränsar dock vad en angripare kan nå efter ett lyckat intrång, till exempel om han kan komma åt andra webbplatser eller inloggningsuppgifter.
Går min webbplats sönder av härdningen?
Risken finns om inställningar ändras utan test. Vi genomför ändringarna stegvis, kontrollerar funktionerna efter varje steg och dokumenterar hur varje ändring kan backas.
Hur ofta bör härdningen ses över?
Senast efter större uppdateringar, ett byte av PHP-version eller nya applikationer på servern. Det är meningsfullt med en regelbunden kontroll inom ramen för det löpande underhållet.