Silence on the Wire. Авторское право © 2005, Michal Zalewski.

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

15 14 13 12 6 7 8 9

ISBN-10: 1-59327-046-1

ISBN-13: 978-1-59327-046-9

• Издатель: William Pollock

• Ответственный редактор: Karol Jurado

• Руководитель производства: Susan Berge

• Дизайн обложки и внутреннего оформления: Octopod Studios

• Редакторы-разработчики: William Pollock и John Mark Walker

• Технический рецензент: Solar Designer

• Литературный редактор: Pat Coleman

• Верстальщик: Riley Hoffman

• Корректор: Stephanie Provines

• Составитель указателя: Ted Laux

За сведениями о распространителях книги или переводах обращайтесь непосредственно в No Starch Press, Inc.:

No Starch Press, Inc.

555 De Haro Street, Suite 250, San Francisco, CA 94107

телефон: 415.863.9900; факс: 415.863.9950; info@nostarch.com; nostarch.com

Zalewski, Michal.

Silence on the wire: a field guide to passive reconnaissance and indirect attacks / Michal Zalewski.

p. cm.

Включает предметный указатель.

ISBN 1-59327-046-1

1. Компьютерные сети - меры безопасности. I. Название.

TK5105.59.Z35 2005

005.8-dc22

2004009744

No Starch Press и логотип No Starch Press являются зарегистрированными товарными знаками No Starch Press, Inc. Другие упомянутые здесь названия продуктов и компаний могут являться товарными знаками соответствующих владельцев. Вместо того чтобы ставить знак товарного знака при каждом появлении защищённого названия, мы используем такие названия исключительно в редакционных целях и в интересах владельца товарного знака, не намереваясь нарушать его права.

Информация в этой книге распространяется на условиях «как есть», без каких-либо гарантий. Хотя при подготовке этой работы были приняты все возможные меры предосторожности, ни автор, ни No Starch Press, Inc. не несут перед каким бы то ни было лицом или организацией ответственности за убытки или ущерб, вызванные либо предположительно вызванные прямо или косвенно содержащейся в книге информацией.

Где мы исследуем, как за нажатиями ваших клавиш можно следить издалека, очень издалека.

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

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

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

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

Способность машин достигать подобной последовательности в сочетании с их замечательными вычислительными возможностями и делает компьютеры великолепным инструментом для тех, кому удаётся ими овладеть и управлять. Разумеется, нужно сделать одну оговорку: не всё так радужно, и жалующиеся на ненадёжность компьютеров не совсем неправы. Несмотря на безупречную работу оборудования, сами программы время от времени ведут себя неверно. Дело в том, что хотя аппаратное обеспечение может быть - и часто бывает - последовательным и надёжным, обычно невозможно надолго предсказать поведение достаточно сложной программы, не говоря уже о сложной совокупности взаимозависимых программ, такой как типичная операционная система. Поэтому проверка программы крайне трудна, даже если предположить, что мы способны построить подробную, достаточно строгую и при этом безошибочную гипотетическую модель того, как программа должна работать. Почему? В 1936 году Алан Тьюринг, отец современных вычислений, методом reductio ad absurdum - сведением к абсурду - доказал отсутствие общего способа за конечное время определить результат любой компьютерной процедуры, или алгоритма, хотя для некоторых алгоритмов частные способы существовать могут.^[1]

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

Возьмём шифрование данных, особенно этого загадочного зверя - криптографию с открытым ключом. Эта новая и гениальная разновидность шифрования, причём не только шифрования, впервые предложенная в 1970-х годах Уитфилдом Диффи и Мартином Хеллманом, а вскоре превращённая Роном Ривестом, Ади Шамиром и Леном Адлеманом в полноценную криптосистему, основана на простой мысли: одни задачи труднее других. Конечно, это кажется очевидным, но добавьте несколько понятий высшей математики - и революционное изобретение готово.

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

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

В основе исходной криптосистемы с открытым ключом RSA - Rivest, Shamir и Adleman - лежит наблюдение, что вычислительная сложность умножения двух сколь угодно больших чисел сравнительно невелика: она прямо пропорциональна количеству умножаемых цифр. С другой стороны, сложность поиска множителей большого числа - факторизации - значительно выше, если только вы не легендарный криптографический гений из Агентства национальной безопасности. Сначала алгоритм RSA выбирает два произвольных очень больших простых числа^[1], p и q, и перемножает их. Затем он использует произведение вместе с числом (p - 1)(q - 1), взаимно простым^[2] с другим параметром, чтобы построить открытый ключ. Этим ключом можно зашифровать информацию, но одного его недостаточно для расшифровки без факторизации.

Вот в чём хитрость: факторизация произведения двух больших простых чисел зачастую практически невыполнима, и такие атаки срываются. Самому быстрому универсальному алгоритму факторизации целых чисел на традиционных компьютерах, методу решета числового поля общего вида, GNFS, потребовалось бы более тысячи лет для нахождения множителей такого 1024-битного целого числа при скорости миллион проверок в секунду. Между тем обычный персональный компьютер находит два простых числа с произведением такого размера за несколько секунд.

Как уже говорилось, в RSA вместе с открытым ключом создаётся и закрытый. Закрытый ключ содержит дополнительные сведения о простых числах, позволяющие расшифровать любую информацию, зашифрованную открытым ключом. Этот трюк возможен благодаря китайской теореме об остатках, теореме Эйлера и другим несколько пугающим, но увлекательным математическим понятиям, которые особенно любознательный читатель, возможно, захочет изучить самостоятельно.^[2]

Позднее появились и другие криптосистемы с открытым ключом, основанные на иных трудных математических задачах, включая системы на эллиптических кривых и так далее, но все они используют основную идею открытого и закрытого ключей. Метод оказался практичным для защиты электронной почты, веб-транзакций и многого другого, даже если две стороны никогда не общались и до установления соединения у них не было безопасного канала для обмена дополнительными сведениями.^[3] Почти все повседневные схемы шифрования - от Secure Shell, SSH, и Secure Sockets Layer, SSL, до обновлений с цифровой подписью и смарт-карт - существуют благодаря вкладу Диффи, Хеллмана, Ривеста, Шамира и Адлемана.

Есть лишь одна проблема: при реализации RSA на детерминированной машине сначала нужно получить два очень больших простых числа, p и q. Компьютеру нетрудно найти большое простое число, но остаётся небольшая загвоздка: другие не должны иметь возможности угадать эти числа, и на разных машинах они не могут быть одинаковыми. В противном случае для атаки на алгоритм не понадобилась бы факторизация, а p и q были бы известны любому владельцу похожего компьютера.

За последние годы разработано множество алгоритмов, которые быстро находят кандидаты в простые числа - псевдопростые числа - и выполняют быстрые предварительные проверки простоты, применяемые для проверки таких кандидатов.^[3] Но для получения действительно непредсказуемого простого числа нужна хорошая порция энтропии, или случайности: тогда можно вслепую выбрать одно из простых чисел заданного диапазона либо начать со случайного места и взять первое встреченное простое число.

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

Чтобы реализовать, например, SSH с приемлемой производительностью, разумнее установить первоначальную связь и выполнить базовую проверку с помощью алгоритмов с открытым ключом, создав тем самым безопасный канал. Затем стороны обмениваются компактным симметричным ключом шифрования, скажем 128-битным, переключаются на старую симметричную криптографию и продолжают общение. Главный недостаток симметричной криптографии устраняется благодаря первоначальному - медленному - защищённому потоку для обмена общим секретом; затем используются более быстрые алгоритмы, и пользователь получает высокую производительность, не жертвуя безопасностью. Но для разумного применения симметричной криптографии всё равно требуется определённая энтропия, позволяющая создавать непредсказуемый симметричный сеансовый ключ для каждого защищённого сеанса связи.

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

PRNG достаточно для простых задач, например для создания «случайных» событий в компьютерных играх или бессмысленных тем особенно назойливых массовых спам-рассылок. Возьмём линейный конгруэнтный генератор, также называемый генератором степенных вычетов,^[4] - классический пример такого алгоритма. Несмотря на непонятное название, при каждом получении «случайного» результата этот генератор выполняет последовательность простых операций: умножение, сложение и взятие остатка^[4]. Для вычисления следующего значения r(t+1) он использует предыдущий результат r(t), где t обозначает время:

Операция взятия остатка ограничивает диапазон и предотвращает переполнение - ситуацию, когда результат на некотором этапе выходит за заранее определённые границы значений. Если r(0), a, M и c - набор управляющих переменных генератора - являются положительными целыми числами, все результаты уравнения лежат в диапазоне от 0 до M - 1.

Однако, хотя после некоторой настройки результаты алгоритма могут обладать статистическими свойствами, подходящими для создания подобий случайных чисел, в самих его действиях нет ничего по-настоящему непредсказуемого. В этом и заключается проблема: нападающий легко может создать собственную копию генератора и с её помощью определить любое количество результатов, которые выдаст наш генератор. Даже если исходное состояние генератора, r(0), нападающему неизвестно, зачастую он способен успешно вывести важные свойства этого значения, наблюдая за последующими результатами генератора жертвы, а затем использовать полученные сведения, чтобы настроить свою версию и заставить её подражать нашей. В действительности общий метод восстановления и предсказания всех полиномиальных конгруэнтных генераторов был разработан более десяти лет назад,^[5] и игнорировать эту небольшую, пусть и несколько неудобную подробность было бы крайне неразумно: при использовании алгоритма в критически важных задачах она оставляет зияющую брешь.

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

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

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

Но возникает другая проблема. Если реализация долго работает на старой, унаследованной энтропии, лишь снова и снова хешируемой с помощью MD5 или SHA-1, она становится полностью зависимой от безопасности алгоритма получения отпечатка, которому нельзя безоговорочно доверять из-за рассмотренного выше компромисса между производительностью и безопасностью. Более того, компетентные криптографы могли не провести надлежащую оценку пригодности хеш-функций именно для такого применения. Теперь реализация опирается уже не просто на свойства перемешивания битов функцией отпечатка, а полностью зависит от её неуязвимости для взлома. Если с каждым последующим шагом раскрывается небольшая часть сведений о внутреннем состоянии генератора, а новые непредсказуемые данные в пул не добавляются, со временем накопленной информации может хватить, чтобы с достаточной уверенностью восстановить или угадать внутреннее состояние и получить возможность предсказывать дальнейшее поведение устройства. С другой стороны, если новые случайные данные добавляются со скоростью, которая хотя бы статистически предотвращает существенное повторное использование внутреннего состояния, атака становится гораздо менее осуществимой даже при фундаментальной уязвимости хеш-функции.

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

Хороший пример правильной реализации PRNG, учитывающей всё сказанное, - превосходная система, разработанная и реализованная в 1994 году Теодором Цо из Массачусетского технологического института. Его механизм /dev/random впервые появился в Linux, а позднее был перенесён в FreeBSD, NetBSD и HP/UX. Механизм Цо наблюдает за рядом системных событий ввода-вывода, измеряя интервалы времени и другие важные характеристики прерываний. Он также сохраняет пул энтропии на диск при завершении работы, чтобы после загрузки система не оказалась в полностью предсказуемом состоянии; это ещё больше затрудняет атаку.

[1] [назад] Простое число - положительное целое число, которое делится только на 1 и на само себя.

[2] [назад] Число, взаимно простое с x, также называют относительно простым с x; у него нет общих с x множителей, кроме 1 и -1. Их наибольший общий делитель равен 1.

[3] [назад] Для полноты следует отметить, что криптография с открытым ключом, применяемая без дополнительных мер, помимо прочего уязвима для атак «человек посередине». При такой атаке злоумышленник выдаёт себя за одну из конечных сторон и предоставляет собственный поддельный открытый ключ, чтобы получить возможность перехватывать связь. Для защиты нужны дополнительные способы проверки подлинности ключа: либо организация безопасного обмена, либо создание центрального органа, выпускающего или удостоверяющего ключи, то есть инфраструктуры открытых ключей, PKI.

[4] [назад] Операция взятия остатка возвращает остаток от целочисленного деления двух чисел. Например, при делении 7 на 3 целый результат равен 2, а остаток равен 1: 7 = 2 * 3 + 1; следовательно, 7 по модулю 3 равно 1.

[5] [назад] Во многих архитектурах PIC необходимо вручную сообщить, что прерывание обработано и больше не должно блокировать последующие прерывания. Для этого служит код окончания прерывания, End of Interrupt, EOI.

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

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

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

Чтобы понять устройство процессора, придётся вернуться во времена, когда о процессорах ещё никто не мечтал. Всё началось довольно невинно в XIX веке, когда математик-самоучка Джордж Буль (1815-1864) разработал простую систему двоичной алгебры как основу для понимания и моделирования формального исчисления. Его подход свёл фундаментальные понятия логики к трём простым алгебраическим операциям, применимым к элементам, которые представляют два противоположных состояния - истину и ложь. Вот эти операции:

• Оператор дизъюнкции OR. Результат истинен, когда истинен хотя бы один операнд^[1].^[2]

• Оператор конъюнкции AND. Результат истинен только тогда, когда истинны все операнды.

• Оператор дополнения, или отрицания, NOT. Результат истинен, когда единственный операнд ложен.

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

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

В механизме Буля нет ничего сложного: ему нужны два противоположных логических состояния - «истина» и «ложь», 0 и 1, «голубой» и «пурпурный», 999 и 999 1/2. Фактический смысл, физическое представление и носитель несущественны; важна лишь произвольно выбранная договорённость, которая сопоставляет определённые состояния носителя конкретному набору логических значений.

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

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

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

На рисунке 2-1 показан простейший механизм из шестерён, который реализует функцию NOR с помощью логики, основанной на вращающем моменте. Бездействующее «выходное» колесо представляет состояние 0; когда к нему приложен вращающий момент, его состояние равно 1. Устройство передаёт вращающий момент от внешнего источника к выходу только в том случае, если момент не приложен ни к одному из двух управляющих «входных» колёс. Теоретически внешний источник энергии не нужен и конструкцию можно упростить; на практике трение и другие трудности сильно осложнили бы создание более сложного набора полностью автономных вентилей.

Рисунок 2-1. Конструкция механического вентиля NOR. На схеме обозначены выход вентиля, возвратная пружина, внешний источник энергии, подвижный вал тяги, вход 1 и вход 2.

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

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

Если отвлечься от неприятной мелочи - необходимости заставить все вентили согласованно работать привычным для нас образом, - можно заключить, что компьютеры способны строиться практически на любой технологии.^[3]

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

Например, набор вентилей XOR и AND позволяет увеличить входное число на 1, а это первый шаг на пути к сложению. Основанная на такой идее схема счётчика показана на рисунке 2-3.

Ага, новый термин! XOR - ещё один «удобный» оператор булевой логики, истинный только тогда, когда истинен ровно один из операндов. В этом отношении он ближе к обычному значению английского слова or. Оператор XOR часто упрощает запись, однако его легко реализовать и другими средствами, сочетая AND, NOT и OR. Определяется он так:

Вернёмся к нашей схеме. Что она умеет? Устройство на рисунке 2-3 принимает число в двоичной записи. В этом примере оно ограничено тремя битами, хотя конструкцию легко расширить для большего числа входов.

Рисунок 2-3. Простейшая схема увеличения на единицу. Входное число I0, I1, I2 проходит через вентили NOT, AND и XOR; результат образуют O0, O1, O2 и O3, последний является переносом.

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

Посмотрим, как это происходит. У нас есть двоичное число, записанное в строку. Мы хотим увеличить его на единицу и, как при сложении десятичных чисел, начинаем с крайней правой цифры.

Там находится двоичная цифра. При увеличении двоичной цифры на 1 возможны лишь два результата: если входная цифра равна 0, выход равен 1, то есть 0 + 1 = 1; иначе выход равен 0, а 1 нужно перенести в следующий разряд, поскольку 1 + 1 = 10. Иначе говоря, выполняются два действия: создаётся результат, равный отрицанию входа - 1 для 0 и 0 для 1, - а если входная цифра равна 1, это нужно запомнить и учесть позднее.

Именно это и делает схема. Для первого входа, I0, самый верхний вентиль обрабатывает значение: инвертирует его и выдаёт на выходе O0, а само входное значение передаёт вентилям, отвечающим за следующий разряд, O1.

Мы увеличили число на единицу; если переноса из предыдущего разряда нет, в остальных разрядах делать нечего. При отсутствии переноса O1 должен повторять I1. Если значение переноса есть, нужно поступить так же, как при добавлении 1 к предыдущему разряду: инвертировать выход и при необходимости передать значение дальше.

Начиная с этого момента каждый последующий выход On, где n > 0, либо непосредственно копируется из In, если переноса из предыдущего разряда нет, либо увеличивается на 1, что снова сводится к инверсии, из-за добавления бита переноса. Поэтому, если In равно 1, перенос из этого разряда Cn также будет равен 1, а On - 0, поскольку в двоичной системе 1 + 1 = 10. Можно заметить, что фактический выход в позиции n - просто результат XOR входного значения в позиции n и бита переноса из разряда n - 1. Следовательно, схема получает On, выполняя XOR перенесённого бита Cn-1 и значения In, а затем выполняет AND переноса из On-1 и In, чтобы определить, нужен ли перенос в следующий разряд:

Рассмотрим пример. Требуется увеличить входное значение 3, то есть 011 в двоичной записи, на 1. Входы таковы:

Схема получает O0, инвертируя I0, поэтому O0 = 0. Поскольку I0 было ненулевым, в следующий разряд также передаётся перенос. В следующем разряде вентиль XOR задаёт O1 = 0: хотя I1 равно 1, из предыдущего разряда пришёл перенос, а 1 + 1 = 10. И снова возникает перенос в следующий разряд.

Ещё в одном разряде I2 = 0, но вентиль AND указывает на перенос из предыдущей строки, поскольку оба предыдущих входа были равны 1. Поэтому результат равен 1. В последний разряд переноса не будет. Получаем:

Или 0100, что, по счастливой случайности, после преобразования в десятичную систему равно 4.

И вуаля - вот операция +1, записанная в двоичном виде.

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

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

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

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

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

Путешествие вышло долгим, но, надеюсь, оно того стоило. Как обычно, оставлю вам несколько, возможно, весьма интересных задач для размышления:

• Хотя основное внимание уделялось влиянию атак по вычислительной сложности на криптографические приложения, проблема не ограничивается этой областью и часто проявляется при обработке закрытой или конфиденциальной информации. Внимательно наблюдая за соответствующей системной службой, безусловно можно вывести разные основные сведения о запросах HTTP или трафике SMTP. Сможете придумать более практичные сценарии?

• Даже если служба не обрабатывает секретные данные, сведения о вычислительной сложности могут оказаться полезны. Рассмотрим приложения наподобие сетевых демонов, которые защищают секреты, выдавая, возможно, чрезмерно общие сообщения об ошибке или успехе. Например, они стремятся не дать нападающему понять, вызвано ли сообщение «неверные данные для входа» ошибкой в пароле или отсутствием пользователя. Но по времени получения сообщения внимательный наблюдатель способен определить, какой путь кода был выполнен и когда возникла ошибка: раньше, при проверке допустимости имени пользователя, или позднее, при проверке пароля. Я предлагаю поэкспериментировать с распространёнными сетевыми службами SSH, POP3 и Telnet и выяснить, существует ли измеримое и устойчивое различие.

• Как всегда, даже лучшая защита от утечки иногда неожиданно отказывает. Кроме того, вычислительная сложность - не единственный способ узнать, что происходит внутри кремниевой микросхемы. Рассмотрим пример: Бихам и Шамир^[5] придумали блестящую схему взлома «защищённых» микросхем смарт-карт. Смарт-карты предназначены для безопасного хранения информации, например персональных идентификационных данных или криптографических ключей, и раскрытия её лишь определённым службам аутентификации и доверенным клиентам. Как выясняется, свойства охраняемых данных или механизма защиты можно вывести, злоупотребляя устройством и вызывая сбои механическим напряжением, высокоэнергетическим излучением, перегревом или сходными внешними факторами, которые заставляют устройство работать неправильно.

Просто захотелось поделиться.

[1] [назад] Операнд - то, над чем оператор выполняет операцию.

[2] [назад] Смысл логического OR отличается от обычного понимания английского слова or: результат остаётся истинным и тогда, когда истинен лишь один параметр OR, и тогда, когда истинны все параметры. В английской речи or обычно подразумевает, что истинен только один вариант.

[3] [назад] Само собой, неэлектрические компьютеры - не выдумка. Среди известных примеров таких устройств - аналитическая машина Чарльза Бэббиджа; определённые надежды дают и технологии наподобие нанотехнологий. См. Ralph C. Merkle, “Two Types of Mechanical Reversible Logic,” Nanotechnology 4 (1993).

Где мы рассматриваем несколько других заманчивых сценариев, возникающих на самом раннем этапе передачи данных.

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

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

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

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

Термин TEMPEST, Transient Electromagnetic Pulse Emanation Standard, возник из засекреченного исследования электромагнитных излучений, заказанного американскими вооружёнными силами в 1960-х годах. Изначально им обозначали набор методов предотвращения побочных излучений в электронных схемах, обрабатывающих конфиденциальные данные. Позднее он превратился в модное слово для общего класса проблем и методов перехвата и восстановления радиочастотных, RF, излучений.

Скептикам этот риск сначала казался скорее плохой научной фантастикой, чем настоящей угрозой. Но в важной исследовательской работе, опубликованной в 1985 году, Вим ван Эк^[1] показал: изображение на мониторе с электронно-лучевой трубкой, CRT, довольно легко восстановить, перехватывая радиосигналы, которые создают высоковольтные цепи внутри устройства. Более того, так и есть на практике.

