Як перевірити сайт на шкідливий код: практичний чек-лист для власника сайту

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

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

Коротка відповідь

Для нормальної перевірки сайту недостатньо запустити один онлайн-сканер. Потрібно перевірити щонайменше п’ять рівнів:

1. зовнішню поведінку сайту;
2. файли на сервері;
3. базу даних;
4. облікові записи та доступи;
5. журнали сервера.

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

Коли перевірка потрібна навіть без очевидних проблем

Проведіть аудит, якщо помітили хоча б один із таких симптомів:

• сайт став повільнішим без видимої причини;
• зросло навантаження CPU;
• з’явилися невідомі файли;
• Google показує незнайомі сторінки вашого домену;
• відвідувачів іноді перекидає на інші сайти;
• із сервера надсилається багато пошти;
• з’явилися нові адміністратори CMS;
• антивірус хостингу повідомив про зараження;
• сайт почав періодично повертати 500 або 502;
• у файлах CMS змінилася дата модифікації без вашої участі.

Перед початком: нічого не видаляйте

Перша реакція після виявлення підозрілого файлу — видалити його. Але це може ускладнити пошук джерела зараження.

Спочатку:

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

Ця інформація допоможе зрозуміти, коли і яким способом сайт був скомпрометований.

Чек-лист №1. Перевірте сайт ззовні

Спочатку подивіться на сайт як звичайний користувач.

Перевірте різні пристрої

Відкрийте сайт:

• з комп’ютера;
• зі смартфона;
• через мобільний інтернет;
• у режимі інкогніто.

Шкідливий код часто працює вибірково. Наприклад, редирект може бачити лише новий користувач із мобільного пристрою.

Зайдіть із Google

Деякі зараження перевіряють HTTP Referer і активуються лише для користувачів, які прийшли з пошукової системи.

Знайдіть сторінку сайту через пошук і відкрийте її звідти.

Перевірте невідомі сторінки

Виконайте пошук:

site:example.com

Зверніть увагу на сторінки про казино, ліки, криптовалюти, знайомства або інший контент, якого ви не створювали.

Чек-лист №2. Використайте зовнішні сканери

Онлайн-сканери корисні як перший фільтр. Вони можуть виявити:

• відомі шкідливі скрипти;
• підозрілі редиректи;
• включення стороннього JavaScript;
• наявність домену у чорних списках;
• змінену поведінку сторінки.

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

Тому чистий результат зовнішнього сканування ще не означає, що сервер не заражений.

Чек-лист №3. Перевірте дату зміни файлів

Це один із найкорисніших методів ручної діагностики.

Якщо сайт давно не оновлювався, але сьогодні змінилися десятки PHP-файлів, це серйозний привід для перевірки.

Особливо підозрілими є зміни у:

• корені сайту;
• каталогах плагінів;
• каталогах тем;
• uploads або image;
• системних каталогах CMS.

Чому uploads особливо важливий

У каталозі завантажень зазвичай повинні знаходитися зображення та документи. PHP-файл усередині папки з картинками може бути бекдором.

Це не абсолютне правило для всіх систем, але такий файл потрібно перевірити окремо.

Чек-лист №4. Шукайте PHP-файли з підозрілим кодом

Шкідливий код часто маскується та намагається ускладнити читання.

Підозру повинні викликати великі блоки незрозумілих символів або конструкції з функціями на кшталт:

base64_decode()
eval()
gzinflate()
str_rot13()
shell_exec()
system()
exec()

Але важливо: сама наявність такої функції не доводить зараження. Деякі легальні програми також можуть їх використовувати.

Оцінювати потрібно контекст.

Чек-лист №5. Порівняйте ядро CMS з оригіналом

Для WordPress та інших популярних CMS системні файли можна порівняти з чистим офіційним дистрибутивом тієї самої версії.

Якщо файл ядра змінився без причини — його потрібно дослідити.

Особливо це корисно для:

• wp-admin;
• wp-includes;
• системних каталогів OpenCart;
• файлів ядра фреймворку.

При цьому не замінюйте автоматично файли тем, кастомні модулі та власний код — вони можуть містити легальні зміни.

Чек-лист №6. Перевірте .htaccess і конфігурацію вебсервера

Шкідливі редиректи часто додаються саме сюди.

Перевірте:

• невідомі RewriteRule;
• редиректи на сторонні домени;
• правила, що залежать від User-Agent;
• правила для пошукових ботів;
• підключення невідомих файлів.

Якщо проблема бачиться лише користувачам із Google, правила можуть перевіряти referer і перенаправляти лише пошуковий трафік.

Чек-лист №7. Перевірте wp-config.php або config.php

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

Перевірте:

• початок файлу;
• кінець файлу;
• невідомі include або require;
• довгі зашифровані рядки;
• посилання на сторонні URL.

В OpenCart потрібно перевірити як основний config.php, так і конфігурацію адміністративної частини.

Чек-лист №8. Перевірте базу даних

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

Наприклад, шкідливий JavaScript може бути вставлений у:

• налаштування CMS;
• віджети;
• текст сторінок;
• HTML-блоки;
• шаблони листів;
• поля модулів.

Що шукати

Перевіряйте:

• iframe на невідомі домени;
• script із зовнішніми адресами;
• підозрілі base64-рядки;
• невідомі URL;
• дивні JavaScript-вставки.

Чек-лист №9. Перевірте адміністраторів

Якщо зловмисник отримав доступ до CMS, він може створити собі окремий обліковий запис.

Перегляньте всіх:

• адміністраторів WordPress;
• користувачів OpenCart із доступом до панелі;
• FTP/SFTP-користувачів;
• SSH-акаунтів;
• користувачів панелі хостингу.

