Метка: нелегальный майнинг

  • Как работают точки обмена интернет 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.

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

  • Нелегальный майнинг криптовалюты задаёт тренд на площадках процессинга

    Нелегальный майнинг криптовалюты задаёт тренд на площадках процессинга

    Европейский центр по борьбе с киберпреступностью при Европоле опубликовал футурологический прогноз

    c описанием возможных сценариев развития нелегальной киберактивности в Европе. Прогнозы выглядят довольно мрачно. По мнению специалистов, нальщики и дроповоды смогут взламывать огромное количество устройств — автомобили, медицинские приборы, имплантаты или беспилотные летательные аппараты.

    103 USD за 11 кликов

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

    Новые типы компьютерных атак и смежных активностей

    • Рынок скрэмблеров для распознавания настроения пользователей, симуляции дистанционного присутствия, технологии Near Field Communication
    • Сильно распределенные DoS-атаки через облачные сервисы
    • Переход от ботнетов на устройствах к облачным ботнетам, использование чужих вычислительных ресурсов
    • Зрелый подпольный рынок виртуальных товаров, как украденных, так и контрафактных
    • Физические атаки на дата-центры и точки обмена трафиком
    • Электронные атаки на критическую инфраструктуру, включая источники энергии, транспорт и информационные службы
    • Микро-преступность, включая воровство и генерацию фальшивых микроплатежей
    • Биовзломы элементов многофакторной аутентификации
    • Насилие против людей с использованием компьютеров, появление вредоносных программ для людей (вероятно, здесь имеется в виду атака на имплантаты)
    • Войны кибергруппировок
    • Продвинутая криминалистическая разведка, включая дата-майнинг больших объемов данных
    • Таргетированные кражи личностей и взлом аватаров
    • Сложные манипуляции с репутацией
    • Подделка дополненной реальности для мошенничества с помощью социальной инженерии
    • Использование беспилотных аппаратов и роботов в преступных целях
    • Взлом коммуникационных устройств с прямым физическим доступом (коммуникации между автомобилями, наголовные дисплеи и другая носимая электроника)


    В общем, будущее нас ждет довольно интересное… 
  • Celer Bridge incident analysis or why the BGP hijacks still having success

    Celer Bridge incident analysis or why the BGP hijacks still having success

     On 17 August 2022, a BGP spoofer was able to steal approximately USD 235,000 in cryptocurrency by employing a BGP hijack against the Celer Bridge, a service that allows users to convert between cryptocurrencies.

    In this blog post, I discuss this and previous infrastructure attacks against cryptocurrency services. While these episodes revolve around the theft of cryptocurrency, the underlying attacks hold lessons for securing the BGP routing of any organization that conducts business on the Internet.

    The BGP hijack of Celer Bridge

    In a detailed blog post earlier this month, the threat intelligence team from Coinbase explained how the attack went down (Note: Coinbase was not the target of the attack). In short, the attacker used a BGP hijack to gain control of a portion of Amazon’s IP address space.

    Doing so allowed it to impersonate a part of the Celer Bridge infrastructure, which was hosted by Amazon, and issue malicious smart contracts. These ‘phishing contracts’ stole the victim’s assets by redirecting them to the attacker’s wallet.

    To ensure the BGP hijack would be successful, the attacker needed to make certain its malicious BGP announcements wouldn’t get filtered by an upstream network by taking two steps. First, it managed to insert bogus route objects (shown below) for QuickhostUK in AltDB, a free alternative to the IRR databases managed by RADB and the five RIRs. At this time, it is unclear whether QuickhostUK was also a victim of this attack.

    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

    Credit: Siyuan Miao of Misaka on NANOG list

    Since network service providers build their route filters using these IRR databases, this step was necessary to ensure upstream networks wouldn’t filter the bogus announcements coming from QuickhostUK.

    Secondly, the attacker altered the AS-PATH of the route so that it appears to be originated by an Amazon ASN (specifically AS14618). This also caused the route to be evaluated as RPKI-valid; more on that later.

    After the hijack in August, I tweeted the following Kentik BGP visualization showing the propagation of this malicious route. The upper portion shows 44.235.216.0/24 appearing with an origin of AS14618 (in green) at 19:39 UTC and quickly becoming globally routed. It was withdrawn at 20:22 UTC but returned again at 20:38, 20:54, and 21:30 before being withdrawn for good at 22:07 UTC.

    Kentik BFP Monitor’s view of the Amazon BGP hijack

    Amazon didn’t begin announcing this identical /24 until 23:07 UTC (in purple), an hour after the last hijack was finished and more than three hours after the hijacks began. According to Coinbase’s timeline, victims had cryptocurrency stolen in separate events between 19:51 and 21:49 UTC.

    Previous BGP hijacks against cryptocurrencies

    The Celer Bridge attack wasn’t the first time that a cryptocurrency service was targeted using a BGP hijack. In April 2018, Amazon’s authoritative DNS service, the former Route 53, was hijacked in order to redirect certain DNS queries to an imposter DNS service, as illustrated below.

    Amazon’s authoritative DNS service was hijacked to redirect certain DNS queries to an imposter DNS service, in April 2018

    The imposter authoritative DNS server returned bogus responses for myetherwallet.com, misdirecting users to an imposter version of MyEtherWallet’s website. When users logged into their accounts (after clicking past the certificate error, ∗sigh∗), the cryptocurrency was drained from their accounts.

    Within a couple of months of this incident, Amazon had published ROAs for their routes including those of its authoritative DNS service. This move enabled RPKI ROV to help offer some protection against such an attack in the future.

    Since public DNS services like Google DNS peer directly with Amazon and reject RPKI-invalids, it would be difficult, if not impossible, to fool Google DNS like this again. If an attacker surreptitiously appended an Amazon ASN to the AS-PATH of its hijack route in order to render it RPKI-valid, it would be unlikely to be selected over the legitimate route from Amazon because of its longer AS-PATH length.

    The BGP hijack against Amazon was not to be the last to target cryptocurrency.

    Earlier this year there was another incident that involved the manipulation of BGP to target a cryptocurrency service. Attackers were able to make off with over USD 2 million in cryptocurrency by employing a BGP hijack against KLAYswap, an online cryptocurrency exchange based in South Korea.

    Henry Birge-Lee and his colleagues at Princeton authored an excellent post on this incident. In this incident, the attackers went after the users of the KLAYswap cryptocurrency exchange by performing a BGP hijack of the IP space of a South Korean hosting provider (Kakao), as illustrated below.

    BGP hijack of Kakao’s IP space. Image credit Henry Birge-Lee

    This is because Kakao was hosting a javascript library that was loaded when users were on the KLAYswap platform. The BGP hijack enabled the attackers to impersonate Kakao and return a malicious version of this library redirecting user transactions to destinations controlled by the attackers.

    So what can be done to protect against BGP hijacks?

    While the incidents discussed above all involved the targeting of cryptocurrency services, the underlying issues are universal and can affect any organization that uses Internet-based services. In order to safeguard against attacks like these, BGP and DNS monitoring need to play a central role in your monitoring strategy. Additionally, strict RPKI configuration can also increase the difficulty for someone to hijack your routes, as I will explain.

    BGP and DNS monitoring

    DNS monitoring exists for the scenario that unfolded with MyEtherWallet in 2018. It uses agents around the world to check that queries for a specified domain return expected results. If a response contains something other than what was expected, it will fire off an alert.

    In the case of last month’s Celer Bridge attack, BGP monitoring could have alerted that a new /24 of Amazon address space was being announced, although the forged Amazon origin may have caused it to appear legitimate.

    However, when this new /24 appeared with an unexpected upstream of AS209243 (Quickhost), that should have triggered an alert drawing attention to this anomaly. The key detail here that would have distinguished this alert from the appearance of just another peer of Amazon would have been that the new upstream was seen by 100% of BGP vantage points. In other words, this new Amazon prefix was getting exclusively transited by this relatively unknown hosting provider. That should have raised some eyebrows among the Amazon NetOps team.

    RPKI ROV

    Amazon had a ROA for the prefix that was hijacked, so why didn’t RPKI ROV help here? It is important to first emphasize that RPKI ROV is intended to limit the impact of inadvertent or accidental hijacks due to routing leaks or misconfigurations. This is because ROV alone cannot prevent a ‘determined adversary’ from forging the origin in the AS-PATH, rendering a malicious hijack RPKI-valid.

    Having said that, it could have still helped if the ROA were set up differently. As it stands, the ROA for the address space in question is quite liberal. Basically, three different Amazon ASNs (16509, 8987, and 14618) can all announce parts of this address space with prefixes ranging in size from a /10 all the way down to a /24. See the output of the Routinator web UI, as shown in figure 4.

    Validation results for 44.235.216.0/24 - AS16509 via the Routinator web UI

    An alternative approach to ROA creation would be to do what other networks such as Cloudflare and Comcast have done — set the origin and maximum prefix length to be identical to how the prefix is routed. While this approach incurs an overhead cost of needing to update a ROA every time a route is modified, it also leaves little room for alternate versions of the route to come into circulation. Another consideration is the propagation time of the RPKI system itself — changes to ROAs take time to propagate around the world and networks only periodically update their RPKI data.

    In its blog post following the June 2019 routing leak by Allegheny Technologies, Cloudflare made the argument that had Verizon deployed RPKI ROV and had been rejecting RPKI-invalid routes, the leak would not have circulated and the impact would have been minimal. As I discussed in my talk at NANOG 78 in February 2020, this statement is only true because the maximum prefix lengths in Cloudflare’s ROAs matched the prefix lengths of their routes. This is not true of many ROAs, including Amazon’s.

    At NANOG 84 earlier this year, Comcast presented the story of how they deployed RPKI ROV on their network. In the Q&A, they confirmed that they adopted a strategy of using automation to maintain exact matches of maximum prefix lengths in their ROAs to avoid this route optimizer leak scenario.

    Had Amazon created a ROA specifically for 44.224.0.0/11 with an origin of AS16509 and a max-prefin-len of 11, then the attacker would have to do one of two things to pull off this attack. One option would be to announce the same route (44.224.0.0/11 with a forged origin of AS16509). This route would have been RPKI-valid but would have had to contend with the real AS16509 for route propagation. Alternatively, if the attacker announced a more-specific route, it would have been evaluated as RPKI-invalid and had its propagation dramatically reduced if not completely blocked given the upstream in this case was Arelion and they reject RPKI-invalid routes.

    Conclusions

    The attacks against cryptocurrency services in recent years highlight universal problems that aren’t restricted to cryptocurrencies. Companies looking to secure their Internet-facing infrastructures need to deploy robust BGP and DNS monitoring of their infrastructure as well as that of any Internet-based dependencies they may have.
    Additionally, companies should reject RPKI-invalid routes while also creating strict ROAs for their IP address space by including maximum prefix lengths that exactly match the prefix lengths used in their routes. In fact, RFC 9319 ‘The Use of maxLength in the Resource Public Key Infrastructure (RPKI)’ states that it is a ‘best current practice’ that networks entirely avoid using the maxLength attribute in ROAs, except in certain circumstances. Leaving the maxLength field blank in a ROA has the same effect as setting the maxLength field to match the prefix. These steps can greatly reduce the window of opportunity for an attacker to subvert your Internet infrastructure.
  • ЕС ужесточил «криптовалютные» санкции для россиян

    ЕС ужесточил «криптовалютные» санкции для россиян

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

    Какие лазейки для этих целей продолжат действовать и как быть криптоинвесторам?

    Согласно сообщению Еврокомиссии, европейским компаниям запрещается открытие криптосчетов, криптокошельков и оказание услуг хранения криптовалюты для россиян. Таким образом, ужесточаются существующие «криптовалютные» санкции, которые действуют с апреля 2022 года, тогда им запретили иметь на европейских криптокошельках больше суммы, эквивалентной €10 000.

    как обойти санкции ЕС и продолжить заниматься криптой

    После ухода Visa и Mastercard из Росии, отключения части банков от SWIFT и проблем, связанных с международными переводами из-за отказа ряда крупных западных банков-корреспондентов работать с российскими контрагентами, покупка криптовалют, в частности стейблкоина USDT (криптовалюты Tether, чья стоимость привязана к доллару США), стала одним из популярных способов вывода валюты за рубеж. На пиках в марте объем торгов в паре рубль-USDT, по данным The Block, превышал 30 млн в долларовом эквиваленте, хотя до этого в основном был в районе 5 млн и ниже. Россияне активно использовали крупнейшую по объему торгов криптобиржу Binance и ее peer-to-peer сервис, который соединяет между собой продавцов и покупателей цифровых активов напрямую для переводов. 

    Если ЕС запретит операторам криптосервисов оказывать услуги россиянам, это коснется в первую очередь тех площадок, чьи штаб-квартиры зарегистрированы в Евросоюзе, объясняет сооснователь криптовалютной платформы Encry Foundation Роман Некрасов. Например, LocalBitcoins зарегистрирована в Финляндии, и скорее всего, в случае запрета прекратит работать с россиянами, если у них, кроме российского паспорта, нет вида на жительство или документа о постоянном месте жительства в европейской стране, приводит пример он. 

    Тем не менее исключительно европейскими площадками риски не ограничиваются. Например, после ввода в апреле лимитов в €10 000 соответствующие ограничения ввела Binance, зарегистрированная в США. Вероятнее всего, в случае введения запрета Binance и сейчас предпочтет последовать санкциям и полностью запретит россиянам торги на своей площадке, говорит основатель форума Terracrypto Никита Вассев. Рисковать лицензиями в ЕС компания не станет. То же самое касается Coinbase и других криптобирж с множеством юрлиц для работы на разных локальных рынках, добавляет Некрасов. Штаб-квартира Coinbase расположена в США, но в ЕС у компании тоже есть юрлицо — ирландское Coinbase Europe Ltd.  «При этом, судя по тому, как быстро развиваются геополитические события, можно предположить, что запрет на использование американских бирж — это всего лишь вопрос времени», — добавляет Некрасов.

    DeFi пришли на помощь россиянам

    При этом с введением санкций россияне лишатся услуг только централизованных бирж, убежден сооснователь Berezka DAO и Weezi Роман Кауфман. Централизованные биржи, такие как Binance или Coinbase, используют свою торговую систему, через которую проходят сделки между продавцами и покупателями. Именно централизация позволяет клиенту, например, восстановить пароль от своего криптовалютного кошелька. 

    Однако даже с санкциями от ЕС для российских пользователей останутся доступными децентрализованные биржи, у которых нет централизованного посредника между продавцом и покупателем, а торговля криптоактивами происходит с помощью смарт-контрактов. Такие биржи не могут контролировать сделки между своими пользователями — они также не хранят средства своих клиентов и пароли от их криптокошельков. При этом, поскольку подобные биржи не хранят средства своих клиентов, то и не пользуются популярностью у хакеров — их не будут взламывать с целью получения денег. Часто такие биржи не обладают юрисдикциями и не соблюдают финансовые законодательства каких-либо стран, поэтому децентрализованные биржи не вводили ограничения против клиентов из России.

    При этом по объему торгов децентрализованные биржи гораздо скромнее: по данным CoinMarketcap, объем торгов на крупнейшей децентрализованной бирже dYdX более чем в 20 раз ниже, чем на Binance. 

    Среди самых надежных для торговли Некрасов называет децентрализованные биржи DEX UniSwap, SushiSwap, PancakeSwap. Среди централизованных бирж, которыми можно воспользоваться, кроме Binance, исполнительный директор InDeFi Smart Bank Сергей Менделеев называет Okex, Baybit и Huobi. По состоянию на 5 октября Okex работает для жителей России с ограничением в €10 000, а Bybit и Huobi не вводили никаких ограничений. 

    «В случае запрета трейдеры из России могут перейти на такие криптобиржи, как FTX, Huobi, Bybit. Но если площадка заинтересована в европейском рынке, то ей, скорее всего, придется выбирать — или сохранять аудиторию в России, или поддерживать санкции и не иметь проблем в Евросоюзе», — говорит Васеев. Он рекомендует инвесторам не держать крупные суммы на централизованных биржах, особенно если аккаунт верифицирован по российскому паспорту.

    При этом возможность переводить криптовалюту с кошелька на кошелек с помощью peer-to-peer сервиса Binance, вероятнее всего, останется и после введения санкций, считает Некрасов. «Трейдинг, может, и прекратится, а покупка и продажа, где сделка проводится между двумя пользователями, а биржа просто выступает гарантом сделки, останется», — предполагает он. С ним согласен и Никита Вассев: он считает, что этот вариант останется популярным для вывода криптовалюты из России. «Не думаю, что Binance полностью закроет для россиян возможность купли и продажи криптовалют на своей p2p площадке, потому что в таких торгах биржа не является стороной сделки — купля и продажа осуществляется между конкретным продавцом и покупателем. Так что те, кто едет в Грузию, все еще смогут купить там $50 000 в USDT», — заключает основатель TerraCrypto.