Как защитить сайт от взлома: полный гайд по безопасности веб-ресурса

Почему нужно защищать сайт

Большинство владельцев сайтов думают об информационной безопасности в одном из двух случаев: когда их уже взломали или когда видят страшный заголовок в новостях. До этого момента кажется, что угроза где-то далеко и касается только крупных корпораций. Это опасное заблуждение.

По данным Positive Technologies, в первой половине 2025 года число успешных кибератак в России выросло на 53% по сравнению с аналогичным периодом 2024-го. Аналитики компании прогнозируют рост еще на 30–35% в #CURRENT_YEAR# году. Только за первые шесть месяцев 2025 года на российские компании зафиксировано более 63 000 кибератак.

Россия уже занимает третье место в мире по числу кибератак — после США и Китая. На нее приходится 46% всех инцидентов в СНГ.

Атакуют не только банки и госструктуры. Если у вас есть сайт с формой обратной связи, интернет-магазин или корпоративный лендинг — вы в зоне риска.

Что происходит после взлома: последствия для бизнеса

Последствия взлома сайта делятся на несколько уровней:

Поисковые санкции. Яндекс и Google располагают системами Safe Browsing, которые автоматически обнаруживают вредоносный код на страницах. После обнаружения сайт помечается как опасный, выпадает из индекса или получает предупреждение в выдаче. Восстановление позиций после такого занимает от нескольких недель до нескольких месяцев.

Утечка персональных данных. Если на сайте хранятся данные клиентов — имена, телефоны, адреса электронной почты, платежные данные — их кража влечет административную и уголовную ответственность. По закону 152-ФЗ «О персональных данных» оператор обязан уведомить Роскомнадзор об инциденте в течение 24 часов. За нарушение требований грозит штраф: с 2024 года для компаний — от 3 до 5 млн рублей при утечке данных от 1 до 10 тыс. пользователей и до 500 млн рублей за повторное нарушение крупного масштаба.

Финансовые потери. Совокупный ущерб от одной кибератаки на бизнес в #CURRENT_YEAR# году в среднем превышает 50 млн рублей — с учетом простоя, восстановления, юридических издержек и репутационного ущерба. Для малого бизнеса, конечно, цифры скромнее, но и масштаб другой: даже неделя простоя интернет-магазина — это потеря реальной выручки.

Репутационный удар. Клиент, который увидит предупреждение «Этот сайт может навредить вашему компьютеру», скорее всего, больше не вернется. И расскажет об этом другим.

Кто атакует сайты и зачем: мотивы злоумышленников

Понять мотив атакующего — значит правильно расставить приоритеты в защите.

Важно: большинство атак на малый и средний бизнес — автоматизированные. Никто не «целится» в ваш конкретный сайт. Боты непрерывно сканируют весь интернет в поисках известных уязвимостей — устаревших версий WordPress, открытых портов, слабых паролей. Как только дыра найдена, эксплуатация происходит мгновенно.

Миф о «маленьком сайте»: почему атакуют всех

«У меня небольшой сайт-визитка, меня никто не будет взламывать» — это самое дорогостоящее заблуждение в области веб-безопасности. По данным PT SWARM (команда Positive Technologies по анализу защищенности), в 89% случаев тестировщики, имитирующие хакера, успешно проникали в инфраструктуру компаний — и в 79% из них это удавалось менее чем за 4 часа.

Маленький сайт интересен злоумышленнику сразу по нескольким причинам.

• Слабая защита. Малый бизнес реже обновляет CMS, реже меняет пароли и реже нанимает специалистов по безопасности.
• Ресурс для атак. Скомпрометированный сайт используют как плацдарм для DDoS-атак на других, рассылки спама или майнинга криптовалюты — все это происходит незаметно для владельца.
• Данные клиентов. Даже небольшая база из 500 email-адресов имеет ценность на теневом рынке.
• Полное отсутствие мониторинга. Владельцы маленьких сайтов зачастую обнаруживают взлом спустя недели — когда уже пришло письмо от хостера или поисковика.

Безопасность сайта — это не привилегия крупного бизнеса. Это базовая гигиена для любого веб-ресурса.

Основные виды атак на сайты

DDoS-атаки — как перегружают сервер и останавливают сайт

Представьте: ваш магазин одновременно «посещают» несколько десятков тысяч человек. Никто из них не покупает — они просто стоят в дверях, не давая пройти реальным покупателям. Именно так работает DDoS (Distributed Denial of Service) — распределенная атака отказа в обслуживании.

Злоумышленник управляет тысячами зараженных устройств (ботнетом) и направляет их трафик на ваш сервер. Сервер не справляется с нагрузкой и перестает отвечать. Для легитимных пользователей сайт просто недоступен.

Атаки различаются по уровням сетевой модели OSI:

Атаки уровня L7 — самые коварные: они выглядят как обычные запросы к страницам сайта и хуже поддаются фильтрации. Именно против них нужны специализированные WAF и CDN с анализом трафика.

SQL-инъекции — как хакеры крадут базы данных через форму

Каждый раз, когда пользователь вводит что-то в поле на вашем сайте — имя, email, запрос в поиске — эти данные уходят в базу данных. Если разработчик не позаботился о правильной обработке этих данных, злоумышленник может вместо имени ввести фрагмент SQL-кода. Такие атаки позволяют выгрузить всю базу данных целиком, изменить записи или вовсе ее уничтожить.

SQL-инъекции стабильно входят в тройку наиболее распространенных атак на веб-приложения.

XSS — как вредоносный код добирается до ваших посетителей

XSS* (Cross-Site Scripting, межсайтовый скриптинг) — атака, при которой злоумышленник внедряет вредоносный JavaScript в страницы вашего сайта. Страдают уже не вы, а ваши посетители: их сессии крадут, данные утекают, браузер выполняет чужие команды.

Существует три основных типа XSS-атак.

• Stored XSS — самый опасный. Вредоносный скрипт сохраняется в базе данных сайта (например, в комментарии или отзыве) и загружается для каждого посетителя страницы.
• Reflected XSS — скрипт передается через URL. Жертву обманом заставляют перейти по специально сформированной ссылке.
• DOM-based XSS — уязвимость находится в клиентском JavaScript-коде, который небезопасно обрабатывает данные.

