Русский
Русский
English
Статистика
Реклама

Qrator labs

Анонс. DDoS-атаки откуда берется и куда девается мусорный трафик

02.06.2021 22:14:13 | Автор: admin
Завтра, 3 июня в 15:00 в наших соцсетях выступит Георгий Тарасов, Product Manager в Qrator Labs.

Георгий выпускник ВМиК МГУ, работает в команде Qrator с 2012. Занимался разработкой, управлением проектами, собрал в компании команду pre-sales инженеров. Сейчас развивает в Qrator новый продукт, а именно защиту от онлайн-ботов.




План выступления


Задавайте вопросы в комментариях и Георгий ответит на них во время прямого эфира.

  • Откуда я знаю о DDoS и почему могу рассказывать
  • Каким образом DDoS причиняет боль, откуда берется тело атаки ботнеты, амплификация, пакеты, запросы
  • Ботнеты. Как возникают, на каких устройствах размножаются, как находят владельцев ботнетов и привлекают к ответственности (пример с атакой на некий онлайн-банк в 2014, Krebs разоблачение vDOS)
  • Общая инфа про методы защиты от DDoS блокировки отдельных запросов, источников, борьба на уровне глоб.маршрутизации. Коробки, ISP и сервисы.
  • Защита в даркнете. Уязвимость Tor к атакам. EndGame.
  • Косты: атака vs защита, почему такая большая разница
  • Странные и забавные случаи атак из практики защиты клиентов.


До встречи в эфире!


Предыдущий эфир можно посмотреть тут, ещё больше наших спикеров по хэштегу #ruvds_анонсы


Подробнее..

DDoS-атаки откуда берется и куда девается мусорный трафик

13.06.2021 18:05:09 | Автор: admin
На прошлой неделе в наших соцсетях выступил Георгий Тарасов, Product Manager в Qrator Labs.

Георгий выпускник ВМиК МГУ, работает в команде Qrator с 2012. Занимался разработкой, управлением проектами, собрал в компании команду pre-sales инженеров. Теперь развивает в Qrator новый продукт, а именно защиту от онлайн-ботов.

Делимся с вами расшифровкой эфира и записью.


Всем привет, меня зовут Георгий Тарасов. Я работаю в компании Qrator Lботнетовabs, знаю кое-что о DDoS-атаках и методах противодействия этим угрозам. В основном на собственном опыте, на опыте работы с клиентами, которые страдают от DDoS-атак или знают про угрозы, исходящие от них, и заблаговременно принимают решение выстроить себе защиту, применять контрмеры, быть готовыми к такой активности.
Из общения с десятками, потом сотнями (сейчас уже, наверно, перевалило за тысячу) разных организаций складывается достаточно интересная картина того, откуда приходят атаки, почему они случаются, какие действия бизнеса могут к этому привести. И, конечно, техническая сторона дела: что происходит на стороне жертвы, что происходит на транзите в сети к жертве, кто еще может пострадать от атаки, и многие другие вещи.
Сегодня мы, я думаю, достаточно неформально поговорим: не будем затрагивать прописные истины, а посмотрим, скорее, на эффекты DDoS-атак, попробуем понять, почему они происходят, и как вести себя, оказавшись один на один с DDoS-ером, который пришел на ваш ресурс, на промо-сайт или на сайт бизнеса, которым вы занимаетесь.

Сначала, наверно, вставлю пару слов о себе. Меня зовут Георгий Тарасов, я учился в МГУ на факультете ВМК, мечтал заниматься распределенными вычислениями, суперкомпьютерами, но жизнь повернулась немного по-другому. После выпуска я пришел в компанию замечательных людей, которых тогда было немного чуть больше десятка. И там сказали мне: ты слышал что-то про DDoSатаки? Я сперва округлил глаза: что за DDoS-атаки? Хакерство, киберпреступность, что это такое? Мне тут же пояснили, я изучил начальное количество материалов, почитал статьи; на тот момент это был 2012 год в отношении DDoS и защиты от них царил полный Дикий Запад. То есть, сервисы еще не заняли главенствующее положение защитников для мелкого, среднего и большого бизнеса, каждый защищался подручными средствами, кто во что горазд, нанимал специалистов для настройки фаерволов. И посреди всего этого оказалась та компания, в которую я пришел и она стремилась наладить более-менее одинаково высокий по качеству сервис как для мелких сайтов, которых прикладывают чем-то таким прикладным-хозяйственным, так и для крупного бизнеса, перед которым стояли гораздо большие угрозы.

Год за годом рабочая стезя меня толкала все ближе к самим клиентам, к их кейсам, к историям с их подключением. В итоге, со временем, я пришел к тому, чтобы заниматься работой pre-sale. То есть, приходит заказчик он либо уже под атакой, либо ожидает ее, либо просто хочет построить защищенную инфраструктуру для своего бизнеса. Он хочет подключиться к сервису, защититься от атак, купить дополнительные услуги. Его нужно проконсультировать, выяснить, что наибольшим образом подходит ему, выслушать, какие риски у него есть сейчас и какие ожидаются, и совместить гору с горой: понять, какой спектр услуг, какой сетап в техническом и организационном плане более других подойдет для того, чтобы ему снять боль, напряжение и неприятности, с которыми он пришел.

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

Вернемся к DDoS-атакам: мы о них говорим сегодня, и говорили также и полгода назад, и говорим помногу раз каждый год, но, тем не менее, они никуда не деваются. Они все еще с нами.
Надо сказать, что, несмотря на их эволюцию в техническом плане, появление новых векторов, рост полосы и рост интенсивности атак, те тулзы и подходы, которые DDoS-атаки используют, не слишком изменились за последние 30 лет. Давайте сравним это с хакерской активностью, со взломами, с поиском дырок, уязвимостей, различных способов проникновения через защиту чужого приложения и извлечения данных из него. У нас есть уязвимость в фреймворке, компоненте, инхаус-приложении; в нем обнаруживается дырка. Есть вектор атаки, который это эксплуатирует. Приходит ресерчер, приходит whitehat или случается реальная атака; разработчики, security-специалисты закрывают дырку. Она может позднее всплыть в видоизмененном виде снова, где-нибудь в новой версии фреймворка или в похожих решениях, но конкретный эпизод остается в истории. Дословного повторения мы вряд ли увидим.

