Коли WordPress сайт зламують, власник часто бачить уже наслідки: редиректи на сторонні ресурси, невідомі сторінки в Google, підозрілі файли, спам, блокування хостингом або попередження про небезпечний сайт.
Але справжня причина може бути значно менш помітною — один вразливий плагін. Причому недостатньо просто видалити знайдений вірус. Якщо не визначити плагін або іншу точку входу, сайт можуть заразити повторно.
Розберемо, як перевірити WordPress після злому, знайти можливу вразливість у плагіні та правильно відновити сайт.
Чому плагіни стають точкою входу
WordPress дозволяє розширювати функціональність сайту за допомогою плагінів. Саме це робить CMS зручною, але кожен додатковий компонент також збільшує кількість коду, який потрібно підтримувати та оновлювати.
Ризик особливо зростає, якщо на сайті є:
- плагіни, які давно не оновлювалися;
- розширення, підтримка яких припинена;
- піратські або “nulled” версії платних плагінів;
- старі плагіни, які вже не використовуються, але залишаються встановленими;
- власні або маловідомі розширення без регулярного аудиту;
- несумісні версії WordPress, PHP і плагінів.
При цьому зловмиснику не обов’язково вручну шукати конкретно ваш сайт. Значна частина атак автоматизована: боти сканують велику кількість сайтів у пошуку відомих слабких місць.
Як зрозуміти, що сайт могли зламати через плагін
Однозначно визначити причину лише за зовнішніми симптомами складно. Але є кілька ситуацій, коли плагін потрібно перевіряти одним із перших.
- проблема з’явилася після встановлення або оновлення конкретного плагіна;
- плагін давно не отримував оновлень;
- розробник більше не підтримує розширення;
- у файлах плагіна з’явилися незрозумілі PHP-файли;
- у логах видно підозрілі запити до файлів конкретного плагіна;
- на сайті є розширення невідомого походження;
- після очищення зараження з’являється повторно.
Особливо підозрілою є ситуація, коли сайт очищали вже кілька разів, але шкідливий код повертається. Це означає, що точка входу, ймовірно, залишилась відкритою.
Перший крок — не видаляти все навмання
Якщо сайт зламаний, бажання одразу видалити підозрілий плагін зрозуміле. Але для діагностики краще спочатку зафіксувати поточний стан.
Перед очищенням варто:
- створити повну резервну копію файлів;
- експортувати базу даних;
- зберегти доступні серверні логи;
- зафіксувати список встановлених плагінів та їх версії;
- перевірити список адміністраторів WordPress;
- зафіксувати час, коли вперше помітили проблему.
Ці дані можуть допомогти зрозуміти, як саме відбулося зараження.
Перевірте список плагінів
Почати варто з простої інвентаризації.
Для кожного плагіна потрібно зрозуміти:
- чи він дійсно використовується;
- коли його востаннє оновлювали;
- чи є новіша версія;
- чи підтримує його розробник;
- звідки він був встановлений;
- чи не залишився він від попереднього розробника або старої версії сайту.
Непотрібний плагін краще не просто деактивувати, а після перевірки повністю видалити. Неактивне розширення все одно залишається у файловій системі.
Перевірте дату зміни файлів
Один із корисних напрямків діагностики — подивитися, які файли змінювалися приблизно в момент зараження.
Підозру можуть викликати:
- нові PHP-файли в папці плагіна;
- зміни основних файлів розширення без оновлення;
- файли з випадковими назвами;
- PHP-файли в папці uploads;
- незрозумілі зміни functions.php;
- сторонній код у wp-config.php або .htaccess.
Але дата зміни сама по собі не є доказом. Її потрібно оцінювати разом із логами та вмістом файлів.
Перевірте серверні логи
Якщо хостинг зберігає access logs та error logs, вони можуть дати дуже корисну інформацію.
У логах варто шукати:
- велику кількість запитів до одного PHP-файла;
- незвичайні POST-запити;
- звернення до файлів конкретного плагіна;
- запити з підозрілими параметрами;
- момент першої появи невідомих файлів;
- серію запитів перед різким ростом навантаження.
Саме тут якість хостингу має велике значення. Якщо підтримка може допомогти знайти потрібний період у логах, визначити причину значно простіше.
Перевірте користувачів WordPress
Після отримання доступу до сайту зловмисник може створити нового адміністратора, щоб повернутися пізніше навіть після очищення файлів.
Перевірте:
- усіх користувачів із роллю Administrator;
- дату появи незнайомих облікових записів;
- підозрілі email-адреси;
- користувачів, яким більше не потрібен доступ.
Невідомі акаунти потрібно видалити, але тільки після того, як ви переконаєтесь, що вони не належать розробнику або співробітнику.
Плагін може бути лише одним етапом атаки
Навіть якщо вдалося знайти вразливий плагін, після злому шкідливий код уже міг поширитися по інших частинах сайту.
Тому перевірити потрібно не тільки папку проблемного розширення.
Шкідливий код може залишатися:
- у темі;
- у папці uploads;
- в інших плагінах;
- у wp-config.php;
- у .htaccess;
- у базі даних;
- у cron-завданнях;
- у додаткових користувачах.
Саме тому схема “видалили один плагін — проблема вирішена” часто не працює.
Що робити з уразливим плагіном
Рішення залежить від ситуації.
Є безпечне оновлення
Якщо розробник виправив проблему, після резервної копії та очищення сайту потрібно перейти на актуальну версію.
Плагін більше не підтримується
Краще знайти підтримувану альтернативу. Залишати критично важливий функціонал на покинутому розширенні ризиковано.
Плагін не потрібен
Його потрібно повністю видалити.
Це кастомний плагін
Потрібна перевірка коду розробником. Просте перевстановлення тут не вирішить проблему.
Чому відновлення з бекапу може не допомогти
Бекап — важлива частина відновлення, але він не є автоматичним лікуванням.
Наприклад:
- уразливий плагін встановили кілька місяців тому;
- сайт зламали два тижні тому;
- власник помітив проблему сьогодні;
- відновив копію за вчора;
- уразливий плагін залишився;
- сайт заражається повторно.
Тому потрібно не просто знайти чисту копію, а закрити саму точку входу.
Що потрібно зробити після очищення
Після видалення шкідливого коду і проблемного плагіна необхідно:
- оновити WordPress;
- оновити тему;
- оновити всі плагіни;
- видалити непотрібні розширення;
- змінити паролі адміністраторів;
- змінити FTP/SFTP-доступи;
- змінити пароль до хостингу;
- за потреби змінити пароль до бази даних;
- перевірити адміністраторів;
- переглянути cron-завдання;
- повторно просканувати файли.
Детальний алгоритм відновлення ми розбирали у статті Як відновити WordPress після злому без втрати даних.
Як зменшити ризик повторного злому через плагін
Повністю виключити ризик неможливо, але його можна суттєво знизити.
- встановлюйте тільки потрібні плагіни;
- використовуйте розширення з активною підтримкою;
- регулярно встановлюйте оновлення;
- не використовуйте nulled-версії;
- видаляйте старі й непотрібні плагіни;
- робіть резервні копії перед оновленнями;
- використовуйте унікальні складні паролі;
- обмежуйте кількість адміністраторів;
- контролюйте серверні логи;
- регулярно перевіряйте сайт на підозрілі зміни.
Чому хостинг важливий після злому
Хостинг не може гарантувати, що вразливого плагіна ніколи не буде. Але від інфраструктури та підтримки залежить, наскільки швидко вдасться знайти проблему й відновити сайт.
Корисні можливості:
- регулярні резервні копії;
- доступ до server logs;
- ізоляція сайтів;
- контроль підозрілих файлів;
- можливість швидкого відновлення;
- підтримка, яка допомагає з діагностикою.
Особливо важлива ізоляція, якщо на одному акаунті знаходиться кілька сайтів. Зараження одного проекту не повинно автоматично створювати проблему для всіх інших.
Коли після злому варто змінити хостинг
Сам факт злому не означає, що винен хостинг. Але зміну провайдера варто розглянути, якщо:
- підтримка не надає потрібні логи;
- немає нормальних резервних копій;
- сусідні сайти на акаунті заражають один одного;
- сайт після очищення регулярно заражається повторно;
- хостинг просто блокує сайт без допомоги в діагностиці;
- відновлення кожного разу перетворюється на окрему проблему.
Якщо потрібен перенос, Hostnova може перенести сайт на новий хостинг при замовленні тарифу безкоштовно.
Чек-лист: WordPress зламали через плагін
- не видаляти все навмання;
- зробити резервну копію файлів і бази;
- зберегти логи;
- перевірити список і версії плагінів;
- перевірити дату зміни файлів;
- перевірити access/error logs;
- перевірити адміністраторів WordPress;
- перевірити всю файлову систему, а не лише один плагін;
- перевірити базу даних;
- видалити або оновити вразливий компонент;
- змінити всі важливі доступи;
- повторно перевірити сайт після очищення.
Висновок
Якщо WordPress зламали через плагін, основне завдання — не просто прибрати видимий вірус, а знайти точку входу. Інакше сайт можна чистити багато разів, але зараження буде повертатися.
Перевірка версій плагінів, серверних логів, змінених файлів, бази даних та адміністраторів дозволяє значно точніше зрозуміти причину проблеми.
А після очищення сайт потрібно привести до нормального стану: оновити компоненти, прибрати непотрібні розширення, змінити доступи та налаштувати регулярні резервні копії.
Якщо Google уже попереджає користувачів про загрозу, додатково перегляньте матеріал Google показує “сайт може бути небезпечним”: що робити власнику бізнесу.
Потрібен хостинг для WordPress із резервними копіями та реальною підтримкою?
Переглянути тарифи Hostnova:
https://www.hostnova.eu/pricing/
При замовленні хостингу перенесення вашого сайту з іншого провайдера виконаємо безкоштовно.
