# Massskanning efter opatchad PHP: så går automatiserade angrepp till

> Automatiserade angrepp mot webbservrar: hur massskanning efter opatchad PHP går till, varför små företag är mål och vad ni kan göra åt det.

Källa: https://phpsos.de/sv/blog/automatisierte-massenscans/  
Aktualitet: 2026-10-25  
Leverantör: PHP SOS, PHP-nödhjälp och serversäkerhet. Omedelbar hjälp via WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20beh%C3%B6ver%20hj%C3%A4lp%20med%20v%C3%A5r%20PHP-server.%20F%C3%B6retag%3A%20%E2%80%A6%20Webbplats%3A%20%E2%80%A6

**Kort sagt:** Automatiserade angrepp mot webbservrar sker i vågor: program söker igenom internet efter nåbara servrar, placerar in dem utifrån yttre kännetecken och prövar kända sårbarheter som PHP2Shell i massor. Företagets storlek spelar därvid ingen roll. Skydd ger en patchad PHP, en liten angreppsyta och en övervakning som snabbt märker lyckade träffar.

## Utgångspunkten: ”Vem skulle intressera sig för vår webbplats?”

Den här frågan hör vi ofta efter PHP2Shell, framför allt från mindre företag. Det ärliga svaret: förmodligen ingen personligen. Men det behövs inte heller vid sårbarheter av det här slaget. Angreppen utförs av program som inte söker efter namn utan efter tillfällen.

BSI (den tyska federala myndigheten för informationssäkerhet) räknade vid PHP2Shell med snabbt och storskaligt utnyttjande. Cloudflare rapporterade om angreppsförsök och om att angripare ändrade sina mönster för att kringgå skyddsregler. Båda sakerna stämmer med det som regelbundet sker vid kritiska sårbarheter i mycket utbredd programvara.

## Hur automatiserade angrepp mot webbservrar går till

Automatiserade kampanjer följer oftast ett liknande mönster. Översikten nedan beskriver faserna allmänt, utan angreppsdetaljer:

| Fas | Vad som händer | Vad som hjälper mot det |
|---|---|---|
| Söka | Program kontrollerar stora adressintervall eller offentliga register som certifikatloggar efter nåbara webbservrar | få publikt nåbara system, inventering av alla adresser |
| Placera in | Svar analyseras: webbserver, PHP-version, CMS, typiska sökvägar | dölja versionsuppgifter, ta bort onödiga filer |
| Pröva | kända sårbarheter testas i massor, ofta utan föregående inplacering | aktuell PHP, omstart, WAF som extra lager |
| Etablera sig | vid lyckat resultat läggs en bakdörr, till exempel en webshell eller ett cronjobb | begränsade skrivrättigheter, ingen PHP-körning i uppladdningsmappar |
| Utnyttja | servern används, till exempel för skräppost, kryptobrytning, vidarebefordran eller datastöld | övervakning av processer, filer och utgående förbindelser |

Viktig är den tredje raden. Många kampanjer gör sig inte ens besväret att först placera in servrar noggrant. De prövar helt enkelt allt som är nåbart. Därför skyddar enbart oansenlighet inte.

### Varför angrepp kommer i vågor

Automatiserade kampanjer körs sällan en gång och sedan aldrig mer. Typiskt är ett mönster i vågor. Den första vågen följer kort efter att en sårbarhet blivit känd, ofta med ännu omogna verktyg. Ytterligare vågor kommer när angripare förbättrar sina verktyg eller anpassar dem till skyddsregler. Cloudflare har vid PHP2Shell observerat just det: ändrade angreppsmönster för att kringgå reglerna.

För er betyder det: en server som klarat den första vågen oskadd är inte varaktigt säker så länge den är opatchad. Och en nyuppsatt server är mål från det ögonblick den är nåbar. Den som till exempel låter utfärda ett nytt TLS-certifikat gör namnet synligt i offentliga certifikatloggar som även skannrar utvärderar. Ett nytt system bör därför kopplas till nätet först när det redan är uppdaterat.

## Varför små företag är lika berörda

För automatiserade angrepp räknas inte värdet av ett enskilt mål utan mängden. En server hos ett litet företag erbjuder beräkningskraft, en domän med gott rykte, en e-postutskickstjänst och ibland kunddata. För angripare är det tillräckligt.

Därtill kommer: mindre företag har ofta ingen egen IT som genast installerar uppdateringar. Deras servrar förblir sårbara längre och hamnar därför oftare i skannrarnas resultatlistor. Den som patchar först faller ut ur de listorna.

En ytterligare punkt är leveranskedjan. Många små webbplatser ligger på servrar hos byråer eller små webbhotell där dussintals kundprojekt körs bredvid varandra. För angripare är en sådan server särskilt lönsam, eftersom en enda träff berör många webbplatser samtidigt. Er risk beror då inte bara på er egen omsorg utan även på er leverantörs.

