Работа в Стамбуле

Метка: mpls mitm

  • Celer Bridge процессинг или Amazon опять теряет контроль над своим IP-пространством из-за перехвата сессии BGP

    Celer Bridge процессинг или Amazon опять теряет контроль над своим IP-пространством из-за перехвата сессии BGP

    Поговорим о том, как три часа бездействия сетевых инженеров Amazon стоили держателям криптовалюты в $235 000.

    Amazon недавно потерял контроль над своими IP-адресами, которые он использует для предоставления облачных сервисов, и потребовалось более трех часов инженерам электросвязи, чтобы восстановить контроль над сетью. Эта ошибка позволила похитить 235 000 долларов США в криптовалюте у пользователей одного из партнёров Amazon.

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

    Случай ошибочной идентификации

    В прошлом месяце автономная система 209243, принадлежащая британскому сетевому оператору Quickhost.uk, внезапно начала объявлять через bgp, что ее инфраструктура является подходящим и наилучшим путём для других ASN для доступа к так называемому блоку IP-адресов /24, принадлежащему AS16509, одному из как минимум трёх ASN, которыми управляет Amazon. Захваченный блок включал 44.235.216.69 IP-адрес, на котором размещен cbridge-prod2.celer.network, поддомен, отвечающий за обслуживание критического пользовательского интерфейса смарт-контрактов криптовалютной биржи Celer Bridge.
    17 августа неизвестные использовали bgp-перехват, чтобы сначала получить сертификат TLS для cbridge-prod2.celer.network, поскольку им удалось продемонстрировать центру сертификации GoGetSSL в Латвии, что они контролируют этот субдомен. Имея сертификат, неизвестные затем разместили свой собственный смарт-контракт в том же домене и ждали посещений от людей, пытающихся получить доступ к реальной странице Celer Bridge cbridge-prod2.celer.network.
    В общей сложности подставной контракт унес с 32 учетных записей биржи в общей сложности 234 866,65 долларов США, согласно отчету охранной фирмы SlowMist и отчету группы анализа угроз Coinbase.
    потери криптобиржы Celer Bridge из-за перехвата сессии BGP
    потери криптобиржы Celer Bridge из-за перехвата сессии BGP

    Что думает по этому поводу команда Coinbase

    Фишинговый контракт очень похож на официальный контракт Celer Bridge, поскольку имитирует многие его атрибуты. Для любого метода, явно не определенного в фишинговом контракте, он реализует структуру прокси, которая перенаправляет вызовы на легальный контракт Celer Bridge. Прокси-контракт уникален для каждой цепочки и настраивается при инициализации. Команда ниже иллюстрирует содержимое слота хранилища, отвечающего за конфигурацию прокси-контракта фишингового контракта:
    Хранение прокси-контракта для фишинговых смарт-контрактов
    Фишинговый контракт крадет средства пользователей двумя способами:
    • Любые токены, одобренные жертвами фишинга, удаляются с помощью специального метода с 4-байтовым значением 0x9c307de6().
    • Фишинговый контракт отменяет следующие методы, предназначенные для немедленной кражи токенов жертвы:
    • send() — используется для кражи токенов (например, USDC)
    • sendNative() — используется для кражи собственных активов (например, ETH)
    • addLiquidity() — используется для кражи токенов (например, USDC)
    • addNativeLiquidity() — используется для кражи собственных активов (например, ETH)
    Ниже приведен пример фрагмента кода, полученного методом реверс-инжиниринга, который перенаправляет активы в кошелек человека, осуществившего BGP-перехват:
    Фрагмент фишингового смарт-контракта

    Привет, Amazon? Где ваш сетевой инженер?

    Как показано в зеленых секциях в верхней части этого графика, подготовленного Дугом Мэдори из компании по мониторингу сети Kentik, мошенническое объявление BGP началось 17 августа около 19:39 UTC времени и за считанные секунды префикс распространился глобально. По неизвестным причинам объявление префикса было отозвано в 20:22 только для того, чтобы вернуться и быть отозвано еще три раза в течение следующих двух часов.
    BGP-перехват Celer Bridge
    В объявлении маршрута по BGP утверждалось, что адрес 44.235.216.0/24 исходит от AS14618, одного из других ASN Amazon, и должен быть маршрутизирован через AS20943 Quickhostuk. Новое объявление BGP, подобное этому, которое за считанные секунды заставляет весь Интернет маршрутизировать IP-адреса Amazon через Quickhostuk ASN, — это событие, которое должно было вызвать немедленное расследование со стороны облачного провайдера. По причинам, которые остаются неизвестными, Amazon не начал объявлять правильный путь для своего блока /24 до 23:07 (как указано фиолетовым цветом на графике выше), более чем через три часа после начала мошеннических объявлений маршрутной информации BGP.
    «Ключевой деталью, которая отличала бы это предупреждение от появления просто еще одного узла Amazon, было бы то, что новый восходящий поток был виден 100% точек обзора BGP», — написал Мадори в четверг. «Другими словами, этот новый префикс Amazon эксклюзивно передавался этим относительно неизвестным хостинг-провайдером. Это должно было вызвать удивление у команды Amazon NetOps».
    Представители Amazon не ответили ни на одно из трех электронных писем с просьбой прокомментировать этот пост, отправленных за последние девять дней. После публикации этого сообщения представитель Amazon заявил, что все несколько адресов назначения в запросе на комментарий были отключены, и что компания не игнорирует электронные письма.
    Представители Quickhostuk не ответили на два электронных письма с вопросом, как и откуда появились мошеннические объявления маршрутной информации BGP. 

    Подобное уже случалось ранее

    Это не первый случай, когда BGP-атака с целью перехвата IP-адресов Amazon заканчивается огромными потерями криптовалюты. В 2018 году невероятно похожее событие произошло с сервисом системы доменных имен Amazon Route 53. В результате атаки у владельцев счетов MyEtherWallet.com было украдено около 150 000 долларов США в криптовалюте. Украденная сумма, вероятно, была бы выше, если бы неизвестные получили бы доверенный браузеру TLS-сертификат вместо самописного сертификата, который требовал от жертв нажатия на предупреждение.

    После атаки 2018 года Amazon добавила более 5000 своих IP-префиксов к так называемым ROA (разрешения на происхождение маршрута), которые представляют собой общедоступные документы, в которых указывается, какие ASN имеют право объявлять какие IP-адреса. Этот шаг обеспечил некоторую защиту от RPKI (инфраструктуры открытых ключей ресурсов), которая использует цифровые сертификаты для подключения ASN к их законным IP-адресам.
    Этот анализ показывает, что для обхода защиты неизвестные в прошлом месяце добавили AS16509 и более конкретный маршрут /24 в так называемый AS-SET, индексированный в ALTDB, бесплатном реестре для автономных систем, в котором можно публиковать свои политики маршрутизации BGP.

    irrd.log-20220817.gz:31106270-ADD 96126
    irrd.log-20220817.gz:31106280-
    irrd.log-20220817.gz:31106281-as-set: AS-SET209243
    irrd.log-20220817.gz:31106306-descr: quickhost set
    irrd.log-20220817.gz:31106332-members: AS209243, AS16509
    irrd.log-20220817.gz:31106362:mnt-by: MAINT-QUICKHOSTUK
    irrd.log-20220817.gz:31106392-changed: crussell()quickhostuk net 20220816
    irrd.log-20220817.gz:31106438-source: ALTDB

    irrd.log-20220817.gz:31147549-ADD 96127
    irrd.log-20220817.gz:31147559-
    irrd.log-20220817.gz:31147560-route: 44.235.216.0/24
    irrd.log-20220817.gz:31147588-descr: route
    irrd.log-20220817.gz:31147606-origin: AS16509
    irrd.log-20220817.gz:31147626:mnt-by: MAINT-QUICKHOSTUK
    irrd.log-20220817.gz:31147656-changed: crussell()quickhostuk net 20220816
    irrd.log-20220817.gz:31147702-source: ALTDB

    AS-SET — это регистрационная запись, определяющая допустимый набор номеров ASN, с которыми провайдер может взаимодействовать в глобальной сети.
    Анализируя, почему этот приём не смог предотвратить угон bgp-сессии в прошлом месяце, Мадори осторожно отметил, что RPKI предназначен для ограничения воздействия непреднамеренных или случайных перехватов bgp из-за утечек маршрутизации или неправильных конфигураций, а не в качестве механизма безопасности для предотвращения мошенничества и угона bgp-сессии со стороны мотивированных нарушителей.
    Он написал: «Тем не менее, это все равно могло бы помочь, если бы ROA было настроено по-другому. В нынешнем виде ROA для рассматриваемого адресного пространства довольно либерален. По сути, три разных ASN Amazon (16509, 8987 и 14618) могут объявлять части этого адресного пространства с префиксами размером от /10 до /24. Посмотрите выходные данные веб-интерфейса Routinator:…»

    Альтернативным подходом к созданию ROA было бы сделать то, что сделали другие сети, такие как Cloudflare и Comcast: установить источник и максимальную длину префикса, чтобы они были идентичны тому, как маршрутизируется префикс. Хотя этот подход влечет за собой накладные расходы, связанные с необходимостью обновлять ROA каждый раз при изменении маршрута, он также оставляет мало места для ввода в обращение альтернативных версий маршрута.
    Честно говоря, Amazon — далеко не единственный облачный оператор, потерявший контроль над своими IP-адресами в результате атаки BGP. Уязвимость BGP к неуклюжим ошибкам в настройке и откровенному мошенничеству очевидна уже более двух десятилетий. Отсутствие безопасности в конечном итоге является общеотраслевой проблемой, которую Amazon не в состоянии решить в одиночку.
    Но как облачный провайдер первого уровня, который в настоящее время пострадал как минимум от двух перехватов BGP, которые стоили денег нижестоящим пользователям, Amazon следует ожидать, что он признает это событие, объяснит, почему он ждал более трех часов, чтобы принять корректирующие меры, и наметит план. для предотвращения подобных случаев в будущем. Вместо того, чтобы хранить молчание по радио, как это делалось в течение последних пяти недель, Quickhostuk также должен объяснить этот инцидент и объяснить, почему его ASN опубликовал такое проблемное объявление.
  • Реализация сценариев bgp spoofing и bgp hijacking с помощью Loki

    Реализация сценариев bgp spoofing и bgp hijacking с помощью Loki

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

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

    Некоторые из представленных утилит нацелены на внедрение ложных маршрутов технологии MPLS (многопротокольная коммутация на основе признаков), которую провайдеры типа Ростелеком, Транстелеком, Вымпелком, Мегафон, Укртелеком, Level 3, Verizon, AT&T, Vodafone и Sprint используют для отделения трафика одних корпоративных пользователей от других во время его передачи из одного географического региона в другой. Утилита позволяет без труда перенаправлять такой трафик и подменять в нем данные всем, кто имеет доступ к сети определенного провайдера.

    Заниматься пробивкой в Ростелекоме очень выгодно
    Метод работает из-за того, что MPLS не имеет встроенного механизма защиты целостности заголовков пакетов, определяющих, куда должен быть доставлен поток. По словам Рея, обнаружить подмену абсолютно невозможно.

    Еще несколько приложений нацелены на использование уязвимостей в протоколе BGP (пограничный шлюзовый протокол). Помимо всего прочего, они позволяют взламывать криптографические ключи MD5, используемые для предотвращения манипуляции данными маршрутизации. Кроме этого можно прописывать в таблицы BGP несанкционированные пути, что позволяет контролировать огромные объемы сетевого транзитного трафика.

    Оставшиеся программы предназначены для использования вышеописанных дыр в Ethernet. Все они находятся в свободном доступе. В последней версии добавлена функция перехвата и расшифровки ключей сервера аутентификации и авторизации пользователей tacacs+.

  • Как работают точки обмена интернет IP трафиком в России

    Как работают точки обмена интернет IP трафиком в России

    Знаете, благодаря чему провайдеры в России имеют возможность делать нам безлимитные тарифные планы с высокими скоростями доступа в Интернет? И мы можем качать фильмы, музычку и игры, обмениваться фотографиями и говорить бесплатно по скайпу в свое удовольствие, не обращая внимания на потребленный трафик.
    точки обмена трафиком в Ростелеком
    Во многом все это наше счастье стало возможным только благодаря российским точкам обмена трафиком, о которых и пойдет речь в этой статье.  
    Точка обмена Интернет-трафиком (англ. Internet Exchange Point, поэтому ее еще называют IE) – это сетевая инфраструктура, при помощи которой несколько провайдеров могут обмениваться IP-трафиком между независимыми сетями.
    Эффективность точки обмена трафиком увеличивается с ростом числа подключенных участников. Целью создания таких точек является разгрузка магистральных внешних каналов, удешевление трафика, развитие сетевой инфраструктуры в удаленных регионах и проч. Зачастую обменный трафик бесплатен для интернет-провайдеров, подключенных к точкам обмена трафика, что позволяет удешевлять услуги для пользователей и делать им безлимитные тарифные планы с высокими скоростями.  Если бы точек IE не существовало, то каждому оператору пришлось бы покупать и транспортировать в свой регион Интернет-трафик самому, а это не только дорого, но еще и трудно реализовать на практике.
    Преимущества использования точек обмена трафиком:
    • Доступность и удешевление Интернет-трафика. Точка IE получает трафик через единый магистральный внешний канал, затем трафик поступает к каждому провайдеру-участнику, который оплачивает только свою часть расходов. После этого ресурсы становятся доступны конечным пользователям, которые также получают более дешевый трафик, ведь расходы оператора напрямую влияют на затраты каждого конкретного Интернет-пользователя.
    • Доступность информационных ресурсов для пользователей, провайдеры которых подключены к точке обмена трафиком. В рамках одной точки обмена все подключенные операторы обмениваются трафиком на более выгодных для пользователей и для самих провайдеров условиях – выше скорость, объемы больше и т.п. Таким образом, преимущества получает не только оператор, но и конечный потребитель.
    • Отсутствие необходимости развивать всю инфраструктуру сети в удаленных и труднодоступных регионах. Т.е. оператор может не вкладывать сумасшедшие деньги в построение сети, договоренности с иностранными компаниями насчет предоставления трафика, транспортировку трафика и проч. Он может просто присоединиться к точке обмена и получить тот же объем трафика, но по более простой и дешевой схеме. А зачастую это единственная возможность для удаленных провайдеров, а как следствие, и для Интернет-пользователей данного региона.
    Точки обмена трафиком в России
    Крупнейшей сетью для обмена трафиком в России является MSK-IX (Moscow Internet Exchange) – точка обмена трафика, которая находится в Москве. По данным на июнь 2011 г., к ней подключено 345 организаций, а суммарный пиковый трафик превосходит 500 Гбит/с.
    Под управлением MSK-IX находится несколько региональных точек обмена трафиком, среди которых:
    • SPB-IX Saint Petersburg Internet Exchange – Санкт-Петербург;
    • RND-IX Rostov-na-Donu Internet Exchange – Ростов-на-Дону;
    • SMR-IX Samara Internet Exchange – Самара;
    • KZN-IX Kazan Internet Exchange – Казань;
    • EKT-IX Ekaterinburg Internet Exchange – Екатеринбург;
    • NSK-IX Novosibirsk Internet Exchange – Новосибирск;
    • VLV-IX Vladivostok Internet Exchange – Владивосток.
    Точка MSK-IX была создана еще в 1995 г. Тогда она имела название М9-XI (поскольку в качестве точки обмена трафиком была выбрана телефонная станция ММТС-9). Среди Московских операторов, объединивших себя в единую сеть обмена были: «Демос», «Релком», МГУ, НИИЯФ МГУ, FREEnet, Ассоциация RELARN и «Роспринт». Свое название MSK-IX сеть получила несколько позже, когда развилась и увеличила количество точек обмена.
    Именно благодаря организации первой точки обмена в России MSK-IX появилось разделение трафика на дешевый российский и дорогой зарубежный, которое существует до сих пор. Это привело к тому, что в конце 90-х гг. прошлого века, впервые в истории Рунета, потребление российского трафика превысило потребление зарубежного ресурса. Именно в этот период Рунет выделился и стал самодостаточным.
    Кроме того, дешевый локальный трафик позволил провайдерам ввести первые безлимитные тарифы, которые по сегодняшний день являются востребованными и любимыми конечным пользователем.
    Сегодня MSK-IX является одной из 5-ти крупнейших в мире точек обмена трафиком по количеству подключенных операторов и по показателям трафика. Она обслуживает более 80% Интернет-пользователей Рунета.
    Также в России существуют и другие точки обмена трафиком. В частности:
    • PIRIX – Санкт-Петербург;
    • DATAIX – Cанкт-Петербург;
    • SIB-IX – Омск;
    • OMSK-IX – Омск;
    • IX-NN – Нижний Новгород;
    • KRS-IX – Красноярск;
    • SIBIR-IX – Сибирская точка обмена трафиком, в основном Красноярск и Красноярский край;
    • ULN-IX Ulyanovsk Internet Exchange – Ульяновск;
    • MPIX – Cанкт-Петербург;
    • Chelyabinsk Peering Point Ural – Челябинск;
    • SAKH-IX – Сахалин;
    • PERM-IX – Perm Internet Exchange – Пермь (пользователи часто называют ее «Пермь-девять» или «Пермское (интернет) кольцо»).
    • SARATOV-IX – Саратов.
    Рынок обмена Интернет-трафиком в России: особенности, достижения и проблемы
    Точки обмена Интернет-трафиком в России и других странах мира призваны повысить доступность Интернета для рядового потребителя, удешевить услуги доступа в Сеть, стимулировать развитие локального Интернет-рынка. К счастью, в РФ сети по обмену трафиком есть, работают успешно и имеют значительно влияние на быстрое развитие Интернет-отрасли в стране.
    Для России экономия средств имеет огромное значение, особенно это касается оплаты услуг доступа в Сеть, ведь страна большая, население разбросано по всей территории, и обеспечить россиян качественным Интернетом бывает очень сложно и дорого. Поэтому поставка трафика по единым магистральным зарубежным каналам, транспортировка его внутри страны, использование локального трафика в отдаленных регионах помогает значительно сэкономить – порядка 20%. Иначе доступ в Сеть и сегодня был бы слишком дорогим удовольствием и диковинкой для жителей удаленных и малозаселенных регионов РФ.
    Развитие инфраструктуры для Интернет-доступа в России также тесно связано с функционированием точек обмена трафиком. В частности, высококачественные и высокоскоростные зарубежные магистральные каналы появились и усовершенствуются именно благодаря совместным вложениям операторов, объединившихся в сеть. Каждому отдельному провайдеру не под силу тянуть оптоволоконные кабели на глобальные расстояния, чтобы закупить и транспортировать трафик от иностранного поставщика к конечному пользователю. Это также разгружает международные линии связи. Да и местная инфраструктура в РФ развивается – оператор может себе позволить тратить больше средств на прокладку линий связи в своем регионе, экономя на получении трафика от поставщика через точку обмена трафиком.
    Кроме того, провайдеры, объединившиеся в сеть, и их клиенты получили возможность активнее развивать свои ресурсы, иметь доступ к ресурсам партнеров, зарабатывать дополнительно благодаря сотрудничеству. Это также стимулирует Интернет-рынок в России, расширяя его и делая более доступным для пользователя, а также более выгодным для операторов и Интернет-предпринимателей.
    Растущие объемы локального Интернет-трафика стимулируют и местных разработчиков приложений, которые находят внутри страны потребителя и могут легко продать свой продукт. По мере того, как рынок приложений растет, конечный потребитель получает все более качественный продукт по все более конкурентной цене. Более того, рынок становится интересным для иностранных разработчиков, которые также начинают предоставлять свои услуги на конкретном локальном рынке. Тем самым конкуренция порождает качество и дешевизну приложений, а также широкий выбор продуктов.
    Производители оборудования, как российские, так и иностранные, также получили выгоду от развития рынка обмена трафиком. В частности, оборудование для организации точек обмена требуется каждому провайдеру-участнику сети. Кроме того, оборудование регулярно нужно обновлять, менять, усовершенствовать, что дает возможность производителям иметь постоянный доход от продаж.
    Современное усовершенствованное оборудование позволяет увеличить скорость подключения внутри сети, передавать большие объемы данных, увеличить пропускную способность сети, предоставлять дополнительные услуги (несколько одновременных подключений к точке обмена, передача видео, голосовых сигналов и т.п., конвертация трафика – зарабатывание на нем) и проч.
    Минимальный набор оборудования для создания точки обмена состоит из нескольких серверов и большого числа коммутаторов и маршрутизаторов (количество элементов зависит от размера точки обмена и количества участников сети). Провайдеры, которые присоединяются к сети, подключаются к порту ближайшего коммутатора по протоколу Ethernet.
    Среди ведущих производителей оборудования для точек обмена трафиком – Extreme Networks, Cisco Systems, Brocade и др.
    Точки обмена трафиком — очень позитивный шаг в развитии Интернет-рынка РФ. Преимущества получили все игроки данного рынка (все звенья): конечные потребители, российские провайдеры, иностранные компании-поставщики трафика, производители оборудования, разработчики приложений и ПО (как отечественные, так и иностранные) и российские специалисты в области Интернет-технологий (которые получили достойную работу).
    Но обмен Интернет-трафиком в России имеет и свои недостатки. В частности, растущее потребление трафика Интернет-пользователями заставляет провайдеров закупать все больше трафика, ограничивать его потребление, отказываться от безлимитных тарифов и т.п. Многие операторы уже перешли на погигабайтную оплату, причины этого – чисто технические. Дело в том, что точки обмена, как и локальные сети провайдеров, разрослись до таких размеров, когда сложно разделять трафик на категории и отдельно считать каждую из категорий. Намного проще, дешевле и технически доступнее считать общее количество потребленного трафика на порту.
    Более того, подключиться к самой популярной и крупной в РФ сети провайдеров MSK-IX с каждым годом все труднее. В настоящее время уже сформировался целый ряд условий, которым операторы вынуждены соответствовать. И основным критерием здесь является объем потребления трафика (а соответственно, количество абонентов): от 500-1000 ГБ/мес.
    При всем этом производительность современных компьютерных систем за 2 года удваивается, а потребление трафика за этот же период увеличивается в 4 раза. И рынку обмена трафиком приходится поспевать за этими показателям, развиваться быстрее, изменять методы работы.
    Поэтому рынок обмена трафиком в России имеет не такие радужные реальность и перспективы, как это может показаться на первый взгляд. Безусловно, эта отрасль стимулировала развитие всего Интернет-рынка РФ и привела к тому уровню, который существует в нашей стране на сегодняшний день. Но как рынок обмена трафиком будет развиваться дальше, пока сложно сказать. Значительное увеличение затрат на закупку трафика, транзит его, организацию инфраструктуры, увеличение числа каналов и расширение их пропускной способности и проч. заставляет многих операторов задуматься над тем, что делать дальше, как удешевить услуги и минимизировать затраты, как провести безболезненную оптимизацию работы данной отрасли.

  • DDOS атаки на маршрутизатор и методы защиты Juniper routing engine

    По долгу службы мне часто приходится сталкиваться с DDOS на сервера, но некоторое время назад столкнулся с другой атакой, к которой был не готов. Атака производилась на маршрутизатор Juniper MX80 поддерживающий BGP сессии и выполняющий анонс сетей дата-центра. Целью атакующих был веб-ресурс расположенный на одном из наших серверов, но в результате атаки, без связи с внешним миром остался весь дата-центр. Подробности атаки, а также тесты и методы борьбы с такими атаками под катом. 

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


    Исторически сложилось, что на маршрутизаторе блокируется весь UDP трафик летящий в нашу сеть. Первая волна атаки (в 17:22) была как раз UDP трафиком, график unicast пакетов с аплинка маршрутизатора:

    график unicast пакетов с аплинка маршрутизатора
    и график unicast пакетов с порта свича подключенного к роутеру:
    график unicast пакетов с порта свича подключенного к роутеру

    демонстрируют, что весь трафик осел на фильтре маршрутизатора. Поток unicast пакетов на аплинке маршрутизатора увеличился на 400 тысяч и атака только UDP пакетами продолжалась до 17:33. Далее атакующие изменили стратегию и добавили к атаке UDP еще и атаку TCP SYN пакетами на атакуемый сервер, а также на сам маршрутизатор. Как видно по графику, маршрутизатору стало настолько плохо, что он перестал отдавать SNMP в zabbix. После волны SYN на порты маршрутизатора стали отваливаться BGP сессии с пирами (используется три аплинка с каждого получаем full view по ipv4 и по ipv6), в логах появились трагические записи:

    Jun 27 17:35:07 ROUTER rpd[1408]: bgp_hold_timeout:4035: NOTIFICATION sent to ip.ip.ip.ip (External AS 1111): code 4 (Hold Timer Expired Error), Reason: holdtime expired for ip.ip.ip.ip (External AS 1111), socket buffer sndcc: 19 rcvcc: 0 TCP state: 4, snd_una: 1200215741 snd_nxt: 1200215760 snd_wnd: 15358 rcv_nxt: 4074908977 rcv_adv: 4074925361, hold timer out 90s, hold timer remain 0s
    Jun 27 17:35:33 ROUTER rpd[1408]: bgp_hold_timeout:4035: NOTIFICATION sent to ip.ip.ip.ip (External AS 1111): code 4 (Hold Timer Expired Error), Reason: holdtime expired for ip.ip.ip.ip (External AS 1111), socket buffer sndcc: 38 rcvcc: 0 TCP state: 4, snd_una: 244521089 snd_nxt: 244521108 snd_wnd: 16251 rcv_nxt: 3829118827 rcv_adv: 3829135211, hold timer out 90s, hold timer remain 0s
    Jun 27 17:37:26 ROUTER rpd[1408]: bgp_hold_timeout:4035: NOTIFICATION sent to ip.ip.ip.ip (External AS 1111): code 4 (Hold Timer Expired Error), Reason: holdtime expired for ip.ip.ip.ip (External AS 1111), socket buffer sndcc: 19 rcvcc: 0 TCP state: 4, snd_una: 1840501056 snd_nxt: 1840501075 snd_wnd: 16384 rcv_nxt: 1457490093 rcv_adv: 1457506477, hold timer out 90s, hold timer remain 0s


    Как было выяснено позже, после атаки, волна TCP SYN увеличила нагрузку на routing engine маршрутизатора после чего упали все BGP сессии и маршрутизатор не смог самостоятельно восстановить работу. Атака на маршрутизатор длилась несколько минут, но из-за дополнительной нагрузки, маршрутизатор не мог обработать full view с трех аплинков и сессии снова рвались. Восстановить работу удалось только поочередным поднятием всех BGP сессий. Дальнейшая атака шла на сам сервер.

    Испытание в условиях стенда и воспроизведение атаки


    В качестве цели атаки использовался Juniper MX80 с той же версией прошивки, что и на боевом роутере. В качестве атакующего использовался сервер с 10Gb картой и установленной на нем ubuntu server + quagga. Генератором трафика выступал скрипт с вызовом утилиты hping3. Для проверки пагубного воздействия “всплесков” трафика, скрипт генерировал трафик с временными разрывами: 30 секунд атака — 2 секунды атаки нет. Также, для чистоты эксперимента, была поднята BGP сессия между маршрутизатором и сервером. В установленной на тот момент конфигурации боевого маршрутизатора, порты BGP и SSH были открыты на всех интерфейсах/адресах маршрутизатора и не фильтровались. Аналогичная конфигурация была перенесена на стендовый маршрутизатор.

    Первым этапом испытаний стала атака TCP SYN на BGP (179) порт маршрутизатора. IP адрес источника совпадал с адресом пира в конфигурации маршрутизатора. IP address spoofing не исключался, так как у наших аплинков не включен uPRF. Сессия была установлена. Со стороны quagga:

    BGP router identifier 9.4.8.2, local AS number 9123
    RIB entries 3, using 288 bytes of memory
    Peers 1, using 4560 bytes of memory

    Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
    9.4.8.1       4  1234    1633    2000        0    0    0 00:59:56        0

    Total number of neighbors 1


    Со стороны Juniper:

    user@MX80> show bgp summary 
    Groups: 1 Peers: 1 Down peers: 0
    Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
    inet.0               
                           2          1          0          0          0          0
    Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
    9.4.8.2              4567        155        201       0     111       59:14 1/2/2/0              0/0/0/0


    После начала атаки (13:52) на маршрутизатор летит ~1.2 Mpps трафика:
    на маршрутизатор летит ~1.2 Mpps трафика

    или 380Mbps:
    на маршрутизатор летит 380 Mpps трафика
    Нагрузка на CPU RE и CPU FE маршрутизатора возрастает:
    Нагрузка на CPU RE и CPU FE маршрутизатора возрастает
    После задержки (90 сек) BGP сессия падает и больше не поднимается:

    Jul 4 13:54:01 MX80 rpd[1407]: bgp_hold_timeout:4035: NOTIFICATION sent to 9.4.8.2 (External AS 4567): code 4 (Hold Timer Expired Error), Reason: holdtime expired for 9.4.8.2 (External AS 4567), socket buffer sndcc: 38 rcvcc: 0 TCP state: 4, snd_una: 3523671294 snd_nxt: 3523671313 snd_wnd: 114 rcv_nxt: 1556791630 rcv_adv: 1556808014, hold timer out 90s, hold timer remain 0s


    Маршрутизатор занят обработкой прилетающего TCP SYN на порт BGP и не может установить сессию. На порту множество пакетов:

    user@MX80> monitor traffic interface ge-1/0/0 count 20 
    13:55:39.219155 In IP 9.4.8.2.2097 > 9.4.8.1.bgp: S 1443462200:1443462200(0) win 512
    13:55:39.219169 In IP 9.4.8.2.27095 > 9.4.8.1.bgp: S 295677290:295677290(0) win 512
    13:55:39.219177 In IP 9.4.8.2.30114 > 9.4.8.1.bgp: S 380995480:380995480(0) win 512
    13:55:39.219184 In IP 9.4.8.2.57280 > 9.4.8.1.bgp: S 814209218:814209218(0) win 512
    13:55:39.219192 In IP 9.4.8.2.2731 > 9.4.8.1.bgp: S 131350916:131350916(0) win 512
    13:55:39.219199 In IP 9.4.8.2.2261 > 9.4.8.1.bgp: S 2145330024:2145330024(0) win 512
    13:55:39.219206 In IP 9.4.8.2.z39.50 > 9.4.8.1.bgp: S 1238175350:1238175350(0) win 512
    13:55:39.219213 In IP 9.4.8.2.2098 > 9.4.8.1.bgp: S 1378645261:1378645261(0) win 512
    13:55:39.219220 In IP 9.4.8.2.30115 > 9.4.8.1.bgp: S 1925718835:1925718835(0) win 512
    13:55:39.219227 In IP 9.4.8.2.27096 > 9.4.8.1.bgp: S 286229321:286229321(0) win 512
    13:55:39.219235 In IP 9.4.8.2.2732 > 9.4.8.1.bgp: S 1469740166:1469740166(0) win 512
    13:55:39.219242 In IP 9.4.8.2.57281 > 9.4.8.1.bgp: S 1179645542:1179645542(0) win 512
    13:55:39.219254 In IP 9.4.8.2.2262 > 9.4.8.1.bgp: S 1507663512:1507663512(0) win 512
    13:55:39.219262 In IP 9.4.8.2.914c/g > 9.4.8.1.bgp: S 1219404184:1219404184(0) win 512
    13:55:39.219269 In IP 9.4.8.2.2099 > 9.4.8.1.bgp: S 577616492:577616492(0) win 512
    13:55:39.219276 In IP 9.4.8.2.267 > 9.4.8.1.bgp: S 1257310851:1257310851(0) win 512
    13:55:39.219283 In IP 9.4.8.2.27153 > 9.4.8.1.bgp: S 1965427542:1965427542(0) win 512
    13:55:39.219291 In IP 9.4.8.2.30172 > 9.4.8.1.bgp: S 1446880235:1446880235(0) win 512
    13:55:39.219297 In IP 9.4.8.2.57338 > 9.4.8.1.bgp: S 206377149:206377149(0) win 512
    13:55:39.219305 In IP 9.4.8.2.2789 > 9.4.8.1.bgp: S 838483872:838483872(0) win 512


    Вторым этапом испытаний стала атака TCP SYN на BGP (179) порт маршрутизатора. IP адрес источника выбирался случайно и не совпадал с адресом пира указанным в конфигурации маршрутизатора. Эта атака произвела на маршрутизатор такой же эффект. Дабы не растягивать статью однообразными выводами логов, приведу только график нагрузки:

    график нагрузки CPU

    По графику отчетливо видно момент начала атаки. BGP сессия также упала и не смогла восстановиться.

    Концепция построения защиты RE маршрутизатора


    Особенность работы оборудования Juniper заключается в разделении задач между routing engine (RE) и packet forwarding engine (PFE). PFE обрабатывает весь поток проходящего трафика осуществляя его фильтрацию и маршрутизацию по заранее сформированной схеме. RE занимается обработкой прямых обращений к маршрутизатору (traceroute, ping, ssh), обработкой пакетов для служб BGP, NTP, DNS, SNMP и формирует схемы фильтрации и маршрутизации трафика для PFE маршрутизатора. 

    Основная идея защиты маршрутизатора состоит в фильтрации всего трафика предназначенного для RE. Создание фильтра позволит перенести нагрузку, создаваемую DDOS атакой, с CPU RE на CPU PFE маршрутизатора, что даст возможность RE обрабатывать только реальные пакеты и не тратить процессорное время на другой трафик. Для построения защиты необходимо определить, что фильтруем. Схема написания фильтров для IPv4 была взята из книги Douglas Hanks Jr. — Day One Book: Securing the Routing Engine on M, MX and T series. В моем случае на маршрутизаторе схема была следующей:

    По протоколу IPv4

    • BGP — фильтруем пакеты по source и destination ip, source ip может быть любой из списка bgp neighbor. Разрешаем только подключения tcp established, то есть фльтр будет отбрасывать все SYN прилетающие на этот порт, а сессия BGP будет начинаться только от нас (BGP сосед аплинка работает в пассивном режиме).
    • TACACS+ — фильтруем пакеты по source и destination ip, source ip может быть только из внутренней сети. Ограничиваем полосу пропускания в 1Mb/s.
    • SNMP — фильтруем пакеты по source и destination ip, source ip может быть любой из списка snmp-clients в конфигурации.
    • SSH — фильтруем пакеты по destination ip, source ip может быть любой, так как есть необходимость экстренного доступа к устройству из любой сети. Ограничиваем полосу пропускания в 5Mb/s.
    • NTP — фильтруем пакеты по source и destination ip, source ip может быть любой из списка ntp servers конфигурации. Ограничиваем полосу пропускания в 1Mb/s (в дальнейшем порог был уменьшен до 512Kb/s).
    • DNS — фильтруем пакеты по source и destination ip, source ip может быть любой из списка dns servers конфигурации. Ограничиваем полосу пропускания в 1Mb/s.
    • ICMP — фильтруем пакеты, пропускаем только на адреса принадлежащие маршрутизатору. Ограничиваем полосу пропускания в 5Mb/s (в дальнейшем порог был уменьшен до 1Mb/s).
    • TRACEROUTE — фильтруем пакеты, пропускаем только пакеты с TTL равным 1 и только на адреса принадлежащие маршрутизатору. Ограничиваем полосу пропускания в 1Mb/s.


    По протоколу IPv6, в моем случае, фильтры накладывались только на BGP, NTP, ICMP, DNS и traceroute. Единственное отличие в фильтрации ICMP трафика, так как IPv6 использует ICMP в служебных целях. Остальные протоколы не использовали IPv6 адресацию. 

    Написание конфигурации


    Для написания фильтров в juniper существует удобный инструмент — prefix-list, который позволяет динамически составлять списки ip адресов/подсетей для подстановки в фильтры. Например, для создания списка адресов ipv4 BGP соседей указанных в конфигурации, используется следующая структура:

    prefix-list BGP-neighbors-v4 {
             apply-path "protocols bgp group <*> neighbor <*.*>";
    }


    результат составления списка:

    show configuration policy-options prefix-list BGP-neighbors-v4 | display inheritance 
    ##
    ## apply-path was expanded to:
    ## 1.1.1.1/32;
    ## 2.2.2.2/32;
    ## 3.3.3.3/32;
    ##
    apply-path «protocols bgp group <*> neighbor <*.*>»;


    Составляем динамические списки префиксов для всех фильтров:


    /* Список всех ipv4 адресов соседей BGP  */
    prefix-list BGP-neighbors-v4 {
        apply-path "protocols bgp group <*> neighbor <*.*>";
    }
    /* Список всех ipv6 адресов соседей BGP  */
    prefix-list BGP-neighbors-v6 {
        apply-path "protocols bgp group <*> neighbor <*:*>";
    }
    /* Список всех ipv4 серверов NTP  */
    prefix-list NTP-servers-v4 {
        apply-path "system ntp server <*.*>";
    }
    /* Список всех ipv6 серверов NTP  */
    prefix-list NTP-servers-v6 {
        apply-path "system ntp server <*:*>";
    }
    /* Список всех ipv4 адресов назначеных роутеру  */
    prefix-list LOCALS-v4 {
        apply-path "interfaces <*> unit <*> family inet address <*>";
    }
    /* Список всех ipv6 адресов назначеных роутеру  */
    prefix-list LOCALS-v6 {
        apply-path "interfaces <*> unit <*> family inet6 address <*>";
    }
    /* Список всех ipv4 адресов SNMP клиентов */
    prefix-list SNMP-clients {
        apply-path "snmp client-list <*> <*>";
    }
    prefix-list SNMP-community-clients {
        apply-path "snmp community <*> clients <*>";
    }
    /* Список всех серверов TACACS+  */
    prefix-list TACPLUS-servers {
        apply-path "system tacplus-server <*>";
    }
    /* Список адресов роутера которые принадлежат внутренней сети  */
    prefix-list INTERNAL-locals {
        /* В моем случае лучший вариант - ручное указание адреса  */
        192.168.0.1/32;
    }
    /* Список адресов роутера на интерфейсе управления, для доступа по SSH */
    prefix-list MGMT-locals {
        apply-path "interfaces fxp0 unit 0 family inet address <*>";
    }
    /* Приватные сети  */
    prefix-list rfc1918 {
        10.0.0.0/8;
        172.16.0.0/12;
        192.168.0.0/16;
    }
    /* Loopback  */
    prefix-list localhost-v6 {
        ::1/128;
    }
    prefix-list localhost-v4 {
        127.0.0.0/8;
    }
    /* Список всех ipv4 локальных адресов BGP  */
    prefix-list BGP-locals-v4 {
        apply-path "protocols bgp group <*> neighbor <*.*> local-address <*.*>";
    }
    /* Список всех ipv6 локальных адресов BGP  */
    prefix-list BGP-locals-v6 {
        apply-path "protocols bgp group <*> neighbor <*:*> local-address <*:*>";
    }  
    /* Список всех ipv4 серверов DNS  */                                     
    prefix-list DNS-servers-v4 {
        apply-path "system name-server <*.*>";
    }
    /* Список всех ipv6 серверов DNS  */      
    prefix-list DNS-servers-v6 {
        apply-path "system name-server <*:*>";
    }


    Составляем политики для ограничения пропускной способности:

    /* Ограничение в 1Mb */
    policer management-1m {
        apply-flags omit;
        if-exceeding {
            bandwidth-limit 1m;
            burst-size-limit 625k;
        }
        /* Все что не помещается дропаем */
        then discard;
    }
    /* Ограничение в 5Mb */
    policer management-5m {
        apply-flags omit;
        if-exceeding {
            bandwidth-limit 5m;
            burst-size-limit 625k;
        }
        /* Все что не помещается дропаем */
        then discard;
    }
    /* Ограничение в 512Kb */
    policer management-512k {
        apply-flags omit;
        if-exceeding {
            bandwidth-limit 512k;
            burst-size-limit 25k;
        }
        /* Все что не помещается дропаем */
        then discard;
    }


    Ниже, под «копи-паст», конфигурация фильтров конечного варианта защиты (были уменьшены пороги пропускной способности трафика NTP и ICMP, причины снижения порогов подробно описаны в разделе тестирования). Настраиваем фильтры ipv4:

    IPv4 filter


    Аналогичный фильтр для ipv6:

    IPv6 filter


    Далее необходимо применить фильтры на служебный интерфейс lo0.0. В системе JunOS этот интерфейс используется для передачи данных между PFE и RE. Конфигурация примет следующий вид:

    lo0 {
        unit 0 {
            family inet {
                filter {
                    input-list [ accept-bgp accept-common-services discard-all ];
                }
            }
            family inet6 {
                filter {
                    input-list [ accept-v6-bgp accept-v6-common-services discard-v6-all ];
                }
            }
        }
    }


    Порядок указания фильтров в input-list интерфейса очень важен. Каждый пакет будет проверяться на валидность проходя по фильтрам указанным в input-list слева направо.

    Тестирование фильтров


    После применения фильтров, провел ряд тестов на том же стенде. После каждого теста выполнялась очистка счетчиков firewall. Нормальная (без атаки) нагрузка на роутере видна на графиках в 11:06 — 11:08. График pps за весь период тестов:
    pps за весь период тестов
    График CPU за весь период тестов:
    график CPU за весь период тестов

    Первым проводился тест флуда icmp c порогом трафика 5Мб/с (на графиках 10:21 — 10:24). По счетчикам фильтра и на графике видно ограничение по трафика по пропускной способности, но даже этого потока было достаточно для повышения нагрузки, поэтому порог был уменьшен до 1Мб/с. Счетчики:

    Filter: lo0.0-i                                                
    Counters:
    Name                                                Bytes              Packets
    accept-bgp-lo0.0-i                                      0                    0
    accept-icmp-lo0.0-i                              47225584              1686628
    accept-ntp-lo0.0-i                                    152                    2
    accept-snmp-lo0.0-i                                174681                 2306
    accept-ssh-lo0.0-i                                  38952                  702
    accept-traceroute-icmp-lo0.0-i                          0                    0
    accept-traceroute-tcp-lo0.0-i                         841                   13
    accept-traceroute-udp-lo0.0-i                           0                    0
    discard-TTL_1-unknown-lo0.0-i                           0                    0
    discard-icmp-lo0.0-i                                    0                    0
    discard-icmp-fragments-lo0.0-i                          0                    0
    discard-ip-options-lo0.0-i                              0                    0
    discard-tcp-lo0.0-i                                   780                   13
    discard-udp-lo0.0-i                                 18743                  133
    discard-unknown-lo0.0-i                                 0                    0
    Policers:
    Name                                                Bytes              Packets
    management-1m-accept-ntp-lo0.0-i                        0                    0
    management-1m-accept-traceroute-icmp-lo0.0-i                    0                    0
    management-1m-accept-traceroute-tcp-lo0.0-i                    0                    0
    management-1m-accept-traceroute-udp-lo0.0-i                    0                    0
    management-5m-accept-icmp-lo0.0-i               933705892             33346639
    management-5m-accept-ssh-lo0.0-i                        0                    0


    Повторный тест флуда icmp c порогом трафика 1Мб/с (на графиках 10:24 — 10:27). Нагрузка на RE роутера упала с 19% до 10%, нагрузка на PFE до 30%. Счетчики:

    Filter: lo0.0-i                                                
    Counters:
    Name                                                Bytes              Packets
    accept-bgp-lo0.0-i                                      0                    0
    accept-icmp-lo0.0-i                               6461448               230766
    accept-ntp-lo0.0-i                                      0                    0
    accept-snmp-lo0.0-i                                113433                 1497
    accept-ssh-lo0.0-i                                  33780                  609
    accept-traceroute-icmp-lo0.0-i                          0                    0
    accept-traceroute-tcp-lo0.0-i                           0                    0
    accept-traceroute-udp-lo0.0-i                           0                    0
    discard-TTL_1-unknown-lo0.0-i                           0                    0
    discard-icmp-lo0.0-i                                    0                    0
    discard-icmp-fragments-lo0.0-i                          0                    0
    discard-ip-options-lo0.0-i                              0                    0
    discard-tcp-lo0.0-i                                   360                    6
    discard-udp-lo0.0-i                                 12394                   85
    discard-unknown-lo0.0-i                                 0                    0
    Policers:
    Name                                                Bytes              Packets
    management-1m-accept-icmp-lo0.0-i               665335496             23761982
    management-1m-accept-ntp-lo0.0-i                        0                    0
    management-1m-accept-traceroute-icmp-lo0.0-i                    0                    0
    management-1m-accept-traceroute-tcp-lo0.0-i                    0                    0
    management-1m-accept-traceroute-udp-lo0.0-i                    0                    0
    management-5m-accept-ssh-lo0.0-i                        0                    0


    Следующим был проведен тест флуда на порт BGP роутера с постороннего (не включеного в конфиг) ip адреса (на графиках 10:29 — 10:36). Как видно из счетчиков, весь флуд осел на discard-tcp фильтре RE и лишь увеличил нагрузку на PFE. Нагрузка на RE не изменилась. Счетчики:

    Filter: lo0.0-i                                                
    Counters:
    Name                                                Bytes              Packets
    accept-bgp-lo0.0-i                                      824                    26
    accept-icmp-lo0.0-i                                     0                    0
    accept-ntp-lo0.0-i                                      0                    0
    accept-snmp-lo0.0-i                                560615                 7401
    accept-ssh-lo0.0-i                                  33972                  585
    accept-traceroute-icmp-lo0.0-i                          0                    0
    accept-traceroute-tcp-lo0.0-i                        1088                   18
    accept-traceroute-udp-lo0.0-i                           0                    0
    discard-TTL_1-unknown-lo0.0-i                           0                    0
    discard-icmp-lo0.0-i                                    0                    0
    discard-icmp-fragments-lo0.0-i                          0                    0
    discard-ip-options-lo0.0-i                              0                    0
    discard-tcp-lo0.0-i                           12250785600            306269640
    discard-udp-lo0.0-i                                 63533                  441
    discard-unknown-lo0.0-i                                 0                    0
    Policers:
    Name                                                Bytes              Packets
    management-1m-accept-icmp-lo0.0-i                       0                    0
    management-1m-accept-ntp-lo0.0-i                        0                    0
    management-1m-accept-traceroute-icmp-lo0.0-i                    0                    0
    management-1m-accept-traceroute-tcp-lo0.0-i                    0                    0
    management-1m-accept-traceroute-udp-lo0.0-i                    0                    0
    management-5m-accept-ssh-lo0.0-i                        0                    0


    сессия не падает:

    user@MX80# run show bgp summary                
    Groups: 1 Peers: 1 Down peers: 0
    Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
    inet.0               
                           2          1          0          0          0          0
    Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
    9.4.8.2              4567         21         22       0      76        8:49 1/2/2/0              0/0/0/0


    Четвертым был проведен тест флуда (на графиках 10:41 — 10:46) UDP на порт NTP (в настройках фильтра взаимодействие по этому порту ограничивается серверами указанными в конфиге роутера). По графику, нагрузка поднимается только на PFE роутера до 28%. Счетчики:

    Filter: lo0.0-i                                                
    Counters:
    Name                                                Bytes              Packets
    accept-bgp-lo0.0-i                                      0                    0
    accept-icmp-lo0.0-i                                     0                    0
    accept-ntp-lo0.0-i                                      0                    0
    accept-snmp-lo0.0-i                                329059                 4344
    accept-ssh-lo0.0-i                                  22000                  388
    accept-traceroute-icmp-lo0.0-i                          0                    0
    accept-traceroute-tcp-lo0.0-i                         615                   10
    accept-traceroute-udp-lo0.0-i                           0                    0
    discard-TTL_1-unknown-lo0.0-i                           0                    0
    discard-icmp-lo0.0-i                                    0                    0
    discard-icmp-fragments-lo0.0-i                          0                    0
    discard-ip-options-lo0.0-i                              0                    0
    discard-tcp-lo0.0-i                                     0                    0
    discard-udp-lo0.0-i                            1938171670             69219329
    discard-unknown-lo0.0-i                                 0                    0
    Policers:
    Name                                                Bytes              Packets
    management-1m-accept-icmp-lo0.0-i                       0                    0
    management-1m-accept-ntp-lo0.0-i                        0                    0
    management-1m-accept-traceroute-icmp-lo0.0-i                    0                    0
    management-1m-accept-traceroute-tcp-lo0.0-i                    0                    0
    management-1m-accept-traceroute-udp-lo0.0-i                    0                    0
    management-5m-accept-ssh-lo0.0-i                        0                    0


    Пятым был проведен тест флуда (на графиках 10:41 — 11:04) UDP на порт NTP с IP spoofing. Нагрузка на RE увеличилась на 12%, нагрузка на PFE увеличилась до 22%. По счетчикам видно, что флуд упирается в порог 1Мб/с, но этого достаточно для повышения нагрузки на RE. Порог трафика в итоге был уменьшен до 512Кб/с. Счетчики:

    Filter: lo0.0-i                                                
    Counters:
    Name                                                Bytes              Packets
    accept-bgp-lo0.0-i                                      0                    0
    accept-icmp-lo0.0-i                                     0                    0
    accept-ntp-lo0.0-i                               34796804              1242743
    accept-snmp-lo0.0-i                                630617                 8324
    accept-ssh-lo0.0-i                                  20568                  366
    accept-traceroute-icmp-lo0.0-i                          0                    0
    accept-traceroute-tcp-lo0.0-i                        1159                   19
    accept-traceroute-udp-lo0.0-i                           0                    0
    discard-TTL_1-unknown-lo0.0-i                           0                    0
    discard-icmp-lo0.0-i                                    0                    0
    discard-icmp-fragments-lo0.0-i                          0                    0
    discard-ip-options-lo0.0-i                              0                    0
    discard-tcp-lo0.0-i                                     0                    0
    discard-udp-lo0.0-i                                 53365                  409
    discard-unknown-lo0.0-i                                 0                    0
    Policers:
    Name                                                Bytes              Packets
    management-1m-accept-icmp-lo0.0-i                       0                    0
    management-1m-accept-ntp-lo0.0-i               3717958468            132784231
    management-1m-accept-traceroute-icmp-lo0.0-i                    0                    0
    management-1m-accept-traceroute-tcp-lo0.0-i                    0                    0
    management-1m-accept-traceroute-udp-lo0.0-i                    0                    0
    management-5m-accept-ssh-lo0.0-i                        0                    0


    Повторный тест флуда (на графике ниже 11:29 — 11:34) UDP на порт NTP с IP spoofing, но с порогом трафика 512Кб/с. График нагрузки:
    график нагрузки CPU
    Счетчики:

    Filter: lo0.0-i                                                
    Counters:
    Name                                                Bytes              Packets
    accept-bgp-lo0.0-i                                      0                    0
    accept-icmp-lo0.0-i                                     0                    0
    accept-ntp-lo0.0-i                               21066260               752363
    accept-snmp-lo0.0-i                                744161                 9823
    accept-ssh-lo0.0-i                                  19772                  347
    accept-traceroute-icmp-lo0.0-i                          0                    0
    accept-traceroute-tcp-lo0.0-i                        1353                   22
    accept-traceroute-udp-lo0.0-i                           0                    0
    discard-TTL_1-unknown-lo0.0-i                           0                    0
    discard-icmp-lo0.0-i                                    0                    0
    discard-icmp-fragments-lo0.0-i                          0                    0
    discard-ip-options-lo0.0-i                              0                    0
    discard-tcp-lo0.0-i                                     0                    0
    discard-udp-lo0.0-i                                 82745                  602
    discard-unknown-lo0.0-i                                 0                    0
    Policers:
    Name                                                Bytes              Packets
    management-1m-accept-icmp-lo0.0-i                       0                    0
    management-1m-accept-traceroute-icmp-lo0.0-i                    0                    0
    management-1m-accept-traceroute-tcp-lo0.0-i                    0                    0
    management-1m-accept-traceroute-udp-lo0.0-i                    0                    0
    management-512k-accept-ntp-lo0.0-i             4197080384            149895728
    management-5m-accept-ssh-lo0.0-i                        0                    0


    Заключение


    В итоге всех проведенных тестов удалось получить, устойчивую к DDOS атакам, конфигурацию фильтров трафика RE. В настоящий момент эта конфигурация уже применена на боевом роутере и проблем не выявлено. По счетчикам с боевого MX80:

    Filter: lo0.0-i                                                
    Counters:
    Name                                                Bytes              Packets
    accept-v6-bgp-lo0.0-i                            31091878               176809
    accept-v6-icmp-lo0.0-i                            1831144                26705
    accept-v6-ntp-lo0.0-i                                   0                    0
    accept-v6-traceroute-icmp-lo0.0-i                       0                    0
    accept-v6-traceroute-tcp-lo0.0-i                    48488                  684
    accept-v6-traceroute-udp-lo0.0-i                        0                    0
    discard-v6-icmp-lo0.0-i                                 0                    0
    discard-v6-tcp-lo0.0-i                                  0                    0
    discard-v6-udp-lo0.0-i                                  0                    0
    discard-v6-unknown-lo0.0-i                              0                    0
    Policers:
    Name                                                Bytes              Packets
    management-1m-accept-v6-icmp-lo0.0-i                    0                    0
    management-1m-accept-v6-traceroute-icmp-lo0.0-i                    0                    0
    management-1m-accept-v6-traceroute-tcp-lo0.0-i                    0                    0
    management-1m-accept-v6-traceroute-udp-lo0.0-i                    0                    0
    management-512k-accept-v6-ntp-lo0.0-i                    0                    0

    Filter: lo0.0-i                                                
    Counters:
    Name                                                Bytes              Packets
    accept-bgp-lo0.0-i                              135948400               698272
    accept-dns-lo0.0-i                                    374                    3
    accept-icmp-lo0.0-i                             121304849              1437305
    accept-ntp-lo0.0-i                                  87780                 1155
    accept-snmp-lo0.0-i                            1265470648             12094967
    accept-ssh-lo0.0-i                                2550011                30897
    accept-tacacs-lo0.0-i                              702450                11657
    accept-traceroute-icmp-lo0.0-i                      28824                  636
    accept-traceroute-tcp-lo0.0-i                       75378                 1361
    accept-traceroute-udp-lo0.0-i                       47328                 1479
    discard-TTL_1-unknown-lo0.0-i                       27790                  798
    discard-icmp-lo0.0-i                                26400                  472
    discard-icmp-fragments-lo0.0-i                          0                    0
    discard-ip-options-lo0.0-i                          35680                 1115
    discard-tcp-lo0.0-i                              73399674              1572144
    discard-udp-lo0.0-i                             126386306               694603
    discard-unknown-lo0.0-i                                 0                    0
    Policers:
    Name                                                Bytes              Packets
    management-1m-accept-dns-lo0.0-i                        0                    0
    management-1m-accept-icmp-lo0.0-i                   38012                  731
    management-1m-accept-tacacs-lo0.0-i                     0                    0
    management-1m-accept-traceroute-icmp-lo0.0-i                    0                    0
    management-1m-accept-traceroute-tcp-lo0.0-i                    0                    0
    management-1m-accept-traceroute-udp-lo0.0-i                    0                    0
    management-512k-accept-ntp-lo0.0-i                      0                    0
    management-5m-accept-ssh-lo0.0-i                        0                    0


    видно какое количество “левого” трафика оседает на фильтре discard.

    Буду рад ответить на все вопросы в комментариях.

  • Конфігурації мережного устаткування зазвичай забувають видалити за його продажу

    Конфігурації мережного устаткування зазвичай забувають видалити за його продажу

    Аналітики з компанії ESET виявили, що після придбання уживаного маршрутизатора на пристрої нерідко можна виявити забуті конфіденційні дані. Такі дані можуть бути використані для проникнення в корпоративні середовища або отримання інформації про клієнтів.

    Це дослідження почалося з того, що компанія ESET придбала кілька маршрутизаторів для створення тестового середовища, але виявилося, що куплені пристрої не були очищені належним чином і досі містять дані про конфігурацію мережі, а також інформацію, що дозволяє ідентифікувати їх попередніх власників.

    Серед придбаного обладнання було чотири пристрої Cisco (ASA 5500), три Fortinet (серія Fortigate) та 11 девайсів Juniper Networks (SRX Series Services Gateway).

    Загалом дослідники придбали з рук 18 вживаних пристроїв корпоративного рівня. З’ясувалося, що ці зміни, як і раніше, доступні більш ніж на половині з них, і вони все ще актуальні.

    Один пристрій виявився непрацюючим (після чого його виключили з випробувань), а ще два були дзеркалами один одного, і в результаті їх порахували як один. З 16 пристроїв, що залишилися, тільки 5 були очищені належним чином і тільки 2 мали хоч якийсь захист, що ускладнювало доступ до деяких даних.

    На жаль, в більшості випадків на пристроях можна було отримати доступ до повних даних конфігурації, тобто дізнатися безліч подробиць про колишнього власника, як він налаштував мережу, а також про з’єднання між іншими системами.

    Найгірше, деякі з маршрутизаторів зберігали навіть інформацію про клієнтів, дані, які дозволяли сторонньому підключитися до мережі, і навіть «облікові дані для підключення до інших мереж як довірена сторона».

    Крім того, 8 з 9 маршрутизаторів, які розкривали повні дані конфігурації, також містили ключі та хеші для автентифікації між маршрутизаторами. У результаті список корпоративних секретів розширювався до повної «карти» важливих додатків, розміщених локально або у хмарі (включаючи Microsoft Exchange, Salesforce, SharePoint, Spiceworks, VMware Horizon та SQL).

    «З таким рівнем деталізації зловмиснику буде набагато простіше видати себе за мережеві або внутрішні вузли, тим більше що на пристроях часто зберігаються облікові дані VPN або інші токени автентифікації, що легко компрометуються», — пишуть експерти.

    Також, судячи з даних, виявлених у куплених маршрутизаторах, деякі з них раніше працювали в середовищі managed-провайдерів, які обслуговують мережі великих компаній. Наприклад, один девайс взагалі належав постачальнику MSSP (Managed Security Service Provider), який обслуговував мережі сотень клієнтів у різних галузях (освіта, фінанси, охорона здоров’я, виробництво тощо).

    Наводячи цей яскравий приклад, дослідники вкотре нагадують, наскільки важливо правильно очищати мережеві пристрої перед продажем. У компаніях повинні існувати процедури безпечного знищення та утилізації цифрового обладнання. Також експерти зазначають, що використання сторонніх сервісів для цих потреб не є гарною ідеєю. Справа в тому, що повідомивши одного з колишніх власників пристроїв про проблему, дослідники дізналися, що для утилізації обладнання компанія користувалася послугами такого стороннього сервісу. «Щось явно пішло не за планом», — резюмують аналітики.