Защита сайта от взлома и устранение последствий

Взлом сайта: что теряет бизнес и как быстро вернуть трафик

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

Безопасность веб-приложений: HTTPS, CSP, XSS, CSRF, WAF, защита от DDoS

Взлом сайта редко выглядит как в кино. Чаще это: бот нашёл endpoint /admin/export без авторизации, скачал базу клиентов, закрыл соединение. Или: через устаревший плагин WordPress залил веб-шелл, теперь сервер рассылает спам. Или тише: XSS в поле комментария позволяет красть session cookies администраторов, и никто не замечает месяцами. Мы такие случаи разбирали десятками — каждый раз уязвимость можно было закрыть на этапе разработки или аудита.

Безопасность веб-приложений — не одна настройка. Это слои защиты, каждый из которых закрывает отдельный класс атак. Закажите аудит — оценим проект и дадим план работ под ключ за 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: max-age=31536000; includeSubDomains; preload) — браузер больше не делает незащищённых запросов
• OCSP Stapling — ускоряет проверку отзыва сертификата
• Redirect 301 с HTTP на HTTPS — и в конфиге сервера, и в коде (двойной редирект = потеря SEO-веса)

Проверка: SSL Labs (ssllabs.com/ssltest) должен показывать A или A+. Если B — конфигурация слабая.

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

Content Security Policy: самая мощная и самая сложная защита

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-файлы, но это требует рефакторинга.

Почему 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 в браузере.

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 — обязательно.

Обновления зависимостей. 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. Аудит — сканирование кода, конфигураций, зависимостей, ручная проверка бизнес-логики.
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 дней постаудит-поддержки (консультации, правки)

Сроки и стоимость

Бюджет рассчитывается индивидуально — напишите нам, чтобы оценить проект.