Россия+7 (495) 960-65-87

Что делать, чтобы избежать массового взлома сайтов на мультисайтовых аккаунтах хостинга

Россия+7 (495) 960-65-87
Шрифт:
0 6927

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

Причина массовых взломов чаще всего кроется в неправильном размещении сайтов на хостинге, когда взлом одного сайта на аккаунте приводит по цепочке к заражению остальных. Например, один сайт на старой и уязвимой версии Joomla, Wordpress, MODx, DLE и т.п. подвергает угрозе все остальные сайты на аккаунте, даже если они работают на актуальных версиях CMS с обновленными плагинами.

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

«Скрытая угроза»

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

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

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

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

Многие владельцы сайтов заблуждаются относительно «изолированности» сайтов друг от друга. Считается, что если для каждого сайта создан отдельный FTP-аккаунт, то и сайты «живут» независимой друг от друга жизнью, то есть изолированы. Однако это не так, ведь речь идет об одном и том же пользователе операционной системы, и наличие виртуальных пользователей для работы FTP-доступов не исключает возможность взлома одного сайта через другой с помощью PHP-скриптов (для них в большинстве случаев не будет ограничений внутри аккаунта) или компрометации SSH-аккаунта или основного FTP-аккаунта. Поэтому проблема остается актуальной для очень многих клиентов. Единственное, что изолирует сайты друг от друга – это возможность создания отдельных SSH-доступов для каждого сайта. Используйте это как индикатор реальной «изолированности». Если для каждого сайта на хостинг-площадке нельзя организовать отдельный SSH-аккаунт, то сайтам угрожает массовый взлом.

Многие неопытные администраторы убеждены, что при определенных настройках PHP (например, настроив параметр open_basedir) можно ограничить свободу на хостинге и защитить сайты от массового взлома, но это, увы, не так. Во-первых, хакеры умеют обходить эти настройки, а во-вторых, кроме PHP есть и другие возможности активировать хакерские скрипты или внедрять вредоносный код в файлы соседних сайтов.

Безопасность сайта = технические средства защиты + организационные меры

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

Организационные меры включают в себя:

1) Обеспечение безопасного рабочего места, то есть компьютера, с которого выполняется администрирование сайта (лицензионное антивирусное ПО; обновленные до последней версии приложения и пр.).

2) Безопасное сетевое подключение при работе с сайтом (использование VPN – Virtual Private Network – при подключении к WiFi в общественных местах).

3) Инструктаж сотрудников по безопасной работе с сайтом (кому и как предоставлять доступы к сайту и хостингу).

4) Управление доступами (регулярная смена паролей; безопасная передача доступов; предоставление ограниченных прав доступа для выполнения задач подрядчиками).

5) Работа с подрядчиками (работа по договору; проверка сайта на предмет заражения после завершения работ на сайте третьими лицами).

6) Регулярная плановая проверка сайтов на предмет взлома и заражения специальными инструментами (для этой цели отлично подходят бесплатные сканеры типа AI-BOLIT (проверка файлов на хостинге) и ReScan.Pro)

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

Согласитесь, довольно трудно проверить, стоит ли на компьютере фрилансера, который удаленно занимается SEO вашего сайта, коммерческий антивирус; всегда ли контент-менеджер, обновляющий информацию в разделе «Публикации», использует VPN, подключаясь к WiFi в его любимой пиццерии; предоставляет ли ваш веб-мастер FTP-доступ дизайнеру в конкретную папку с нужным сайтом, а не SSH ко всему аккаунту хостинга.

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

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

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

Случаи из практики

В нашей практике много случаев, когда интернет-агентства или веб-студии «попадают» на крупную сумму из-за уязвимого сайта одного из своих клиентов или нерадивого подрядчика (фрилансера), которому делегируют определенную задачу. Ситуации типичны: агентство занимается поддержкой и продвижением клиентских сайтов, все сайты находятся на одном аккаунте хостинга или сервера, на котором нет технической изоляции проектов друг от друга. В один не очень прекрасный день обнаруживается, что все они заражены: инвестиции в SEO и продвижение нескольких сайтов потрачены зря, так как Яндекс или Google блокируют сайты в поисковой выдаче, хостер закрывает аккаунт за рассылку спама или фишингового контента и т.п.

