В январе 2026-го владелец небольшого интернет-магазина из Воронежа обнаружил, что его сайт третий день майнит криптовалюту для кого-то другого. Антивирус молчал, посещаемость не упала — просто сервер стал тормозить. Причина? Устаревший плагин для отзывов, который не обновляли полтора года. Через него бот залил скрипт-майнер за 11 минут после публикации информации об уязвимости.
Это не выдуманная страшилка — таких историй десятки каждый день. Разберёмся, как не стать следующим.
Коротко для тех, кто спешит
Если нет времени читать всю статью — вот минимум, который закроет 80% рисков:
- Включите автообновление CMS, плагинов и серверного ПО
- Поставьте многофакторную аутентификацию на всё, куда можно войти с паролем
- Подключите облачный WAF (Cloudflare, например — есть бесплатный тариф)
- Настройте ежедневные бэкапы с хранением вне основного сервера
- Удалите плагины и библиотеки, которыми не пользуетесь
Сделали? Хорошо. Теперь можно углубиться.
Что изменилось в угрозах
Два года назад для взлома типового сайта на WordPress хакеру нужно было потратить вечер на разведку: просканировать порты, определить версии ПО, подобрать эксплойт. Сейчас эту работу делает ИИ-агент за минуты. Языковые модели генерируют эксплойты под конкретную конфигурацию, пишут убедительные фишинговые письма администраторам и даже обходят простые CAPTCHA.
Ещё одна неприятная тенденция — атаки через цепочки поставок. В марте 2025-го скомпрометированный npm-пакет event-stream-pro (не путать с оригинальным event-stream) попал в зависимости нескольких тысяч проектов. Вредоносный код тихо сливал переменные окружения — а в них часто лежат ключи от баз данных и API. Владельцы сайтов, которые не проверяли свои зависимости, узнали о проблеме только после утечки данных.
Скорость тоже изменилась. Между публикацией информации об уязвимости и массовым сканированием интернета на её наличие проходит 3–6 часов. Не дней — часов.
Уровень первый: для тех, кто начинает с нуля
Если вы до сих пор не занимались безопасностью системно — не страшно, но начинать нужно сегодня. Вот с чего.
Обновления — самое простое и самое эффективное действие. Настройте автоматические обновления для CMS и плагинов. Для серверного ПО — хотя бы автоматические уведомления о новых патчах. Да, иногда обновление ломает совместимость. Но сломанная вёрстка на полчаса — это несопоставимо лучше, чем украденная база клиентов.
Многофакторная аутентификация. Ставьте на админку сайта, на хостинг-панель, на доступ к серверу по SSH, на почту администратора. Лучший вариант — аппаратный ключ YubiKey или аналог. Приложение-аутентификатор (Google Authenticator, Authy) тоже подойдёт. SMS — хуже: перевыпуск SIM-карты через сговор с сотрудником салона связи стоит копейки и занимает полчаса.
HTTPS. Если у вас до сих пор нет сертификата — зайдите на сайт Let's Encrypt, потратьте десять минут, настройте. Используйте TLS 1.3, старые версии протокола отключите в конфигурации веб-сервера. В nginx это одна строчка:
ssl_protocols TLSv1.3;
Удалите всё лишнее. Плагин для галереи, который поставили три года назад и забыли? Тема оформления, которая не используется? Тестовый поддомен с phpMyAdmin без пароля? Всё это — двери, которые вы оставили открытыми.
Уровень второй: крепкая оборона
Базу закрыли — идём дальше.
WAF: щит перед сайтом. Web Application Firewall анализирует входящий трафик и отсекает вредоносные запросы до того, как они дойдут до вашего кода. Cloudflare на бесплатном тарифе уже даёт базовую защиту. Платные решения (Cloudflare Pro, AWS WAF, Sucuri) добавляют поведенческий анализ и защиту от DDoS. Настраивается за час, а разницу вы увидите сразу — в логах резко упадёт количество мусорных запросов.
Content Security Policy. Добавьте CSP-заголовок, который скажет браузеру: выполняй скрипты только с моего домена и с CDN, который я явно разрешил. Даже если злоумышленник внедрит вредоносный тег <script> на страницу, браузер его проигнорирует. Начните с режима report-only — он не блокирует, а только логирует нарушения. Так вы увидите, что сломается, прежде чем включать строгий режим.
Защита API. Если ваш сайт отдаёт данные через API — а сейчас это почти любой сайт сложнее визитки — каждый эндпоинт должен требовать аутентификацию. Ограничьте количество запросов с одного IP (rate limiting). Валидируйте всё, что приходит от клиента. Не доверяйте ничему — ни заголовкам, ни параметрам, ни телу запроса.
Мониторинг. Без него вы слепы. Минимальный набор: оповещение о неудачных попытках входа в админку, алерт при изменении файлов ядра CMS, уведомление о всплесках 404-ошибок (признак сканирования). Для WordPress есть Wordfence, для произвольных проектов — связка Fail2ban + централизованные логи через Grafana Loki или аналог.
Уровень третий: для тех, кто хочет спать спокойно
Здесь начинается территория, на которую заходят далеко не все. Но если ваш сайт обрабатывает платежи, хранит персональные данные или просто приносит деньги — стоит.
Контейнеризация меняет правила игры при компрометации. Когда каждый компонент — веб-сервер, бэкенд, база — живёт в отдельном Docker-контейнере, взлом одного не даёт автоматического доступа к остальным. Но контейнер — не магическая стена. Запускайте процессы внутри от непривилегированного пользователя, используйте минимальные базовые образы (Alpine вместо Ubuntu), сканируйте образы через Trivy или Grype перед деплоем.
Сегментация сети. База данных не должна быть доступна из интернета. Вообще. Она общается только с бэкендом, бэкенд — только с веб-сервером. Между сегментами — файрвол с белым списком разрешённых соединений. Если вы на VPS и не хотите разбираться с VLAN — хотя бы настройте iptables так, чтобы порт MySQL/PostgreSQL слушал только localhost.
Аудит зависимостей. Встройте в CI/CD-пайплайн проверку через Snyk или Dependabot. Пусть деплой автоматически блокируется, если в зависимостях найдена критическая уязвимость. Фиксируйте версии через lock-файлы (package-lock.json, composer.lock, Pipfile.lock) и проверяйте хеши пакетов. Раз в квартал проводите ручную ревизию: что из зависимостей реально используется, а что тянется по инерции.
Immutable-бэкапы. Обычный бэкап шифровальщик зашифрует вместе с основными данными — если до него можно дотянуться с того же сервера. Храните хотя бы одну копию в хранилище с политикой WORM (Write Once Read Many). У AWS это S3 Object Lock, у других провайдеров — аналогичные механизмы. И раз в месяц проверяйте, что из бэкапа реально можно восстановиться. Серьёзно — разверните тестовую копию и убедитесь, что всё работает.
Постквантовая криптография: не паника, но и не игнор
Квантовые компьютеры, способные сломать RSA, пока не построены. Но спецслужбы и крупные группировки уже сейчас перехватывают зашифрованный трафик с расчётом расшифровать его через 5–10 лет, когда технология дозреет. Если ваш сайт работает с данными, которые останутся конфиденциальными и в 2035-м — медицинские записи, финансовые документы, юридическая переписка — это ваш случай.
NIST утвердил постквантовые стандарты (ML-KEM, ML-DSA). Cloudflare и Google уже поддерживают гибридные схемы шифрования в своих сервисах. Проверьте настройки вашего CDN и хостинга — возможно, включить постквантовую защиту можно одним переключателем.
Люди ломаются быстрее серверов
Можно настроить идеальную инфраструктуру, а потом ваш контент-менеджер получит письмо «Ваш хостинг заблокирован, срочно подтвердите данные» — и введёт пароль на фишинговой странице. В 2026-м такие письма генерирует нейросеть: правильный стиль, актуальный контекст, домен отличается от настоящего одним символом.
Что с этим делать? Проводите тестовые фишинговые рассылки для своей команды — сервисы вроде GoPhish позволяют это делать бесплатно. Разбирайте результаты без наказаний, но с обучением. Установите правило: любые действия с доступами — только через закладки в браузере, никогда по ссылкам из писем.
Ноутбуки и телефоны администраторов — отдельная зона риска. Шифрование диска (BitLocker, FileVault), менеджер паролей (Bitwarden, KeePass), VPN при работе из кафе или коворкинга. Если на ноутбуке разработчика лежат SSH-ключи от продакшена без парольной фразы — считайте, что ключи от сервера лежат на столике в «Шоколаднице».
Когда всё-таки взломали
Допустим, худшее случилось. Что дальше?
Если у вас нет плана — начнётся хаос. Кто-то побежит выдёргивать сервер из розетки, кто-то начнёт менять пароли не в том порядке, кто-то вообще не поймёт, что происходит.
Подготовьте план заранее. Он не должен быть на 50 страниц — хватит одного листа с ответами на вопросы: кто принимает решение об отключении сайта? Кто изолирует заражённый компонент? В каком порядке восстанавливаем из бэкапа? Кого уведомляем — пользователей, Роскомнадзор (если утекли персональные данные, по закону у вас 24 часа), полицию?
Проведите учебную тревогу хотя бы раз. Соберите команду, озвучьте сценарий («шифровальщик зашифровал базу данных, последний бэкап — вчерашний»), пройдите по плану. Вы удивитесь, сколько дыр обнаружится.
Юридическая сторона
Штрафы за утечку персональных данных в России выросли. Если вы собираете имена, телефоны, адреса электронной почты — вы оператор персональных данных, и у вас есть обязательства по 152-ФЗ. Проверьте: есть ли на сайте политика обработки персональных данных? Собираете ли вы согласия? Можете ли удалить данные пользователя по запросу? Где физически хранится база — в России или за рубежом?
Если работаете с европейскими пользователями — добавьте GDPR. Если принимаете платежи картами — PCI DSS. Это не бюрократия ради бюрократии: в случае инцидента наличие задокументированных мер защиты — ваш аргумент в суде и перед регулятором.
Идеальной защиты не бывает. Но есть разница между сайтом, который взломают за 11 минут через забытый плагин, и сайтом, на который злоумышленник потратит неделю — и переключится на цель попроще. Всё, что описано выше, сдвигает вас из первой категории во вторую. А начать можно прямо сейчас — с того самого чеклиста в начале статьи.