Ваш сайт ўзламалі? 5 неадкладных крокаў па аварыйным аднаўленні і абароне

Калі ваш сайт ўзламалі, першае, што трэба зрабіць — не паддавацца паніцы, а абмежаваць шкоду, ізаляваць сайт, абнавіць усе доступы, вярнуцца да чыстай рэзервовай копіі, выдаліць шкодны код і ўключыць пастаянныя меры бяспекі. У крытычныя першыя 24 гадзіны ваша мэта — перапыніць доступ зламысніка, абараніць наведвальнікаў і дадзеныя, не даць пошукавым сістэмам атрымаць няправільную інфармацыю пра сайт і вярнуць яго ў эфір у пацверджаным, бяспечным стане.

Узлам сайта — гэта не толькі чужая картынка на галоўнай старонцы. Зламыснікі часта дзейнічаюць незаўважна: ствараюць спам-старонкі, змяняюць формы аплаты, дадаюць адміністратараў, пакідаюць сакрэтныя перанакіроўкі ў базе, выкарыстоўваюць ваш сервер для рассылкі пошты. Таму аднаўленне — гэта не проста выдаленне файлаў. Неабходна сістэмна захоўваць доказы, пацвярджаць чысціню і прадухіляць паўтор.

У гэтым гайдзе мы разглядаем 5 першых аварыйных крокаў па аднаўленні сайта пасля ўзламу — простым, але практычным мовай. Прынцыпы актуальныя для WordPress, індывідуальных CMS, інтэрнэт-крам і карпаратыўных сайтаў: ізаляваць, абмежаваць доступ, вярнуцца да чыстай копіі, пацвердзіць і ўмацаваць.

Сімптомы ўзламу сайта

Узлам не заўсёды пачынаецца з відавочнай памылкі. Некаторыя атакі працягваюцца тыднямі незаўважна. Калі вы заўважылі хоць адзін з наступных сімптомаў, разглядайце гэта як інцыдэнт бяспекі, а не як звычайную памылку:

• У выніках Google побач з вашым сайтам з’явіліся загалоўкі пра азартныя гульні, лекі, криптавалюту або дарослыя тэмы.
• Браўзер выдае папярэджанне пра шкодны сайт, фішынг або небяспечнае злучэнне.
• Не атрымліваецца ўвайсці ў панэль адміністратара, ці бачны невядомыя карыстальнікі з правамі адміністратара.
• Рэзкі рост выкарыстання CPU, RAM, дыска або рассылкі e-mail на серверы.
• Незвычайныя змены ў .htaccess, index.php, wp-config.php або файлах тэмы.
• Аўтаматычнае перанакіраванне наведвальнікаў на іншыя дамены.
• Масавая рассылка e-mail з вашага хостынгу без вашага ведама.
• Выключэнне бяспековых плагінаў або выдаленне лог-файлаў.

Напрыклад, калі ваш блог звычайна атрымлівае 2 000 наведванняў у дзень, а раптам — 30 000 запытаў, гэта звычайна не рост аўдыторыі, а актыўнасць ботаў, брутфорс або шкодная скрыпта. Калі тэма, якая займала 10 МБ, за пару дзён стала 80 МБ — гэта прыкмета “backdoor” файлаў.

Першыя 30 хвілін: не панікаваць, а фіксаваць і кантраляваць

Не спяшайцеся ўсё выдаляць. Случайнае выдаленне файлаў можа схаваць следы атакі, ускладніць чыстку і прывесці да памылковага аднаўлення з няправільнай копіі. Спачатку зафіксуйце стан: дату, час, папярэджанні, URL-ы, падазроных карыстальнікаў, апошнія абнаўленні і хостынг-логі. Гэта дапаможа тэхнічнай падтрымцы і спецыялісту па бяспецы хутка паставіць дыягназ.

Асабліва важна весці журнал у інтэрнэт-крамах, сайтах з рэгістрацыяй або апрацоўкай персанальных дадзеных. Фіксуйце, якія дадзеныя маглі быць закрануты, калі пачалася атака, з якіх IP быў доступ. Калі ваш сайт на Hostragons, для падтрымкі важна паведаміць дамен, папку, час і памылкі — гэта скарачае час рэакцыі. Больш пра выбар хостынгу чытайце тут: Пакеты бяспечнага вэб-хостынгу.

