Состояние сетевой безопасности в 2016 году, подробный отчёт Qrator Labs и Wallarm



    «Хабраэффект» наоборот — атаки на Хабрахабр за год (сверху) и на Гиктаймс (снизу). В феврале 2017 на Гиктаймс была нейтрализована атака в 17,5 Гбит/с.



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

    Инциденты, связанные с атаками типа «отказ в обслуживании» вновь на слуху — но теперь грамотно выполненные атаки уже угрожают доступности целых регионов. На проблему вновь нужно обращать повышенное внимание — словно мы вернулись на 5—7 лет назад в прошлое.

    До прошлого года могло казаться, что проблема DDoS уже достаточно хорошо решена.

    Но мощность атак и их сложность в минувшем году выросли радикально. В прошлом даже мощные атаки в 100—300 Гбит/с не вызывали особой «головной боли». Сложные типы атак на протоколы прикладного уровня случались редко.

    А в 2016 году мир впервые увидел атаки в 1 Тбит/с, и атаки на L7 стали куда более распространёнными.

    Упрощение атак


    Можно назвать несколько причин для этих изменений.

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

    Таким же образом сформировался весь современный Интернет — создание его протоколов и спецификаций породили аналогичные проблемы.

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


    Динамика изменения активности атак по индустриям за 2015 — 2016 гг.

    Хорошая иллюстрация этому — возникшая осенью 2016 года угроза Mirai, ботнета небывалой мощности, который был построен на устройствах Интернета вещей — от домашних маршрутизаторов и IP-камер до смешной «экзотики» уровня чайников с Wi-Fi. Опасность Mirai оказалась вполне реальной: на блог исследователя Брайна Кребса пришли вполне осязаемые 620 Гбит/с volumetric-атаки, а французский хостер OVH выдержал 990 Гбит/с.

    Сами мы в минувшем году тоже встречались с Mirai — в виде атаки на 120 Гбит/с.

    Сильнее всего от Mirai пострадал DNS-провайдер Dyn, к услугам которого прибегают многие компании из списка Fortune 500. Атака water torture на DNS-серверы, трафик TCP и UDP на порт 53, мощность в 1,2 Тбит/с со ста тысяч узлов — и на несколько часов ушли в оффлайн крупнейшие веб-сайты мира. Защищать DNS особенно сложно. Обычно мусорный трафик приходит с десятка портов (53, 123 и так далее). В случае с DNS-сервером закрытие 53 порта означает приостановку нормальной работы сервиса.

    Сам ботнет Mirai состоял из подключённых к Интернету устройств с парами «логин-пароль» по умолчанию и достаточно простыми уязвимостями. Мы полагаем, что это — лишь первенец в целом поколении ботнетов на основе Интернета вещей. Даже решение проблемы одного Mirai не поможет.

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

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

    С какими атаками придётся столкнуться, скажем, в 2019 году?

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

    Амплификация


    Для увеличения мощности атак злоумышленники амплифицируют атаки. Атакующий увеличивает объём отсылаемого «мусорного» трафика путём эксплуатации уязвимостей в сторонних сервисах, а также маскирует адреса реального ботнета. Типичный пример атаки с амплификацией — это трафик DNS-ответов на IP-адрес жертвы.



    Другой вектор — Wordpress, повсеместный и функциональный движок для блогов. Среди прочих функций в этой CMS есть функция Pingback, с помощью которой автономные блоги обмениваются информацией о комментариях и упоминаниях. Уязвимость в Pingback позволяет специальным XML-запросом заставить уязвимый сервер запросить любую веб-страницу из Интернета. Полученный злонамеренный трафик называют Wordpress Pingback DDoS.

    Атака на HTTPS не сложнее, чем на HTTP: нужно лишь указать другой протокол. Для нейтрализации же потребуется канал шириной от 20 Гбит/с, возможность обрабатывать трафик прикладного уровня на полной пропускной способности соединения и расшифровывать все TLS-соединения в реальном времени — значительные технические требования, исполнить которые могут далеко не все. К этой комбинации факторов добавляется огромное число уязвимых серверов на Wordpress — в одной атаке можно задействовать сотни тысяч. У каждого сервера неплохое соединение и производительность, а участие в атаке для обычных пользователей незаметно.

    Мы увидели первое использование вектора в 2015 году, но он до сих пор работает. Мы ожидаем, что в дальнейшем этот тип атак вырастет в частоте и мощности. Амплификация на Wordpress Pingback или DNS — это уже отработанные примеры. Вероятно, в будущем мы увидим эксплуатацию более молодых протоколов, в первую очередь игровых.

    BGP и утечки


    Отцы-основатели Интернета вряд ли могли предвидеть, что он вырастет до своих текущих объёмов. Та сеть, которую они создавали, была построена на доверии. Это доверие было утрачено в периоды бурного роста Интернета. Протокол BGP создавали, когда общее число автономных систем (AS) считали десятками. Сейчас их более 50 тысяч.

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

    Но в реальном мире деньги — на первом месте. Деньги отправляют трафик из России куда-то в Европу, а затем возвращают обратно на Родину — так дешевле, чем использовать канал внутри страны. Политика не даёт двум поссорившимся провайдерам обмениваться трафиком напрямую, им легче договориться с третьей стороной.

    Другая проблема протокола — отсутствие встроенных механизмов проверок данных по маршрутизации. Отсюда берут корни уязвимости BGP hijacking, утечек маршрутов и зарезервированных номеров AS. Не все аномалии злонамеренны по своей природе, часто технические специалисты не до конца понимают принципы функционирования протокола. «Водительских прав» на вождение BGP не дают, штрафов нет, зато доступно большое пространство для разрушений.

    Типичный пример утечек маршрутов: провайдер использует список префиксов клиентов как единственный механизм фильтрации исходящих анонсов. Вне зависимости от источника анонсов клиентские префиксы всегда будут анонсироваться по всем доступным направлениях. Пока существуют анонсы напрямую, данная проблема остаётся труднодетектируемой. В один момент сеть провайдера деградирует, клиенты пытаются увести анонсы и отключают BGP-сессию с проблемным провайдером. Но оператор продолжает анонсировать клиентские префиксы во всех направлениях, создавая тем самым утечки маршрутов и стягивая на свою проблемную сеть значительную часть клиентского трафика. Разумеется, так можно организовывать атаки Man in the Middle, чем некоторые и пользуются.

    Для борьбы с утечками в anycast-сетях мы разработали ряд поправок и представили их Инженерному совету Интернета (IETF). Изначально мы хотели понять, когда в такие аномалии попадают наши префиксы, и по чьей вине. Поскольку причиной большинства утечек оказалась неправильная настройка, мы поняли, что единственный способ решить проблему — устранить условия, в которых ошибки инженеров способны влиять на других операторов связи.


    IETF разрабатывает добровольные стандарты Интернета и помогает их распространению. IETF — это не юридическое лицо, а сообщество. У такого метода организации есть множество плюсов: IETF не зависит от правовых вопросов и требований какой-либо страны, его нельзя засудить, взломать или атаковать. Но IETF не платит зарплаты, всё участие добровольно. Вся деятельность едва ли выходит на приоритет выше, чем «неприбыльная». Поэтому разработка новых стандартов идёт медленно.

    Обсуждать или предлагать черновики стандартов может любой желающий — в IETF нет требований членства. В рабочей группе идёт основной процесс. Когда достигнуто согласие об общей теме, то с авторами предложения начинают обсуждения и доработку черновика. Результат уходит директору области, цель которого — перепроверка документа. Затем документ направляют в IANA, поскольку всеми изменениями протокола управляет именно эта организация.

    Если наш черновик с новым расширением BGP пройдёт все «круги ада», то поток утечек маршрутов иссякнет. Злонамеренные утечки никуда не уйдут, но для решения этой задачи есть лишь один вариант — постоянный мониторинг.

    2017 год


    Мы ожидаем более быстрое обнаружение уязвимостей у предприятий. По статистике, полученной компанией Wallarm с развёрнутых компанией honeypot'ов, в 2016 году между публичным эксплойтом и его массовой эксплуатацией проходит в среднем 3 часа. В 2013 году этот срок составлял неделю. Злоумышленники становятся всё более подготовленными и профессиональными. Ускорение продолжится, мы ожидаем сокращения этого временного промежутка до 2 часов в ближайшем будущем. И снова лишь проактивный мониторинг способен предотвратить эту угрозу и застраховать от чудовищных последствий.

    Взлом и сетевое сканирование уже достигли небывалого масштаба. Всё больше злоумышленников в этом году обзаведутся предварительно отсканированными диапазонами IP-адресов, сегментированных по используемым технологиям и продуктам — к примеру, «все серверы Wordpress». Увеличится число атак на новые технологические стеки: микроконтейнеры, приватные и публичные облака (AWS, Azure, OpenStack).

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



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

    • +52
    • 8,3k
    • 5
    Qrator Labs
    146,99
    DDoS Attacks Mitigation & Continuous Availability
    Поделиться публикацией

    Комментарии 5

      +1
      Для нейтрализации же потребуется канал шириной от 20 Гбит/с, возможность обрабатывать трафик прикладного уровня на полной пропускной способности соединения и расшифровывать все TLS-соединения в реальном времени

      Атака со статических адресов и для блокировки должно быть достаточно блеклиста, а для построения блеклиста должно быть достаточно зарулить/дешифровать какой-нибудь небольшой процент соединений. Есть какая-то причина дешифровать весь трафик?
      На самом деле, все еще интересней, в большинстве случаев можно обнаружить подозрительные узлы даже пассивно по используемому cypher suite, отличие от популярных браузеров будет весьма значительное.
        0
        Владимир, в случае если ботовод с ярко выраженным синдромом дауна — можно еще и до SSL хэндшейка «отшить». А если нет?

        И что именно с рандомными соединениями делать?
        Полнота наблюдений определяет Качество фильтрации;
        Рандомное покрытие — > рандомный результат.
          +5
          Есть какая-то причина дешифровать весь трафик?

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

          Во-первых, какому-то одному конкретному сайту, вполне вероятно, достаточно настроить себе простую фильтрацию по cipher suite, плюс обезопасить себя от самых простых угроз (amplification, pingback) — то есть, от ковровых бомбардировщиков-вымогателей — и жить себе дальше. Но к системам по защите от атак обычно обращаются клиенты, у которых проблема не эпизодическая, она постоянная и носит характер, прошу прощения, advanced persistent threat.

          Здесь уже нельзя ограничиться защитой от 80% популярных угроз (что, в полном соответствии с принципом Парето, займёт 20% сил), нужно быть готовым защитить клиента от всего, что может быть использовано целеустремлённым злоумышленником.

          Это, кстати, как раз та стена, о которую, по моему опыту, разбиваются те же 80% попыток построить свой бизнес в защите от DDoS-атак (и у меня есть стойкое подозрение, что это можно экстраполировать на весь остальной ИБ-бизнес). Выглядит это обычно примерно следующим образом:

          1. Вначале администратор некого хостинга сталкивается с пресловутой «ковровой бомбардировкой» в виде письма с угрозами одному из клиентов и «детской» атакой типа NTP Amplification мощностью 40 Гбит/с.

            Администратор решает эту проблему (в сотрудничестве с провайдером Интернет-доступа) оперативно и эффективно, после чего решает, что может теперь предоставлять услуги по защите от DDoS-атак всем желающим.

          2. На сайте хостинга вывешивается реклама новой услуги по защите от DDoS-атак. Эта же реклама появляется в поисковой выдаче.

          3. Спустя полгода-год эту рекламу находит в выдаче всерьёз страдающий от постоянных атак сайт, на который сделали дорогостоящий «заказ» конкуренты.

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

          5. Через двое суток без сна, под неослабевающим давлением клиентского отдела, администратор не выдерживает, отказывает сайту в услугах и удаляет рекламу с сайта.

          Во-вторых, и это не менее важно, система фильтрации атак должна быть готова не только к существующим методикам, но и к появлению новых. Уязвимые Wordpress-серверы, в основном, все переписаны и учтены, и, в самом деле, можно предзагрузить их список, но что будет делать система фильтрации, если аналогичная проблема появится в Joomla? А что делать с эволюцией IoT-ботнетов? Или с Android-ботнетами — не фильтровать же любую Android-ОС по cipher suite, да и IP-адреса мобильных телефонов никак не фиксированы.

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

            Притворюсь, что не понял, что это риторический вопрос :)
            Давайте я еще чтобы продемонстрировать мысль усложню задачу, и представим, что атака пошла сразу с миллиона джумл, чтобы дешифровать весь трафик не хватит никаких ресурсов и надо срочно спасать клиента. Именно в этом случае, я бы сделал примерно так: разграничил трафик от браузеров и от хостинговых сетей, можно по имеющимся IP-классификаторам, можно по сигнатурам TLS-хэндшейка, одного коннекта с одного IP хватает для классификации. В атаке участвует 1,000,000 джумл — для «грубой» классификации пропустим миллион коннектов от джумл прежде чем их грубо отфильтруем. Дальше трафик гарантированно не от джумл пропустил бы обычным путем, % грубо отфильтрованных коннектов на который хватает мощности пустил бы на дешифровку и анализ и состсавил черный список (с джумлами) / белый список (с false positive'ами «грубого» классификатора), остальные коннекты, на которые не хватает ресурсов просто пустил бы в блекхол. Да, зарежем на время людей с проксями на хостингах или возможно какие-то поисковики — и фик с ними. И так пока большая часть атаки не будет отфильтрована блеклистом. По мере роста блеклиста мощность атаки и процент коннектов, уходящих в блекхол будет снижаться, не думаю что потребуется больше нескольких минут, чтобы митигировать ее блеклистами до уровня, когда можно обработать весь трафик. Так что джумлы с вордпрессами не очень пугают, потому что можно быстро сделать грубый фильтр на пассивный трафик.
            А вот IoT с Андроидами это очень страшно, да, потому что такое не прокатит.
              +1
              Именно в этом случае, я бы сделал примерно так: разграничил трафик от браузеров и от хостинговых сетей

              … что тут же уничтожит бизнес B2B-клиентов: платёжные системы, СДБО, банкоматы, биржи, торги, бронирование билетов, регистрация на авиарейсы, облачная бухгалтерия, государственные электронные системы доступа к информации…

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

              Вначале вам нужно будет проснуться, или дойти до офиса от метро, или приземлиться на самолёте, если вы в отпуске. Так как вы заранее не знаете, что нужно ловить именно Joomla, вам нужно будет вначале построить кластеры запросов и понять, на какой именно параметр запроса смотреть и что именно искать в User-Agent. И это в предположении, что гипотетическая уязвимость в Joomla, как и уязвимость в Wordpress, не позволяет формировать этот заголовок произвольным образом — а такое предположение чересчур оптимистично, поскольку все уязвимости разные. Таким образом, пропустить придётся куда больше миллиона соединений — в предположении, что у нас миллионный ботнет, это будет порядка 300 миллионов соединений в минуту. 300 миллионов пропущенных одновременных коннектов сами по себе отделают любой Windows Server, как Бог черепаху. Для восстановления работы потребуется перезагрузка.

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

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

        Самое читаемое