Рассылка представлена компанией NStor (www.nstor.ru)

Китайский инцидент: небезопасные маршруты

Как показывает инцидент о котором сообщалось на прошлой неделе, система Интернет-маршрутизации не так безопасна. Но на самом ли деле все так плохо?

А что собственно представляет из себя интернет маршрутизация. Маршрутизация основана на автономных системах (AS), которые обмениваются префиксами (диапазоны IP адресов) используя Border Gateway Protocol (BGP). Автономные системы это первые и главные интернет провайдеры (ISP). Но некоторые организации подключены к двум или более провайдерам одновременно. IP адреса, которые ISP выдают своим клиентам, сгруппированны в относительно небольшое число префиксов, покрывающих большие адресные блоки. Эти префиксы "анонсируются" или "рекламируются" через BGP в AS. Префиксы идут от AS к AS, так что в конце концов весь Интернет знает, куда отсылать пакеты с данным адресом назначения.

Понятие BGP (Border Gateway Protocol, протокол граничного шлюза) было более осязаемо 20 лет назад, когда слово "шлюз" использовалось для название того, что мы сегодня называем маршрутизатор. Итак BGP это протокол, используемый между пограничными маршрутизаторами – роутерами, которые находятся на периферии соседствующих автономных систем. AS представляют собой иерархию, которая выглядит примерно таким образом:

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

Таким образом, AS 6 может идти к AS 5 по маршруту 6 – 3 – 1 – 2 – 5, где AS 6 платит AS 3, который в свою очередь платит AS 1, при этом AS 5 оплачивающем услуги AS 2. Получается, что все ISP получают деньги, даже несмотря на то, что AS 1 не платит AS 2. Однако маршрут 6 – 3 – 4 – 2 – 5 не действенен для доставки трафика от AS 6 к AS 5. В этом случае, AS 4 пришлось бы платить AS 2 за этот трафик, но так как AS 3 ничего не платит AS 4, получилось бы, что AS 4 предоставляет свои услуги бесплатно. С другой стороны, маршрут 6 – 3 – 4 – 8 от AS 6 к AS 8 работает нормально, так как AS 8 это клиент AS 4 и следовательно AS 8 оплачивает AS 4 входящий трафик.

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

Зная то, как автономные системы взаимосвязаны с другими автономными системами, будь то клиент/ISP соединение или равноправный информационный обмен, можно точно узнать, как может быть достигнута искомая точка назначения из любого источника. Также, необходимо знать какой диапазон IP адресов принадлежит к какой AS. Расчеты перемаршрутатизации после неудачи несколько усложняют дело, но это не слишком большая проблема.

Знание графа сети и отношений префиксов AS позволило бы создать фильтры, которые утверждали бы информацию, получаемую через BGP и отклоняли некорректную или ложную информацию. Есть специальные базы данных маршрутизации, где отмечается такая информация. К сожалению, не всегда удается пополнять их и информация зачастую ненадежна. IETF и региональные регистраторы, которые раздают IP адреса и AS номера, сейчас работают над базой данных и инфраструктурой сертификатов, которые как раз позволили бы это делать. Хотя пока это только разработки.

Как бы то ни было, где же эти сервера?

Операторы сети просто напросто сами не знаю где находится сервера CNN, в Атланте или в Пекине. И когда приходит обновление BGP, утверждая последнее, у провайдеров - точнее у их роутеров, нет другого выбора: им приходится устанавливать обновления и посылать трафик в новом направлении. 999 раз из 1000 перемаршрутизация это вполне обыденное явление. Но 1 раз это все-таки либо ошибка, либо какого-нибудь рода атака.

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

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

(Я пошел на мое первое IETF собрание в 2002 году, когда в разработке находилась система маршрутизации inter-AS. Я помню у нас был ланч в пицеррии в Атланте. Было 20 человек из Cisco, которые все время неистово изображали топологию сетей на салфетках. К этому времени уже было два предложения для того, чтобы сделать BGP более безопасным: S-BGP от BBN и soBGP от Cisco. Вот уже почти десять лет прошло в спорах о том, какое из этих предложений лучше и вообще стоит ли что-нибудь предпринимать… Но результатов как не было так и нет…)