С DDoS-атаками все по-другому. Абсолютно такие же векторы атак, использующие те же самые протоколы, ту же самую методу с точностью до сигнатуры трафика, продолжают долбить сайты и сети на протяжении десятилетий. Они нечасто сходят со сцены: сходят только векторы, использующие совсем устаревшие протоколы, которые оказываются закрыты на любом устройстве. Хотя и там иногда бывают приколы. Если мы посмотрим на список прикладных протоколов поверх транспортного протокола UDP, применяющихся в крупномасштабных volumetric-атаках с использованием амплификации, то увидим интересные экспонаты, которые, наравне с TNS, ATP, SSDB используются сплошь и рядом. Есть, например, MotD, RIPv1-протоколы. Пойди в любую компанию, спроси devops-ов или админов есть хоть один компонент или endpoint, слушающий или пишущий, который использует это? Скорее всего, на тебя посмотрят как на Рип ван Винкля из произведения Вашингтона Ирвинга, который проспал 100 лет и спрашивает какую-то нерелевантную музейную фигню. Тем не менее, если отверстие есть, то вода в него обязательно пойдет. Если где-то есть открытый порт для этого протокола и, не дай бог, есть какой-то стандартный системный компонент, который может слушать на этом порту, то атака может пойти туда. Поэтому зоопарк решений для организации DDoS не движется по исторической шкале из точки А в точку Б. Он от точки А продолжает прирастать вширь и вглубь всевозможными новыми методам по мере того, как новые протоколы появляются, развиваются, их внедряют крупные компании, и в них находятся свои приколы и схемы для того, чтобы принимающей стороне, читающей протокол, сделать больно.

Старые методы не сходят с арены. Простой пример: если посмотреть немного в историю, в первых зарегистрированных случаях крупных DDoS-атак в середине-конце 90-х, которые уже тогда попали в новости то есть, они не были замечены историками и исследователями спустя годы, а сделали заголовки сразу же использовался вектор TCP SYN Flood. То есть, это были атаки при помощи TCP SYN-пакетов. Любой человек, мало-мальски знакомый с тематикой DDoS-атак, который читал книги или смотрел презентации и статьи на эту тему, скорее всего, видел описание такой атаки на первых листах. Это, можно сказать, хрестоматийный случай генерации достаточно большого количества дешевого трафика, затраты на обработку которого на стороне сервера окажутся гораздо выше затрат на его создание со стороны атакующего ботнета, каких-то устройств, которые он использует. Если мы посмотрим в статистику атак за 2020-21 год, например, то увидим, что TCP SYN Flood никуда не делся, такие атаки все еще встречаются в дикой природе, и ими прикладывают крупных и мелких игроков бизнеса. Тулзы и ботнеты, которые генерируют TCP-трафик, тоже никуда не делись, потому что эта атака даже с поправкой на то, как изменилась производительность компьютеров и пропускная способность интернет-каналов и корпоративных сетей за последние 30 лет приводит к столь же эффективным результатам. От нее просто нет смысла отказываться. Другое дело, что мир уже научился чуть лучше от них защищаться, но и здесь есть некоторые оговорки.

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

image

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

DDoS-атаки


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

image

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

Тем не менее, на заре нашей юности был интересный эпизод: существовал один интернет-магазин кедровых бочек. Он не продавал кедровое масло или кедровые орешки продавал конкретно бочки для промышленного использования пищевиками. Это был их основной бизнес, продавались бочки через сайт; можно сказать, они одними из первых стали это делать. И, когда с клиентом пообщались по поводу атак на него, оказалось, что существуют другие интернет-магазины кедровых бочек, и между ними реально происходит кровная вражда: конкуренты постоянно DDoS-ят сайты друг друга, в нонстоп-режиме, пытаясь завернуть поток клиентов. Ну, много ли клиентов для кедровых бочек можно сказать, что это одни и те же люди, которые приходят либо в одно место, либо в другое, и вряд ли будут заказывать в обоих местах сразу. Поэтому за этот ручеек клиентов шла борьба не на жизнь, а на смерть.

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

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

Что мы знаем про облик DDoS-атаки в наше время? Что это часы паразитной нагрузки, или всплеск трафика на 5 секунд, который вырубает маршрутизатор? На самое деле, если взять среднее по больнице с учетом морга и крематория, получится ни то, ни другое. Что-то опосредованное. В прошлом году медиана длительности, по данным из нашего годового отчета, была около 5 минут;

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

Касаемо ботнетов и их задействованности в современном DDoS-ландшафте.


Самый большой ботнет, который мы наблюдали, и от атаки с которого мы защищали клиентов это порядка 200 тысяч источников. Это уникальные IP-адреса речь идет не об источниках трафика, о которых мы можем предполагать из емкости атаки, а об атаках, где используются валидные сессии, при которых источник должен себя подтвердить через TCP-handshake или более вышестоящие протоколы и сессии. То есть, это валидные устройства пользователей интернета, с которых приходил в сторону жертвы DDoS-трафик.

Нельзя сказать, что весь DDoS в мире приходит с подобных классических ботнетов. Я сейчас кратко опишу, в порядке прописных истин, как они вообще появляются, чтобы потом не останавливаться на этом. Ботнет это сеть устройств, подконтрольная злоумышленнику, который имеет возможность выполнять определенные действия на каждом из устройств этой сети например, генерировать трафик. За счет этого происходит распределённая атака на отказ в обслуживании: злоумышленник дает команду, устройства шлют трафик в различном виде и на разных уровнях пакеты, запросы, битики к цели, которую он хочет вывести из строя. Так мы привыкли видеть DDoS-атаки: есть тысячи зараженных машин, и хакер со своего C&C-центра машины, с которой осуществляется управление централизованно посылает броадкастом команду. Например, слать UDP-трафик на адрес Х, что и происходит. Но сейчас этот процесс может выглядеть немного по-другому, потому что существенный пласт атак использует подход с амплификацией (усилением) трафика. Его идея заключается в том, что напрямую ботнет трафик на ресурс жертвы не шлет. Задача ботнета сгенерировать некоторый начальный поток трафика, который может быть небольшим (порядка сотни мегабит), и за счет эксплуатации особенностей прикладных протоколов на базе UDP например, DNS заставить большое количество DNS-серверов в сетях (во многих сетях есть большое количество DNS-серверов, которые не защищены от использования их в таких атаках) принимать запрос, не особо проверяя, от кого он, и выполнять его. Например, они отгружают доменную зону размером в десятки килобайт на некоторый адрес, который непонятно кому принадлежит, и непонятно, этот ли адрес присылал этот запрос. Таким образом, начальный поток трафика проходит через тысячи DNS-серверов, которыми хакер непосредственно не управляет эти сервера просто находятся в интернете и готовы обработать query, не проверяя, от кого он приходит. За счет такой схемы сотня мегабит трафика, которую злоумышленник сгенерировал с помощью относительно небольшого ботнета (это может быть всего несколько десятков машин) превращается в десятки гигабит в секунду полосы, которая летит с этих name-серверов в сторону жертвы.