Совет: если у вас есть форма комментариев, поле поиска или любое другое место, куда пользователь может что-то вводить — это потенциальная точка входа для XSS.

CSRF — как злоумышленники действуют от вашего имени

CSRF* (Cross-Site Request Forgery) — атака, которая вынуждает авторизованного пользователя выполнить нежелательное действие на сайте без его ведома.

Пример: вы авторизованы в своем интернет-банке. Параллельно вы открываете стороннюю страницу с безобидной картинкой — но в ее HTML-коде спрятан запрос к банку на перевод средств. Банк получает запрос с вашими cookies и видит его как легитимный.

Для сайтов с личными кабинетами, формами смены пароля или оплатой — это серьезная угроза. Защищают от нее CSRF-токены: уникальный секрет, который генерируется для каждой формы и проверяется сервером при отправке.

Брутфорс — подбор пароля как основной метод взлома

Брутфорс — это банальный перебор паролей. Звучит примитивно, но работает пугающе эффективно: согласно данным ГК «Солар», в I квартале 2025 года число брутфорс-атак на российские организации выросло в 2,7 раза по сравнению с IV кварталом 2024-го и достигло 570 000 зафиксированных инцидентов. На атаки методом перебора паролей пришлось 94% всех зафиксированных атак за квартал.

Современные инструменты перебирают миллионы комбинаций в секунду. По данным Kaspersky Securelist, пароль из 8 символов (только строчные буквы) подбирается за несколько минут. 12-символьный пароль с буквами, цифрами и спецсимволами — уже тысячи лет при той же мощности.

Отдельная разновидность — credential stuffing: злоумышленники берут базы логинов и паролей, утекших с других сервисов, и проверяют их на вашем сайте. Работает, потому что большинство людей используют один пароль везде.

Вредоносный код и малварь — как вирус попадает на сайт

Заражение сайта вредоносным кодом — ситуация, когда злоумышленник получает доступ к файлам на сервере и внедряет туда свои скрипты. Посетители заражаются, не подозревая об этом. Поисковики обнаруживают малварь* и убирают сайт из выдачи.

Основные пути заражения:

• Уязвимые плагины и темы.97% всех уязвимостей в WordPress приходится именно на плагины и темы, а не на ядро CMS.
• Скомпрометированные FTP/SSH-данные. Украденные учетные данные хостинга дают злоумышленнику прямой доступ к файлам сайта.
• Загрузка вредоносных файлов через форму. Если сайт принимает загрузку файлов (аватары, документы), а расширения не проверяются — через форму можно закачать исполняемый PHP-файл.
• Цепочка зависимостей. Один зараженный npm-пакет или библиотека может скомпрометировать весь проект.

Уязвимости в CMS и плагинах — тихая угроза устаревшего ПО

Каждый день исследователи находят новые уязвимости в популярных платформах и публикуют их в базе CVE* (Common Vulnerabilities and Exposures). Как только уязвимость становится известна — боты начинают автоматически проверять весь интернет на ее наличие. Иногда между публикацией CVE и первой массовой атакой проходит меньше суток.

Если вы не обновили WordPress, Joomla, Битрикс или любой другой движок вовремя — вы буквально оставили дверь незапертой с объявлением «здесь есть что взять». Это не метафора: по данным Positive Technologies, 60% успешных атак на веб-ресурсы используют уязвимости, для которых патч уже существовал в момент атаки.

Таблица: Карта угроз веб-ресурса

Часть атак начинается именно со спама: фишинговые письма, вредоносные вложения, поддельные формы. О том, как распознать цифровой мусор и защитить данные компании — в материале Виды спама в интернете.

С чего начать: базовая защита сайта, которую должны иметь все

SSL/TLS-сертификат и HTTPS — первый и обязательный шаг

Если ваш сайт до сих пор работает по HTTP, а не HTTPS — браузер Chrome показывает посетителю предупреждение «Не защищено» прямо в адресной строке. Яндекс и Google учитывают наличие HTTPS как сигнал ранжирования. А главное — без шифрования любые данные, которые вводит пользователь на вашем сайте (логин, пароль, номер карты), можно перехватить при передаче.

SSL/TLS-сертификат* создает зашифрованный канал между браузером посетителя и вашим сервером. Даже если кто-то «подслушает» соединение — он получит нечитаемый зашифрованный поток.

Какой сертификат выбрать:

Важный факт, который часто скрывают продавцы сертификатов: уровень шифрования у DV, OV и EV одинаковый. Разница только в уровне проверки владельца. Для подавляющего большинства сайтов бесплатный Let’s Encrypt — полноценное решение.

Как получить бесплатный сертификат

Большинство российских хостингов (Timeweb, REG.RU, Spaceweb, Selectel) подключают Let’s Encrypt в один клик прямо из панели управления. Если у вас VPS — установите утилиту Certbot, которая автоматически выпускает и обновляет сертификат каждые 90 дней.

После установки сертификата обязательно настройте принудительный редирект с HTTP на HTTPS — иначе часть трафика будет идти по незащищенному протоколу. И включите HSTS (HTTP Strict Transport Security) — заголовок, который указывает браузеру всегда использовать HTTPS для вашего домена, даже если пользователь вручную набрал http://:

Надежный хостинг как фундамент безопасности

Хостинг — это не просто место, где лежат файлы вашего сайта. Это первый рубеж обороны, который вы не контролируете напрямую. Выбор ненадежного провайдера обесценивает любые усилия по защите на уровне сайта.

На что смотреть при выборе хостинга с точки зрения безопасности:

• Изоляция аккаунтов. На виртуальном хостинге один сервер делят десятки клиентов. Если аккаунты не изолированы — заражение соседнего сайта может перекинуться на ваш. Спрашивайте у провайдера про технологии изоляции (CloudLinux, контейнеризация).
• Встроенный антивирус. Хорошие провайдеры включают сканирование файлов на вредоносный код — ImunifyAV или аналоги. Это не замена вашим мерам, но дополнительная страховка.
• Автоматические резервные копии. Минимум — ежедневный бэкап с хранением 7–14 дней. Уточняйте, входит ли это в тариф или стоит отдельно.
• Защита от DDoS. Базовый уровень (L3/L4) должен быть включен по умолчанию. Для серьезных проектов — уточняйте наличие L7-защиты.
• Техподдержка при инцидентах. Важно знать: есть ли у провайдера процедура реагирования на взломы? Помогут ли вам найти и удалить вредоносный код?

Виртуальный хостинг vs VPS vs выделенный сервер

На виртуальном хостинге большую часть настроек безопасности делает провайдер — это плюс для тех, кто не хочет разбираться в технических деталях. Минус — меньше контроля и изоляции.

На VPS (виртуальный частный сервер) вы получаете полный контроль над окружением, но и полную ответственность за его защиту: обновления ОС, настройка фаервола, закрытие портов — все на вас.

Выделенный сервер — максимальная производительность и изоляция, но и максимальная ответственность. Имеет смысл при высоких нагрузках и строгих требованиях к безопасности.

Сложные пароли и парольная политика

В I квартале 2025 года 94% всех зафиксированных атак на российские организации составляли брутфорс-атаки — перебор паролей. Это не потому что хакеры ленивы — это потому что пароли у большинства действительно слабые.

Минимальные требования к паролю администратора сайта:

• Не менее 16 символов
• Сочетание букв верхнего и нижнего регистра, цифр, спецсимволов
• Не использовался ранее на других сервисах
• Не содержит имя домена, дату рождения, слово «admin» или «password»

Не нужно придумывать такие пароли вручную. Используйте менеджеры паролей — они генерируют, хранят и подставляют сложные пароли автоматически.

Надежные менеджеры паролей:

• Bitwarden — open-source, бесплатный для личного использования, есть самостоятельный хостинг
• KeePass — полностью локальное хранение, хранилище — зашифрованный файл на вашем устройстве
• 1Password — удобный интерфейс, есть командные тарифы для бизнеса

Важно: у каждого сотрудника, имеющего доступ к сайту, должен быть свой уникальный пароль. Никаких общих паролей на всю команду — это делает невозможным аудит: кто именно и когда заходил в панель управления.

Двухфакторная аутентификация (2FA) — второй замок на двери

Даже самый сложный пароль можно украсть — через фишинг, через утечку базы данных с другого сервиса, через вредоносное ПО на компьютере. 2FA* решает эту проблему: даже зная пароль, злоумышленник не войдет без второго фактора подтверждения.

Как работает 2FA: при входе в систему после ввода пароля приходит одноразовый код — в приложении, по SMS или через аппаратный ключ. Код действует 30–60 секунд. Без физического доступа к вашему телефону или ключу войти невозможно.

Варианты второго фактора (от надежного к менее надежному):

Где включить 2FA:

• WordPress — плагины WP 2FA или Wordfence включают TOTP в несколько кликов
• Битрикс — двухфакторная аутентификация настраивается в настройках безопасности административного раздела
• Панель управления хостингом (cPanel, ISPmanager, Beget, Timeweb) — у большинства провайдеров есть встроенная поддержка 2FA
• Почта администратора — обязательно, ведь через сброс пароля на почту злоумышленник получает доступ ко всему остальному

Принцип минимальных привилегий — кому какой доступ нужен

Принцип минимальных привилегий (Principle of Least Privilege) звучит так: каждый пользователь, процесс или компонент системы должен иметь только тот уровень доступа, который необходим для выполнения конкретной задачи — и не больше.

На практике это означает следующее.

В CMS: если у вас есть авторы, редакторы и администраторы — разграничьте роли. Автор статей не должен иметь доступ к настройкам плагинов. Редактор не должен мочь удалять пользователей. Роль «Администратор» — только у тех, кому она действительно нужна.

На файловой системе сервера: файлы сайта должны иметь правильные права доступа (chmod).

В базе данных: создайте отдельного пользователя БД для сайта с правами только на нужные операции (SELECT, INSERT, UPDATE, DELETE). Права DROP, CREATE, GRANT — только для администратора и только при необходимости.

Для FTP/SFTP: не раздавайте доступ к корневой директории всем подряд. Для каждого подрядчика или разработчика создайте отдельный аккаунт с доступом только к нужной папке — и удаляйте его сразу после окончания работ.

Подробнее о том, как выстроить ролевую модель доступа в компании и не утонуть в ручном управлении правами — в нашем гайде Разграничение прав доступа: RBAC, ABAC и внедрение.

Этот принцип не требует дополнительных инструментов — только дисциплины. Зато он существенно ограничивает «радиус поражения» при успешной атаке: даже если злоумышленник скомпрометировал одного пользователя, он не получит доступ ко всей системе.

Как защитить CMS: WordPress, Битрикс, Joomla и другие

CMS — это сердце сайта и одновременно его самое уязвимое место. Большинство атак направлено именно сюда: через устаревшие плагины, слабые настройки по умолчанию, предсказуемые URL и незакрытые функции, которые включены «на всякий случай». Хорошая новость — большинство этих проблем устраняется без единой строчки кода.

Регулярные обновления — самый простой и самый игнорируемый способ защиты

Правило железное: обновленная CMS — защищенная CMS. Необновленная — мишень.

Каждое обновление WordPress, Битрикс или Joomla закрывает конкретные уязвимости, которые к моменту выхода патча уже известны хакерам. 60% успешных атак на веб-ресурсы эксплуатируют уязвимости , для которых патч уже существовал — просто не был установлен.

Что и как обновлять:

• Ядро CMS — обновляйте в первую очередь, сразу после выхода патча. В WordPress включите автообновление минорных версий (они содержат только исправления безопасности, без риска поломки функциональности).

• Плагины и темы — обновляйте регулярно. Для WordPress: настройте автообновление для доверенных плагинов через «Плагины → Автообновления». Плагин Easy Updates Manager позволяет управлять политикой обновлений более гибко.
• PHP на сервере — многие владельцы сайтов забывают, что PHP тоже требует обновлений. PHP 7.4 уже не получает обновлений безопасности. Проверьте версию в панели хостинга и обновитесь как минимум до PHP 8.2.