Не стоит недооценивать сложности, возникающие при обеспечении безопасности Интернет маршрутизации. Что если сертификат используемый S-BGP или soBGP истечет? Если это означает, что соединение будет прервано, пожелаем успехов в скачивании нового сертификата...

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

Спасает маршрутизацию то, что большинство ISP тщательно фильтруют то, что клиенты им присылают. И если я настрою свой BGP-маршрутизатор сообщить моему провайдеру, что я владелец IP адреса Windows Update, то мой ISP должен проявить бдительность и игнорировать подобную BGP "рекламу". И так как между ISP и клиентами имеют место быть бизнес-отношения, обе стороны заинтересованы быть в курсе всех последних изменений в префиксах.

Однако как только некорректная информация перешла границу клиент/провайдер, она быстро распространится по равноправным соединениям практически не встречая никаких преград на своем пути. Это происходит потому, что на данный момент нет никакой официальной базы данных маршрутизируемой информации. Единственный способ ISP отфильтровать равноправных ISP – это постоянный обмен обновленным данным по принципу тет-а-тет. Но по причине постоянной смены клиентов и введения новых префиксов, большого количества пиров у крупных ISP - это способ просто неосуществим.

Китайская маршрутизация

Так что же на самом деле случилось в Китае, что повлекло перенаправление маршрутов 15% Интернет-префиксов – а не 15% трафика – на эту страну в апреле? И был ли это несчастный случай или что-то более опасное? Я не был в офисе China Telecommunications Corporation и не наблюдал за случившимся лично, поэтому не могу сказать наверняка, был ли это дьявольский и совершенный план или очень глупая ошибка сетевого инженера. Но я порассуждаю на эту тему позже, не только из-за принципа "Лезвия Хэнлона" ("Никогда не приписывайте злонамеренности тому, что вполне может быть объяснено глупостью").

Обычный сбой протокола BGP - утечка всей таблицы маршрутизации. В настоящее время существует 341 000 Интернет-префиксов, образующих Интернет, и чтобы работать со всеми ними BGP-маршрутизатору нужно иметь их все в таблице маршрутизации. Если по какой-либо причине BGP-маршрутизатор не имеет никаких фильтров, он просто отправляет всю копию этой таблицы всем маршрутизаторам в соседних автономных системах, к которым он подключен.

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

После обновления фильтра, он может перестать функционировать. Обычно, такое случается с фильтром "максимального префикса" последней инстанции – это останавливает сессию BGP если получено большее количество префиксов нежели возможно. Но, даже не беря в расчет это, подобная утечка должна была быть не настолько разрушительной, потому что обход через (например) Китай означает преодоление дополнительных автономных систем, а BGP предпочитает долгим путям короткие. Это обусловлено тем, что для каждого префикса автономные системы на пути к адресу назначения записываются в "AS путь" - самый короткий путь по количеству автономных систем.

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

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

Таким образом утечка целой таблицы BGP или ее части сама по себе не настолько подозрительна, хотя провайдерам размера China Telecom следовало бы в этом разбираться лучше. Но то, что AS пути были очищены, можно расценить как причину для умеренного подозрения.

Если бы я был еще большим параноиком, я бы, тем не менее, начал искать в Интернете неправильные префиксы/комбинации автономных систем, которые случайно проявлялись бы на некоторое время. Тот, кто хочет перехватить трафик, наверняка бы создал несколько серверов и BGP-маршрутизаторов в дата-центрах с хорошей связью, а потом попытался бы посмотреть, какой Интернет-провайдер дает сбой в фильтрации. С таким провайдером нацеленная атака могла бы вызвать перемаршрутизацию трафика гораздо дольше чем на 18 минут. Перенаправление префиксов Северной Америки внутри самой Америки выглядело бы менее подозрительно, чем перенаправление их в Китай.