Обычный CRT, показанный на рисунке 3-1, строит изображение, с очень высокой скоростью последовательно подсвечивая каждый пиксель строка за строкой и ряд за рядом и изменяя силу сигнала в зависимости от текущей точки экрана. Для этого электронная пушка с катодом в задней части устройства испускает узкий пучок электронов. Он попадает в анод - проводящий слой материала экрана, - который в ответ испускает видимые нами фотоны света. Специальная схема модулирует электронный пучок, а набор электромагнитов управляет его положением, заставляя обходить всю область дисплея слева направо и сверху вниз, чтобы создать и обновить экранное изображение. Вим заметил, что генераторы, управляющие электромагнитами, и электроника электронной пушки испускают несколько типов характерных сигналов на стандартных частотах. Обнаружить эти сигналы в радиоспектре довольно просто,^[1] и обычно каждый из них достаточно чист и силён, чтобы построить сравнительно недорогое устройство слежения за CRT-дисплеем даже со значительного расстояния.

Рисунок 3-1. Сканирование и процесс построения изображения на CRT-дисплее. Электронная пушка направляет пятно через горизонтальные и вертикальные отклоняющие пластины; строки 1, 2, 3, 4 и далее последовательно формируются на экране.

Проверяемых сообщений о подобных атаках в реальных условиях, за исключением военных и разведывательных применений, особенно во время холодной войны,^[2] нет, однако в литературе встречаются отдельные рассказы о промышленном шпионаже.^[3]

Очевидно, атака имеет ограничения: нападающий должен находиться рядом с целью. Кроме того, если речь не идёт о слежении за аналоговым CRT-дисплеем, ему потребуется дорогое и сложное оборудование, особенно для современных дисплеев с низким уровнем помех и высоких скоростей CPU и шин. Но предотвращение любой такой атаки всё равно трудно и дорого.

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

Где мы приходим к выводу, что красивое тоже бывает смертельно опасным, и учимся считывать данные со светодиодов.

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

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

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

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

В исследовательской работе “Information Leakage from Optical Emanations” Джо Лагри и Дэвид А. Амфресс^[4] обнаружили новый сценарий раскрытия сигнала в некоторых видах сетевого оборудования, чаще всего в модемах. Они заключили, что наблюдатель способен не просто любоваться волшебными огоньками невооружённым глазом.

В отличие от ламп накаливания, светодиоды обычно имеют короткое время нарастания и спада, то есть включаются и выключаются почти мгновенно. Это неудивительно: высококлассные LED применяются для управления оптоволоконными линиями и другими оптоэлектронными каналами связи. Поэтому мигание светодиода, подключённого к последовательной линии передачи, часто действительно отражает отдельные биты в момент их прохождения по проводу. Если записать активность с достаточной скоростью, сведения можно восстановить как минимум с того расстояния, с которого крошечный огонёк виден невооружённым глазом или через телеобъектив.

Исследование вызвало некоторое волнение в отрасли; позднее проблему одновременно и преуменьшали, и чрезмерно раздували, вследствие чего возникла большая путаница, а изменилось совсем немного. Работа породила множество противоречивых сообщений, но её основная идея проста и поистине прекрасна. Приёмник такого сигнала создать элементарно: столь же дешёвые и распространённые аналоги светодиодов - фотодиоды и фототранзисторы - легко приобрести и столь же легко соединить с компьютером. А зона раскрытия, в отличие от большей части активности TEMPEST из главы 3, не является лишь предметом городских легенд и чисто лабораторных результатов - её можно непосредственно наблюдать и измерять.

В ходе исследования авторы провели ряд опытов и подтвердили успешный приём сигнала с расстояния до 20 метров - чуть меньше 100 футов - без дополнительной цифровой обработки. Здравый смысл подсказывает, что оценка может быть занижена, особенно при хорошей оптике. Авторы использовали объектив 100 мм с диафрагмой f/2,0, но многим фотолюбителям со среднеценовыми зеркальными камерами, SLR, доступны куда лучшие телеобъективы. Готовый расстаться с деньгами человек может купить превосходный объектив с фокусным расстоянием до 1 200 мм.

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

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

Базовая конструкция предельно проста. Нужен один фототранзистор - транзистор со встроенным управляющим фотодиодом, - обычный маломощный NPN-транзистор, Negative-Positive-Negative, для дополнительного усиления сигнала, которое требуется не всегда, и набор потенциометров, возможно порядка 10 кОм для достаточной гибкости, чтобы экспериментально подтягивать напряжение вниз и управлять чувствительностью и порогами схемы. Особых требований к компонентам нет, хотя результат зависит от выбранных деталей. Фототранзистор должен хорошо реагировать на видимый свет, но сгодится любой дешёвый. Для справки: зелёный LED излучает примерно на длине волны 520 нм.

Пример схемы показан на рисунке 5-6.

Рисунок 5-6. Простейшая схема приёмника. Фототранзистор BP 109 или аналогичный управляет NPN-транзистором 2N2222; чувствительность задают Rvar1 и Rvar2, схема подключена между Vcc и GND, а выход ведёт к компьютеру.

Оптимальное рабочее напряжение схемы около 5 В, максимальный ток невелик: источника на 10-50 мА более чем достаточно. Предупреждение: источник с более высоким напряжением может повредить порт или компьютер; то же произойдёт с более мощным источником, если не ограничить ток в схеме.

Фототранзистор необходимо экранировать от внешнего света, например заключить в непрозрачную трубку. У него нет фокусирующего механизма, поэтому дальние сигналы, кроме фонового света, он вряд ли уловит. Для первых испытаний датчик лучше полностью закрыть, имитируя темноту, а затем поднести к LED, возбуждая схему. Можно временно подключить другой светодиод между GND и выходом для проверки. При направлении датчика на источник света тестовый LED должен загораться, а в остальных случаях оставаться довольно тёмным.

Если схема с проверочным LED работает - поздравляю, вы построили модный тестер телевизионных пультов. Дешёвые универсальные фототранзисторы охотно воспринимают инфракрасный свет, поэтому ваше творение должно «переводить» IR в видимый свет, но на этом развлечения заканчиваются. Для чего-то более полезного схему нужно соединить с компьютером. Хороший вариант - интерфейс линейного принтера LPT, если он есть. К сожалению, этот замечательный инструмент аппаратного хакера исчезает из некоторых компактных и модных конструкций.

Изначально LPT создавался однонаправленным, только для вывода, но имеет несколько линий обратной связи состояния - «нет бумаги», «занят», «подтверждение», - через которые принтер должен был жаловаться на проблемы. В PC-совместимой системе данные легко прочесть через порт 0x379, регистр состояния LPT1. Подключив схему к параллельному порту, можно без труда передавать сведения компьютеру. Вы вправе выбрать другой интерфейс, но LPT намного быстрее, скажем, RS-232, и не заставляет разбираться с обыденными протоколами, схемами сигнализации и необычными уровнями напряжения. В отличие от USB и некоторых современных решений, ему не нужны специальные контроллеры, реализующие довольно сложный протокол хотя бы для начала общения с PC.

Линию состояния выбирайте сами. В таблице 5-3 приведена распиновка разъёма DB25 принтерного порта. Затенённые в исходнике строки можно использовать для ввода.

Таблица 5-3. Распиновка LPT

Для соединения схемы с портом просто свяжите точку земли разъёма с землёй схемы, а выходную линию подключите к любому из пяти входных контактов. Сначала не забудьте отключить диагностический LED. Затем следите за портом состояния, поочерёдно освещая и закрывая датчик. Считанное значение зависит от подключения, но точное число неважно, лишь бы в двух случаях оно различалось.

Логике микросхем нужны несколько иные входные уровни, чем тестовому LED, поэтому, возможно, придётся настраивать Rvar2, пока порт не начнёт выдавать разные показания для закрытого и освещённого датчика. Для этого лучше наблюдать порт на компьютере в реальном времени.

Способ наблюдения зависит от операционной системы и языка программирования. В C значение порта читает функция inb(port), поэтому здесь нужно вызвать inb(0x379) и проверить результат. В других языках функция, вероятно, называется похоже: ищите in, inport, readport и так далее. Пользователям Windows может пригодиться встроенная программа debug и её функция i, чтение порта.

Теперь всё готово. Направьте зонд на любой LED устройства, настройте датчик по яркости и начинайте читать чередование света и темноты, выясняя, соответствует ли оно передаваемой информации и каким образом.

Подход позволяет выбирать сигнал с частотой менее миллиона битов в секунду. Этого достаточно для многих интерфейсов, но не обязательно для портов Ethernet, передающих не менее 10 миллионов битов в секунду. При большей скорости LPT, вероятно, достигнет физического предела пропускной способности, но отчаиваться не следует. Пока датчик - фототранзистор - переключается достаточно быстро для нужной связи, вариант остаётся. Помните, что LPT параллельный. Для ускорения, необходимого Ethernet, объедините простейший генератор тактов, схему счётчика и набор защёлок выборки и хранения, например 74LS377, чтобы последовательно записывать данные между чтениями порта компьютером. Короткое время накапливайте сведения, затем через несколько линий состояния или в двунаправленном режиме отправляйте компьютеру сразу несколько битов - образцов - одним пакетом за один цикл чтения, повышая скорость в четыре или восемь раз.

Не стану продолжать, вероятно, лишнее путешествие в мир электроники. Если вы хотите поиграть с высокоскоростной или аналоговой выборкой либо просто любите спаивать детали и подключать их к компьютеру, взгляните на моё довольно полное вводное руководство, тонко замаскированное под проект робота с компьютерным управлением. Его можно найти по адресу lcamtuf.coredump.cx.

А теперь для тех, чьи интересы ближе к практической безопасности: кратко обсудим, как решить проблему, не заклеивая все LED в офисе изолентой.

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

Распространены и более совершенные, надёжные конструкции, в том числе полностью цифровые схемы. Все они могут применяться в концентраторах и коммутаторах, чтобы LED выглядели привлекательнее. Без них быстрое мигание с частотой намного выше 50 циклов в секунду - частоты, считающейся пределом нашей способности воспринимать мерцание, - обычно заставило бы нас видеть тусклый, но как будто непрерывно светящийся огонёк. Дискриминатор заставляет LED чаще получать 1, чем 0, продлевая каждый импульс 1. Благодаря этому LED светится ярче и мигает реже. На рисунке 5-7 показано поведение такого растяжителя: одиночный пик, одна 1, растягивается до трёхкратной длительности, а все 0 остаются без изменений.

Рисунок 5-7. Поведение растяжителя импульсов, 3x. Одиночная 1 во входном сигнале продлевается на три цикла в выходном, тогда как нули не изменяются.

Хотя основное назначение таких устройств эстетическое, как уже говорилось, они кажутся и хорошим способом решить проблему раскрытия информации посредством светового излучения, позволяя атакующему определить лишь некоторые общие свойства трафика. Таким образом, в лучшем случае атакующий способен выяснить только общие его характеристики: например, когда что-то передаётся, а когда нет.^[3]

Но кажущееся хорошим решение не всегда таково. Рассмотрим следующие примерные данные и соответствующий сигнал последовательной линии:

Пример данных, соответствующего сигнала NRZ, исходного сигнала, выхода растяжителя 5x и данных, читаемых по LED после растяжения.

Предположим, сигнал обрабатывается растяжителем импульсов 5x, который продлевает каждую 1 ещё на пять циклов. В первоначальной работе безопасным пределом предлагается 2x, но ради наглядности мы преувеличим.

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

• Очевидно, все участки, где выход растяжителя равен нулю, должны были быть нулевыми и в исходном сигнале.

• Каждая растянутая последовательность единиц должна была быть запущена единицей в начальной позиции исходного потока.

• Каждая последовательность из L единиц первоначально должна была содержать по крайней мере одну 1 на каждые N циклов, где N - коэффициент растяжения этой схемы; иначе в последовательности возникли бы разрывы. Количество единиц в блоке данных, представленном на выходе одним непрерывным растянутым участком единиц, не меньше L/N, округлённого вверх.

• Каждая последовательность заканчивается ровно после N-1 нулей в исходном потоке. Мы знаем, что этим нулям обязательно предшествовала 1, иначе последовательность закончилась бы раньше.

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

Реконструкция: вопросительные знаки обозначают биты, которые нельзя установить однозначно; в отмеченном участке находилась по крайней мере одна 1.

В предыдущем, вполне реалистичном примере из-за растяжения импульсов потеряно менее 9 из 32 битов данных, которые нельзя однозначно восстановить; на рисунке они помечены вопросительными знаками. Тем самым мы восстановили 99,999988% потенциального пространства поиска. Оставшиеся данные приходится угадывать, но, особенно если перехвачены обычные английские тексты, например электронная почта, восстановить их по сравнению с исходной задачей довольно просто. Авторы исследования предполагают, что для сокрытия данных достаточно растяжения времени включения с N = 1,5 или N = 2, однако это не обязательно так.

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

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

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

Оптимальное решение, особенно при других типах кодирования или когда растяжение импульсов по иной причине нежелательно - например, если разработчик хочет избежать впечатления, будто LED непрерывно горит всё время передачи, - состоит в том, чтобы считывать линию с довольно низкой частотой, скажем 20 Гц, и фиксировать результат в регистре. Регистр хранит его до следующей выборки и одновременно управляет LED.

А теперь вернёмся к простому английскому языку.

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

Другими потенциальными направлениями атаки служат многочисленные USB-устройства и другие проприетарные интерфейсы. Как упоминалось ранее, USB является последовательной шиной, а некоторые USB-устройства снабжены индикаторами активности.

Предлагались, частично исследовались или по крайней мере испытывались и разнообразные другие необычные и малоизвестные способы раскрытия информации. Среди них - измерение акустических эффектов перезарядки конденсаторов, когда центральный процессор потребляет разную мощность в зависимости от выполняемой инструкции,^[5] либо исследование устройства - «чёрного ящика» путём статистического анализа его энергопотребления.^[6] И снова: действительно всесторонних исследований каналов раскрытия, отличных от классического излучения EMF, электромагнитного поля, не проводилось, а заняться этим кажется хорошей идеей. Удачи. :-)

[1] [назад] Либо наоборот - в зависимости от конструкции передатчика.

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

[3] [назад] Строго говоря, согласно обсуждению в главе 1, даже это остаётся направлением атаки. Однако оно значительно менее эффективно и практично, поскольку даёт лишь приблизительное представление о происходящем, а не копию данных.

Где на примере любопытного недостатка Ethernet мы узнаём, что выражаться следует точно

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

Тем не менее проблема проявляется совершенно непредвиденными способами, главным образом из-за неудачного выбора слов - или отсутствия нужных слов - в официальных требованиях к реализации драйверов Ethernet. Результатом стала широко распространённая ошибка реализации, достигшая таких масштабов, что заслужила отдельной главы. Она даёт интересный материал для исследования целого класса проблем, в которых никто как будто не виноват.

Протокол Ethernet предоставляет базовые средства распределения байтов по проводу: низкоуровневую схему кодирования данных и формат, вмещающий порцию информации. Кадр Ethernet содержит сведения о локальном назначении переносимых данных, то есть о том, кто их отправляет и кто должен получить, а также краткое описание типа инкапсулированной информации. Предусмотрены и дополнительные способы обнаружения ошибок, после чего весь кадр отправляется потенциальному получателю и всем прочим системам. По своей функции Ethernet похож на схемы инкапсуляции порций данных, применяемые в других средах или приложениях, например Frame Relay, Asynchronous Transfer Mode, ATM, Point-to-Point Protocol, PPP, и так далее.

Возникает вопрос: «Какие данные должен нести такой кадр Ethernet?» Компьютеры используют сотни форматов и прикладных протоколов и способны выполнять самые разные приложения - от научного моделирования до сетевых игр и клиентов чата. Поэтому, хотя данные для удалённого получателя можно просто как есть заключить в кадр Ethernet, обычно это плохая идея: получатель не будет знать, как с ними поступить. Это входящая электронная почта? Картинка с веб-страницы? А может, данные конфигурации? Определить невозможно. Более того, поскольку обычный компьютер почти одновременно выполняет множество программ, различие размывается ещё сильнее.

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

Ethernet использует собственную, уникальную и специализированную схему адресации. Он называет хосты по теоретически уникальным идентификационным номерам аппаратных плат, адресам Media Access Control, или MAC-адресам, записанным производителем в каждом адаптере Ethernet. Эти номера имеют смысл только для Ethernet; для сети любого другого типа они бессмысленны, а отыскать по ним конкретное оборудование, не находясь в локальной среде, почти невозможно. Отсюда возникает вопрос доверия. Например, кто купил плату с адресом 00:0D:56:E3:FB:E4 и где этот человек теперь? Можно ли верить, что перед нами действительно первоначальный покупатель, а не самозванец?

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

Протоколы канального уровня разрабатывались для поддержки связи между локальными узлами или, в некоторых крайних случаях, между двумя постоянными конечными точками общего соединения. Чтобы сделать возможным объединение сетей и некоторые более практические их применения, была разработана иерархическая структура сетевых протоколов, названная Open System Interconnection, OSI, взаимодействием открытых систем.

Модель OSI, показанная на рисунке 6-1, определяет уровень физического соединения как первый, а поверх него строит функции более высокого уровня. Протоколы канального уровня образуют второй уровень, уровень передачи данных, и, как и следовало ожидать, задают способ связи с другими локальными узлами, использующими то же физическое соединение. Эти протоколы переносят данные более высокого протокола, не зависящего от канала и определённого как третий, сетевой уровень модели. Самый заметный пример такого протокола - Internet Protocol, сокращённо IP.

Рисунок 6-1. Пример физической компоновки данных в модели OSI. Кадр Ethernet, уровень 2, заключает в себе пакет Internet Protocol, уровень 3; тот содержит пакет TCP/UDP, уровень 4; внутри находятся прикладные протоколы, уровень 7, и собственно данные. Заголовки последовательно описывают локальные источник и назначение, контрольную сумму и размер, удалённые источник и назначение, а также идентификатор контекста.

Третий уровень предназначен для предоставления сведений об общем назначении трафика, а также универсальной идентификации и источника, и конечного адресата данных посредством сетевой адресации, что облегчает маршрутизацию пакета. В отличие от протоколов второго уровня, третий уровень не отбрасывается и не изменяется по пути и лишён любых особенностей конкретного канала, таких как MAC-адреса, служебные данные CSMA/CD, Carrier Sense Multiple Access with Collision Detection, и тому подобное.

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

Последующие уровни модели OSI, возможно, менее интересны и имеют склонность сливаться друг с другом. Пятый уровень должен обеспечивать надёжность, функции которой часто включаются либо в протоколы четвёртого уровня, такие как TCP/IP, Transmission Control Protocol/Internet Protocol, либо в прикладной уровень. В некоторых случаях они вообще не реализуются, если надёжная связь не нужна. Шестой уровень предоставляет «библиотечные» функции, например распаковку и декодирование данных, и, как пятый, обычно воспринимается частью функций прикладного уровня. Наконец, седьмой уровень является прикладным - здесь данные передаются в конкретном формате.

Обратите внимание: применительно к переносимым данным верхние уровни модели OSI не зависят от нижних. В надлежащий момент нижние уровни можно постепенно отбросить, не потеряв данные и возможность обрабатывать их дальше. Второй уровень отбрасывается в каждой промежуточной системе; третий можно удалить, когда данные доставлены в систему назначения. Четвёртый отбрасывается перед передачей данных клиентскому приложению.

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

Важное следствие такой конструкции состоит в том, что любые лишние сведения, добавленные к пакету на втором уровне во время передачи, не повлияют на то, как адресат интерпретирует информацию IP.

Обсуждая устройство Ethernet в предыдущей главе, я упоминал любопытное требование, возникшее из необходимости надёжно распространять код затора для уведомления о коллизии: минимальный размер кадра Ethernet.

Это требование перешло в официальные спецификации инкапсуляции IP поверх Ethernet, например RFC 1042 “A Standard for the Transit of Internet Protocol Datagrams Over IEEE 802 Networks”,^[1] которые требуют дополнять кадры короче минимальной длины. Дополнение можно выполнять любым образом, и оно не влияет на переносимые данные уровня IP, поскольку длина пакета, указанная в заголовках IP, не меняется. Поэтому получатель не истолкует дополнение как часть трафика верхних уровней модели OSI.

Однако есть небольшая проблема. Хотя RFC требует инициализировать дополнение нулями, он не указывает, кто должен предоставить и подготовить его и на каком этапе работы программного обеспечения это следует делать. Требование определённого значения дополнения по своей природе к тому же довольно произвольно, поэтому ему не уделяют внимания: любое другое заполнение не повлияет на работу протокола, ведь посторонние данные после получения просто отбрасываются.

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

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

Так было до 2003 года, когда Офир Аркин и Джош Андерсон из @Stake решили присмотреться к ней внимательнее. В их работе “EtherLeak - Ethernet Frame Padding Information Leaks”^[2] проблема исследовалась подробнее. Авторы поняли, что множество широко используемых систем - Linux, NetBSD, Microsoft Windows и другие платформы - после изменения длины нового кадра Ethernet не инициализируют память в его конце. Некоторые реализации даже неправильно меняют размер кадра или отправляют аппаратному уровню неверное количество байтов.

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

Утечка ограничена одной сетью Ethernet и потому в обычной среде LAN имеет довольно локальный, некритичный характер. Тем не менее это определённо остаётся достаточно значимой проблемой. И хотя любая локальная сеть отчасти уязвима для прослушивания, конкретно эта проблема наводит на выводы, выходящие за пределы самых очевидных:

• В системах с динамическими буферами исходящих кадров Ethernet, например Linux, дополнение может раскрывать не только предыдущий кадр, но и иное содержимое памяти: редактируемые или просмотренные документы, URL, пароли либо другие конфиденциальные ресурсы. В таком случае внимательный наблюдатель способен получить доступ к сведениям, которые иначе не смог бы перехватить в сети.

• В системах, использующих для подготовки кадров Ethernet только статические буферы, проблему можно применить для обхода средств защиты от перехвата трафика, например коммутаторов, что позволит атакующему перехватить данные другого соединения.

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

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

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

К проблемам сценариев утечки через протоколы, хотя и в несколько ином контексте, мы вернёмся в части III этой книги.

Или почему локальные сети Ethernet невозможно окончательно исправить, как бы мы ни старались

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

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

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

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

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

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

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

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

