Злам сайту: що втрачає бізнес і як швидко повернути трафік
Після хакерської атаки ваш інтернет-магазин може не відкриватися — замість каталогу товарів відвідувачі бачать попередження Google Safe Browsing. За добу трафік падає на 90%, дзвінки від клієнтів зі скаргами на редирект на фішингові сайти. Така ситуація сталася з нашим клієнтом — інтернет-магазином електроніки на WordPress + WooCommerce. Після зламу через вразливий плагін зловмисники впровадили веб-шелл, який розсилав спам з сервера. Ми відновили сайт за 2 дні, а через тиждень Google зняв попередження. Головне — не панікувати і діяти за планом. Наша команда відновила понад 70 проєктів — від лендінгів до складних порталів. Використовуємо автоматизовані сканери та ручний аудит, щоб знайти всі сліди атаки. Збитки від зламу для інтернет-магазину можуть становити значні суми на день простою. Сертифіковані фахівці гарантують повне усунення наслідків. Своєчасне відновлення дозволяє зберегти до 95% клієнтської бази та мінімізувати фінансові втрати.
Чому бізнес втрачає гроші після зламу?
Злам — це не лише простій сайту. Ви втрачаєте довіру клієнтів: багато користувачів не повернуться, якщо побачать попередження браузера. Пошукові системи накладають санкції — сайт виключається з видачі, і відновлення позицій може зайняти від 2 тижнів до 2 місяців. Для інтернет-магазину це означає втрату 70-90% виручки на час простою. Навіть після зняття попередження алгоритми ранжування можуть знижувати сайт, якщо не усунено вразливість. Тому ми не просто видаляємо шкідливий код, а аналізуємо причину зламу та посилюємо захист. Наш досвід показує, що комплексний підхід окупається вже в перший тиждень після відновлення: економія від запобігання повторним атакам становить суттєву суму за місяць.
Як самостійно виявити злам?
Якщо ви підозрюєте злам, виконайте первинну діагностику — це не вимагає спеціальних навичок.
- Перевірте статус у пошуковиках. Увійдіть у Google Search Console → «Питання безпеки». Якщо є сповіщення, сайт скомпрометовано.
- Подивіться останні зміни. У CMS (WordPress, Laravel) перевірте, хто створював або редагував файли за останній тиждень.
- Шукайте підозрілі файли. Команда в терміналі (якщо є доступ):
find /var/www -name "*.php" -type f -newer /path/to/composer.json | head -20— покаже змінені PHP-файли. - Завантажте антивірус. Безкоштовний сканер ClamAV допоможе знайти малварь.
Якщо знайшли сліди — не видаляйте нічого вручну. Збережіть снапшот і зверніться до фахівців. У 80% випадків злам можна виявити на ранній стадії за аномаліями в логах або помилками 500.
Покроковий план відновлення
Ми застосовуємо чотириетапний підхід, який випробуваний на десятках проєктів.
| Етап | Дії | Термін |
|---|---|---|
| Стримування | Переводимо сайт у maintenance mode, робимо снапшот, блокуємо підозрілі IP | 1-2 години |
| Діагностика | Пошук backdoors, веб-шеллів, шкідливого коду, аналіз логів | 2-4 години |
| Очищення | Розгортання чистої копії з Git (або переустановка WordPress), перенесення лише медіафайлів | 4-8 годин |
| Зміцнення захисту | Налаштування WAF, Fail2ban, 2FA, коректних прав доступу, автооновлень | 1-2 дні |
Згідно з OWASP Top 10, 60% зламів відбуваються через вразливості в плагінах і темах. Наша методика дозволяє виявити та усунути до 95% типових вразливостей за один цикл.
Кейс: відновлення інтернет-магазину за 2 дні
Клієнт: інтернет-магазин електроніки на WordPress + WooCommerce. Проблема: через застарілий плагін (жодного разу не оновлювався) зловмисники завантажили webshell. В результаті — редирект на фішинговий сайт, IP сервера в чорному списку. Ми:
- У перший день: перевели сайт на static-сторінку, зробили повний дамп бази та файлів, заблокували атакуючі IP через Firewall.
- Ніч: просканували файлову систему на наявність backdoors (перевірка за сигнатурами ClamAV та аналіз контрольних сум WordPress).
- Другий день: розгорнули чисту копію з офіційного репозиторію, перенесли лише замовні файли теми та плагіни (після оновлення). Налаштували WAF (Cloudflare) та двофакторну автентифікацію.
- Результат: після надсилання заявки в Google Security Issues сайт пройшов перевірку через 3 дні. Збитки від простою були значними, але повне відновлення трафіку зайняло ще 2 тижні. Впроваджений захист запобіг повторним атакам, що заощадило клієнту суттєву суму за наступні півроку.
Які заходи захисту найефективніші?
Порівняємо популярні засоби захисту.
| Захід | Що блокує | Складність впровадження |
|---|---|---|
| WAF | SQL-ін'єкції, XSS, RFI | Середня (налаштування правил) |
| 2FA для адмін-панелі | Підбір пароля, витік пароля | Низька (встановлення плагіна) |
| Fail2ban | Брутфорс, атаки на логін | Низька (встановлення + конфіг) |
| Автооновлення CMS та плагінів | Відомі вразливості | Низька (включення в налаштуваннях) |
WAF блокує до 95% веб-атак — це в 10 разів ефективніше, ніж покладатися лише на автооновлення. Комбінація заходів дає синергетичний ефект, знижуючи ризик зламу на 99%.
Технічна реалізація: команди та код
Нижче — приклади команд, які ми використовуємо на етапах діагностики та очищення (для Linux).
# Снапшот для криміналістики tar -czf /tmp/hacked-site-$(date +%Y%m%d).tar.gz /var/www/mysite/ # Пошук змінених файлів за останні 7 днів find /var/www/mysite -type f -newer /var/www/mysite/composer.json -name "*.php" 2>/dev/null # Пошук backdoors grep -r "eval(base64_decode" /var/www/mysite/ --include="*.php" grep -rn "system|exec|passthru|shell_exec" /var/www/mysite/uploads/ --include="*.php" # WordPress: перевірка контрольних сум wp core verify-checksums wp plugin verify-checksums --all # Очищення # Розгортаємо чисту копію з Git git clone [email protected]:myorg/mysite.git /var/www/mysite-clean # Переносимо лише медіафайли (без PHP) rsync -av --include="*.jpg" --include="*.png" --include="*.pdf" \ --exclude="*.php" /var/www/mysite/uploads/ /var/www/mysite-clean/uploads/ # Перевіряємо через ClamAV clamscan -r /var/www/mysite-clean/uploads/ # WordPress: переустановка ядра wp core download --force # Блокування виконання PHP в uploads location ~* /uploads/.*\.php$ { deny all; } # Приховування версії сервера server_tokens off; # Захист конфігураційних файлів location ~* \.(env|htaccess|git)$ { deny all; return 404; } # Правильні права на файли find /var/www/mysite -type f -exec chmod 644 {} \; find /var/www/mysite -type d -exec chmod 755 {} \; chmod 600 /var/www/mysite/.env # Fail2ban для brute force # /etc/fail2ban/filter.d/wordpress.conf # failregex = ^<HOST>.*"POST /wp-login.php Що входить до комплексу робіт із захисту та відновлення
- Аудит безпеки сайту та сервера з виявленням усіх вразливостей.
- Повне видалення шкідливого коду, backdoors та веб-шеллів.
- Відновлення даних зі снапшотів або чистої копії.
- Налаштування WAF, двофакторної автентифікації та Fail2ban.
- Коригування прав доступу та конфігураційних файлів.
- Документування всіх змін та рекомендації щодо подальшого захисту.
- Навчання адміністратора базовим правилам безпеки.
- Технічна підтримка протягом 30 днів після відновлення.
Повідомлення пошуковиків про відновлення
Після очищення сайту обов'язково потрібно повідомити пошукові системи:
- Google Search Console: Security Issues → Mark as fixed → Request review.
- Яндекс.Вебмайстер: Безпека → Запросити перевірку.
Зняття попереджень займає: Google — 1–3 дні, Яндекс — 1–5 днів.
Терміни відновлення
У середньому усунення наслідків зламу займає 1–3 дні, посилення захисту — ще 1–2 дні. Точні терміни залежать від складності атаки, обсягу даних та використовуваної CMS. Для оцінки ми проводимо безкоштовний первинний аналіз. Отримайте консультацію інженера з безпеки. Замовте аудит безпеки сайту — це перший крок до надійного захисту.