# Ali sem že ogrožen? Znaki po PHP2Shell

> Strežnik vdrt? Tipični znaki po PHP2Shell, prvi pregledi brez izgube sledi in kaj naj storite ob sumu, korak za korakom, od dnevnikov do prijave.

Vir: https://phpsos.de/sl/php2shell/bin-ich-gehackt-anzeichen/  
Stanje: 25.10.2026  
Ponudnik: PHP SOS, Nujna pomoč za PHP in varnost strežnikov. Takojšnja pomoč po WhatsAppu: https://wa.me/491736494914?text=Pozdravljeni%2C%20PHP%20SOS%2C%20potrebujemo%20pomo%C4%8D%20z%20na%C5%A1im%20stre%C5%BEnikom%20PHP.%20Podjetje%3A%20%E2%80%A6%20Spletna%20stran%3A%20%E2%80%A6

**Na kratko:** Ali je bil strežnik vdrt prek PHP2Shell, ni mogoče razbrati iz ene same značilnosti. Objavljenih, potrjenih indikatorjev ogroženosti (Indicators of Compromise) ni; odkrivanje temelji na analizi vedenja. Tipični znaki so nove datoteke PHP, neznana cron opravila in nenavadne povezave. Najprej zavarujte dnevnike od 20. oktobra dalje, preden karkoli spremenite.

## Ali obstajajo nedvoumni znaki napada PHP2Shell?

Ne, in to je pošten odgovor. Za številne znane ranljivosti proizvajalci ali varnostna podjetja objavijo konkretne sledi: imena datotek, kontrolne vsote, naslove IP. Za PHP2Shell takšnih potrjenih indikatorjev ogroženosti doslej ni.

Kar je znano: po poročilih medijev je bil prvi poskus napada opažen 17. oktobra, štiri dni pred popravki z dne 21. oktobra. Cloudflare je poročal o nadaljnjih poskusih. Potrjeni uspešni napadi v širšem obsegu po navedbah BSI sprva niso bili znani. Kdor je bil med 17. oktobrom in lastnim popravkom nezaščiteno dosegljiv, naj zato preveri, namesto da upa.

Za oceno šteje predvsem obdobje. Med prvim opaženim poskusom napada 17. oktobra in popravki 21. oktobra uradne posodobitve ni bilo. Vsak javno dosegljiv strežnik PHP je bil v tem času potencialno napadljiv. Kako dolgo je bil vaš strežnik odprt tudi po tem, je odvisno od tega, kdaj je bila posodobitev nameščena in PHP znova zagnan. Čim daljše je to obdobje in čim občutljivejši so podatki, na primer računi strank, naročila ali prijave, tem temeljitejši naj bo pregled.

## Tipični znaki, da je bil strežnik vdrt

Po uspešnem izvajanju kode se napadalci običajno poskušajo zasidrati in strežnik uporabiti. Iz tega izhajajo znaki, ki niso specifični za PHP2Shell, a štejejo pri vsakem pregledu vdora:

- **Nove ali spremenjene datoteke PHP,** zlasti v mapah za nalaganje, predpomnilnik ali slike, v katerih sicer ni datotek PHP.
- **Neznana cron opravila** ali načrtovane naloge, na primer za uporabnika spletnega strežnika.
- **Nenavadne odhodne povezave** na neznane naslove, visoka obremenitev omrežja ali pošiljanje e-pošte, ki ga nihče ni sprožil.
- **Novi skrbniški računi** v CMS-ju ali trgovini, spremenjena gesla, neznani ključi SSH.
- **Opazna obremenitev:** trajno visoka obremenitev CPE zaradi neznanih procesov, pogosto znak rudarjenja kriptovalut.
- **Vidne posledice:** preusmeritve na tuje strani, strani s spamom v Googlovem indeksu, opozorila v brskalniku ali v Search Console.

Nobeden od teh znakov sam po sebi ne dokazuje vdora, njihova odsotnost pa ne dokazuje nasprotnega. Odločilna je celotna slika.

## Prvi pregledi brez uničenja sledi

Preden karkoli izbrišete ali znova zaženete: zavarujte dnevnike. Strokovni tisk svetuje hranjenje dnevnikov strežnika od 20. oktobra dalje. Dnevnike spletnega strežnika, PHP in sistema kopirajte na varno mesto zunaj strežnika.

Nato pomagajo izključno bralni pregledi. Poti in uporabniška imena se po sistemih razlikujejo:

```bash
# Datoteke PHP, spremenjene od 17. 10.
find /var/www -type f -name "*.php" -newermt "2026-10-17" -ls

# Datoteke PHP v mapah za nalaganje (primer WordPress)
find /var/www -path "*/uploads/*" -name "*.php" -ls

# Cron opravila uporabnika spletnega strežnika in sistemska
crontab -l -u www-data
ls -la /etc/cron.d /etc/cron.daily /var/spool/cron 2>/dev/null

# aktivne omrežne povezave s procesom
ss -tunp

# zadnje prijave
last -n 30
```