Что с таким случаем делать? Забанить источники, от которых пришел трафик так можно забанить половину интернета, потому что они прямого отношения к хакеру и ботнету даже не имеют. Здесь нужны другие механизмы борьбы с этим трафиком как минимум, его нужно куда-то слить, чтобы он не попал на машину, которая находится под ударом, и при этом не запоминать адреса источников и не пытаться применять к ним какие-то санкции.
Получается, что часть атак по-прежнему приходит напрямую с ботнетов с использованием валидных сессий и валидных IP-адресов, а часть в основном, те, которые применяют метод амплификации приходит совсем не с самих ботнетов. Ботнеты там используются только как свеча зажигания в моторе. Так было не всегда; амплификация это сравнительно новая история. Если посмотреть на крупные кейсы, то мы живем с атаками такого типа только последние 10 лет, возможно меньше. Другое дело, что именно сделало их настолько популярными, что именно сделало их опасность такой же большой, как и у традиционных методов здесь интересно будет рассмотреть, наверно, самый известный публике случай, который произошел в 2016 году. Тогда мир узнал о том, что ботнеты это не только зараженные вирусами компьютеры, а еще и IPTV-камеры, кофеварки, микроволновки, умные дома, ворота с Wi-fi и прочее. В какой-то момент развитие, популярность и распространенность интернета вещей разнообразных устройств с доступом в интернет достигло критической точки, на которой злоумышленникам стало интересно использовать именно их вместо более сложных в эксплуатации ПК, корпоративных серверов, публичных серверов и так далее, для генерации трафика.

Знаменитый ботнет Mirai базировался на десятках тысяч IPTV-камер конкретных производителей, на которых стояла одна и та же прошивка, никакой защиты от внешнего управления не предусматривалось, а выход в интернет не всегда был завязан на локальную сеть. Хотя бы админка может быть доступна через интернет, и этого уже достаточно для того, чтобы использовать маленькую железяку для генерации трафика. И, хотя одна камера много нагенерировать не сможет у нее канал маленький таких устройств десятки и сотни тысяч, и они максимально размазаны по миру. Опасность такой атаки, с точки зрения традиционных методов защиты, очень велика. Этим воспользовались авторы Mirai и те, кто последовал за ними, скопипастив этот подход и развернув свои ботнеты. 2016-17 годы стали настоящим всплеском с точки зрения атак с амплификацией, которые использовали в качестве корневого источника трафика подобного рода ботнеты. Эта история продолжается и сейчас: коробки продолжают выходить новые, и их защищенность от взлома и эксплуатации осталась на таком же уровне, потому что на первом месте стоит дешевизна и массовость производства. Другое дело, что мир уже научился чуть лучше защищаться от них, как и в случае с атаками SYN Flood. Гонять такого рода потоки трафика с IPTV-довольно затруднительно, security-люди уже слишком привыкли к такой истории.

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

Так или иначе, эта история никак не завершилась. Другое дело, что остальные методы атак подтянулись по своей опасности и интенсивности к тому, что продемонстрировал Mirai в 2016 году. Тогдашние атаки были примерно на 600-700 гигабит в секунду полосы, на тот момент невиданные цифры. Это почти в 10 раз превосходило виденные в дикой природе доселе атаки. Сейчас такими цифрами никого не удивишь: с момента возникновения Mirai рост полосы атак давно перевалил за терабит в секунду и продолжает расти. Широкополосные соединения и надежные магистральные сети провайдеров этому способствуют.

Что касается того, что из этой активности видели у себя мы. Несмотря на то, что Mirai это была в основном западная история, кусочек долетел и до наших клиентов в России. Это случилось на следующий год после его возникновения: к нам прилетела самая крупная на тот момент для РФ атака, которая составляла порядка 500 гигабит в секунду. Конечно, полтерабита уже было довольно популярной цифрой в мировой DDoS-ологии, но для сайтов Рунета, чьи инфраструктуры было расположены в России и подключены к нашим провайдерам, это было что-то с чем-то. К счастью, мы довольно быстро и эффективно пришибли атаку, и последующие встречи с подобного рода ботнетами уже не были сюрпризами ни для нас, ни для наших заказчиков.

DDoS-атаки в даркнете


image

У меня в повестке дня есть интересный вопрос: рассказать о том, что происходит в DDoS-атаками в даркнете. То есть, организация, проведение, методы, способы защиты. Тематика DDoS-атак в даркнете для нас, как для компании, никогда особого интереса не представляла: по понятным причинам, клиенты из даркнета к нам защищаться не приходят. Специфика занятий, на которых они зарабатывают деньги, и их собственная база пользователей, приходящих к ним на ресурсы, не располагает к тому, чтобы в такого рода отношения с сервисами защиты входить. Конечно, в мире есть исключения. Понятно, что где спрос там и предложение, и конкуренция в даркнете имеет примерно те же виды и обличия, что и в публичной сети. Поэтому DDoS-атака как способ выключить конкурента или заставить кого-то заплатить выкуп за то, чтобы его перестали DDoS-ить, постепенно, уйдя из заголовков новостных статей в публичном интернете, продолжает цвести пышным цветом в Tor-сетях и в даркнете в целом.