Невідомий адміністратор — дуже серйозний сигнал.

Чек-лист №10. Перевірте cron-завдання

Шкідливий код може відновлювати видалені файли через cron.

Типова ситуація:

1. власник видаляє заражений PHP-файл;
2. через кілька годин файл з’являється знову;
3. джерелом виявляється заплановане завдання.

Перевірте системний cron та завдання всередині CMS.

Чек-лист №11. Проаналізуйте server access log

Журнал доступу може показати, як саме з’явилося зараження.

Шукайте:

• POST-запити до незвичних PHP-файлів;
• часті запити з однієї IP-адреси;
• звернення до старих плагінів;
• підозрілі запити перед появою нового файлу;
• спроби завантаження файлів.

Особливо корисно зіставити час створення шкідливого файлу з access log.

Чек-лист №12. Перевірте error log

Заражений код часто генерує PHP-помилки.

У журналі можуть з’явитися:

• помилки виконання невідомого файлу;
• звернення до неіснуючих URL;
• помилки сторонніх скриптів;
• аномальна кількість PHP warning;
• повторні аварійні завершення процесів.

Якщо сайт одночасно почав повертати 502 Bad Gateway, перевірка серверних журналів особливо важлива.

Чек-лист №13. Перевірте вихідну пошту

Деякі зараження використовують сервер для спам-розсилок.

Ознаки:

• різко зросла кількість відправлених листів;
• хостинг обмежив пошту;
• IP сервера потрапив у чорні списки;
• у mail log видно невідомих одержувачів.

Джерелом може бути як заражений PHP-файл, так і скомпрометована поштова скринька.

Чек-лист №14. Перевірте навантаження сервера

Шкідливий код може:

• виконувати фонові процеси;
• генерувати тисячі сторінок;
• надсилати спам;
• створювати запити до сторонніх серверів;
• запускати криптомайнінг;
• атакувати інші ресурси.

Тому зараження іноді спочатку проявляється як проблема продуктивності.

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

Як оцінити знайдений файл

Що робити, якщо шкідливий код знайдено

Не обмежуйтеся видаленням одного файлу.

Правильний порядок:

1. ізолюйте або тимчасово обмежте сайт, якщо зараження активне;
2. збережіть копію для аналізу;
3. визначте всі заражені файли;
4. перевірте базу даних;
5. знайдіть точку проникнення;
6. видаліть шкідливий код;
7. оновіть вразливі компоненти;
8. змініть паролі;
9. перевірте cron і адміністраторів;
10. проскануйте сайт повторно.

Детальний порядок відновлення описаний у матеріалі що робити, якщо сайт заражений вірусом.

Чому зараження повертається після очищення

Найчастіше через те, що видалили наслідок, але не закрили точку входу.

Причиною можуть залишатися:

• вразливий плагін;
• стара версія CMS;
• вкрадений FTP-пароль;
• невідомий адміністратор;
• cron-завдання;
• бекдор в іншому каталозі;
• заражений комп’ютер адміністратора.

Коли краще відновити чистий бекап

Відновлення може бути швидшим за ручне очищення, якщо:

• точно відома дата зараження;
• є гарантовано чиста резервна копія;
• після її створення сайт мало змінювався;
• можна окремо перенести нові замовлення або контент.

Перед відновленням потрібно спочатку закрити вразливість. Інакше чиста копія буде заражена повторно.

Чи можна перевіряти сайт на staging

Так. Для складного очищення безпечніше створити ізольовану копію й аналізувати її окремо.

Але staging також потрібно ізолювати від зовнішнього світу, вимкнути розсилки та заблокувати виконання потенційно небезпечних інтеграцій.

Для цього скористайтеся інструкцією, як створити staging-копію сайту.

Коли перевірку краще довірити спеціалісту

Самостійна перевірка доречна для початкової діагностики. Професійне очищення варто розглядати, якщо:

• зараження постійно повертається;
• уражено багато сайтів одного акаунта;
• змінено системні файли;
• сайт обробляє персональні дані;
• відбулися підозрілі дії з обліковими записами;
• невідомо, коли саме стався злом;
• потрібно встановити точку проникнення.

Практичний чек-лист перевірки

• Створено резервну копію.
• Перевірено сайт із різних пристроїв.
• Переглянуто результати site:domain.
• Запущено зовнішнє сканування.
• Перевірено дати зміни файлів.
• Переглянуто конфігураційні файли.
• Перевірено базу даних.
• Перевірено адміністраторів.
• Перевірено cron.
• Проаналізовано access log.
• Проаналізовано error log.
• Перевірено вихідну пошту.
• Перевірено використання CPU.
• Після очищення виконано повторне сканування.

FAQ

Чи може онлайн-сканер точно визначити зараження?

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

Чи можна просто перевстановити WordPress?

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

Чи потрібно міняти всі паролі?

Якщо зараження підтверджено, варто змінити паролі CMS, хостингу, SFTP/SSH та інших критичних сервісів після очищення.

Чому вірус не знаходить антивірус хостингу?

Шкідливий код може бути новим, добре замаскованим або виглядати як легальний PHP-код. Автоматичне сканування не замінює ручний аудит.

Чи впливає зараження на SEO?

Так. Приховані сторінки, редиректи та попередження про небезпечний сайт можуть призвести до втрати трафіку й позицій.

Висновок

Перевірка сайту на шкідливий код — це не натискання кнопки «Scan». Повноцінний аудит охоплює файли, базу даних, журнали сервера, облікові записи, cron-завдання та поведінку сайту для різних користувачів.

Найцінніша частина перевірки — не сам факт знаходження зараженого файлу, а визначення того, як він потрапив на сервер.

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