Если плагин давно не обновлялся — это красный флаг. Зайдите на страницу плагина в репозитории WordPress.org и проверьте дату последнего обновления. Плагин без обновлений более года — кандидат на замену.

Специфика WordPress: как защитить самую атакуемую CMS

WordPress занимает более 43% мирового рынка CMS — именно поэтому он главная цель для автоматизированных атак. 97% уязвимостей в экосистеме WordPress приходится на плагины и темы, а не на само ядро.

Помимо обновлений, есть несколько WordPress-специфичных мер, которые существенно сужают поверхность атаки.

Смените стандартный URL страницы входа. По умолчанию это /wp-admin или /wp-login.php — боты знают это и атакуют именно туда. Плагин WPS Hide Login меняет адрес на любой произвольный за одну минуту.

Отключите XML-RPC, если не используете сторонние приложения для публикации контента (например, мобильное приложение WordPress). XML-RPC — старый протокол, который активно эксплуатируется для брутфорс-атак и DDoS-амплификации. Заблокируйте его через .htaccess

Скройте версию WordPress из публичного доступа. По умолчанию версия CMS видна в мета-тегах и RSS-лентах — это помогает ботам выбирать правильный эксплойт. Добавьте в functions.php вашей темы.

Таблица: Плагины безопасности для WordPress — сравнение трех основных решений

Для большинства сайтов достаточно Wordfence в бесплатной версии в связке с WPS Hide Login и WP 2FA.

Фильтрация и валидация пользовательских данных 

Это правило для разработчиков, но понять его должен каждый владелец сайта, который заказывает разработку: никогда не доверяйте данным, которые вводит пользователь.

Любое поле ввода на сайте — строка поиска, форма заказа, поле комментария, загрузчик файлов — потенциальная точка входа для атаки. Задача разработчика: обработать эти данные так, чтобы они не могли стать частью SQL-запроса, HTML-страницы или системной команды.

Главный инструмент против SQL-инъекций — параметризованные запросы (prepared statements). Вместо того чтобы вставлять данные пользователя напрямую в SQL-строку, используйте подстановочные параметры.

Параметризованные запросы поддерживаются в любом современном фреймворке и любой ORM. Если ваш разработчик пишет SQL-запросы конкатенацией строк — это проблема, которую нужно решить немедленно.

Принципы валидации на стороне сервера:

• Проверяйте тип данных (ожидаете число — проверьте, что пришло число)
• Проверяйте длину (ограничьте максимальную длину полей ввода)
• Используйте whitelist-подход: разрешайте только то, что точно безопасно, а не запрещайте «подозрительное»
• Экранируйте все данные перед выводом в HTML (htmlspecialchars() в PHP, встроенные механизмы в шаблонизаторах)

Безопасность файловой системы

Правильно выставленные права на файлы — это еще один рубеж, который существенно ограничивает возможности злоумышленника, уже проникшего на сервер.

Стандартная безопасная конфигурация:

# Папки: владелец может читать/писать/выполнять, остальные — только читать

# Файлы: владелец может читать/писать, остальные — только читать

# Конфигурационные файлы — только для владельца

Запретите выполнение PHP в директории загрузок. Это закрывает один из самых популярных векторов атаки — загрузку PHP-шелла под видом изображения. В .htaccess директории uploads

Заголовки безопасности HTTP — невидимая броня сайта

HTTP-заголовки безопасности — это инструкции, которые ваш сервер передает браузеру вместе со страницей. Браузер их не показывает пользователю, но строго выполняет. Они не заменяют другие меры защиты, но закрывают целый класс атак на уровне браузера.

Вот ключевые заголовки, которые стоит настроить на любом сайте:

Как проверить заголовки своего сайта: зайдите на securityheaders.com, введите адрес вашего сайта и получите оценку от F до A+. Цель — не ниже B, в идеале A. Сервис показывает, каких заголовков не хватает и что именно нужно добавить.

Капча и защита форм от автоматических атак

Любая форма на сайте — форма регистрации, вход, обратная связь, поиск — привлекает ботов. Без защиты вы получаете спам, брутфорс и нагрузку на сервер от автоматических запросов.

Варианты защиты форм:

• Google reCAPTCHA v3 — работает в фоне, не требует действий от пользователя, присваивает запросу оценку риска от 0 до 1. Бесплатно, но с 2025 года Google существенно сократил лимит бесплатных проверок.
• Cloudflare Turnstile — бесплатная альтернатива reCAPTCHA. Не требует решения задач, работает незаметно, не собирает данные для рекламных целей. Устанавливается через плагин «Simple Cloudflare Turnstile» для WordPress.
• hCaptcha — еще один независимый вариант, популярен на проектах с требованиями к приватности.
• Honeypot-метод — скрытое поле в форме, которое человек не видит и не заполняет, а бот заполняет автоматически. Простой и эффективный дополнительный фильтр без UX-нагрузки на пользователя.

Выбор конкретного решения зависит от аудитории сайта и требований к приватности данных. Для российских проектов оптимальна Яндекс SmartCaptcha — работает на серверах в РФ, соответствует 152-ФЗ и не замедляет загрузку страницы. Подробно о том, как работают разные типы капчи, чем они отличаются и как правильно их настроить, — в нашем гайде Капча: что это такое и как работает проверка на человечность.

Ограничение попыток входа (rate limiting) — отдельная мера, дополняющая капчу. После трех-пяти неверных попыток ввода пароля IP-адрес блокируется на несколько минут. В WordPress это реализуется через плагины Wordfence или WP Cerber; на уровне сервера — через Fail2Ban* (подробнее — в следующем разделе про серверную защиту).

Защита на уровне сервера и сети

WAF (Web Application Firewall) — умный фильтр трафика

WAF — это фильтр, который стоит между интернетом и вашим сайтом. Он анализирует каждый входящий HTTP/HTTPS-запрос и блокирует те, которые выглядят как атака: SQL-инъекции, XSS, CSRF, сканирование уязвимостей, вредоносные боты. До вашего сервера доходит только «чистый» трафик.

