Главная » Хабрахабр » Как построить защиту от фрода в масштабах корпорации. Лекция на YaC 2018

Как построить защиту от фрода в масштабах корпорации. Лекция на YaC 2018

29 мая прошла Yet another Conference 2018 — ежегодная и самая большая конференция Яндекса. На YaC этого года было три секции: о технологиях маркетинга, умном городе и информационной безопасности. По горячим следам мы публикуем один из ключевых докладов третьей секции — от Юрия Леонычева tracer0tong из японской компании Rakuten.

В нашем случае ничего экстраординарного нет, но один метод хочу упомянуть. Как мы аутентифицируем? Нет, мы не майним биткоины на компьютерах пользователей. Кроме традиционных видов — капчи и одноразовых паролей — мы используем Proof of Work, PoW. Мы используем PoW, чтобы замедлить атакующего и иногда даже заблокировать полностью, заставив его решить очень сложную задачу, на которую он потратит очень много времени.

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

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

Из более чем 70 наших сервисов в России известен Rakuten Viber, и если тут есть футбольные фанаты, возможно, вы знаете, что наша компания — генеральный спонсор футбольного клуба «Барселона». Компания Rakuten не очень широко известна в РФ, но думаю, вы все знаете ее по двум причинам.

И естественно, у нас всегда есть запрос от бизнеса на системы защиты от фрода. Поскольку у нас очень много сервисов, есть свои платежные системы, свои кредитные карты, множество reward-программ, мы постоянно подвергаемся атакам злоумышленников.

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

Если вы будете покупать fraud prevention-систему или попытаетесь сделать ее сами, вам в первую очередь нужно оценить затраты.

Мы опирались на то, что у нас от фрода есть некоторые виды финансовых потерь. Как мы считали, нужен ли нам fraud prevention? Это затраты на службу техподдержки, которая будет общаться с пользователями, разрешать конфликтные вопросы. Это прямые потери — деньги, которые вы вернете своим клиентам, если они были похищены злоумышленниками. И есть прямые затраты на разработку системы. Это возврат товаров, которые очень часто доставляются по ненастоящим адресам. И есть третий очень важный аспект ущерба от атакующих — упущенная прибыль. Если вы сделали систему защиты от фрода, развернули ее на каких-то серверах, вы будете платить за инфраструктуру, за разработку ПО. Она состоит из нескольких компонентов.

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

Это customer acquisition cost, CAC. Также мы платим деньги за рекламу, и если пользователь ушел, они потеряны. И если у нас много автоматизированных пользователей, не являющихся реальными людьми — мы имеем ненастоящие цифры monthly active users, MAU, которые тоже влияют на бизнес.

Давайте посмотрим с другой стороны, со стороны атакующих.

Но какой бы метод они ни использовали, им все равно нужно инвестировать деньги, заплатить за атаку, они тоже тратят какие-то средства. Некоторые докладчики говорили, что атакующие активно используют ботнеты. Это делает атаку на нас невыгодной, и злоумышленники просто уходят ломать другой сервис. Наша задача, когда мы делаем систему fraud prevention, найти такой баланс, чтобы атакующий потратил слишком много денег, а мы потратили меньше.

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

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

Позже приведу пример. Массовая регистрация аккаунтов, для нас она очевидна вредна.

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

Ну или просто кража персональных данных. Есть еще неочевидные для e-commerce, но очевидные для Яндекса проблемы — атаки на рекламный бюджет, click fraud.

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

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

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

Так что профит не пошел впрок. Тут нет девятого пункта, его позже арестовала полиция.

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

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

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

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

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

У нас 95% вредоносного трафика исходит от ботнетов. У меня всегда атака ботнетов ассоциируется с парадом Пикачу в Йокогаме.

И здесь внимательный человек может заметить, что я вроде сказал, что атака равномерно распределена по земному шару. Если посмотреть на скриншот нашей системы мониторинга, вы увидите множество желтых пятен — это заблокированные запросы от различных узлов. Это довольно любопытный случай. Но на карте есть явная аномалия, красное пятно в районе Тайваня.

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

Если у вас маленький e-commerce веб-сайт или маленький региональный сервис, у вас особых проблем нет. Если говорить о скоупе, о поверхности, о том, что мы защищаем. Ну и пользователи, плохие, хорошие, которые к вам приходят. У вас есть сервер, может, несколько, или виртуальные машины в облаке. Защищать особой проблемы здесь нет.

У нас есть сервисы, развернутые в наших собственных дата-центрах, в Европе, в Юго-Восточной Азии, в США. В нашем случае все сложнее, поверхность атаки огромная. Плюс некоторые сервисы развернуты в облачной инфраструктуре, причем не нашей собственной. У нас пользователи тоже на разных континентах, причем как хорошие, так и плохие.

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

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