Традиционно для компрометации системы требовался доступ к магистрали, а не к станции конечного пользователя, поэтому ситуация несколько отличалась от Ethernet. Но современные системы Voice-over-IP, VoIP, быстро устраняют это неудобство, нередко позволяя легко совершать подмену и иные уловки, поскольку чрезмерно доверяют стороне конечного пользовательского устройства.

[1] [назад] Как подсказывает название, к памяти этого типа можно обращаться непосредственно по параметру, значение которого требуется определить. Это экономит время, которое обычно пришлось бы потратить на поиск параметра. Простой пример CAM - библиотечный каталог: чтобы найти одну книгу, не нужно просматривать все книги библиотеки; место поиска определяется тем, что именно вы ищете, то есть сведениями о «содержимом».

Что ещё может произойти внутри локального периметра «нашей» сети? Очень многое!

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

Уже по одной этой причине можно было бы предположить, что разработчики Ethernet не видели нужды включать в конструкцию полноценные функции безопасности. Однако их следует винить в неоправданном оптимизме и неспособности предвидеть неизбежное. Ethernet просто не оставил пространства для лёгкой реализации механизмов целостности, конфиденциальности и проверки отправителя на верхних уровнях OSI, в устройствах и приложениях. Более поздние протоколы и схемы связи пытались обеспечить частичную приватность и некоторую неоспоримость связи, но лишь привели нас к пониманию: достаточную безопасность там невозможно реализовать, не вернувшись назад и не переделав канальный уровень. Единственной оставшейся возможностью стало возведение поверх системы вычислительно дорогих и сложных криптографических заплаток, сама сложность которых способствует появлению множества проблем безопасности, обнаруживаемых из года в год.

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

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

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

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

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

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

Simple Network Management Protocol,^[1] SNMP, является самым популярным способом наблюдения за сетевыми устройствами, а иногда и их администрирования. SNMP часто реализуется и на конечных системах, серверах и рабочих станциях, и на сетевых устройствах - коммутаторах, маршрутизаторах и принтерах.

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

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

Упс. Но неужели из этого действительно может выйти столько дурного?

Хотя этот класс проблем уже упоминался несколько раз и может казаться абстрактным, его последствия реальны, даже если не учитывать восстановление нажатий клавиш, которому была посвящена глава 1. Например, в ходе увлекательной разработки группа немецких исследователей из Institut für Bankinnovation создала коммерческий продукт PSYLock с биометрией на основе манеры печати.^[2] С помощью PSYLock им удалось однозначно идентифицировать, а значит, возможно, и отслеживать пользователей по тому, как они обращаются с клавиатурой.

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

Возможен и более лёгкий вариант атаки, не требующий сложного моделирования, с которым прежде приходилось справляться. В публикации Bugtraq “Passive Analysis of SSH (Secure Shell) Traffic”^[3] Solar Designer и Даг Сонг среди прочего предлагают ещё одну возможную атаку, на этот раз с использованием SSH, распространённого способа подключения к удалённой системе. Хотя SSH зашифрован, в версиях, выпущенных до их исследования, длину пароля можно измерить, тщательно проанализировав размер наблюдаемого пакета при входе: после ввода пользователем пароль отправляется одним блоком данных.

Тот же приём вполне можно успешно применить к другим криптографическим протоколам, которые не принимают активных мер для сокрытия длины пароля путём его дополнения перед отправкой. И, что неудивительно, атаку можно провести простым наблюдением за счётчиком байтов SNMP, а не непосредственным перехватом трафика.

Ещё одна причина не радоваться перспективе враждебного наблюдения за нашей сетью, независимо от того, считаем ли мы видимые противнику данные конфиденциальными, состоит в том, что множество программ нарушает принцип наименьшего удивления. Это фундаментальное правило разработки программного обеспечения, согласно которому программа должна отвечать пользователю способом, который удивит его меньше всего, то есть последовательно, интуитивно, предсказуемо или иным ожидаемым образом. Оказывается, многие программы разных издателей отправляют поразительный объём ценной информации, намного превосходящий ожидания, и часто ставят пользователей в положение, на которое те не соглашались. Как всегда, Microsoft Windows возглавляет стаю этих удивительных программ и великолепно выпускает информацию намеренными, но часто упускаемыми из виду и неочевидными путями. Впрочем, дружелюбный программный гигант не одинок.

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

Сходным и, пожалуй, ещё более удивительным образом, если домашний каталог пользователя в домене находится на сетевом диске, Windows ищет все команды, введённые пользователем в поле Run, сначала на удалённом сервере и только потом локально. Поэтому внимательный наблюдатель получает сведения обо всех командах пользователя через протокол Server Message Block, SMB.

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

Было бы несправедливо закончить главу, проигнорировав проблемы беспроводной замены Ethernet - Wi-Fi.

Беспроводные сети на основе протокола IEEE 802.11 набирают силу и в корпоративном мире, и среди обычных домашних пользователей. К несчастью, задолго до широкого признания и несмотря на намерение обеспечить дополнительную безопасность по сравнению с проводными соединениями Wi-Fi оказался довольно сложен для правильного развёртывания - возможно, потому, что пытался слишком точно идти по стопам старшего брата.

По принципам работы стандарт 802.11 не слишком отличается от Ethernet. Он применяет традиционную схему управления доступом к среде «один говорит, остальные слушают»; разница лишь в том, что носителем сигнала вместо пары проводов теперь служит выделенная радиочастота. Это приводит нас к первой проблеме 802.11.

В мае 2004 года Information Security Research Centre, ISRC, Технологического университета Квинсленда объявил результаты: любую сеть 802.11 на любом предприятии можно за считаные секунды полностью остановить, просто передавая сигнал, который не позволяет другим сторонам попытаться заговорить. Естественно, то же верно для Ethernet, но там сначала необходимо подключиться к сетевой розетке, благодаря чему атакующего гораздо легче отследить, а проблему - решить. Можно просто проверить коммутатор и проследовать по кабелю. Атака не то чтобы неожиданна, но корпоративные пользователи ожидали не этого.

На этом проблемы не заканчиваются. Там, где стандарт 802.11 пытался противостоять атакам на уровне носителя, он потерпел сокрушительную неудачу. Механизм Wired Equivalent Privacy, WEP, создавался для защиты сетей Wi-Fi от прослушивания сетевых сеансов внешними сторонами, то есть для безопасности, примерно сопоставимой с традиционной LAN. Однако в 2001 году исследователи Калифорнийского университета и Zero Knowledge Systems обнаружили в схеме WEP ряд проектных недостатков, доказавших её полную непригодность. К сожалению, уже тогда Wi-Fi был распространён настолько широко, что необходимые изменения оказалось трудно внедрить.^[4]

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

Рисунок 8-1. Воздушная экспедиция Трейси Рида в поисках беспроводных сетей. Предоставлено Трейси Ридом из Copilot Consulting, treed@copilotconsulting.com.

Практика wardriving - оснащение автомобиля ноутбуком с Wi-Fi и поездки по городу в поисках сетей - стала чрезвычайно популярной после открытия, что у большинства крупных предприятий, особенно в больших торговых центрах и коммерческих районах каждого города, беспроводные сети частично или полностью открыты. Злоупотребления часто вполне тривиальны: от бесплатного доступа к сети до рассылки спама или удалённых атак через сеть жертвы. Но риск проникновения в сеть изнутри умелым атакующим реален.

Каков настоящий масштаб проблемы? Достаточно сказать, что в какой-то момент wardriving вышел из моды с появлением warflying, то есть того же поиска, но с самолёта вместо наземного транспорта. В 2002 году Трейси Рид из Copilot Consulting решил облететь Сан-Диего и окрестности с беспроводным сканером. На высоте 1 500 футов он обнаружил почти 400 точек доступа с настройками по умолчанию и, вероятно, свободным доступом в Интернет или внутренние корпоративные сети для любого человека поблизости, как показано на рисунках 8-1 и 8-2. Только 23 процента просканированных устройств были защищены WEP, который в общем случае всё равно легко взломать, или более совершенными механизмами.

Вот так-то.

Рисунок 8-2. Воздушный поиск беспроводных сетей над Кремниевой долиной.

Пассивное снятие отпечатков: едва заметные различия в нашем поведении помогают другим понять, кто мы

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

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

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

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

Я начну с изучения набора основных сетевых протоколов Интернета и их последствий для приватности. Приступим?

Официальный язык Интернета называется Internet Protocol, а самый распространённый диалект обозначен как версия 4. Протокол, заданный в RFC 793,^[1] позволяет стандартизованно передавать данные на огромные расстояния и через самые разные сети с минимальными усилиями. IP-пакеты образуют третий уровень рассмотренной ранее модели OSI и состоят из заголовка со сведениями, необходимыми для доставки порции данных к окончательному месту назначения, удалённой конечной точке, и полезной нагрузки из информации верхних уровней, непосредственно следующей за заголовком.

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

Системы, участвующие в маршрутизации трафика от локального шлюза до сети назначения, читают сведения уровня IP и на основании своих знаний о путях к определённым сетям решают, как передать данные дальше. В данном контексте сеть определяется как совокупность сетевых адресов, находящихся в определённом месте.

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

На рисунке 9-1 приведён пример структуры маршрутизации. Отправитель слева пытается послать пакет системе, чей адрес принадлежит сети C, о которой отправителю ничего не известно. Чтобы обеспечить доставку, он отправляет трафик локальному шлюзу в надежде, что тот знает, где искать получателя. Но эта система, маршрутизатор 1, способна добраться только до собственной сети отправителя и сети A, не имеющей ничего общего с C. Поскольку цель не находится в их локальной сети, маршрутизатор решает, что лучше всего просто передать пакет маршрутизатору WAN более высокого ранга, маршрутизатору 2, который случайно доступен ему локально.

Рисунок 9-1. Наивная схема маршрутизации глобальной сети. Отправитель хочет связаться с системой в сети C. Его шлюз по умолчанию, маршрутизатор 1, может доставить пакет в сеть A или передать дальше. Маршрутизатор 2 непосредственно достигает сетей B и D, а маршрутизатор 3 доставляет трафик в сеть C.

Устройство также не имеет непосредственного соединения с сетью C и может напрямую достичь лишь хостов сетей B и D. Однако оно знает, что адрес назначения обслуживает маршрутизатор 3, который наверняка поймёт, что делать. Поэтому пакет пересылается ему, и теперь маршрутизатор 3 может локально доставить трафик окончательному получателю, после чего все вправе радоваться и праздновать очередной успех.

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

Поэтому, когда трафик достигает магистрального маршрутизатора, применяется более разумная стратегия. Магистральный маршрутизатор, находящийся в ведении сетевого оператора, - это выделенное устройство WAN, связывающее множество сетей под управлением конкретного провайдера в сложную сущность, называемую автономной системой. Магистральные маршрутизаторы обычно имеют интерфейсы к другим крупным маршрутизаторам и используют усовершенствованный алгоритм поиска пути и объёмную «телефонную книгу» сетевых блоков и их местонахождения, динамически управляемую Border Gateway Protocol. Так они находят лучший маршрут данных к системе назначения и не передают вслепую задачу доставки трафика какой-нибудь системе в надежде, что та сумеет правильно переслать его дальше.

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

Отдельный адрес IPv4, уникально идентифицирующий конечную систему во всей связи Internet Protocol, устроен довольно просто: он состоит из 32 битов, для удобства разделённых на 4 байта, что в сумме даёт 4 294 967 296 возможных адресов. Адрес традиционно записывается четырьмя 8-битными значениями от 0 до 255, разделёнными точками. Например, 195.117.3.59 соответствует 32-битному целому числу 3279225659.

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

При определении сети набор старших битов IP, теоретически от 1 до 31, а на практике от 8 до 24, резервируется как сетевой адрес. Фиксированную часть адреса разделяют все адреса, принадлежащие этой конкретной сети и предположительно направляемые в неё. Оставшимся младшим битам можно свободно присваивать значения, выдавая адреса системам внутри сети.

Исторически, согласно RFC 796,^[2] размер сети, то есть количество зафиксированных старших битов, зависел от адреса и мог быть определён по самому сетевому адресу. Только на основании самых старших битов адреса группировались в сети класса A, где фиксированы 8 старших битов и доступно более 16 миллионов пользовательских адресов; сети класса B с 16 фиксированными битами и более чем 65 000 хостов; либо сети класса C с 24 фиксированными битами и 256 возможными хостами. Поэтому, если IP-адрес вашей системы начинается с числа 1, можно сказать, что перед нами сеть класса A и все остальные системы с этим префиксом находятся рядом с вашей машиной.

В своё время это казалось удобным, но адресное пространство IPv4 значительно сократилось после того, как первые пользователи, Армия США, Xerox, IBM и другие гиганты, на заре Интернета получили по нескольку сетевых адресов класса A и, похоже, не слишком стремились вернуть их, хотя не использовали для общедоступной инфраструктуры и малой доли доставшегося пространства. Кроме того, после коммерциализации Интернета, когда IP-адреса стали ресурсом, за который пользователи платили, те начали требовать части адресного пространства, лучше соответствующие потребностям: одним требовалось всего четыре адреса, другим - непрерывное пространство из 8 000. Пользователи стали перепродавать или иначе делить своё пространство Интернета.

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

Как показано на рисунке 9-2, фиксация 24 битов в сети 195.117.3.0 оставляет 8 изменяемых младших битов. Это позволяет создать 256 принадлежащих сети адресов от 195.117.3.0 до 195.117.3.255, хотя некоторые реализации заставляют резервировать первый и последний для специальных целей, оставляя лишь 254 возможных хоста. С таким сравнительно простым описанием сети адресов легко определить, какие адреса принадлежат ей и потому должны доставляться системе, являющейся её шлюзом, а какие нет.

Рисунок 9-2. Правила сетевой адресации. Чтобы считаться принадлежащим конкретной сети, адрес должен совпадать с её «образцом», здесь 195.117.3.0, во всех битах, отмеченных маской. Адрес 195.117.3.59 допустим, а 195.117.4.59 не принадлежит той же сети, поскольку часть фиксированных битов не совпадает.

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

Мы знаем, как данные попадают из точки A в точку B, но происходящее по дороге интереснее выбора пути. Поэтому присмотримся к тому, чем обмениваются маршрутизаторы и наши конечные системы. Можно подумать, что больше всего интересного содержит сама полезная нагрузка пакетов Интернета, учитывая всю личную почту и странные материалы, которыми каждую секунду обмениваются по всему миру, но здесь есть гораздо больше, чем видно глазу.

Формат IP-пакетов, применяемых для маршрутизации данных, и сведения четвёртого уровня, заключающие сами прикладные данные, определены RFC довольно строго и с удивительно малой неоднозначностью. Однако даже при грамотной реализации стека TCP нижележащая информация способна последовательно давать получателю значительно больше ценных сведений, чем сама полученная полезная нагрузка. Раскрытие на этом уровне непреднамеренно и неожиданно, но, чтобы узнать о нём больше, необходимо внимательнее рассмотреть устройство базовых протоколов.

Одно из следствий множества решений, принятых при создании IPv4, - отсутствие разумной гарантии надёжности даже при надёжной работе самой сети. Хотя номера IP ID призваны уменьшать риск столкновений при сборке, их сравнительно небольшой 16-битный размер, допускающий 65 536 значений, позволяет изредка возникать проблемам, когда одновременно собираются два пакета с одинаковым IP ID. Кроме того, контрольных сумм IP-заголовка попросту недостаточно для надёжной защиты целостности: хотя это маловероятно, случайное изменение пакета всё же может дать ту же сумму. А если сеть действительно откажет, выяснить, какие данные пропали, невозможно, даже если отказ вызван столь простой причиной, как кратковременная перегрузка одного сетевого компонента.

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

TCP и, в меньшей степени, UDP не только предоставляют крайне необходимую защиту трафика, но и позволяют указать получателя или отправителя на уровне, выходящем за рамки указания определённой системы.

В то время как IP-заголовок содержит лишь достаточно сведений для маршрутизации трафика между двумя системами и недостаточно для выбора приложения, которому следует доставить информацию, UDP и TCP идут дальше: переходят в область конечной системы и сообщают получателю, какому приложению направить входящие данные.

Как устройство этих протоколов связано с приватностью пользователя? Ответ несколько странен. Хотя устройство пакетов IP, TCP, UDP и ICMP в целом довольно строго, а передаваемые в заголовках сведения не особенно многословны, различия в том, как операционные системы добавляют в пакеты информацию, позволяют определить не только тип используемой ОС, но даже конкретную версию экземпляра машины. Различия особенно заметны при работе с трафиком, который спецификация не обсуждает ясно и должным образом или который не анализируется в обычных процедурах контроля качества, например входящим пакетом с незаконным сочетанием флагов SYN+RST.

Интенсивные исследования различения систем посредством стрессового испытания реализаций показали, что можно уверенно заключить: двух одинаковых реализаций семейства IP в операционных системах не существует. Сложный анализ часто позволяет отличить одну систему на немного разных платформах или близкие версии одной системы. Инструменты активного анализа вроде NMAP Фёдора, средства снятия отпечатков TCP/UDP и сканера портов, и Xprobe Офира Аркина, средства снятия отпечатков ICMP, эксплуатируют недостатки и странности каждой системы. Они определяют семейство и версию ОС, посылая разнообразные искажённые или необычные пакеты, а затем измеряя и анализируя вызванные ответы.

В этой главе мы рассмотрели самые распространённые показатели определения ОС удалённого хоста и отслеживания его пользователей без их ведома. Но для тех же и более широких целей можно применять множество увлекательных, менее исследованных сторон связи.

Например, один интересный вариант снятия отпечатков связан не с самими пакетами, а с измерением времени и частоты ответов для отдельных сообщений ICMP, повторных передач TCP и подобных функций. Значения всех тайм-аутов и числа повторов позволяют точно и однозначно опознать систему. Проект CRONOS, основанный на исследованиях Франка Вейссе, Оливье Курте и Оливье Хина из Intranode Research Team, создаёт средство активного снятия отпечатков по такому набору показателей, но пассивные применения столь же заманчивы.

Ещё одно многообещающее направление - сочетание и измерение других аномалий или необычных настроек: использования отправителем определённых меток времени, номеров последовательности, совпадающих с номерами подтверждения, необычных флагов, полезной нагрузки в управляющих пакетах, параметра EOL и так далее. Они также помогают различать ОС, хотя часто свойственны небольшому набору реализаций. Алгоритм выбора начальных номеров последовательности нередко служит ценным источником сведений, как станет видно в следующей главе.

Эти показатели позволяют точно определять ОС и её конфигурацию, а также параметры сети, эффективно и незаметно отслеживая пользователей. Хотя это может казаться невероятным, созданный мной инструмент p0f реализует большинство приёмов и полностью пассивно собирает и анализирует сведения по пакетам SYN, SYN+ACK и RST с высокой долей успеха.

Рассмотрим пример пакета, чтобы увидеть эффективность подхода. Ниже приведён набор важных параметров, извлечённых из настоящего TCP-пакета, захваченного в сети. Что они сообщают об ОС отправителя?

Очень многое. Вот что можно вывести из наблюдений:

• Поскольку в IP-заголовке установлен DF, система должна применять обнаружение MTU пути. Подходящие системы - новые версии Linux, FreeBSD, OpenBSD, Solaris и Windows. Можно исключить IRIX, AIX, многие коммерческие межсетевые экраны^[6] и другие системы, не реализующие PMTUD по соображениям надёжности.

• Время жизни пакета равно 57. Мы знаем, что начальный TTL не мог быть ниже, поскольку по пути он способен только уменьшаться.

Маловероятно, что значение превышало 87, ведь тогда система находилась бы действительно далеко. Это согласуется со многими Unix, использующими начальный TTL 64, но исключает Windows с 128, версии Solaris до 8 с 255 и несколько сетевых устройств с 32.

• Идентификационный номер пакета ненулевой. Это исключает Linux 2.4 и новее, а также несколько недавних выпусков других популярных ОС.

• Исходный порт находится в самом распространённом диапазоне от 1 024 до 4 095. Само по себе это не исключает системы, но можно уверенно предположить, что до данного соединения машина установила более 2 700 других и вряд ли находится за маскарадингом.

• Выбор и порядок параметров, MSS, Selective ACK, Timestamp, Window scaling, характерны для Linux 2.2 и новее.

• Размер окна кратен MSS, а именно MSS*22. Единственная подходящая система - Linux 2.2.

• В пакете не наблюдается аномалий, нарушений RFC или иных странностей, что подтверждает гипотезу о Linux.

• Maximum Segment Size указывает соединение Ethernet или PPP через модем с MTU 1 500.

• Время непрерывной работы системы составляет приблизительно 19 дней, а находится она на расстоянии 7 систем.

Разумеется, отдельные показатели могут меняться приложениями или пользовательскими настройками. Например, пользователи склонны изменять TTL либо включать и выключать настройки, прочитав руководства по оптимизации сети или запустив приложения «системного доктора». Но цепочка выводов из наблюдений даёт надёжный способ определить ОС машины, выбрав систему, которая лучше всего совпадает по большинству категорий.

В данном случае есть веские основания считать, что перед нами Linux 2.2, а отправитель подключён к Интернету через Ethernet или коммутируемый модем. Из этого также следует, что система находится в 7 переходах, 64-57, где 64 - начальный TTL Linux, и работает около 20 дней. Если за IP скрываются несколько пользователей, их легко подсчитать и различить сеансы по характеристикам систем и данным меток времени, если они доступны.

Из-за сложности обычного стека IP предотвратить снятие отпечатков вообще чрезвычайно трудно. Но можно устранить отдельные проблемы и отключить известные средства, определив, на какой параметр они опираются больше всего, и изменив его. Например, некоторые решения фильтрации пакетов, такие как pf в OpenBSD, предоставляют нормализацию, гарантирующую одинаковый «вид» всего исходящего трафика. Это способно в некоторой степени помешать отдельным сторонам снятия отпечатков или лишь осложнить его, снизив точность популярных программ, но полностью проблему не решает.