Пока мы ждем появления какой-то формы безопасности для BGP, мы все должны задуматься о том, что бы случилось, если бы адреса удаленных систем, с которыми мы общаемся, были перенаправлены и наш трафик был бы перехвачен. Шифрование и закрытая аутентификация типа HTTPS илиVPN защищают от этого. Однако есть проблема и в шифровании: центрам выдачи сертификатов нельзя так уж доверять. А как справиться с этим – расскажу в следующий раз.

Источник: arstechnica.com

 Микропроцессорные архитектуры: сколько их останется?

Опасения поклонников серверов SUN Microsystems, вызванные вопросом о том, станет ли Oracle поддерживать доставшуюся ей вместе с покупкой SUN микропроцессорную архитектуру SPARC (Scalable Processor ARChitecture), далеко небеспочвенны. На протяжении десяти последних лет Oracle занималась агрессивным поглощением других фирм, хотя SUN, конечно же, настоящая жемчужина в цепи этих приобретений.

Жемчужина добавила в портфель Oracle:

• язык программирования Java и все связанные с ним патенты, среды разработки и разветвленную сеть приверженцев, экосистему;
• популярнейшую бесплатную базу данных – MySQL (связка Linux + база данных MySQL + веб-сервер Apache – пожалуй, самый массовый бандл приложений в Интернете);
• процессоры архитектуры UltraSPARC и весь построенный на них стек решений для корпоративного сектора – Sun SPARC Enterprise Servers, UNIX-подобную операционную систему SUN Solaris и полный набор приложений под нее, одним из которых и является система управления базами данных Oracle Database.

Конечно же, глава Oracle Ларри Эллисон заверял индустрию, что ничего из этого славного наследия потеряно не будет, а, наоборот, получит развитие и новую жизнь. Как раз недавно была опубликована дальнейшая программа по «перевариванию» доставшихся Oracle технологий. Однако опыт похожих поглощений в прошлом позволяет усомниться, что все будет столь радужно. Как говорят американцы, все это «too good to be true». То есть слишком уже хорошо, чтобы быть правдой.

С одной стороны, поглощение SUN Microsystems, конечно же, не было случайным или спонтанным. Oracle давно и успешно использует язык Java практически во всех своих программных продуктах, а о таком сообществе разработчиков, каким является экосистема Java-программистов, можно только мечтать (даже «Майкрософту»). Сравниться оно может только с приверженцами продукции фирмы Apple – тут все на грани культа (как вам рекламный лозунг 90-х «Тропой Макинтоша»?).

Корпоративные серверные системы – старшие многопроцессорные серверы Sun SPARC – один из столпов флагманского продукта Oracle — Database. И интеграция этого приложения с операционной системой Solaris и самим серверным «железом» теперь, после поглощения, наверняка станет еще лучше. Но вот что совершенно не факт в данной ситуации, так это то, что процессорная архитектура UltraSPARC останется востребованной.

• Серия Motorola 68 000. Долгое время Intel и Motorola и шли буквально вровень, выпуская поколения процессоров с очень похожей нумерацией – 286, 386, 486 против 68020, 68030, 68040. Процессоры были сердцем соответственно IBM-совместимых компьютеров и Apple Macintosh (даже ранние модели SUN Sparc Station и Silicon Graphics использовали мотороловские процессоры – до начала производства своих). Кроме того процессоры Motorola использовались в очень известных в свое время компьютерах «Коммодор», АТАРИ, «Синклер», в калькуляторах Texas Instrumetns и в первых версиях «наладонников» Palm. Более того, подыскивая поставщиков компонентов для своего первого персонального компьютера (1981 год), фирма IBM выбирала между Motorola и Intel в качестве поставщика процессоров, и между Microsoft и Digital Research – в качестве разработчика операционной системы. Ни Intel, ни Microsoft не были тогда лидерами в своих сегментах. Известный компьютерный журналист Рубен Герр написал в 1993 году, что, видимо, это был осознанный выбор – ставка на вторых, которые очень желали стать первыми. Ставка оправдалась на 100%.

