dxdt.blog: занимательный интернет-журнал

Популярная тема: давайте сделаем шифрование обязательным элементом HTTP. Речь, понятно, о новой версии протокола HTTP2 (2.0). Это такой способ борьбы с массовой “слежкой через Интернет”, которая сейчас регулярно фигурирует в газетных заголовках. Конечно, шифрование полезно. Но в случае с HTTP есть интересные моменты.

Так, с трафиком работает большое количество разнообразных программно-аппаратных комплексов, не занимающихся “слежкой” как таковой. Хороший пример: системы обнаружения атак и средства противодействия этим атакам. С зашифрованным трафиком они работать не смогут, так как там, по определению, не существует сигнатур, связанных с атаками уровня протокола HTTP, да и вообще – анализировать, с целью обнаружения атак, особенно нечего. Скажем, сейчас, при работе защищаемого веб-ресурса по HTTPS, анализаторы трафика (специальные брандмауэры и разные “гарды”) используют сеансовые ключи, которые в их сторону экспортирует веб-сервер. Эти ключи позволяют просматривать, фильтровать трафик и отрабатывать атаки. Естественно, в случае с тотальным шифрованием – владельцам важных веб-ресурсов поступать придётся точно так же, а ведь именно их трафик и представляет интерес.

Что это означает? А вот что: за периметром, во внутренней сети, трафик всё равно будет нешифрованным. И тотальное введение шифрования HTTP всего лишь сузит круг тех организаций, которые смогут читать “шифрованный” трафик, резко подняв порог доступа. Да, не смогут работать провайдерские системы DPI, пытающиеся балансировать нагрузку и выявлять всякую вредоносную активность, а попутно – строить поведенческие профили пользователей. Но если для анализа трафика используется порт, установленный во внутренней сети крупного сервиса, проблем с анализом не будет. И, естественно, если сервис передаёт вам сеансовые ключи, то трафик можно расшифровывать самостоятельно, записывая его на любой доступной точке.

В Renesys нашли много подтверждений тому, что целевой перехват трафика в Интернете реализуется и путём подмены маршрутов через BGP. Странно, конечно, что они в заголовке называют такое явление “новой угрозой” (The New Threat) – подобные методы известны достаточно давно: например, я писал об одном из сценариев BGP-перехвата в начале 2010 года, это равно тот механизм, который пронаблюдали в Renesys. Но, похоже, сейчас к этой теме привлекут внимание.

Проблема там следующая. Логическую основу Интернета, как сети передачи данных, составляют автономные системы (AS) – это обособленные вычислительные сети, имеющие собственную административную и техническую политику. Существует старый протокол BGP, по которому пограничные узлы-маршрутизаторы автономных систем обмениваются информацией об известных путях доставки пакетов данных. Эти пути (“роуты”) формируют динамическую глобальную систему маршрутов, благодаря которой пакеты от узла в одной автономной системе могут быть доставлены узлу в другой автономной системе, проследовав через ряд транзитных автономных систем. Так работает глобальная Сеть. У BGP есть фундаментальные особенности, которые позволяют автономным системам, активно манипулирующим маршрутами, “заводить” к себе трафик, предназначенный для любой другой автономной системы. Делать так можно даже в том случае, если атакующая система не являлась, в штатном варианте, транзитной для перехватываемого пути (маршрута). Другими словами – узел, находящийся, например, в Праге, может слушать IP-трафик между двумя узлами, находящимися в Вашингтоне.

Почему это возможно? Грубо говоря, потому, что в BGP нет эффективных механизмов проверки того, какие маршруты могут проходить через данную автономную систему. Глобальная таблица заполняется на основе так называемых анонсов, которые выдают пограничные маршрутизаторы, если маршрутизатор анонсирует “чужой” маршрут, то, часто, обнаружить это удаётся только после того, как трафик уже утёк. (Англоязычное название явления: Internet route hijacking.) Очевидно, что трафик, следующий по перехваченному маршруту, может прослушиваться в транзитной автономной системе – для чего и делается перехват. При этом существуют методы, позволяющие скрыть следы такого перенаправления.

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

(Кстати, а в материале Renesys, отчего-то, упоминаются белорусские сети, замеченные в описанной выше подмене маршрутов.)

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