Понятно, что структура Tor несколько отличается от того, что мы имеем в публичной сети. Связь даркнета с публичным интернетом, которая осуществляется через экзит-ноды (гард-ноды) сама по себе является узким местом и не располагает к тому, чтобы большое количество трафика организовано лилось из даркнета в паблик (и наоборот). Тем не менее, в стародавние времена (2012-14 годы) такая штука, как сокрытие C&C-центра ботнета, существующего в публичной сети, внутри Tor-сетей, имела место быть. То есть, хакер держит свой C&C-компьютер в даркнете, через Tor отсылает управляющий трафик на ботнет, находящийся в публичной сети, и уже в публичной сети происходит атака на сайт. Для злоумышленника профит в том, что, если C&C в публичной сети можно отловить есть конкретные методы, которыми владеют ИБ-шники и форензики, по поиску управляющих центров, их перехвату и поиску владельцев то в даркнете это сделать гораздо труднее. Но эта лавочка просуществовала недолго, по ряду причин. Во-первых, сама работа C&C, рассылающего управляющий трафик по десяткам, сотням или сотням тысяч машин для начала атаки даже такая нагрузка, небольшая с точки зрения публичной сети (control point traffic), для Tor очень заметна и существенна. В 2013 году, когда один из крупных ботнетов поселил свой C&C-центр на onion-ресурс, трафик, который он генерировал, оказался достаточно заметным, чтобы замедлить работу целого сегмента Tor-сети. Не всем это понравилось, конечно. А самое главное, что в случае, когда атака уже случилась или была предотвращена, и расследованием атаки занимаются правоохранительные органы, инфосек-компании, эксперты-форензики, то, если ботнет был скомпрометирован, ниточки ведут в экзит-ноды тора. И по шапке получает, как и всегда в этом случае, владелец экзит-нода. Сам хакер не подвергается непосредственной угрозе, но закрытие экзит-нода и привлечение владельца к ответственности (хотя владелец и не имеет отношения конкретно к этим атакам) приводит к невозможности использовать инфраструктуру Tor в дальнейшем, в том числе и для других подобных действий. Поэтому, чтобы не пилить сук, на котором сидят сами организаторы атак, эту активность они преуменьшили, и сейчас она уже не столь заметна.

Что касается поиска контрольных центров ботнета и их владельцев это не совсем наша история. Мы занимаемся конкретно защитой от атак, а не расследованиями и поиском организаторов, хотя информация, которая у нас есть, помогает инфосек-компаниям заниматься своим делом конкретно, поиском. Один такой кейс прошел в большой степени на моих глазах, поэтому я с удовольствием им поделюсь. В 2014 году на одного из наших клиентов крупный банк с большим онлайн-присутствием произошла серия DDoS-атак, достаточно интенсивных. Мы сумели их отфильтровать и защитить клиента. Клиент не остановился на этом и обратился к инфосек-специалистам для поиска источников атаки и ее организаторов. У них были соображения о том, что ряд атак, происходивших на их ресурс, используя примерно одинаковый технический стек, вполне могли происходить из одного и того же места и быть одной и той же природы то есть, скорее всего, заказчик и организатор были те же самые. Что сделали люди из инфобеза: они достаточно быстро нашли сам ботнет, с которого генерировался трафик это было самое простое. А потом они подселили свой собственный honeypot такую же машину в этот ботнет, чтобы поймать момент, когда придет управляющая команда на атаку какого-нибудь ресурса. При очередном кейсе атаки они не только обнаружили машину, управлявшую началом и процессом атаки, но и выяснили, что с той же самой машины были обращения на атакуемый ресурс. То есть, злоумышленник-организатор атаки параллельно с кручением ручек для отправки мусорного трафика сам заходил на ресурс почекать, как он там, живой еще или свалился. По этим двум признакам его и нашли, сопоставили, нашли владельца машины. Дальше история уже переросла в уголовное дело; конец был довольно прозаический, и к технической сфере отношения не имеет. Тем не менее, понятно, что с даркнетом похожая история прокатывает труднее. Выход будет, естественно, на владельца экзит-нода, а что с ними бывает в России я уже говорил.
Это что касается атак из Tor-сетей наружу, теперь по поводу происходящего внутри самого даркнета. Там DDoS цветут пышным цветом, всех сортов и мастей. Что интересно например, в нашей статистике за последнюю пару лет можно увидеть, что атаки на 7 уровне то есть, на уровне приложений, те, которые используют HTTP, HTTPS-запросы, выбирают конкретные URL
Q: Посадить удалось? Если нет, то все равно безнаказанно будут нападать
Да, доказать и привлечь к уголовной ответственности злоумышленника удалось. Правда, это случилось не в Российской Федерации, а в соседней стране.

так вот, атаки на уровне приложения сейчас составляют в статистике лишь малую часть. Большая часть атак, которые мы видим регулярно это TCP, UDP, пакетные флуды, амплификации. То есть, более примитивные методы, которые дешевле стоят в организации, для которых есть куда больше тулзов, чтобы их быстро развернуть и начать. Для них не нужно большой подготовки перед атакой на какой-то сайт достаточно развернуть эту пушку в общем направлении жертвы и долбануть из нее. Прикладные атаки это всегда некоторый предварительный ресерч, выяснение того, как работает приложение, которое будут атаковать, как работает инфраструктура, куда эффективнее всего долбить в какие URI, в какие компоненты приложения. Эта работа стоит денег организатору, и по затратам такие методы атак выходят гораздо выше, чем дженерик-средства. А дженерик-средства популярны и дешевы в том числе и потому, что со времен Mirai, с 15-16 года, отрасль организации DDoS-атак и вообще активности на этой почве стала сервисной.

image

То есть, такое понятие, как устроить DDoS на заказ написать какому-нибудь хакеру, сказать ему, чтобы он положил некоторый сайт в определённое время этого уже практически нет. Потому что владельцы ботнетов и владельцы тулзов для организации ботнетов нашли более прибыльный способ зарабатывать на своем ремесле. DDoS as a service работает примерно так же, как и любой легальный сервис по подписке защита, CDN, ускорение сайтов. Ботнет предоставляется клиенту в shared-виде: то есть, некоторая часть мощностей предоставляется заказчику в пользование на определенное время за определенный прайс. Допустим, 5 минут атаки с существенной полосой будут стоить 10 долларов. Понятно, что маржинальность для владельцев все равно высокая: это гораздо выгоднее, чем one-time заказы от сомнительных личностей, которые и сдать властям могут. Сервисная работа куда более опосредована и не контактирует с заказчиком напрямую, при этом задействованность такого ботнета в атаках получается гораздо выше. То есть, зараженные устройства используются для генерации мусорного трафика гораздо более эффективно. Такие сервисы их еще называют бутеры растут как грибы; их искореняют, их сносят, находят организаторов, но они тут же вырастают снова. Самый знаменитый пример бутеров это сервис под названием vDOS, который держал под контролем часть ботнета Mirai, предоставляя его в shared-формате всем желающим. У них даже был сайт в публичной сети, довольно посещаемый, а оплату они принимали вообще через PayPal. Собственно, именно через PayPal эксперты-форензики и нашли организаторов; ими оказались двое израильских студентов, которые предпочли такой способ зарабатывания денег учебе и карьерным перспективам. Их привлекли к ответственности, но, по последним новостям все ограничилось общественными работами; возможно, мы еще увидим их либо в новой ипостаси бизнеса, либо уже на службе у какой-нибудь спецслужбы государства.

