Перейти к содержимому

Как изолировать сайты друг от друга на vps

  • автор:

Как перейти на другой хостинг, если старый

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

На что обратить внимание при выборе нового хостинга

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

Давайте разберём каждый параметр на примере хостинга REG.RU.

Надёжная сетевая инфраструктура

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

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

Защита от DDoS-атак

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

На хостинге REG.RU используется DDoS-GUARD в качестве основной защиты и StormWall – в качестве резервной. По умолчанию весь трафик идёт в обход поставщиков защиты. В случае атаки специальное ПО опознаёт её в течение нескольких секунд и перенаправляет небезопасный трафик к поставщику защиты. Это происходит незаметно для клиента.

Резервное оборудование

Иногда из строя может выйти даже самое надёжное оборудование. Непредвиденные проблемы могут быть с CPU, материнскими платами, модулями памяти и другими комплектующими. В REG.RU на такие случаи всегда есть готовый резервный сервер. Если по какой-то причине в работе основного сервера возникнут сбои, дежурный инженер оперативно перенесёт все диски на резервный. При такой ситуации сайт будет недоступен не больше 20 минут.

Резервное копирование

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

Собственные DNS-серверы

От DNS-серверов зависит скорость загрузки сайта. Поэтому важно, чтобы хостинг-провайдер зарезервировал свои DNS-серверы. Желательно, чтобы эти серверы находились в разных дата-центрах. Если один из них выйдет из строя, второй продолжит работать.

REG.RU предоставляет собственные надёжные DNS бесплатно.

Сетевой мониторинг

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

Если заражен хотя бы один сайт, вирус может распространиться на другие сайты сервера. Чтобы вовремя предотвратить эту проблему, используется сетевой мониторинг.

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

В REG.RU cистема мониторинга Nagios обновляет статусы всех проверок каждые 5 минут. Если в сети что-то пошло не так, проблема будет в работе уже через 5 минут после оповещения.

Изоляция виртуальных серверов (VPS/VDS)

Если вы хотите работать с виртуальным сервером, важна его полная изоляция от соседних услуг. Поэтому рекомендуем выбирать провайдера, который не использует Bridge при создании сети.

Bridge (режим моста) — это способ настройки, при котором все виртуальные серверы находятся в одном широковещательном домене.

REG.RU не использует режим моста на серверах с услугами VPS/VDS. Это значит, что клиенты не зависят друг от друга: проблема на одном виртуальном сервере не затронет соседние.

Постепенное обновление функционала

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

Чтобы обезопасить сайты клиентов, REG.RU использует конвеерный подход выкладки с тремя этапами тестирования:

— функционал обновляется на 5% серверов;

— спустя час этот же функционал добавляется ещё на 5% серверов;

— пошагово, с промежутком в 1 час, изменения вносятся ещё на 15%, 25% и 50% серверов.

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

Как перейти на хостинг REG.RU

В REG.RU вы можете бесплатно перенести сайт на любой тариф виртуального хостинга и на облачный сервер с панелью управления ISPmanager. Для этого подайте заявку через форму переноса.

Чтобы отправить заявку:

  • зарегистрируйте личный кабинет в REG.RU;
  • закажите хостинг;
  • подготовьте архив с файлами сайта. Принимаются форматы .zip, .tar.gz, .tar.bz2, .tgz и .tar;
  • подготовьте дамп базы данных в формате .sql. Также можно запаковать его в архив с форматом .sql.gz или .sql.zip.

Если вы не можете приложить файлы, предоставьте SSH-доступ к текущему серверу. Для подключения специалистам нужны:

— IP-адрес сервера, на котором сейчас размещён ваш сайт,

Готово, вы отправили заявку! Специалисты, которые будут переносить сайт, напишут вам на контактный email. Вы указывали его при покупке хостинга. Если возникнут вопросы, обращайтесь в службу поддержки. Специалисты REG.RU всегда готовы вам помочь.

Изолированный хостинг

Изолированный аккаунт хостинга необходим для защиты веб-ресурсов от массовых взломов.
Безлимитные тарифы позволяют разместить множество сайтов на одной виртуальной площадке. Однако такая модель имеет недостаток – если злоумышленник взломает одну CMS, то через залитый Web-shell сможет войти в директории соседних сайтов.
Чтобы предотвратить распространение уязвимости, мы предлагаем ограничить возможность выхода в соседние директории для любого хоста площадки.

  1. Выберите аккаунт хостинга, на котором нужно изолировать один и более ресурсов.
  2. В списке размещенных доменов выберете хост, который требуется изолировать.
  3. Выберите в меню настроек хоста пункт: «Изоляция сайта» и активируйте опцию.

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

Классический PHP хостинг HDD

Безлимитный SSD-хостинг SSD

Как безопасно размещать сайты на хостинге

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

