Не взломают, если скучно взламывать: базовый чек-лист безопасности сайта без паранойи

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

Я видел десятки историй, когда человек говорил: да кому нужен мой маленький сайт. А потом утром открывает страницу, а там казино, ссылки на таблетки и странные редиректы. Самое обидное – в большинстве случаев это лечится не героической кибербезопасностью, а скучными базовыми настройками. Ниже – чек-лист, который делает взлом банально невыгодным.

Обновления: самая дешёвая страховка

Звучит банально, но почти всегда «взломали» начинается со слов «я давно не обновлял…».

Что сделать:

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

Почему важно:

Уязвимости в популярных движках и плагинах живут неделями. Боты сканируют интернет по сигнатурам. Если версия известна и дырка публичная – это не вопрос если, это вопрос когда.

Мини-пример:
У вас стоит плагин для форм, которым вы пользовались год назад. Он остался, потому что «пусть будет». А потом выясняется, что через него грузят файлы и кладут веб-шелл. И никто даже не заходил в админку – всё автоматом.

Пароли и доступы: убираем очевидное

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

Чек-лист:

Пароли создаем менеджером паролей, не в заметках и не в браузере без защиты.
Для админок – 2FA обязательно.
Запрещаем повторное использование паролей. Один утёк – и привет всем аккаунтам.
Лимитируем попытки входа в админку.

Про доступы на сервере:

SSH только по ключам, парольный вход выключить.
Root по SSH лучше запретить, работать через обычного пользователя + sudo.
Если панель управления сервером доступна из интернета – поставьте 2FA и ограничьте доступ по IP, если возможно.

Маленькая проверка:
Если у вас где-то остался логин admin – это как наклейка «сюда ломай». Переименуйте пользователя-админа, заведите нового и старого уберите из администраторов.

Админка: сделать так, чтобы её не было видно издалека

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

Что помогает почти всегда:

Ограничение доступа к админке по IP, если у вас статический IP или вы заходите из одной страны.
Дополнительная HTTP-авторизация на страницу логина.
Перенос адреса страницы входа в нестандартный (не абсолютная защита, но снижает шум).
CAPTCHA или антибот-защита, если сайт под постоянным брутфорсом.
2FA для всех пользователей с правами выше редактора.

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

Права на файлы и владельцы: самая частая тихая причина боли

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

Нормальная база:

Файлам обычно хватает 644, папкам 755.
Никогда не давать запись веб-серверу туда, где не нужно.
Директория загрузок – отдельная зона, и лучше запретить выполнение скриптов внутри неё.

Если коротко по логике:
Веб-сервер должен уметь читать файлы сайта и писать только туда, где это задумано (кэш, загрузки). Если он может писать куда угодно – злоумышленник сможет положить туда что угодно.

Резервные копии: не обсуждается

Бэкапы – это не про «если взломают». Это про «когда что-то сломается». И ломается оно чаще руками владельца, чем хакерами.

Правило, которое спасает нервы:

3-2-1: три копии, на двух разных носителях, одна – вне сервера.
Бэкап базы данных и файлов раздельно.
Проверять восстановление. Бэкап, который не восстанавливается, – просто красивая иллюзия.

Мини-план:

Ежедневно: база данных.
Раз в неделю: файлы сайта.
Раз в месяц: контрольное восстановление на тестовый стенд.

HTTPS и безопасность cookies: чтобы не отдали сессию

HTTPS сегодня – это стандарт. Но многие ставят сертификат и забывают про мелочи, которые делают сессии безопаснее.

Проверьте:

Включён редирект на HTTPS.
Cookies сессий помечены как Secure и HttpOnly.
Если есть авторизация – полезно SameSite (обычно Lax, иногда Strict).

Зачем:
Сессия – это ваш пропуск в админку. Если её можно украсть, пароль может даже не понадобиться.

WAF и базовая фильтрация: не панацея, но хороший фильтр мусора

WAF – это не волшебный щит, но он отлично режет массовые автоматические атаки: SQL-инъекции, XSS по шаблонам, попытки загрузки шеллов и прочий шум.

Что можно сделать без фанатизма:

Включить WAF на уровне CDN или хостинга, если доступно.
Включить ограничение запросов к логину и XML-RPC (если вы на WordPress и не используете это).
Добавить rate limiting на чувствительные маршруты: login, admin, api.

Это как домофон в подъезде: не защищает от всего, но случайных прохожих отсекает.

Логи и мониторинг: чтобы узнать о проблеме не от клиента

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

Минимум, который стоит настроить:

Мониторинг доступности: проверка ответа сайта раз в минуту.
Уведомления о росте ошибок 500.
Уведомления о резком росте исходящего трафика.
Логи авторизаций в админке и на сервере.

Признаки компрометации, на которые стоит реагировать:

Неожиданные новые админы.
Необъяснимые изменения файлов (особенно в ночное время).
Странные задания cron, которых вы не ставили.
Сайт стал медленнее без причины, нагрузка выросла.

Тестовые поддомены и старые копии: любимая лазейка

Серьёзно, это топ. Основной сайт может быть вылизан, а рядом висит test.site.ru или old.site.ru с копией годичной давности.

Что проверить:

Все поддомены и старые версии, которые остаются в DNS.
Старые бэкапы в публичной директории, типа backup.zip или site_old.tar.gz.
Открытые phpinfo.php, install.php, test.php и прочие файлы-помощники.

Правило простое:
Если это доступно из интернета – это часть вашего периметра. Даже если вы забыли, что оно существует.

Минимальный план на случай взлома: без паники

Паника – худший админ. Лучше иметь короткий сценарий, что делать.

Если подозреваете взлом:

Перевести сайт в режим обслуживания или закрыть доступ (временно), чтобы не раздавать вредоносное.
Снять копию текущего состояния для разбора: файлы + база. Не лечить, не сохранив.
Сменить все пароли: админка, FTP/SFTP, SSH, база, панель, почта.
Проверить пользователей-админов и ключи доступа.
Сравнить файлы с чистой версией, найти посторонние.
Восстановиться из заведомо чистого бэкапа, а не пытаться выковырять один вредный файл.
Закрыть причину: уязвимый плагин, права, открытая админка, старый поддомен.

Важно:
Если вы один раз почистили, но не закрыли дыру – вас, скорее всего, взломают снова. Иногда в тот же день.

Быстрый чек-лист в одно чтение

Всё обновлено, лишнее удалено
Пароли уникальные, 2FA в админке, логин не «admin»
SSH по ключам, root-login выключен
Админка защищена: 2FA, лимит попыток, по возможности IP-ограничение
Права на файлы без 777, запрет выполнения скриптов в загрузках
Бэкапы по расписанию, один вне сервера, восстановление проверено
HTTPS включён, cookies защищены
WAF или базовая антибот-защита включены
Мониторинг и алерты настроены
Нет тестовых поддоменов и публичных архивов

Финальная мысль

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

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