Существует два принципиально разных подхода к WAF.

Облачный WAF — вы меняете DNS-записи так, чтобы трафик шел через серверы провайдера защиты. Там он фильтруется и только потом передается на ваш хостинг. Не требует доступа к серверу, подключается за 10–30 минут.

Серверный WAF — устанавливается непосредственно на ваш сервер как модуль веб-сервера. Требует доступа к серверу и навыков администрирования.

Таблица: Сравнение основных WAF-решений

Важный нюанс про Cloudflare в России. Бесплатный план Cloudflare доступен и работает для большинства российских сайтов, однако для проектов с критичными требованиями к юрисдикции данных — рассматривайте российские альтернативы: DDoS-Guard или StormWall.

Защита от DDoS — как не упасть под мусорным трафиком

Средняя мощность DDoS-атак на российские компании в 2025 году выросла до 116 Гбит/с (+63% к 2024 году). В 2025 году 52% всех DDoS-атак стали многовекторными — то есть злоумышленник одновременно бьет по нескольким уровням сети.

Самостоятельно отразить такую атаку на уровне конфигурации сервера невозможно — для этого нужны специализированные сервисы с распределенной инфраструктурой фильтрации.

Как выбрать уровень защиты от DDoS:

• Небольшой сайт или лендинг — бесплатный план Cloudflare или DDoS-Guard закроет большинство типовых атак.
• Интернет-магазин или корпоративный сайт — нужен платный тариф с L7-фильтрацией и гарантией SLA по доступности.
• Высоконагруженный проект — специализированный провайдер (StormWall, DDoS-Guard Pro) с выделенной пропускной способностью.

Что должно быть в любом решении по защите от DDoS:

• Фильтрация на уровне L3, L4 и L7
• BGP Anycast — распределение трафика через множество точек присутствия по всему миру
• Анализ поведения трафика в реальном времени, а не только по статическим сигнатурам
• Время активации защиты — не более 15 минут (в идеале — мгновенно)

Fail2Ban — автоматическая блокировка атакующих IP

Fail2Ban — это утилита, которая следит за лог-файлами сервера и автоматически блокирует IP-адреса, с которых идут подозрительные запросы. Установил и забыл — работает в фоне круглосуточно.

Уже в первые часы после установки Fail2Ban вы увидите в логах сотни автоматически заблокированных IP-адресов — именно столько ботов непрерывно сканируют серверы в интернете.

UFW — контроль портов и сетевых соединений

UFW (Uncomplicated Firewall) — простой интерфейс для управления правилами iptables на Linux. Принцип работы: запрещаем все, разрешаем только необходимое.

Что закрыть в первую очередь: порты баз данных (3306 для MySQL, 5432 для PostgreSQL) должны быть доступны только с localhost или конкретных IP. Открытый в интернет порт базы данных — одна из наиболее распространенных точек входа при взломе.

Таблица: Итоговая карта сетевой защиты

Ни один из этих инструментов не заменяет другие — они работают в связке, перекрывая разные векторы атаки.

Резервные копии — последняя линия обороны

Представьте: все сработало — хакер обошел WAF, нашел незакрытую уязвимость, получил доступ к серверу. Или сотрудник случайно удалил базу данных. Или хостинг-провайдер потерял данные при аварии. В этот момент единственное, что стоит между вами и катастрофой, — резервная копия.

Но вот в чем проблема: в 93% атак шифровальщиков злоумышленники целенаправленно уничтожают резервные копии до того, как запустить шифрование. Они знают, что бэкап — ваш единственный спасательный круг, и первым делом его вырывают. Это значит, что бэкап, хранящийся на том же сервере или в той же сети, что и основной сайт, — не бэкап.

Стратегия 3-2-1-1-0: золотое правило резервного копирования

Классическое правило «3-2-1» появилось около 20 лет назад и до сих пор остается основой. Но в 2025–#CURRENT_YEAR# году оно эволюционировало до формулы «3-2-1-1-0».

Вот что означает каждая цифра:

Последняя цифра — самая важная и самая игнорируемая. Резервная копия, которую вы не проверяли, — это кот Шредингера: она может быть рабочей, а может содержать пустой архив, битый дамп базы данных или файлы, которые восстанавливаются с ошибками. Узнаете вы об этом только в момент катастрофы.

Если вы хотите разобраться в теме резервного копирования глубже — выбор носителей, облачные vs локальные решения, типичные ошибки при настройке — читайте наш отдельный гайд по резервному копированию данных для бизнеса.

Где хранить резервные копии

Средства хостинг-панели. Самый простой вариант — включить автоматическое резервное копирование прямо в панели управления хостингом.

• cPanel — раздел «Резервное копирование», настраивается расписание и удаленное хранилище (FTP, S3-совместимые облака).
• ISPmanager — по умолчанию выполняет бэкап раз в сутки; расписание и место хранения настраиваются в разделе «Резервные копии».

Важно: бэкапы хостинга хранятся на том же физическом оборудовании, что и ваш сайт. Если сервер провайдера упадет — потеряете и сайт, и резервные копии. Поэтому хранилище хостинга — только первый уровень, но не единственный.

Плагины для WordPress. Если у вас WordPress, настройте дополнительный бэкап через плагин с отправкой копий во внешнее облако:

• UpdraftPlus — самый популярный плагин резервного копирования для WordPress (более 3 млн установок). Поддерживает Google Drive, Яндекс.Диск, Dropbox, S3-совместимые хранилища. Расписание — от ежечасного до еженедельного. Бесплатная версия покрывает базовые потребности.
• All-in-One WP Migration — удобен для переноса сайта между хостингами, но можно использовать и для регулярных бэкапов.

Облачные хранилища. Для внешнего хранения выбирайте:

• Яндекс Object Storage — S3-совместимое хранилище, российская юрисдикция, интегрируется с большинством инструментов резервного копирования.
• Selectel Object Storage — еще один российский S3-совместимый вариант.

