# Kontrolni popis nakon hakiranja: 20 točaka za naknadno postupanje

> Kontrolni popis kad je web-stranica hakirana: 20 točaka od obuzdavanja i osiguravanja dokaza preko čišćenja i novih pristupa do obveza prijave.

Izvor: https://phpsos.de/hr/ratgeber/checkliste-nach-dem-hack/  
Stanje: 25.10.2026  
Pružatelj: PHP SOS, PHP hitna pomoć i sigurnost poslužitelja. Hitna pomoć putem WhatsAppa: https://wa.me/491736494914?text=Pozdrav%20PHP%20SOS%2C%20trebamo%20pomo%C4%87%20s%20na%C5%A1im%20PHP%20poslu%C5%BEiteljem.%20Tvrtka%3A%20%E2%80%A6%20Web-stranica%3A%20%E2%80%A6

**Ukratko:** Ako je Vaša web-stranica hakirana, ovaj kontrolni popis pomaže da ništa ne zaboravite: najprije obuzdati i osigurati dokaze, zatim pronaći uzrok i očistiti, potom obnoviti sve pristupe, provjeriti obveze i incident dokumentirano zaključiti. Redoslijed je važan jer tko najprije briše, gubi tragove, a tko samo čisti bez zatvaranja ranjivosti, bit će ponovno napadnut.

## Za što vrijedi ovaj kontrolni popis kad je web-stranica hakirana

Kontrolni popis namijenjen je upravi, vlasnicima i IT odgovornima nakon potvrđenog ili vjerojatnog napada na web-stranicu, shop ili PHP web-poslužitelj. Prikladan je i nakon PHP2Shella, ako je poslužitelj prije ažuriranja bio dostupan i postoje naznake kompromitacije.

Nije svaka točka prikladna za svako okruženje. Ipak prođite popis u cijelosti i uz svaku točku zabilježite je li obavljena, neprimjenjiva ili otvorena. Taj je zapisnik kasnije vrijedan za osiguranje, zaštitu podataka i interno naknadno postupanje.

Uz svaki korak upišite datum, vrijeme, odgovornu osobu i rezultat. Ako je uključeno više osoba, odredite jednu koja vodi popis i bilježi odluke.

## Faza 1: odmah obuzdati i osigurati

1. **Ograničiti štetu:** Web-stranicu staviti u način održavanja ili je isključiti s mreže ako su posjetitelji ugroženi ili podaci mogu curiti. BSI (njemački Savezni ured za sigurnost informacijske tehnologije) kod PHP2Shella preporučuje privremeno isključiti nezakrpane web-poslužitelje s mreže ako ažuriranje nije odmah moguće.
2. **Ništa ne brisati:** Ne uklanjati datoteke, poslužitelj ne postavljati iznova i ne pražniti logove prije nego se tragovi osiguraju.
3. **Osigurati logove:** Access, error, PHP-FPM i sistemske logove kopirati na drugi sustav i zabilježiti kontrolne zbrojeve. Za PHP2Shell stručni mediji savjetuju čuvanje logova od 20.10.2026.
4. **Osigurati sliku:** Kopiju datoteka i baze podataka, kod virtualnih poslužitelja snapshot, izraditi kao dokazno stanje i ne mijenjati je.
5. **Obavijestiti odgovorne:** Rano uključiti upravu, službenika za zaštitu podataka, pružatelja hostinga i, ako postoji, kibernetičko osiguranje. Mnoga osiguranja imaju obveze prijave.

## Faza 2: pronaći uzrok i očistiti

6. **Utvrditi ulaz:** Analizirati logove, izmjene datoteka i verzije. Provjerite sam PHP, CMS, teme, ekstenzije, pristupne podatke i usluge poslužitelja. Bez poznatog uzroka ostaje rizik novog napada.
7. **Zatvoriti ranjivost:** PHP dovesti na ispravljenu verziju (8.5.12, 8.4.27, 8.3.36 ili 8.2.35 odnosno potvrđeni backport pružatelja), ažurirati CMS i ekstenzije, ponovno pokrenuti sve PHP workere.
8. **Suziti razdoblje:** Odrediti najraniji trenutak sumnjive aktivnosti. On odlučuje koje sigurnosne kopije mogu biti čiste i koji podaci mogu biti pogođeni.
9. **Ukloniti stražnja vrata:** Provjeriti i ukloniti webshellove, strane PHP datoteke u mapama za upload i cache, izmijenjene datoteke jezgre, cron zadatke, SSH ključeve i sistemske usluge. Datoteke jezgre zamijeniti iz čistog izvora.
10. **Očistiti bazu podataka:** Ukloniti nepoznate admin račune, ubačene skripte u sadržajima i postavkama te spam sadržaje.
11. **Razmotriti ponovnu izgradnju:** Kod dubinske kompromitacije poslužitelja ponovna izgradnja na svježem, zakrpanom sustavu s provjerenim podacima često je pouzdaniji put od čišćenja na pokrenutom sustavu.

## Faza 3: obnoviti pristupe i ojačati

12. **Promijeniti lozinke:** Za CMS, hosting račun, panel, bazu podataka, FTP, SFTP, SSH i e-poštu, i to s čistog uređaja.
13. **Zamijeniti ključeve i tokene:** Iznova generirati API ključeve, sučelja usluga plaćanja i dostave, ključeve aplikacije CMS-a, SSH ključeve i certifikate koji su bili na poslužitelju.
14. **Završiti sesije:** Odjaviti sve aktivne prijave u CMS-u i kod usluga te provjeriti registrirane uređaje za dvofaktorsku prijavu.
15. **Aktivirati dvofaktorsku prijavu:** Za sve admin pristupe, uključujući hosting, domenu i DNS.
16. **Ojačati poslužitelj:** Provjeriti i dokumentirati PHP postavke, prava datoteka, zabrane izvršavanja u mapama za upload, vatrozid i sigurnosna zaglavlja.

## Faza 4: obveze, komunikacija i zaključivanje

17. **Provjeriti obveze prijave:** Ako mogu biti pogođeni osobni podaci, prema [čl. 33. GDPR-a može biti potrebna prijava u roku od 72 sata](https://phpsos.de/hr/compliance/dsgvo-meldepflicht-72-stunden/). Procjena pripada službeniku za zaštitu podataka ili odvjetniku. Obveze specifične za branšu, primjerice prema NIS2, provjeriti zasebno.
18. **Razmotriti prijavu:** [Središnje kontaktne točke za kibernetički kriminal (Zentrale Ansprechstellen Cybercrime, ZAC)](https://phpsos.de/hr/compliance/anzeige-polizei-zac/) njemačke policije primaju prijave tvrtki. Osigurani logovi za to su važna osnova.
19. **Obavijestiti klijente i Google:** Pogođene osobe obavijestiti stvarno i usklađeno. Ako Google prikazuje upozorenje, nakon čišćenja zatražiti ponovnu provjeru, kako je opisano u vodiču [Uklanjanje Google upozorenja](https://phpsos.de/hr/ratgeber/google-warnung-entfernen/).
20. **Zabilježiti zaključak i nadzirati:** Uzrok, razdoblje, mjere i otvorene točke zabilježiti u izvješću, izvesti pouke za plan za hitne slučajeve i u idućim tjednima pojačano nadzirati sustave.

## Česte pogreške pri naknadnom postupanju

Mnogi se incidenti otegnu jer se u prvom uzbuđenju štedi na pogrešnom mjestu ili prebrzo djeluje. Ove pogreške trebali biste izbjegavati:

- **Ukloniti samo vidljivo:** Izbrisana spam stranica ili uklonjeno preusmjeravanje nisu dokaz čiste web-stranice. Stražnja vrata često ostaju neprimijećena.
- **Mijenjati lozinke sa pogođenog sustava:** Ako na računalu ili poslužitelju još radi zlonamjerni softver, nove pristupne podatke moguće je odmah ponovno izvući.
- **Naslijepo vratiti sigurnosnu kopiju:** Bez zatvorene ranjivosti i bez provjere sigurnosne kopije napadač brzo opet stoji na vratima.
- **Zakrpu shvatiti kao otklanjanje uzbune:** Ažuriranje na ispravljenu verziju PHP-a ne dokazuje da se prije nije ništa dogodilo i ne uklanja ubačeni zlonamjerni softver.
- **Prekasno provjeriti obveze:** Rokovi počinju saznanjem za incident, a ne krajem čišćenja.
- **Bez dokumentacije:** Bez zapisnika se pitanja osiguranja, tijela ili klijenata kasnije jedva mogu odgovoriti.

> **Važno:**
> Ovaj kontrolni popis ne zamjenjuje pravni savjet. Za pitanja o obvezama prijave, odgovornosti ili osiguranju obratite se službeniku za zaštitu podataka, odvjetniku ili osiguravatelju.

## Kako PHP SOS konkretno pomaže?

- Preuzimamo strukturirani [odgovor na incident](https://phpsos.de/hr/leistungen/incident-response/) i s Vama vodimo kontrolni popis, točku po točku, sa zapisnikom.
- Logove i stanja sustava osiguravamo tako da ostanu upotrebljivi za osiguranje, tijela i moguću [IT forenziku](https://phpsos.de/hr/leistungen/it-forensik/).
- Zatvaramo ranjivost, čistimo ili gradimo iznova i obnavljamo pristupe pravilnim redoslijedom.
- Isporučujemo završno izvješće s uzrokom, mjerama i preporukama te po želji nakon toga dalje nadziremo sustave.


## Česta pitanja

**Što prvo trebam učiniti ako je moja web-stranica hakirana?**  
Sačuvati mirnu glavu, ništa ne brisati i ograničiti štetu. Po potrebi isključite web-stranicu s mreže ili je stavite u način održavanja i osigurajte logove i datoteke prije čišćenja. Zatim slijede potraga za uzrokom i čišćenje.

**Je li dovoljno vratiti web-stranicu iz sigurnosne kopije?**  
Najčešće nije. Sigurnosna kopija može već sadržavati zlonamjerni kod, a ranjivost kroz koju je napadač došao nakon vraćanja je još otvorena. Najprije zatvorite uzrok, zatim vratite provjereno, čisto stanje na ažuriran sustav.

**Moram li hakiranje prijaviti tijelu za zaštitu podataka?**  
Ako mogu biti pogođeni osobni podaci, čl. 33. GDPR-a u načelu predviđa prijavu u roku od 72 sata od saznanja, osim ako rizik za ispitanike nije vjerojatan. Procjena pripada Vašem službeniku za zaštitu podataka ili odvjetniku.

**Kada je incident zaista zaključen?**  
Kad je uzrok zatvoren, sva poznata stražnja vrata uklonjena, pristupi obnovljeni, obveze ispunjene i mjere dokumentirane. Tu spada i razdoblje pojačanog nadzora nakon toga, radi prepoznavanja previđenih tragova.

## Izvori

- [GDPR čl. 33: prijava nadzornom tijelu](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [Policija: Središnje kontaktne točke za kibernetički kriminal (Njemačka)](https://www.polizei.de/)
- [BSI: napomene o IT sigurnosnim incidentima](https://www.bsi.bund.de/)
- [php.net: sigurnosne objave o PHP2Shellu](https://www.php.net/)