Злом сайту — стресова ситуація, яка вимагає чітких і швидких дій. Головне правило: не панікувати, діяти системно. Більшість сайтів можна повністю відновити за кілька годин.
Ознаки злому сайту
- Редирект на чужий сайт (фармінг, фішинг)
- Попередження Google «Сайт містить шкідливе ПЗ»
- Хостинг заблокував акаунт за розсилку спаму
- Поява нових файлів або директорій
- Незрозуміле зростання трафіку або навантаження на сервер
- Скарги користувачів на антивірус
Крок 1: Ізоляція та збереження доказів
cp -r /var/www/site/ /tmp/site-backup-hacked/
find /var/www/site/ -newer /var/www/site/index.php -type f | head -50
ls -lat /var/www/site/ | head -20Крок 2: Пошук шкідливого коду
apt install clamav -y && freshclam
clamscan -r --infected /var/www/site/
find /var/www/site/ -name "*.php" -exec grep -l "base64_decode\|eval\|gzinflate\|str_rot13\|preg_replace.*e" {} \;
find /var/www/site/ -name "*.php" -newer /var/log/dpkg.log -type f
grep -r "FilesMan\|c99\|r57\|WSO Shell\|webshell" /var/www/site/Крок 3: Очищення або відновлення
grep -r "eval(base64_decode" /var/www/wordpress/ --include="*.php" -l | while read f; do
echo "Infected: $f"
done
for infected_file in $(grep -rl "eval(base64_decode" /var/www/wordpress/ --include="*.php"); do
rm "$infected_file"
echo "Removed: $infected_file"
done
Відновлення з бекапу надійніше за ручне очищення. Якщо є чистий бекап до злому — відновіть його. Ручне очищення залишає ризик пропустити один файл, що призведе до повторного зараження через кілька днів.
Крок 4: Усунення причини злому
grep "access.log" /var/log/nginx/access.log | grep "POST /wp-admin\|/xmlrpc.php" | sort | uniq -c | sort -rn | head -20
grep "404\|403" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20Крок 5: Повідомити Google
Після очищення: Google Search Console → Безпека → Запросити перевірку. Зняття попередження займає 1–3 дні.
Чекліст після відновлення
| Дія | Статус |
|---|---|
| Змінити всі паролі (БД, FTP, панель) | |
| Оновити CMS, плагіни, теми | |
| Встановити WAF (Wordfence, ModSecurity) | |
| Налаштувати моніторинг змін файлів | |
| Перевірити права на файли | |
| Запросити перевірку в Google Search Console | |
| Повідомити хостинг про очищення |
Профілактика важливіша за лікування: Налаштуйте автоматичні оновлення CMS/плагінів, регулярні бекапи, моніторинг файлової системи (auditd, inotifywait) і WAF. Це скоротить ризик злому на 90%.
Типові повідомлення під час злому
| Повідомлення | Що воно означає | Що робити |
|---|---|---|
| «Deceptive site ahead» у браузері Chrome | Google Safe Browsing знайшов на сайті фішинговий або оманливий контент | Очистіть сайт, потім запросіть перегляд у Google Search Console → Безпека |
| «Your account has been suspended due to abuse complaints» від хостингу | З сайту розсилався спам або йшов шкідливий трафік, хостинг заблокував акаунт превентивно | Зверніться до підтримки хостингу, отримайте список порушень, усуньте причину до розблокування |
| Незнайоме правило RewriteRule у .htaccess | Зловмисник додав редирект частини трафіку на сторонній спам- чи фішинговий домен | Видаліть чужі правила, залишивши лише ті, що додавали ви самі |
| siteurl у таблиці wp_options вказує на чужий домен | Специфічна для WordPress ознака: через вразливість змінили адресу сайту в базі | Поверніть значення вручну через wp option update siteurl "https://example.com" |
Порівняння підходів до очищення
| Підхід | Швидкість | Надійність | Вартість |
|---|---|---|---|
| Відновлення з чистого бекапу | Швидко — хвилини-години | Висока, якщо бекап точно знято до зараження | Безкоштовно за наявності бекапу |
| Ручне очищення файлів | Повільно — години або дні | Середня, є ризик пропустити один заражений файл | Безкоштовно, але дорого за часом фахівця |
| Платна послуга (Sucuri, MalCare тощо) | Швидко — зазвичай протягом доби | Висока, професійний аудит і моніторинг після | $100–400 за разове очищення |
Коли відновлення складніше за чекліст
- Зараження торкнулося не лише файлів сайту, а самого сервера (руткіт, змінені системні бінарники) — потрібен повний аудит ОС, а не лише вебдиректорії
- Shared-хостинг, де заразився сусідній акаунт і постійно повторно інфікує ваш через спільні ресурси сервера — єдине рішення — переїзд на ізольований VDS
- Шкідливий код потрапив через довірене оновлення легітимного плагіна (supply-chain атака) — звичайне порівняння з оригіналом плагіна нічого не покаже
- Використовується ще не закрита 0-day вразливість у ядрі CMS — тимчасове рішення — правило WAF, що блокує експлойт, до виходу патча
Щоб така ситуація не повторилася, варто пройтися чеклістом «Безпека WordPress: повний чекліст 2026», а на майбутнє — мати напоготові заздалегідь підготовлений «План реагування на інцидент: перші 60 хвилин».
Перевірка результату
Після очищення переконайтеся, що не залишилося прихованих точок повернення для зловмисника:
# Перевірити cron-завдання на сервері і в самому WordPress
crontab -l -u www-data
wp cron event list
# Перевірити список адміністраторів — чи не з'явився новий
wp user list --role=administrator
# Перевірити вихідні з'єднання на підозрілі адреси
netstat -antp | grep ESTABLISHED
# Повторне сканування іншим інструментом для перехресної перевірки
apt install rkhunter -y && rkhunter --check --skДля захисту від повторного підбору паролів на панелі і SSH після очищення встановіть Fail2ban: захист SSH і Nginx від підбору паролів.