Безопасность сайта: как защитить его от взлома

Почему атакуют даже маленькие сайты

Начнём с главного заблуждения, которое мы слышим на каждой второй встрече: «Кому мы нужны? У нас пять страниц и три заявки в неделю». Это звучит логично — и именно поэтому такие сайты падают чаще всего.

Дело в том, что вас никто не выбирал. Подавляющее большинство атак на малый и средний бизнес не персональные. Работают программы: они берут списки доменов и IP-адресов, обходят их подряд и проверяют десятки известных дыр. Бот не знает, что вы стоматология из Полтавы или студия керамики. Он видит строку в ответе сервера, узнаёт версию популярной CMS, сверяется со своим списком и идёт дальше, если не совпало. Совпало — начинает работать.

Это как проверять ручки припаркованных машин. Никто не выбирал именно вашу — просто она оказалась незапертой.

Зачем вообще ломать сайт-визитку

У взломщика редко есть цель «навредить именно вам». У взломанного сайта есть рыночная стоимость, и она складывается из нескольких вещей:

• Ссылочный вес. На ваши страницы тихо добавляют ссылки или целые скрытые разделы про казино, займы, аптеки. Вы этого не видите — а поисковик видит.
• Трафик. Ваших посетителей начинают перенаправлять на чужие страницы, но не всех: часто только мобильных, только с поиска и только один раз в сутки на человека. Поэтому вы, заходя на сайт со своего компьютера, ничего не замечаете месяцами.
• Ресурсы сервера. Ваш хостинг превращается в узел для рассылки спама, майнинга или атак на другие сайты.
• Данные. База с заявками, телефонами, адресами и почтой — это готовый товар. Даже если у вас «просто форма обратной связи».
• Вымогательство. Файлы шифруются или удаляются, а вам предлагают заплатить за возврат.

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

Что обычно замечают первым

Симптомы взлома чаще всего приходят не от вас, а извне. Хостинг присылает письмо о подозрительной активности. Google Search Console показывает предупреждение. Клиент звонит и говорит, что браузер ругается на сайт. Почта компании начинает попадать в спам у всех подряд. Трафик из поиска падает без видимой причины. Если что-то из этого случилось — считайте, что вы узнали об этом поздно, но не безнадёжно поздно.

Как сайты ломают на самом деле

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

Устаревшая CMS и особенно плагины

Это чемпион с огромным отрывом. WordPress, Joomla, OpenCart, любая популярная система — сами по себе не дырявые. Проблема в экосистеме: плагин для галереи, который не обновлялся с 2021 года, тема, купленная когда-то на маркетплейсе и заброшенная автором, модуль формы, который поставил подрядчик и забыл.

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

Слабые и, что хуже, повторяющиеся пароли

Пароль Admin2024! кажется сложным — в нём есть заглавная, цифры и восклицательный знак. Он есть в словарях подбора. Но настоящая беда не в этом. Настоящая беда — один и тот же пароль в панели хостинга, в админке сайта, в почте и в личном кабинете сервиса, который однажды утёк. Утечка чужой базы превращается в вход в ваш сайт, и никакого «взлома» технически не происходит: злоумышленник просто вводит логин и пароль.

Утечка учётных данных через компьютер сотрудника

Классика, которую почти никогда не подозревают. FTP-пароли, сохранённые в файловом менеджере на ноутбуке дизайнера, вычитываются обычным вирусом. Сайт «ломают» через легальный доступ. Признак: вы всё почистили, а заражение вернулось через два дня.

Незащищённые формы и открытые точки входа

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

Лишние файлы в корне сайта

Тихий убийца, который мы находим постоянно. В корневой папке живут: backup.zip от прошлого подрядчика, dump.sql с полной базой, папка .git со всей историей проекта и паролями в старых коммитах, файл test.php, info.php, копия конфига с именем config.php.bak. Всё это доступно по прямой ссылке любому, кто её угадает. А боты не угадывают — у них есть списки типовых имён, и они проверяют их за секунды.

