Ежегодный отчет Qrator Labs о сетевой безопасности и доступности
Есть у нас в Qrator Labs такая традиция — в начале, а февраль это точно не конец, каждого года публиковать отчет о годе предыдущем.
Как и любая многолетняя сущность, она обрастает множеством сопутствующих историй. К примеру, уже стало «доброй» приметой, когда в начале января на наши корпоративные страницы заходит очередная DDoS-атака, которую мы не успеваем разобрать в отчете. 2020 год стал наполовину исключением — вектор атаки мы успели писать (TCP SYN-ACK-амплификация), но именно к нам, на qrator.net, гость пожаловал только 18 января, зато сразу с гостинцами: 116 Gbps при 26 Mpps.
Стоит признаться, что пересказывать события ушедшего года — жанр специфический. Поэтому мы решили в процессе рефлексии сосредоточиться и на том, что будет происходить — в первую очередь с нашей командой и продуктом — в текущем году, так что не удивляйтесь читая о наших планах по разработке.
Начнём мы с двух самых интересных нам тем прошлого года: SYN-ACK-амплификации и BGP-«оптимизации».
TCP SYN-ACK-амплификация и другие протоколы
Рост рынка IoT, помимо прочего, означает, что злоумышленники при желании могут эксплуатировать уязвимые устройства, создавая значительную пропускную полосу атаки — как это произошло в середине года, когда протокол WSDD был использован для нанесения видимого ущерба. Протокол Apple ARMS, задействовавшийся для получения коэффициента амплификации порядка 35,5, также был виден в атаках на сеть фильтрации Qrator Labs.
В течение 2019 года общественность узнала и о новых амплификаторах (PCAP), а также воочию увидела уже давно известный вектор атаки с задействованием TCP — SYN-ACK. Основное различие между данным методом и типичной UDP-амплификацией заключается в том, что вектор SYN-ACK не использует увеличенный по сравнению с запросом ответ — вместо этого он лишь пытается несколько раз ответить на TCP-запрос, таким образом, создавая заметный коэффициент амплификации. Так как публичные облака в Интернете отвечают на пакеты с подменой адреса источника, атаки, задействующие вектор амплификации SYN-ACK, стали одной из наиболее серьезных сетевых угроз. Апогей случился, когда крупный облачный хостинговый провайдер Servers.com обратился к Qrator Labs с просьбой о помощи в нейтрализации DDoS-атак, задействующих в том числе и вектор SYN-ACK.
Довольно интересным является и то, что наиболее часто использовавшийся в прошлом метод реакции в виде сброса всего UDP-трафика, виртуально нейтрализующего львиную долю атак с использованием амплификации, совсем не помогает нейтрализовать вектор SYN-ACK. Меньшие интернет-компании испытывают огромные трудности при нейтрализации подобных угроз, так как она требует задействования комплексных мер по борьбе с DDoS-атаками.
И хотя TCP SYN-ACK-амплификация не является новой, до сих пор она оставалась относительно неизвестным вектором атак. Злоумышленник посылает SYN-пакеты по всем публичным TCP-сервисам в интернете, подменяя адрес источника на адрес жертвы, а каждый из таких сервисов в свою очередь отвечает несколько раз в попытке установить соединение — обычно от 3 до 5. Очень долгое время данный вектор атаки считался бессмысленным, и лишь в июле 2019 года мы увидели, что атакующие оказались в состоянии генерировать достаточно атакующей пропускной полосы для того, чтобы потрясти даже очень крупные и распределенные сетевые инфраструктуры. Что особенно необычно, учитывая уже упомянутый факт отсутствия «амплификации ответа» как такового и задействование лишь заложенной в протокол возможности переподключения в случае неудачи. Для тех, кто интересуется другими протоколами с подобными «возможностями», можно указать на протокол QUIC, уже предоставляющий серверу опцию отвечать на запрос клиента увеличенным ответом (хотя черновик протокола и «рекомендует» не посылать ответ более чем в три раза превышающий размер запроса).
Амплификация перестала быть угрозой при коэффициентах около 100х — очевидно, что сегодня вполне достаточно 3–5х. Решение этой проблемы почти невозможно без устранения феномена «спуфленного» трафика как категории — у злоумышленника не должно быть возможности имитировать чей-то сетевой идентификатор и заливать его трафиком от источников легитимного контента. BCP38 (набор лучших и общепринятых практик по настройке сетей и решению проблематичных ситуаций) совсем не работает и создатели новых транспортных протоколов — таких как QUIC — плохо оценивают опасность, исходящую даже из совсем небольших возможностей по амплификации. Они на другой стороне.
Сетям нужен надежный способ сбрасывать или как минимум лимитировать спуфленный трафик — и данный инструмент должен иметь достаточно информации о легитимности источника запроса. Облачные сети, принадлежащие таким компаниям как Amazon, Akamai, Google и Azure, сегодня представляют собой почти идеальную цель для TCP амплификации — у них много мощного железа, способного удовлетворить практически все цели атакующего.
Устранять последствия таких атак в современном интернете сложно. Как уже упоминалось, современные фронтенды и бэкенды приложений и используемых для их создания библиотек взаимно интегрированы. Использование возможностей программных решений с открытым исходным кодом, находящихся внутри крупных облаков в собственном стеке разработки, может привести к тому, что в результате атаки с использованием SYN-ACK-амплификации из того же самого облака вы попадете в крупные неприятности. Неработающие репозитории и необновляющиеся файлы конфигурации в результате блокировки (из-за поддельного адреса источника запросов, вашего адреса) со стороны провайдера облачной услуги — ситуация, в которой никто не захочет оказаться. В течение 2019 года мы несколько раз сталкивались с такой ситуацией, имея дело с обращениями пострадавших компаний, обнаруживших невообразимые критические зависимости впервые за время своего существования и разработки.
Необходимо дальнейшее развитие протокола BGP с целью задействования его в борьбе со спуфингом в стеке протоколов TCP/IP. Таблицы маршрутизации кардинально отличаются от таблиц подсетей, и нам необходимо научить сеть быстро вычленять и отбрасывать нелегитимный пакет — другими словами, обеспечить аутентификацию на уровне сетевой инфраструктуры. Внимание должно обращаться не на «целевой адрес», но на «адрес источника», чтобы сопоставить его с информацией, содержащейся в таблице маршрутизации.
BGP-«оптимизаторы»
Инциденты, связанные с протоколом BGP, всегда продолжительны. По текущей шкале величин сетевых инцидентов, утечки маршрутов и перехваты анонсируемых подсетей, которые распространились достаточно далеко, несут основную опасность в степени распространении и времени, требуемом для устранения последствий. Возможно, это происходит по той причине, что развитие непосредственно сетевой составляющей шло значительно медленнее остального мира разработки нового железа и ПО. В течение долгого времени это было верно — пора отказаться от данного наследия. Необходимо вкладывать средства и время в сетевое программное и аппаратное обеспечение, а также в людей, настраивающих BGP-фильтры.
Инциденты 2019 года, связанные с BGP-оптимизаторами, показали, что та статистика относительно BGP, на которую все полагаются, содержит много проблем. Дело в том, что в полученном от однорангового узла BGP-анонсе можно изменить практически все содержимое до того, как оно будет снова анонсировано — протокол очень гибкий. Это именно то, что использует оптимизатор: большие или меньшие сетевые префиксы, одновременно с неработающими фильтрами и опцией local pref. Если кто-нибудь дезагрегирует префикс на два меньших, он, как правило, выиграет соревнование за право передавать трафик. Оптимизаторы берут корректный маршрут и анонсируют его меньшую часть — достаточно прямолинейно. И это работает, разнося на части большие составляющие Интернета.
BGP-оптимизаторы существуют, потому что большое количество компаний хочет контролировать исходящий поток трафика автоматически, не задумываясь о трафике как таковом. Принятие маршрутов, которых не должно существовать, — огромная ошибка, ведь таких маршрутов нет на точке, из которой они исходят.
Множество текстов было написано за 2019 год, в том числе и нашей компанией, о рисках «оптимизации BGP». В случае с Verizon, конечно, создавать новую политику фильтрации на каждого нового потребителя услуги неприятно. И также известно, что у Verizon нет фильтров, так как он принял сотни проблемных маршрутов от собственного клиента AS396531, являющегося «стабом» — автономной системой с единственным подключением. Более того, у телекоммуникационного гиганта также не был настроен лимит подсетей на данное соединение. Не было даже базовой проверки на присутствие других Tier-1 операторов в пути со стороны потребителя (такой тип проверки заводится по умолчанию и не требует поддержки или изменения).
В прессе данный инцидент, включающий Verizon и Cloudflare, обсуждался достаточно бурно. Помимо возможных действий со стороны Verizon, многие отмечали выгоды RPKI и строгую максимальную запись в ROA. Но что же с maxLength? Известно, что при строгой проверке максимальной длины записи все анонсы с указанием на меньшие подсети становятся некорректными при проверке ROA. Также известно, что существует политика сброса некорректных путей. Существует и черновик в рамках IETF, указывающий на то, что maxLength должна быть равна длине сетевого префикса.
Cloudflare следует лучшим практикам. Однако есть небольшая проблема. Verizon не поддерживает политику сброса некорректных маршрутов. Возможно, у него не было вообще никакой проверки по RPKI. В результате все маршруты с меньшими подсетями распространились еще дальше, хотя они и являлись некорректными с точки зрения Route Origin-валидации и стягивали на себя весь трафик. При этом, несмотря на некорректный (Invalid) статус, Cloudflare не могла сама проанонсировать такие же маршруты, так как ее поставщики сбросили бы их как некорректные.
Утечку маршрута можно устранить простой манипуляцией атрибутом AS_PATH в форме: ASx AS396531 ASx (где ASx это номер автономной системы источника) в процессе создания анонса — это поможет избежать утечки благодаря задействованию механизма обнаружения циклов, пока проблема решается другими способами. Хотя каждый раз при подобной манипуляции придется держать такие политики в памяти.
Чаще всего в реальной жизни задействуется стандартный метод — жалоба. Что выливается в дополнительные часы ожидания. Коммуникация может быть болезненной, и мы не можем винить в этом Cloudflare — они сделали все, что смогли, учитывая обстоятельства.
Что в итоге? Иногда нас спрашивают, насколько сложно использовать BGP для того, чтобы организовать что-нибудь плохое. Представим, что вы начинающий злодей. Необходимо подключиться к крупному оператору связи, у которого плохо с настройкой фильтров. Потом выберите любую цель и возьмите ее сетевые префиксы, проанонсировав их меньшие части. Также не забудьте сбросить все транзитные пакеты. Поздравляем! Вы только что создали черную дыру в Интернете для всего транзитного трафика данного сервиса через вашего провайдера. Жертва потеряет реальные деньги из-за такого отказа в обслуживании и, вполне возможно, понесет значительные репутационные потери. Не менее часа уходит на нахождение причин подобного инцидента, и от часа требуется на то, чтобы привести все в норму — при условии непреднамеренности такой ситуации и доброй воли к разрешению среди всех участников.
В марте 2019 года был еще один случай, который в свое время мы не связали с BGP-оптимизацией. Однако он также заслуживает внимания.
Представьте, что вы транзитный провайдер, анонсирующий подсети собственных клиентов. Если у таких клиентов несколько провайдеров, а не вы один — вы получите лишь часть их трафика. Но чем больше трафика — тем больше прибыль. Так что вы решаете проанонсировать меньшие подсети от данных сетей с тем же самым атрибутом AS_PATH, чтобы получить весь трафик таких сетей. С оставшимися деньгами, конечно же.
Поможет ли в этом случае ROA? Возможно, да, но только если вы решите не использовать maxLength вовсе и у вас нет ROA-записей с пересекающимися в них префиксами. Для некоторых операторов связи подобная опция является неосуществимой.
Если говорить о других механизмах обеспечения безопасности BGP, то в данном типе перехвата не помогла бы и ASPA — потому что AS_PATH принадлежит корректному пути. BGPSec на текущем этапе неэффективен по причине отсутствия поддержки и остающейся возможности проводить downgrade-атаки.
Остается мотив повышения прибыльности вследствие получения всего трафика автономных систем с несколькими провайдерами и отсутствия какого-либо средства защиты.
Суммарное количество статических циклов (static loops) в сети.
Что все-таки можно сделать? Очевидный и наиболее радикальный шаг — пересмотреть текущие политики маршрутизации. Это поможет вам разделить адресное пространство на наименьшие возможные части (без пересечений), которые вы хотели бы анонсировать. Подпишите ROA только для этих маршрутов, используя опцию maxLength. Текущая валидация ROV может спасти от такой атаки. Но повторим, некоторые не могут позволить себе использовать только наименьшие подсети.
С помощью Radar.Qrator можно отслеживать подобные события. Для этого нам нужна базовая информация о ваших префиксах. Вы можете установить BGP-сессию с коллектором и представить информацию о своей видимости Интернета. Мы также положительно оцениваем тех, кто готов отправить нам полную таблицу маршрутизации (full-view) — это помогает отслеживать степень распространения инцидентов, но для собственной выгоды и начала использования инструмента достаточно списка маршрутов только для ваших префиксов. Если у вас уже установлена сессия с Radar.Qrator — пожалуйста, проверьте, что вы отправляете маршруты. Для автоматического определения и оповещения об атаках на ваше адресное пространство эта информация необходима.
Повторим — в случае обнаружения подобной ситуации вы можете попытаться ей противодействовать. Первым подходом является самостоятельное анонсирование путей с префиксами меньших подсетей. При очередной атаке на данные префиксы — повторить. Второй подход — наказать атакующего, запретив автономной системе доступ к вашим путям. Как это описывалось ранее, это достигается добавлением номера автономной системы атакующего в AS_PATH ваших старых путей, заставляя срабатывать защиту от циклов.
Банки
В 2019 году мы провели исследование в России, которое показало, что финансовые учреждения зафиксировали повышение значимости информационной безопасности и стали отдавать таким инвестициям больший приоритет.
Банки-респонденты выделяют финансовый и репутационный ущерб как наиболее серьезные последствия нарушений информационной безопасности.
Большинство опрошенных финансовых учреждений считают гибридные решения наиболее эффективным средством противодействия распределенным атакам типа «отказ в обслуживании».
Динамика последних двух лет ярко свидетельствует о том, что сфера информационной безопасности растет колоссальными темпами: за последние 2 года большинство банков увеличили инвестиции в информационную безопасность. Кибербезопасность уже стала заметной на уровне руководства компании. Руководители бизнеса начинают уделять больше внимания процессам реализации политик безопасности, а должность директора по информационной безопасности приобрела новую роль. Руководители ИБ постепенно превращаются в ключевых советников для топ-менеджеров финансовых организаций, внедряя тактику ведения бизнеса и стратегии безопасности в соответствии с потребностями компании.
Электронная коммерция
Аналогичное исследование было проведено и в области e-commerce, где мы выяснили, что DDoS-атаки остаются заметной угрозой для российского ритейла, особенно для развивающего цифровые каналы услуг. Количество атак в этом сегменте продолжает расти.
В некоторых сегментах рынка, несмотря на его, в целом, стабилизацию и консолидацию, доверие к чистоплотности конкурентов всё еще находится на невысоком уровне. При этом крупные онлайн-магазины в массе своей доверяют своим потребителям и не считают личные мотивы клиентов серьезной причиной кибератак.
Как правило, о своей готовности к DDoS-атакам средний и крупный e-commerce-бизнес узнаёт исключительно на практике, проходя «проверку боем». Необходимость предварительной оценки рисков подготовки проекта осознают далеко не все, и еще меньше компаний реально проводят такую оценку. Основными причинами взломов респонденты считают нарушение работоспособности магазина, а также кражу пользовательской базы.
В целом, уровень зрелости ритейла в подходах к обеспечению кибербезопасности растет. Так, все респонденты используют те или иные средства DDoS-защиты и WAF.
В дальнейших исследованиях планируется включить в число респондентов репрезентативную выборку малого онлайн-бизнеса и детально исследовать этот сегмент рынка, его риски и текущий уровень защищенности.
DNS-over-HTTPS против DNS-over-TLS
Одной из наиболее горячих тем 2019 года были дебаты относительно того, за какой технологией будущее — DoH или DoT. Изначальное противоречие связано как со значительными различиями в различных легислативах (GDPR Евросоюза против федеральных и законов уровня штатов в США), так и конкуренцией на рынке главных браузеров: Google Chrome и Mozilla Firefox, а также Apple Safari. Мы не готовы утверждать, снизит ли внедрение любой из данных технологий количество амплификаторов в Интернете. Однако, с опцией DoT это представляется более возможным с архитектурной точки зрения из-за создания защищенных соединений между DNS-резолверами. Относительно других прогнозов — подождем решения, которое примет рынок.
Наиболее атакуемые в 2019 году индустрии.
Уязвимости TCP acknowledgment
В июне 2019 года появились первые подробности о наличии серьезных уязвимостей в некоторых реализациях стека протоколов TCP/IP, о которых сообщила компания Netflix. Предположительно, первоначально проблема была обнаружена в операционной системе FreeBSD, после чего наша компания получила подтверждение о наличии этой же и других уязвимостей в Linux.
Наиболее опасна CVE-2019–11477 (SACK Panic), которая может позволить злоумышленнику вызвать kernel panic с помощью последовательности специально сформированных пакетов. Три других уязвимости могут приводить к избыточному потреблению ресурсов, что может повлечь отказ в обслуживании.
Отключение SACK-функционала может привести к увеличению задержек, однако это обезопасит серверы от возможных атак на отказ в обслуживании — временное снижение производительности TCP/IP, по мнению Qrator Labs, является оправданным способом нейтрализации серьезной уязвимости. Патчи, закрывающие данные уязвимости, уже давно доступны и рекомендованы к установке.
Будущее BGP-маршрутизации
На конец 2019 года Radar.Qrator — крупнейшая платформа по сбору и аналитике глобальной маршрутизации BGP с более чем 650 установленных сессий.
Команда Radar.Qrator работает над повышением удобства использования и надежности сервиса, внося улучшения и в модель отношений BGP, являющейся основой платного сервиса мониторинга автономной системы в реальном времени.
В 2019 году большие усилия были вложены в ускорение процесса обработки данных и исполнение SLA, которым гарантируется качество потока аналитических данных. На сегодняшний день Radar является крупнейшей аналитической платформой и BGP-коллектором в мире, насчитывая более 600 установленных сессий, и мы надеемся использовать полученные данные в полной мере с целью оповещения потребителей платной части сервиса обо всех происходящих в BGP-маршрутизации событиях без задержек.
Radar.Qrator растет быстрее, чем ожидалось — и по количеству посетителей сайта, и одновременно по числу подписчиков. В 2020 году, благодаря обратной связи от клиентов, будет представлено сразу несколько значительных улучшений, одной из таких вещей станет новое хранилище инцидентов по каждой автономной системе.
Одной из проблем, с которой мы столкнулись, было ожидаемое время отклика в веб-интерфейсе Radar, доступном каждому посетителю сайта. С ростом количества данных появилась необходимость обновить и модель хранения данных, и архитектуру запросов к ней от пользователей. Radar должен быть в состоянии быстро отгружать все данные по запрошенному периоду любому посетителю.
Предложенная схема работы механизма ASPA.
Также мы надеемся, что в течение этого года ASPA станет RFC — утвержденным сетевым стандартом. Необходимость наличия более широкого, чем комбинация IRR/RPKI, и более легковесного, чем BGPSec-решения, очевидна всем в индустрии. В 2019 году стало очевидно, как некорректная настройка BGP может вести к утечкам маршрутов с чудовищными последствиями в виде недоступности огромного количества сервисов, вовлекающих крупнейших поставщиков Интернет-услуг. Удивительно, но эти инциденты в очередной раз доказали, что не существует серебряной пули, способной одолеть все возможные сценарии их развития.
Необходимо, чтобы крупнейшие Интернет-провайдеры в мире поддержали изначальное движение. Вовлечение крупных сообществ, способных помочь в нахождении источника утечки маршрута — это следующий шаг. Говоря простым языком, ASPA является новым объектом, соединяющим текущие возможности ROA и RPKI — она реализует простой принцип: «Знай своего поставщика». Владельцу AS нужно знать только свои апстримы для того, чтобы внедрить достаточно надежный способ защиты от инцидентов BGP-маршрутизации.
Как и в случае с ROA, ASPA позволяет фильтровать маршруты при любом соединении: с вышестоящим поставщиком, соседом или, конечно же, потребителем. Соединение ROA и ASPA может решить львиную долю задач по защите сети без необходимости внесения принципиальных изменений в сам протокол, отфильтровывая намеренные атаки и ошибки, связанные с человеческим фактором. Однако, необходимо будет дождаться также и поддержки от производителей ПО и оборудования — хотя есть уверенность, что поддержка в открытом исходном коде не заставит себя ждать.
Одним из главным преимуществ ASPA является то, что это очень простая идея. В 2020 году планируется завершить работу над черновиком протокола, а в случае успеха IETF и соавторы черновика придут к единому мнению относительно закрепления статуса протокола.
Текущее и будущее развитие сети фильтрации Qrator
Логика фильтрации
В течение предыдущих двух лет мы инвестировали значительные объемы времени и усилий в улучшение логики фильтрации, являющейся основой сервиса нейтрализации атак, который мы предоставляем. К текущему моменту они уже работают на всей сети, показывая значительное повышение как эффективности работы, так и снижение нагрузки на память и центральный процессор на точках присутствия. Новые фильтры также позволяют синхронно анализировать запросы и предоставлять разнообразные JavaScript-задачи для проверки легитимности посетителя, улучшая качество обнаружения атак.
Главная причина обновления логики фильтрации заключается в необходимости обнаружения целого класса ботов с первого запроса. Qrator Labs использует комбинации проверок с запоминанием состояния и без, и только после подтверждения легитимности пользователя посылает запрос дальше на защищаемый сервер. Поэтому необходимо, чтобы фильтры работали очень быстро — современные DDoS-атаки проходят с интенсивностью десятков миллионов пакетов в секунду, и часть из них может быть одноразовыми, уникальными запросами.
В 2020 году как часть этого процесса также будут внесены значительные изменения в процесс «онбординга» трафика, то есть начала работы с новым защищаемым сервисом. Трафик каждого сервиса по-своему уникален и мы стремимся добиться того, чтобы вне зависимости ни от чего новые клиенты быстрее получали полную нейтрализацию всех типов атак, даже при условии недостаточной обученности модели. В результате мы обеспечим более гладкое включение фильтрации при подключении под атакой, а начало фильтрации будет сопровождаться меньшим количеством ложноположительных срабатываний. Все это важно, когда сервис и люди, стоящие за ним, находятся посреди борьбы за выживание под массированными сетевыми ударами.
Распределение DDoS-атак за 2019 год по используемой полосе.
Проблемы с реализациями протокола HTTP/2 (уязвимости на отказ в обслуживании) были в основном решены в течение 2019 года, что позволило нам включить поддержку данного протокола внутри сети фильтрации Qrator.
Сейчас работа активно продолжается с целью обеспечить возможность защиты HTTP/2 каждому клиенту, завершая длительный и глубокий период тестирования. Одновременно с поддержкой HTTP/2, TLS 1.3 была представлена возможность использования eSNI с автоматизированной выдачей сертификатов безопасности Let«s Encrypt.
В настоящий же момент HTTP/2 предоставляется по запросу в качестве дополнительной опции.
Контейнеры и оркестрация
Текущие тренды контейнеризации плохо совместимы с нашими подходами к безопасности. Это значит, что работая с Kubernetes, приходится преодолевать разнообразные вызовы. Безопасность и доступность находятся среди высших приоритетов, что не позволяет полагаться на распространенные среди работающих с Kubernetes практики, в первую очередь предоставляя процессу оркестрации полный контроль над операционной системой со всеми возможностями — это бы оставило нас исключительно на милость разработчиков Kubernetes и дополнений к нему. Пока что Kubernetes не обладает всеми необходимыми возможностями из коробки, а кое-какие даже сокрыты до состояния «используйте как есть, гарантия отсутствует» и не могут быть детально исследованы. Но все это не отворачивает от дальнейшей работы над внедрением Kubernetes в управление сетью фильтрации, постепенно подгоняя его под наши требования и делая достаточно важной частью внутренней инфраструктуры.
Будущее разработки и развития распределенных и отказоустойчивых сетей требует внедрения соответствующего инструментария (CI/CD и автоматическое тестирование — его часть) и умения использовать его для создания и управления стабильной и надежной системой. Так как количество данных только увеличивается, усилия по мониторингу должны расти вслед за ними. Наиболее естественный способ построения мониторинга — это предоставление безопасного и легко различимого способа общения для приложений. Мы считаем, что Kubernetes уже доказал свою универсальность и применимость, а дальнейшая специализация его под нужды работы инфраструктуры, борющейся с DDoS-атаками, это реальность работы с любым решением с открытым исходным кодом.
Изменение средней продолжительности DDoS-атак с 2018 по 2019 год.
Яндекс.Облако и Ingress 2.0
В 2019 году совместно с Яндекс.Облаком мы представили обновленную версию нашего сервиса по фильтрации входящего трафика — Ingress, значительно расширив его возможности фильтрации и конфигурации, предоставив конечному пользователю понятные интерфейсы для управления. Новая версия сервиса уже работает на сети фильтрации Qrator Labs, равно как и на сети Яндекс.Облака.
Команда Яндекс.Облака прошла с нами длинный путь, объединив две инфраструктуры с помощью физических узлов Qrator Labs, размещенных внутри инфраструктуры партнера, работающих над его трафиком.
Наконец, спустя период глубокого тестирования, новая версия Ingress готова к использованию. С помощью Яндекса мы смогли сделать одно из лучших решений по фильтрации входящего трафика, созданное специально для нужд сервисов, генерирующих много контента.
Также считаем большим успехом, что новая версия сервиса интуитивно понятна конечному пользователю и позволяет более гибко настраивать параметры фильтрации.
TLS 1.3 и ECDSA-сертификаты
В начале 2019 года Qrator Labs писала о поддержке TLS версии 1.3 с одновременным отключением SSL v. 3. По причине наличия услуги нейтрализации DDoS без раскрытия ключей шифрования, были сделаны дополнительные улучшения в данной схеме фильтрации, повышающие скорость и надежность трансляции syslog. Позволим себе напомнить результаты замеров производительности.
Как вы можете видеть, на одном ядре процессора Intel® Xeon® Silver 4114 CPU @ 2.20GHz (выпущенного в третьем квартале 17 года) общая разница между производительностью ECDSA и общепринятым RSA с длиной ключа 2048 бит составляет 3,5 раза.
Давайте посмотрим на результаты выполнения команды openssl -speed для ECDSA и RSA на том же процессоре.
Здесь мы можем найти подтверждение ранее написанному тезису о том, как различаются вычислительно операции подписи и ее проверки для ECC и RSA. На текущий момент, вооружившись TLS 1.3 криптография на основе эллиптических кривых дает значительный прирост производительности сервера при большем уровне защиты, по сравнению с RSA. Это и есть та главная причина, по которой мы в Qrator Labs рекомендуем и всячески поощряем клиентов, готовых использовать в том числе ECDSA-сертификаты. На современных CPU прирост производительности в пользу ECDSA составляет 5х.
Меньшие улучшения
Одним из небольших и незаметных, но тем не менее важных нововведений в течение 2019 года было внедрение процесса активной проверки состояния апстрима. Если по какой-то причине на одном из вышестоящих соединений нашего клиента что-то происходит во время атаки — сервис фильтрации будет первыми, кто узнаем об этом, выведя соединение из рабочего состояния до тех пор, пока проблема не будет решена. В этом ему помогает не только мониторинг ошибок и состояния трафика, но и настройка специального интерфейса проверки доступности, которая делается совместно с потребителем услуги.
В конце 2019 года был произведен большой апдейт пользовательского интерфейса услуги фильтрации. И хотя возможность использования старой версии личного кабинета предоставляется, новые возможности развиваются уже в обновленной части, предоставляющей более широкий функционал, например, управление TLS-сертификатами.
В то время как старая версия личного кабинета использовала серверный рендеринг, обновленная версия в лучших традициях современного веба является JavaScript-приложением, выполняемом на клиенте, общающемся с сервером по REST API. Такой подход позволит быстрее предоставлять новые функции пользователю, одновременно давая более глубокие возможности по индивидуальной настройке каждого личного кабинета отдельного потребителя. Одной из таких вещей является секция «Аналитика», где возможна настройка индивидуальных метрик, количество которых постоянно увеличивается.
Сравнение двух основных групп классификации DDoS-атак за 2019 год.
IPv6
Qrator Labs активно готовится к тому, чтобы начать использовать протокол IPv6 в рамках услуг фильтрации трафика. Для любой компании, занимающейся кибербезопасностью, такой переход не может быть элементарен. Из-за самой природы DDoS-атак нейтрализация сетевых нападений с использованием IPv6 требует кардинальной смены подхода, так как более невозможно оперировать с любыми формами «списков», имея дело с теоретическим лимитом в 2128 IP-адресов. И речь идет только о TCP, не рассматривая UDP.
Для нас 2020 год станет годом IPv6. С истощением свободного IPv4 адресного пространства не существует другого способа развивать сеть, которая бы отвечала будущим требованиям. Надеемся, что сможем эффективно ответить на все вызовы, стоящие перед нами в рамках нейтрализации IPv6-атак. В первую очередь это значит, что мы будем в состоянии анонсировать IPv6-подсеть потребителя услуги фильтрации с помощью нашей сети, одновременно предлагая первоклассный сервис кибербезопасности.
Антибот
В 2019 году индустрия наблюдала ожесточенную схватку фингерпринтинга (идентификации посетителя) и попыток его ограничения. Желание владельцев и разработчиков интернет-сервисов ограничить или разделить запросы от легитимных пользователей от автоматизированных запросов от ботов вполне понятно. С другой стороны, нет ничего странного и в желании разработчиков браузеров обезопасить пользователей ПО. Qrator Labs годами напоминали рынку о том, что если какая-то информация является публично доступной и не требуется никакой авторизации для ее получения, то вероятность защитить ее от автоматизированного парсинга стремится к нулю. В то же время напоминаем владельцам цифрового бизнеса, что у них есть право выбирать, что делать с приходящими на сервер запросами. Проактивный подход в определенных ситуациях помогает оценить и определить угрозу.
Так как боты генерируют все большую долю трафика, можно ожидать наступления в будущем момента, когда крупные сервисы будут создавать специальные интерфейсы для хороших ботов, отдавая им легитимную информацию. Остальные же будут блокироваться. Даже сейчас, в начале 2020 года, можно утверждать, что не на