Даже тщательное и кажущееся исчерпывающим ручное или автоматическое изменение отдельных настроек ОС и TCP способно лишь затруднить идентификацию: некоторые варианты поведения скрыты глубоко в ядре и не настраиваются. Например, довольно трудно поменять порядок параметров пакета. Более того, ручные изменения рискуют внести в исходящие из системы пакеты уникальные признаки, ещё сильнее повредив приватности и анонимности.

К счастью, некоторые решения противодействуют определённым испытаниям. Например, IP Personality Гаэля Руаллана и Жан-Марка Саффруа изменяет стек TCP, чтобы для конкретных средств он казался исходящим от другой ОС. При желании можно заставить NMAP считать систему лазерным принтером Hewlett-Packard. Но возникают проблемы. Во-первых, легко ослабить стек TCP, пытаясь изобразить устройство, чей стек изначально слаб. Если ради соответствия свойствам принтера использовать простейшие номера последовательности во всех соединениях, рано или поздно кто-нибудь воспользуется этим и легко нарушит или изменит трафик. Кроме того, программы вроде IP Personality действуют лишь против самых популярных, известных и хорошо документированных средств, не гарантируя успеха против остальных: каждый инструмент изучает свои признаки и толкует их по-разному. Можно надеяться обмануть только наименее решительных и самых наивных «массовых» атакующих, использующих известные вам средства.

[1] [назад] Строго говоря, хотя для обсуждения это не имеет особого значения, контрольная сумма IP основана на 16-битном дополнении до единицы суммы дополнений до единицы проверяемых данных.

[2] [назад] Строго говоря, 65 536, однако порт номер 0 использовать не следует. Разумеется, операционная система и её приложения могут это разрешать, нарушая стандарт.

[3] [назад] Кевин Митник, один из самых известных и спорных хакеров в чёрной шляпе, скомпрометировал компьютер Цутому Симомуры, выдав себя посредством подделки TCP за одну из доверенных рабочих станций. Поступок сильно расстроил господина Цутому и, судя по большинству рассказов, в долгосрочной перспективе не особенно помог Кевину.

[4] [назад] «Требуется» в смысле «необходимо для правильной обработки». Некоторые процессоры значительно теряют производительность при доступе к многобайтовым структурам, не выровненным по 32 или 64 битам; другие прямо требуют такого выравнивания, иначе вызывают фатальное исключение, ловушку выполнения, и отказываются исполнять операцию. Разумеется, непослушный отправитель может намеренно поместить невыровненные данные в буфер, надеясь, что система получателя сгорит при получении пакета. Вменяемая операционная система сначала проверит данные или скопирует параметр в правильно выровненную область перед обработкой. Но вменяемость системы нельзя принимать на веру.

[5] [назад] Некоторые разработчики даже устанавливают бит Must Be Zero, который в законном применении не должен быть установлен никогда, предположительно просто как заявление о стиле.

[6] [назад] Межсетевой экран по существу является фильтрующим маршрутизатором, который часто также способен понимать характеристики трафика верхних уровней и принимать по ним решения.

[7] [назад] Сам выбор времени не так сложен, как кажется. Атакующий может послать вредоносный второй фрагмент чуть заранее; получатель создаст буфер сборки и определённое время будет ждать остальные части. Когда придёт первый законный фрагмент, содержимое буфера признаётся полностью восстановленным без ожидания настоящей второй части.

Где мы разбираем древнее искусство определения сетевой архитектуры и местонахождения компьютеров

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

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

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

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

Однако ещё не всё потеряно. Как отмечалось ранее, точному применению пассивного снятия отпечатков мешают некоторые проблемы. Надёжность традиционного определения ОС страдает из-за лёгкости обмана наблюдателя посредством тщательной настройки некоторых или всех сетевых параметров наблюдаемой системы. Даже если полностью изменить все настройки непросто, частичного изменения может хватить, чтобы сорвать отдельные попытки автоматического анализа - ура! - или ввести в заблуждение исследователя злонамеренного происшествия - упс. Проблема не массовая и потому не беспокоит статистический анализ, но в отдельных случаях вызывает опасения.

Кроме того, возможности отслеживания и подсчёта пользователей в мучительно разобранном в главе 9 подходе почти полностью зависят от таких параметров, как метки времени пакетов TCP/IP. Все прочие признаки либо стандартизованы, либо имеют слишком мало вариантов для однозначной положительной идентификации одного компьютера, кроме самых необычных случаев. Если данные недоступны, потому что конкретное расширение производительности отключено, как в большинстве систем Windows, точная идентификация невозможна.

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

Рисунок 10-1. Пассивное снятие отпечатков позволяет картировать сложную и даже недоступную сеть простым наблюдением за трафиком некоторых узлов. Особенно важны свойства ОС, TTL и MSS пакетов; по различиям наблюдаемых характеристик выводится наличие остальных компонентов. Непосредственно наблюдаемые активные компоненты отмечены отдельно. Читателю предлагается определить, как окончательно построить эту карту, наблюдая лишь внешний трафик.

Однако другой, возможно более интересный, многообещающий и сложный способ легко устраняет недостатки. Новый подход крайне трудно обмануть и почти повсеместно можно применять для отслеживания систем. Что ещё интереснее, он позволяет различать экземпляры совершенно одной системы в совершенно одинаковой конфигурации, выводя обнаружение маскарадинга на новый уровень. Он использует свойства механизма генерации номеров последовательности TCP/IP и вдобавок умеет создавать красивые картинки.

Напомним из предыдущей главы: начальные номера последовательности используются TCP для целостности сеанса и фактически гарантируют его самую базовую устойчивость безопасности.

Единственный по-настоящему универсальный способ защитить открытый сеанс TCP/IP от внедрения данных, захвата или подделки совершенно посторонним человеком - выбирать начальные номера непредсказуемо для атакующего. Это уменьшает его шанс сделать верное слепое предположение и подделать пакет, который будет принят законной частью чужого сеанса, до практически несущественного уровня, даже если атакующий штурмует систему тысячами пакетов в надежде, что хотя бы у одного номер приблизительно совпадёт.

В начале 1980-х аспекты безопасности связи TCP не казались достойной беспокойства проблемой: Интернет был довольно малой, замкнутой и, возможно, слегка элитарной средой учёных и им подобных. Поэтому спецификация RFC протокола TCP не задавала требований к выбору начальных номеров, а почти все ранние и некоторые не столь ранние реализации стека TCP/IP применяли простейшие алгоритмы на основе времени или счётчика, выдававшие последовательные числа для следующих соединений. Тогда рандомизация казалась ненужной тратой драгоценной вычислительной мощности. Кроме того, она без необходимости повышала вероятность столкновения номеров. Столкновение возникает, когда два ISN для последовательных соединений с хостом слишком близки и старые, несвоевременно пришедшие пакеты могут быть истолкованы в контексте неправильного соединения. Естественно, в краткосрочной перспективе случайный выбор скорее создаёт столкновения, чем последовательное увеличение.

С 1980-х Интернет, конечно, сильно развился: выросла доступность, база пользователей быстро менялась и увеличивалась, а по проводам передавалось всё больше важных данных, отчего вопросы безопасности стали актуальнее. К сожалению, популярные и надёжные механизмы защиты целостности и приватности до сих пор не догнали расширение Интернета. Не все службы поддерживают шифрование, не все пользователи знают, когда его применять, а главное - большинство не умеет правильно проверять криптографические сертификаты удалённых сторон.

Со временем, особенно после широко распространённого практического злоупотребления слабой генерацией ISN в середине 1990-х, хотя в основном в сетевых чатах и подобных службах, стало ясно, что потокам TCP/IP нужна хотя бы простейшая защита целостности. Это важно даже для малой доли криптографически защищённого трафика: нарушение уровня носителя внедрением мусора или пакетов RST столь же нежелательно, пусть результат ограничен отключением, отказом в обслуживании, а не внедрением данных.

Поскольку единственный способ исправить положение без капитальной перестройки почти всех известных человечеству схем связи TCP состоял в том, чтобы сам протокол было трудно атаковать, многие разработчики начали отходить от устаревших и опасных механизмов ISN с простым увеличением на единицу. Усилия действительно повысили устойчивость соединений к слепой подделке, но одновременно открыли интересные направления сбора сведений для более совершенного снятия отпечатков систем и сетей - ради оценки безопасности или спланированной атаки.

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

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

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

Если видна зависимость между выходом генератора в момент t и в t+x, атакующий может заранее подключиться перед соединением, которому надеется помешать или которое хочет полностью подделать, чтобы получить выход ISN в t. По наблюдаемому номеру он затем определит ответ другой стороны в будущем, t+x, и подделает допустимый пакет нового соединения, хотя непосредственно используемый ISN не видит.

С этой мыслью в 2001 году я провёл исследование универсального способа изучения менее очевидных временных зависимостей в последовательностях ISN удалённых систем. Результатом стала работа “Strange Attractors and TCP/IP Sequence Number Analysis”,^[1] где некоторые алгоритмы рассматривались подробнее и предлагался способ обнаруживать тонкие связи за пределами самых очевидных известных закономерностей и недостатков. Подход хорошо знаком миру прикладной математики, но для сетей был весьма новым.

При работе с генератором ISN как чёрным ящиком в современной закрытой системе виден только его выход, последовательность 32-битных значений пакетов TCP/IP, но не алгоритм. Код многих ОС проприетарен и хорошо охраняется, находясь далеко за пределами досягаемости простых смертных. Даже в открытой системе исходники бывают хитрыми и вводящими в заблуждение, заставляя повторить ошибки первоначального разработчика.

Типичный вход для оценки мог бы выглядеть так:

Сразу ли очевидна зависимость этих чисел? И если да, существует ли сравнительно универсальный способ, которым компьютер сможет проследить её и более сложные схемы?

Элегантное решение казалось далёким. Я хотел разработать способ определения универсальных свойств нижележащего алгоритма ISN лишь по его выходу. Но перед этим для облегчения анализа было желательно и удобно предположить: поскольку многие реализации повторяют определённые арифметические операции, лучше наблюдать изменения последовательных результатов, а не абсолютные значения. Для таких алгоритмов это выгодно и почти не повредит остальным возможным генераторам. Для этого вычислим дискретную производную входной последовательности: приращения между элементами S. Последовательность дельт D, естественно начиная с t = 1, задаётся:

В примере получается:

Если отбросить сами значения и рассматривать только динамику ISN, нижележащая зависимость становится заметнее и обычно останется такой для всех реализаций с данным типом арифметики. Для систем без простейшей итеративной арифметики преобразование практически не имеет значения и существенно не влияет на качество данных анализа.

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

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

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

Координаты вычисляются так, чтобы вторая соответствовала значению в t-1, третья - наблюдению в t-2 и так далее. В данном применении для времени t:

Последовательность новых троек (x, y, z) позволяет изобразить поведение генератора ISN в трёхмерном пространстве. Положение точки зависит от текущего значения и нескольких предыдущих результатов, поэтому даже довольно сложные зависимости создают абстрактные, но заметные неравномерные картины плотности в фазовом пространстве - уникальный портрет алгоритма. В отношении таких портретов термин «аттрактор» означает форму, отображающую динамику системы: множество или пространство представляет «след» состояний, через которые система циклически проходит либо эволюционирует, будучи предоставленной самой себе.

На рисунке 10-2 показан набор данных, первоначально выглядевший так:

Рисунок 10-2. Трёхмерное представление набора данных, описанного в тексте.

На рисунках 10-3 - 10-5 показаны несколько других распространённых, но не обязательно очевидных схем зависимости.

Рисунок 10-3. Трёхмерное представление набора данных, полученного от сложной, но небезопасной функции генератора случайных чисел.

Рисунок 10-4. Представление PRNG без сильной корреляции, но с заметными статистическими смещениями.

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

Прежде чем отвечать, позвольте прервать себя и включить небольшую галерею интереснейших результатов, полученных при написании первоначальной работы. Она показывает разнообразие и красоту наблюдаемых узоров, следуя древнему правилу: один трёхмерный график стоит тысячи слов. На рисунках 10-6 - 10-14 приведены портреты PRNG нескольких операционных систем.

Не все графики нарисованы в одинаковом масштабе; некоторые фигуры значительно меньше других. Масштаб и прочие параметры читаются в верхней строке каждого графика, как показано на рисунке 10-6.

Рисунок 10-5. Распространённая схема временной зависимости, наблюдаемая в несовершенных условиях испытания.

Рисунок 10-6. Windows 98. Показанное множество имеет диаметр около 128, то есть последовательные ISN увеличиваются на число с приблизительно 7 битами «случайности». Внутри заметна сильная частотная закономерность, похожая на один из предыдущих примеров и, возможно, указывающая на простейшую зависимость от времени во всех результатах. Размер аттрактора тревожно мал. Верхняя строка показывает текущие положения X и Y, коэффициент увеличения, видимый диапазон, битовый размер области просмотра, её поворот, число видимых и общее число точек, а также процент видимых.

Рисунок 10-7. FreeBSD 4.2. Равномерный куб шириной 16 битов, вероятно, признак малых, но действительно случайных приращений на каждом шаге.

Рисунок 10-8. HP-UX 11. Странная структура в форме X-крыла шириной 18 битов, явно неравномерная и, вероятно, указывающая на высокий уровень корреляции ущербного PRNG.

Рисунок 10-9. Mac OS 9. Сходная, но немного иная 17-битная структура.

Рисунок 10-10. Windows NT 4.0 SP3. Снова сильный узор притяжения и крошечный аттрактор шириной 8 битов.

Рисунок 10-11. IRIX 6.5. Крайне неравномерное случайное облако шириной 16-18 битов; вероятно, ущербный алгоритм.

Рисунок 10-12. NetWare 6. Кажущаяся случайной система с 32-битным облаком аттрактора, которое, однако, неравномерно и состоит из множества участков высокой плотности.

Рисунок 10-13. UNICOS 10.0.0.8. Странное 17-битное облако с неравномерными вытянутыми участками повышенной вероятности попадания.

Рисунок 10-14. OpenVMS 7.2, стандартный стек TCP/IP. 32-битная структура с малой случайностью и сильными, но довольно необычными корреляциями, указывающими на сломанную конструкцию PRNG.

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

Ключ к успешной атаке - понимание того, что координата x каждой точки зависит от Dt, то есть от номеров последовательности в моменты t и t-1, поскольку Dt = St - S(t-1). Координата y зависит от D(t-1), ISN в t-1 и t-2, а z - от D(t-2), ISN в t-2 и t-3.

Предположим, атакующий отправил три зонда удалённой системе, структура аттрактора ОС которой уже нанесена на карту. Зонды соответствуют моментам t-3, t-2, t-1 и, естественно, достаточны для восстановления координат y и z точки, обозначающей текущее поведение системы в аттракторе.

По наблюдавшимся неравномерностям атакующий может вывести значения x для известных y и z, которые вероятнее других. Координаты y и z соответствуют одной линии пространства аттрактора, перпендикулярной плоскости x, как на рисунке 10-15: совокупности точек со всеми возможными x, но известными остальными координатами. Места, где линия пересекает области высокой плотности или проходит рядом с ними, образуют набор наиболее вероятных x. Области самой низкой плотности, очевидно, реже соответствуют правильному x: при предыдущих измерениях точки аттрактора там не появлялись.

Способность построить набор кандидатов x для известных y, z - крупный шаг к успешной атаке. Зная ранее полученный S(t-1), атакующий легко вычисляет St для каждого кандидата x, то есть Dt:

Получив три предыдущих номера S(t-3), S(t-2), S(t-1), атакующий определяет набор вероятных кандидатов на следующий St, который атакуемая система, скорее всего, выберет для нового соединения - уже не начатого самим атакующим, но того, в которое он надеется вмешаться.

Затем он проводит атаку, отправляя пакеты TCP/IP с номерами-кандидатами. Угадывать с первой попытки не обязательно: все неверные варианты удалённая реализация просто проигнорирует. Но как только значение поддельного пакета совпадёт с ожидаемым номером в пределах ожидаемого окна, трафик будет принят, победив защиту целостности сеанса TCP/IP.

Рисунок 10-15. «Линия атаки», пересекающая аттрактор.

Разумеется, у атаки есть оговорки:

• наблюдаемая динамика может быть локальной для условий наблюдения или самого источника, хотя, судя по достигнутой успешности против распространённых реализаций, это маловероятно;

• если набор кандидатов особенно велик, как у алгоритмов с равномерными облаками аттрактора без явных неравномерностей, приём становится довольно непрактичным: для правильного предположения требуется слишком много попыток;

• поскольку обычно невозможно получить всю последовательность значений реализации ISN, ведь у некоторых систем длинные или неограниченные циклы, полный аттрактор построить нельзя. Поэтому применяется приближение: значение считается кандидатом, если точка находится в заданном радиусе от определённой точки линии (y,z), что компенсирует пробелы даже в достаточно плотных областях аттрактора.

Чтобы сохранить осмысленность результатов и получить способ сравнительной оценки качества генератора ISN, я решил эмпирически оценить вероятность успеха с ограниченным числом попыток. В частности, определить вероятность попадания в верный номер за 5 000 попыток, предполагая, что атакующий с сетевым соединением от слабого до среднего способен послать за короткое время не более 5 000 пакетов.^[1]

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

Вот некоторые результаты для систем из галереи аттракторов:

Подход оказался явно довольно эффективным^[2] и побудил многих поставщиков переделать алгоритмы либо пересмотреть заявления об их безопасности. В последующем исследовании, опубликованном годом позже, в 2002-м, я изучил некоторые изменения, и далеко не все оказались удовлетворительными.

Но главный вопрос: какое отношение всё это имеет к пассивному снятию отпечатков ОС?

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

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

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

Но разве это всё? Конечно нет!

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

Прочитав мою работу по анализу ISN TCP/IP, Том Вандепул написал превосходный инструмент ISNProber. Он использует анализ номеров для различения нескольких экземпляров одной системы, исходя из того, что две отдельные системы, скорее всего, находятся в разных местах аттрактора.

В простейшем случае ISNProber определяет, что за общим адресом скрываются две системы, по виду наблюдаемых ISN. Для простоты предположим, что система Y использует генератор с увеличением на единицу. Мы обращаемся к IP веб-сайта www.example.com и хотим определить число систем. Сначала опознаём www.example.com как Y, устанавливаем несколько последовательных соединений и наблюдаем ISN: 10, 11, 534, 13, 540, 19.

Очевидно, меньшие числа образуют последовательность компьютера, который либо обработал меньше трафика, либо работает меньше времени, 10, 11, 13, 19, а большие относятся к другой системе. Значит, два компьютера совместно обслуживают один общедоступный IP, возможно, за балансировщиком нагрузки. Меняя интервалы получения образцов, можно тщательно исследовать тип балансировщика, его политику распределения запросов и получаемый трафик.

Подход способен не только различать системы за общим адресом, но и отслеживать пользователей Y при переходе с одного IP на другой, пока они не перезагрузят машину и не сбросят счётчик ISN. У систем со схемой сложнее примера различение труднее, но определённо возможно, если ISN не полностью случайны во всех 32 битах. В последнем случае возникают опасения столкновений.

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

Защититься от предсказания номеров довольно просто, и хорошие решения вроде спецификации RFC 1948 Стивена М. Белловина^[2] доступны давно. Но предотвратить пассивный анализ чисел очень трудно: проблема возникает не только из слабости алгоритмов, но и из их разнообразия, из-за которого немногие системы имеют одинаковый след ISN. Даже реализации RFC 1948 и другие криптографически безопасные генераторы на внешней энтропии могут значительно различаться поведением в зависимости от тонкостей алгоритма и представлений автора о достаточных для противодействия атаке значениях.

Некоторой защиты можно добиться межсетевым экраном с отслеживанием состояния, переписывающим все номера последовательности исходящих пакетов,^[3] благодаря чему все системы защищённой сети выглядят примерно одинаково. К сожалению, функцию предлагают лишь некоторые решения, и лишь некоторые способны получить от неё пользу.

Анализ фазового пространства полезен далеко за пределами генерации номеров последовательности. Другие параметры, выбираемые псевдослучайно или по внутренней схеме, - поля ID пакетов IP, идентификаторы запросов DNS, как на рисунке 10-16, создаваемые приложениями «секретные» cookie пользовательских сеансов и так далее - можно успешно анализировать для поиска недостатков конструкции либо опознания реализации, упрощения дальнейшего анализа или содействия атаке.

Рисунок 10-16. Интересный узор аттрактора реализации разрешения имён Linux.

Некоторая работа в этом направлении уже выполнена или ведётся. В исследовании, отчасти связанном с моей первоначальной работой, Джо Стюарт рассматривает проблемы DNS,^[3] возникающие с развитием механизмов предсказания номеров. Он отмечает, что протокол DNS на UDP предлагает явно недостаточные способы проверки запросов даже против «малобюджетных» атак подделки, а низкое качество уникальных идентификаторов запросов разных реализаций дополнительно ослабляет схему и делает её элементарно уязвимой для вредоносного внедрения данных. Учитывая, что DNS - одна из основных служб Интернета, а перспектива подделать ответ DNS популярного сайта и перенаправить всех пользователей конкретной сети на другую страницу отнюдь не непривлекательна, отравление DNS возглавляет мой список недооценённых интернет-угроз.

Дэн Камински приводит интересные, более совершенные визуализации предположительно случайных данных по адресу doxpara.com, с которыми определённо стоит познакомиться, см. рисунок 10-17.

Рисунок 10-17. Представление случайности ядра BSD Дэном Камински. Предоставлено www.doxpara.com.

[1] [назад] Самый малый пакет SYN занимает 40 байтов, поэтому 5 000 таких пакетов потребляют не менее 200 килобайтов пропускной способности. По модемной линии со сжатием V.42bis этот объём успешно отправляется за 10-20 секунд. Порог выбран довольно произвольно, но кажется разумным.

[2] [назад] Результаты относятся к сценариям, где необходимо точное внедрение или подделка данных. Если точность менее важна либо цель состоит лишь в нарушении работы, удалённая сторона примет не только пакеты с точным номером, но и попадающие в размер окна из параметров TCP/IP, см. главу 9. Иными словами, атаки отказа в обслуживании будут ещё успешнее.