А вот если рассматривать Интернет как новое “виртуальное пространство”, то ситуация тут хитрее. “Посольства” здесь есть у многих государств, а вот принимающей стороной выступает ряд “надгосударственных” образований (например, ICANN). При этом, если взять – и огородить суверенный национальный сетевой сегмент, с целью предотвращения в нём “бурной иностранной деятельности”, то окажется, что, из-за технических особенностей организации Сети, потеряны выходы в общее пространство, где можно было бы вести самостоятельную, вполне активную, деятельность по сбору полезной информации и анализу разных “метаданных”. И не так просто определить, что тут важнее: закрытие сетевых границ или игра на чужом, пока что, информационном поле.

Кстати, в записке, которой уже больше года, оценивается объём ресурсов, нужных для работы системы тотального мониторинга перемещений владельцев смартфонов мощностью в 500 млн абонентов. И такая система, несмотря на то, что описана под грифом “Технологический юмор”, сейчас вообще не выглядит фантастической. Потоки данных там минимальные, для их приёма достаточно всего двух коммуникационных портов, имеющих пропускную способность в гигабит. Порты эти могут быть разделены (пусть их будет, например, семь). Располагаться им лучше всего неподалёку от точек концентрации интернет-трафика, чтобы компенсировать возможные флуктуации пропускной способности в Интернете (ведь наблюдаемые абоненты перемещаются по всему миру).

Другими словами: ждём информации о практической реализации.

В корне DNS работает уже несколько совсем новых, тематических, доменов верхнего уровня, которые выглядят весьма непривычно. Проверьте, например: nic.camera, nic.guru, nic.equipment.

У адресов в этих доменах, при наборе из адресной строки некоторых браузеров (пример – Сhrome), возникает конфликт со встроенной функцией поиска браузера. В Chrome это выглядит вот так (предлагается кликнуть по ссылке, следующей за вопросом о том, хотели ли вы перейти на данный сайт):

Для того чтобы ручной набор сработал, нужно набирать перед именем домена http://.

Странный Интернет, да.

Занимательно видеть, что, например, на сайтах российских автодилеров, где они стараются продавать автомобили, используется “Яндекс.Метрика”. Согласно пользовательскому соглашению, “Яндекс” может использовать данные, собираемые “Метрикой”, в своих целях. Соответственно, почему бы ему не использовать эти данные для повышения качества “таргетирования” рекламы в “Яндекс.Директе”? А в “Директе”, тем посетителям, которые ушли с сайта автодилера и теперь путешествуют по другим, даже не автомобильным сайтам, показывается реклама конкурентов. Лучше всего, если объявления содержат те же модели, которыми конкретный посетитель интересовался.

Риск, в общем-то, хорошо известный. Думаю, что и Google, и другие системы массовой статистики, могут поступать так же. Тем не менее, коды на “продающие сайты” ставят стандартно. Очень грубая оценка даст нам примерно 15-20% потерь клиентов в направлении конкурентов через данную схему. Забавно, что, в таком случае, на “закрытом” рынке, некий автодилер мог бы заработать при помощи сайта дополнительно эти самые 10-15%, всего лишь убрав со страниц внешние “шпионские счётчики”. Ну, окей, понятно, что нужно нормировать расчёт по выручке и так далее, что нужно ещё исследовать, уводит ли “Директ” посетителей таким образом, но сумма-то может выйти весьма заметной, не факт, что использование той же “Метрики” позволяет поднять продажи на сравнимую величину. А код – всё равно на сайтах.

С относительно недавних пор WordPress получил функцию автоматического обновления. То есть, и раньше-то эта CMS была среди лидеров по удобству процедуры обновления: кликнул на кнопку в панели управления – всё успешно обновилось (не чета, например, Drupal-у, который до сих пор требует ручного накатывания файлов обновления, что, конечно, не слишком удобно). А теперь для обновления WordPress-а и кнопку нажимать не нужно: скачивает и накатывает новые файлы он самостоятельно, тихо, никого не спрашивая. Присылает e-mail по результатам обновления. Замечательная практика.

Действительно, интересно будет посмотреть, как однажды эти смелые люди, разработчики данной CMS, одним неловким движением сломают миллионы ничего не подозревающих сайтов в Интернете (о перспективе взлома раздающего обновления центра – пока лучше не думать).

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

Кстати, на сайте RU-CENTER, принимающем предварительные заявки на регистрацию доменов в новых зонах, можно ощутить, куда же катится DNS – чего там только не будет, на новом верхнем уровне: new.nic.ru.

В продолжение предыдущей записки о системе хранения интернет-трафика. Понятно, что мало найти место для хранения трафика, нужно ещё решить ряд других непростых задач: во-первых, трафик нужно как-то заливать в хранилище; во-вторых, нужно предоставить доступ (с поиском и разными выборками) к сохранённому трафику.