Крок 1: Ізалюем сайт і абмяжоўваем шкоду

Першы неадкладны крок — прадухіліць далейшую шкоду ад зламыснікаў і шкоднага кода. Гэта як перакрыць газ да тушэння пажару. Сайт не абавязкова цалкам закрываць; важна абараніць наведвальнікаў ад фішынгу, шкодных файлаў і падмены аплаты.

Уключыце рэжым абслугоўвання або часова абмяжуйце доступ

У WordPress можна ўключыць старонку абслугоўвання, у індывідуальных CMS — выдаваць часовы адказ 503 або дапускаць толькі вызначаныя IP-адрасы. Код 503 паведамляе пошукавікам, што сайт недаступны часова — гэта лепш, чым 404 або пустая старонка. Калі ваш сайт распаўсюджвае вірусы або фішынг, лепш цалкам абмежаваць доступ.

• Панэль адміністратара не павінна быць адкрыта для ўсіх — выкарыстоўвайце абмежаванне па IP.
• Тымчасова адключыце выкананне PHP у папках для загрузкі файлаў.
• Калі адбываецца рассылка e-mail, спыніце SMTP доступ.
• Калі пашкоджана старонка аплаты — дэактывуйце інтэграцыю аплаты.

Захоўвайце логі і стан файлаў

Ізаляцыя павінна ўключаць захаванне лог-файлаў доступу, памылак, FTP і дзеянняў у панелі кіравання. Часцей за ўсё зламыснік пранікае праз стары плагін, слабы FTP-пароль, уцечку адміністратара або памылку правоў. Без логаў цяжка знайсці першапрычыну — і пасля “чысткі” сайт можа быць ўзламаны нанова.

Загружайце файлы на лакальны камп’ютар для аналізу ў бяспечным асяроддзі, але працуйце толькі на камп’ютары з антывірусам. Калі ў хостынгу ёсць аўтаматычнае рэзервовае капіраванне, захоўвайце копію інцыдэнта толькі для аналізу, а не як чыстую копію. Для стратэгіі бэкапаў глядзіце: рашэнні хостынгу з аўтаматычным рэзервным капіраваннем.

Крок 2: Абнавіце ўсе доступы, паролі і ключы

Большасць уладальнікаў мяняюць толькі пароль адміністратара. Але зламыснік можа атрымаць доступ праз FTP, базу, панэль хостынгу, SSH, e-mail, API або інтэграцыі. Другі аварыйны крок — поўнае абнаўленне ўсіх дакументаў і ключоў.

Якія паролі трэба мяняць?

• Пароль да хостынг-панэлі.
• FTP, SFTP і SSH паролі.
• Паролі карыстальніка базы дадзеных і параметры доступу.
• Паролі CMS адміністратараў і рэдактараў.
• Паролі e-mail, асабліва тых, што працуюць з даменам.
• API ключы, токены аплаты, доступы да CDN і DNS.
• Паролі Git, deployment, аўтаматызацыі і бэкапаў.

Мацны пароль — не менш за 16 знакаў, унікальны і непрадказальны. Не выкарыстоўвайце адны і тыя ж паролі на розных платформах — гэта рызыка пры ўцечцы дадзеных. Ва ўсіх панэлях уключайце двухфактарную аўтарызацыю. Для адміністратараў 2FA значна зніжае рызыку брутфорса.

Выдаляйце падазроных карыстальнікаў і закрывайце сесіі

Калі ў CMS ёсць невядомыя карыстальнікі, проста дэактывацыя недастатковая: зафіксуйце іх ролю, дату стварэння і дзеянні, затым выдаліце. У WordPress можна абнавіць ключы бяспекі для завершання сесій; у індывідуальных CMS — вычысціць табліцу сесій. У інтэрнэт-крамах перш за ўсё правярайце персанал з правамі кіравання, а не кліентаў.