Отдельно про .bak и .old: сервер не выполняет такие файлы как код, а отдаёт их текстом. То есть отдаёт содержимое конфига с паролем к базе данных прямо в браузер.

Забытые и брошенные проекты

Старый лендинг акции на поддомене. Тестовая копия сайта, которую делали два года назад и не удалили. Форум, которым никто не пользуется. Их не обновляют, потому что о них не помнят. При этом они часто лежат на том же аккаунте хостинга — и взлом заброшенного лендинга даёт доступ к файлам основного сайта. Мы всегда начинаем аудит с вопроса «а что ещё висит на этом аккаунте?», и ответ регулярно удивляет самого владельца.

HTTPS и SSL-сертификат: почему это уже не обсуждается

Если у вас нет HTTPS, дальше можно не читать — сначала закройте это. В 2026 году сайт без шифрования — это не «экономия», а неисправность.

Что делает SSL-сертификат простыми словами

Без HTTPS данные между браузером посетителя и вашим сервером идут открытым текстом. Их видит и может изменить любой, кто находится на пути: владелец Wi-Fi в кафе, провайдер, оборудование в промежуточной сети. Видит — значит, читает пароли и содержимое форм. Может изменить — значит, способен подменить контент вашей страницы или вставить в неё чужую рекламу, и посетитель будет уверен, что это вы.

SSL-сертификат решает две задачи одновременно. Он шифрует канал и подтверждает, что домен принадлежит тому, кто его обслуживает. Второе не менее важно первого: без подтверждения подлинности шифрование бесполезно, потому что вы можете шифровать канал с мошенником.

Практические вещи, которые важнее самого сертификата

Сертификат сегодня получить бесплатно и автоматически — Let's Encrypt закрыл этот вопрос для всех. Поэтому ошибки давно не в «есть или нет», а в деталях настройки:

• Редирект. Все запросы по HTTP должны постоянным редиректом уходить на HTTPS. Иначе старая версия просто продолжает работать параллельно.
• Смешанный контент. Страница загружается по HTTPS, но подтягивает картинку, шрифт или скрипт по HTTP. Браузер ругается, а замок в адресной строке пропадает. Особенно часто это старые скрипты аналитики и виджеты.
• Автопродление. Сертификат живёт недолго и продлевается роботом. Если робот сломался, вы узнаете об этом от клиентов в самый неудачный день. Мониторинг срока — обязателен.
• Канонические адреса. После перехода на HTTPS проследите, чтобы одна страница была доступна по одному адресу, а не по четырём вариантам с www и без.

Чего HTTPS не делает

Здесь живёт опасное заблуждение. Замочек в браузере не означает, что сайт безопасен. Он означает ровно одно: канал до сервера зашифрован. Взломанный сайт с вирусом в коде прекрасно работает по HTTPS, и замочек на месте. Мошеннический фишинговый сайт тоже имеет сертификат — его выдают бесплатно и автоматически всем. HTTPS — это фундамент, а не крыша.

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

Заголовки безопасности: тихая защита, которую почти никто не включает

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

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

Content-Security-Policy (CSP)

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

Честное предупреждение: CSP легко сломать сайт, если включить его наспех. Правильный путь — сначала режим только отчётов, сбор нарушений, потом ужесточение. На сайте с десятком сторонних виджетов это работа на несколько дней, а не на десять минут.

Strict-Transport-Security (HSTS)

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

X-Frame-Options

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

X-Content-Type-Options

Одна строка, никаких настроек. Запрещает браузеру «догадываться» о типе файла вопреки тому, что сказал сервер. Без него загруженная картинка при определённых условиях может быть истолкована браузером как скрипт и выполнена.

Referrer-Policy

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

Permissions-Policy

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

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

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

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

Почему обновления откладывают