Мы оцениваем трафик порядка терабита в секунду (это верхний предел, определённый из объёмов MSK IX). Конечно, напрямую заливать терабит в систему хранения через один порт технически невозможно. Поэтому для приёма трафика требуется построить некий распределённый многопортовый шлюз. Это большая проблема. Дело даже не в том, что гипотетический сверхпроизводительный элементарный узел сможет обрабатывать не более гигабита в секунду и таких узлов потребуется тысяча, а в том, что поступающий трафик нужно будет корректно сортировать по ряду признаков. Сортировка нужна хотя бы для того, чтобы удалить дубликаты пакетов и верно определить источник и получателя для каждой сессии. Тем не менее, эта проблема решается. Узлы, составляющие принимающий шлюз, могут быть размещены на разных площадках: не обязательно организовывать подключение в одной точке. Между узлами потребуется построить собственную сеть обмена “метаинформацией” о том, кто и что сохраняет. Очищенный на местах трафик отправляется в центральное хранилище.

Отдельная сложность – поиск в базе данных, имеющей объём около трех петабайт. Вспомним, что речь идёт о данных, которые перезаписываются каждые 12 часов. То есть, поиск должен быть быстрым, так как каждый час, затраченный на выборку, означает, что часть данных, которые могут потребоваться для уточняющих запросов, уже удалена. Возьмём экстремальный случай и предположим, что для выполнения запроса требуется перебрать 10% собранных данных. Пусть объём всей базы 2,7 петабайта, тогда 0.1 это 270 терабайт. Если наш “процессинговый центр” обрабатывает гигабайт в секунду (чрезвычайно быстро), то для перелопачивания 270 терабайт потребуется 75 часов. А это означает, что обработка уже не имеет никакого смысла. Не нужно, впрочем, делать вывод, что из подобной системы хранения нельзя извлечь ничего полезного.

Решением является создание архитектуры, оптимизированной с точки зрения выполнения неких определённых типов запросов на поиск. Чтобы такие запросы выполнять быстро, нужно будет при сохранении трафика вычислить некоторое “избыточное” представление, позволяющее найти нужный фрагмент трафика, скажем, в течение часа. Впрочем, решение этой задачи существенно усложняет организацию системы, записывающей трафик: потребуются дополнительные вычислительные мощности и, конечно, новое дисковое пространство.

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

Предположим, что у нас есть гигабитный канал и нам нужно записывать весь проходящий интернет-трафик, на уровне IP, вместе с заголовками и служебной информацией. Сколько потребуется места в хранилище? Гигабит – это не более 125 мегабайт в секунду. 125 Mb * 3600 = 450 гигабайт в час. Объём буфера на 12 часов не превысит 450*12 = 5,4 терабайт. Удобно использовать хранилище, построенное на базе SSD. А если прикрутить к хранилищу пару мощных процессоров, то (нешифрованный) трафик можно будет на лету сжимать, раза в два: получаем 2,7 терабайта.

Вернёмся к объёмам трафика. На MSK-IX говорят о терабите (в секунду, понятно), как о некоторой важной отметке. Пусть это действующий верхний предел, определяющий понятие “большой объём трафика” для масштабов Рунета. Терабит (примем, что это 1000 гигабит), взятый за 12 часов, согласно расчётам из предыдущего абзаца, поместится в хранилище, имеющее объём 2,7 петабайта. Объём приличный, да. Пусть 100 Gb на SSD, вместе с доступом, стоят около $50, тогда затраты на диски составят 500 тыс. долларов США (поправка: это на петабайт, то есть, полный комплект – 1 млн 350 тыс. долларов). Понятно, конечно, что само хранилище будет стоить существенно дороже, но ничего фантастического в этих, примерно, трёх петабайтах – нет.

(Дополнение 25/10/13. Посмотрим на расценки сервиса хранения данных Amazon S3: размещение 2,7 петабайта обойдётся в 2,7 * 55000 = 148500 долларов США в месяц, по тарифу US Standard; это, конечно, только хранение данных с резервированием, извлечение, а также быстрый доступ вообще, потребуют дополнительных затрат. 148,5 тыс. ежемесячно – дают нам 1 млн 782 тыс. в год. То есть, можно предположить, что соответствующее хранилище обойдётся где-то в 7-10 млн долларов.)

Продолжение: сбор и обработка трафика.

На картинке ниже – рост числа российских и зарубежных хостингов, на которых размещаются сайты под доменами .RU (то есть, сайты Рунета). Зарубежные хостинги – это нижний график, красный. За год он хорошо приблизился к хостингу российскому.

Источник данных: stat.nic.ru.