Блог Яндекса для вебмастеров

Доклад команды безопасного поиска на РИТ-2012

26 апреля 2012, 11:40
В начале апреля на конференции РИТ-2012 был представлен доклад «Как не заразить посетителей своего сайта» . Этот доклад является кратким руководством по борьбе с вредоносным кодом. Надеемся, данный текст поможет вам не допустить заражения сайта, а если сайт всё же взломали – оперативно устранить причины и удалить вредоносный код.

 

В начале апреля мы сделали доклад «Как не заразить посетителей своего сайта» на конференции РИТ 2012. Этот доклад является кратким руководством по борьбе с вредоносным кодом.

 

Вступление 

Мы рассказываем об этом потому, что:

  • в сутки Яндекс детектирует среднем более 1400 новых заражений сайтов;
  • всего Яндексу известно более 230k заражённых хостов, к-рые недополучают из-за заражения примерно 100m показов в сутки;
  • с 24.05.2011 по 18.04.2012 было более 130 случаев заражения сайтов, которые знают все;
  • даже известные сайты в основном попадают под обычные, массовые заражения, которые легко предотвратить и устранить, если следовать рекомендациям, приведённым ниже.

Безопасность веб-сайтов нужна:

  • по общим причинам;
    • пользователям – чтобы не терять деньги (кража, мошенничество), ценные данные, время на лечение компьютеров, репутацию;
    • интернету – чтобы существовать (быть полезным для людей), без DDoS’ов, накрутки, спама;
    • злоумышленникам – чтобы пойти заниматься чем-нибудь полезным;
  • из финансовых соображений:
    • сайту – чтобы его трафик, пользователи ( деньги) не доставались другим:
      • не редиректить на другие сайты;
      • не заражать компьютеры пользователей;
      • не показывать чужих ссылок и рекламы;
      • предупреждения о заражении = – 99% трафика, поисковый спам = – 100% трафика;
    • поисковой системе – чтобы было, чем отвечать на запросы пользователей:
      • заражённые, испорченные, перенаправляющие сайты – это плохой ответ.

Как предотвратить заражение сайта 

  • не дать злоумышленникам взломать сайт и разместить на нём malware;
  • не размещать блоков с malware и вредоносных редиректов самим;
  • не давать размещать malware пользователям в UGC.

 

Как помешать злоумышленникам  

  • контролировать ввод данных пользователями:
    • закладывать контроль при разработке, причём не только на уровне javascript, но и на уровне серверного ПО:
      • проверять на стороне сервера, входят ли значения каждого параметра, которые принимает сервер, в допустимые списки и интервалы, допустим ли их размер;
      • обязательно проверять полученные от пользователя данные перед выполнением в eval, прямой вставкой в SQL-запросы, преобразованием типов, сохранением на сервере;
      • не оставлять параметров, нужных для отладочного режима, экспериментов с новой или отключенной функциональностью;
      • рассчитывать, что параметры могут быть отправлены серверу не только со страниц и из форм, которые сайт загружает в браузер пользователю, но и другими способами, и надёжно определить, откуда именно они отправлены, невозможно;
    • использовать WAF (Web Application Firewall) для защита от атак XSS, Injection;

 

  • контролировать операции (Insecure Direct Object References):
    • защита от IDOR, CSRF, закрытие доступа к консолям администрирования, резервным копиям, SVN;
    • проверять все возможные URL и GET-запросы.

  • обновлять CMS и серверное ПО, использовать минимум «кустарных» модулей, отключать лишнее, следить за новостями об уязвимостях своей CMS:
    • следить за обновлением и ограничением доступа к серверному ПО – OpenX, phpMyAdmin;
    • использовать дистрибутивы CMS из проверенных источников (в «nulled» дистрибутивы часто встраивают бэкдоры и вредоносные мобильные редиректы);

     

  • использовать сложные пароли от веб-серверного ПО (FTP, SSH, админ-панели хостинга, CMS):
    • не менее 11 символов: буквы, цифры, специальные символы, чтобы было легче запоминать, можно взять обычное слово и «разбавить» его цифрами и символами;

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

  • убрать данные, на каком ПО работает ваш сервер (ОС, веб-сервер, CMS), чтобы не позволять найти его с помощью поисковых dork-запросов;

 

    • анти-кликджекинг – чтобы злоумышленники не могли использовать ваш сайт в качестве фона, и накладывать на него сообщения наподобие «чтобы попасть – отправьте платную SMS»:
      • встраивать в свою страницу JavaScript-проверки наподобие:
        if (top.location != window.location) top.location = window.location
        или
        top.location = 'http://example.com'
      • выдавать HTTP-Header:
        X-FRAME-OPTIONS SAMEORIGIN
        или
        X-FRAME-OPTIONS DENY

      • хостингам – регулярно проверять свои сайты, например, например через Safe Browsing API Яндекса или API Яндекс.Вебмастера.

 