Прыклад: зламыснік атрымаў доступ да старога рэдактара і праз плагін загрузкі файлаў усталяваў web shell. Калі вы мяняеце толькі пароль галоўнага адміністратара, зламыснік застаецца ў сістэме. Праверце матрыцу доступу, зніміце лішнія правы, выдаліце непатрэбныя ролі. Яшчэ адзін важны момант — бяспека дамена, DNS і SSL: чытайце тут кіраванне даменамі і бяспека DNS і Рашэнні сертыфікатаў SSL.

Крок 3: Вяртанне да чыстай копіі або каранцінаванне заражаных абласцей

Самы хуткі і бяспечны спосаб — аднавіць сайт з пацверджанай чыстай копіі да атакі. Але важна, каб копія сапраўды была чыстай: учорашні бэкап не падыходзіць, калі атака пачалася тыдзень таму. Аналізуйце дату бэкапа, логі і час зменаў файлаў.

Як выбраць чыстую копію?

Вызначайце, калі з’явіліся першыя сімптомы — напрыклад, калі ў Google Search Console папярэджанне было 12 сакавіка, а ў логах серверу падазроныя POST былі ўжо 5 сакавіка, то копія ад 12 сакавіка не падыходзіць. Аналізуйце бэкапы да 4 сакавіка і сканіруйце іх на шкодны код.

• Дата бэкапа павінна быць да пачатку атакі.
• У копіі не павінна быць невядомых адміністратараў.
• Праверце цэласнасць файлаў: базавая CMS павінна супадаць з арыгінальнай версіяй.
• У базе шукайце скрыты iframe, base64-код, падазроныя скрыпты і спам.
• Пасля аднаўлення абнавіце ўсе праграмныя кампаненты.

Што рабіць, калі няма чыстай копіі?

Калі бэкапа няма, працэс больш складанны. Спачатку перанясіце сайт у staging/часовую зону. Каранцініруйце падазроныя файлы, пераўсталюйце асноўныя CMS-файлы з афіцыйных крыніц, замяніце тэмы і плагіны на чыстыя. У папках загрузкі правярайце на .php, .phtml, .phar — там звычайна хаваюцца шкодныя скрыпты.

Чысціня базы не менш важная за файлы. Спам і шкодныя перанакіроўкі могуць быць у наладах сайта, віджэтах, параметрах тэм ці ў артыкулах. Для пошуку ў вялікай базе шукайце: script, iframe, eval, atob, base64_decode, gzinflate, shell_exec, document.location. Але не кожны base64 — шкодны; памылковае выдаленне можа зламаць сайт, таму перад працай абавязкова зрабіце копію базы.

Крок 4: Чыстка шкоднага кода, абнаўленне і ліквідацыя ўразлівасцяў

Проста аднавіць сайт недастаткова — калі не знайсці шлях пранікнення, зламыснік вернецца. Чацвёрты крок — поўная чыстка файлаў і базы, закрыццё ўразлівасцяў і выпраўленне памылак канфігурацыі.

Чэк-ліст для файлавай сістэмы

• Пералічыце файлы па апошняй змяненні і праверце падазроныя змены.
• Параўнайце базавую CMS з афіцыйнай версіяй.
• Праверце папкі загрузкі на выкананыя файлы.
• Паглядзіце схаваныя файлы (.user.ini, .htaccess) — яны могуць выкарыстоўвацца для перанакіравання.
• Звузьце правы на файлы: стандарт — 644 для файлаў, 755 для папак.
• Выдаліце старыя тэмы, плагіны, бэкапы і тэставыя папкі.

У WordPress выдаліце невыкарыстоўваемыя плагіны — проста дэактывацыя недастаткова. Стары slider, форма або file manager, нават калі неактыўны, усё роўна захоўвае файлы і можа быць выкарыстаны. Нелицэнзійныя тэмы і плагіны часта ўтрымліваюць backdoor-код: эканомія тут — рызыка для брэнда і дадзеных кліентаў.

Парадак абнаўлення

