Защита сайта компании от взлома и DDoS: угрозы и меры защиты

Как защитить сайт компании: типичные атаки на CMS и формы, DDoS и боты, WAF и сервисы защиты, обновления и доступы, резервные копии, мониторинг и план действий при взломе — без паники и лишних расходов.

Большинство взломанных корпоративных сайтов никто специально не выбирал. Их нашёл автоматический сканер, который перебирает адреса в поисках устаревшего плагина, открытой админки или забытого архива с резервной копией. Последствия при этом вполне адресные: сайт рассылает спам, показывает посетителям чужую рекламу, попадает в предупреждения браузеров, а заявки клиентов с персональными данными утекают — и компания отвечает за это по 152-ФЗ. Ниже — какие угрозы реально касаются сайта обычной компании, какие меры закрывают большую часть рисков, когда нужны WAF и защита от DDoS и что делать в первые часы, если взлом уже случился. Кто и зачем атакует сайт компании Короткий ответ: чаще всего — автоматические инструменты, которым не важно, кто вы. Им нужен любой уязвимый сервер. Целевые атаки тоже бывают, но для большинства компаний первична массовая угроза. Злоумышленникам нужны ресурсы сервера для спама и фишинга, поисковая репутация сайта для скрытых ссылок и перенаправлений, данные заявок и личных кабинетов, деньги через вымогательство — или просто недоступность сайта в сезон продаж и во время запуска. Скорость здесь важнее сложности. По отчёту Patchstack «State of WordPress Security in 2026», медианное время до массовой эксплуатации активно атакуемых уязвимостей в экосистеме WordPress составило пять часов. Для других платформ цифры будут иными, но вывод общий: между публикацией уязвимости и попытками её использовать проходят часы, а не недели. Основные угрозы для сайта Удобная опора для классификации — OWASP Top 10:2025, список наиболее значимых рисков веб-приложений, финальная версия которого вышла в январе 2026 года. Ниже угрозы переведены на язык корпоративного сайта. Уязвимые и устаревшие компоненты CMS, модули, темы, JavaScript-библиотеки, версия PHP или Node.js на сервере. Уязвимость в любом из них открывает доступ ко всему сайту. Частая ситуация — забытый компонент: отключённый, но не удалённый плагин или заброшенная тестовая копия сайта на поддомене. Ошибки конфигурации В OWASP Top 10:2025 эта категория поднялась на второе место. Для сайта это открытая папка .git , архив резервной копии в корне сайта, включённый режим отладки с выводом ошибок, панель управления базой данных, доступная из интернета, стандартный адрес админки без ограничений. Подбор и утечка паролей Учётные записи администраторов CMS, хостинга, FTP, почты и регистратора домена. Пароли уходят через заражённые компьютеры сотрудников и подрядчиков, повторно используются на разных сервисах, пересылаются в мессенджерах. Взлом аккаунта у регистратора позволяет увести домен целиком. Формы и загрузка файлов Любое поле ввода — потенциальная точка атаки: SQL-инъекции, межсайтовый скриптинг, загрузка исполняемого файла под видом резюме. Плюс массовый спам через формы, который засоряет CRM и может использоваться для рассылок от имени компании. Нарушение контроля доступа Первое место в OWASP Top 10:2025. Актуально для сайтов с личными кабинетами: пользователь меняет номер заказа в адресе и видит чужие документы. Эта же проблема лежит в основе большинства атак на API — подробный разбор в статье о безопасности API . Цепочка поставок Новая категория OWASP Top 10:2025. Сторонние скрипты аналитики и чатов, виджеты, пакеты из npm или Composer выполняются с теми же правами, что и ваш код. Компрометация поставщика означает компрометацию вашего сайта. DDoS и вредоносные боты Атаки на отказ в обслуживании бывают двух типов. Сетевые (уровни L3–L4) забивают канал или ресурсы сервера мусорным трафиком. Атаки на уровне приложения (L7) имитируют обычных посетителей и бьют по «тяжёлым» страницам: поиску, фильтрам каталога, формам. Вторые сложнее отличить от реальных пользователей. К той же группе относятся боты, которые парсят цены, перебирают пароли и накручивают заявки. Доступы: самая дешёвая и самая недооценённая защита Контроль доступов закрывает значительную часть реальных инцидентов и почти ничего не стоит. Минимальный набор: двухфакторная аутентификация в админке CMS, на хостинге, у регистратора домена, в DNS и в репозитории; уникальные пароли в корпоративном менеджере паролей, а не в таблице или чате; персональные учётные записи вместо общей «admin» — чтобы в журнале было видно, кто что сделал; административная панель доступна только из офисной сети или через VPN; доступ к серверу по SSH-ключам, отказ от FTP с паролем; минимально необходимые права: контент-менеджеру не нужен доступ к установке плагинов; отзыв доступов в день ухода сотрудника или завершения работы подрядчика, ревизия списка учётных записей раз в квартал. Компоненты и обновления: знать, что у вас установлено Обновлять можно только то, о чём вы знаете. Поэтому первый шаг — перечень компонентов: CMS и её версия, все модули и плагины, библиотеки фронтенда и бэкенда, версии серверного ПО. Для проектов на современных стеках список зависимостей формируется автоматически, а сканеры зависимостей в процессе сборки сообщают об известных уязвимостях. Дальше — источники информации об уязвимостях: бюллетени разработчиков вашей CMS, уведомления репозитория кода, Банк данных угроз безопасности информации ФСТЭК России. Всё, что не используется, удаляется, а не отключается. Как организовать сам процесс обновлений с тестированием и откатом, описано в статье о поддержке сайта и SLA , здесь повторять не будем. Выбор платформы тоже влияет на объём этой работы: у конструктора обновления на стороне сервиса, у CMS с десятками плагинов — на вашей. Сравнение вариантов — в материале о выборе между конструктором, CMS и разработкой . Настройка сервера и приложения Правильная конфигурация закрывает целый класс атак без дополнительных сервисов. Что проверить: HTTPS на всех страницах, перенаправление с HTTP, заголовок HSTS; заголовки безопасности: запрет встраивания сайта в чужие фреймы, X-Content-Type-Options , политика источников контента (CSP) — хотя бы в режиме отчётов; cookie сессий с флагами Secure , HttpOnly и атрибутом SameSite ; закрыт доступ к служебным файлам и каталогам: .git , .env , дампы баз, архивы, журналы; режим отладки выключен, пользователю не показываются тексты системных ошибок; ограничена частота запросов к форме входа и формам заявок. Пример фрагмента конфигурации nginx, который реализует часть этих правил: # в контексте http: не более 5 попыток входа в минуту с одного адреса limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m; server { listen 443 ssl; server_name example.ru; add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; add_header X-Content-Type-Options "nosniff" always; add_header Referrer-Policy "strict-origin-when-cross-origin" always; add_header Content-Security-Policy "frame-ancestors 'self'" always; # скрытые файлы и каталоги (.git, .env), кроме .well-known location ~ /\.(?!well-known) { deny all; } # резервные копии, дампы и журналы не должны отдаваться по HTTP location ~* \.(sql|bak|zip|tar|gz|log)$ { deny all; } # админка только из офисной сети location /admin/ { allow 203.0.113.0/24; deny all; proxy_pass http://127.0.0.1:3000; } location = /login { limit_req zone=login burst=5 nodelay; proxy_pass http://127.0.0.1:3000; } } Для форм обязательна проверка данных на сервере, а не только в браузере, параметризованные запросы к базе, экранирование вывода. Загруженные файлы проверяются по фактическому содержимому, сохраняются вне публичного каталога и никогда не исполняются. От массового спама помогают ограничение частоты и капча — например, Yandex SmartCaptcha. Как правильно хранить пароли пользователей и настроить TLS, разобрано в статье о шифровании в веб-приложениях . WAF: что он делает и чего не делает WAF (Web Application Firewall) — фильтр перед сайтом, который анализирует HTTP-запросы и блокирует похожие на атаку: инъекции, попытки обхода каталогов, сканирование уязвимостей. Он полезен, но не заменяет обновления и безопасный код. Он отсекает массовые атаки и сканеры, ограничивает частоту запросов, даёт журнал атак и позволяет закрыть известную уязвимость правилом, пока готовится обновление, — так называемый виртуальный патч. Чего WAF не делает: не защищает от логических ошибок вроде доступа к чужому заказу, не спасает при украденном пароле администратора и может блокировать легитимных пользователей при слишком строгих правилах. Поэтому WAF подключают сначала в режиме наблюдения, изучают срабатывания и только потом включают блокировку. WAF бывает встроенным в CMS (например, в «1С-Битрикс» есть модуль «Проактивная защита» с веб-фильтром), установленным на сервер или облачным — в составе сервиса защиты от DDoS. Защита от DDoS: как устроена и как выбрать сервис Сервер компании не выдержит серьёзную DDoS-атаку сам: канал и ресурсы закончатся раньше, чем любые настройки успеют помочь. Защита строится на внешней сети фильтрации, которая принимает весь трафик, отсекает вредоносный и пропускает к сайту только чистый. Как это работает DNS-записи сайта указывают на адреса сервиса защиты, а не на ваш сервер. Сервис фильтрует трафик на своей распределённой инфраструктуре. Очищенные запросы передаются на ваш сервер. Сервер принимает входящие соединения только с адресов сервиса защиты. Последний пункт критичен. Если настоящий IP-адрес сервера известен — из старых DNS-записей, заголовков писем, поддоменов, — атакующие обойдут фильтрацию и ударят напрямую. После подключения защиты адрес сервера лучше сменить. Российские сервисы Защиту от DDoS и WAF в России предоставляют, в частности: Curator — бывший Qrator Labs; в декабре 2024 года компания разделилась, и в России работает под брендом Curator (защита от DDoS, WAF, защита от ботов, CDN); StormWall — защита от DDoS, WAF и CDN; DDoS-Guard — сеть фильтрации трафика и защита сайтов; Servicepipe — защита от DDoS и ботов с интеграцией WAF; Yandex Smart Web Security — сервис Yandex Cloud: защита от DDoS на уровне приложения и от ботов, WAF, ограничение частоты запросов, интеграция с SmartCaptcha; Cloud.ru — облачный провайдер, предлагающий защиту от DDoS и WAF на базе решений StormWall и Curator; VK Cloud — облачные WAF и защита от DDoS. Список не исчерпывающий и не является рейтингом: подходящий сервис зависит от инфраструктуры и требований проекта. Критерии выбора Уровни защиты : только сетевые атаки или также атаки на приложение и боты. Работа с HTTPS : для фильтрации на уровне приложения сервис расшифровывает трафик, а значит, получает доступ к данным форм. Это нужно отразить в договоре и в документах по персональным данным. Размещение узлов фильтрации и юрисдикция сервиса. Скорость подключения при атаке : можно ли включить защиту за минуты, когда атака уже идёт. Ложные срабатывания : как настраиваются исключения для платёжных уведомлений, интеграций, поисковых роботов. Поддержка и отчётность : круглосуточная связь и понятная статистика отфильтрованного трафика. Если хостинг «включает защиту от DDoS», уточните, от каких атак именно. Базовая сетевая фильтрация у провайдера часто не спасает от атак на уровне приложения. Резервные копии, которые переживут атаку Получив доступ к серверу, злоумышленник удалит и резервные копии, если они лежат там же или доступны с тех же учётных данных. Поэтому копии хранят в отдельном хранилище с отдельными доступами, в нескольких поколениях — заражение могло начаться недели назад, — а сервер не должен иметь права удалять старые версии. Мониторинг: узнать о взломе раньше клиентов Взлом, который обнаружили через полгода, обходится намного дороже, чем взлом, замеченный за час. Что стоит отслеживать: изменения файлов сайта вне плановых выкладок; появление новых администраторов и изменение прав; всплески неудачных попыток входа; доступность сайта и срок действия сертификата; сообщения в разделах безопасности Яндекс Вебмастера и Google Search Console; исходящую почту с сервера и нетипичную нагрузку. Журналы веб-сервера и приложения лучше хранить вне сайта: иначе злоумышленник сотрёт следы вместе с ними. Что нужно именно вашему сайту Меры защиты стоит соразмерять с тем, что сайт делает и какие данные обрабатывает. Тип сайта Обязательный минимум Добавить