Не из лени. Из страха. Однажды обновление сломало вёрстку или отвалилась корзина — и с тех пор кнопку «обновить» обходят стороной. Страх обоснованный: обновление действительно может что-то сломать, особенно если сайт собран из плагинов, которые правили напильником прямо в коде.

Но математика неумолима. Риск сломать вёрстку — это час работы. Риск взлома — это восстановление из бэкапа, чистка, объяснения с клиентами и месяцы возврата позиций в поиске. Второй риск дороже первого на порядок.

Как обновляться без паники

1. Сделайте бэкап до, а не после. Полный: файлы и база. Без этого шага дальше не идём никогда.
2. Заведите тестовую копию. Отдельная площадка, закрытая от индексации и от посторонних, где обновление проверяется до боя. Для серьёзного проекта это обязательный элемент.
3. Разделите критику и рутину. Обновления безопасности ставятся сразу, минорные — по расписанию, крупные версии — как отдельный проект с планом.
4. Проверьте главное после. Отправка формы, оплата, вход в кабинет, отображение на телефоне. Три минуты ручной проверки экономят недели.

Ревизия чужого кода

Раз в квартал открывайте список плагинов и задавайте два вопроса. Первый: используется ли это вообще? Плагин, который стоит «на всякий случай», — это дыра без функции. Отключённый плагин, кстати, продолжает лежать в файловой системе и может быть уязвим, поэтому неиспользуемое надо удалять, а не выключать.

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

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

Доступы и хостинг: гигиена, которая решает больше, чем код

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

Принцип минимальных прав

У каждого человека и каждой программы должно быть ровно столько прав, сколько нужно для работы, и ни каплей больше. Контент-менеджеру не нужны права администратора — ему нужно публиковать статьи. Подрядчику, который правит одну страницу, не нужен доступ к базе данных. Скрипту, который читает каталог, не нужны права на запись.

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

Отдельные аккаунты для отдельных людей

Общий логин admin с паролем в переписке — это отсутствие ответственности. Когда что-то происходит, в логах вы видите «зашёл admin», и это не говорит вам ровным счётом ничего. Отдельные аккаунты дают две вещи: понятную историю действий и возможность отозвать доступ одного человека, не меняя пароли всей компании.

Двухфакторная аутентификация

Если внедрить только один пункт из всей статьи — внедряйте этот. 2FA обесценивает украденный пароль. Все атаки подбора и все утечки чужих баз перестают работать против вас, потому что пароля недостаточно. Включите её везде, где она есть: панель хостинга, регистратор домена, админка сайта, почта, Cloudflare, GitHub.

Особо о регистраторе домена. Это самая недооценённая точка. Потеря контроля над доменом хуже потери сайта: сайт восстанавливается из бэкапа за час, а домен возвращается месяцами через переписку с поддержкой, если возвращается вообще.

SSH-ключи вместо паролей, и никакого FTP

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

И отдельно: откажитесь от обычного FTP. Он передаёт логин и пароль открытым текстом, как в девяностые. Только SFTP или SSH. Если хостинг предлагает вам FTP как основной способ — это сигнал о качестве хостинга.

Менеджер паролей вместо памяти

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

Формы, спам и ограничение частоты запросов

Форма обратной связи — самое доступное место вашего сайта. Она открыта всем, работает без авторизации и ждёт данных. Логично, что именно её нагружают чаще всего.

Почему CAPTCHA — не полное решение

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

Рабочий подход — многослойный и невидимый для посетителя:

• Honeypot. Скрытое поле, которое человек не видит и не заполняет, а бот заполняет автоматически. Заполнено — отбрасываем. Просто, бесплатно, эффективно против массы.
• Проверка времени. Форма, отправленная через полсекунды после загрузки страницы, заполнена не человеком.
• Ограничение частоты (rate limiting). С одного адреса — не больше нескольких отправок за промежуток времени. Это ключевой механизм, и он же защищает страницу входа от перебора паролей.
• Невидимые проверки. Современные системы оценивают поведение и показывают задание только подозрительным запросам. Живой клиент не видит ничего.