Upoštevajte: napadalci lahko ponaredijo časovne žige datotek. Neopazen rezultat `find` zato ni oprostitev. Kako ciljno analizirate dnevnike, opisuje stran [Analiza dnevnikov spletnega strežnika po napadu](https://phpsos.de/sl/ratgeber/logfiles-auswerten/); kako najdete stranska vrata, stran [Prepoznavanje in odstranjevanje webshellov](https://phpsos.de/sl/ratgeber/webshell-erkennen/).

> **Ukrepajte takoj:**
> Če najdete konkretne namige, na primer neznano datoteko PHP v mapi za nalaganje: ne brišite, ne postavljajte znova, aplikacije ne „hitro popravljajte“. Strežnik ločite od omrežja ali ga izolirajte, zavarujte dnevnike in sliko sistema ter začnite urejeno obravnavo incidenta.

## Česa ne smete storiti

- **Samo popraviti in nadaljevati.** Popravek ne odstrani že vnesene škodljive programske opreme.
- **Sumljive datoteke takoj izbrisati.** S tem izginejo dokazi o tem, kaj se je zgodilo in kateri podatki bi lahko bili prizadeti.
- **Strežnik postaviti znova, preden je zavarovan.** Vzrok ostane nejasen, stranska vrata v podatkovni zbirki ali dostopni podatki pa preživijo novo namestitev.
- **Stare varnostne kopije obnoviti nepreverjeno.** Tudi kopija lahko že vsebuje stranska vrata.
- **Pozabiti dostopne podatke.** Po izvajanju kode so lahko gesla podatkovne zbirke, ključi API in drugi dostopni podatki iz konfiguracijskih datotek iztekli. Obnovite jih po čiščenju, ne prej, da novih noben še aktivni napadalec ne prebere sproti.

## Če se sum potrdi

Takrat ne gre več samo za tehniko. S pooblaščencem za varstvo podatkov preverite, ali je potrebna prijava po GDPR; rok je 72 ur od seznanitve, podrobnosti na strani [Obveznost prijave po GDPR](https://phpsos.de/sl/compliance/dsgvo-meldepflicht-72-stunden/). Zgodaj obvestite svojo zavarovalnico za kibernetska tveganja, če jo imate, in z odvetnikom razjasnite, ali naj se poda ovadba. Glede tega podajamo splošne napotke, ne pravnega svetovanja.

## Kako konkretno pomaga PHP SOS?

Z našim [incident response](https://phpsos.de/sl/leistungen/incident-response/) sum obdelamo strukturirano:

- **Zavarovati:** dnevnike od 20. oktobra dalje in, kjer je treba, sliko sistema, preden se karkoli spremeni.
- **Preiskati:** analiza vedenja datotek, procesov, povezav in računov; po potrebi z dokazno vrednostjo prek [IT-forenzike](https://phpsos.de/sl/leistungen/it-forensik/).
- **Očistiti in zapreti:** odstraniti stranska vrata, posodobiti PHP, obnoviti dostopne podatke, strežnik utrditi.
- **Dokumentirati,** dokler incident ni zaključen in dokumentiran, kot podlago za varstvo podatkov, zavarovanje in vodstvo.


## Pogosta vprašanja

**Ali posodobitev PHP dokazuje, da je moj strežnik čist?**  
Ne. Popravek ranljivost zapre za prihodnost, ne odstrani pa že vnesene škodljive programske opreme. Prav tako ne pove, ali je kdo vdrl pred popravkom.

**Ali obstaja skener, ki napade PHP2Shell zanesljivo prepozna?**  
Doslej ne. Objavljenih, potrjenih indikatorjev ogroženosti (Indicators of Compromise), ki bi jih skener lahko ciljno iskal, ni. Skenerji zlonamerne kode najdejo znane webshelle, ocena strežnika pa temelji na analizi vedenja.

**Ali moram sum prijaviti organu za varstvo podatkov?**  
To je odvisno od tega, ali so lahko prizadeti osebni podatki. GDPR za prijavljive kršitve varstva podatkov predvideva rok 72 ur od seznanitve. Zgodaj to razjasnite s pooblaščencem za varstvo podatkov ali odvetnikom; pravnega svetovanja ne nudimo.

**Ali naj vdrti strežnik preprosto postavim znova?**  
Ne kot prvi korak. Najprej zavarujte dnevnike in, če je mogoče, sliko sistema. Kdor takoj postavi znova, izgubi sledi, ki kažejo, kaj se je zgodilo in kateri podatki bi lahko bili prizadeti.

## Viri

- [php.net: varnostna obvestila](https://www.php.net/)
- [BSI: nemški zvezni urad za informacijsko varnost](https://www.bsi.bund.de/)
- [GDPR, 33. člen: prijava nadzornemu organu](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)