
Когда к нам обращаются с взломанным сайтом, первая реакция владельца обычно одна и та же: «Кому нужен наш маленький сайт?» Ответ неприятный: никому лично. Подавляющее большинство атак автоматические. Боты круглосуточно сканируют интернет в поисках известных уязвимостей, слабых паролей и забытых файлов. Им всё равно, крупная у вас компания или небольшая мастерская.
Хорошая новость в том, что от большинства таких атак защищают базовые меры, которые не требуют огромных вложений. Расскажем о них в том порядке, в котором мы сами проверяем сайты клиентов.
Что происходит со взломанным сайтом
Чтобы понимать, от чего защищаемся, полезно знать, что обычно делают злоумышленники. Взлом редко выглядит как сообщение «вас взломали» на главной. Чаще всего это незаметные вещи:
- Скрытые ссылки и страницы. На сайт добавляют сотни страниц с рекламой сомнительных товаров. Владелец их не видит, а поисковые системы видят и понижают сайт в выдаче.
- Редиректы для мобильных посетителей. С компьютера сайт открывается нормально, а пользователей смартфонов перенаправляет на мошеннические ресурсы.
- Рассылка спама. Сервер используется для отправки писем, из-за чего его IP попадает в чёрные списки, и перестаёт доходить почта с ваших форм.
- Кража данных. Утечка базы клиентов, заказов, контактов. Это уже не только технический, но и юридический вопрос.
- Майнинг и участие в атаках. Ресурсы сервера используются для чужих задач, сайт начинает тормозить.
Последствия — потеря позиций в поиске, пометка «сайт может быть опасен» в браузере и в выдаче, блокировка рекламных кампаний, проблемы с законом о персональных данных. Восстановление репутации занимает недели и месяцы.
Мера 1. Обновления — главная защита
Если бы нужно было выбрать одну меру, это были бы обновления. Большинство взломов, с которыми мы сталкивались, происходили через известные уязвимости в устаревших версиях CMS, плагинов и модулей. Разработчики уже выпустили исправление, но на сайте его не установили.
Что нужно обновлять:
- ядро CMS;
- плагины, модули, расширения, темы оформления;
- серверное ПО: PHP, веб-сервер, СУБД, операционную систему;
- библиотеки, подключённые в проекте.
Важный момент: обновлять нужно с умом. Обновление «вслепую» на рабочем сайте может что-то сломать. Правильный порядок — сделать резервную копию, обновить на тестовой копии, проверить ключевые функции, затем повторить на рабочем сайте.
Отдельная беда — сайты, которые не обновлялись годами. Там обновление превращается в проект: накопилось столько несовместимостей, что модули приходится переписывать. Такие сайты мы обычно берём на доработку, поэтапно приводя код в порядок.
Мера 2. Доступы и пароли
Второй по популярности путь взлома — подбор или утечка паролей. Проверьте:
- Сложность паролей. Пароли к админке, хостингу, базе данных, FTP должны быть длинными и уникальными. Пароль «admin123» или название компании подбираются за минуты.
- Уникальность. Один и тот же пароль на почте, в админке и в соцсетях — это один пароль на всё. Утечёт в одном месте — откроются все двери.
- Двухфакторная аутентификация. Включите её везде, где можно: в панели хостинга, у регистратора домена, в админке сайта.
- Нестандартный адрес админки. Не панацея, но отсекает значительную часть автоматических попыток входа.
- Ограничение попыток входа. После нескольких неудачных попыток IP временно блокируется.
Ревизия пользователей
Загляните в список пользователей админки. Часто там обнаруживаются аккаунты бывших сотрудников, фрилансеров, которые делали что-то три года назад, предыдущей студии. Каждый неиспользуемый аккаунт — потенциальная дыра. Удаляйте лишних, а оставшимся выдавайте минимально необходимые права: контент-менеджеру не нужен доступ к настройкам и установке плагинов.
То же самое касается доступов к хостингу и серверу. После завершения работ с подрядчиком смените пароли или отзовите его ключи.
Мера 3. Резервные копии
Бэкапы не защищают от взлома, но позволяют быстро восстановиться после него, а также после ошибки сотрудника, неудачного обновления или сбоя оборудования. Правила простые, но их часто нарушают:
- Копируются и файлы, и база данных.
- Копии делаются автоматически по расписанию: база — ежедневно, для активного магазина — чаще.
- Копии хранятся вне сервера сайта. Если злоумышленник получил доступ к серверу, он может удалить и бэкапы рядом.
- Хранится несколько поколений копий. Взлом иногда обнаруживают через несколько недель, и вчерашняя копия уже заражена.
- Восстановление регулярно проверяется. Бэкап, который не удалось развернуть, — не бэкап.
Последний пункт мы считаем самым недооценённым. Нам встречались ситуации, когда копии исправно делались, но оказывались неполными или повреждёнными, и выяснялось это ровно в тот момент, когда они понадобились.
Мера 4. Защита форм и пользовательского ввода
Любое место, где пользователь может что-то ввести, — потенциальная точка атаки. Формы обратной связи, поиск, комментарии, загрузка файлов, личный кабинет.
Что должно быть сделано
- Валидация на сервере. Проверки только в браузере недостаточно — её легко обойти.
- Защита от SQL-инъекций. Запросы к базе формируются через подготовленные выражения, а не склейкой строк с данными пользователя.
- Защита от XSS. Всё, что вводит пользователь, экранируется при выводе на страницу.
- Проверка загружаемых файлов. Разрешены только нужные типы, файлы сохраняются вне публичной директории или с запретом исполнения.
- Защита от спама. Капча, скрытые поля-ловушки, ограничение частоты отправки.
- CSRF-токены в формах, которые меняют данные.
Если сайт работает на популярной CMS и использует её стандартные механизмы, многое из этого уже реализовано. Проблемы обычно возникают в самописных модулях и доработках, сделанных на скорую руку.
Мера 5. HTTPS, настройки сервера и мониторинг
HTTPS и настройки сервера
SSL-сертификат сегодня обязателен для любого сайта. Без него браузеры помечают сайт как небезопасный, а данные из форм передаются в открытом виде. Сертификат нужно не только установить, но и:
- настроить перенаправление всех страниц с HTTP на HTTPS;
- убедиться, что на страницах нет ресурсов, загружаемых по HTTP;
- настроить автоматическое продление, чтобы сертификат не истёк неожиданно.
На уровне сервера стоит проверить ещё несколько вещей. Запрещён ли просмотр содержимого директорий. Не лежат ли в публичном доступе архивы с бэкапами, файлы конфигурации, дампы базы, служебные папки систем контроля версий. Это удивительно частая находка: архив site.zip или backup.sql в корне сайта, доступный любому. Также полезно настроить заголовки безопасности, которые запрещают встраивание сайта во фреймы на чужих ресурсах и ограничивают источники загрузки скриптов.
Мониторинг
Чем раньше вы узнаете о проблеме, тем дешевле её устранить. Минимальный набор мониторинга:
- проверка доступности сайта с уведомлением при падении;
- отслеживание изменений файлов на сервере;
- уведомления от панелей вебмастеров поисковых систем — они сообщают об обнаружении вредоносного кода;
- контроль срока действия SSL-сертификата и домена;
- периодический просмотр логов на предмет подозрительной активности.
Отдельно отметим продление домена. Это не про взлом, но последствия похожие: истёк срок регистрации, домен освободился, и его перехватили. Включите автопродление и держите контакты у регистратора актуальными.
Если сайт уже взломан
Коротко о порядке действий, если вы обнаружили признаки взлома:
- Не паникуйте и не удаляйте всё подряд — можно уничтожить следы, по которым определяется путь проникновения.
- Смените все пароли: хостинг, админка, база, FTP, почта.
- Сделайте копию текущего состояния для анализа.
- Найдите и устраните уязвимость, через которую произошёл взлом. Иначе после очистки всё повторится.
- Очистите сайт от вредоносного кода или восстановите из чистой копии.
- Обновите всё ПО.
- Отправьте сайт на перепроверку в панелях вебмастеров.
Самый важный пункт — четвёртый. Нам нередко приходят сайты, которые «чистили» уже несколько раз, а заражение возвращается через пару недель. Причина всегда одна: убирали последствия, но не закрывали дыру.
Вывод
Безопасность сайта — не разовое действие, а регулярная гигиена. Своевременные обновления, сложные пароли с двухфакторной защитой, ревизия доступов, автоматические резервные копии вне сервера, корректная обработка пользовательского ввода, HTTPS и мониторинг закрывают подавляющее большинство реальных угроз. Если вы не уверены в состоянии своего сайта, начните с аудита — он покажет уязвимые места до того, как их найдут боты.