Что в этом случае делают клиенты? Естественно винят во всем агентство. А агентство в недоумении: как такое могло случиться, что все сайты в одночасье оказались завирусованными? Начинается анализ взлома и заражения и выясняется, к примеру, что первопричиной был один из клиентов, доступы которого были перехвачены и использованы злоумышленником в неблаговидных целях сначала на его собственном сайте, а потом и на остальных. Или у одного из сайтов давно не обновляли CMS, в результате он пострадал при очередной вредоносной кампании (нецелевой атаки), а вместе с ним зацепило и всех его соседей по аккаунту.

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

«Герой» последней печальной истории – вебмастер, довольно успешно в течение нескольких лет поддерживающий десяток клиентских сайтов на CMS Битрикс.

Все шло благополучно до появления нового клиента с сайтом на CMS Joomla – некоммерческом движке, который часто не выдерживает даже нецелевой атаки. Никакой защиты на Joomla установлено не было, и, что вполне ожидаемо, однажды сайт пал жертвой «случайного взлома». И, как следствие, были заражены и соседние сайты на Битриксе.

Делаем выводы

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

(Голосов: 5, Рейтинг: 5)
Читайте нас в Telegram - digital_bar

Есть о чем рассказать? Тогда присылайте свои материалы Даше Калинской


Новые 
Новые
Лучшие
Старые
Сообщество
Подписаться 
Подписаться на дискуссию:
E-mail:
ОК
Вы подписаны на комментарии
Ошибка. Пожалуйста, попробуйте ещё раз.
Отправить отзыв
    ПОПУЛЯРНЫЕ ОБСУЖДЕНИЯ НА SEONEWS
    Google Data Studio: делаем красивые отчеты по контекстной рекламе для клиентов
    Askar Seitov
    1
    комментарий
    0
    читателей
    Полный профиль
    Askar Seitov - помогите! не могу понять почему по инструкции в вашей статье добавляю вычистяемые поля просто копирую ваш код, но датастудио выдает ошибку на этот код: Синтаксическая ошибка: Недопустимый входной символ. Убедитесь, что в формуле нет кавычек-лапок.. как это исправить? я все варианты кавычек уже попробовал
    Сайт на WordPress: за и против
    Мира Смурков
    1
    комментарий
    0
    читателей
    Полный профиль
    Мира Смурков - Людмила, я согласен с большинством комментаторов. Вы хоть один полноценный магазин сделали на этих движках? Woocommerce это система с супер возможностями. И к ней есть дополнительные модули, с функционалом, который вряд ли появиться на Битрикс. А самому это программировать - сотни тысяч рублей на разработку. А приведя в пример сложности с robots.txt и Sitemap вы ставите под вопрос вашу компетенцию в понимании Интернет-бизнеса и веб-разработки в целом. Во-первых это такие мелочи, а во-вторых это все делается на вордпресса за 2 минуты, и опять же с возможностями многократно превышающими Битрикс.
    #SEOnews14: мы празднуем – вы получаете подарки!
    Rizat Sundetov
    1
    комментарий
    0
    читателей
    Полный профиль
    Rizat Sundetov - 14
    Как ускорить сайт на WordPress, чтобы получить 100/100 в Google PageSpeed Insights
    1qa
    1
    комментарий
    0
    читателей
    Полный профиль
    1qa - 87 Performance 95 Accessibility 79 Best Practices 95 SEO аудит точнее будет
    Война с дубликатами. Как нужно и как не нужно канонизировать URL
    Дмитрий
    1
    комментарий
    0
    читателей
    Полный профиль
    Дмитрий - Здравствуйте, на сайте возможно несколькими путями дойти до почти одинаковой страницы, те отличаться будет только незначительная часть H1, а контент будет одинаковым, дело в применимости автозапчастей к разным автомобилям. Что из этого будет каноничной ссылкой и какие есть пути для решения подобных ситуаций? 1 - bpauto.ru/catalog/audi/audi-a6/a6-iv-c7-sedan-2011-2014/kuzov-naruzhnaya-chast/dveri-i-komplektuyushchie/dver-perednyaya-levaya/ 2 - bpauto.ru/catalog/audi/audi-a6/a6-iv-c7-rest-sedan-2014-n-v-/kuzov-naruzhnaya-chast/dveri-i-komplektuyushchie/dver-perednyaya-levaya/
    Как выбрать подрядчика для продвижения сайта: 7 уровней воронки поиска
    aashutosh
    1
    комментарий
    0
    читателей
    Полный профиль
    aashutosh - data science training institute in noida- Webtrackker Technology (8802820025) providing Data Science Training in Noida. Get ✓ 40 Hours Learning training✓ 70 Hrs Projects ✓ 24 X 7 Support ✓ Job Assistance. WEBTRACKKER TECHNOLOGY (P) LTD. C - 67, sector- 63, Noida, India. E-47 Sector 3, Noida, India. +91 - 8802820025 0120-433-0760 +91 - 8810252423 012 - 04204716 EMAIL:info@webtrackker.com webtrackker.com/Best-Data-Science-Training-Institute-in-Noida.php
    Как построить качественный ссылочный профиль на основе конкурентов
    Ирина
    5
    комментариев
    0
    читателей
    Полный профиль
    Ирина - Давно сотрудничаю с megaindex.com и считаю данный сервис одним из лучших в сео сегменте рунета да и не только рунета. Пользуюсь их инструментами для аналитики своих работ и выявлению своих и чужих ошибок. Да и ссылочный профиль, как и говорится в данной статье сделать гораздо проще и правильней при помощи как раз мегаиндекса. Добавлю еще что инструмент для поиска конкурентов у мегаиндекса очень удобный и простой в применении.
    6 причин, почему нет позиций и трафика
    Артур Латыпов
    0
    комментариев
    0
    читателей
    Полный профиль
    Артур Латыпов - Леонид, да 3 пункта повторяется, согласен. Но сильно актуальны и сейчас, смотрим на сайты, приходящие на SEO, которые ранее продвигались, практически на всех можно что из 6 пунктов найти, исправить и ситуация улучшиться оперативно.
    Google назвал три главных SEO-фактора
    Павел Андрейчук
    44
    комментария
    0
    читателей
    Полный профиль
    Павел Андрейчук - Я бы не стал утверждать что это так. У меня есть ресурс где ссылок.. ну я не знаю, полтинник может быть, вручную проставленные года за 2 и позиции хорошие по могим запросам именно в гугле, в то время как в Яндексе позиции ниже. Хотя конечно с ссылками позиции были бы лучше, наверное, но владелец увы не выделяет бюджет на ссылки.
    Чек-лист для аудита рекламных кампаний в Яндекс.Директе и Google Ads
    Елена Бикташева
    1
    комментарий
    0
    читателей
    Полный профиль
    Елена Бикташева - Спасибо! Была бы еще возможность скачивания.
    ТОП КОММЕНТАТОРОВ
    Комментариев
    910
    Комментариев
    834
    Комментариев
    554
    Комментариев
    540
    Комментариев
    483
    Комментариев
    373
    Комментариев
    352
    Комментариев
    262
    Комментариев
    249
    Комментариев
    171
    Комментариев
    156
    Комментариев
    137
    Комментариев
    121
    Комментариев
    105
    Комментариев
    97
    Комментариев
    97
    Комментариев
    96
    Комментариев
    80
    Комментариев
    77
    Комментариев
    69
    Комментариев
    67
    Комментариев
    60
    Комментариев
    59
    Комментариев
    57
    Комментариев
    55

    Отправьте отзыв!
    Отправьте отзыв!