[3] [назад] Solar Designer отмечает, что технически это можно хитро реализовать и в экране без состояния. Он объединяет, например посредством XOR, исходный номер с безопасным хешем секретного ключа и четвёркой адресов и портов, однозначно задающей соединение. У возвращаемых пакетов хеш снимается повторным XOR, чтобы при доставке пакет соответствовал представлению внутреннего хоста о соединении, а снаружи существовал только в непредсказуемом случайном 32-битном виде. Это сработает для всех реализаций ISN, кроме самых сломанных, с частыми повторами и столкновениями.

Или что можно узнать из едва заметных несовершенств сетевого трафика

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

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

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

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

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

Популярные межсетевые экраны^[1] по существу являются классом промежуточных маршрутизирующих устройств, созданных для нарушения фундаментальной конструкции промежуточного маршрутизатора. В отличие от настоящих маршрутизаторов, которые должны без избирательности принимать решения по сведениям третьего уровня OSI, экраны обычно интерпретируют, используют или даже изменяют сведения верхних уровней, например TCP или HTTP. Хотя технология довольно нова, она предлагает устоявшийся и хорошо понятный набор решений и встречается и в домашних сетях, и в крупных корпорациях. Экраны настраиваются отклонять, разрешать или перенаправлять конкретные виды трафика, адресованного определённым службам, и, что неудивительно, ограничивают доступ к функциям и ресурсам всего проходящего трафика. Поэтому это мощное, хотя иногда чрезмерно разрекламированное и переоценённое решение безопасности и управления сетью.

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

Простейшие экраны - пакетные фильтры без состояния. Они лишь исследуют отдельные свойства каждого пакета, например целевой порт попытки соединения SYN Transmission Control Protocol, а затем по одним этим признакам решают, пропустить ли пакет. Конструкция чрезвычайно проста, надёжна и экономна по памяти и ресурсам. Например, такой экран ограничивает входящие соединения с почтовым сервером только адресованными порту 25, SMTP, отбрасывая все остальные SYN. Без первоначального SYN соединение установить нельзя, поэтому атакующий не сможет содержательно взаимодействовать с приложениями других портов. Для этого экрану не нужно быть почти столь же быстрым и сложным, как сам почтовый сервер: он не хранит записи об установленных соединениях и их точном состоянии.

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

Хотя вызвать такое непонимание кажется маловероятным, это довольно легко достигается с помощью старого друга, фрагментации пакетов, способом «атаки перекрывающимися фрагментами»,^[2] описанным RFC 1858 в 1995 году. Атакующий посылает начальный пакет с началом запроса SYN TCP к разрешённому экраном порту, например 25. В конце недостаёт лишь крошечной части, а в IP-заголовке установлен флаг more fragments, но зачем экрану беспокоиться о завершающих данных?

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

Затем атакующий отправляет второй фрагмент. Он создан так, чтобы перекрыть первоначальный ровно настолько, чтобы в буфере сборки перезаписать целевой порт, одно из полей TCP-заголовка. Фрагмент начинается с ненулевого смещения и лишён большей части заголовка, кроме перезаписываемого фрагмента.

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

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

Обычно неспособность фильтровать после SYN не проблема: если атакующий не доставит начальный SYN, он не установит соединение. Но есть ловушка: обработка трафика без SYN к определённому порту зависит от того, закрыт порт или система его слушает. Например, некоторые ОС отвечают RST на заблудившиеся FIN и ничего не отвечают на открытых, слушающих портах.^[1]

Поэтому против фильтров без состояния можно применять сканирование FIN или ACK, последнее впервые описано Уриэлем Маймоном в Phrack Magazine,^[3] а также сканирование NUL и Xmas - незаконными пакетами соответственно без единого флага и со всеми флагами. Так собираются сведения перед атакой об открытых портах удалённой системы либо строится карта трафика, отбрасываемого экраном. Само знание открытого порта без возможности правильно подключиться не является непосредственной угрозой. Но сканирование часто раскрывает крайне ценные внутренние сведения, например ОС и службы, которые помогают провести более эффективную и трудно обнаруживаемую атаку после компрометации или обхода первой линии обороны. Поэтому это считается потенциальной слабостью фильтра без состояния.

Возможно, более серьёзная угроза связана с механизмом SYN-cookie в сочетании с фильтрацией без состояния. SYN-cookie защищают ОС от атак истощения ресурсов, где злоумышленник посылает хосту огромное число поддельных запросов соединения, что само по себе нетрудно. Получатель вынужден отправлять ложные ответы SYN+ACK, выделять память и расходовать другие ресурсы, добавляя будущее соединение в таблицы состояния TCP. Большинство систем либо чрезмерно расходуют ресурсы и почти останавливаются, либо в какой-то момент отказывают всем клиентам до истечения ложных соединений.

Для решения SYN-cookie помещают во все ответы SYN+ACK внутри поля ISN криптографическую подпись, фактически сокращение, однозначно идентифицирующее соединение, а затем полностью забывают его. Только когда от хоста приходит ACK и номер подтверждения проходит криптографическую проверку, соединение добавляется в таблицу состояния.

Но при такой конструкции существует вероятность, что SYN и ответ SYN+ACK вообще никогда не отправлялись. Если атакующий создаст ISN-cookie, успешно проверяемую алгоритмом хоста, возможно благодаря достаточной пропускной способности или слабому алгоритму, он пошлёт ACK и заставит удалённый хост добавить новое соединение в таблицу, хотя SYN никогда не посылался и SYN+ACK не принимался. Фильтр без состояния не узнает об установлении соединения, поскольку не видел первоначального запроса. Без SYN целевой IP и порт нельзя было проверить и одобрить либо отклонить, но соединение внезапно установлено.

Это действительно плохо.

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

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

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

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

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

С развитием решений стало ясно, что перезапись не только полезна сети, но и даёт качественный скачок безопасности и функциональности благодаря чрезвычайно полезным технологиям вроде NAT. Это практика сопоставления некоторых IP-адресов с другим набором IP перед пересылкой и обратного преобразования ответов защищённой системы. NAT с состоянием можно, помимо прочего, применять в отказоустойчивых конфигурациях, где один общедоступный IP обслуживается несколькими внутренними серверами. Либо ради экономии адресов и безопасности внутренняя сеть использует пул частных недоступных извне адресов, а хосты выходят в Интернет, «маскируясь» под одну машину с общедоступным IP.

В первом сценарии NAT переписывает целевые адреса входящих пакетов на несколько частных систем за экраном. Получается отказоустойчивая балансировка нагрузки: последовательные запросы популярного сайта, возможно http://www.microsoft.com, или другой критической службы распределяются по набору систем, и при отказе одной остальные берут работу на себя. Иногда задачу выполняют выделенные устройства, что неудивительно называемые балансировщиками нагрузки, но часто её поддерживают и экраны с NAT.

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

Преобразование адресов сложнее, чем кажется: некоторые протоколы верхнего уровня не ограничиваются подключением к удалённой системе и отправкой команд. Например, древний, но чрезвычайно популярный File Transfer Protocol,^[4] FTP, в базовом и наиболее поддерживаемом режиме устанавливает обратное соединение от сервера к клиенту для передачи запрошенных данных; начатое клиентом исходное соединение служит лишь для команд. Многие другие протоколы, прежде всего некоторые чаты, одноранговые средства совместной работы или обмена данными, службы вещания мультимедиа и тому подобное, также имеют странные конструкции с обратными соединениями, перескакиванием портов или допуском к рабочей станции определённого трафика без сеанса, например пакетов UDP.

Чтобы не сделать протоколы бесполезными, каждая реализация маскарадинга должна иметь несколько протокольных помощников. Они исследуют прикладные данные соединения, иногда переписывают их и временно открывают дыры в экране для обратной связи. Здесь возникает другая проблема, впервые обнаруженная Микаэлем Олссоном в помощнике FTP несколько лет назад,^[5] а затем исследованная в других помощниках в том числе автором книги.^[6] Они открывают дыры по сведениям, отправленным рабочей станцией удалённой системе через определённый протокол, предполагая, что трафик создан от имени пользователя и с его ведома. Само собой, некоторые программы, например браузеры, можно обманом заставить посылать определённый сетевой трафик, в том числе похожий на протокол, который программа изначально не поддерживает, и даже делать это автоматически посредством специально созданного вредоносного содержимого. Поддельный трафик способен убедить помощника пробить дыру.

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

Следующий URL заставит HTTP-клиент подключиться к FTP-порту и выдать нечто похожее на команду FTP PORT, которую подхватит помощник:

Для законной службы FTP на другом конце запрос клиента будет бессмысленной тарабарщиной, а её ответ - непонятным веб-клиенту. Но дело не в этом. Важно, что атакующий управляет частью запроса, именем файла, который клиент попросит у сервера. Выбранное злоумышленником вымышленное имя может содержать любые данные. Включив подстроки, обычно признаваемые запросами FTP, атакующий обманывает помощника, слушающего конкретную текстовую команду PORT, заставляя его поверить, что пользователь пытается загрузить определённый файл. Поэтому удалённому серверу временно разрешается подключиться к жертве, здесь к непослушно звучащему порту 31337, поскольку 122*256+105=31337. Так мы впускаем атакующего без ведома жертвы. Снова упс: получили больше, чем ожидали.

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

Как отмечалось ранее, маскарадинг не является ненавязчивым. Его основной принцип - изменять исходящий трафик, переписывая части. При этом он выходит за пределы простой корректировки адреса и не только делает...

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

• Расхождение между TTL приходящих пакетов и ожидаемым или измеренным расстоянием до сети назначения. Трафик из-за маскарадинга как минимум на один переход «старше» пакета системы, получающей IP для исходящих соединений непосредственно из защищённой сети.

• В исходной сети чаще всего находятся разные ОС либо немного отличающиеся конфигурации или времена работы с разными свойствами TCP/IP, рассмотренными в главах 9 и 10. Наблюдение нескольких отпечатков в соединениях, словно исходящих от одного IP, служит сильной подсказкой о NAT на конкретной машине и внутренней сети за ней.

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

Каждая ОС резервирует определённый диапазон исходных портов для локального идентификатора конечной точки всех внешних соединений. Однако экран часто применяет для отображения маскируемых соединений другой диапазон, свойственный ОС устройства NAT. Если наблюдаемое не соответствует ожидаемому для опознанной системы, например Linux, обычно работающий с 1024 по 4999, использует очень большие номера, можно вывести наличие преобразования адресов и иногда тип экрана.

Эти широко применяемые приёмы лежат в основе обнаружения маскарадинга и разведки скрытой сети. Но доступны и другие способы выявления перезаписи пакетов.

Один менее очевидный и потому менее популярный способ обнаружить устройства перезаписи и узнать больше о конфигурации - анализ Maximum Segment Size входящего трафика.

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

Чтобы предотвратить последствия PMTUD для производительности и надёжности и уменьшить расходы фрагментации, многие экраны NAT, переписывающие параметры исходящего трафика, также меняют объявленный MSS TCP-заголовков соединений частной сети на более подходящий внешнему каналу. Новое значение, вероятно, немного уже, имеет меньший MTU, чем LAN. Изменение не позволяет получателю отправить данные, которые не поместятся в соединение, если именно оно имеет наименьший MTU инфраструктуры, и делает фрагментацию менее вероятной. Предполагается, что несовместимость MTU чаще возникает рядом с отправителем или получателем на «последней миле», где встречаются DSL, беспроводные линии и другие соединения с малым MTU, требующие уменьшения пакетов.

Одно уменьшение MSS обнаружить непросто. Фактически нельзя сказать, установил ли значение отправитель или его изменили по дороге. За одним небольшим исключением. Напомним из главы 9 особенность выбора окна во многих современных системах:

Всё больше современных систем, включая новые Linux и Solaris, отдельные Windows и SCO UnixWare, используют размер окна, кратный MSS. Поэтому вмешательство в MSS легко обнаружить: окно полученного пакета перестанет быть конкретным кратным и, скорее всего, вообще не будет делиться на MSS.

Сравнение MSS с окном надёжно обнаруживает группу экранов, поддерживающих MSS clamping, подгонку к соединению, в трафике самых разных систем. Хотя в Linux и FreeBSD она необязательна, домашние экраны, интеллектуальные DSL-маршрутизаторы и другие домашние сети часто выполняют её автоматически. Поэтому аномальный MSS указывает не только на устройство перезаписи, но и на связь с возможностями NAT, что становится признаком сетевого подключения отправителя.

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

Спецификация TCP/IP требует отвечать RST на все неожиданные ACK, уведомляя отправителя, что продолжаемый им сеанс больше не признаётся или никогда не признавался. Некоторые экраны могут нарушать RFC и вообще не отвечать, просто отбрасывая пакеты вне существующего сеанса. Это не всегда мудро, поскольку вызывает лишние задержки, когда законное соединение потеряно из-за временных сетевых проблем.

Однако многие устройства отвечают законным ожидаемым RST, открывая новое направление обнаружения и точного снятия отпечатка экрана. Поскольку пакет создаётся с нуля экраном, параметры относятся к нему, а не к защищаемой системе. Поэтому традиционные приёмы главы 9, изучение DF, TTL, окна, типов, значений и порядка параметров и так далее, определяют сам экран.

Существует и другая возможность согласно RFC 1122:^[7]

И действительно, хотя стандарт не установлен, некоторые системы при заблудившемся ACK отвечают многословными, пусть зачастую загадочными сообщениями RST в надежде утешить другую сторону знанием причины. Они нередко содержат внутренние ключевые слова или попытки странного жанра юмора фанатов, свойственные ОС: no tcp, reset; tcp_close, during connect в Mac OS; tcp_fin_wait_2_timeout; No TCP в HP-UX; new data when detached; tcp_lift_anchor, can't wait в SunOS.

Если в ответ на сетевую проблему или неожиданный трафик хосту приходит такой многословный RST, а мы знаем, что удалённая система не использует подобные сообщения, получаем подсказку. Между нами и адресатом находится устройство, вероятно экран с состоянием, а его ОС определяется сопоставлением ответа с известными сообщениями распространённых и редких систем.

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

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

Возможно, самое странное и интересное открытие я встретил примерно в 1999 году. Оно не связано непосредственно с устройством экранов, но даёт пищу каждому, кого интересует пассивное снятие отпечатков промежуточных систем.

Яцек П. Шиманьский, с которым я недолго работал, а позже с удовольствием обсуждал необычные и подозрительные картины трафика,^[3] заметил внезапный рост сильно сломанных пакетов TCP/IP к порту 21536 и в меньшей степени к 18477 или 19535. Они всегда исходили с портов 18245, 21331 или 17736 и приходили от множества систем пространства коммутируемых адресов польской национальной телефонной компании Telekomunikacja Polska.

После захвата нескольких пакетов обнаружилось сильное странное искажение. IP-заголовки были на месте, тип протокола установлен в TCP, но сразу за ними шла полезная нагрузка TCP - сами TCP-заголовки просто исчезли. Наблюдаемые сочетания портов возникали из толкования первых четырёх байтов нагрузки как пары чисел, которые при наличии TCP-заголовка были бы исходным и целевым портами. Пара 18245 и 21536 всего лишь представляла строку GET - четыре символа, открывающие большинство HTTP-запросов. Аналогично 18477 и 21331 означали SSH-, начало каждого Secure Shell, а 19535 и 17736 - EHLO, команду открытия всех сеансов ESMTP, Extended SMTP.

Но причина внезапного появления трафика оставалась загадкой. Почему только из этой сети? И почему искажение сетевым оборудованием не вызывало у пользователей проблем связи или других неудобств?

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

Компания исправила TCP/IP вскоре после развёртывания в Польше, и все жили долго и счастливо. Но, как можно представить, они не первыми и не последними случайно оставили уникальный след систем в передаваемых пакетах.

Мораль: снова наивно отвергать то, что обычно игнорируется. В современном сетевом мире тонкие подсказки и необычные, неожиданные, необъяснённые наблюдения чрезвычайно ценны. Их легко найти, но трудно анализировать.

Дополнительной пищей и областью исследования могут стать способы противодействия снятию отпечатков. Некоторые поставщики экранов пытались внедрять меры, меняющие характеристики пакетов настройкой IP ID, номеров последовательности TCP и прочего. Само собой, решение помогает атакующему и даёт результат, прямо противоположный желаемому: если не изменить и не унифицировать все признаки, включая номера последовательности, время повторных передач, метки времени и так далее, можно определить и нижележащую ОС, и защищающий сеть экран.

C’est la vie.

[1] [назад] Некоторые стороны поведения, склонность отвечать RST на заблудившиеся неожиданные пакеты к закрытым портам и игнорировать такой же трафик к портам слушающей службы, предписаны RFC 793; другие лишь выбраны конкретной группой разработчиков.

[2] [назад] Объявления маршрутизаторов должны были обеспечивать автоматическую конфигурацию хостов без ручного ввода настроек. Маршрутизатор периодически или по запросу передавал: «Вот я. Пользуйся мной». По умолчанию некоторые системы без больших колебаний принимали незапрошенные объявления - плохая идея.

[3] [назад] Сотрудничество в какой-то момент привело к созданию свободно связанной группы польских исследователей, которые в 1999-2000 годах сопоставляли, отслеживали и пытались объяснить множество причудливых видов неожиданного сетевого трафика.

Ещё один короткий рассказ о том, где найти то, что мы вообще не собирались отправлять

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

Обо всём по порядку. Несколько лет назад я попросил друга Кристьяна дать немного дискового пространства на одной машине, чтобы разместить мои проекты на надёжной и быстрой системе. Он согласился, и вскоре я стал постепенно переносить программы и работы в новый дом. Среди них была новая версия p0f, моего инструмента пассивного снятия отпечатков ОС, знакомого по главе 9. Скромная программа реализовывала интересные приёмы пассивного анализа, но для настоящей силы ей требовалась хорошая актуальная база подписей операционных систем. Поддерживать её вручную было трудно, и вскоре у меня закончились редкие системы, с которых можно снять отпечаток и добавить его.

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

В причудливом повороте событий Кристьян решил разместить на системе другой, коммерческий сайт, чтобы машина сама оплачивала счета. Как можно представить, он был посвящён вовсе не сетевой безопасности, садоводству или иному благородному делу, а менее престижным, но, возможно, более привлекательным сторонам нашей жизни: сексу, наготе и всему связанному. Я возликовал, как всякий уважающий себя фанат, не из-за содержимого, а потому что за считаные часы хлынули миллионы подписей соединений для анализа разрабатываемой программой. Аллилуйя!

Бережёного бог бережёт: проектируя новый код p0f, я решил реализовать множество проверок разумности для обнаружения самых причудливых, маловероятных и неслыханных схем входящего трафика, охватив все незаконные или бессмысленные сочетания настроек TCP/IP. Здравый смысл подсказывал, что пакеты со странно искажёнными параметрами никогда не встретятся, по крайней мере от популярных и хорошо испытанных систем, однако реализация функции не вредила. Если же система действительно отправит пакет с определённой аномалией, её обнаружение превосходно отличит конкретную ОС от похожих реализаций без недостатка.

В счастливые месяцы благословенной бури подписей я видел страннейшие вещи. Некоторые удалось объяснить и документировать для p0f, другие остались загадкой. Большинство ранее реализованных проверок попало в цель, и я сразу нашёл системы с более необычными причудами TCP/IP. Но одна вещь была особенно тревожной и невероятной, поэтому я уделил ей больше внимания.

Две проверки - значения ACK в заголовке при неустановленном флаге ACK, действительно бесполезное действие, и значения URG без флага URG - поначалу казались бессмысленными и не давали интересных результатов. Затем я заметил необычное: некоторые Windows 2000 и XP, подключавшиеся к серверу Кристьяна, время от времени имели ненулевые URG или ACK в пакетах без соответствующих флагов, прежде всего в SYN, открывающих соединение.

Наличие значений без флагов строго говоря не проблема. Согласно RFC 793, они просто теряют всякое значение. Например:

RFC 793 своим совершенно особым способом сообщает, что аномалия вряд ли вызовет сетевые проблемы и потому могла остаться незамеченной навсегда. Но я обратил внимание просто потому, что она была странной.

Сначала я считал виновным определённое сетевое оборудование, как в большинстве проблем главы 11, но это было не так. Срабатывания приходили от отдельных систем, не целых сетей, и не были постоянными: появлялись в нескольких пакетах, со стабильными или случайно меняющимися значениями, а затем исчезали и больше не возникали в последующих соединениях. Кроме того, проблема казалась исключительно свойственной Windows: среди затронутых не было ни одной редкой ОС.

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

Загадочно.

Я был близок к сдаче. Опубликовал наблюдения в нескольких общедоступных списках рассылки, прежде всего VULN-DEV, популярном обсуждении уязвимостей от Security Focus, попросив других исследователей об анализе и отзывах, но безрезультатно. И тут по чистой случайности поймал собственную испытательную станцию на точно таком поведении, занимаясь совершенно иной проблемой. На фоне случайно работал сниффер - разве у нас бывает иначе?

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

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

Раскрытые сведения имеют двойное значение:

• Это традиционный сценарий раскрытия информации. Объём в каждом пакете с неверно инициализированными URG и ACK мал и не гарантированно осмысленен, если буфер изначально не содержал интересного, но в отдельных случаях ценен, особенно когда внешняя сущность способна вызвать одновременный сеанс с конфиденциальными сведениями и сам недостаток.

• Уязвимость служит удобным показателем отпечатка, раскрывающим дополнительные сведения об ОС и её состоянии, простым способом отличить систему, интенсивно использующую сеть, от бездействующей.

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

Легко обвинить разработчиков. Они, разумеется, виноваты в неправильной инициализации памяти, но само наличие отдельного «включателя» для поля заголовка, возможно, является недостатком конструкции TCP и способствует таким проблемам. Подобные тонкости преследуют спецификации протоколов, как показано в главе 7, где сходную уязвимость вызвало слишком точное следование спецификации без достаточного размышления о побочных последствиях.

