Базовая защита сайта от взлома: что подготовить заранее

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

До начала: доступы и точка отката

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

• Убедитесь, что можете войти в панель хостинга и восстановить сайт из копии либо запросить восстановление у поддержки.
• Запишите адрес сайта, контакт поддержки и список людей с административными доступами. Не храните пароли в открытой таблице или переписке.
• Проверьте, что сайт работает по HTTPS и сертификат не просрочен. Если браузер показывает предупреждение о сертификате, сначала обратитесь к хостеру.
• Уточните у хостера, как часто создаются резервные копии, сколько они хранятся и можно ли восстановить отдельно файлы и базу данных.

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

Пять шагов базовой настройки

1. Создайте свежую резервную копию. Запустите копирование через панель хостинга или используемый вами инструмент. Не обновляйте сайт, пока не знаете, где лежит копия и как запросить восстановление. Проверка: в панели видна копия с сегодняшней датой, а поддержка или документация хостинга объясняет порядок восстановления.
2. Обновите WordPress, тему и плагины. В панели управления проверьте раздел обновлений. Сначала обновляйте компоненты, которые поддерживаются и нужны сайту; давно не используемые плагины удалите. Если сайт критичен для продаж, попросите хостера уточнить возможность тестового восстановления или используйте тестовую копию сайта. Проверка: в панели не осталось доступных обновлений, а главная страница и ключевые формы открываются.
3. Защитите учётные записи. Удалите аккаунты ушедших сотрудников или измените их роли. Для каждого человека используйте отдельную учётную запись, а для администраторов включите многофакторную аутентификацию — если её поддерживает выбранное решение. Пароль должен быть уникальным; хранить его лучше в менеджере паролей. Проверка: у каждого действующего пользователя есть понятная роль, а вход в аккаунт администратора требует второй фактор, если он настроен.
4. Сократите число администраторов. Не выдавайте полные права редактору, подрядчику или автору публикаций, если ему достаточно ограниченной роли. Удалите старые учётные записи, но сначала проверьте, кому принадлежат созданные ими материалы. Проверка: в списке пользователей нет неизвестных аккаунтов с административными правами.
5. Проверьте сигналы о проблемах. Включите уведомления хостинга о сбоях и необычных входах, если такие функции доступны. Сохраните адрес поддержки и способ сообщить о взломе. Не устанавливайте несколько плагинов безопасности подряд: они могут дублировать функции или конфликтовать. Проверка: вы знаете, где смотреть уведомления и куда обращаться, если сайт перестанет открываться.

Что делать, если что-то пошло не так

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

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

Где заканчивается базовая защита

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

Резервная копия полезна не тогда, когда она появилась в панели, а когда вы знаете, кто и как восстановит из неё сайт.

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

Следующий шаг

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