Так или иначе, такая модель то есть, вместо того, чтобы заниматься разработкой метода DDoS-атаки под конкретную жертву, делать сервис, на который можно прийти, заплатить криптовалютой и арендовать ботнет для атак на 5 минут (или на 10, или на час) и приводит к тому, что большая часть атак получается очень дженерик. Они не специфичны ни по конкретной цели, ни по протоколу, ни по особенностям генерации трафика. Они длятся недолго, так как в задачу DDoS-атаки в первую очередь входит запугивание жертвы. Если это не какая-то политическая история, то неважно, будет ли сайт жертвы лежать 5 минут или час. Если жертва согласится заплатить выкуп или иным способом пойти навстречу злоумышленникам, то тут и одной минуты достаточно, а раз так, то зачем переплачивать. Те атаки, которые выделяются из этого ландшафта, бывают гораздо интереснее, и на них как раз и нужно учиться и мы этим занимаемся.

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

Касательно даркнета есть еще одна интересная история. Техстек, который там используется, проходит те же стадии эволюции, которые публичный интернет проходил десятки лет назад. Уязвимость конкретных веб-серверов, уязвимость устройств, которые используются для размещения ресурса в даркнете, к самым примитивным методам DDoS-атак, никуда не делась. Она потихоньку устраняется, но, так как этим не занимаются специализированные компании, это происходит спонтанно и медленно. Методов завалить ресурс, размещенный в даркнете, великое множество их был миллион, и сейчас осталось прилично. Если зайти на GitHub и поискать тулзы, с помощью которых можно вывести из строя ресурс, размещенный в даркнете, то можно найти совершенно курьезные способы. Такие примитивные вещи, как медленная атака GET-запросами, с которой справился бы любой, даже бесплатный, сервис по защите от DDoS и ботов (а если бесплатный не справляется, то можно заплатить 20 долларов CloudFlare и решить этот вопрос, или самому настроить балансировщик) были все так же эффективны против onion-сайтов пару лет назад. Подобные методы публично доступны и не требуют больших ресурсов, то есть, большого ботнета, для организации атаки. Довольно частая история на Tor-ресурсы приходят не DDoS, а нераспределенные DoS-атаки. Достаточно определенной последовательности запросов с одной конкретной машины, чтобы погасить Tor-сервер.

image

Такая ситуация сохранялась; например, фикс Tor-браузера 0.4.2 закрыл дырку, которая позволяла запросами из этого браузера завалить любой ресурс в даркнете, затратив 0 рублей на атаку.

Защита в даркнете


Что касается защиты в даркнете это тоже забавная история. В конце концов, adhoc-security-сообщество, которое там существует, пришло к выводу, что защищаться таки надо. Появилась такая штука, как EndGame: это тулкит для защиты от DDoS на своей конкретной машине, которая публикует ресурс в Tor.

image
Используются такие компоненты, как Nexi бесплатный фаервол для NGINX, а также конфиг самого NGINX и настройки сетевого фаервола. С точки зрения тех историй, которые происходят в публичной сети, EndGame это курам на смех; это то, что студент в рамках курса по internet security учится делать в первую очередь. Настройка фаервола на своей машине, если там крутится NGINX настройка его параметров, чтобы нельзя было завалить его медленной атакой, защита от небольшого SYN Flood. Никакого rocket science. Все это достаточно простые с технической и организационной точки зрения действия. Тот факт, что такая защита стала популярной историей в даркнете, говорит о том, что эволюционировать там еще есть очень далеко куда. Возможно, именно инфраструктурная разделенность таких сетей приводит к тому, что более крутые решения, которые есть по эту сторону, там не приживаются.

Есть еще один аспект, не совсем технический, который может являться важным здесь. Защита от DDoS для бизнеса может осуществляться по-разному. Это может быть коробка, которая фильтрует трафик. Это может быть огромная сеть из коробок, фильтрующая за пределами инфраструктуры. Это может быть батарея коробок, стоящая у интернет-провайдера, которая занимается тем же самым поиском аномалий в трафике и блокировкой плохих источников. Все эти вещи не нужны ситуативно: за них нужно хвататься не тогда, когда атака уже идет. Тогда уже поздно. Эти вещи должны быть всегда наготове; фактически, вам продают гарантию того, что, если атака случится, эти вещи справятся с ней, и на вас, на ваших пользователей, на доступность вашего ресурса это не повлияет негативным образом. Эти гарантии не очень применимы в даркнете, где нет конкретных identity того, кто предоставляет этот ресурс, и того, кто его приобретает и использует. Поэтому adhoc-защита на своей собственной машине, которая поможет от самых примитивных методов, но при распределенной атаке, генерирующей большую полосу, ничего не сможет сделать, там используется и там имеет право на жизнь. Такая история.

Забавные случаи из практики



image

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

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

Простой пример это когда пользователь с абсолютно, в целом, легальной линией поведения, работает как планировщик задач, посещая новостные страницы на ресурсе в строго определенное время. Начинает в .00 минут утра, заканчивает в .00 минут вечера. При этом действия, которые пользователь совершает, не причиняют никакого вреда: это не парсинг и не скрепинг, он просто ходит по статьям, пишет комменты и отвечает на них.
Придраться не к чему кроме того, что он каждый день стартует и заканчивает в одно и то же время, и объем работы, которую он проделывает на ресурсе, получается несоизмеримо больше, чем у всех пользователей, которые не были определены как боты. У нас были разные гипотезы на этот счет; пару раз мы его случайно банили, после чего он писал в abuse ресурса по поводу того, что, собственно, происходит. В конце концов, мы махнули рукой мало ли, может быть, это контент-райтер, который явно работает в две смены без выходных и перерывов. В любом случае, пока такие юзеры время не приносят, принимать какие-то санкции к ним мы не считаем нужным.