Или как изящно исчезнуть

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

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

До сих пор эта часть книги была посвящена атакам уровня IP, требующим прямого наблюдения трафика отправителя, хотя обычно без взаимодействия с жертвой. Здесь мы взглянем на эффектно активную, но косвенную атаку IP, где атакующий профилирует жертву обоснованным предположением о невидимом. Он взаимодействует с невинным наблюдателем, который не является настоящим объектом испытания, без его согласия и ведома узнавая всё возможное о реальной жертве.

Такой подход не звучит лёгким способом сбора данных. Но в духе фанатского сообщества почему бы не выбрать живописный, пусть немного более длинный маршрут и не рассмотреть его подробно?

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

Первая проблема традиционного сканирования в его шумности: жертва, вероятно, заметит бурю или устойчивый поток попыток к необычным портам. Скрыться тоже нелегко; атакующий должен видеть ответы на SYN, чтобы различать открытые и закрытые порты. Открытые отвечают SYN+ACK, закрытые - RST, а отфильтрованные экраном, скорее всего, ничего не посылают либо возвращают Internet Control Message Protocol, ICMP. Поэтому нельзя просто подделать исходный адрес всех пакетов: приходится раскрыть личность адресом, ведущим обратно в сеть, где атакующий слушает входящий трафик.

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

Обычный способ маскировки - сканирование с «приманками», где атакующий посылает каждому порту SYN от нескольких ложных адресов вместе с настоящим IP. Жертва обрабатывает подделки как реальные, но ответы, конечно, уходят в пустоту. Определить источник гораздо труднее: все системы-приманки нужно исключить из списка тщательным анализом или перебором. При решительности отправителя всё же можно найти без властей, но атакующий надеется обескуражить жертву чрезмерными затратами времени на столь малое происшествие.

Окончательная защита от обнаружения появилась, как часто бывает, от парня с избытком времени, потраченного на чтение спецификаций вместо продуктивного занятия. Так родилось «бездействующее» сканирование, idle scan. Сальваторе «antirez» Санфилиппо придумал его в 1998 году; вскоре оно было широко реализовано и стало популярно среди и просто любопытных, и злонамеренных хакеров.^[1]

Основа - важное наблюдение. Процитируем RFC 793:

Пакеты RST TCP безусловно завершают соединение и приказывают отправителю прекратить дальнейшие попытки связи. Согласно RFC 793 система без долгих колебаний посылает RST на неожиданный трафик. Естественно, сами RST, даже неожиданные, ответа не получают, иначе при малейшем сбое между сторонами бесконечно отскакивал бы поток сбросов.

Idle scan умно злоупотребляет тем, что посторонний хост-свидетель так обрабатывает все неожиданные пакеты. Злонамеренный сетевой гражданин сканирует жертву, с которой не собирается непосредственно связываться, посредством ничего не подозревающей случайной системы Интернета и не раскрывает личность.

Работает это так. Атакующий подделывает SYN к проверяемому порту жертвы. Пакет адресован ей, но обратным адресом вместо атакующего указан свидетель. Само по себе это не кажется полезным, но подождите.

Дальнейшее зависит от открытости порта:

• Если проверяемый порт жертвы отвечает свидетелю RST, тот получает его и молча размышляет, не создавая обратного трафика.

• Если порт открыт, жертва отвечает SYN+ACK. Свидетель с величайшим недоверием заключает, что вообще не посылал SYN, и отправляет RST, сообщая жертве, что она жестоко ошиблась и ей лучше немедленно остановиться. Жертва смущённо принимает ответ и удаляет все записи о соединении, которое надеялась принять.

Значение различия поначалу трудно оценить. Но вернёмся к главе 9 и вспомним поле IP-заголовка:

Выбрав свидетеля с такой схемой IP ID, а кандидатов много, атакующий легко определяет, посылал ли тот IP-пакет за период. Для этого до и после настоящего зонда он отправляет свидетелю бессмысленный трафик и сравнивает ID ответов. Если два значения отличаются ровно на 1, между ними свидетель ничего не посылал. Если больше - пакеты обменивались, хотя неизвестно с кем.

Можно зондировать непосредственно перед поддельным пакетом жертве и вскоре после него и по ответам свидетеля определить порт. Увеличенный IP ID означает вероятный RST жертве, а значит, жертва сначала послала SYN+ACK на подделку и порт открыт. Если свидетель выдаёт ожидаемый следующий ID, он не получил трафик от жертвы либо проигнорировал RST.

Разумеется, есть практические соображения. Главное: свидетель должен быть сравнительно бездеятельным, а испытание следует повторить несколько раз для исключения ложных срабатываний. Иначе стороннюю связь свидетеля можно ошибочно принять за открытый порт жертвы.

Важность подхода в том, что он скрывает происхождение не простым обескураживанием жертвы, а фактическим отсутствием опознаваемой связи атакующего. Отследить его без владельца свидетеля, который сам может получать запросы IP ID как часть законного трафика вроде HTTP и с трудом понять, что использован в атаке, или внешних организаций, правоохранительных органов и провайдеров, гораздо сложнее. Поскольку органы обычно действуют только после компрометации, а не простого зондирования, любопытные конкуренты могут спать спокойно, и требуют от жертвы признать компрометацию, что крупным корпорациям не всегда удобно, атакующий чувствует себя довольно безопасно.

Непосредственной защиты сейчас нет, и легко отличить его от обычного SYN невозможно. Но не стать свидетелем просто: используйте случайные или постоянные IP ID, как обсуждалось в главе 9. Это не усложнит атаки на вас или вообще, поскольку множество систем всегда будет применять последовательные идентификаторы, но не позволит злоупотреблять вашей сетью с данной целью.

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

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

На некоторых системах ту же функцию выполняют номера последовательности TCP в зависимости от конструкции генератора ISN. Предлагаю исследовать идею подробнее.

О поиске источника idle scan или другой поддельной атаки см. главу 17.

Умение видеть сквозь тонкую маскировку может пригодиться во многих случаях

Задачу определения истинной личности программного обеспечения и его законности довольно легко решить локально на компьютере, где оно работает. Но по сети это не так просто.

И системные администраторы, и разработчики приложений часто пытаются с разной успешностью определить программу на другом конце сетевого сеанса. Причин несколько. Для World Wide Web, WWW, самая распространённая цель - оптимизировать отдаваемое клиенту содержимое под используемый механизм отображения, независимо от того, законно оно или вредоносно. В многочисленных других схемах связи, мгновенных сообщениях, почтовых клиентах и так далее, задача - обеспечить соблюдение политики и обнаружить связь из возможно опасных или неприемлемых приложений. И наконец, сами программисты пытаются не допустить неразрешённые или нелицензионные программы к сетевой службе, возможно лишающие их части дохода, либо обнаруживать такие случаи и принимать исправительные меры.

Самый простой и распространённый способ опирается на сведения, добровольно объявляемые удалённой системой. Можно просто заметить приветственный баннер сервера, изучить заголовки протокола клиента, например X-Mailer в письмах или User-Agent в WWW, либо анализировать текстовые состояния, ошибки и предупреждения службы в ответ на трафик.^[1] К сожалению, первый подход крайне ненадёжен и легко саботируется пользователями, которым есть что скрывать; последний навязчив и трудно применяется против клиентов без проблем. Большинство клиентских программ прекращает работу и жалуется при первой ошибке, а пользователь, который из-за попытки идентификации получает сообщение и не может законно обратиться к службе, не будет впечатлён.

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

Кроме того, многие корпоративные среды начали строже фильтровать содержимое для блокировки нежелательного трафика, и авторы сомнительных приложений в ответ стали выдавать их за безобидные. Не так давно одноранговые программы обмена музыкой, вредоносные трояны и шпионские программы начали изображать в исходящей связи самый распространённый браузер Microsoft Internet Explorer. Так же поступали многие веб-роботы, собиравшие адреса для сомнительных маркетинговых компаний по всему миру.

И другие протоколы страдают от самозванцев. Неудивительно, что большинство ненавистных программ массовой рассылки спамеров и мошенников притворяются Microsoft Outlook, PINE, Mutt, Eudora, The Bat! или Netscape Mail. Основная идея - спрятаться в камуфляже и проскользнуть мимо сетевых администраторов, которые, узнав о программе, легко её заблокируют. Ни один вменяемый спамер не объявит, что письма исходят от «Пресловутого массового рассыльщика дядюшки Берни, экстремальная редакция», ведь пользователь или фильтр слишком легко их отбросит.

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

Вскоре пытаться учитывать каждое воплощение вредоносной программы становится непрактично. Иногда общее обнаружение достигается поиском схем, явно указывающих на предотвращаемое злоупотребление: отличие законного почтового клиента от программы спамера в том, что первый едва ли попытается отправить за раз 10 000 000 писем. Но подход очень ограничен. Для некоторых протоколов и чётко заданных атак он работает как волшебство, а с трафиком WWW всё иначе: трудно попасть в цель без чрезмерного числа ложных срабатываний или пропущенных программ.

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

После всего сказанного различить шпионскую программу или троян и законное приложение кажется чрезвычайно трудно. Однако существуют хорошие средства точной идентификации такого ПО. Самый многообещающий универсальный подход обычно называется поведенческим анализом, модным обозначением старых и затасканных «временных закономерностей». Он исследует тонкие внутренние зависимости между последовательными порциями трафика вместо фактических данных одного запроса или общего числа соединений за время. Зависимости тесно связаны с внутренними алгоритмами и производительностью, поэтому их гораздо труднее подделать. В этой главе я рассмотрю подход и предложу основной набор аналитических средств для такой точности и подробности на удобном примере World Wide Web.

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

Концепцию World Wide Web понять нетрудно: дать пользователям мгновенный доступ к множеству перекрёстно ссылающихся, связанных документов, сочетающих разные виды информации. Достаточно просто.

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

Согласно хронологии,^[1] опубликованной World Wide Web Consortium, W3C, концепцию гиперссылок впервые обсуждал в Atlantic Monthly^[2] в 1945 году Вэнивар Буш, директор Office of Scientific Research and Development во время и после Второй мировой войны.

Буш предложил Memex, персональное электромеханическое устройство, которое можно считать ранним предшественником PDA. Оно хранило документы и личные файлы и должно было предоставить интуитивные механизмы доступа. Одна функция позволяла создавать ссылки между документами на микрофильме и следовать им. По какой-то причине идея безумно сложного механического устройства на микрофильме тогда не прижилась.

Концепция всплывала ещё несколько раз и привела к первым компьютерным реализациям в 1960-х. Они не были особенно успешны, главным образом потому, что вычислительная мощность, необходимая для привлекательности технологии, оставалась делом будущего.

Нужное время наступило в конце 1980-х. После бума микрокомпьютеров и незадолго до лобового штурма платформы PC в Conseil Europeén pour la Recherche Nucléaire, CERN,^[2] ходило несколько скромных предложений о гиперссылках. Исследователя Тима Бернерса-Ли по общему мнению официально следует винить в появлении HyperText Markup Language, HTML, набора средств включения метаданных, ссылок и мультимедийных ресурсов в текстовые документы. По правде говоря, HTML, основа знакомой Паутины, едва ли полностью новая конструкция и заимствует идеи у SGML, ISO 8879 Standard Generalized Markup Language 1986 года. Вскоре после этого на ныне почти неизвестной, но тогда передовой платформе NeXT появился первый браузер с вездесущим названием World Wide Web.

После появления броского названия революцию было не остановить. В 1992 году Бернерс-Ли подал первоначальный проект спецификации^[3] HyperText Transfer Protocol, HTTP, средства инкапсуляции HTML и других ресурсов в связи от сервера клиенту. К 1993 году было доступно несколько механизмов браузеров, а горстка веб-серверов уже отдавала содержимое любопытным посетителям. Конечно, HTTP составлял лишь сокрушительные 0,01% магистрального трафика, но рос!

Первый популярный браузер Mosaic разработали в National Center for Supercomputer Applications Иллинойсского университета. Он заимствовал код Бернерса-Ли, но добавил содержимое помимо текста, заполняемые формы и многие другие привычные функции. Код Mosaic постепенно превратился в Netscape Navigator, затем отделился в открытый проект Mozilla, чья база позднее стала основой последующих поколений Navigator. Одновременно, чтобы ещё больше запутать пользователей, компания Spyglass превратила Mosaic в ядро будущего главного конкурента Netscape, Microsoft Internet Explorer.

В 1994 году образовался W3C, орган надзора за развитием Паутины. В 1996 году Бернерс-Ли, Рой Т. Филдинг и Хенрик Фристик представили первую официальную, значительно улучшенную и расширенную версию протокола, вскоре за ней вышла спецификация HTML 3.2. В последующие годы появились новые версии HTTP и HTML под управлением W3C. Конец истории всем известен. Или это только начало?

HTTP^[4] - удивительно прямолинейный текстовый протокол поверх TCP/IP. Клиент подключается к службе HTTP удалённого сервера и просит конкретный ресурс. Первая строка запроса включает:

• метод доступа. Чаще всего клиент просит получить файл посредством GET, хотя существуют методы отправки форм, диагностики, хранения данных на сервере или выполнения расширений;

• universal resource identifier, URI: путь к статическому файлу или динамической программе, являющейся объектом запроса. Динамической программе можно передать как часть URI дополнительные правильно закодированные параметры;

• поддерживаемую и желаемую версию протокола. Сервер может ответить более низкой, если версия клиента не поддерживается. Без этой информации предполагается ранний устаревший HTTP/0.9, который здесь не рассматривается.

Например:

Запрос просит ресурс /show_plush_toys.cgi у www.plush-penguins.com. Судя по расширению cgi, это динамически выполняемая программа с двумя параметрами, param1 и param2, после вопросительного знака.

За запросом может, как в примере, следовать несколько текстовых заголовков по одному на строке с дополнительными параметрами. Это может быть идентификация клиента в User-Agent, предпочтительный язык содержимого, здесь польский и английский, или виртуальный сервер. Если несколько доменных имён указывают на один IP, заголовок позволяет понять, ищет пользователь www.squeaky-ducks.com или www.plush-penguins.com, размещённые на одной системе.

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

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

Код или сообщение описывает успешное выполнение, указание браузеру искать в другом месте либо ошибку вроде «Файл не найден» или «Доступ запрещён». Далее идут заголовки сходного формата: версия серверной программы, следующее местонахождение для браузера, тип возвращаемого файла, отличающий изображения от текста или HTML от двоичных данных, и так далее. Затем, при наличии, само содержимое.

Как видно, базовый HTTP довольно прост. Он предлагает некоторые совершенные функции, но большинство либо слегка странны, либо редко применяются. Думаю, ошибку 402 Payment Required вы видите не каждый день. Но наивно верить, что базового протокола достаточно современным пользователям.

Дни типичного сайта из нескольких килобайтов статического текста и малых графических элементов давно прошли. По мере усиления компьютеров и перемещения модемов 300 bps из домов в музеи форма начала преобладать над содержанием. Сотни килобайтов изображений, подстраниц, фреймов и клиентских сценариев с переменным успехом делают сайты привлекательнее и профессиональнее. На многих мультимедиа стало основным содержимым, а HTML лишь заполняет место для изображений, видео, встроенных Java-программ или игр. Паутина больше не просто способ рассказывать о личных проектах или интересах; движущая сила - продажа товаров и услуг дешевле и быстрее, чем когда-либо. А маркетинг требует броской подачи.

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

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

Поэтому клиенту нужно несколько запросов. Самый наивный способ - получать части по очереди, но в реальности это создаёт узкие места: зачем ждать страницу только потому, что сервер баннеров медленный? Ради скорости браузер выдаёт несколько запросов одновременно.

Здесь первый недостаток HTTP: он не умеет изначально обслуживать одновременные запросы, только последовательные.

Последовательная модель заметно снижает производительность, если элемент страницы загружается с медленного сервера или нестабильной линии либо долго готовится. При единственном варианте любой медленный запрос не даёт отправить и обслужить последующие до завершения.

Поскольку новые HTTP ситуацию не исправили, клиенты применяют заплатку: браузер открывает несколько одновременных отдельных сеансов TCP/IP с сервером или набором и выдаёт много запросов сразу. Когда ресурсы находятся на отдельных машинах, решение вполне разумно. Но для одной системы, где все запросы можно было сделать в одном сеансе и разумно управлять сервером, оно плохо:

• Сервер не может выбрать лучший порядок. Иначе он оставил бы трудоёмкие, крупные или наименее важные объекты напоследок. Его заставляют делать почти всё сразу, и важнейшее всё равно без необходимости задерживается из-за нагрузки CPU.

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

• Новое рукопожатие TCP/IP даёт значительные расходы, хотя в новых HTTP это несколько смягчается keep-alive. Эффективнее выдать все запросы в одном соединении.

• Новый сеанс и процесс обработки создают расходы ОС и нагружают устройства вроде экранов с состоянием. Современные серверы уменьшают проблему запасными постоянными процессами для поступающих запросов, но редко устраняют полностью. Один сеанс избегает расходов и позволяет выделить лишь действительно необходимые ресурсы для асинхронного обслуживания выбранных запросов.

• Наконец, если узкое место - сеть, а не сервер, производительность может ухудшиться из-за отбрасывания пакетов, когда канал насыщается данными нескольких одновременных источников.

Увы, хороша эта архитектура или плоха, пока она с нами и всё же лучше последовательного получения. Следует признать её существование и научиться использовать в своих интересах.

Как свойство поможет определить программу клиента? Очень просто. Значение параллельного получения файлов для отпечатка браузера достаточно очевидно: двух совершенно одинаковых алгоритмов нет, а измерить их можно хорошими способами.

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

Хранение локальных кэшей документов сервера - одна из важнейших функций Паутины в период быстрого расширения последних лет.^[3] Без неё стоимость этого дела была бы значительно выше.

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

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

Наконец, тяжёлые сложные сайты не всегда согласуются с ожиданиями. Сравнительно долгое время загрузки, прежде считавшееся приличным, теперь раздражает и отпугивает. Исследования показывают, что средний пользователь не ждёт более 10 секунд.^[5] Корпорациям и поставщикам нужны дополнительные ресурсы и лучшие линии. Если бы всё осталось в первоначальном виде, спрос на серверные ресурсы, вероятно, давно превысил бы наши возможности.

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

Для кэширования HTTP предлагает две встроенные функции:

• способ с минимальными усилиями узнать, изменилась ли порция данных после самой свежей версии в кэше, документа последнего посещения;

• способ определить, что не следует кэшировать из-за безопасности или динамического создания при каждом запросе.

На практике всё просто. Сервер возвращает кэшируемые документы в обычном сеансе с дополнительным заголовком Last-Modified, который, неудивительно, представляет его мнение о времени последнего изменения. Некэшируемые отмечаются Pragma: no-cache, а в HTTP/1.1 - Cache-Control: no-cache.

Браузер или промежуточный механизм провайдера должен сохранить копию каждой кэшируемой страницы вместе со временем изменения и держать её как можно дольше: пока не превышен пользовательский предел или пользователь вручную не очистит кэш, если только Expires не приказывает отбросить после даты.

При повторном посещении клиент обнаруживает предыдущий экземпляр на диске и действует немного иначе. Пока документ живёт в кэше, при каждом возвращении клиент пытается получить файл, но указывает If-Modified-Since со значением ранее увиденного Last-Modified. Сервер сравнивает его со временем последнего изменения ресурса. Если с тех пор ничего не изменилось, вместо данных возвращается ошибка HTTP 304 Not Modified. Передача подавляется, экономя полосу: обмениваются лишь пара сотен байтов, а клиент или промежуточный кэш использует прежнюю копию.

Другое важное и кажущееся не связанным требование к HTTP - различать и отслеживать сеансы между соединениями, хранить настройки и идентичность. Например, сайтам полезно приспосабливаться к предпочтениям и восстанавливать выбранный вид при каждом посещении.

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

Для бесшовного персонализированного доступа к форумам, доскам, чатам и множеству других привычных функций требовался прозрачный постоянный способ хранить и получать сведения на машине клиента. Но способность администратора узнавать вернувшихся посетителей, назначая уникальную метку и позднее извлекая её, означала сдачу анонимности за небольшое удобство. Механизм дал бы компаниям со второсортной этикой превосходный инструмент слежения и профилирования: записывать покупки и просмотр, определять интересы. Поисковики легко связывали бы запросы одного человека, а поставщики баннеров отслеживали бы людей без их разрешения или ведома операторов сайтов.^[4] Но достаточно универсальной альтернативы не было. Так родились веб-cookie.

Cookie согласно RFC 2109^[6] - малые порции текста, выдаваемые сервером при подключении клиента. В ответе указывается Set-Cookie; дополнительными параметрами текст ограничивается конкретным доменом, сервером или ресурсом и сроком. Клиент хранит его в специальном файле или папке, cookie jar, и автоматически возвращает заголовком Cookie при новом соединении с ресурсом.

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

Механизм широко считается серьёзной угрозой приватности. Некоторые активисты прямо ненавидят cookie, хотя теперь сопротивление всё тише. Просматривать Паутины без них всё труднее, а некоторые сайты отказывают клиентам, не прошедшим проверку. К счастью, многие браузеры предлагают подробные настройки принятия, ограничения и отклонения и даже спрашивают о каждом, хотя последнее непрактично. Это позволяет разумно защищать приватность, хотя бы определив «хороших парней» и доверенных.

Но находится ли приватность после этого в наших руках?

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

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

Примерно в 2000 году Мартин Пул отправил в Bugtraq короткое, но проницательное сообщение^[7] с наблюдением и кодом. Он заключил, что между Set-Cookie/Cookie и Last-Modified/If-Modified-Since нет существенной разницы, по крайней мере без централизованного прокси-кэша, когда копии хранятся локально на диске, как у большинства простых смертных. Злонамеренный администратор может поместить в Last-Modified почти любое сообщение или, если заголовок проверяется, произвольную уникальную дату для идентификации посетителя. При возвращении клиент отправит If-Modified-Since с точной копией сохранённого злоумышленником идентификатора. Ответ 304 Not Modified не даст этому «cookie» исчезнуть.

