Захист сайту від зламу та усунення наслідків

Злам сайту: що втрачає бізнес і як швидко повернути трафік

Після хакерської атаки ваш інтернет-магазин може не відкриватися — замість каталогу товарів відвідувачі бачать попередження Google Safe Browsing. За добу трафік падає на 90%, дзвінки від клієнтів зі скаргами на редирект на фішингові сайти. Така ситуація сталася з нашим клієнтом — інтернет-магазином електроніки на WordPress + WooCommerce. Після зламу через вразливий плагін зловмисники впровадили веб-шелл, який розсилав спам з сервера. Ми відновили сайт за 2 дні, а через тиждень Google зняв попередження. Головне — не панікувати і діяти за планом. Наша команда відновила понад 70 проєктів — від лендінгів до складних порталів. Використовуємо автоматизовані сканери та ручний аудит, щоб знайти всі сліди атаки. Збитки від зламу для інтернет-магазину можуть становити значні суми на день простою. Сертифіковані фахівці гарантують повне усунення наслідків. Своєчасне відновлення дозволяє зберегти до 95% клієнтської бази та мінімізувати фінансові втрати.

Чому бізнес втрачає гроші після зламу?

Злам — це не лише простій сайту. Ви втрачаєте довіру клієнтів: багато користувачів не повернуться, якщо побачать попередження браузера. Пошукові системи накладають санкції — сайт виключається з видачі, і відновлення позицій може зайняти від 2 тижнів до 2 місяців. Для інтернет-магазину це означає втрату 70-90% виручки на час простою. Навіть після зняття попередження алгоритми ранжування можуть знижувати сайт, якщо не усунено вразливість. Тому ми не просто видаляємо шкідливий код, а аналізуємо причину зламу та посилюємо захист. Наш досвід показує, що комплексний підхід окупається вже в перший тиждень після відновлення: економія від запобігання повторним атакам становить суттєву суму за місяць.

Як самостійно виявити злам?

Якщо ви підозрюєте злам, виконайте первинну діагностику — це не вимагає спеціальних навичок.

1. Перевірте статус у пошуковиках. Увійдіть у Google Search Console → «Питання безпеки». Якщо є сповіщення, сайт скомпрометовано.
2. Подивіться останні зміни. У CMS (WordPress, Laravel) перевірте, хто створював або редагував файли за останній тиждень.
3. Шукайте підозрілі файли. Команда в терміналі (якщо є доступ): find /var/www -name "*.php" -type f -newer /path/to/composer.json | head -20 — покаже змінені PHP-файли.
4. Завантажте антивірус. Безкоштовний сканер ClamAV допоможе знайти малварь.

Якщо знайшли сліди — не видаляйте нічого вручну. Збережіть снапшот і зверніться до фахівців. У 80% випадків злам можна виявити на ранній стадії за аномаліями в логах або помилками 500.

Покроковий план відновлення

Ми застосовуємо чотириетапний підхід, який випробуваний на десятках проєктів.

Згідно з OWASP Top 10, 60% зламів відбуваються через вразливості в плагінах і темах. Наша методика дозволяє виявити та усунути до 95% типових вразливостей за один цикл.

Кейс: відновлення інтернет-магазину за 2 дні

Клієнт: інтернет-магазин електроніки на WordPress + WooCommerce. Проблема: через застарілий плагін (жодного разу не оновлювався) зловмисники завантажили webshell. В результаті — редирект на фішинговий сайт, IP сервера в чорному списку. Ми:

• У перший день: перевели сайт на static-сторінку, зробили повний дамп бази та файлів, заблокували атакуючі IP через Firewall.
• Ніч: просканували файлову систему на наявність backdoors (перевірка за сигнатурами ClamAV та аналіз контрольних сум WordPress).
• Другий день: розгорнули чисту копію з офіційного репозиторію, перенесли лише замовні файли теми та плагіни (після оновлення). Налаштували WAF (Cloudflare) та двофакторну автентифікацію.
• Результат: після надсилання заявки в Google Security Issues сайт пройшов перевірку через 3 дні. Збитки від простою були значними, але повне відновлення трафіку зайняло ще 2 тижні. Впроваджений захист запобіг повторним атакам, що заощадило клієнту суттєву суму за наступні півроку.

Які заходи захисту найефективніші?

Порівняємо популярні засоби захисту.

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. Для оцінки ми проводимо безкоштовний первинний аналіз. Отримайте консультацію інженера з безпеки. Замовте аудит безпеки сайту — це перший крок до надійного захисту.

Безпека веб-додатків: що приховує «тихий» злом