Автоматизация бэкапа через rclone и cron

Для VPS-серверов без графической панели управления — комбинация rclone + cron закрывает задачу автоматического резервного копирования с минимальными усилиями.

rclone — утилита командной строки, которая умеет синхронизировать файлы с десятками облачных хранилищ, включая Яндекс Object Storage и S3-совместимые сервисы. Официально поддерживается Яндекс Облаком.

Защита бэкапов от шифровальщиков

Средний выкуп, который злоумышленники требовали с российских компаний в 2024 году, составил 175 млн рублей, с пиковыми требованиями до 500 млн рублей. При этом один из зафиксированных кейсов 2025 года — атака на российский интернет-магазин через систему 1С — завершилась шифрованием данных и удалением 30% резервных копий, после чего последовало требование выкупа в 20 млн рублей.

Чтобы бэкапы выжили при атаке шифровальщика, нужны:

Иммутабельность (Object Lock / WORM). При хранении бэкапов в S3-совместимом облаке (Яндекс Object Storage, Selectel) включите версионность и Object Lock в режиме Compliance. Данные с таким параметром нельзя удалить или перезаписать до истечения срока удержания — даже с правами администратора.

Изоляция учетных данных. Ключи доступа к хранилищу бэкапов должны существовать отдельно от ключей основной инфраструктуры. Учетная запись для бэкапа — права только на запись (PutObject), но не на удаление (DeleteObject). Если злоумышленник скомпрометирует основной сервер, он не должен иметь возможности добраться до резервных копий.

Физическая или логическая изоляция. Хотя бы одна копия должна быть недоступна из сети, где работает основной сайт: отдельное облако с другими учетными данными, внешний жесткий диск, который подключается только во время бэкапа, или лентовый носитель. Это и есть принцип «воздушного зазора» (air gap).

Как тестировать резервные копии — и почему это делают единицы

Рекомендуемая частота тестового восстановления из бэкапа — раз в месяц или квартал. На практике большинство владельцев сайтов не проверяют бэкапы никогда — до тех пор, пока они не понадобятся по-настоящему.

Типичные причины, по которым бэкап оказывается нерабочим:

• Архив создается, но внутри — пустая директория (скрипт был прописан с ошибкой в пути)
• Дамп базы данных сохраняется без данных (проблема с правами пользователя БД)
• Файлы восстанавливаются, но сайт не запускается — не хватает конфигурационных файлов или переменных окружения
• Архив есть, но пароль от него утерян или неизвестен новому администратору

Минимальный чек-лист проверки бэкапа:

• Разверните копию на тестовом домене или поддомене (например, test.yoursite.ru)
• Убедитесь, что сайт запускается и все страницы открываются корректно
• Проверьте, что база данных содержит актуальные данные (например, последний заказ или публикацию)
• Замерьте время восстановления — это ваш реальный RTO (Recovery Time Objective), который важно знать заранее, а не в момент кризиса

Тест восстановления занимает 30–60 минут раз в квартал. Стоимость пренебрежения им — потенциально весь бизнес.

Мониторинг, аудит и действия при взломе

Взлом редко происходит мгновенно. Злоумышленник часто «сидит» в системе днями и неделями, прежде чем нанести удар. Мониторинг — это возможность заметить угрозу до катастрофы, а не после.

Почему мониторинг критичен

В 2025 году среднее время присутствия атакующего в скомпрометированной инфраструктуре до обнаружения составило несколько недель. За это время он успевает собрать данные, установить бэкдоры и подготовить следующий удар. Ранее мониторинг считался уделом крупных компаний — сегодня базовые инструменты доступны бесплатно.

Мониторинг доступности сайта

Первое, что нужно знать: сайт работает или нет. Для этого достаточно бесплатных сервисов.

• UptimeRobot — до 50 мониторов бесплатно, проверка каждые 5 минут, уведомления в Telegram/email/Slack. Отслеживает HTTP-статусы, SSL-сертификаты, ключевые слова на странице.
• Better Uptime — бесплатный тариф, красивые страницы статуса, интеграция с PagerDuty.
• Яндекс.Вебмастер → «Безопасность и нарушения» — Яндекс уведомляет о вирусах и взломе на сайте напрямую, бесплатно.
• Google Search Console → «Проблемы безопасности» — аналогичный инструмент для Google.

Настройте уведомления так, чтобы получать алерт в течение 1–5 минут после падения. Каждая минута простоя в пиковое время — потеря реальных денег и позиций.

Таблица: Сканирование на вредоносный код

Sucuri SiteCheck — самый быстрый старт: вставьте URL, получите отчет за 30 секунд. Для WordPress — добавьте плагин Sucuri Security, он запускает сканирование по расписанию.

WPScan — запускается из терминала или через бесплатный API

Флаги: vp — уязвимые плагины, vt — уязвимые темы, u — перечисление пользователей.

Анализ логов сервера

Логи — «черный ящик» любого взлома. Большинство следов взлома можно восстановить именно из /var/log.

Главные файлы логов:

• /var/log/nginx/access.log — все HTTP-запросы к сайту
• /var/log/nginx/error.log — ошибки и подозрительные события
• /var/log/auth.log — попытки входа по SSH
• /var/log/syslog — системные события

Выдает интерактивный дашборд прямо в терминале: топ IP, топ запросов, статус-коды, трафик по часам.

Таблица: Периодичность аудита

Что делать, если сайт взломан: пошаговый план

Обнаружили взлом — не паникуйте. Первые 30 минут определяют масштаб ущерба.

Шаг 1 — Изоляция (первые 5 минут)
Включите режим обслуживания или временно закройте сайт. Смените все пароли: хостинг, FTP/SFTP, БД, CMS-администратор, почта. Отзовите все активные сессии.

Шаг 2 — Фиксация доказательств (5–15 минут)
Сделайте резервную копию текущего состояния (даже зараженного) — для криминалистического анализа. Сохраните логи доступа и ошибок за последние 30 дней.

Шаг 3 — Выявление точки входа (15–60 минут)
Проверьте логи на подозрительные запросы. Найдите измененные файлы за последние 7–14 дней. Проверьте наличие веб-шеллов (файлы shell.php, c99.php, r57.php, cmd.php).

