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

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

Рынок лечения и защиты сайтов на данный момент на 90% является серым, оттого и непрозрачным. Большинство заражений сайтов лечится самостоятельно (в редких случаях), знакомыми веб-мастерами, агентствами и студиями, с которыми сотрудничает владелец сайта, фрилансерами и знакомыми знакомых. На открытый рынок доходит примерно 10% всего спроса, с которыми работаем мы (SiteSecure) и еще1-2 компании.

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

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

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

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

Лечение сайта бесплатно

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

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

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

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

Что делать?

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

Как показал наш прошлогодний опрос агентского рынка, только у трети студий и агентств в договоре присутствует пункт об обеспечении безопасности сайта (часто просто перечисление функций по безопасности в коммерческих CMS и хостинге), пункт про лечение сайтов есть у единиц.

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

Не долеченный сайт

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

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

Типичный кейс такого псевдо-лечения: сайт вроде вылечен, подается заявка на исключение его из черных списков Google Safebrowsing и Яндекс Safebrowsing. После перепроверки поисковыми системами выдается сообщение, что вредоносный код все еще присутствует на сайте.

В итоге все лечение затягивается на срок от нескольких дней до недели, клиент зол и недоволен.

Что делать?

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

Выявить весь вредоносный код на сайте можно — используя дополнительные инструменты (сканеры sitesecure.ru/scan, sitecheck.sucuri.com, утилиты Манул, Ай-Болит, MalDev и ClamAV). Часть из них просты в эксплуатации, с остальными сможет справиться любой разработчик средней руки. Что важно — все они бесплатные и доступны в интернете.

Для контроля процесса просите разработчика прикладывать к тикету или таску на лечение сайта результаты проверки каждым из инструментов.

Сайт удаляется только из черных списков Google и Яндекса

После лечения сайта, полного устранения вирусной угрозы и последствий взлома владельцы почти всегда подают заявки на перепроверку и исключение сайта из черных списков поисковых систем (Google Safebrowsing и Яндекс Safebrowsing), но забывают сделать то же самое с черными списками антивирусов, фишинга и спама. А между тем зараженные сайты попадают туда достаточно быстро.

Из всех черных списков полностью вылеченный сайт автоматически исключается за период от двух дней до нескольких месяцев, в зависимости от периодичности перепроверки.

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

Типичный пример: сайт исключен из черных списков Google и Яндекса, но остается в черном списке в Лаборатории Касперского. А что это значит? Это значит, что примерно для 55% всех домашних и корпоративных пользователей сайт будет полностью недоступен из-за блокировки антивирусом.

Что делать?

Для начала стоит сказать, что помимо поисковых систем для сайта в Рунете наиболее ощутимо будет попадание в черные списки Лаборатории Касперского (Kaspersky), ESET, Dr.Web, Avast и Phishtank. Если первые опасны тем, что имеют весомое количество пользователей в России, для которых они могут сделать сайт недоступным, то последний сервис является самым влиятельным черным списком фишинговых сайтов. Внесение во многие другие списки чаще всего не приводит к каким-либо ощутимым потерям и простоям в работе (не считая некоторые черные списки спама).

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

Мы в свое время описали с картинками, как исключить сайт из черных списков Касперского, Dr.Web и ESET:

• исключение из черного списка Kaspersky;
• исключение из черного списка Dr.Web;
• исключение из черного списка ESET.

Непрозрачность процесса лечения сайта для клиента

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

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

К чему приводит эта непрозрачность процесса лечения сайта? Например, при возникновении какого-нибудь бага на сайте — поехала верстка, перестала работать форма регистрации/обратной связи, не работает кнопка, появился вирус — клиент будет винить студию. Хотя причина могла быть в том, что владелец сайта сам не соблюдает меры безопасности или влез в код и что-то поломал.

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

Что делать?

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

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

Какая информация должна присутствовать в отчете?

1. Перечень вылеченных файлов.

2. Какие защитные меры были приняты, чтобы сайт был лучше защищен от заражений.

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

4. Условия гарантии, где прописан ее срок и то, что не является гарантийными случаями.

Мы еще добавляем в отчет доступы к аккаунту sitesecure.ru, который в рамках гарантийного обслуживания проверяет безопасность сайтов, чтобы заражения не повторились или клиент узнал о них сразу же, а также сведения о настроенном дополнительном резервном копировании.

«А защищать кто будет?»

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

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

Важно понимать: вкладываться в профессиональные WAF решения (где фильтрация идет на уровне DNS, а не на уровне CMS), средства защиты от DDoS-атак, средства обнаружения вторжений и аудита кода нужно только тогда, когда час простоя сайта или потеря информации, на нем содержащейся, будут стоить дороже всех этих средств защиты. Так, кстати, продают средства защиты от DDoS-атак банкам — большинство банков четко понимают, сколько они потеряют за час недоступности своего банк-клиента.

Какие меры чаще всего применяют для защиты после лечения:

• обновление уязвимого компонента или установка «костыля»;
• смена паролей от FTP/SSH, админ-панели сайта.

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

Что делать?

Способов и мер защиты сайта множество — WAF, цементирование, настройки хостинга и CMS, регламенты работы с доступами, системы защиты сайта и мониторинга безопасности.

Главное — придерживаться правил.

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

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

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

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

• меняем пароли к FTP/SSH, админ-панели сайта, хостинг-панели;
• прописываем настройки безопасности на хостинге;
• защищаем админ-панель сайта от брутфорса и захода на нее нежелательных лиц;
• ограничиваем возможность загрузить вредоносный код в неизменяемые каталоги;
• настраиваем дополнительное резервное копирование сайта;
• обновляем небезопасные компоненты;
• устанавливаем хранение логов за максимально возможный период;
• прописываем в .htaccess настройки безопасности, защищающие от нецелевых атак;
• подключаем сайт к мониторингу безопасности SiteSecure, чтобы в случае появления проблем безопасности мы и клиент узнавали о них первыми.

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

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

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

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