Небольшое изменение браузером данных Last-Modified в ответе кажется аккуратной защитой ценой некоторой неточности кэша, но это не так. Другой вариант хранит данные в кэшированных документах вместо меток. При первом посещении злоумышленник готовит особую страницу со ссылкой на уникальное имя встроенного ресурса, например изображения. При возвращении сервер видит If-Modified-Since, отвечает 304 и заставляет использовать старую копию. Она содержит уникальную ссылку, запрашиваемую у сервера, благодаря чему IP клиента сопоставляется предыдущему сеансу, где было возвращено имя. Упс.

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

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

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

Но пора вернуться к основной теме.

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

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

Для простейшего реального примера я решил выяснить, что можно сказать по уже существующим ограниченным данным, которые, вероятно, у многих под рукой, и взял стандартные журналы чуть более миллиона запросов к достаточно популярному сайту. Это обычный журнал Apache со временем завершения, URI, объявленными данными User-Agent и другими основами. Страница состоит из набора сравнительно малых картинок похожего размера и одного HTML, вызывающего их все.

Практика Apache записывать запросы после завершения, а не при выдаче, может казаться проблемой, но при достаточно однородных файлах помогает. Порядок начала обычно сильнее зависит от последовательности ссылок главной страницы, тогда как время завершения сложнее.

Вероятности порядка завершения зависят от числа запросов, задержек и других параметров, тонко, но заметно различающихся у браузеров. В частности, клиент с одним соединением всегда выдаёт A-B-C-D; с тремя одновременными быстрыми запросами с равной вероятностью получается B-A-C-D, C-B-A-D, C-A-B-D и так далее, и тогда особенно важны очередь и управление сеансами.

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

Рисунок 14-1 показывает статистическое распределение попыток загрузить описанную десятиэлементную страницу четырьмя самыми популярными клиентами набора. Каждый график разделён на десять крупных сегментов. Первый соответствует непосредственно запрошенному главному HTML и естественно является первым элементом. Остальные девять - девяти изображениям по порядку ссылок в HTML.

Каждый сегмент дополнительно делится на десять дискретных позиций оси X, не показанных явно во избежание загромождения. Высота в позиции n представляет вероятность загрузки данного файла элементом n последовательности.

Рисунок 14-1. Различия поведенческих шаблонов популярных веб-клиентов. Показаны Internet Explorer, Netscape Navigator, Opera и Wget; подписи под ними дают десятизначные отпечатки поведения.

Для читаемости вероятности даны процентами от 1 до 100, все меньше 1 округлены вверх, а дискретные точки соединены линиями. Графики построены в логарифмическом масштабе log10 с основными направляющими 1, 10, 100, чтобы тонкие признаки были заметнее и легче сравнивались.

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

Различия отчётливо видны даже между браузерами, исторически основанными на одном механизме, Mozilla и Internet Explorer. Все соблюдают порядок ссылок главного документа, поэтому последовательные пики медленно движутся слева направо. Но Mozilla заметно менее нетерпелив и чаще заканчивает в порядке запросов. Opera, рекламируемая самым быстрым браузером на земле, гораздо менее последовательна: у многих файлов два-три почти одинаковых пика, то есть запросы выдаются настолько быстро, что завершение почти произвольно и главным образом зависит от дрожания сети. Для сравнения открытый робот Wget идеально последователен, как часто автоматические роботы, использует одно соединение и всегда загружает в одном порядке.

Картинки и графики приятны, но почти бесполезны для автоматического обеспечения политики или обнаружения злоупотребления. Чтобы количественно выразить схемы и сделать отпечатки реалистичнее, я ввёл простой показатель, дающий сегменту лучший балл от 0 до 10 при одном пике и меньший при произвольном распределении. Так можно создать десятизначный отпечаток программы и сопоставлять активность с подписями.

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

Хотя уравнение поначалу пугает, оно прямолинейно. Я хотел отдать предпочтение случаю, когда файл чаще всего загружается в одной фиксированной позиции, одно f близко к 100%, остальные к 0, перед случаем, когда все позиции равновероятны по 10%.

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

Остальная математика лишь отображает результаты на разумную шкалу от 0 до 10 после округления.

Результаты вычисления для каждого сегмента каждого браузера наложены на рисунок 14-1 числом, описывающим сегмент. Как ожидалось, Wget везде идеален. Оценки остальных подтверждают визуальные наблюдения и делают их осязаемее. Хотя Internet Explorer и механизмы Mozilla/Netscape дают примерно сходные графики, сильные различия видны в загрузке элементов 4-6 и слабее по всей последовательности. Opera явно отделяется постоянно более низкими оценками.

Так простейший аналитический инструмент дал основу практического способа идентифицировать браузеры и обнаруживать обман в статистически значимой выборке HTTP-трафика пользователя. Модель можно улучшить анализом других автоматически загружаемых элементов, сценариев, таблиц стилей HTML, карт изображений, фреймов и файлов с ещё большим различием между браузерами. Санте в этом году может быть легче составить список непослушных пользователей.

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

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

И подумайте: более продуманные формы анализа можно продвинуть дальше, различая не механизмы отображения, а машины и людей или даже отдельных пользователей. Как обсуждалось в главе 8, манера работы с клавиатурой настолько уникальна, что пригодна для биометрии. Аналогично исследования показывают, что способы нажатия ссылок, выбора, чтения и прочего способны указать, кто или что стоит за запросами.^[8] Пока это ближе к научному предположению, чем факту, но область замечательна для исследования и игры.

Применения активности браузера и поведенческого анализа выходят за рамки обнаружения программы; некоторые вступают в область приватности и анонимности.

Интересная работа Эдварда Фелтена и Майкла Шнайдера 2000 года^[9] вносит увлекательный вклад: возможность, тесно связанная с механизмами кэширования современных движков, где наконец встречаются все обсуждённые элементы.

Основная идея: вставив ссылку на файл определённого сайта и измерив задержку браузера при загрузке, можно узнать, посещал ли пользователь сайт в последние дни. Достаточно просто.

Вместо длинной экскурсии в теорию, предсказания и предположения, хотя бы один раз, предложу почти реальный пример. Допустим, я управляю www.rogue-severs.com и решил, что главная страница зачем-то ссылается на картинку, например логотип, с www.kinky-kittens.com. Я делаю элемент трудным для поиска или уменьшаю до невидимости, но браузер всё равно его загрузит.

Ничего не подозревающий пользователь посещает мой сайт. Если на www.kinky-kittens.com он не бывал, загрузка занимает время. У частого посетителя картинка уже в кэше и появляется почти мгновенно.

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

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

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

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

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

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

[1] [назад] Популярный инструмент, снимающий отпечатки анализом ответов, - AMAP от THC; подробнее: thc.org. NMAP Фёдора определяет службы по баннерам.

[2] [назад] Европейская лаборатория физики элементарных частиц, Женева, Швейцария.

[3] [назад] Однако значение постепенно уменьшается: всё больше страниц создаётся динамически, а магистраль Интернета становится зрелее и мощнее, поэтому кэширование неизбежно теряет важность.

[4] [назад] Если баннер или иной элемент размещён на общем сервере вроде http://banners.evilcompany.com, оператор evilcompany.com может выдавать и получать cookie при посещении любого законного сайта с его баннерами. Большинство поставщиков действительно это делает и отслеживает пользователей, хотя прежде всего для маркетинговых исследований.

Где мы заключаем, что должный оптимизм в отношении жизни помогает отследить атакующего

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

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

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

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

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

Как и ожидалось, о злонамеренной удалённой стороне можно узнать многое, просто применив к трафику распространённые показатели TCP/IP из предыдущих глав, например пассивное снятие отпечатка ОС. Так определяется конкретный инструмент сканирования портов.

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

Особенно интересный способ определить сканер переносит на новую задачу один метод главы 9, снятие отпечатка последовательности портов. Большинство современных сканеров проходит сети и системы от меньших портов или адресов к большим либо перемешивает порядок доступа. Последний подход применяется чаще и считается лучше, потому что выравнивает нагрузку и слегка затрудняет обнаружение. Но неожиданно случайность способна несколькими причудливыми способами обернуться против атакующего.

Проблема возникает, поскольку авторы не считают сетевые сканеры критическими приложениями с высокими требованиями безопасности. Самый обычный и лёгкий способ реализовать генератор псевдослучайных чисел без необходимости криптографически безопасного выхода - вызвать стандартные системные или встроенные средства языка. Стандарт ISO^[1] самого распространённого в мире языка C предлагает простейший линейный конгруэнтный алгоритм для генератора стандартной библиотеки, рассмотренного в главе 1. Рецепт таков:

1. Генератор инициализируется начальным 32-битным значением S0 через стандартную srand(). Без этого он начнёт с фиксированного значения и всегда выдаст одинаковую последовательность.

2. При каждом вызове rand(), получающем очередное псевдослучайное число для пользовательской программы, состояние пересчитывается: S(t+1) = St * 1103515245 + 12345. Результат обрезается до 32 битов, по модулю 4294967296.

3. Возвращается старшее слово S(t+1) по модулю 32768. В распространённом ныне 32-битном варианте процедура этого и предыдущего шага повторяется несколько раз для последовательных частей результата.

Все линейные конгруэнтные генераторы, включая этот, уязвимы к общей методике криптоанализа Х. Кравчика 1990-х, упомянутой в главе 1. По нескольким последовательным или иначе упорядоченным выходам восстанавливается внутреннее состояние и предсказываются все предыдущие и будущие результаты.

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

• Можно определить S0. Если известно или оценивается время начала работы генератора либо общие свойства начального состояния, значение инициализации восстанавливается. Поскольку S0 - единственный вход, одинаковое значение обязательно создаёт одинаковое поведение, и состояние прослеживается по выходу PRNG.

• Можно определить приращения t. После восстановления состояния видно, сколько случайных значений запросил сканер вызовами rand() между двумя вызовами, использованными для номеров портов или адресов хостов захваченных пакетов.

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

Применив знание к рассчитанному S0, жертва зонда узнаёт системное время атакующего, GMT или локальное в зависимости от ОС и сканера. Локальное время тривиально подсказывает происхождение и личность. Если нас пытаются запутать поддельными пакетами разных источников, можно исключить те, где часовой пояс S0 не совпадает с географией исходного адреса. Например, если время атакующего на пять часов отстаёт от Гринвича, он, вероятно, на восточном побережье США, а не в Китае. Сравнив лучший вариант часового пояса с записями блоков IP, мы заключим, что из всех «приманок» настоящий адрес скорее скрыт за пакетами провайдера Бостона, чем Пекина.

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

Наконец, если PID включён в состояние вместе со временем, а время известно в некотором диапазоне, PID помогает определить приблизительное время работы системы или число задач между сканированиями. Каждый новый процесс получает больший PID, поэтому зависимость прямолинейна.^[1]

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

Если сканер создаёт ложные пакеты-приманки от случайных хостов, можно исключить поддельные адреса, сформированные PRNG и совпадающие с возможным выходом, и найти не совпадающий настоящий, окончательно указывающий на виновника. Например, если трафик идёт от:

можно определить, что 3334192695 и 3475961302 были среди первых выходов генератора с S0, а 3279225659 не является ранним выходом восстановленного PRNG и, вероятно, настоящий адрес.

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

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

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

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

Кража полученных атакующим знаний проста лишь в теории; сопоставлять и обрабатывать результаты, особенно в крупных средах или по частичной информации отдельных атак из разных мест, нетривиально. Однако средства картирования сети и систем «пассивным сканированием» постепенно появляются, яркий пример - DISCO Престона Вуда.^[2]

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

Я могу осветить лишь верхушку айсберга, но это, несомненно, одна из самых увлекательных областей для исследования и вклада.

А теперь нечто совершенно иное...

[1] [назад] Хотя некоторые системы предлагают необязательную рандомизацию PID, чтобы затруднить другие виды локальных атак.

Где вновь подтверждается старая истина: армия прислужников лучше самостоятельной работы

Надеюсь, путешествие до сих пор доставляло удовольствие. Я обсудил множество причудливых проблем безопасности и приватности информации от ввода на клавиатуре до конечного назначения в сотнях или тысячах миль. Но праздновать рано: в картине отсутствует нечто гораздо большее всего рассмотренного.

Тёмная материя.

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

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

Часть начинается с анализа концепции, наиболее подходящей для перехода. Для многих компьютерных фанатов паразитные вычисления произвели революцию в представлении об Интернете.

Скромная работа Альберта-Ласло Барабаши, Винсента У. Фриха, Хавуна Чона и Джея Б. Брохмана, опубликованная в письмах Nature в 2001 году,^[1] легко могла остаться незамеченной. На первый взгляд она не заслуживала внимания и выдвигала почти смешное предложение. Авторы полагали, что внутри устоявшихся сетевых протоколов вроде TCP/IP можно создать трафик, который в качестве сообщения ставит удалённому компьютеру простейшую арифметическую задачу; система невольно решит её при разборе и подготовке ответа. Но зачем тратить время, задавая загадки бесчувственным машинам? Что это даст? Не столь же ли весело решить самому? Ответ, конечно, интересен.

Во-первых, решение головоломок компьютером является делом: значительная часть современной криптографии основана на относительной трудности так называемых недетерминированных полиномиальных задач, NP.^[1] NP-полные задачи с удовольствием врываются на праздник каждого взломщика в самый неподходящий момент. Способность эффективно решать их огромной вычислительной мощностью, умными алгоритмами или обоими, вероятно, приблизит счастливого изобретателя к мировому господству. Стимул есть. Но как?

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

Здесь P - сама формула, а x1 - x3 - двоичные входы, параметры.

Хотя существует 2^3 комбинаций, только одна делает P истинной: x1 = 1, x2 = 0, x3 = 1. Поэтому лишь эта тройка является решением. Решение SAT сводится к поиску значений всех переменных, при которых вся включающая их формула истинна.

Простейшие случаи вроде этого легко решаются даже перебором, но сложные многопеременные действительно NP-полны, а другие NP-задачи сводятся к SAT за полиномиальное, то есть разумное время.

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

И вот откровение, связывающее SAT и TCP/IP. Основное наблюдение исследователей довольно очевидно, по крайней мере подписчику Nature: алгоритм контрольной суммы TCP или IP из главы 9, хотя создан совсем для иной цели, является лишь набором последовательных булевых операций над битами входного сообщения. На низком уровне это чистая логика над словами пакета. Предоставив особое содержимое, «вход», удалённую систему заставляют выполнить набор арифметических операций и проверить правильность, совпадение с суммой заголовка TCP или IP.

Хотя операция на каждой итерации абсолютно одинакова, её функциональности достаточно для универсального логического вентиля из главы 2. Чередуя испытательные входы с тщательно выбранными «управляющими» словами, инвертирующими или иначе меняющими текущую частичную сумму, можно выполнить любую булеву операцию.

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

Таким образом, проверку выполнимости случайно выполняет удалённый получатель при проверке суммы. Если она равна 1 или другому значению, соответствующему истинному SAT, испытание для выбранных переменных пройдено, трафик передаётся верхним уровням и обрабатывается. При несовпадении формула не удовлетворена и пакет молча отбрасывается. Иными словами, если входные биты обозначали гипотезу, адресат либо проверил, либо опроверг её, выполняя разные действия по результату.

Желающий быстро решить SAT готовит все комбинации переменных формулы, чередует со сведениями для нужного сочетания, помещает в TCP-пакеты и почти параллельно отправляет множеству хостов мира. Контрольная сумма вручную ставится в значение, которое «гипотеза» создаст при истинности, вместо фактического вычисления. Только хосты с переменными, дающими желаемый результат, ответят; остальные отбросят трафик как повреждённый. Отправитель находит решение без огромных вычислений, просто смотря набор значений в пакетах ответившим хостам.

Работа идёт дальше и сообщает об успешном решении NP-задачи посредством реальных хостов мира, давая не только теорию, но и подтверждение.

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

Мировое господство близко? Не так быстро.

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

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

Другие способы красть пренебрежимо малую индивидуальную мощность интереснее как источник впечатляющих вычислений по низкой цене. Например, некоторые клиенты, такие как браузеры, легко заставить выполнять довольно сложные алгоритмы. Один пример, схема «китайской лотереи» из RFC 3607,^[2] - крошечный Java-апплет, который сайт Жана-Люка Кука md5crk.com предлагал веб-мастерам добавлять на страницы. Каждый посетитель исполнял апплет, занимавший ничтожную долю циклов CPU для проекта поиска столкновений сокращающей функции MD5. Столкновения - два разных сообщения с одинаковым сокращением; они неуловимы и анекдотичны, но определённо возможны^[2] и помогают понимать слабости функций и эмпирически показать, что MD5 слишком слаб для современных компьютеров.

Java-апплеты - малые машинно-независимые программы, по умолчанию выполняемые браузером в особой ограниченной «песочнице». У них нет доступа к локальному диску и только теоретически способности навредить, хотя ограниченная сеть позволяет вычислять и добавлять визуальные элементы. Обычно они расширяют сайты играми, эффектами и так далее. Но Жан-Люк использовал их иначе: для поиска вероятных кандидатов столкновений совместной мощностью сотен или тысяч систем одновременно.

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

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

Хотя подход находится в серой зоне киберэтики, впервые открыто развёрнутый md5crk.com действительно работал и хорошо демонстрировал эффективность и скрытность паразитных вычислений. Кража циклов процессора, предназначенных для «правомерных» целей, вполне достижима и, возможно, применяется чаще желаемого. И возможность останется.

Но ворчливый скептик продолжает: способны ли паразитные вычисления на большее, чем откусывание крошечных кусочков CPU ради взлома шифрования, интересующего немногих?

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

Но что произойдёт, когда фанат теории информации читает свой код вслух на вершине горы в сторону каменистой долины? Я знал, что вы спросите. Он неизбежно делает умное наблюдение: если читать быстро и сразу забывать произнесённое, отвлёкшись на другие дела, позднее информацию всё равно можно восстановить, когда она отразится от дна долины и вернётся эхом. Voilà - удобный механизм хранения данных.

Звучит нелепо? Возможно, мы просто слишком молоды. В ранних типах компьютерной памяти применялась похожая акустическая техника: процессор мог хранить часть информации «вне себя» и позднее получать её обратно. Вместо воздуха, в котором волны распространяются слишком быстро, чтобы без чрезвычайно больших запоминающих устройств обеспечить разумную ёмкость, использовался заполненный ртутью барабан - среда, где акустические волны идут гораздо медленнее. Однако принцип оставался тем же и даже придавал интересный смысл выражению memory leak - «утечка памяти». Такое устройство, память на ртутной линии задержки, применялось, например, в знаменитом UNIVAC I.^[3]

Естественно, от такой медленной, громоздкой, опасной и неудобной памяти отказались в пользу других решений, едва технология достаточно развилась. Но у самого изобретения было своё очарование, и так просто исчезнуть в забвении оно не могло. Короткая презентация Сакиба А. Хана на конференции DefCON в Лас-Вегасе в 2002 году возродила эту идею и впервые подсказала, как использовать свойства крупномасштабной сети, чтобы построить похожее временное хранилище на основе Интернета. Но теперь описание акустической памяти казалось смотревшим короткий показ слайдов хакерам и гикам не смехотворно примитивным, а невероятно крутым. Акустическая память вернулась со стилем.

Поскольку время кругового пути пакета - время, необходимое сообщению, чтобы достичь удалённой системы, а ответу вернуться, - ненулевое, некоторое количество данных всегда можно держать «в проводе», многократно отправляя и принимая их части и ожидая возвращения эха. Сакиб добился этого с помощью пакетов ICMP (Internet Control Message Protocol) «echo request» (ping); большинство систем Интернета отвечает на них пакетами «echo reply», цитируя исходную полученную полезную нагрузку.

Это выглядело отличным трюком. Но для любого разумного приложения он был далеко не практичен, потому что части данных требовалось часто пересылать заново. Поскольку ICMP «echo reply» отправляется почти немедленно после получения «echo request», наружу удавалось вытолкнуть лишь немного данных, прежде чем они начинали возвращаться и их требовалось снимать с провода. В итоге объём такого хранилища не мог превышать количества, которое пользователь способен отправить в лучшем случае за пару секунд, а чаще - менее чем за десятую долю секунды.

Ах, но паразитное хранение можно было улучшить.

Но что теперь? Какая польза от практических схем паразитных вычислений и хранения, если их преимущества всё ещё далеко не настолько велики, чтобы стать заманчивой альтернативой простой покупке дополнительного оборудования?

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

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

Более того, представьте энергозависимые системы, которые после загрузки и инициализации способны долго поддерживать себя сами, живя в Интернете и не имея локализованного физического присутствия. Возможны две конструкции энергозависимых распределённых компьютерных систем, и ни одна не столь абсурдна:

• системы можно проектировать так, чтобы они выполняли сложную задачу, параллельно ища решение; это уже в основном достигнуто рассмотренной выше схемой вычисления SAT. Недостаток таких систем в том, что результат вычисления приходится получать, а следующую итерацию обработки - запускать вручную, время от времени «засевая» всю систему заново из некоторого места. Решения на основе низкоуровневых свойств протоколов вроде TCP, вероятно, относятся к этой категории;

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

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

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

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

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

[1] [назад] В теории сложности полиномиальные задачи решаются машиной Тьюринга за время, полиномиально пропорциональное длине входа, количеству или размеру переменных. Необходимое время прямо соответствует длине в постоянной степени, которая может быть нулевой, и тогда оно вообще не зависит от входа, как при проверке чётности. Для недетерминированных полиномиальных, NP, задач решения такого рода неизвестны, и при росте входа может требоваться резко больше времени, например экспоненциально. Подмножество NP-полных задач доказанно не имеет решений за полиномиальное время. NP обычно считаются «трудными» для нетривиального входа, P обходятся дешевле.

