Иногда сайты меняют своих «хозяев». Причины для этого могут быть разные: веб-студия получает клиента с его старыми сайтами на обслуживание (поддержку), компания или частное лицо приобретает новый проект с целью пополнения своих интернет-активов, веб-студия покупает «движок» с готовой базой данных для внутреннего использования и т.п. Во всех случаях скрипты сайта и база данных попадают в распоряжение новых администраторов и достаточно часто содержат ряд неприятных сюрпризов («пасхальных яиц» или «закладок»), которые случайно или намеренно оставил предыдущий хозяин или веб-мастер, ранее занимающийся разработкой и обслуживанием данного ресурса. Бэкдоры, веб-шеллы, дорвеи, black-hat seo ссылки, дополнительный административный аккаунт — это лишь небольшая часть проблем, с которыми может столкнуться новый хозяин или новоиспеченный администратор сайта. Но обо всем по порядку...

Откуда растут ноги

Рассмотрим типичную историю «брошенного» сайта.

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

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

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

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

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

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

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

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

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

Итак, рассмотрим проблемы безопасности сайтов, с которыми может столкнуться новый саппорт сайта.

Проблемы безопасности сайтов «б/у»

На что в первую очередь следует обратить внимание новому администратору ресурса, который получает сайт на поддержку?

Спам-ссылки (black-hat seo ссылки)

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

Источником появления ссылок может быть код биржи ссылок, который внедрен в шаблоны или скрипты (код sape, trustlink, linkfeed и др). Кроме того при разработке сайта могли использоваться бесплатные шаблоны или нелицензионные плагины, в которых часто внедряют как статические ссылки, так и код загрузки блока ссылок с удаленного сервера. Если данная проблема обнаружена на сайте, необходимо найти код, который внедряет ссылки на страницы и удалить его. В большинстве случаев задача решаемая поиском по файлам. Кстати, код ссылок может быть не только в файлах, но и базе данных.

Искать внешние ссылки можно SEO-сервисами, которые показывают внешние ссылки на страницах, с помощью грабберов контента (Teleport, Xenu Link Sleuth), а также путем анализа исходного кода страниц. Кроме того, использование специализированного сканера вредоносного кода, например, AI-BOLIT, также ищут внедрения ссылок в код.
 

Веб-шеллы, бэкдоры, «загрузчики»

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

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

Бэкдор — это небольшой хакерский скрипт или фрагмент кода, инжектированный в один из скриптов CMS. Задача бэкдора — предоставить хакеру «черный ход», через который можно выполнить произвольный код или загрузить веб-шелл, а далее получить контроль над скомпрометированным сайтом или сервером.

«Загрузчик» (Uploader) — это еще один вариант бэкдора, позволяющий загрузить произвольный файл на сервер. Естественно, хакера в первую очередь интересует загрузка инструментов для взлома (веб-шеллы, туннеллеры, спам-рассыльщики, и пр). «Загрузчик» достаточно сложно обнаружить, так как он представляет собой небольшой скрипт с кодом, встречающимся и в легитимных скриптах загрузки файлов на сервер (например, в upload формах CMS). Поэтому даже обнаружив файл «загрузчика» неопытный веб-мастер может не придать ему значения. Пример «зарузчика»:

Для поиска хакерских скриптов эффективно воспользоваться сканером вредоносного кода AI-BOLIT (http://revisium.com/ai/), который «заточен» под детектирование вредоносного кода в PHP/Perl/шелл скриптах.

Уязвимости

Можно с уверенностью утверждать, что в большинстве динамических сайтов, реализованных на PHP, ASP и скриптах с использованием CGI, есть уязвимости. Если сайт работает на популярной CMS, которая давно не обновлялась или написан неопытным веб-разработчиком, то данный сайт попадает в зону риска и уже скорее всего был (или в скором времени будет) взломан в ходе массовых атак через известные «дыры». При этом не важно, какая у сайта посещаемость и насколько он популярен. Чтобы снизить вероятность взлома, CMS сайта необходимо как можно быстрее обновить до последней доступной версии, на нее необходимо установить все существующие патчи безопасности, и, желательно, выполнить процедуру CMS hardening («цементирование» или «заморозку» сайта), которая запретит несанкционированные изменения на сайте. Кроме того, необходимо просканировать сайт на наличие хакерских скриптов, веб-шеллов и бэкдоров, чтобы проверить его на компрометацию и гарантировать безопасность сайта в будущем.

Для поиска уязвимостей на сайте можно специализированным программным обеспечением (Acunetix Web Vulnerability Scanner, XSpider, Nikto, Metasploit Framework, sqlmap и другими инструментами пентестера), а для популярных CMS и модулей — проверить уязвимости по базе http://www.cvedetails.com
 

Мобильный или поисковый редирект

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

Причиной мобильного редиректа может быть фрагмент кода, вставленный злоумышленником в шаблон, скрипт или базу данных сайта. Чтобы достоверно проверить свои сайты на наличие мобильного редиректа, в большинстве случаев достаточно подключить мобильное устройство к мобильному интернету через 3G/LTE сеть и открыть сайт в мобильном браузере.

Подробно вопрос обнаружения и удаления мобильных редиректов был рассмотрен в нашем докладе на конференции Яндекса: https://events.yandex.ru/lib/talks/2673/

Вирусный код, реклама

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

Дополнительный (забытый) административный аккаунт, заброшенные FTP аккаунты и невежественность подрядчиков

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

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

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

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

• Веб-разработчик может выходить в интернет через открытые сети (в кафе, в парке, в метро и через другие открытые WI-FI точки) без использования VPN, в результате чего доступы к хостингу и в административную панель сайта оказываются скомпрометированы, а переписка с владельцем сайта, содержащая конфиденциальную информацию, перехвачена злоумышленником (сейчас этим может заниматься любой школьник используя снифер трафика в promiscuous mode или специализированные приложения наподобие Intercepter-NG).

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

Теперь вы понимаете, почему не стоит доверять подрядчику (не имеет значения это веб-студия или фрилансер), и почему следует немедленно после окончания работ с сайтом менять все пароли.

Старые административные email’ы

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

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

Подмена платежных реквизитов и контактных данных

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

Неработающий функционал

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

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

Чеклист

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

Для удобства приводим чеклист новоиспеченного администратора сайта. Вот что нужно сделать сразу после получения сайта на обслуживание (поддержку):

1. Проверить регистрационную информацию аккаунта хостинга и домена. Убедиться, что все email’ы, контактные данные принадлежат владельцу сайта (включая домен, хостинг-аккаунт и административные аккаунты CMS).

2. Удалить лишние аккаунты: FTP/SSH, администраторов CMS. Оставить только минимально необходимый набор.

3. Сменить пароли у оставшихся аккаунтов: от биллинг и хостинг панелей, FTP, SSH, административных аккаунтов CMS. А также проверить и скорректировать привилегии для аккаунтов (сделать минимально допустимые права для каждого пользователя).

4. Выполнить аудит безопасности сайта: просканировать сайт на наличие вредоносного кода, вирусов, фактов взлома. Вылечить сайт, если необходимо, и установить защиту от взлома.

5. Обновить CMS и скрипты до актуальных версий, установить все необходимые патчи безопасности.

6. Проверить все основные сценарии поведения пользователя, выполнить функциональное тестирование пользовательских и административных разделов.

7. Настроить систему мониторинга сайта для своевременного обнаружения проблем в работе или взлома

8. Настроить систему резервного копирования сайта

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

10. Выработать правила безопасной работы с сайтом для персонала, обслуживающего ресурс и оформить ее в виде памятки.

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