Після виявлення злому не варто одразу відновлювати сайт із найновішої доступної копії. Якщо зловмисник мав доступ до файлів або панелі керування протягом тривалого часу, шкідливий код міг потрапити не лише на сайт, а й у резервні архіви. Неправильний вибір копії здатен повернути зараження, прихований доступ або вразливий компонент.
Резервна копія має бути не просто свіжою, а перевіреною. Важливо встановити, коли саме відбулося проникнення, порівняти кілька версій і виконувати відновлення в ізольованому середовищі. Корисно також заздалегідь ознайомитися з матеріалом Резервні копії сайту: чому вони рятують бізнес, щоб оцінити значення різних типів копій для відновлення бізнес-сайту.
Чому найновіша копія може бути заражена
Дата створення архіву не свідчить про його безпеку. Якщо злом стався раніше, ніж було зроблено копію, резерв міг зберегти шкідливі файли, змінені налаштування або сторонні облікові записи.
Зараження може ховатися в:
- файлах теми, плагінів або ядра CMS;
- завантажених зображеннях, документах та інших медіафайлах;
- таблицях бази даних, зокрема в параметрах і записах WordPress;
- файлах конфігурації, правилах перенаправлення та службових скриптах;
- нових користувачах із правами адміністратора.
Особливо ризикованими є автоматичні щоденні копії, якщо вони перезаписують попередню версію. У такому разі кілька послідовних архівів можуть містити один і той самий шкідливий код.
Не відновлюйте копію поверх робочого сайту без попередньої перевірки. Спочатку збережіть поточний стан: файли, базу даних, журнали помилок і доступні логи. Навіть заражені дані можуть допомогти визначити спосіб проникнення.
Дата першого проникнення
Вибір безпечної копії починається з приблизного визначення дати злому. Точний момент не завжди можна встановити, але сукупність ознак допомагає звузити період.
Перевірте:
- час зміни підозрілих файлів у файловій системі;
- логи вебсервера, FTP, SSH, панелі хостингу та WordPress;
- дату появи невідомих адміністраторів;
- сповіщення хостингу, антивіруса або пошукової системи;
- різке зростання навантаження, перенаправлення чи появу стороннього контенту;
- час, коли користувачі або працівники вперше помітили проблему.
Варто враховувати, що дата зміни файлу може бути підроблена або змінитися під час копіювання. Тому її не можна використовувати як єдиний доказ. Якщо ознаки вказують на проникнення кілька тижнів або місяців тому, копії за цей період потрібно вважати потенційно небезпечними до завершення аналізу.
Перевірка кількох версій
Після визначення приблизної дати злому сформуйте список усіх доступних резервів: серверних, хмарних, локальних, створених плагіном або хостинг-провайдером. Не обмежуйтеся одним архівом, адже копії можуть відрізнятися за складом і часом створення.
- Відберіть кілька копій, створених до ймовірного проникнення, а також одну-дві пізніші для порівняння.
- Перевірте цілісність архівів і можливість їх розпакування.
- Порівняйте структуру файлів, версії WordPress, тем і плагінів.
- Перегляньте базу даних на наявність невідомих користувачів, підозрілих параметрів, скриптів і зміненого контенту.
- Перевірте файли антивірусним сканером та інструментами пошуку аномалій.
- Запишіть результати перевірки, щоб не переплутати протестовані та неперевірені копії.
Найкращою зазвичай є найпізніша копія, яка підтверджено передує проникненню та не містить сторонніх змін. Однак інколи доводиться поєднувати чисті файли з однієї версії та актуальні дані з іншої. Таке рішення потребує обережності: несумісність структури бази даних або версій компонентів може спричинити нові помилки.
Не видаляйте старі архіви до завершення відновлення й перевірки сайту. Якщо копія виявиться непридатною, резервні версії можуть бути єдиним джерелом для порівняння або повернення окремих даних.
Чисте середовище для відновлення
Перевіряти та розгортати резервну копію безпечніше не на тому самому зараженому сайті, а в окремому середовищі: на тестовому домені, ізольованому сервері або іншому обліковому записі хостингу. Це зменшує ризик повторного зараження робочого ресурсу й дає змогу спокійно провести діагностику.
Перед відновленням створіть резервну копію поточного стану, навіть якщо сайт уже пошкоджений. Окремо збережіть базу даних, файли та журнали. Пам’ятайте, що будь-яке очищення, видалення або перезаписування може призвести до незворотної втрати даних.
У тестовому середовищі потрібно:
- встановити сумісні версії PHP, CMS, теми та плагінів;
- перевірити файли на сторонній код і невідомі виконувані скрипти;
- переглянути базу даних і облікові записи користувачів;
- перевірити перенаправлення, права доступу та конфігурацію сервера;
- переконатися, що форми, оплата, авторизація та інші критичні функції працюють коректно;
- перевірити сайт у браузері й за допомогою зовнішніх засобів безпеки.
Якщо резерв містить зашифровані файли, приховані скрипти, незрозумілі адміністраторські облікові записи або сайт знову перенаправляє відвідувачів, самостійне розгортання краще зупинити. На цьому етапі потрібен спеціаліст, який зможе дослідити файли, базу даних і журнали без додаткового пошкодження.
Закриття вразливості
Відновлення чистої копії саме по собі не усуває причину злому. Якщо залишити вразливий плагін, застарілу CMS, слабкий пароль або відкритий службовий доступ, сайт можуть зламати повторно.
Після вибору копії та перед поверненням сайту в роботу:
- оновіть WordPress, тему, плагіни та серверне програмне забезпечення до сумісних безпечних версій;
- видаліть непотрібні й сумнівні компоненти;
- змініть паролі адміністратора, хостингу, FTP, SSH, бази даних і поштових скриньок;
- перевірте користувачів та їхні права;
- замініть ключі доступу й сесії, якщо вони могли бути викрадені;
- обмежте доступ до адміністративної панелі та служб керування;
- перевірте права на файли й каталоги;
- налаштуйте регулярні резервні копії з кількома версіями та зберіганням поза сайтом;
- увімкніть моніторинг змін файлів, двофакторну автентифікацію та сповіщення про підозрілу активність.
Якщо невідомо, яким способом відбувся злом, або після відновлення з’являються повторні ознаки зараження, не варто обмежуватися повторним завантаженням іншої копії. Потрібна повна технічна діагностика сайту, сервера та бази даних, а також контрольна перевірка після очищення. Лише після цього можна обґрунтовано визначити, яку резервну версію безпечніше використовувати для подальшої роботи.