# Varningssignal: webbservern startar ett skal

> PHP-FPM eller Apache startar ett skal? Så läser ni processträdet, skiljer ofarliga fall från intrångsspår och övervakar mönstret varaktigt.

Källa: https://phpsos.de/sv/blog/webserver-startet-shell/  
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:** Om PHP-FPM, Apache eller en annan webbserverprocess startar ett skal som `sh` eller `bash` är det en av de starkaste varningssignalerna för ett intrång via webbplatsen. Kontrollera processträdet, kommandoraden och skalets arbetskatalog innan ni avslutar något. Enstaka korta skal kan vara legitima; långvarigt körande skal med nätverksverktyg är det nästan aldrig.

## Varför det här mönstret säger så mycket

En webbserver besvarar förfrågningar. PHP-FPM, processhanteraren som kör PHP-skript åt webbservern, startar normalt inga ytterligare program för det. Ett skal under webbservern betyder att PHP-kod medvetet har anropat ett program. Antingen gör applikationen det avsiktligt, eller så har någon annan smugglat in kod.

För PHP2Shell finns inga publicerade, bekräftade Indicators of Compromise, alltså ingen lista över fasta kännetecken. Upptäckten bygger på beteende. Enligt de rapporter vi har tillgång till hör webbserver- eller PHP-FPM-processer som startar ett skal till de starkaste allmänna varningssignalerna. Det gäller för varje sårbarhet via vilken angripare kan köra kod på servern. En översikt över fler tecken ger [Är jag redan komprometterad?](https://phpsos.de/sv/php2shell/bin-ich-gehackt-anzeichen/).

Varför är skalet så viktigt för en angripare? Med en sårbarhet kan han till en början bara skicka enstaka kommandon via PHP-processen. Ett skal gör det till en bekväm arbetsplats: han kan se sig omkring, ladda ned verktyg, läsa inloggningsuppgifter ur konfigurationsfiler och installera sig varaktigt. Den som upptäcker skalet upptäcker alltså ofta angriparen i det ögonblick han går från den första åtkomsten till det egentliga syftet.

## PHP-FPM startar bash: läs processträdet

Varje process under Linux har en föräldraprocess. Frågan är om ett skal körs som barn till en webbserverprocess. Kommandona nedan läser bara:

```bash
# Processträd med användare, förälder-PID och starttid
ps -eo user,pid,ppid,lstart,cmd --forest | grep -B2 -A4 -E "[p]hp-fpm|[a]pache2|[h]ttpd|[l]sphp"

# Skal som körs under typiska webbserveranvändare
ps -eo user,pid,ppid,lstart,cmd | grep -E "^(www-data|apache|nginx) " | grep -E "[ /](ba|da)?sh( |$)"

# Träd från den äldsta PHP-FPM-processen
pstree -alp "$(pgrep -o php-fpm)"
```

Har ni hittat ett misstänkt skal ger posterna under `/proc` fler ledtrådar, också bara läsande:

```bash
PID=12345   # PID för det misstänkta skalet
tr '\0' ' ' < /proc/$PID/cmdline; echo        # fullständig kommandorad
ls -l /proc/$PID/cwd /proc/$PID/exe            # arbetskatalog och programfil
ls -l /proc/$PID/fd 2>/dev/null | grep socket  # öppna nätverksanslutningar
```

Processnamn på Debian och Ubuntu är ofta `php8.3-fpm` eller liknande; anpassa sökmönstren. Arbetskataloger i `/tmp`, `/dev/shm` eller i uppladdningsmappar är ett tydligt tecken.

## Legitima undantag och verkliga varningstecken

Vissa applikationer anropar program via PHP. Då kan ett skal kortvarigt uppstå, till exempel när PHP lämnar över e-post via `sendmail_path` eller en applikation bearbetar bilder med ett externt verktyg. Sådana skal lever bara sekunder och anropar alltid samma program. Dokumentera dessa förväntade fall en gång ordentligt; då syns varje avvikelse direkt, i stället för att drunkna i en flod av kända meddelanden.

| Iakttagelse | Snarare ofarligt om | Misstänkt om |
|---|---|---|
| Kort skal under PHP-FPM | det startar ett känt program i applikationen | mål och syfte är oklara |
| Längre körande skal | aldrig | det körs i minuter eller timmar |
| Nätverksverktyg som barnprocess | känd uppdaterings- eller API-förfrågan i applikationen | nedladdningar till temporära kataloger följer |
| Arbetskatalog | applikationens projektmapp | `/tmp`, `/dev/shm`, uppladdningsmappar |
| Tidpunkt | passar till en känd åtgärd, till exempel e-postutskick | på natten, utan användaraktivitet, i klumpar |

Om ni inte vet om er applikation anropar program, fråga utvecklaren eller sök i koden efter funktioner som `exec`, `shell_exec`, `system`, `passthru`, `proc_open` och `popen`. Träffar i den egna koden är normala, träffar i okända filer är det inte.

## Övervaka varaktigt i stället för att titta efter en gång

En ögonblicksbild med `ps` fångar bara skal som körs just då. Kortlivade processer slinker igenom. Mer tillförlitligt är att varaktigt logga programstarter från webbserveranvändaren. Under Linux klarar revisionstjänsten auditd det med en regel för programstarter från webbserveranvändaren. Utvärderingen sker läsande:

```bash
# Visa loggade programstarter under en regelnyckel (nyckeln som exempel)
sudo ausearch -k web_exec --start today -i | grep -E "exe=|proctitle="
```

Hur regeln ser ut beror på distribution och användar-ID; testa den först, eftersom det på hårt belastade servrar uppstår många poster.

Två tillägg gör övervakningen hållbar. För det första bör loggarna dessutom gå till ett centralt system, eftersom en angripare med root-rättigheter kan radera lokala loggar. För det andra behövs larmning: en programstart från webbserveranvändaren som inte finns på en kort lista över förväntade program bör utlösa ett meddelande, inte bara en loggpost. Den som redan använder en lösning för upptäckt på slutenheter eller servrar kan avbilda samma regel där. Förebyggande kan man med `disable_functions` spärra det som applikationen inte behöver. Det stänger ingen sårbarhet i tolken, men försvårar angriparens nästa steg. Detaljer finns under [Använd disable_functions rätt](https://phpsos.de/sv/ratgeber/disable-functions/).

## Vad ni gör om ni hittar ett skal under webbservern

1. **Dokumentera:** Säkra utskriften från `ps`, kommandorad, arbetskatalog och öppna anslutningar i en fil utanför webbkatalogen.
2. **Städa inte:** Radera inga filer och avsluta inga processer innan spåren är säkrade.
3. **Isolera:** Ta servern från nätet eller begränsa åtkomsten kraftigt.
4. **Sök orsaken:** Kontrollera loggar, nya filer och persistens som cronjobb, se [Hitta misstänkta processer på Linux-servrar](https://phpsos.de/sv/blog/verdaechtige-prozesse-linux/).
5. **Byt åtkomster:** Alla lösenord och nycklar som låg på servern räknas som kända.

Körs applikationen i containrar gäller samma princip i det lilla. Ett skal i PHP-containern är lika misstänkt som på en klassisk server, och container-images innehåller det ofta bara för att basimagen levererar det. Säkra containerns tillstånd före omstart, för med containern försvinner också spåren i det flyktiga filsystemet.

Kontrollera dessutom grannskapet. En angripare med skal på en webbserver försöker ofta nå andra system därifrån, till exempel databasen, säkerhetskopieringslagring eller interna administrationsgränssnitt. Inloggningsuppgifter i applikationens konfigurationsfiler gör det lätt för honom.

> **Agera direkt:**
> Ett långvarigt körande skal under PHP-FPM på en server med kunddata är en säkerhetsincident. Behandla det så: säkra, isolera, reda ut strukturerat, låt kontrollera anmälningsskyldigheter.

## Hur hjälper PHP SOS konkret?

- **Placera fyndet:** Vi granskar processträd, kommandorader och anslutningar och skiljer applikationsbeteende från intrångsspår.
- **Säkra spår:** Vi säkrar systemets tillstånd spårbart innan något ändras.
- **Hantera incidenten:** Med [incidenthanteringen (Incident Response)](https://phpsos.de/sv/leistungen/incident-response/) leder vi från begränsning till dokumenterat avslut.
- **Säkra varaktigt:** Vi sätter upp loggning av programstarter och begränsar PHP-funktionerna till det nödvändiga. Hur PHP-FPM arbetar internt förklaras i [PHP-FPM förklarat](https://phpsos.de/sv/php/php-fpm-erklaert/).


## Vanliga frågor

**Är varje skal under PHP-FPM ett angrepp?**  
Inte varje. Vissa applikationer anropar medvetet program via PHP, till exempel för bildbehandling eller e-postutskick, och då kan ett skal kortvarigt uppstå. Det blir misstänkt när skalet körs längre, startar nätverksverktyg eller arbetar från ovanliga kataloger.

**Bör jag avsluta den misstänkta processen direkt?**  
Dokumentera först, agera sedan. Säkra processdata, kommandorad, arbetskatalog och nätverksanslutningar. Därefter isolerar ni servern. Ett förhastat avslut förstör spår och hindrar inte angriparen från att komma tillbaka.

**Finns det bekräftade kännetecken för PHP2Shell?**  
Nej. Det finns inga publicerade, bekräftade Indicators of Compromise. Skal under webbservern är en allmän varningssignal för intrång via webbapplikationer, inte specifik för PHP2Shell.

**Hur förhindrar jag att PHP överhuvudtaget startar skal?**  
Med disable_functions kan funktioner som exec, shell_exec, system och proc_open spärras om applikationen inte behöver dem. Det stänger ingen sårbarhet i PHP-tolken, men försvårar utnyttjandet.

## Källor

- [BSI: den tyska federala myndigheten för informationssäkerhet](https://www.bsi.bund.de/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
- [php.net: säkerhetsmeddelanden](https://www.php.net/)