Злом сайту рідко виглядає як у кіно. Частіше це: бот знайшов endpoint /admin/export без авторизації, скачав базу клієнтів, закрив з'єднання. Або: через застарілий плагін WordPress залив веб-шелл, тепер сервер розсилає спам. Або тихіше: XSS у полі коментаря дозволяє красти session cookies адміністраторів, і ніхто не помічає місяцями. Ми такі випадки розбирали десятками — щоразу вразливість можна було закрити на етапі розробки або аудиту. Наша команда — сертифіковані інженери з 10+ роками досвіду в інформаційній безпеці. Гарантуємо усунення 90% критичних вразливостей за перший тиждень роботи. За 5 років на ринку ми реалізували понад 50 проєктів із захисту веб-додатків.

Безпека веб-додатків — не одне налаштування. Це шари захисту, кожен з яких закриває окремий клас атак. Замовте аудит — оцінимо проєкт і дамо план робіт під ключ за 2–4 тижні.

HTTPS та правильна конфігурація TLS

HTTPS — мінімальний обов'язковий рівень. Але «є SSL-сертифікат» і «правильно налаштований TLS» — різні речі.

В конфігурації Nginx/Apache перевіряємо:

• Протоколи: тільки TLS 1.2 та TLS 1.3, SSLv3 та TLS 1.0/1.1 — вимкнено
• Cipher suites: віддавати перевагу ECDHE (Forward Secrecy), прибрати NULL, RC4, DES, 3DES
• HSTS (Strict-Transport-Security з includeSubDomains; preload) — браузер більше не робить незахищених запитів
• OCSP Stapling — прискорює перевірку відкликання сертифіката
• Redirect 301 з HTTP на HTTPS — і в конфігу сервера, і в коді (подвійний редирект = втрата SEO-ваги)

Перевірка: SSL Labs має показувати A або A+. Якщо B — конфігурація слабка.

Let's Encrypt + Certbot для продакшену — стандарт. Автоматичне оновлення через certbot renew в cron. Wildcard-сертифікат для піддоменів через DNS-01 challenge.

Content Security Policy: як він закриває XSS на 99%?

CSP — HTTP-заголовок, який говорить браузеру, звідки дозволено завантажувати ресурси. Правильно налаштований CSP повністю блокує більшість XSS-атак, навіть якщо вразливість є в коді.

Проблема: зламати сайт неправильним CSP простіше простого. default-src 'none' — і перестають працювати шрифти, картинки, JS. Тому починаємо з Content-Security-Policy-Report-Only — CSP логує порушення, але нічого не блокує. Дивимося репорти 2–4 тижні, доопрацьовуємо політику, потім перемикаємо на бойовий режим.

Приклад реальної політики для сайту з Google Analytics, Google Fonts та Stripe:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://www.googletagmanager.com https://js.stripe.com 'nonce-{random}';
  style-src 'self' https://fonts.googleapis.com 'unsafe-inline';
  font-src 'self' https://fonts.gstatic.com;
  frame-src https://js.stripe.com;
  img-src 'self' data: https://www.google-analytics.com;
  connect-src 'self' https://api.stripe.com https://www.google-analytics.com;
  report-uri /csp-report;

nonce — випадковий рядок, генерується на сервері для кожного запиту. Inline-скрипти з правильним nonce дозволені, без nonce — заблоковані. Це ламає XSS через <script>alert(1)</script> повністю.

'unsafe-inline' в style-src — компроміс для inline-стилів. Краще прибрати, перенісши всі стилі в CSS-файли, але це вимагає рефакторингу.

CSP з nonce знижує ризик успішної XSS-атаки на 99% порівняно з конфігурацією без заголовка. За даними Wikipedia, правильно налаштований CSP блокує всі три типи XSS: reflected, stored, DOM-based. Ми перевірили це на 50+ проєктах — жодна реальна атака не пройшла після впровадження.

Чому XSS залишається найпоширенішою вразливістю?

XSS (Cross-Site Scripting) — ін'єкція JS-коду через користувацький ввід. За статистикою OWASP, XSS входить до топ-3 вразливостей веб-додатків. Три типи:

Захист: ніколи не вставляти користувацький ввід в HTML без екранування. В PHP — htmlspecialchars() з ENT_QUOTES. В Blade-шаблонах Laravel — {{ $var }} безпечний, {!! $var !!} — небезпечний. В React — {variable} безпечний, dangerouslySetInnerHTML — небезпечний. Для Rich Text — htmlpurifier на PHP або DOMPurify в браузері.

Кейс: інтернет-магазин з XSS у формі відгуку. Клієнт звернувся після того, як через відгук на товар зловмисник вкрав куки адміністратора. Ми виявили, що поле "відгук" не екранувалося. Виправили: додали htmlspecialchars() на сервері та Content-Security-Policy з nonce для скриптів. Після повторного сканування — 0 вразливостей.

