Ukratko: Tko nakon sigurnosnog incidenta želi promijeniti hostera, trebao bi najprije osigurati dokaze i razjasniti incident, zatim na novo postavljen sustav prenijeti samo provjerene podatke i tek onda otkazati stari ugovor. Novog pružatelja birajte prema sigurnosnim kriterijima: dokazivi postupci zakrpanja, razdvajanje klijenata, pristup zapisnicima, sigurnosne kopije i jasne kontakt osobe. Promjena hostera ima smisla kad nedostaje povjerenja ili kvalitete usluge, ali ne zamjenjuje čišćenje.
Kad povjerenja više nema
Nakon PHP2Shella mnoge tvrtke prvi put doživljavaju svog hostera pod pritiskom. Neke su brzo dobile jasnu informaciju o stanju zakrpe. Druge su danima čekale odgovor, dobile samo opće fraze ili utvrdile da je njihova web-stranica radila na zastarjeloj PHP verziji. Ako se tome pridoda još i incident, želja za promjenom je razumljiva.
Promjena hostera ipak nije korak rješavanja incidenta, nego novog početka nakon njega. Tko je stavi u pogrešan redoslijed, u najgorem slučaju sa sobom povlači napadača i istodobno gubi tragove koji pokazuju što se dogodilo.
Pravi redoslijed pri promjeni
- Osigurati tragove dok postoje. Zapisnici, datoteke i baza podataka starog sustava pripadaju u sigurnosnu kopiju prije nego što se nešto obriše ili otkaže. Starog hostera izričito pitajte za pristupne zapisnike i zapisnike pogrešaka od 20. listopada 2026. te za trajanje njihove pohrane. Kako postupiti, opisuje članak Osigurati dokaze prije ponovne instalacije.
- Ograničiti incident. Koji su sustavi pogođeni, koji su pristupi korišteni, koji su podaci bili dostupni? O tome ovise obveze prijave i pitanje što smijete preseliti.
- Provjeriti obveze prijave. Ako su mogli biti pogođeni osobni podaci, rok za moguću GDPR prijavu počinje saznanjem za incident, a ne selidbom. Pozadinu donosi članak Obveza prijave prema GDPR-u: 72 sata.
- Novi sustav postaviti čisto. Podržana PHP verzija, aktualni paketi, ojačana konfiguracija, prije nego što se prenese prva datoteka.
- Prenijeti samo provjereno. Kod iz čistog izvora, baza podataka i mediji nakon kontrole.
- Promijeniti sve pristupne podatke. Baza podataka, administratorski računi, SSH, FTP, API ključevi, i oni u konfiguracijskim datotekama.
- Prebaciti i promatrati. Promjena DNS-a, zatim neko vrijeme pojačan nadzor.
- Raskinuti stari ugovor. Tek kad su zapisnici i sigurnosne kopije osigurani, a novi pogon stabilno radi.
Ne otkazujte stari ugovor dok zapisnike i sigurnosne kopije nemate u rukama. S krajem ugovora kod pružatelja se mogu obrisati podaci koji su Vam potrebni za osiguravatelja, tijela ili vlastito razjašnjavanje.
Što ne biste smjeli preseliti
Bilo bi zgodno jednostavno kopirati cijeli web-direktorij ili sliku poslužitelja. Upravo je to nakon incidenta rizično. Web shellovi maskiraju se u bezazlene datoteke, stražnja vrata skrivaju se u konfiguracijskim datotekama poput .htaccess ili .user.ini, a ubačeni kod može ležati u sadržaju baze podataka.
Kod aplikacije stoga prenesite iz čistog izvora, primjerice iz paketa proizvođača u odgovarajućoj verziji ili iz svog sustava za upravljanje verzijama. Medije preuzmite bez izvršnih datoteka, a bazu podataka nakon provjere na upadljive sadržaje i nove administratorske račune. Ono što je pronađeno na starom sustavu pomaže u toj provjeri.
Pomislite i na sve što uz web-stranicu leži kod starog pružatelja. E-mail sandučići, DNS zapisi, certifikati i preusmjeravanja pri selidbi se lako zaborave. Nekoliko dana prije prebacivanja skratite vrijeme valjanosti DNS zapisa kako bi promjena brzo stigla do posjetitelja. Ako se sele i e-mailovi, promjenu sandučića planirajte zasebno, jer i tamo nakon incidenta mogu biti pogođeni pristupni podaci.
Novog hostera birati prema sigurnosti
Cijena i prostor za pohranu stoje u svakoj ponudi. Ključna sigurnosna pitanja uglavnom morate postaviti sami. Sljedeći popis pomaže pri usporedbi:
| Kriterij | Pitanje pružatelju | Zašto je važno |
|---|---|---|
| Postupak zakrpanja | Kako i u kojem okviru se instaliraju PHP sigurnosna ažuriranja i radi ponovno pokretanje? | PHP2Shell je pokazao koliko je važan dokaziv postupak |
| Dokaz | Dobivam li na zahtjev pisanu potvrdu o stanju zakrpe? | Osnova za Vašu vlastitu dokumentaciju |
| PHP verzije | Koje se grane nude i dokle? | Stare grane bez ažuriranja trajan su rizik |
| Razdvajanje | Radi li svaka web-stranica s vlastitim korisnikom i vlastitim PHP procesom? | Ograničava štetu ako je napadnut susjed |
| Zapisnici | Imam li pristup pristupnim zapisnicima i zapisnicima pogrešaka, koliko se dugo čuvaju? | Bez zapisnika nema razjašnjavanja |
| Sigurnosne kopije | Koliko često, koliko dugo, odvojeno od web-poslužitelja, s testom oporavka? | Oporavak nakon incidenta |
| Kontakt za hitne slučajeve | Kako u slučaju incidenta mogu doći do stručne osobe? | Vrijeme je u kriznoj situaciji najrjeđi čimbenik |
| Obrada podataka | Postoji li ugovor prema GDPR-u i popis podobrađivača? | Obveza kod osobnih podataka |
Predložak za pitanje o stanju zakrpe nudi vodič Pitati hostera za stanje zakrpe. Prikladan je i za usporedbu pružatelja prije sklapanja ugovora.
Je li drugi model poslovanja bolji odgovor?
Ponekad problem nije toliko u hosteru koliko u modelu poslovanja. Tko vodi vlastiti poslužitelj bez redovite njege, često je bolje zbrinut uz dobro održavanu upravljanu ponudu. Obrnuto, tvrtka s vlastitim IT-om može dobiti više kontrole nad trenucima zakrpanja ako sama upravlja. Odvagivanje opisuje članak Upravljani hosting ili vlastiti poslužitelj?.
Neovisno o modelu vrijedi: podjelu zadataka zabilježite pisano. Tko instalira PHP ažuriranja, tko ponovno pokreće, tko provjerava aplikaciju, tko se u slučaju nužde kome javlja? Kod PHP2Shella mnoga su kašnjenja nastala upravo na tom mjestu, jer je svaka strana mislila da će se druga pobrinuti.
Kako PHP SOS konkretno pomaže?
- Osiguravamo zapisnike i podatke starog sustava i razjašnjavamo što se dogodilo tijekom incidenta.
- Novi sustav postavljamo ojačano i prenosimo samo provjerene sadržaje iz čistih izvora.
- Ponude novih pružatelja provjeravamo prema sigurnosnim kriterijima i postavljamo prava pitanja.
- Kod aktivnog incidenta radimo u okviru svog odgovora na incidente sve dok incident nije zaključen i dokumentiran.
Česta pitanja
Trebam li nakon hakerskog napada odmah promijeniti hostera?
Ne odmah. Prvo treba osigurati tragove, ograničiti incident i razjasniti uzrok. Prenagljena selidba možda sa sobom nosi zlonamjerni kod i može uništiti dokaze kod starog pružatelja.
Je li hoster kriv ako je moja web-stranica napadnuta putem PHP2Shella?
To ovisi o ugovoru i trenutku. Kod zajedničkog hostinga za PHP ažuriranja je u pravilu odgovoran hoster, a kod vlastitih poslužitelja operater. Zakrpe su objavljene 21. listopada 2026.; jesu li i kada instalirane, može se razjasniti samo dokazima. Za pitanja odgovornosti zatražite pravni savjet.
Koje podatke smijem preseliti k novom hosteru?
Samo provjerene sadržaje: bazu podataka nakon provjere na ubačeni kod, medije bez izvršnih datoteka i kod iz čistog izvora, poput paketa proizvođača ili Vašeg sustava za upravljanje verzijama. Cijele slike poslužitelja ili web-direktorije s kompromitiranog sustava ne biste smjeli prenositi neprovjereno.
Moram li nakon incidenta uključiti zaštitu podataka?
Ako su mogli biti pogođeni osobni podaci, može postojati obveza prijave prema GDPR-u, u pravilu u roku od 72 sata. Kod novog hostera uz to trebate ugovor o obradi podataka. Razjasnite to sa službenikom za zaštitu podataka; ovo nije pravni savjet.