Как не заразить сайт самому, по незнанию  


      • блоки и реклама – только от проверенных партнёрских программ:
        • избегать «уникальных предложений» (подозрительно высокая плата за счётчики и блоки, монетизация мобильного трафика) – вместо денег отсутствие трафика и потеря позиций в поисковых системах;
        • использовать партнёрские программы со скрытыми блоками – опасно;
        • блоки и реклама – только от проверенных систем;
        • по возможности принимать только статический контент, а именно ссылки и картинки. Не принимать подгружаемые <script> и <iframe>. .swf, .jar и ActiveX принимать только в виде исходного кода, но не в скомпиллированном виде, перед компилляцией проверять;
        • о новых партнерских системах – искать отзывы, проверять, какой контент через них приходит; пример заражения из-за распространения вредоносного кода партнёрской системой – traffbiz.ru;

      • дистрибутивы CMS, виджеты, библиотеки – из проверенных источников (например, c официальных сайтов CMS):
        • дистрибутивы CMS из сомнительных источников, виджеты и сторонние библиотеки обязательно нужно проверять на распространение вредоносного кода:
          • как минимум сканировать их обычными антивирусами;
          • пример распространения версии CMS с встроенным backdoor'ом – DLE nulled by Zloy;
        • в wordpress-темах часто встречается подгрузка блоков с вредоносным кодом и ссылками для чёрного SEO – внимательно изучайте код шаблонов перед тем, как ставить их в CMS:
        • радио-виджеты для ucoz также могут быть заражены;

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

 

Как не дать заразить сайт пользователям через UGC  

      • антиробот – можно использовать для этого специальные плагины к CMS, например BotScout, и/или сделать такую проверку самостоятельно, на основании различных списков ip-адресов ботов, например с myip.ms;

 

      • валидация данных:
        • не давайте возможности вставлять javascript в <script>, тегах, гиперссылках;
        • не позволяйте вставлять <iframe>, <object>, <embed>, а также подгружать jar, swf, pdf, для которых сайт сам будет генерировать подобные теги;
        • лучше всего поддерживать конечный список разрешённых HTML-тегов;

         

      • проверять ссылки, например, через Safe Browsing API Яндекса, обращайтесь за доступом: и рекомендациями по подключению на safesearch@yandex-team.ru;

 

 

Как устранить заражение 

  • вовремя узнать;
  • остановить веб-сервер;
  • найти браузерное malware, чтобы было легче найти причину, по которой его выдаёт веб-сервер;
  • найти и удалить веб-серверное malware;
  • устранить причины заражения;
  • запустить веб-сервер снова.

Как вовремя узнать о заражении  

  • наблюдайте за аномалиями в трафике сайта, статистике переходов на него и с него, например по Яндекс.Метрике;
  • если пользуетесь системой контроля версий – регулярно сравнивайте то, что опубликовано, с тем, что должно быть;
  • если пользуетесь браузерами от Яндекса, Opera, Яндекс.Интернет, Firefox с Яндекс.Баром – при просмотре своего сайта увидите предупреждения;
  • сообщения в Я.Вебмастере http://webmaster.yandex.ru/;
  • читайте email, которые приходят на стандартные адреса веб-сайта, а также email, указанные в его whois:
    • при заражении присылаем на них уведомления;
    • используются адреса info@, webmaster@, admin@, abuse@, administrator@, contact@, postmaster@, support@;
    • проблему спама, который приходит на стандартные адреса, можно решить с помощью Почты Яндекса для домена;
  • сделайте книгу отзывов, в которой пользователи смогут пожаловаться, что сайт заражён;
  • если ваш сайт является крупным и известным, ищищте на форумах сообщения «<DNS-имя> заражён», например с помощью Яндекс.Подписок и Поиска по блогам;
  • системы мониторинга сайтов, такие как http://www.dasient.com/product-services/web-malware-protection/, http://verity.paladiononline.com/;
  • читайте блог http://safesearch.ya.ru/, мы пишем в нём об актуальных заражениях.

 

