Защита сайта
от взлома

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

Типичные причины заражения

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

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

Порядок проверки сайта

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

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

Чем отличаются случаи

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

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

От чего зависят объём и глубина проверки

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

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

Когда такая проверка не подойдёт

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

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

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

Последствия для трафика и репутации

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

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

Как взлом проявляется для посетителей и поисковых систем

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

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

Базовые и дополнительные меры защиты

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

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

Почему разовых мер надолго не хватает

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

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

Когда усиленная защита сайта избыточна

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

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

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

Атаки на стороне сервера

SQL-инъекция — распространённый способ получить доступ к базе данных через форму с незащищённым полем ввода. Хакер подставляет в поле управляющую команду вместо обычного текста, и сервер выполняет её как фрагмент запроса к базе данных. DDoS-атака устроена иначе. Она не ищет брешь в защите, а заваливает сервер потоком автоматических запросов и делает сайт недоступным для пользователей. Оба вида атак не требуют физического доступа к серверу — их проводят удалённо, зачастую автоматически.

Правила на стороне веб-сервера — Apache или nginx — блокируют долю таких запросов до программной составляющей сайта. Пример — фильтр, отклоняющий запрос с признаками SQL-инъекции по шаблону в строке адреса. Такой фильтр включается бесплатно и не позволяет автоматическому сканеру достучаться до формы на сайте. Похожий фильтр отсекает и повторяющиеся DDoS-запросы с того же адреса, прежде чем они успевают перегрузить сервер.

Кража данных и ущерб для бизнеса

Кража данных из базы — частый итог как SQL-инъекции, так и утечки пароля администратора. Информация о покупателях, платежах и переписке переходит к постороннему человеку. Её могут продать или использовать для следующих кибератак на другие сайты той же организации. Такая информация часто оказывается на теневых площадках, где её покупают ради рассылок или дальнейших кибератак.

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

Административный доступ и внутреннее руководство

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

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

Когда набор таких средств избыточен

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

Масштаб угрозы для обычного сайта

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

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

Cloudflare и сервисы перед сайтом

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

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

Аудит и хранение бэкапов

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

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

Фишинговые сообщения и уведомления о вторжении

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

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

Интернет-магазин и хранение данных пользователей в России

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

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

Когда такой контур избыточен

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