Перелом в соревновании Intel и Motorola наступил в 1993 году с появлением процессора Pentium. Интересно, что в своей первой редакции он был выпущен на тактовой частоте всего 60MHz, то есть меньше своего предшественника стомегагерцового 486DX4-100. Однако примененные в Pentium новшества – многоконвейерность, 64-битная шина данных, предсказание ветвлений, разбор на микрокоды, элементы RISC-архитектуры и т.д. сразу вывели новый микропроцессор в лидеры по производительности. Семейство 68000 ушло в область микроконтроллеров, а Apple «пересела» на нового неудачника нашего обзора – процессор PowerPC.

• Великолепная Alpha от фирмы DEC – в свое время самый быстрый и первый массовый 64-разрядный микропроцессор в индустрии, ВДВОЕ превосходивший конкурентов по скорости вычислений с плавающей точкой – еще одна жертва. Этот проект пришлось убить уже самой HP, «не потянувшей» после всех приобретений такое количество систем в своем портфеле.
• Попытка перенести успешную на мейнфреймах архитектуру POWER от IBM на персоналки (эппловские, между прочим!) – процессор PowerPC. Выпуском занимался альянс AIM (Apple — IBM – Motorola). Это была вторая и последняя попытка Motorola сделать массовый процессор для персоналок.
• Следующая потеря — процессоры архитектуры PA-RISC от HP. На них строилась линейка суперпроизводительных серверов HP TopDome. Еще в 90-е Hewlett-Packard вступила в альянс с Intel для создания совместного процессора по технологии VLIW (Very Large Instruction Word, сверхдлинное командное слово) – известного сейчас как Itanium. На него и были переведены в 2008 году все серверы HP старшего класса.
• Процессоры MIPS, на которых были построены уникально быстрые графические станции Silicon Graphics.4.
• RISC-процессор Intel i960. И так далее, и тому подобное.

Между прочим, еще в середине 90-х подобный исход вряд ли казался кому-нибудь возможным. Например, вышедшая в 1996 году операционная система Windows NT 4.0 Server, только начинавшая тогда свои попытки проникнуть в корпоративный сектор, могла работать, помимо традиционного x86, на процессорах Alpha, MIPS и PowerPC (фирма Intergraph делала даже попытки портировать Windows NT и на SUN SPARC, к слову). Но уже в выпущенной через 4 года версии Windows Server 2000 поддержка отличных от x86 архитектур была убрана целиком и полностью.

Два владельца оригинальных процессорных архитектур – Silicon Graphics и та же Sun Microsystems – перевели в свое время на x86 младшие модели своих серверов, у фирмы Hewlett Packard серверы x86 были в линейке продукции с самого начала. Apple также перешла на архитектуру x86 в 2006 году — после неудачи с дальнейшим развитием PowerPC. Владельцы главных патентов на x86 – Intel и AMD — стремятся расширить влияние этой архитектуры на все сегменты рынка, от суперкомпьютеров (что удается очень неплохо) до переносных миниатюрных устройств (пока не очень). И тут настает звездный час архитектуры ARM…

Источник: ibusiness.ru

Наши информационные сайты: NStor.ru - Cайт компании Nstor ProLiant.ru - Серверы и комплектующие HP Proliant POSKAS.RU - Торговое оборудование и автоматизация торговли QuickScan.ru - Информационный сайт по системам сканирования книг, слайдов и документов Tape-Drive.ru - Системы резервного копирования, стримеры, ленточные библиотеки Allbackup.ru - Интернет-магазин по системам резервного копирования данных RaidShop.ru - RAID-системы (NAS, SAN, SAS): статьи, новости, интернет-магазин LargeFormat.ru - Оборудование для широкоформатной печати и сканирования A3 и более TapeBackup.ru - Форум по серверам и системам хранения информации Наши рассылки:          Новости систем хранения данных