Другой случай с обратной стороны, это когда ресурс ведет себя странно по отношению ко всем пользователям. У нас был заказчик, одна из функциональностей ресурса которого заключалась в том, чтобы предоставлять пользователям сгенерированные отчеты в виде DOC-файлов. Каждый такой отчет весил порядка 200 Мб, с картинками и таблицами. Забавным было то, что генерация отчета на сервере начиналась по нажатию кнопки на веб-странице. После этого сервер уходил в себя думать, генерил отчет и по готовности отсылал его одним куском, не нарезая на chunks, через HTTP file transfer, в рамках ответа на запрос. Шутка заключалась в том, что этот файл генерировался на сервере десятки минут. В какой-то момент наша служба поддержки получила от клиента заявку с просьбой увеличить время таймаута на обработку запроса на наш reverse proxy до 20 минут. Сначала люди не поверили своим глазам и пошли разбираться: как так, 20 минут на таймаут на запрос? Зашли на сайт, проверили, получилось именно так: с момента нажатия кнопки соединение продолжается 20 минут, после чего сервер наконец выгружает файл, и его можно получить. Экспериментальным путем скорее, даже трезвым оценочным взглядом стало понятно, что десяток пользователей, одновременно попавших на сайт, могут случайно устроить DDoS и полностью вывести сервер из обращения без какого-либо злого умысла, труда и затрат. И это не хабраэффект, когда десятки тысяч людей ломятся на инфоресурс одновременно, а сервер не может обработать их всех из-за нехватки производительности; здесь просто интересная история с ответами на запросы приводит к тому, что сервер не может так работать. Мы со своей стороны, конечно, порекомендовали делить файл на chunks, отправлять его кусочками, формировать отчеты в фоне и прочее.

В интернете есть ресурсы, которые работают по похожему принципу то есть, они by design уязвимы к атакам любой интенсивности и сложности организации. Вообще ничего не нужно, чтобы вывести такой сайт из строя. Есть API, работающие таким же примерно образом (тяжеловесные ответы, дорогие в обработке запросы к API, синхронная работа API). Сам факт этого приводит к тому, что DDoS-атаки случаются в разных местах даже без участия злоумышленников, хакеров, без всякой задней мысли. Когда мы сталкиваемся с такими ситуациями, мы стараемся консультировать заказчика насчет того, где у него странность в приложении и как ее можно исправить. И, конечно, пополняем свой паноптикум забавных архитектурных решений, которые мы ни в коем случае никому бы не рекомендовали имплементировать.

Буду рад ответить на любые вопросы их можно будет оставить в статье на Хабре или написать мне по контактным данным.

Ссылки для чтения:


Предыдущую расшифровку нашего эфира можно посмотреть тут, ещё больше наших спикеров по хэштегу #ruvds_расшифровка


Подробнее..

Отчет о сетевой безопасности и доступности в 2020 году

22.03.2021 16:16:43 | Автор: admin

Краткое содержание

  • К 2021 году сеть фильтрации Qrator Labs расширилась до 14 центров очистки трафика общей пропускной способностью в 3 Тбит/с с точкой присутствия в Сан-Паулу, Бразилия, вводящейся в эксплуатацию в начале 2021 г.

  • Новые сервисы, предоставляемые партнерами компании (SolidWall WAF и RuGeeks CDN) за 2020 год были полностью интегрированы в инфраструктуру Qrator Labs и личный кабинет.

  • Улучшенная логика фильтрации позволяет Qrator Labs удовлетворить потребности даже самых крупных заказчиков с глобально распределенной инфраструктурой, обеспечивая полное покрытие услуг кибербезопасности и нейтрализации DDoS-атак.

  • Qrator Labs активно использует новейшие процессоры AMD для задач, связанных с обработкой трафика.

За 2020 год количество DDoS-атак лишь увеличилось, самые опасные можно описать просто: короткие и обескураживающе интенсивные.

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

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

Вторая декада Qrator Labs

С началом 2021 года Qrator Labs отметила собственное десятилетие. Некоторым коллегам, работающим в компании с самого начала, было сложно поверить, что прошло уже столько времени.

Немного о том, чего компания достигла за эти 10 лет:

  • От 1 до 14 центров очистки трафика на 4 континентах, островах Сингапура и Японии, а также Аравийском полуострове;

  • В начале 2021 года сеть фильтрации Qrator приближается к 3 Tbps кумулятивной емкости, используемой для нейтрализации DDoS-атак;

  • С 7 до 70 сотрудников в одиннадцати городах;

  • Тысячи спасённых клиентов. Буквально.

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

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

2021 год начался взрывным образом с DDoS-атаки интенсивностью 750 Гбит/с, состоящей в основном из DNS-амплифицированного трафика. Этот вектор атак является одним из старейших и наиболее изученных, что не мешает ему сеять хаос с огромной эффективностью.

Улучшения логики фильтрации

В течение последних двух лет в Qrator Labs приложили множество усилий для обновления логики фильтрация трафика, лежащей в основе услуги нейтрализации DDoS-атак. В итоге, в зависимости от параметров конкретного трафика и задач, нам удалось повысить общую эффективность в 4-8 раз, при этом используя на 25-33% меньше оперативной памяти. Это означает, что теперь мы можем принимать на борт еще больше легитимного трафика, а также работать с крупнейшими потенциальными клиентами в мире.

Мы значительно обновили детектор атак алгоритм, призванный подтвердить наличие атаки. Теперь у нас есть более широкий набор параметров, доступных пользователю для выбора, каждый из которых может служить источником для наполнения черного списка. Это позволяет нам нейтрализовать атаки ближе к уровню L7 модели OSI, по сравнению с L3-L4.

Ещё одно нововведение это брокер запросов. Он позволяет упростить процесс адаптации WAF потенциальным пользователем. Мы улучшили процессы взаимодействия с различными Web Application Firewall продуктами в сети фильтрации Qrator, реализовав асинхронную схему принятия решений по сомнительным, а значит потенциально вредоносным запросам.

