Кратак одговор
Када сајт падне или је хакован, прво га изолујте (не бришите ништа), утврдите тачно време инцидента и пронађите резервну копију насталу пре тог тренутка. Затим вратите фајлове и базу података из бацкупа, проверите интегритет, ресетујте лозинке и тек онда поново пустите сајт у рад.
Како се проблем препознаје
- Сајт приказује грешку 500, белу страницу или поруку о грешци базе података
- На сајту се појављују непознати линкови, рекламе или странице које нисте направили
- Појављују се нови администраторски налози или непознати фајлови у директоријуму
- Google приказује упозорење о опасном сајту или сајт је уклоњен из индекса
- Хостинг је суспендовао налог због сумњиве активности или прекорачења ресурса
Најчешћи узроци
Компромитована администраторска лозинка
Слаба или поново коришћена лозинка омогућава нападачу да се пријави као администратор и мења садржај или инсталира злонамерни код.
Застарели додатак или тема
Рањиви додаци и теме (нарочито они који нису ажурирани) најчешћи су улаз за нападе на WordPress и сличне системе.
Грешка у конфигурацији или ажурирању
Неуспешно ажурирање, погрешно измењен фајл или конфликт додатака може оборити сајт и без напада.
Проблеми на хостингу
Пад сервера, базе података или прекорачење ресурса могу изазвати недоступност сајта, а да сајт није хакован.
Злонамерни код на рачунару
Ако се на сајт пријављујете са зараженог рачунара, акредитиви могу бити украдени и сајт компромитован.
Решење корак по корак
- 1
Изолујте сајт и сачувајте доказе
Не бришите фајлове и не радите реинсталацију. Ако је сајт хакован, пребаците га у режим одржавања или привремено искључите јавни приступ. Сачувајте копију тренутног стања (фајлове и базу) за анализу, а затим што пре промените приступне податке (FTP, база, администраторски налог).
- 2
Утврдите време инцидента
Прегледајте приступни лог (access лог) и лог грешака (еррор лог) на хостингу (најчешће у контролном панелу, нпр. cPanel или Plesk, у одељку за логове или статистику, или у директоријуму за логове који вам хостинг наведе). Забележите датум и време када су се појавиле сумњиве активности или грешке. То је кључно да бисте изабрали резервну копију насталу пре тог тренутка.
- 3
Пронађите одговарајућу резервну копију
У хостинг панелу потражите секцију за резервне копије (нпр.
BackupилиBackup Wizard). Ако хостинг прави аутоматске дневне backup-е, изаберите онај од пре инцидента. Ако немате хостинг backup, проверите да ли имате сопствену копију (plugin за backup, ручни извоз базе и фајлова). - 4
Вратите фајлове сајта
Преко FTP или управљача фајловима хостинга преименујте тренутни директоријум сајта (нпр.
public_htmlуpublic_html_old) и отпакујте архиву резервне копије. Не бришите стари директоријум док не проверите да све ради. Водите рачуна да не прегазите конфигурационе фајлове ако нису део бацкупа. Ако је могуће, прво вратите сајт на локално развојно окружење ради провере. - 5
Вратите базу података
У панелу базе података (нпр. phpMyAdmin) направите нову базу или, ако користите постојећу, прво направите њен извоз. Затим, ако је потребно, обришите постојеће табеле и увезите
.sqlфајл из резервне копије. Ако се префикс табела разликује, прилагодите конфигурацију сајта. Проверите да су све табеле увезене без грешака. - 6
Проверите интегритет и уклоните злонамерни код
Упоредите фајлове сајта са оригиналном верзијом (нпр. поновним преузимањем WordPress језгра и тема). Прегледајте
wp-config.php,.htaccessи директоријум за уплоадс на сумњиве фајлове. Ако пронађете непознате фајлове или код, изолујте их (преименујте или померите ван јавног директоријума) и забележите путање. - 7
Ресетујте лозинке и кључеве
Промените лозинку за хостинг panel, FTP, базу података и све администраторске налоге на сајту. У WordPressu замените
SALTкључеве уwp-config.phpновим вредностима (нпр. помоћу генератора наapi.wordpress.org/secret-key/1.1/salt/). Уклоните непознате кориснике; промена SALT кључева ће одјавити све активне сесије. - 8
Ажурирајте све и поново пустите сајт
Ажурирајте језгро, теме и додатке на најновије верзије, уклоните непотребне додатке и теме. Проверите да ли сајт ради исправно, па га вратите у јавни режим. Пратите логове наредних 24 сата.
- 9
Пријавите проблем и очистите репутацију
Ако је сајт био на Google листи опасних сајтова, поднесите захтев за поновну проверу у Google Search Console. Ако је хостинг суспендовао налог, обратите се подршци са објашњењем шта сте урадили. Проверите да ли су мејлови компромитовани и обавестите кориснике ако је било цурења података.
Ако ништа не помогне: напредна провера и изолација
Ако се проблем враћа и после враћања из бацкупа, могуће је да је злонамерни код остао у бази (нпр. у опцијама, постовима или корисницима) или у фајловима изван стандардног директоријума. Тада урадите следеће: направите потпуно нову инсталацију на чистом хостингу, увезите само садржај (постове, странице, медије) из проверене копије, а теме и додатке инсталирајте из званичних извора. Обавезно скенирајте рачунар из ког се пријављујете. Ако је сајт био компромитован дуже време, обратите се специјализованој служби за форензику или хостинг подршци која може да прегледа логове на нивоу сервера.
Како да спречите да се понови
- Редовно правите резервне копије (фајлови и база) и чувајте их ван хостинга, најмање 30 дана уназад.
- Ажурирајте језгро, теме и додатке одмах, и уклоните све што не користите.
- Користите јаке, јединствене лозинке и двофакторску аутентификацију за администраторе и хостинг panel.
- Пратите логове и поставите обавештења о неуспешним пријавама и променама фајлова.
Када је боље позвати стручњака
Ако сајт садржи осетљиве податке корисника, ако је био компромитован дуже време или ако се проблем понавља и после више покушаја враћања, обратите се IT стручњаку или специјализованој служби за безбедност сајта.
Израда сајтова · Брзи, SEO оптимизовани сајтови на више језикаЧеста питања
Колико често треба да правим резервне копије сајта?
За сајтове који се често мењају, препоручује се дневна аутоматска резервна копија, а ручна пре сваке веће измене (ажурирање, инсталација додатка). Чувајте најмање недељу дневних и неколико месечних копија.
Да ли могу да вратим само базу података ако је сајт хакован?
Понекад је довољно вратити базу ако је злонамерни код само у њој, али често су измењени и фајлови. Најсигурније је вратити и фајлове и базу из исте резервне копије, па затим проверити интегритет.
Шта ако немам резервну копију, а сајт је пао?
Обратите се хостинг подршци и питајте да ли они чувају backup-е. Ако не, преостаје ручна санација или израда новог сајта. Зато је редован backup кључан.