Итак, из чего и как мы собрали нашу систему?

Использовали силу множества «сусликов». Нам удалось использовать только open source компоненты, это было достаточно дешево. Использовали очереди сообщений и БД. Значительная часть ПО была написана на языке Golang. Мы преследовали две цели: сбор данных о поведении пользователей и расчет репутации, проведение каких-то действий, чтобы распознать, хороший пользователь или плохой. Для чего нам это было нужно?

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

У нас есть бэкенды, которые также реплицируют состояние репутации пользователей с помощью Cassandra.

Шина данных, ничего секретного, Apache Kafka.

События и логи в одну сторону, репутация в другую.

Мозг построен на Apache Storm, и самое интересное — что происходит там внутри. И естественно, у системы есть мозг, который считает, плохой это пользователь или хороший, плохая это активность или хорошая.

Но сначала расскажу, как мы собираем данные и как блокируем злоумышленников.

Про некоторые из них уже говорили коллеги из Яндекса в своем первом докладе. Здесь существует множество подходов. Антон Карпов сказал, что файрволы — это плохо, они нам не нравится. Как блокировать злоумышленников? Мы предпочитаем использовать более высокоуровневые блокировки, на седьмом уровне, на уровне приложения, с помощью аутентификации запросов с помощью токенов, сессионные кук. Действительно можно блокировать по IP-адресам, тема для России очень актуальная, но этот метод нам не подходит совершенно.

Давайте посмотрим сначала на блокировки на низком уровне. Почему?

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

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

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

В нашем случае ничего экстраординарного нет, но один метод хочу упомянуть. Как мы аутентифицируем? Нет, мы не майним биткоины на компьютерах пользователей. Кроме традиционных видов — капчи и одноразовых паролей — мы используем Proof of Work, PoW. Мы используем PoW, чтобы замедлить атакующего и иногда даже заблокировать полностью, заставив его решить очень сложную задачу, на которую он потратит очень много времени.

Мы используем IP-адреса как одну из фич, также одним из источников данных для нас являются протоколы шифрования, поддерживаемые клиентами, и время установления соединения. Как мы собираем данные? Также данные, которые мы собираем с пользовательских браузеров, особенности этих браузеров, ну и токены, которые мы используем для аутентификации запросов.

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

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

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

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

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

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

Цепи Маркова — достаточно простая математическая модель, их очень легко считать на лету, поэтому они позволяют добавить еще один уровень защиты, отсеять еще часть трафика.

Мы поймали злоумышленников глупых, поймали злоумышленников среднего ума. Следующий этап. Для хитрых злоумышленников нужны дополнительные фичи. Теперь остались самые умные. Что мы можем сделать?

Сейчас браузеры — это достаточно сложные системы, у них много поддерживаемых фич, они запускают JS, у них есть различные низкоуровневые возможности, и все это можно собрать, все эти данные. Мы можем собрать какие-то отпечатки с браузеров. На слайде — пример вывода одной из опенсорсных библиотек.

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

Что такое профиль? Мы перешли к сравнению пользовательских действий с профилем, который у нас уже есть. Все эти данные накапливаются долгое время, и после этого вы можете начать использовать профиль. Мы знаем, что люди часто покупают и когда, какой у человека домашний провайдер, в каких регионах он бывал, когда он путешествует. Decision tree порождает конструкции вида if-else, занимает небольшое место в памяти, и вы можете строить деревья для каждого пользователя отдельно. Здесь уже мы применили machine learning, но использовали простые decision tree, поскольку это один из самых легко интерпретируемых человеком алгоритмов. Если что-то не так, вы можете показать пользователю какой-то челлендж — например, запросить двухфакторную аутентификацию при покупке, и тем самым остановить злоумышленника. Работают они быстро, вы можете сопоставлять поведение пользователей с профилем почти в реальном времени.

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

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

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

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

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


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Триумф и трагедия «Бурана»

В полностью автоматическом режиме он совершил 2 витка вокруг Земли и успешно приземлился спустя 205 минут. Ровно 30 лет назад с космодрома Байконур на ракете-носителе «Энергия» в свой единственный полёт отправился корабль «Буран». Это стало несомненным триумфом советской космонавтики, впервые ...

[Из песочницы] Несертифицированный GPS-трекер из Китая. Законно ли в России?

Иностранные интернет-магазины завалены разнообразными устройствами, оснащёнными GPS, GSM-модулями, позволяющими отслеживать местоположение наблюдаемого объекта и управлять устройством посредством SMS и мобильных приложений. И, конечно же, большинство из них не сертифицированы и запрещены для ввоза/использования в России. Простой обыватель, услышав слова «несертифицированный» ...