Виртуальный (он же “шаред”/shared) хостинг можно представить в виде коммунальной квартиры или общежития, где живут несколько сайтов в одном общем виртуальном пространстве. У большинства хостинг-компаний на аккаунтах shared-хостинга (это те тарифы, где можно размещать 2, 3, 10, 50 сайтов) ресурсы не изолированы друг от друга: у всех сайтов один общий владелец, а скрипты сайта выполняются с правами того единственного владельца аккаунта или с правами пользователя веб-сервера www-data (к счастью, последнее встречается все реже). Фактически это означает, что скриптам одного сайта разрешено создавать, удалять, редактировать файлы любого другого сайта на том же аккаунте, а также скрипты одного сайта могут получить доступ к базе данных другого сайта. Поэтому хакеру достаточно взломать один сайт, чтобы получить контроль над всеми сайтами хостинг-площадки . Например, заразить их вирусами, получить доступ к чувствительным/конфиденциальным данным или полностью уничтожить.

Как все это проецируется на реальную жизнь?
К нам обращается владелец сайтов, размещенных на shared-хостинге, с жалобой на какой-то определенный сайт (с него может идти спам или доступ к нему блокирует антивирус), но после экспресс-проверки сайтов аккаунта оказывается, что на остальных также загружены хакерские скрипты или внедрен вирусный код. То есть взломан и заражен весь аккаунт. Вместо одного сайта нужно лечить все пять (десять, двадцать, пятьдесят,…) Клиент в печали.
Часто в целях финансовой экономии владелец shared-аккаунта просит вылечить только один сайт, а остальные не трогать (или вылечить их позже). Это плохая практика, так как уже через несколько дней вредоносный код с соседнего зараженного сайта может снова попасть на вылеченный и он окажется повторно инфицирован . Поэтому при взломе / заражении сайтов на виртуальной площадке, где размещено больше одного сайта, необходимо обязательно проводить работы с каждым сайтом (сканировать на вирусы и хакерские скрипты, лечить, если сайт заражен, и ставить защиту от взлома). В противном случае гарантированного избавления от взломов и заражения не будет, а сам процесс лечения будет напоминать вычерпывание воды из дырявой лодки. То есть бесконечный процесс: пока один чистили от вирусов, второй уже заразился.

  1. изолировать сайты на отдельных аккаунтах: каждому сайту купить отдельный аккаунт на shared-хостинге и перенести сайты на них, после чего постепенно вылечить сайты
  2. удалить или заблокировать сайты, которые не представляют особой ценности, а остальные в течение суток вылечить и защитить от взлома
  3. вылечить и защитить от взлома все сайты на виртуальной площадке в течение суток (или быстрее)
  1. сайты должны быть изолированы друг от друга , то есть размещены в разных пользовательских аккаунтах виртуального хостинга (или размещены на виртуальном хостинге, где данная изоляция уже заложена в архитектуру хостинга, но таких очень мало)
  2. сканирование, лечение и защита должны быть выполнены для всех активных сайтов виртуальной площадки, причем в сжатый временной интервал (например, в течение суток или быстрее).
  1. к каждому сайту можно сделать отдельный SFTP аккаунт (и перестать пользоваться старым и небезопасным FTP)
  2. для каждого сайта можно прописать оптимальные настройки, повысив безопасность и производительность, и быть уверенным, что они не сломают другие сайты на площадке
  3. seo-специалистам, фрилансерам-программистам можно предоставлять доступы только к одному сайту (по FTP/SSH) и не бояться, что они сломают соседние сайты
  4. лечение и защиту сайов в случае массового взлома можно выполнять постепенно, по одному

Timeweb и доступ ко всем сайтам через шелл

уже писали 1) разнести сайты по разным аккам шаред хостинга. 2) перейти на впс и так же разнести сайты (apache mpm itk, cgi, FastCGI, SUPHP, etc.) 3) забить и всетаки найти дырявый скрипт.

На сайте с 21.02.2008
28 мая 2011, 19:01
Den73:
3) забить и всетаки найти дырявый скрипт.
вот это мне ближе. Всем спасибо.
На сайте с 19.02.2005
28 мая 2011, 19:41
Публичные извинения хостеру не хочешь оставить?
Не стоит плодить сущности без необходимости
На сайте с 21.02.2008
28 мая 2011, 20:02

Andreyka, собственно говоря за что? Я нормально общался с ними и продолжаю общаться в ICQ. Так же, я сразу им отписал, что выложу наш разговор на сёрч. Всё по чесноку Андрейка 😉 Но если конечно кого то задели мои действия, извиняюсь. Мне не трудно. P.S. А вообще я очень доволен хостингом, всегда и даже ночью можно им писать в ICQ со своими насущными проблемами. Я просто думал что сотрудник немного юлит, сказав то, что нельзя закрыть доступ с одного сайта к другим, но теперь всё прояснилось.

На сайте с 25.04.2008
28 мая 2011, 20:26

если все сайты на PHP, то изолировать их друг от друга можно так: 1. отключить CGI, SSI, actions 2. отключить через disable_functions в PHP system и иже с ним 3. установить для каждого сайта нужный open_basedir

На сайте с 29.09.2005
28 мая 2011, 21:04
Andreyka:
Публичные извинения хостеру не хочешь оставить?

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *