Защита сайта от взлома: что нужно настроить в первую очередь

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

Почему это важно именно вам, а не только «крупным» сайтам

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

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

1. Обновления CMS, плагинов и тем

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

• Обновляйте CMS (WordPress, 1С-Битрикс, Joomla и т.д.) и все плагины/модули не реже раза в месяц, критические патчи безопасности — сразу после выхода.
• Перед обновлением делайте резервную копию: иногда новая версия плагина конфликтует с темой или другими модулями.
• Удаляйте неиспользуемые плагины и темы полностью, а не просто деактивируйте — неактивный, но не удалённый код всё равно остаётся точкой входа.
• Никогда не используйте «нулленные» (пиратские) плагины и темы — в большинстве случаев в них уже встроен вредоносный код.

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

2. Пароли и доступы

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

• Пароль администратора сайта. Не менее 12 символов, буквы разного регистра, цифры и символы, никаких «admin123» и названий компании. Уникальный пароль — не тот, что используется ещё где-то.
• Логин администратора. Если он до сих пор «admin» — смените: это первое, что перебирают боты.
• Доступы к хостингу, FTP и базе данных. Их взламывают реже пароля админки, но именно через них получают полный контроль над файлами. Пароли на этом уровне должны быть отдельными от паролей сайта и меняться при любом подозрении на утечку — например, при увольнении сотрудника, у которого были доступы.

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

3. SSL-сертификат и https

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

Установка и настройка сертификата (включая бесплатные варианты вроде Let's Encrypt) — работа на несколько часов, и с этого разумно начинать, если на сайте вообще нет базовой защиты.

4. Права доступа к файлам и защита админки

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

• Права доступа к файлам и папкам на сервере должны быть выставлены по минимуму, необходимому для работы сайта, а не «777» для удобства — слишком открытые права позволяют записывать и подменять файлы даже без пароля.
• Панель администрирования стоит закрыть дополнительным паролем на уровне сервера или ограничить доступ по IP-адресам, если вход в админку нужен только вам и сотрудникам с постоянных рабочих мест.
• Полезно ограничить количество попыток входа — большинство CMS и плагинов безопасности умеют временно блокировать IP после нескольких неудачных попыток авторизации, что делает автоматический перебор пароля бессмысленным.
• Если сайт работает на популярной CMS, стоит установить один проверенный плагин безопасности (файрвол уровня приложения) — он фильтрует подозрительные запросы, блокирует известные шаблоны атак и сканирует файлы на изменения без участия человека.

5. Резервное копирование

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

Для сайта-визитки достаточно еженедельного автоматического бэкапа, для интернет-магазина с ежедневными заказами — ежедневного. Проверяйте раз в несколько месяцев, что копия действительно разворачивается и не повреждена — «бэкап, который никогда не тестировали», статистически не сильно отличается от его отсутствия.

6. Мониторинг доступности и заражений

Последний элемент — не столько защита, сколько система раннего предупреждения. Мониторинг доступности сообщает, если сайт «упал» или стал недоступен, за минуты, а не тогда, когда об этом напишет клиент. Мониторинг заражений (регулярное сканирование файлов на изменения и вредоносный код) позволяет заметить проблему до того, как её увидят Яндекс или Google и поставят метку «сайт может угрожать безопасности» — а снятие такой метки занимает от нескольких часов до пары недель и всё это время сайт теряет посетителей и заявки.

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

Практический вывод: чек-лист на сегодня

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

1. Обновить CMS, все плагины и темы; удалить неиспользуемые и пиратские компоненты.
2. Сменить логин и пароль администратора на уникальные и сложные, включить двухфакторную аутентификацию.
3. Сменить пароли хостинга, FTP и базы данных, если они не менялись больше года.
4. Проверить, что весь сайт работает по https без ошибок смешанного контента.
5. Выставить корректные права доступа к файлам и ограничить доступ к админке (пароль на уровне сервера, ограничение по IP или число попыток входа).
6. Установить плагин безопасности или файрвол уровня приложения, если CMS это позволяет.
7. Настроить автоматические резервные копии с хранением отдельно от хостинга и проверить, что копия реально восстанавливается.
8. Подключить мониторинг доступности и периодическое сканирование на вредоносный код.

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