Сначала абнавіце базавую сістэму, потым тэму, затым плагіны. Калі PHP састарэлы, пасля тэставання пераходзьце на падтрымліваемую версію. У 2026 сайты з старым PHP — у зоне рызыкі, бо не атрымліваюць абнаўлення бяспекі. На хостынгу важна мець сучасны PHP, ізаляваную архітэктуру, рэгулярныя бэкапы і падтрымку firewall. Падрабязней тут: Hostragons веб-хостынг.

Пераканайцеся, што SSL-сертыфікат актуальны. SSL не абараняе ад ўзламу, але шыфруе дадзеныя і зніжае рызыку падмены. Для старонак уваходу, аплаты і рэгістрацыі SSL абавязковы. Падрабязнасці: Купіць сертыфікат SSL.

Крок 5: Пацвярджэнне чысціня, маніторынг і пастаянная абарона

Пяты крок — пацверджанне, што сайт сапраўды чысты, і прадухіленне паўтору атакі. Калі гэты этап прапусціць, праз некалькі дзён праблемы могуць вярнуцца. Пацверджанне павінна ахопліваць як тэхнічны, так і працоўны працэс.

Кантроль перад запускам

• Праверце галоўную, старонку ўваходу, аплаты і папулярныя URL на розных прыладах.
• Праверце бяспеку і ручныя меры ў Google Search Console.
• Паглядзіце sitemap і robots.txt.
• Аналізуйце логі на паўторныя 404, 500, POST і спробу ўваходу.
• Праверце рэпутацыю e-mail — калі ў чорным спісе, пачніце працэс аднаўлення.
• Пратэстуйце формы аплаты, кантакту і загрузкі файлаў.

Калі Google або браўзеры пазначылі ваш сайт як шкодны, пасля чысткі адправіце запыт на паўторную ацэнку. Пакажыце, што было выдалена, якія ўразлівасці закрыты і якія меры прыняты. Не пішыце агульна — канкрэтна: стары file manager выдалены, усе паролі абноўлены, PHP у папцы загрузкі адключаны і г.д.

Пастаянная абарона: што рэкамендуецца

Бяспека — гэта не аднаразовая задача, а пастаянны працэс. Нават для невялікага карпаратыўнага сайта варта завесці месячны план абслугоўвання — гэта істотна зніжае рызыку ўзламу. Мінімум — штотыднёвы кантроль абнаўленняў, штодзённы бэкап, мацныя паролі і маніторынг логаў. Для сайтаў з высокім трафікам рэкамендуецца WAF, CDN, ахова ад ботаў і знешняе сканаванне.

У карпаратыўных сайтах важна задакументаваць адказнасць: хто абнаўляе, хто кантралюе бэкапы, каму паведамляць пра інцыдэнт, у якіх выпадках сайт пераходзіць у рэжым абслугоўвання? Адказы павінны быць загадзя, а не ў момант атакі — гэта пазбягае панікі і дазваляе дзейнічаць па плане.

Дадатковыя крокі для SEO, рэпутацыі і даверу карыстальнікаў

Нават пасля тэхнічнай чысткі сайт патрабуе дадатковых SEO-мер. Зламыснікі часта ствараюць тысячы спам-URL. Калі яны трапілі ў індэкс пошукавіка, пасля чысткі трэба вызначыць — 404, 410 або правільнае перанакіраванне. Перанакіроўваць усе спам-URL на галоўную — не заўсёды добра: Google можа пагоршыць ацэнку.

У Search Console праверце індэксаваныя старонкі, праблемы бяспекі, ручныя меры і sitemap. Пасля выдалення шкоднага кантэнту можна абнавіць sitemap — але толькі калі спам-старонкі сапраўды выдалены. Калі ў выніках пошуку бачныя шкодныя загалоўкі, папрасіце Google пераіндэксаваць чыстыя старонкі.

Для даверу карыстальнікаў важна адкрыта паведамляць пра інцыдэнт, але без панікі. Калі закрануты дадзеныя карыстальнікаў, аплатныя або асабістыя, улічвайце юрыдычныя патрабаванні і працэсы аховы дадзеных. Для простых прэзентацыйных сайтаў гэта менш актуальна, але для e-commerce і рэгістрацыйных сістэм — неабходна прафесійна ацаніць маштаб.