Шаг 4 — Очистка

• Удалите вредоносные файлы вручную или через антивирус хостинга (ImunifyAV).
• Восстановите чистые файлы CMS из официального дистрибутива.
• Если ситуация сложная — разверните сайт из чистой резервной копии на изолированном окружении, убедитесь в ее чистоте, затем замените production.

Шаг 5 — Закрытие уязвимости
Найдите и устраните причину взлома: обновите уязвимый плагин, удалите заброшенную тему, закройте открытый FTP-порт. Восстановление без устранения причины = повторный взлом в течение часов.

Шаг 6 — Уведомление (если был взлом с утечкой ПД)
По 152-ФЗ вы обязаны уведомить Роскомнадзор в течение 24 часов с момента обнаружения инцидента, а в течение 72 часов — предоставить полный отчет об ущербе. Игнорирование — штраф.

Шаг 7 — Запрос на пересмотр в поисковиках
Если сайт попал в блэклист Google или Яндекса — устраните вредоносный код, затем отправьте запрос на пересмотр через Google Search Console и Яндекс.Вебмастер. Среднее время снятия пометки — 1–3 рабочих дня.

Правовой контекст, SEO-последствия взлома и итоговый чек-лист

Правовой контекст: что требует закон

Многие владельцы сайтов воспринимают безопасность как исключительно техническую задачу. Это ошибка. Если ваш сайт собирает любые данные пользователей — имена, email, телефоны, адреса доставки — вы являетесь оператором персональных данных по 152-ФЗ и несете юридическую ответственность за их защиту.

Главные изменения в законе. С 30 мая 2025 года в России существенно выросли штрафы за нарушения в сфере персональных данных.

В #CURRENT_YEAR# году ряд штрафов был удвоен по сравнению с предыдущей редакцией закона.

Если ваша компания относится к субъектам критической информационной инфраструктуры или обрабатывает специальные категории персональных данных, часть инструментов должна быть сертифицирована. Что это значит на практике — в гайде Реестр сертифицированных средств защиты ФСТЭК.

Что обязан сделать оператор ПД:

• Разместить на сайте политику конфиденциальности и форму согласия на обработку данных.
• Хранить ПД граждан РФ на серверах, физически расположенных в России (ст. 18.1 152-ФЗ).
• При обнаружении утечки — уведомить Роскомнадзор в течение 24 часов, а полный отчет об ущербе предоставить в течение 72 часов.
• Применять организационные и технические меры защиты: шифрование, разграничение доступа, аудит.

Для интернет-магазинов — дополнительно PCI DSS. Если сайт принимает оплату картами, с марта 2025 года обязателен стандарт PCI DSS 4.0.1. Он включает 12 требований: защищенная сеть, защита данных держателей карт, управление уязвимостями, контроль доступа, мониторинг и регулярное тестирование. Несоответствие грозит штрафами от платежных систем и отключением от эквайринга.

Взлом сайта: угроза не только безопасности, но и SEO

Кибератака способна нанести серьезный ущерб поисковой видимости ресурса. После взлома сайт может потерять значительную часть органического трафика, а возвращение прежних позиций требует времени и усилий.

Механизм следующий: Google и Яндекс регулярно сканируют сайты на наличие вредоносного кода. Как только малварь обнаружен, поисковик:

• Помечает сайт в выдаче предупреждением «Этот сайт может нанести вред вашему компьютеру» — кликабельность (CTR) падает на 60–80%.
• Добавляет домен в базы блэклистов (Google Safe Browsing, Яндекс.Безопасный браузер), которые используют Chrome, Firefox, Safari.
• Может полностью исключить страницы из индекса.

Типичные последствия взлома для SEO: потеря органического трафика на 50–90%, падение позиций по всем коммерческим запросам, санкции в разделе «Ручные меры» Google Search Console.

Как снять пометку после взлома:

1. Очистить сайт от вредоносного кода (см. предыдущий раздел).
2. Убедиться в чистоте через Sucuri SiteCheck и VirusTotal.
3. В Google Search Console → «Безопасность и ручные меры» → отправить запрос на пересмотр с описанием принятых мер.
4. В Яндекс.Вебмастере → «Безопасность и нарушения» → также подать заявку на повторную проверку.
5. Среднее время снятия пометки: 1–5 рабочих дней у Google, 3–7 дней у Яндекса.

Мнение эксперта

Дмитрий Коноваленко — совладелец и операционный директор digital-агентства MWI (входит в ТОП-10 Рейтинга Рунета). Отвечает за операционное управление компанией, бизнес-процессы, контроль качества реализации проектов и работу с ключевыми клиентами. Автор Telegram-канала «Предпринимательство и digital». Эксперт в области веб-разработки, технической архитектуры интернет-проектов и автоматизации бизнес-процессов. Практик с 15+ годами опыта в digital и e-commerce.

Злоумышленники продолжают исследовать уязвимости для подготовки сложных атак с нанесением максимального ущерба. Именно поэтому они уделяют столько внимания отраслям, заметным обществу и влияющим на качество жизни: транспорту, логистике, органам власти и ритейлу.

За 2025 год зафиксировано 3,3 млрд веб-атак — рост на 89% к 2024 году. Среднее число атак на одну компанию выросло в 1,6 раза. Большинство из них — это автоматизированные боты, которые сканируют веб-приложения в поисках известных уязвимостей. Вывод один: атаки не прекратятся. Они станут умнее.

В #CURRENT_YEAR# году ИИ становится главным катализатором киберугроз: сложные персонализированные атаки теперь доступны даже низкоквалифицированным хакерам. Это означает, что порог входа для атакующих снизился, а значит, под удар все чаще попадают сайты малого бизнеса, интернет-магазины и небольшие корпоративные ресурсы, которые раньше казались слишком незначительными целями.

Мой главный совет: не ждите инцидента. Важно настроить WAF, включить мониторинг, регулярно обновлять зависимости и выстроить парольную политику — это не «на потом», а базовая гигиена #CURRENT_YEAR# года.

FAQ — ответы на главные вопросы по гайду

Мой сайт маленький, зачем его взламывать?

Размер не защищает. Маленькие сайты взламывают не потому, что они ценны сами по себе, а потому что они слабо защищены. Скомпрометированный ресурс используют для рассылки спама, майнинга криптовалюты, DDoS-атак на третьих лиц и перенаправления трафика. Большинство атак полностью автоматизированы — боты сканируют миллионы сайтов в сутки и атакуют всех уязвимых подряд.

Достаточно ли бесплатного SSL от Let’s Encrypt?

Для абсолютного большинства сайтов — да. Let’s Encrypt обеспечивает тот же уровень шифрования AES-256, что и платные сертификаты за десятки тысяч рублей. Платные сертификаты OV и EV нужны там, где важна публичная верификация организации: банки, государственные порталы, крупный e-commerce. Для блога, лендинга или корпоративного сайта МСБ Let’s Encrypt — полноценное решение.

Как часто нужно обновлять плагины WordPress?

Немедленно после выхода обновления, особенно если оно содержит исправление безопасности (security fix). 97% уязвимостей WordPress связаны с плагинами и темами, причем эксплуатация начинается в среднем через 24–48 часов после публикации CVE. Настройте автоматические обновления для CMS-ядра и проверяйте плагины хотя бы раз в неделю.

WAF заменяет все остальные меры защиты?

Нет. WAF — это один слой защиты, который фильтрует вредоносные HTTP-запросы. Он не защитит от украденных паролей, уязвимостей в SSH, зараженных файлов через FTP или атак изнутри сети. Безопасность работает по принципу «глубокой эшелонированной обороны»: WAF + надежные пароли + 2FA + обновления + бэкапы + мониторинг.

Что важнее — защита или резервные копии?

Это не выбор «или–или». Защита снижает вероятность взлома, резервные копии гарантируют восстановление, если он все же произошел. В 93% ransomware-атак злоумышленники уничтожают бэкапы перед шифрованием. Именно поэтому копии должны быть иммутабельными и храниться изолированно — тогда они недоступны для атакующего.

Нужно ли уведомлять Роскомнадзор, если сайт взломан?

Это зависит от того, произошла ли утечка персональных данных. Если да — вы обязаны уведомить РКН в течение 24 часов с момента обнаружения инцидента и предоставить полный отчет в течение 72 часов. Даже если данные не утекли, рекомендуется зафиксировать инцидент внутри компании — на случай проверки.

Хостинг сам обеспечивает безопасность сайта?

Частично. Хороший хостинг защищает физическую инфраструктуру, изолирует аккаунты, предоставляет антивирус и бэкапы на уровне сервера. Но код вашего сайта, пароли, настройки CMS и плагины — ваша ответственность. Разделение ответственности называется моделью shared responsibility: хостинг отвечает за платформу, владелец — за приложение.

Заключение

Безопасность сайта — это не разовая настройка, а непрерывный процесс. Угрозы эволюционируют: в 2025 году веб-атак стало больше на 89%, а в 2026-м ИИ делает их доступными для хакеров любого уровня. Хорошая новость в том, что большинство успешных взломов — результат базовых ошибок, которые устраняются за один вечер: устаревший плагин, слабый пароль, отсутствие 2FA.

Термины и сноски

* 2FA (двухфакторная аутентификация) — метод входа, при котором помимо пароля требуется второй фактор: одноразовый код из приложения, SMS или аппаратный ключ. Делает брутфорс практически бессмысленным даже при компрометации пароля.

* Брутфорс (Brute Force) — метод атаки путем автоматического перебора паролей или ключей. В 2025 году таких атак стало в 2,7 раза больше, чем в конце 2024-го.

* WAF (Web Application Firewall) — межсетевой экран уровня веб-приложений. Анализирует HTTP-трафик и блокирует вредоносные запросы: SQLi, XSS, CSRF, DDoS уровня L7.

* CVE (Common Vulnerabilities and Exposures) — международная база данных публично известных уязвимостей с уникальными идентификаторами. Например, CVE-2024-XXXXX. Служит ориентиром при обновлении ПО.

* CSRF (Cross-Site Request Forgery) — атака, при которой браузер авторизованного пользователя отправляет вредоносный запрос от его имени. Защита — уникальные CSRF-токены в формах.

* CSP (Content Security Policy) — HTTP-заголовок безопасности, ограничивающий источники загрузки скриптов, стилей и медиа. Главная защита от XSS-атак.

* Дефейс — вид атаки, при котором злоумышленник подменяет содержимое страниц сайта своим: политическим заявлением, рекламой или просто демонстрацией факта взлома.

* Малварь (Malware) — вредоносное программное обеспечение: вирусы, трояны, шифровальщики, шпионы, майнеры. На сайте малварь чаще всего попадает через уязвимые плагины или скомпрометированные FTP-доступы.

* Пентест (Penetration Testing) — контролируемая атака на собственную инфраструктуру с целью выявления уязвимостей до того, как их найдут злоумышленники. Проводится профессиональными специалистами по ИБ.

* Rate Limiting — ограничение числа запросов с одного IP-адреса за единицу времени. Защищает от брутфорса форм входа и DDoS-атак уровня L7.

* SQL-инъекция (SQLi) — атака, при которой злоумышленник вставляет вредоносный SQL-код в поля ввода. Может дать полный доступ к базе данных сайта. Защита — параметризованные запросы (prepared statements).

* SSL/TLS — криптографические протоколы для защищенной передачи данных в сети. SSL — устаревшее название, актуальная версия — TLS 1.3. Именно они обеспечивают HTTPS.

* Fail2Ban — утилита для Linux, которая анализирует логи и автоматически блокирует IP-адреса, с которых зафиксированы многократные неудачные попытки входа (SSH, FTP, веб-формы).

* XSS (Cross-Site Scripting) — атака, при которой вредоносный JavaScript-код внедряется в страницы сайта и выполняется в браузере посетителя. Используется для кражи сессий, cookies и редиректов.

Категория вопроса

Что мы можем предложить?