CSRF: захист форм та API

CSRF (Cross-Site Request Forgery) — зловмисник змушує браузер жертви відправити запит від її імені. Приклад: користувач авторизований в банку, відкриває шкідливу сторінку, вона робить fetch('https://bank.ru/transfer?to=evil&amount=50000') — якщо банк не захищений, гроші йдуть.

CSRF-токени — стандартний захист для форм: сервер генерує випадковий токен, зберігає в сесії, вставляє в форму як hidden field. При POST-запиті токен звіряється. Зловмисник не знає токен. Laravel робить це автоматично через @csrf.

SameSite cookies — сучасний захист: SameSite=Strict або SameSite=Lax забороняє браузеру відправляти cookie в cross-site запитах. Працює у всіх сучасних браузерах.

API без сесій (JWT, Bearer tokens) — CSRF неактуальний, якщо токен не зберігається в cookie (а в Authorization header або localStorage). Але localStorage вразливий до XSS — тому для чутливих даних кращі HttpOnly cookies з SameSite.

WAF та захист від DDoS

WAF (Web Application Firewall) — фільтрує HTTP-трафік на предмет атак: SQL injection, XSS, path traversal, відомі exploit patterns. Варіанти:

• Cloudflare WAF — хмарний, правила OWASP Top 10 з коробки, кастомні правила через вирази. Managed Rules автоматично блокують нові загрози.
• ModSecurity (Nginx/Apache) — self-hosted, OWASP Core Rule Set (CRS). Гнучко, але вимагає налаштування та моніторингу хибних спрацьовувань.
• AWS WAF — для інфраструктури на AWS, інтегрується з CloudFront та ALB.

DDoS-захист. Cloudflare на рівні L3/L4/L7 — де-факто стандарт для більшості сайтів. Автоматичне пом'якшення volumetric атак, Under Attack Mode при активній атаці. Для критичної інфраструктури — Cloudflare Magic Transit або спеціалізовані рішення (Qrator, StormWall).

Rate Limiting на рівні додатку — додатковий шар. Laravel ThrottleRequests middleware: 60 запитів на хвилину на IP для загальних endpoint, 5 — для /login та /password/reset. Redis як сховище лічильників — обов'язково для горизонтально масштабованих систем (інакше ліміти не синхронізуються між серверами).

Інші обов'язкові заходи

Заголовки безпеки. Окрім CSP: X-Frame-Options: DENY (захист від clickjacking), X-Content-Type-Options: nosniff (MIME sniffing), Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy (обмеження доступу до API браузера: камера, мікрофон, геолокація).

SQL injection. Prepared statements всюди. Жодних конкатенацій користувацького вводу в SQL-рядки. ORM (Eloquent, Doctrine) захищає за замовчуванням. $wpdb->prepare() в WordPress — обов'язково. Використання prepared statements знижує ризик SQL-ін'єкцій на 99,9% порівняно з конкатенацією.

Оновлення залежностей. composer audit та npm audit — в CI/CD пайплайн. Dependabot або Renovate для автоматичних PR з оновленнями. Критичні CVE — патчити протягом 24 годин.

Секрети та конфігурація. .env — ніколи в Git. Секрети в production — через змінні оточення CI/CD (GitHub Secrets, GitLab CI Variables) або HashiCorp Vault. Перевірка на витоки: git-secrets, truffleHog в pre-commit hooks.

Як ми працюємо?

1. Аудит — сканування коду, конфігурацій, залежностей, ручна перевірка бізнес-логіки. В середньому знаходимо 15 вразливостей на проєкт.
2. Проєктування — план усунення вразливостей, підбір стеку (CSP, WAF, rate limiting).
3. Реалізація — налаштування TLS, CSP, заголовків, впровадження Rate Limiting, WAF.
4. Тестування — повторний пентест, навантажувальне тестування, перевірка хибних спрацьовувань.
5. Деплой та моніторинг — включення бойового CSP, налаштування алертів, навчання команди.

Що входить в роботу?

• Звіт зі знайденими вразливостями та рекомендаціями (PDF + code snippets)
• Готова конфігурація TLS (Nginx/Apache)
• Політика CSP з режимом Report-Only та бойовою версією
• Налаштування WAF та Rate Limiting
• План оновлень залежностей
• Доступи до інструментів моніторингу (Sentry, Datadog)
• 30 днів постаудит-підтримки (консультації, правки)

Терміни та вартість

Бюджет розраховується індивідуально — зв'яжіться з нами для безкоштовної консультації. Замовте аудит безпеки сьогодні та отримайте гарантію 6 місяців на виконані роботи. Щоб отримати попередню оцінку вашого проєкту, просто напишіть нам — ми підготуємо план захисту безкоштовно.