Байки из облака: три обыкновенных истории из жизни Cloudflare

Привет, Хабр.

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

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

История первая

С помощью BGP наши сервера начинают анонсировать IP-префикс клиента, сам же клиент это делать перестаёт.С помощью BGP наши сервера начинают анонсировать IP-префикс клиента, сам же клиент это делать перестаёт.

Люди делятся на два типа: одни не делают бэкапы, другие уже делают. С защитой от DDoS та же история.

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

Дратути, мы готовы к решительной атаке на ваш домек. Ваши зомби.Дратути, мы готовы к решительной атаке на ваш домек. Ваши зомби.

Только в конце ещё было предложение перевести энное количество биткоинов.

Разумеется, средних размеров интернет-провайдер не мог совсем не озаботиться защитой от DDoS. В их центрах стояли аппаратные средства защиты: красивые, умные и дорогие коробки. Проблема с такими железяками — они быстро устаревают. Как говорится, генералы всегда готовятся к прошедшей войне. А DDoS сегодня — это уже не тот DDoS, что пять лет назад. Ботнеты уступают место оптовым закупкам VPS — так проще, дешевле и массовее. Соответственно, растёт и количество гигабайт трафика в секунду, которое злоумышленник готов обрушить на ваши сервера.

Long story short, вскоре после «письма счастья» на инфраструктуру нашего будущего клиента пошла массированная атака на 3–4 уровне. TCP- и UDP-флуд чуть ли не со всего мира (но в основном из Китая). У дорогих железок быстро исчерпалась пропускная способность, и всё легло. И тогда клиент обратился к нам. Если бывали у нас на сайте, возможно, помните эту оранжевую кнопку в правом верхнем углу.

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

Методика спасения у нас отработанная. Есть такая штука, называется Magic Transit. Это технология, которую мы долгое время разрабатывали для защиты собственных серверов, а в 2019 году начали предоставлять как enterprise-решение.

Если в двух словах, то суть очень проста. Наша инфраструктура становится между клиентом и остальным интернетом. С помощью BGP наши сервера (все сразу) начинают анонсировать IP-префикс клиента, сам же клиент это делать перестаёт. Когда кто-то обращается к серверам клиента, он благодаря Anycast вместо этого обращается к ближайшему серверу Cloudflare. Там происходит очистка трафика, о которой можно написать отдельную статью (возможно, как-нибудь потом). Затем запросы, прошедшие фильтрацию, перенаправляются клиенту через Generic Routing Encapsulation. Поскольку 95% пользователей интернета находятся не более чем в 50 мс пинга от серверов Cloudflare, а над оптимизацией анти-DDoS алгоритмов мы корпеем уже с десяток лет, конечный пользователь вряд ли даже заметит, что что-то изменилось. А вот злоумышленник ещё как заметит — по отсутствию эффекта от своих атак.

Наши специалисты префикс за префиксом прятали основную инфраструктуру клиента за Magic Transit. Меньше чем через сутки мы полностью взяли на себя анонс их автономной сети. Когда атакующие обнаружили, что флуд на 3–4 уровне перестал давать результаты, они переключились на седьмой, атаковали сайт и админку —, но для этого уровня у нас, разумеется, тоже есть механизмы защиты, включить их было минутным делом. Защита Cloudflare основана не на специализированных железках, она software-defined и работает на обычных линуксовых серверах. Вскоре хакерам эта история наскучила, и им пришлось оставить свои попытки.

История вторая

Нескольким сотрудникам отдела логистики пришли письма, ассоциированные с компанией DHL, но с необычного домена...Нескольким сотрудникам отдела логистики пришли письма, ассоциированные с компанией DHL, но с необычного домена…

На этот раз клиент — центральноевропейская компания, производящая моторостроительное оборудование. Изначально обратилась к нам по поводу защиты от DDoS. Однако на обсуждении выяснилось, что их также беспокоит безопасность почтового сервиса, конкретно — спам и фишинговые атаки. И мы предложили им попробовать ещё одно наше enterprise-решение — продукт для борьбы с фишингом под названием Area 1.

В своей работе компания использовала Office 365, почта — на Microsoft Exchange, порядка 1 000 пользователей. Мы подключились через API и через 15 минут запустили сканирование. А через 30 — поймали первую атаку. Что, в общем-то, нас не удивило — вполне обычная ситуация. Скорее мы бы удивились, если бы из 1 000 почтовых ящиков крупной компании ни один не был атакован в течение, скажем, часа. Специалисты из Area 1 говорят, что почти каждая компания подвергается атаке хотя бы раз в трое суток. С каждым годом фишинговых атак становится всё больше, и что особенно неприятно — они становятся изощрённее. У фишинговых писем всё меньше очевидных маркеров, они настолько похожи на настоящие, что даже внимательный и осторожный пользователь может попасться на крючок.