[2] [назад] Пока книга готовилась к печати, китайские исследователи Шаньдунского университета Сяоюнь Ван, Дэнго Фэн, Сюэцзя Лай и Хунбо Ю сообщили способ поиска и примеры столкновений MD4, MD5, HAVAL-128 и RIPEMD-128. Это одна из важнейших новостей современной криптографии и подтверждение непригодности функций для некоторых применений безопасности. Проект md5crk.com закрылся, но его вклад в исследование паразитных вычислений остаётся действительным.

[3] [назад] Возможно, стоит отметить, что малоёмкая аналоговая память на линии задержки применялась и в ранних реализациях телевизионных приёмников SECAM (Séquentiel Couleur avec Mémoire, или «последовательный цвет с памятью»). В отличие от NTSC или PAL, сигнал SECAM использует пониженное цветовое разрешение: красная и синяя цветоразностные составляющие передаются попеременно, никогда одновременно. Чтобы определить вид конкретного пикселя, другую составляющую приходится брать из предыдущей строки. Для этого и требовалось запоминающее устройство.

О том, как знание окружающего мира помогает выслеживать друзей и врагов

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

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

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

Самую всестороннюю попытку составить карту Интернета предприняла Cooperative Association for Internet Data Analysis (CAIDA) - организация, финансируемая, среди прочих, федеральными исследовательскими ведомствами NSF, DHS и DARPA, а также отраслью, включая Cisco и Sun. Организация была создана для разработки анализа трафика и инфраструктуры и соответствующих инструментов на общее благо интернет-сообщества, в надежде сделать Интернет лучше, надёжнее, устойчивее и крепче.

С 2000 года одним из ведущих публичных проектов CAIDA стало создание и сопровождение карты магистральной сети автономных систем, также известной как Skitter. На момент выхода этой книги самый свежий снимок представлял данные о 12 517 крупных автономных системах, соответствующих 1 134 634 IP-адресам и 2 434 073 связям - логическим путям - между ними.

Несмотря на поразительно загадочное звучание, карта Интернета CAIDA была создана лишь по общедоступным данным конфигурации BGP маршрутизаторов, эмпирическим результатам проверки сети с помощью traceroute и записям WHOIS для сетевых блоков. Карта организована в полярных координатах. Точка каждой системы расположена под углом, соответствующим физическому местонахождению заявленной штаб-квартиры сети, и на радиусе, соответствующем «значимости пиринга» данной автономной системы. Последний параметр выводится из числа других автономных систем, которые, согласно наблюдениям, принимают трафик от этого узла. Поэтому массивные магистральные системы находятся ближе к центру карты, а системы, непосредственно контактирующие всего с парой узлов, - у внешнего периметра. Линии графа просто соответствуют пиринговым отношениям между маршрутизаторами.

Ещё одна заслуживающая внимания попытка картографировать сеть опиралась на анализ расстояний до разных сетей из определённой точки - в данном случае из Bell Laboratories - и строила древовидную структуру, совсем не похожую на сложную ячеистую сеть CAIDA. Этот анализ, проведённый Биллом Чесвиком в 2000 году,^[1] дал карту на рис. 17-1. Структура не параметризует граф по физическому или административному местонахождению системы; относительное расстояние от центра соответствует числу переходов между узлом и Bell Labs.

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

Рисунок 17-1. Карта Интернета Билла Чесвика

Но, как выясняется, сведения, полученные CAIDA, Биллом Чесвиком или практически любым опытным пользователем Сети, можно с успехом применять и для того, чтобы лучше понять природу и точнее исследовать происхождение загадочного трафика, с которым мы однажды можем столкнуться.

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

При обычной DoS-атаке администратор имеет возможность увидеть источник вредоносного трафика, направленного против одной из его служб и, предположительно, призванного вывести её из строя, причинив оператору неудобство или убыток. Однако атакующие пакеты можно подделывать случайным образом, и тогда администратор остаётся беспомощен: он не способен отфильтровать трафик атакующего, не отрезав других пользователей. Единственная надежда - совместно с вышестоящим провайдером исследовать настоящий источник трафика на канальном уровне и передать сведения провайдеру нарушителя; но это требует времени, и немалого. Кроме того, без судебного приказа нужно убедить все стороны, что дело заслуживает расследования, а также их времени и денег. Поэтому особенно важно снабдить системного администратора инструментами и методами, отличающими поддельный трафик от настоящего.

Когда я жил и работал в Соединённых Штатах - сейчас я живу в Польше, - мой коллега Марк Лавлесс решил реализовать идею, впервые предложенную Дональдом Маклахланом: измерять время жизни TTL сетевого трафика между собой и предполагаемым отправителем пакета, чтобы автоматически определять, подделан ли входящий пакет. В мире, где сведениям нельзя доверять, задача определения источника сетевого пакета важна, и способность решить её хотя бы в некотором подмножестве случаев по указанным выше причинам принесла бы большую пользу множеству аналитических и административных задач.

Чтобы понять идею Дональда и Марка, учтите: удалённая система, от которой мы видим трафик, находится на определённом логическом расстоянии от нас, отделённая заданным числом сетевых устройств. Поэтому все правомерно отправленные ею пакеты при прибытии имеют некоторое TTL, равное исходному TTL по умолчанию, настроенному в системе, минус число пройденных пакетом промежуточных систем, как рассматривалось в главе 9. Но у поддельного трафика, предположительно исходящего из совершенно другой сети, начальный TTL и расстояние, скорее всего, отличаются от того, что следует из данного наблюдения. Инструмент Марка despoof^[2] сравнивает TTL в специально вызванном и ранее полученном трафике, чтобы различить настоящий и фальсифицированный трафик.

Однако, хотя в отдельных случаях против ничего не подозревающих атакующих метод может хорошо работать, с ним связаны по меньшей мере две проблемы:

• Параноидальный атакующий может перед атакой измерить расстояния и выбрать TTL, совпадающий с ожидаемым значением. Хотя это возможно, реализовать трюк несколько трудно. Во-первых, атакующий может физически не суметь установить достаточно высокий TTL, чтобы при достижении назначения получить конкретное значение, ожидаемое от настоящего пакета. Его план можно сорвать, если выдаваемая им система использует TTL по умолчанию, равный или близкий 255 - наибольшему возможному, - а атакующий находится дальше от цели, чем эта система; тогда отправить пакет с желаемым TTL при прибытии совершенно невозможно. Конечно, мало какие системы применяют наибольший TTL, да и атакующему редко требуется выдавать себя именно за конкретную систему.

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

• При получении каждого подозрительного пакета адресат должен начать расследование, а затем ждать результатов. Поэтому использовать despoof как основу автоматической защиты непрактично, особенно при DoS-атаках. Тем не менее этот метод весьма полезен для определения настоящего источника «сканирования с приманками».

Без знания топологии конкретной сети трудно добиться чего-то лучшего, чем despoof; реализованная инструментом техника анализа TTL достаточно хороша, чтобы распознать и остановить многие обычные зондирования и отдельные атаки. Но что дальше?

Объедините инструмент Марка с данными о структуре сети в реальном времени и примените пассивное снятие отпечатков для определения начального TTL системы, отправляющей конкретные запросы, - и техника станет гораздо мощнее. Дополнительные сведения позволяют выполнить начальную пассивную оценку входящего трафика, сравнив наблюдаемый и начальный TTL с ожидаемым расстоянием по карте сети.^[1] Поскольку должное наблюдаемое расстояние можно определить без активного зондирования данных о топологии сети, мы сразу и без особых усилий отличаем настоящий трафик от вредоносного. Это, в свою очередь, позволяет довольно надёжно реагировать на массовые происшествия и обнаруживать отдельные малозаметные пробы, не предупреждая атакующего о наличии системы выявления подделок.

Очевидно, учёт структуры сети при рассмотрении одноранговых отношений способен принести немало пользы. Но обнаружение подделок - лишь начало.

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

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

Независимо от случая, едва данные, предположительно исходящие из одного источника, замечены более чем в одном месте назначения, мы можем выполнить триангуляцию. Для каждого места назначения, где замечен трафик, лишь определённый набор сетей находится на расстоянии, которое можно вычислить по пути атакующего пакета, опять же исследовав TTL.^[2] Пересечение всех таких наборов для каждой точки наблюдения даст меньший набор - а часто лишь одну сеть, - из которого могла исходить атака, как показано на рис. 17-2.

Рисунок 17-2. Наивная сетевая триангуляция: всем наблюдениям соответствует только один источник. Атакующий может подделывать адреса источника, но не способен обмануть жертв.

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

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

Битва проиграна? Нет - существует способ не дать нарушителям так нас одурачить.

Решение под названием «анализ нагрузки сети» появилось в прекрасном исследовании, представленном Хэлом Бранчем и Биллом Чесвиком на конференции LISA в 2000 году.^[3] Бранч и Чесвик предложили интересное применение данных о древовидной топологии сети, подобных ранее показанному графу на рис. 17-1, полученных для конкретного места. Они придумали, как с помощью этих сведений обнаруживать источник определённого вида поддельного трафика - отказа в обслуживании. Сам подход довольно прост и основан на предположении, что такая атака нагружает не только систему, против которой проводится, но и промежуточные маршрутизаторы, а жертва может измерить эту нагрузку извне и использовать её, чтобы почти буквально вернуться назад и найти клубок, потянув за провод.

Для проверки нагрузки сетевых связей сначала строят или получают дерево связей от своего местонахождения до всех сетей Интернета, а при атаке проходят по последовательным ветвям этой древовидной структуры. Для каждой ветви, которая в действительности обозначает соединение с маршрутизатором более высокого порядка, можно последовательно измерять сетевую нагрузку узла, отправляя испытательный трафик соответствующему маршрутизатору или через него. В данной статье применяется UDP-служба chargen, но можно использовать запросы ICMP или любые другие сообщения. Более нагруженный узел выбирается как вероятный кандидат, через который поступает трафик, после чего перечисляются и проверяются все исходящие из него ветви, пока трафик не будет прослежен до источника.

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

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

Рисунок 17-3. Рекурсивная обратная трассировка атаки с помощью данных о топологии сети и проверки нагрузки

Возникает возможная проблема: некоторые устройства могут быть сильно нагружены по причинам, не связанным с обработкой DoS-трафика; у других может быть много свободных циклов CPU, и пересылка вредоносного трафика почти на них не повлияет.

Для решения проблемы исследователи предлагают создать искусственную кратковременную нагрузку на маршрутизатор, генерируя дополнительный трафик, а затем проследить, как проверка влияет на пропускную способность и задержку DoS-запросов. Если конкретное устройство действительно участвует в пересылке вредоносных пакетов, после его нагрузки темп атаки должен снизиться. Нагрузку, опять же, вероятно, создают дополнительными фиктивными запросами TCP, UDP или ICMP, рассчитанными скорее на потребление мощности CPU устройства, чем на насыщение его интерфейсов. Следовательно, корреляция должна появляться только на ветвях, участвующих в обслуживании вредоносного трафика.

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

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

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

В конечном счёте, хотя частное, индивидуальное применение различных способов обнаружения подделок может быть весьма успешным, прежде чем развернуть такие техники в большом масштабе, предстоит ответить на множество открытых вопросов - и не все они относятся к техническим проблемам.

[1] [назад] В таком подходе TTL следует сравнивать с некоторым допуском, поскольку внутри внутренних сетей может быть несколько дополнительных переходов. Кроме того, некоторые маршруты асимметричны, и их длины способны слегка различаться в зависимости от направления обмена трафиком.

[2] [назад] Даже если инструмент использует случайные TTL, при достаточном числе наблюдаемых пакетов в каждом месте назначения - а это возможно почти всегда - расстояние можно оценить по наибольшему замеченному TTL. Например, если сканер выбирает начальные TTL случайно в диапазоне от 32 до 255, но среди нескольких тысяч полученных в месте назначения пакетов ни один не имел TTL больше 247, то хост, скорее всего, находится на расстоянии 255 - 247 = 8 систем.

Когда смотришь в бездну, то, что нас не убивает, делает нас сильнее

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

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

Одно из применений наблюдения за чёрной дырой - обнаружение и анализ глобальных тенденций атак. Многие хакеры в чёрных шляпах, получив новые методы атаки, часто просто сканируют большие блоки сетевых адресов в поиске уязвимых целей, которые можно скомпрометировать и в итоге использовать для незаконной деятельности - предположительно, чтобы собирать транзитные хосты^[1] или строить сети атакующих дронов для автоматических атак. Наблюдение за чёрной дырой может предупреждать нас о новых уязвимостях, эксплуатируемых в реальном мире: достаточно заметить рост обычной активности сетевого сканирования из разных источников.

Многие сетевые администраторы развёртывают наблюдение за чёрной дырой. Иногда они сочетают его с приманками - в сеть выставляется фиктивная система-«наживка», которая ловит атакующих, перехватывает их инструменты и выявляет приёмы^[1], - получая систему раннего предупреждения, которая позволит им первыми узнать о надвигающихся вспышках червей и другого вредоносного ПО. Трафик чёрной дыры можно также применять для калибровки «уровня шума» и более эффективного обнаружения направленных атак на ваши серверы, не реагируя на автоматическую, неизбирательную вредоносную активность.

Такие исследователи, как Даг Сонг и Хосе Назарио - последний совсем недавно в книге Defense and Detection Strategies against Internet Worms^[2], - пытались анализировать активность чёрных дыр во время массовых вспышек сетевых червей. Их цель - лучше понять и смоделировать динамику распространения в сети, то есть первоначальное распространение и повторное заражение, а также проверить эффективность и стойкость алгоритмов заражения червей. Исследования помогут разработать будущую защиту от массовых распределённых угроз и одновременно дадут ценные сведения о сегодняшнем состоянии сети. Некоторые полученные результаты показаны на рис. 18-1 - 18-4.

Рисунок 18-1 показывает распространение червя во время вспышки. Данные основаны на числе наблюдаемых попыток атаки TCP-порта 137 - части реализации Windows NetBIOS, которая по умолчанию установлена на всех компьютерах Windows и служит целью многих видов самораспространяющегося вредоносного ПО. Обратите внимание: после недели первоначального распространения, когда и число заражённых площадок-источников, и число атакованных систем в наблюдаемой сети чёрной дыры стабильно и быстро росло, внезапно наступает период стабилизации продолжительностью больше месяца с резкими пиками и провалами. Такой отпечаток распространения исключительно характерен для конкретного червя и условий сети, где он работает; он отражает также тонкости алгоритмов выбора целей и заражения, применённых автором.

Рисунок 18-1. Характеристики распространения червя Windows

Рисунок 18-2 показывает другую сторону алгоритма распространения червя и изображает свойства алгоритма выбора цели. В данном случае популярный червь, нацеленный на серверы Microsoft SQL, по-видимому, довольно непрерывно охватывает адресное пространство, хотя адреса с октетами примерно от 200 до 225 выбираются заметно чаще, а значения больше 225 червь, похоже, полностью пропускает.

Рисунок 18-2. Гистограмма алгоритма выбора целей червя SQLSnake; обратите внимание на неравномерный, но в целом непрерывный охват адресного пространства

Рисунок 18-3 показывает тот же график для другого сетевого червя - Slapper. Этот червь нацеливался на системы Linux, эксплуатируя изъян популярной криптографической библиотеки OpenSSL. Алгоритм, судя по всему, даёт заметно более равномерный, но гораздо менее непрерывный охват с огромными пробелами в некоторых диапазонах значений.

Рисунок 18-3. Гистограмма алгоритма выбора целей червя Slapper. Распределение гораздо равномернее, но охват прерывистый, с пробелами, которые указывают, что младшие значащие биты каждого «случайного» адреса постоянны - возможно, из-за ошибки программирования.

Рисунок 18-4 показывает закономерности стойкости червей во времени. Например, некоторые черви, по мере исправления и обеззараживания систем, неуклонно отмирают, а другие применяют алгоритмы, вызывающие внезапные и повторяющиеся подъёмы и спады, знакомые всем, кто экспериментировал с моделями популяций или эпидемиологии на основе природных явлений.

Рисунок 18-4. Стойкость червей во времени. Обратите внимание: для CodeRed нет простой картины «всплеск - спад», а модель ведёт себя подобно модели биологической популяции.

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

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

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

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

Хотя получение такого ошибочно направленного пакета может казаться маловероятным, помните: в ответ на сканирование с приманками или SYN-флуд создаётся значительное число пакетов SYN+ACK, RST+ACK и RST. Адресное пространство Интернета кажется огромным, а в подобных атаках обычно участвуют миллионы пакетов, но со временем некоторые из них с большой вероятностью достигнут каждого отдельного сетевого блока. Вероятность отскока одного случайно созданного поддельного пакета на конкретный адрес равна лишь 1 к 4 294 967 296, то есть 1 к 2^32, однако обычная небольшая подсеть, выделенная малой компании или организации, как правило, состоит из 256 адресов - сеть класса C или эквивалентная, - и потому вероятность возрастает до 1 к 16 777 216, то есть 1 к 2^24. Её можно увеличить ещё больше, исключив диапазоны адресов, которые заведомо зарезервированы для особых целей или иначе не представляют интереса и потому не используются в определённых видах атак.

Поскольку размер одного SYN-пакета составляет около 40 байтов, а в массе они хорошо сжимаются, обычный сетевой канал случайного атакующего передаёт примерно от 10 до 150 килобайтов на IP-уровне в секунду - соответственно слабый DSL и линия T1, - и за это время он способен вытолкнуть от 250 до почти 3000 пакетов, то есть от 900 000 примерно до 10 000 000 пакетов в час.^[2]

Чтобы обычная DoS-атака дала заметный результат и причинила жертве серьёзные неудобства, её, как правило, приходится вести несколько часов или дней. Атакующий хочет досаждать жертве как можно дольше. В результате отправляются десятки или сотни миллионов пакетов, порождающих сопоставимое число ответов SYN+ACK или RST+ACK.

Из-за этого огромного объёма трафика вполне разумно ожидать, что даже сравнительно небольшая организация заметит остаточный трафик слабой атаки SYN-флуд непосредственно во время неё, даже если хост-получатель отбрасывает многие атакующие пакеты. Более того, администраторы, способные наблюдать сети, эквивалентные классу B - 65 356 адресов, обычно принадлежащих крупным компаниям, провайдерам, исследовательским учреждениям и так далее, - смогут быстро улавливать гораздо меньшие события.

Поскольку все остаточные ответы при поддельной DoS-атаке содержат некоторые подробности сообщений, сфабрикованных атакующим, чтобы изначально вызвать эти ответы, - например, номера портов и последовательностей, сведения о времени и так далее, - из них можно извлечь важные сведения о виде и масштабе атаки. По этим ответам можно определить, была ли целью конкретная служба, сколько систем атаковано, какая полоса доступна атакующему и какой инструмент применялся - исследовав выбор исходного порта, выбранные номера последовательностей и закономерности «случайных» IP.^[3]

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

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

В 1999 году мы с группой друзей и коллег из Польши начали скромный внерабочий проект. Мы хотели отыскать источник труднообъяснимого набора пакетов RST+ACK, которые заметили в обслуживаемых нами сетях, и в целом наблюдать необычные и незапрошенные закономерности трафика, приходящего в неиспользуемые сегменты сети. Это было очень весело и, как вы можете представить, породило немало догадок, когда мы пытались разумно объяснить самые необычные случаи. Исследование также позволило больше узнать об окружающем мире: мы встречали чрезвычайно странный и вроде бы необъяснимый трафик, который после правильного анализа раскрывал больше сведений о грандиозных заговорах нашего проводного мира.

Хотя проект формально забросили, в итоге он превратился в мой частный «Музей сломанных пакетов»^[3] - полушутливую веб-страницу, посвящённую выслеживанию, документированию и объяснению пакетов, которые либо вообще не должны были достичь места назначения, либо не должны были выглядеть так, как выглядели. Заявленная цель музея такова:

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

Среди экспонатов моего музея есть следующие чудеса:

• Пакеты из сетей с веб-ускорителем, маршрутизатором или межсетевым экраном определённого вида; устройство дописывает, удаляет или иначе искажает часть данных. Хороший пример - изъян некоторых устройств Nortel CVX, ответственный за периодическое удаление TCP-заголовков из пакетов, как рассматривалось в главе 11. Уникальность изъяна позволяет многое узнать о множестве удалённых сетей, не выходя наружу и не зондируя их.

• Несколько экспонатов линейного шума: пакеты содержат либо полную бессмыслицу, либо данные, которые совершенно точно не относились к конкретному соединению. Один из самых удивительных экспонатов - незапрошенный трафик с данными, похожими на дамп содержимого зоны DNS .de, то есть перечень всех доменов Германии. Трафик не мог прийти откуда угодно, потому что простые смертные не имеют права получать такой список. Он должен был исходить от уполномоченной стороны, способной получить и передать эти данные, а исказил его либо отправитель, либо устройство где-то на пути. Хотя все такие случаи мало проясняют природу сетевых происшествий, они нередко обогащают наблюдателя неожиданными - и часто ценными - находками.

Среди других примечательных экспонатов были случаи очевидного шпионажа, замаскированного под обычный трафик, и множество иных ошибок программирования или сетевой работы. Но хватит хвастаться: если вас непреодолимо тянет узнать больше, посетите http://lcamtuf.coredump.cx/mobp/.

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

Естественно, такое наблюдение за чёрной дырой непросто и остаётся дорогим. Требуется время, чтобы научиться находить иголку в стоге обычной активности червей и чёрных шляп, которая в достаточно обширной сети, как правило, не имеет значения за пределами статистической отчётности.

Но ради радости от наконец найденной иголки часто стоит попробовать.

[1] [назад] Транзитный хост - система, используемая как промежуточный переход для дальнейших атак или иной незаконной деятельности, например рассылки спама. Этот приём затрудняет выслеживание конечного нарушителя, поскольку его источник непосредственно неизвестен, а для поиска требуется сотрудничество нескольких администраторов или юрисдикций.

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

[3] [назад] Например, из-за ошибок в коде некоторые инструменты «подделывают» пакеты только с чётных или нечётных IP-адресов. Анализы, подобные проведённым Хосе Назарио и другими, обычно выявляют инструменты атаки столь же хорошо, как идентифицируют червей.