В 2020 году в сети фильтрации Qrator также была реализована поддержка Proxy Protocol. Этот протокол облегчает подключение и дальнейшую нейтрализацию DDoS-атак для приложений, использующих, например, WebSockets. Помимо упрощения подключения прокси-сервера к сети Qrator, такого как HAproxy или NGINX, Proxy Protocol упрощает настройку любого решения, работающего поверх TCP, позволяя легко установить под защиту сети фильтрации Qrator любой ресурс, поддерживающий его.

AMD внутри Qrator Labs

По нашему мнению, новые процессоры AMD отлично подошли к аппаратной архитектуре сети Qrator. Уникальная характеристика ЦПУ AMD иерархическое разделение ядер на кристалле вполне эффективна для задач, решаемых в Qrator Labs. Блоки ядер с раздельными контроллерами памяти представляют собой отдельную задачу с точки зрения корректной настройки, потому что мы меняем то, каким образом операционная система видит ядра центрального процессора. Огромное преимущество новых процессоров AMD заключается в том, что теперь мы в Qrator Labs можем построить однопроцессорную серверную машину с мощностью большей, чем у старой двухпроцессорной установки. С одной сетевой картой внутри каждой машины, подключенной с помощью PCIe, два процессора вносят большую сложность в задачу изначального разделения нагрузки, в дополнение к задержке переключения между ними. Замена двух ЦПУ одним решает эту задачу, оставляя необходимость настраивать только ядерную (иерархическую) архитектуру в одном процессоре, что значительно легче.

У процессора AMD обнаружилась еще одна интересная особенность. Используемая нами модель поддерживает работу с памятью на частоте 3200 ГГц. Когда мы начали тестировать упомянутый ЦПУ, то обнаружили, что, хотя формально контроллер памяти и допускает рабочие нагрузки на частоте 3200 ГГц, но внутрипроцессорная шина, соединяющая ядра, работает на частоте ниже. Фактически это означает, что если мы используем тактовую частоту процессора 3200 ГГц, пропускная способность снижается из-за низшей частоты контроллера памяти. Приложение, которое выиграет от этой особенности, должно быть исключительно однопоточным и работать только с одним каналом памяти.

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

Интеграция партнерских технологий

В течение прошедшего года мы интегрировали новые партнерские технологии в структуру сети фильтрации Qrator.

Новый WAF от SolidWall теперь представлен в составе услуг Qrator Labs. SolidWall WAF интегрирован в панель управления Qrator, что позволяет клиентам полностью управлять всеми настройками межсетевого экрана в одном месте, вместе с другими услугами Qrator Labs.

Другая новинка это CDN-сервис от RuGeeks, стал доступен всем клиентам Qrator Labs после периода интеграции и обширного тестирования.

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

Фильтрация IPv6-трафика

По данным компании Google, к концу 2020 года глобальное внедрение IPv6 превысило 30%. Сейчас протокол находится на решающим этапе и будет либо всеобще принят, либо так и останется лишь частичной заменой IPv4. Мы считаем, что за IPv6 будущее сетей, поэтому в течение последних нескольких лет наша команда инвестировала время и усилия в полную поддержку 6-й версии протокола IP в сети Qrator.

Одна из важных задач сетевой инженерии, решаемая в Qrator Labs это поиск тяжелых элементов в потоке. На самом деле подразумеваются наиболее интенсивные подпотоки, но в академической англоязычной литературе термин heavy hitters уже устоялся, потому и в русском языке мы говорим о задаче поиска "тяжелых" элементов. Для начала стоит объяснить, почему мы решаем конкретно эту задачу: наша основная цель как компании, предоставляющей нейтрализацию DDoS-атак, доставлять легитимный и очищенный трафик его владельцу, одновременно отсекая вредоносный и нелегитимный трафик.

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

С IPv6 ситуация совершенно иная.

"Сохранение в памяти полного пула IPv6-адресов потребовало бы огромного ее объема. Если на хранение каждого IPv6-адреса выделять по одному биту памяти, то потребуется примерно 2^128 бит для всего пула IPv6-адресов. Это больше, чем количество атомов на Земле.

Если же на хранение целого префикса /64 брать по одному биту памяти, то для всего адресного пространства IPv6 уже потребовалось бы всего лишь 2^64 бит памяти. Это число не настолько астрономическое по сравнению с предыдущим, и его можно сравнить со всей произведенной до настоящего момента оперативной памятью всех устройств в мире."

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

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

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

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

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

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

Qrator Labs разработала полномасштабный симулятор для тестирования среды в IPv6. Он генерирует потоки трафика, позволяя применять различные комбинации алгоритмов фильтрации и измерения результатов и качества их работы. Со временем, когда симулятор будет готов с нашей точки зрения, мы планируем сделать его код общедоступным.

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

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

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

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

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

Статистика и дальнейший анализ данных по DDoS-атакам

Медианная продолжительность DDoS-атаки составляет около 5 минут, что не сильно изменилось с тех пор, как мы изменили методологию подсчета и разделения атак. DDoS-атака с DNS-амплификацией, которую мы нейтрализовали в феврале 2021 года, длилась 4 минуты.

Распределение векторов DDoS-атак демонстрирует преобладание атак на основе UDP-флуда в 2020 году, составляя 40,1% от всех наблюдавшихся атак. На втором месте стоит IP-флуд с 38,15%, а SYN-флуд замыкает тройку наиболее популярных векторов по L3-атакам с 16,23% за 2020 год.

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

Сравнение пакетной интенсивности векторов атак демонстрирует, что DDoS-атаки на основе UDP-флуда могут начинаться с самых низких уровней возможной скорости передачи пакетов, а TCP-флуд обладает противоположной характеристикой. Их медианные уровни pps составляют 113,5 тысяч и 1,2 млн соответственно.

А вот иллюстрация комбинаций векторов атаки:

Как видите, в реальном мире DDoS-атак основные векторы смешиваются мало и, по большей части, остаются "чистыми"от комбинаций. Так UDP-флуд и IP-флуд преобладают среди всех DDoS-атак 2020 года.

Погружение в BGP

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

Иначе обстоит ситуация с перехватами трафика и утечками маршрутов. В отчете, который мыпубликовали в мае 2020 по первому кварталу прошлого года, мы указали на статистику утечек маршрутов BGP:

Январь 2020: 1
Февраль 2020: 4
Марта 2020: 6
Апрель 2020: 6 +1 в IPv6