Как найти браузерное malware  

 

      • найти самостоятельно:
        • подготовить тестовый стенд:
          • Windows XP на виртуальной машине, IE+FF+Chrome+Opera без cookies и истории посещений;
          • Желательно IE7 и версии Sun Java, Acrobat Reader, Adobe Flash, выпущенные 2–3 года назад;
        • открыть свой сайт:
          • разными браузерами, с поисковой машины и напрямую, через прокси-сервер и напрямую, с обычным и с мобильным user-agent, можно использовать Firefox User Agent Switcher;
          • несколько раз, каждый раз смотреть, что загружается, например с помощью fiddler или HttpAnalyzer;
          • выданные сервером файлы глазами и проверять антивирусом;
          • признаки браузерного malware;
            • появление в коде страницы «лишних» тегов <iframe>, <script>, <object>, <embed>;
            • подгрузка данных/перенаправление на хосты в доменных зонах cz.cc, .in, .cn, .pl, прямых ip и dyndns-сервисов;
            • подделка под известные сайты: google-analylics.com, yandes.ru;
            • javascript c eval, unescape, document.write, document.location, document.URL, window.location, window.navigate, переопределение элементов DOM;
            • посторонний код в js-библиотеках;
            • длинные нечитаемые скрипты;
            • лишние операции со строками (переопределение, замена подстрок, смещение символов, конкатенация);
          • после каждого просмотра страницы – revert к исходному образу;

      • если не смогли найти вредоносный код или удалить его – обратитесь в тех. поддержку Яндекса, email – в статьях Помощи.

 

Как найти веб-серверное malware  

      • где искать:
        • в серверных скриптах, например:
        <?php header(“Location: evil.com” ?>
        • в шаблонах CMS:
          • особенно если SEO-ссылки или вредоносный код в конце страниц дублируюсь, лучше пояснить: как искать, в каких файлах;
        • в настройках веб-сервера или интерпретатора:
          • в .htaccess – настройки для mod_rewrite, php_value auto_append_file "\tmp\evil.txt";
          • особенно если серверный редирект, в т.ч. работающий только для мобильных, а также если до или после обычного блока <html>;
        • если сайт статический:
          • на соседнем сайте shared-хостинга, а также, вероятнее всего, утечка реквизитов доступа, либо заражение всего сервера;

      • признаки серверного malware:
        • посторонний код:
          • дата модификации совпадает с временем заражения или позже;
          • не соответствует версии из системы контроля версии или из резервной копии;
        • обфусцированный код – нечитаемый, неструктурированный, закодированный;
        • использует характерные функции:
          • eval, assert, create_function;
          • base64_decode, gzuncompress, gzinflate, ob_start, str_rot13, preg_replace;
          • file_get_contents, curl_exec.

           

Как устранить причины заражения  

      1. в 90% случаев на сервере есть веб-шелл, который обязательно надо отыскать; можно найти по характерным php-функциям или антивирусом;
      2. проверить антивирусом, например kaspersky.yandex.ru, рабочие станции всех, кто работает с веб-сервером;
      3. остановить веб-сервер;
      4. обновить ПО;
      5. сменить пароли: root, FTP, SSH, админ-панели хостинга, CMS; удалить везде лишних пользователей;
      6. серверное malware можно удалить только после этого, иначе его быстро восстановят;
      7. в течение нескольких недель пристально следить.

 

Если нашли что-то интересное

Отправьте вредоносный код, который нашли, специалистам Яндекса на анализ. Этим вы поможете и себе, и другим вебмастерам. Как это сделать, написано здесь.


Надеемся, данный текст поможет вам не допустить заражения сайта, а если сайт всё же взломали – оперативно устранить причины и удалить вредоносный код.

Команда Безопасного Поиска Яндекса