Валидация на сервере — не обсуждается

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

Загрузка файлов — отдельная история

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

Rate limiting шире, чем формы

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

Бэкапы: единственная страховка, которая работает всегда

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

Правило 3-2-1

Классика, придуманная задолго до нас и до сих пор не побитая:

• 3 копии данных: боевая и две резервные.
• 2 разных носителя или платформы — не всё в одном месте.
• 1 копия вне основной площадки, физически и административно отдельно от сервера.

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

Бэкап, который не проверяли, — это не бэкап

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

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

Глубина хранения важнее частоты

Ежедневный бэкап с хранением трёх дней бесполезен против тихого заражения. Вредоносный код часто сидит месяцами и не проявляет себя. Когда вы его обнаружите, все три копии будут уже заражены. Держите глубину: ежедневные за две недели, еженедельные за пару месяцев, ежемесячные за год. Место на диске стоит несравнимо дешевле, чем сайт, который не с чего восстановить.

Что именно бэкапить

Файлы и база — это очевидно. Забывают обычно про остальное: конфигурацию сервера, правила веб-сервера, задания планировщика, настройки DNS, письма. Хороший ориентир — вопрос «если завтра хостинг исчезнет целиком, сколько времени займёт полный подъём с нуля на новом месте?». Если ответа нет, значит, бэкап неполный.

Мониторинг и логи: увидеть проблему раньше клиента

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

Минимальный набор

• Аптайм-мониторинг. Проверка доступности каждую минуту с оповещением. Базовые сервисы бесплатны, ставится за десять минут.
• Контроль целостности файлов. Система запоминает состояние файлов и сообщает, когда что-то изменилось. Никто не правил код, а два файла изменились ночью — это разговор.
• Срок действия SSL и домена. Оповещение заранее, а не постфактум. Забытое продление домена бьёт больнее любого взлома.
• Google Search Console. Бесплатно и обязательно. Поисковик часто узнаёт о заражении раньше владельца и честно об этом пишет в разделе безопасности.
• Внешняя проверка на вредоносный код. Регулярное сканирование снаружи ловит то, что видно только посетителю: редиректы, чужие скрипты, подменённый контент.

Логи: скучно, но именно там правда

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

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

На что смотреть в логах

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

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

WAF и CDN: что Cloudflare делает, а чего не делает

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

Что это такое

CDN ставит между посетителем и вашим сервером сеть узлов по всему миру. Статика отдаётся с ближайшего узла — сайт быстрее, сервер разгружен. WAF (файрвол уровня приложения) — фильтр, который смотрит на входящие запросы и отбрасывает похожие на атаку до того, как они дойдут до вашего кода.

Реальная польза

• Поглощение DDoS. Мусорный трафик разбивается о сеть провайдера, а не о ваш сервер. Самостоятельно малый бизнес такую атаку не переживёт.
• Скрытие реального IP сервера. Атаковать напрямую становится сложнее, потому что цель не видна.
• Фильтрация ботов. Значительная часть сканирующего мусора отсеивается автоматически, и логи сразу становятся читаемыми.
• Виртуальный патчинг. Правило WAF может закрыть свежую уязвимость на время, пока вы готовите нормальное обновление. Это выигрыш времени, а не решение.
• Скорость. Приятный побочный эффект, который заметен и посетителям, и поисковику.

Чего он не сделает

А теперь неудобная часть. WAF не спасёт, если:

• У вас украли пароль. Вход с правильным логином и паролем — легальный запрос. Фильтр пропустит его и будет прав.
• Ваш реальный IP уже известен и сервер принимает соединения напрямую, минуя фильтр. Это очень частая ошибка настройки: сервер обязан принимать трафик только от сети провайдера.
• Уязвимость в вашей собственной бизнес-логике. Если ваш код позволяет одному пользователю запросить чужой заказ по номеру, для WAF это обычный корректный запрос.
• Вредоносный код уже внутри. Фильтр смотрит на вход, а не на то, что происходит на сервере.
• Настроен режим шифрования «гибкий». Тогда участок от Cloudflare до вашего сервера идёт открытым текстом, а посетитель видит замочек и уверен, что всё хорошо. Это опасная имитация безопасности — используйте строгий режим с проверкой сертификата.

