Kratak odgovor
Kada sajt padne ili je hakovan, prvo ga izolujte (ne brišite ništa), utvrdite tačno vreme incidenta i pronađite rezervnu kopiju nastalu pre tog trenutka. Zatim vratite fajlove i bazu podataka iz backupa, proverite integritet, resetujte lozinke i tek onda ponovo pustite sajt u rad.
Kako se problem prepoznaje
- Sajt prikazuje grešku 500, belu stranicu ili poruku o grešci baze podataka
- Na sajtu se pojavljuju nepoznati linkovi, reklame ili stranice koje niste napravili
- Pojavljuju se novi administratorski nalozi ili nepoznati fajlovi u direktorijumu
- Google prikazuje upozorenje o opasnom sajtu ili sajt je uklonjen iz indeksa
- Hosting je suspendovao nalog zbog sumnjive aktivnosti ili prekoračenja resursa
Najčešći uzroci
Kompromitovana administratorska lozinka
Slaba ili ponovo korišćena lozinka omogućava napadaču da se prijavi kao administrator i menja sadržaj ili instalira zlonamerni kod.
Zastareli dodatak ili tema
Ranjivi dodaci i teme (naročito oni koji nisu ažurirani) najčešći su ulaz za napade na WordPress i slične sisteme.
Greška u konfiguraciji ili ažuriranju
Neuspešno ažuriranje, pogrešno izmenjen fajl ili konflikt dodataka može oboriti sajt i bez napada.
Problemi na hostingu
Pad servera, baze podataka ili prekoračenje resursa mogu izazvati nedostupnost sajta, a da sajt nije hakovan.
Zlonamerni kod na računaru
Ako se na sajt prijavljujete sa zaraženog računara, akreditivi mogu biti ukradeni i sajt kompromitovan.
Rešenje korak po korak
- 1
Izolujte sajt i sačuvajte dokaze
Ne brišite fajlove i ne radite reinstalaciju. Ako je sajt hakovan, prebacite ga u režim održavanja ili privremeno isključite javni pristup. Sačuvajte kopiju trenutnog stanja (fajlove i bazu) za analizu, a zatim što pre promenite pristupne podatke (FTP, baza, administratorski nalog).
- 2
Utvrdite vreme incidenta
Pregledajte pristupni log (access log) i log grešaka (error log) na hostingu (najčešće u kontrolnom panelu, npr. cPanel ili Plesk, u odeljku za logove ili statistiku, ili u direktorijumu za logove koji vam hosting navede). Zabeležite datum i vreme kada su se pojavile sumnjive aktivnosti ili greške. To je ključno da biste izabrali rezervnu kopiju nastalu pre tog trenutka.
- 3
Pronađite odgovarajuću rezervnu kopiju
U hosting panelu potražite sekciju za rezervne kopije (npr.
BackupiliBackup Wizard). Ako hosting pravi automatske dnevne backup-e, izaberite onaj od pre incidenta. Ako nemate hosting backup, proverite da li imate sopstvenu kopiju (plugin za backup, ručni izvoz baze i fajlova). - 4
Vratite fajlove sajta
Preko FTP ili upravljača fajlovima hostinga preimenujte trenutni direktorijum sajta (npr.
public_htmlupublic_html_old) i otpakujte arhivu rezervne kopije. Ne brišite stari direktorijum dok ne proverite da sve radi. Vodite računa da ne pregazite konfiguracione fajlove ako nisu deo backupa. Ako je moguće, prvo vratite sajt na lokalno razvojno okruženje radi provere. - 5
Vratite bazu podataka
U panelu baze podataka (npr. phpMyAdmin) napravite novu bazu ili, ako koristite postojeću, prvo napravite njen izvoz. Zatim, ako je potrebno, obrišite postojeće tabele i uvezite
.sqlfajl iz rezervne kopije. Ako se prefiks tabela razlikuje, prilagodite konfiguraciju sajta. Proverite da su sve tabele uvezene bez grešaka. - 6
Proverite integritet i uklonite zlonamerni kod
Uporedite fajlove sajta sa originalnom verzijom (npr. ponovnim preuzimanjem WordPress jezgra i tema). Pregledajte
wp-config.php,.htaccessi direktorijum za uploads na sumnjive fajlove. Ako pronađete nepoznate fajlove ili kod, izolujte ih (preimenujte ili pomerite van javnog direktorijuma) i zabeležite putanje. - 7
Resetujte lozinke i ključeve
Promenite lozinku za hosting panel, FTP, bazu podataka i sve administratorske naloge na sajtu. U WordPressu zamenite
SALTključeve uwp-config.phpnovim vrednostima (npr. pomoću generatora naapi.wordpress.org/secret-key/1.1/salt/). Uklonite nepoznate korisnike; promena SALT ključeva će odjaviti sve aktivne sesije. - 8
Ažurirajte sve i ponovo pustite sajt
Ažurirajte jezgro, teme i dodatke na najnovije verzije, uklonite nepotrebne dodatke i teme. Proverite da li sajt radi ispravno, pa ga vratite u javni režim. Pratite logove narednih 24 sata.
- 9
Prijavite problem i očistite reputaciju
Ako je sajt bio na Google listi opasnih sajtova, podnesite zahtev za ponovnu proveru u Google Search Console. Ako je hosting suspendovao nalog, obratite se podršci sa objašnjenjem šta ste uradili. Proverite da li su mejlovi kompromitovani i obavestite korisnike ako je bilo curenja podataka.
Ako ništa ne pomogne: napredna provera i izolacija
Ako se problem vraća i posle vraćanja iz backupa, moguće je da je zlonamerni kod ostao u bazi (npr. u opcijama, postovima ili korisnicima) ili u fajlovima izvan standardnog direktorijuma. Tada uradite sledeće: napravite potpuno novu instalaciju na čistom hostingu, uvezite samo sadržaj (postove, stranice, medije) iz proverene kopije, a teme i dodatke instalirajte iz zvaničnih izvora. Obavezno skenirajte računar iz kog se prijavljujete. Ako je sajt bio kompromitovan duže vreme, obratite se specijalizovanoj službi za forenziku ili hosting podršci koja može da pregleda logove na nivou servera.
Kako da sprečite da se ponovi
- Redovno pravite rezervne kopije (fajlovi i baza) i čuvajte ih van hostinga, najmanje 30 dana unazad.
- Ažurirajte jezgro, teme i dodatke odmah, i uklonite sve što ne koristite.
- Koristite jake, jedinstvene lozinke i dvofaktorsku autentifikaciju za administratore i hosting panel.
- Pratite logove i postavite obaveštenja o neuspešnim prijavama i promenama fajlova.
Kada je bolje pozvati stručnjaka
Ako sajt sadrži osetljive podatke korisnika, ako je bio kompromitovan duže vreme ili ako se problem ponavlja i posle više pokušaja vraćanja, obratite se IT stručnjaku ili specijalizovanoj službi za bezbednost sajta.
Izrada sajtova · Brzi, SEO optimizovani sajtovi na više jezikaČesta pitanja
Koliko često treba da pravim rezervne kopije sajta?
Za sajtove koji se često menjaju, preporučuje se dnevna automatska rezervna kopija, a ručna pre svake veće izmene (ažuriranje, instalacija dodatka). Čuvajte najmanje nedelju dnevnih i nekoliko mesečnih kopija.
Da li mogu da vratim samo bazu podataka ako je sajt hakovan?
Ponekad je dovoljno vratiti bazu ako je zlonamerni kod samo u njoj, ali često su izmenjeni i fajlovi. Najsigurnije je vratiti i fajlove i bazu iz iste rezervne kopije, pa zatim proveriti integritet.
Šta ako nemam rezervnu kopiju, a sajt je pao?
Obratite se hosting podršci i pitajte da li oni čuvaju backup-e. Ako ne, preostaje ručna sanacija ili izrada novog sajta. Zato je redovan backup ključan.