Шырока распаўсюджаныя памылкі, якіх трэба пазбягаць

Некаторыя памылкі ў аварыйным аднаўленні прыводзяць да ўзмоцненага шкоды. Галоўная — лічыць праблему вырашанай пасля запуску сайта, хаця backdoor можа застацца. Другая — аднаўляць з бэкапа без праверкі — заражаная копія верне шкодны код.

• Не рабіць бэкап перад чысткай.
• Выдаляць толькі відавочныя шкодныя файлы, не шукаючы першапрычыну.
• Выкарыстоўваць старыя плагіны або тэмы.
• Даць усім адміністратарам поўныя правы без неабходнасці.
• Выдаляць логі або перапісваць іх без аналізу.
• Лічыць сайт цалкам бяспечным толькі з-за SSL.
• Сцягваць тэмы і плагіны з неафіцыйных крыніц.

Асабліва небяспечна выстаўляць правы 777 — гэта лёгка для зламысніка, але вельмі рызыкоўна для сайта. Давайце мінімальна неабходныя правы: запіс толькі там, дзе сапраўды патрэбна.

Кароткі аварыйны план

Для паспяховага аднаўлення дзейнічайце па парадку: ізалюем сайт, абнаўляем доступы, аднаўляем з чыстай копіі або робім кантраляваную чыстку, закрываем уразлівасці і пацвярджаем чысціню перад запускам. Так вы зніжаеце тэхнічныя рызыкі, страты ў SEO і рэпутацыі.

На Hostragons — бяспечная хостынг-архітэктура, SSL, кіраванне даменам і бэкап-рашэнні ўмацоўваюць устойлівасць вашага сайта. Калі трэба прааналізаваць хостынг, пачніце тут: Hostragons пакеты хостынгу і Праверка дамена і кіраванне даменамі. Не забывайце: галоўная мэта — баланс хуткасці, бяспекі, бэкапу і падтрымкі.

Часта задаваемыя пытанні

Ці трэба адразу здымаць сайт пры ўзламе?

Калі сайт распаўсюджвае шкоднае ПЗ, перанакіроўвае карыстальнікаў або падмяняе формы аплаты — доступ трэба тэрмінова абмежаваць. У больш лёгкіх выпадках выкарыстоўвайце рэжым абслугоўвання (503) або абмежаванне па IP. Галоўнае — абараніць наведвальніка і паведаміць пошукавікам, што гэта часова.

Ці заўсёды дастаткова аднавіць з чыстай копіі?

Не. Чыстая копія — хуткае аднаўленне, але калі не знайсці шлях ўзламу, сайт будзе ўзламаны нанова. Пасля бэкапа абнавіце паролі, зрабіце абнаўленні, праверце правы і ліквідуйце ўразлівасці або памылкі канфігурацыі.

Ці страчвае ўзламаны сайт пазіцыі ў SEO?

Калі інцыдэнт кароткі і добра кіруецца — пастаянных страт у SEO можа не быць. Але калі спам-старонкі трапляюць у індэкс, Google выдае папярэджанне або сайт доўга недаступны — пазіцыі могуць пагоршыцца. Пасля чысткі абавязкова правядзіце кантроль у Search Console, запыты на пераацэнку і выдаленне спам-URL.

Чаму мой WordPress сайт узламваюць зноў і зноў?

Прычыны: backdoor-файлы, старыя плагіны, слабыя паролі, лішнія адміністратараў, няправільныя правы, заражаныя бэкапы. Не абмяжуйцеся выдаленнем відавочнага шкоднага кода — правядзіце аналіз першапрычыны і абнавіце ўсе доступы.

Ці ўплывае выбар хостынгу на бяспеку сайта?

Так. Ізаляваная архітэктура, сучасны PHP, рэгулярны бэкап, firewall, сканаванне на malware, хуткая падтрымка і SSL — усё гэта павышае бяспеку. Бяспечны хостынг не гарантуе 100% абароны, але зніжае рызыкі і паскарае аднаўленне.