> **Viktigt:**
> Skanningar i era loggar är normala och inget belägg för ett intrång. Ett lyckat angrepp visar sig genom andra spår: nya filer, främmande processer, okända konton, ovanliga utgående förbindelser.

## Vad ni själva kan kontrollera

En blick i loggarna visar hur starkt er server skannas. Följande kommandon läser bara och ändrar ingenting:

```bash
# De tio adresserna med flest förfrågningar i den aktuella åtkomstloggen
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10

# Förfrågningar som besvarats med "hittades inte", efter frekvens
awk '$9 == 404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# Avslöjar servern sin PHP-version i headern?
curl -sI https://www.example.de/ | grep -i "x-powered-by"
```

Många förfrågningar på sökvägar som inte finns är typiskt skanningsbrus. Mer uppmärksamma bör ni bli om det på sådana förfrågningar plötsligt följer lyckade svar, om filer anropas i uppladdningsmappar som ni inte känner till, eller om webbserveranvändaren startar processer som den annars aldrig startar. Bekräftade kännetecken särskilt för PHP2Shell finns hittills inte, bedömningen bygger därför på sådana beteendeavvikelser. Hur ni analyserar loggar grundligare beskriver guiden [Analysera webbserverloggar](https://phpsos.de/sv/ratgeber/logfiles-auswerten/). Visar den tredje frågan en PHP-version lönar sig inställningen `expose_php = Off`; bakgrunden står under [Dölja versionsuppgifter](https://phpsos.de/sv/blog/expose-php-versionsangaben/).

## Skyddslagren i rätt ordning

1. **Uppdatera PHP och starta om:** Utan det steget förblir alla andra åtgärder lappverk.
2. **Minska angreppsytan:** stänga av oanvända webbplatser, testsystem och gamla mikrosajter eller lägga dem bakom en inloggning.
3. **Regler i kanten:** En Web Application Firewall med underhållet regelverk, till exempel [OWASP Core Rule Set med ModSecurity](https://phpsos.de/sv/blog/modsecurity-owasp-crs/), fångar upp en del av försöken.
4. **Bromsa upprepade försök:** Verktyg som [Fail2ban](https://phpsos.de/sv/blog/fail2ban-fuer-webserver/) spärrar adresser som genererar påfallande många fel. Mot distribuerade skanningar hjälper det bara begränsat.
5. **Övervaka:** Håll koll på processer från webbserveranvändaren, nya PHP-filer och utgående förbindelser så att en lyckad träff inte förblir obemärkt i veckor.

## Hur hjälper PHP SOS konkret?

- **Kartlägga angreppsytan:** Vi tar reda på vilka av era system som är nåbara utifrån och vad de avslöjar om sig själva.
- **Patcha och härda:** Vi uppdaterar PHP, startar om och minskar versionsuppgifter, skrivrättigheter och onödiga tjänster.
- **Regler och spärrar:** Vi ställer in WAF-regler och spärrmekanismer som passar er applikation.
- **Löpande övervakning:** Vi rapporterar påfallande processer, filer och förbindelser innan en träff blir en incident.

Hur det ser ut i fortlöpande drift beskriver [Säkerhetsövervakning för webbservrar](https://phpsos.de/sv/leistungen/security-monitoring/).

## Slutsats

Automatiserade angrepp frågar inte vem som äger en server. De frågar bara om den är sårbar. Det bästa svaret på det är ospektakulärt: patcha snabbt, erbjud lite, se noga efter. Den som gör det skannas fortfarande, men hittas inte längre.


## Vanliga frågor

**Är små företag mål för automatiserade angrepp?**  
Ja. Automatiserade skanningar kontrollerar nåbara servrar utan hänsyn till vem som driver dem. Om det bakom står en koncern eller ett hantverksföretag spelar för programvaran ingen roll. Avgörande är om servern verkar sårbar.

**Hur känner jag igen skanningar i mina loggar?**  
Typiskt är många förfrågningar på sökvägar som inte alls finns på er webbplats, ofta från växlande adresser och med påfallande identifierare. Sådana poster är normala och inget belägg för ett lyckat angrepp, men visar att er server kontrolleras.

**Hjälper det att dölja PHP-versionen?**  
Det gör det något svårare för skannrar att placera in er server riktat och är en rimlig grundinställning. Men det skyddar inte mot angrepp som helt enkelt prövar varje server. Uppdateringen förblir ett krav.

**Kan jag förhindra skanningar helt?**  
Nej. Varje publikt nåbar server skannas regelbundet. Målet är inte att förhindra skanningar utan att se till att de inte hittar något: aktuell programvara, liten angreppsyta och en övervakning som rapporterar avvikelser.

## Källor

- [Cloudflare-bloggen: Cloudflare deploys protections against php2shell vulnerability](https://blog.cloudflare.com/php-vulnerabilities-waf-protection/)
- [PHP-manualen](https://www.php.net/manual/de/)
- [OWASP ModSecurity Core Rule Set](https://coreruleset.org/)
- [BSI: den tyska federala myndigheten för informationssäkerhet](https://www.bsi.bund.de/)