В нашем случае система Area 1 обнаружила письма, в которых использовалась атрибутика DHL (название, логотип и прочее), однако пришедшие с необычного домена. Да, тут, пожалуй, надо немного рассказать, как работает Area 1. Во-первых, она включает в себя мощный интернет-кроулер — наверно, второй по мощности после гугловского. О любом новом домене, зарегистрированном в интернете, кроулер узнаёт максимом в течение суток. После чего анализирует содержимое страниц на этом домене, делает выводы и наполняет базу данных. В частности, нас интересует связь доменов с крупными компаниями. У Area 1 есть механизмы, позволяющие устанавливать такие связи.

Во-вторых, это, разумеется, система анализа электронной переписки. Письма анализируются на многих уровнях: и по ключевым словам, и с помощью эвристик, и с помощью NLP, и по стилистике, и по тону… Нельзя сказать, допустим: «Area 1 основана на машинном обучении». Area 1 основана на всём сразу.

Так вот, в нашем случае система обнаружила, что нескольким сотрудникам отдела логистики пришли письма, ассоциированные с компанией DHL, но с необычного домена. Дополнительно насторожило то, что в письмах содержалась финансовая информация: якобы новые номера корреспондентских счетов, на которые предлагалось переводить оплату услуг DHL. Area 1 сверилась с базой данных интернет-кроулера, выяснила, что домен был зарегистрирован недавно и, вероятнее всего, с DHL не ассоциирован. Таким образом, система пришла к выводу, что, вероятнее всего, это фишинговая атака. После чего заблокировала подозрительные письма и уведомила администратора.

Каким бы изощрённым ни был современный фишинг, Area 1 ещё изощрённее. Звучит как откровенно рекламное утверждение, но мы знаем, о чём говорим, поскольку уже два года используем её для собственной защиты. За два года ни одна фишинговая атака на Cloudflare — ни реальная, ни тестовая — не достигла успеха. Area 1 просто методично перекрывает все возможные лазейки. Например, один из распространённых векторов атаки — сокращатели ссылок. Разумеется, если сокращённая ссылка сразу ведёт на какой-то плохой сайт, это легко обнаружить. Но можно сделать хитрее — в момент прихода письма ссылка ведёт на вполне добропорядочный сайт, а уже потом её содержимое подменяется на зловредное. Чтобы бороться с этим, Area 1 ведёт реестр сокращённых ссылок из проверенных ей писем. Периодически кроулер ходит по ним и проверяет, не изменился ли адрес редиректа. В случае изменения поднимается тревога. В общем, скука и рутина.

История третья

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

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

Для решения первой проблемы — резкого пика в количестве запросов — у Cloudflare есть продукт под названием Waiting Room. Он перехватывает запросы по определённому адресу и направляет пользователя на страницу ожидания. Её можно кастомизировать на своё усмотрение, но обычно там показывается время начала продаж (если Waiting Room запущен заранее), место пользователя в очереди и предположительное время ожидания. После старта продаж каждую минуту определённое количество пользователей перенаправляется со страницы ожидания на страницу магазина. Тут, опять же, всё можно гибко регулировать.

Для борьбы с ботами используется штука с предсказуемым названием — Cloudflare Bot Management. Она многоступенчато анализирует каждый запрос — начиная с терминации TLS-соединения и до момента, когда запрос прошёл через нашу систему и готов быть передан клиенту. Всё время, пока запрос путешествует по нашим дата-центрам, о нём собирается вся возможная информация и подвергается анализу: эвристическому, поведенческому, с помощью машинного обучения и т. д. В итоге получается число — вероятность того, что запрос исходил от человека, а не был сгенерирован автоматически. На основании этого числа клиент может решить, что с таким запросом делать. Решает он это с помощью воркера — это что-то вроде амазоновских лямбда-функций, пишется клиентом, размещается на наших серверах.

Чаще всего запросы с вероятностью ниже некоторого порога просто отклоняются. Однако в случае нашего клиента решили поступить иначе. Эксклюзивные товары можно перепродать очень дорого — соответственно, атакующий приложит большие усилия, чтобы обойти защиту. А раз так — можно последовать заветам Сунь-цзы и внушить врагу, что он уже победил.

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

Эпилог

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

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

© Habrahabr.ru