О безопасности сайта обычно вспоминают в двух случаях. Первый, когда браузер уже показывает красное предупреждение. Второй, когда вместо главной страницы посетители видят рекламу казино, сомнительные таблетки или белый экран. До этого момента все кажется нормальным. Сайт открывается, заявки приходят, хостинг оплачен. Зачем трогать то, что работает?

Проблема в том, что взлом редко начинается с эффектного появления злоумышленника в черной толстовке. Большую часть рутинной работы выполняют автоматические программы. Они перебирают пароли, ищут сайты без обновлений, проверяют формы, модули и настройки сервера. Размер бизнеса их не особенно волнует. Небольшой корпоративный сайт могут атаковать так же, как крупный интернет-магазин, просто потому, что система нашла уязвимость.

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

Сначала разберитесь, кто имеет доступ

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

Начинать проверку безопасности лучше именно с доступов. Нужно составить список пользователей, удалить ненужные учетные записи и оставить каждому только те права, которые действительно требуются для работы. Контент-менеджеру не нужен полный доступ к серверу, а специалисту по рекламе обычно не требуется роль администратора сайта.

Для всех важных учетных записей нужны разные сложные пароли и двухфакторная авторизация. Одного пароля уже недостаточно для надежной защиты, особенно если он используется сразу в нескольких сервисах. Пароли удобнее хранить в специальном менеджере, а не в общей таблице под названием «Все доступы финал 3». Такая таблица обычно прекрасно переживает смену сотрудников и начинает жить собственной жизнью.

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

Обновления нельзя откладывать на бесконечное потом

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

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

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

«Часто владельцы сайтов боятся обновлений, потому что после них что-нибудь может сломаться. Поэтому годами ничего не обновляют и в итоге получают гораздо более серьезный риск. Задача не в том, чтобы нажимать кнопку обновления при каждом удобном случае, а в том, чтобы делать это регулярно, с резервной копией и пониманием последствий», — Олеся Шаркова, директор IT-интегратора «Экспресс лаб».

Резервная копия нужна не для галочки

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

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

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

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

Формы и загрузка файлов требуют особого внимания

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

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

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

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

HTTPS важен, но одним сертификатом защита не заканчивается

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

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

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

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

После взлома недостаточно удалить один подозрительный файл

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

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

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

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

Безопасность должна проверяться регулярно

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

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

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

С чего начать владельцу сайта

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

После проверки можно составить понятный план. Что нужно исправить срочно, что можно включить в регулярное техническое обслуживание, а какие изменения потребуют отдельной разработки. Такой подход позволяет не покупать безопасность «вообще», а закрывать конкретные риски в разумном порядке.

Абсолютно неуязвимых сайтов не бывает. Но между «взломать невозможно» и «мы ничего не проверяли последние четыре года» есть довольно большое пространство. Именно в нем и находится нормальная техническая защита.

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

Вернуться в блог