На одном сервере могут работать интернет-магазин, сайт строительной компании, несколько блогов и десятки других проектов. У каждого свой владелец, свои посетители и отдельный доступ к панели управления. Но однажды на одном из сайтов появляется фишинговая страница, поступает жалоба — и недоступными становятся все проекты на сервере.
Для остальных клиентов это выглядит несправедливо: они ничего не нарушали, а их сайты перестали работать. Чтобы понять, как такое происходит и от чего действительно можно защититься, нужно разобраться, кто управляет сайтами, кто управляет сервером и где проходит граница между этими полномочиями.
Разные аккаунты ещё не означают независимую работу при любой аварии.
Представьте офисный этаж, на котором помещения сдают разным компаниям. У каждой свой замок: сотрудники одного офиса не могут свободно заходить в другой. Однако электричество и вход в здание у них общие. Хорошие замки помогают защитить помещения, но при отключении всего этажа работать не сможет никто.
У хостинга похожее устройство. Отдельные аккаунты ограничивают доступ к чужим файлам и настройкам. При этом сайты могут зависеть от одного сервера, одного сетевого подключения и одного договора с поставщиком инфраструктуры.
Например, небольшой хостер арендует сервер, устанавливает панель управления и размещает на нём клиентские сайты. Внутри панели для него существуют десятки отдельных клиентов. Для компании, которая предоставила сервер, это может быть одна услуга, оформленная на одного заказчика. Доступа к отдельным аккаунтам сайтов у неё может вообще не быть.
Если поставщик инфраструктуры приостанавливает эту услугу целиком, разделение клиентов внутри панели не сохраняет доступность их сайтов.
Жалобу на вредоносную активность обычно называют abuse-жалобой. Она может касаться фишинга, спама, распространения вредоносных файлов или атак на другие системы. Фишинг — это, например, поддельная страница банка или платёжного сервиса, которая собирает чужие пароли и данные.
Появление такой страницы не обязательно означает, что владелец сайта разместил её сам. Злоумышленник мог использовать уязвимый плагин или украденный пароль. Это нужно выяснять при расследовании, одновременно прекращая вредоносную активность.
Жалоба также может сразу попасть поставщику сервера. Контакт для обращений часто находят по IP-адресу в данных о сети, а там указан её оператор. Поэтому рассчитывать, что сначала обязательно напишут владельцу сайта или небольшому хостеру, нельзя.
Изоляция клиентов помогает ограничить последствия заражения, но порядок блокировок нужно выяснять отдельно.
Сайты разных заказчиков разумно размещать в отдельных аккаунтах с собственными правами доступа и учётными данными баз данных. Если все проекты работают под одним системным пользователем и имеют доступ к файлам друг друга, заражение одного сайта может затронуть соседние.
Дополнительная изоляция файлов и процессов уменьшает возможности такого распространения. Ограничения ресурсов помогают сдерживать другую проблему: ситуацию, когда один клиент занимает всю доступную память или вычислительную мощность сервера. При этом само наличие панели управления ещё не подтверждает, что нужные ограничения включены и правильно настроены.
Отдельный IP-адрес может облегчить применение адресной блокировки. Отдельная VPS позволяет обособить рабочую среду проекта. Но эти меры не дают гарантии от приостановки нескольких услуг или всего аккаунта у поставщика. При выборе схемы размещения важно учитывать и техническое разделение, и условия обслуживания.
Поэтому покупать отдельный сервер для каждого небольшого сайта обычно избыточно. Полезнее оценить последствия общего простоя: сколько клиентов пострадает одновременно, какие проекты критичны для бизнеса и какие из них стоит размещать отдельно.
Следующая часть защиты — понятный порядок обработки жалоб. Даже хорошая изоляция мало поможет, если письмо несколько дней лежит в почтовом ящике, который никто не проверяет.
Для владельца сервера рабочая последовательность может выглядеть так:
- Разобраться, к чему относится жалоба. Проверить указанный адрес страницы, домен, IP и время события, определить клиентский аккаунт. На одном IP могут работать разные сайты, поэтому одного адреса сервера для вывода о виновнике недостаточно. Сохранить сведения, которые понадобятся для расследования.
- Прекратить подтверждённую вредоносную активность. В зависимости от ситуации закрыть доступ к опасному содержимому или приостановить проблемный аккаунт. Проверить связанные процессы и отправку почты: удаление одной видимой страницы может не устранить всю проблему.
- Найти причину. Проверить уязвимости приложения, посторонние файлы и доступы, связаться с владельцем сайта. До устранения причины повторный запуск может привести к новой жалобе.
- Ответить по существу. Указать номер обращения, что обнаружено, какие меры приняты и когда. Если жалоба ошибочная, приложить результаты проверки. Сообщение «передали клиенту» само по себе не подтверждает прекращение нарушения.
- Проверить результат. Убедиться, что опасное содержимое недоступно извне. Если услугу уже ограничили, выполнить порядок разблокировки поставщика и проверить фактическую работу разрешённых сервисов.
Для этого нужен ответственный человек и подмена на время его отсутствия. Почта для срочных уведомлений должна оставаться доступной при отключении рабочего сервера. Та же логика относится к каналу связи с клиентами: если сайт хостера, биллинг и почта размещены на отключённой машине, сообщить о проблеме будет сложнее.
До размещения клиентских проектов стоит выяснить условия работы с abuse. Куда приходят уведомления? Какой срок даётся на реакцию, если он предусмотрен? Когда возможно немедленное ограничение? Может ли оно затронуть отдельный сайт, IP, сервер или весь аккаунт? Как запросить доступ к данным при блокировке?
Универсального правила «сначала всегда предупредят и дадут сутки» нет. Порядок зависит от поставщика, условий услуги и характера нарушения. Эти детали лучше знать заранее, когда есть время выбрать подходящую схему работы.
Резервные копии нужны на случай, если сохранить доступность всё же не удалось. Здесь решающую роль играет их расположение.
Архив на том же сервере может стать недоступным вместе с сайтами. Второй диск защищает от части аппаратных неисправностей, но доступ к нему тоже зависит от сервера. Снимок у того же поставщика удобен для восстановления, однако возможность получить его при блокировке услуги или аккаунта нужно проверять отдельно.
Для такого сценария нужна копия, которую можно забрать без доступа к исходному серверу и его панели. Практический вариант — внешнее хранилище с отдельными учётными данными, доступ к которому сохраняется при остановке основной услуги.
Состав копии зависит от приложения. Для интернет-магазина понадобятся как минимум файлы и база данных, а также настройки, необходимые для запуска. Копия должна быть пригодна к восстановлению: архив с ошибкой или неполная база не вернут магазин в работу.
Проверка проста по смыслу: представить, что основной сервер недоступен, получить резервную копию и восстановить проект на другой площадке. После этого проверить вход, загрузку изображений и важные действия, например оформление тестового заказа. Такая проверка показывает и полноту копии, и реальное время восстановления.
Частоту копирования выбирают с учётом возможной потери изменений. Если последняя копия сделана ночью, в ней не будет заказов, поступивших утром. Для активно работающего магазина это может быть существеннее, чем несколько часов простоя.
Если сервер уже отключён, сначала уточните его статус. Приостановка доступа и удаление данных — разные события. Запросите причину ограничения, порядок его снятия, сведения о сохранности данных и возможность получить копию. До выяснения ситуации не запускайте переустановку, которая может уничтожить оставшиеся данные.
При восстановлении на другой площадке проверьте переносимые проекты и устраните источник нарушения. Запуск прежней заражённой копии способен повторить проблему уже на новом сервере.
Клиентам в это время полезны конкретные сообщения: какие услуги затронуты, что известно о данных, какие действия выполняются и когда будет следующее обновление. Если срок восстановления пока неизвестен, сообщите об этом прямо.
Если планируете размещать клиентские проекты в QCKL, заранее обсудите с поддержкой схему разделения сайтов, хранение резервных копий и порядок экстренных обращений. Укажите количество проектов, используемые приложения и допустимое время простоя. Отдельно уточните, какие задачи администрирования входят в выбранную услугу и кто будет реагировать на жалобы.
По действующей услуге оформляйте обращение через тикет в биллинге. Добавьте идентификатор услуги, номер abuse-жалобы, затронутый домен или IP, время события с часовым поясом и уже принятые меры — это даст поддержке исходные данные для проверки.