Теперь мы можем взглянуть на цифры за 4 квартал 2020 года с дополнительными данными по январю 2021 по тем же утечкам маршрутов:

Обратите внимание, что мы учитываем в данной статистике только такие инциденты, которые команда Qrator.Radar считает глобальными то есть превышающими определенные пороговые значения. Сравнивая данные 4-го квартала с 1-м кварталом 2020 года, создается впечатление, что наблюдается некоторое снижение абсолютного числа инцидентов, связанных с утечкой маршрутов. Что будет справедливо только при условии, что мы примем как факт то, что все инциденты имеют одинаковый размер. На практике же это совершенно противоположно как и всегда, более крупные сети способны быстрее и сильнее влиять на клиентов и соседей. Фактически же это означает, что шансов на изменение ситуации с утечками маршрутов не так много, пока у нас не будет рабочего решения для полного их предотвращения. Мы надеемся, чтоASPAивсе связанныес данным нововведением черновики, рассматриваемые внутри IETF, будут приняты и получат RFC статус в ближайшем будущем.

PDF-версия отчетадоступна для скачивания по ссылке.

Подробнее..

Десять (с плюсом) лет в лабе

14.01.2021 10:07:09 | Автор: admin

В начале 2021 года Qrator Labs отмечает собственный десятилетний юбилей. 19 января наша компания пройдет через формальную отметку 10 лет деятельности, войдя во второе десятилетие существования.

Хотя, на самом деле, все началось несколько ранее - когда в возрасте десяти лет Александр первый раз увидел Robotron K 1820 - в 2008 году, когда Александр Лямин - основатель и директор Qrator Labs, пришел с идеей к начальникам в МГУ, где на тот момент времени он работал сетевым инженером, о создании исследовательского проекта по нейтрализации DDoS-атак. Сеть МГУ тогда была одной из крупнейших в стране и, как мы знаем сейчас, это было лучшее место для того, чтобы посеять зерно будущей технологии.

Тогда администрация МГУ согласилась, и Александр перенёс собственное оборудование в университет, одновременно с этим собирая команду. Через два года, летом 2010, стало ясно, что проект успешен. Он принял на себя DDoS-атаку, превышающую емкость вышестоящего поставщика МГУ. И 22 июня боссы выдвинули ультиматум г-ну Лямину - закрываться или уходить.

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

В сентябре 2010 года первая площадка была введена в эксплуатацию.

Помимо множества других вещей внутри компании мы обожаем старые и хорошо сохранившиеся устройстваПомимо множества других вещей внутри компании мы обожаем старые и хорошо сохранившиеся устройства

Конечно, дело не только во fl8xе - по никнейму, используемому Александром Ляминым. Компания выросла из начальной команды из 7 человек в 2010 до почти 70 сотрудников к началу 2021 года.

Перечислять все, что происходит на текущий момент в Qrator Labs, мы не будем - это бы заняло невозможное к прочтению количество текста. Упомянем, однако, что мы по-прежнему остаемся технически ориентированной компанией с жесткой специализацией по построению отказоустойчивой BGP-anycast сети как можно ближе к ядру интернета и предоставлению одного из лучших в мире сервисов по нейтрализации DDoS-атак. Хотя за эти десять лет все увеличилось в размере и разнообразии - инфраструктура под защитой, количество развиваемых и поддерживаемых сервисов, равно как и сложность коммуникации.

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

Несколько фактов:

  • От 1 до 14 центров очистки трафика на 4 континентах, островах Сингапура и Японии, а также Арабском Полуострове;

  • В начале 2021 года сеть фильтрации Qrator приближается к 3 Tbps кумулятивной емкости, используемой для нейтрализации DDoS-атак;

  • С 7 до 70 сотрудников в одиннадцати городах;

  • И, буквально, тысячи спасенных клиентов.

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

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

Что на самом деле изменилось, так это публичное восприятие ботов, которые трансформировались в шум интернета (который генерируется ботами) и живой сигнал (генерируемый потребителем/посетителем). Хотя для нас ситуация так и выглядела многие годы - из-за первоочередной задачи откладывать в сторону трафик атаки для защищаемых ресурсов. Так что, каким бы ни был очередной вызов - можете оставаться уверенными, что он будет принят Qrator Labs.

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

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

19 января 2021 года компания Qrator Labs официально отмечает десятилетний юбилей!

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

Каждое выступление рассчитано на 15-20 минут, так что каждый зритель может рассчитывать на два с лишним часа презентаций от представителей Qrator Labs.

Отмечайте 19 января 2021 года в своих календарях, потому что вот что будет происходить начиная с 14:00 Московского времени.

I/III - Первый Час

"10 лет развития бизнеса: с нуля к росту, от первых клиентов и спасенных карьер к захвату рынков новейшими технологиями" - Максим Белоенко, вице-президент глобальных продаж.

"Создание технологии опережающей конкурентов, нескончаемое научное исследование на стыке информатики и практики реального мира" - Артем Гавриченков, со-основатель и технический директор Qrator Labs.

5-минутный перерыв

II/III - Второй Час

"Интеграции в облако Qrator Labs - как мы работаем над улучшением сервисов, которые предоставляем под одной крышей - партнерскими решениями CDN и WAF" - Андрей Лескин, менеджер по продукту.

"Qrator Radar - более чем пятилетнее путешествие от внутренней разработки к одному из крупнейших в мире специализированных сервисов" - Евгений Богомазов, сетевой инженер.

5-минутный перерыв

III/III - Третий Час

"Пресейл и интеграция:

Технический пресейл - как мы принимаем на борт наиболее крупных клиентов;

Партнерская интеграция - сделай единожды и наслаждайся результатом;

Продуктовое видение - сделай дважды и у тебя на руках почти готовый продукт." - Георгий Тарасов, инженер.

"Жизнь NOC (центр управления сетью) в компании занимающейся кибербезопасностью" - Дмитрий Шемонаев, глава Центра Управления Сетью.

"Заключительное слово и итоги десятилетия компании. Работа с заказчиками в 20-х годах, грядущие инновации. Дальнейший рост компании 1 эшелона на базе исследовательской деятельности и взаимоотношений с потребителем, как с инвестором." - Сергей Пасечник, директор отдела продаж.

До встречи 19 января!

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru