Ukratko: Hoćete li poslužitelj nakon hakiranja ponovno postaviti ili očistiti, ovisi o tome koliko sigurno poznajete opseg provale. Ako je napadač možda imao root prava, trenutak provale je nejasan ili nedostaju logovi, ponovna izgradnja iz pouzdanih izvora pouzdaniji je izbor. Čišćenje dolazi u obzir samo kod usko ograničene, dobro dokazane zaraze. U oba slučaja vrijedi: najprije osigurati dokaze i zatvoriti ranjivost, tek onda čistiti.
Zašto se to pitanje nakon PHP2Shella postavlja osobito često
PHP2Shell prema php.net-u omogućuje izvršavanje zlonamjernog koda na daljinu bez prijave. Tko je vodio nezakrpan poslužitelj, mora se zato pitati je li se u vremenu od 17. 10. 2026., prvog pokušaja napada koji je prema medijskim izvješćima uočen, nešto dogodilo. Zakrpa ne odgovara na to pitanje i nema objavljenih, potvrđenih Indicators of Compromise.
Ako se zatim pronađe sumnjiva datoteka, nepoznat proces ili strani cron posao, treba donijeti odluku. Poriv je često brzo brisati ili odmah iznova instalirati. Oboje može biti ispravno, ali ne kao prvi korak.
Redoslijed prije odluke
Prije nego što odaberete između čišćenja i ponovnog postavljanja, treba obaviti tri stvari. Vrijede za oba puta.
- Obuzdati: Poslužitelj skinuti s mreže ili pristup ograničiti na najnužnije, a da se ne isključi ako se još želi osigurati radna memorija.
- Osigurati dokaze: Osigurati logove, datoteke, bazu podataka i po mogućnosti sliku sustava, s datumom i kontrolnim zbrojem. Zašto je to potrebno prije svake nove instalacije, objašnjava Osigurajte dokaze prije ponovnog postavljanja.
- Uključiti osiguratelja i zaštitu podataka: Mnoge police kibernetičkog osiguranja očekuju da se bitni koraci usuglase. Napomene su u članku Kibernetičko osiguranje: što se računa u slučaju štete. Postoji li obveza prijave prema GDPR-u, procjenjuju službenik za zaštitu podataka ili odvjetnik.
Tek nakon toga isplati se pravo odvagivanje.
Poslužitelj ponovno postaviti nakon hakiranja ili očistiti: kriteriji
| Kriterij | Čistiti | Ponovno postaviti |
|---|---|---|
| Opseg provale | Usko ograničen, dokazan, primjerice jedna datoteka u mapi za upload bez daljnjih tragova | Nejasan ili s naznakama pristupa sustavu |
| Moguća root prava napadača | Isključena uz dobre dokaze | Ne može se isključiti |
| Dostupnost logova | Potpuni za relevantno razdoblje | Nepotpuni, prebrisani ili podložni manipulaciji |
| Trud | Manji, ako je nalaz jasan | Veći, ali bolje planirljiv |
| Preostala nesigurnost | Veća, skrivena stražnja vrata teško je isključiti | Manja, ako je uredno izgrađeno iz pouzdanih izvora |
| Vrijeme ispada | Najčešće kraće | Najčešće duže, uz pripremu dobro upravljivo |
| Prikladnost za stare sustave | Problematično ako je sustav ionako zastario | Dobra prilika za prelazak na podržanu verziju PHP-a |
Kao praktično pravilo vrijedi: što manje znate, to više govori u prilog ponovnoj izgradnji. Kod ranjivosti u PHP interpreteru koja izvršava kod u kontekstu korisnika web-poslužitelja, napadač može iskoristiti daljnje slabosti da postigne više prava. To se bez temeljite istrage teško može isključiti.
Oba puta u praksi
Što „ponovno postaviti“ doista znači
Ponovno postaviti ne znači staru sigurnosnu kopiju prekopirati na svjež poslužitelj. Ponovna izgradnja počinje čistim operacijskim sustavom iz službenog izvora, aktualnim paketima i zakrpanom verzijom PHP-a. Aplikacija se instalira iz originala proizvođača, jednako tako dodaci i teme.
Tek tada dolaze vlastiti sadržaji, i to provjereni. Učitane datoteke ne smiju sadržavati izvršive skripte, baza podataka može sadržavati ubačene sadržaje, primjerice skrivene administratorske račune ili skripte u člancima. Konfiguracijske datoteke pišu se iznova umjesto da se kopiraju. Svi se pristupni podaci obnavljaju: baza podataka, CMS administratori, SSH ključevi, API ključevi, hosting panel.
Sigurnosne kopije tu imaju važnu ulogu, ali samo ako je njihovo stanje prije provale i ako same nisu izmijenjene. Više generacija na odvojenim mjestima to čini provjerljivim; više o tome u članku Sigurnosne kopije prema pravilu 3-2-1.
Kada je čišćenje opravdano
Čišćenje može biti smisleno ako je zaraza rano otkrivena, postoje potpuni logovi i istraga ne daje naznaku daljnjih pristupa. Tada se pronađene datoteke nakon osiguranja uklanjaju, provjeravaju se cron poslovi, korisnički računi i SSH ključevi, a jezgrene datoteke uspoređuju s originalom proizvođača.
Važna je realistična procjena: web shellovi su često neuočljivi i skriveni na više mjesta. Kako ih pronaći, opisuje Prepoznavanje i uklanjanje web shellova. Nakon čišćenja poslužitelj treba pomno promatrati kako bi se previđena stražnja vrata primijetila.
Ništa ne brišite prije nego što su logovi i datoteke osigurani i zatvorite ranjivost prije nego što poslužitelj ponovno ode na mrežu. Inače gubite tragove i pozivate sljedeću provalu.
Kada Vam pružatelj usluga nije potreban
Kod jednostavne web-stranice na zajedničkom hostingu, gdje pružatelj hostinga upravlja sustavom i potvrđuje PHP zakrpu, odluka često uopće nije na Vama. Možete aplikaciju iznova instalirati iz originala, provjeriti sadržaje i obnoviti pristupne podatke, uz podršku pružatelja hostinga. Ni iskusan interni tim ne mora izbjegavati ponovnu izgradnju ako su osiguranje dokaza i dokumentacija zbrinuti.
Vanjska pomoć isplati se ako se root prava ne mogu isključiti, ako bi mogli biti pogođeni osobni podaci, ako je uključeno osiguranje ili ako je povezano više sustava.
Kako PHP SOS konkretno pomaže?
- Osiguravamo logove, datoteke i bazu podataka na način prihvatljiv kao dokaz prije nego što se išta promijeni.
- Procjenjujemo opseg provale i preporučujemo čišćenje ili ponovnu izgradnju s obrazloženjem, odvojeno na dokazano, vjerojatno i nepoznato.
- Po potrebi iznova gradimo poslužitelj iz pouzdanih izvora, sa zakrpanom verzijom PHP-a i obnovljenim pristupima.
- Preuzimamo uklanjanje zlonamjernog softvera gdje je čišćenje opravdano i dokumentiramo svaki korak.
Zaključak
Na pitanje „ponovno postaviti ili očistiti?“ odgovara se znanjem o provali. Tko ne poznaje opseg sigurno, gradi iznova. Tko ga može dobro dokazano ograničiti, smije čistiti. U oba slučaja vrijedi isti redoslijed: obuzdati, osigurati, zatvoriti ranjivost, zatim čistiti.
Česta pitanja
Je li ponovno postavljanje nakon hakiranja uvijek bolje?
Ne uvijek, ali često. Ako je nejasno dokle je napadač stigao, ponovna izgradnja iz pouzdanih izvora najčešće je pouzdaniji izbor. Kod usko ograničene, dobro dokazane zaraze čišćenje može biti dovoljno.
Mogu li jednostavno vratiti staru sigurnosnu kopiju?
Samo ako je sigurno da je kopija nastala prije provale i da ne sadrži stražnja vrata. Uz to ranjivost mora prije biti zatvorena, inače je poslužitelj odmah opet napadljiv. Novije podatke treba posebno provjeriti.
Što moram osigurati prije ponovnog postavljanja?
Logove, kopiju datoteka i baze podataka te, ako je moguće, sliku sustava. Ti su dokazi potrebni za analizu uzroka, osiguranje i moguću prijavu. Nakon brisanja ih nema.
Je li dovoljno obrisati pronađeni web shell?
Rijetko. Napadači često postavljaju više stražnjih vrata, primjerice cron poslove, korisničke račune ili SSH ključeve. Tko briše samo vidljivu datoteku, ostale pristupe ostavlja otvorenima.