Проверка сайта на вирусы в Волгограде: заражение приходит от соседа по хостингу
В этой статье
- Что означает «сайты на одном сервере»
- Права на файлы, которые открывают дверь
- Как заражение переходит от проекта к проекту
- Что смотрим при аудите на общем хостинге
- Когда пора уходить с общего тарифа
- Значит, виноват хостинг-провайдер?
- Поможет ли простой переезд к другому провайдеру?
- Как убедиться, что источник не в нашем сайте?
Есть ситуация, которая ставит владельца в тупик: код свой, обновления стоят, пароли уникальные, а вредоносные файлы появляются снова и снова. Причина в том, что ваш сайт живёт не один. Металлургия, химия, речная логистика, торговля и строительные компании Волгограда чаще всего размещаются на недорогих тарифах виртуального хостинга, а там на одном сервере рядом с вами работают десятки, иногда сотни чужих проектов.
Что означает «сайты на одном сервере»
Виртуальный хостинг – это одна машина, поделённая между клиентами. При грамотной настройке каждый аккаунт изолирован и не видит соседей. При экономной настройке процессы работают от общего пользователя, а права на каталоги выставлены с запасом, и тогда взломанный сайт соседа получает возможность читать чужие файлы, в том числе конфигурацию с паролем к вашей базе данных.
Права на файлы, которые открывают дверь
- 777 на каталогах, поставленные когда-то «чтобы заработала загрузка картинок»;
- 666 на файле конфигурации с логином и паролем базы;
- отсутствие open_basedir, из-за чего скрипт ходит выше своей папки;
- общая директория временных файлов для всех аккаунтов сервера;
- один пользователь операционной системы на пять ваших сайтов.
Права 777 не нужны ни одному нормально настроенному сайту. Каталогам достаточно 755, файлам 644, а конфигурации лучше 600.
Как заражение переходит от проекта к проекту
Типичный случай: у компании три сайта на одном аккаунте – основной, старый лендинг и внутренний портал. Взломали заброшенный лендинг, но вредоносные файлы через полчаса появились во всех трёх каталогах, потому что писать в них может один и тот же процесс. Дальше лечение вирусов сайта уже нельзя вести по одному проекту: чистить нужно все сразу, иначе оставшийся заново заразит вылеченные.
Что смотрим при аудите на общем хостинге
Помимо обычной диагностики проверяем: от какого пользователя выполняются скрипты, работает ли изоляция аккаунтов, какие права стоят на каталогах и файлах, есть ли посторонние сайты в вашем аккаунте, что лежит в общем временном каталоге и совпадает ли время появления вредоносных файлов в разных проектах. Такая проверка сайта на вирусы отвечает на главный вопрос: источник внутри вашего кода или пришёл со стороны.
Когда пора уходить с общего тарифа
Три признака: на сайте есть оплата или персональные данные клиентов, посещаемость выше тысячи человек в сутки, повторные заражения без найденной уязвимости в вашем коде. В любом из этих случаев отдельный виртуальный сервер решает вопрос надёжнее, чем очередная чистка, и обходится примерно в тысячу рублей в месяц.
Значит, виноват хостинг-провайдер?
Ответственность делится. Провайдер отвечает за изоляцию и настройку сервера, вы – за актуальность движка, права на файлы и пароли. Требовать от хостера чистку своего кода бессмысленно, но запросить у него журнал доступа и отчёт сканера можно и нужно.
Поможет ли простой переезд к другому провайдеру?
Только если сначала вылечить сайт. Иначе вы перевезёте вредоносные файлы вместе с архивом и получите то же самое на новом месте, потеряв время на смену адресов серверов.
Как убедиться, что источник не в нашем сайте?
По времени и способу. Если вредонос появился одновременно в нескольких каталогах, а в журнале обращений к вашему сайту нет ни одного подозрительного запроса перед этим моментом, файлы записаны не через ваш код. Это разговор к провайдеру, и защита сайта от вирусов в такой конфигурации начинается со смены тарифа.
Разобраться, откуда именно приходит заражение, поможем по телефону +7 (901) 417-22-12 или по адресу info@rostsayt.ru. Смежные задачи: сопровождение и мониторинг, соответствие 152-ФЗ, перенос проекта на новую площадку в рамках услуг.