Резюме: WAF и CDN — это отличный внешний забор. Забор бесполезен, если ключ от двери лежит под ковриком, а на первом этаже открыто окно. Он дополняет гигиену, а не заменяет её.

Что делать, если сайт уже взломали

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

1. Изолировать

Закройте сайт заглушкой с кодом 503. Это защищает посетителей от заражения и говорит поисковику, что работы временные, а не что сайт умер. Не удаляйте пока ничего.

2. Сохранить улики

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

3. Сменить все доступы

Все, без исключений и без «этот точно не мог утечь». Хостинг, SSH, база данных, все пользователи админки, FTP, регистратор домена, почта, подключённые сервисы. Одновременно включите 2FA везде, где её не было. Важно: делайте это с чистого компьютера — если заражён ноутбук, новые пароли утекут ровно так же, как старые.

4. Найти точку входа

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

5. Восстановиться

Лучший путь — чистая переустановка: свежая CMS, свежие плагины из официальных источников, а из бэкапа берётся только контент и база, которую нужно предварительно проверить (в базу тоже вставляют код, обычно в шаблоны и настройки). Ручная чистка заражённых файлов — это лотерея: пропущенный один-единственный файл, и всё возвращается.

6. Закрыть дыру и вернуть репутацию

Устраните найденную причину — иначе вы просто перезапустили таймер. Затем: запросите пересмотр в Google Search Console, проверьте почтовые записи домена (взломанный сайт часто рассылал спам, и домен уже мог попасть в чёрные списки), убедитесь, что в базе нет чужих администраторов.

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

Практический чек-лист безопасности

Соберём всё сказанное в список, по которому можно пройтись сегодня. Он отсортирован по соотношению «эффект к усилиям» — начинайте сверху.

Сегодня, за один вечер

1. Включить 2FA на хостинге, у регистратора домена, в почте и в админке сайта.
2. Проверить, что HTTPS работает везде и весь HTTP уходит редиректом.
3. Открыть список пользователей админки и удалить всех лишних: бывших сотрудников, старых подрядчиков, непонятные аккаунты.
4. Проверить корень сайта на лишние файлы: архивы, дампы базы, папку .git, копии конфигов, тестовые скрипты.
5. Убедиться, что бэкапы существуют и лежат не на том же сервере.
6. Подключить сайт к Google Search Console и посмотреть раздел безопасности.

На этой неделе

1. Завести менеджер паролей и сменить все повторяющиеся пароли на уникальные.
2. Обновить CMS и все плагины, предварительно сделав полный бэкап.
3. Удалить неиспользуемые плагины и темы — именно удалить, а не отключить.
4. Настроить заголовки безопасности: начните с X-Content-Type-Options, X-Frame-Options и Referrer-Policy, они безопасны и включаются сразу.
5. Отключить FTP, перейти на SSH-ключи.
6. Поставить мониторинг доступности и оповещение об истечении SSL и домена.
7. Ограничить частоту попыток входа в админку.

В этом месяце

1. Проверить восстановление из бэкапа на тестовой площадке — реально развернуть и посмотреть.
2. Подключить CDN и WAF, обязательно закрыв прямой доступ к серверу в обход фильтра.
3. Внедрить CSP, начиная с режима отчётов.
4. Провести ревизию всего, что висит на аккаунте: поддомены, тестовые копии, забытые лендинги. Лишнее — удалить.
5. Настроить контроль целостности файлов.
6. Проверить права доступа к папкам и файлам, убрать возможность записи там, где она не нужна.

Регулярно, чтобы не возвращаться к этой статье

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

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

Частые вопросы