Аудит безпеки WordPress після видалення вірусів: повний чекліст

Видалення шкідливого коду з WordPress не означає, що сайт автоматично став безпечним. Вірус міг залишити прихований обліковий запис, змінити системні файли, додати бекдор або викрасти паролі. Якщо не усунути першопричину зараження, повторна атака може відбутися навіть після успішного очищення.

Перед будь-якими змінами бажано створити резервні копії файлів і бази даних та зберегти їх окремо від сервера. Копія зараженого сайту не є безпечною для негайного відновлення, але може знадобитися для аналізу. Видалення файлів, записів у базі або користувачів без попереднього резервування може призвести до втрати даних і працездатності сайту.

Нижче наведено послідовність перевірки, яку варто пройти після очищення WordPress.

Користувачі й паролі

Починати аудит слід із контролю доступу. Якщо зловмисник отримав пароль адміністратора, саме очищення файлів не перекриє йому шлях назад.

• Перевірте список користувачів WordPress і видаліть невідомі облікові записи.
• Перегляньте ролі користувачів: звичайний редактор або підозрілий обліковий запис не повинен мати права адміністратора без обґрунтованої причини.
• Змініть паролі всіх адміністраторів, редакторів, користувачів хостингу, FTP або SFTP, SSH, панелі керування та бази даних.
• Використовуйте унікальні довгі паролі, які не повторюються на інших сервісах.
• Увімкніть двофакторну автентифікацію для адміністративних облікових записів, якщо її підтримує сайт або плагін безпеки.
• Перевірте електронні адреси адміністраторів і налаштування відновлення пароля.
• Переконайтеся, що в конфігурації або коді не залишилися старі API-ключі, токени чи паролі.

Окремо варто перевірити активні сесії та примусово завершити їх після зміни паролів. Якщо зараження було пов’язане з викраденням cookie або токена, проста зміна пароля може бути недостатньою.

Практичні рекомендації щодо пошуку слабких місць описані у матеріалі Як знайти та закрити вразливості на сайті WordPress.

Ядро, теми та плагіни

Заражені файли часто маскуються під легітимні компоненти WordPress або додаються до них після злому. Навіть якщо антивірус видалив очевидний шкідливий код, необхідно перевірити цілісність усієї файлової структури.

• Оновіть ядро WordPress до актуальної стабільної версії, сумісної з сайтом.
• Видаліть теми та плагіни, які не використовуються. Неактивний компонент усе одно може містити вразливість.
• Перевірте джерело встановлених тем і плагінів. Зламані або неліцензійні копії часто містять бекдори.
• Замініть підозрілі компоненти чистими файлами з офіційного джерела або з надійної резервної копії.
• Порівняйте файли ядра з оригінальною версією WordPress та зверніть увагу на несподівані зміни у wp-config.php, .htaccess і файлах теми.
• Перевірте папку wp-content/uploads: PHP-файли там зазвичай не потрібні та можуть бути ознакою бекдора.
• Перегляньте код теми на наявність підозрілих викликів eval, base64_decode, gzinflate, прихованих iframe та перенаправлень.

Не слід бездумно видаляти всі файли, які здаються незнайомими. Частина з них може належати плагінам, кешуванню або серверним налаштуванням. Перед видаленням зробіть копію та перевірте призначення файлу. Якщо зміни вносилися вручну, спочатку зафіксуйте поточний стан, щоб не втратити потрібні налаштування.

Права доступу до файлів

Надмірні права доступу спрощують повторне зараження. Вебсервер не повинен мати можливість без обмежень змінювати всі файли сайту, а сторонні користувачі не повинні отримувати доступ до конфіденційних даних.

• Перевірте власника файлів і групу на сервері. Вони мають відповідати моделі доступу, яку використовує ваш хостинг.
• Для більшості файлів WordPress зазвичай застосовують права 644, а для каталогів — 755, але точні значення залежать від конфігурації сервера.
• Файл wp-config.php потребує особливого захисту, оскільки містить параметри підключення до бази даних.
• Забороніть виконання PHP у каталогах завантажень, якщо це не потрібно конкретному компоненту.
• Перевірте, чи не доступні через браузер резервні копії, архіви, журнали, файли налаштувань або тимчасові дампи.
• Переконайтеся, що індексація службових каталогів вимкнена.
• Не залишайте на сервері файли на кшталт старих архівів, тестових скриптів, резервних копій із розширеннями .zip, .tar, .sql або копіями конфігурації.

Зміна прав доступу без розуміння серверної схеми може спричинити помилки 403, проблеми із завантаженням файлів або зупинку оновлень. Перед масовим редагуванням дозволів створіть резервну копію та перевірте зміни на копії сайту або в погоджене сервісне вікно.

Сервер і база даних

Причина зараження може перебувати не лише у WordPress. Слабкий доступ до хостингу, застаріла версія PHP, небезпечні серверні налаштування або шкідливі записи в базі даних здатні підтримувати атаку після очищення файлів.

• Оновіть PHP до версії, яку підтримують WordPress, тема та плагіни.
• Перевірте облікові записи хостингу, FTP, SFTP, SSH і панелі керування.
• Обмежте доступ до адміністративних служб за IP або через додаткову автентифікацію, якщо це можливо.
• Перегляньте завдання cron на сервері та планувальник WordPress. Підозрілі команди можуть повторно створювати шкідливі файли.
• Перевірте базу даних на невідомих користувачів, змінені параметри, сторонні скрипти в записах, віджетах і метаполях.
• Зверніть увагу на параметри сайту, адресу WordPress та адресу сайту: несанкціоновані зміни можуть спричиняти перенаправлення.
• Переконайтеся, що резервні копії зберігаються поза основним сервером і не доступні за прямим URL.
• Налаштуйте HTTPS і перевірте, чи немає змішаного вмісту або помилок сертифіката.

Перед редагуванням бази даних обов’язково зробіть її дамп. Помилка в SQL-запиті або видалення не того запису може пошкодити меню, налаштування, замовлення чи контент. Масову заміну посилань, очищення таблиць і видалення підозрілих значень краще виконувати після аналізу структури бази та з можливістю відкату.

Журнали та сповіщення

Журнали допомагають зрозуміти, як саме відбулося зараження і чи залишилися спроби доступу після очищення. Без них аудит часто обмежується пошуком уже видимих наслідків.

• Перегляньте журнали входів до WordPress, панелі хостингу, FTP, SSH і бази даних.
• Проаналізуйте помилки вебсервера та PHP: повторювані запити до неіснуючих файлів або незвичні POST-запити можуть бути ознакою сканування чи атаки.
• Перевірте час зміни файлів і зіставте його з підозрілими входами або появою перенаправлень.
• Налаштуйте сповіщення про нових адміністраторів, зміну файлів, невдалі входи та оновлення компонентів.
• Підключіть моніторинг доступності сайту, терміну дії SSL-сертифіката та змін DNS.
• Регулярно перевіряйте сайт зовнішнім сканером, але не сприймайте результат автоматичної перевірки як повний аудит.

Після завершення перевірки сформуйте план подальшого захисту: регулярні резервні копії, своєчасні оновлення, обмеження доступу, двофакторну автентифікацію та періодичний перегляд журналів. Якщо зараження повторюється, сайт перенаправляє відвідувачів, адміністраторський доступ зникає або в базі даних знаходяться незрозумілі зміни, не варто продовжувати експерименти на робочому сайті. Спочатку збережіть копію, обмежте доступ і зверніться до спеціаліста для ізоляції проблеми та детальної діагностики.