Защита сайта от взлома: базовые меры, которые закрывают большинство угроз

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

Как на самом деле взламывают сайты компаний

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

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

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

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

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

Ошибки в собственном коде. Уязвимости в самописных формах, загрузке файлов, поиске: SQL-инъекции, межсайтовый скриптинг, возможность загрузить исполняемый файл вместо картинки.

Пароли и доступы: фундамент защиты

Начинать стоит с самого простого и самого действенного. Даже идеально обновлённый сайт беззащитен, если пароль от административной панели знают семь человек, трое из которых давно не работают в компании.

• Уникальные длинные пароли (от 14 символов) для каждого сервиса, хранение в менеджере паролей, а не в таблице или блокноте
• Двухфакторная аутентификация для административной панели, хостинга, регистратора домена и почты
• Отдельная учётная запись для каждого сотрудника и подрядчика — никаких общих логинов
• Минимальные права: контент-менеджеру не нужны права администратора, бухгалтеру — доступ к серверу
• Отключение доступов в день увольнения сотрудника или завершения работ с подрядчиком
• Вход на сервер по SSH-ключам вместо паролей, отключённый FTP без шифрования
• Ежеквартальный пересмотр списка учётных записей с удалением лишних

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

Обновления: закрываем известные дыры

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

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

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

Защита административной панели

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

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

Настройки сервера и файлов

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

Права на файлы и папки

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

Скрытие служебной информации

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

Актуальное серверное ПО

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

HTTPS везде

Весь сайт, включая административную панель и формы, должен работать только по защищённому протоколу. Без этого пароли и данные форм передаются в открытом виде и могут быть перехвачены, например, в общественной сети Wi-Fi.

Межсетевой экран и мониторинг изменений

Межсетевой экран для веб-приложений (WAF) анализирует входящие запросы и блокирует те, что похожи на атаки: попытки SQL-инъекций, обращения к известным уязвимым путям, подозрительные загрузки файлов. Он бывает встроенным в хостинг, облачным (как часть сервиса защиты от DDoS) или в виде модуля CMS. WAF не заменяет обновления, но даёт время: если уязвимость нашли в пятницу вечером, а обновить модуль можно только в понедельник, правило межсетевого экрана может закрыть её на выходные.

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

Признаки того, что сайт уже взломан

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

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

Что запомнить

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