Относительно разговора о спуфинге протокола IP. TCP/IP – это стек (набор) протоколов, и протокол IP – один из них, причем он требует поддержки. Для защиты протокола IP от спуфинга следует использовать протоколы (подобные протоколу TCP), в которых при инициализации соединения предусмотрен обязательный ответ и которые могут лишить возможности передачи, бесцеремонно сбрасывая полученные данные в битоприемник (bit bucket) (это гипотетическая корзина, в которую сбрасываются «мусорные» записи базы данных), тем самым защищая сеть от входящих и выходящих пакетов, относительно содержимого которых появилось подозрение, что оно фальсифицировано отправителем пакета.
Всесторонняя защита протоколов TCP/IP может быть реализована с использованием методов, описываемых автором. В них большое значение имеет кодирование удостоверения, например кодового числа, которое защищает сообщение от несанкционированного изменения. (В протоколе TCP далеко не все построено на простом кодировании. Возвращаемые при каждом ответе случайные порядковые номера, по своей сути, являются недолговечным разделяемым секретом для каждого соединения. Разделяемые двумя сторонами секретные данные будут обсуждены в следующем разделе.)
Хотя очевидно, что кодирование необходимо для взаимодействия с другими хостами, тем не менее эта глава не о взаимодействии. Эта глава об идентификации. Достаточно ли предусмотренной в протоколе возможности понимать и говорить с другим хостом, для того чтобы подтвердить свою подлинность при получении доступа?
Для общедоступных сервисов это очень важный вопрос.
В большинстве случаев Интернет обслуживает внутренние потоки данных, не тревожа своих клиентов. Доказательство их подлинности может быть сведено к одному запросу HTTP с методом GET/. (В данном случае точка является знаком препинания, завершающим предложение, а не ссылкой слэш-точка. Обязательная ссылка слэш-точка в тексте выделяется курсивом.)
Описанный в RFCl945 метод запроса GET протокола HTTP известен многим. Есть возможность реализовать аутентификацию на более высоких уровнях, если они поддерживаются этим протоколом. Причем их модернизация может быть выполнена в достаточно мягкой форме. В основном доступ к системе зависит от знания протокола HTTP и возможности установить успешное соединение по протоколу TCP c использованием его стандартного порта 80.
Но не все протоколы открыты для общественности. Из-за недокументированных возможностей или наложенных ограничений на примеры программного кода внутренняя часть многих протоколов скрыта от постороннего взгляда. Для многих протоколов простой возможности говорить оказывается достаточным, чтобы считать собеседника достойным для предоставления затребованных им прав и уровня доверительных отношений. Считается, что если собеседник может разговаривать на понятном для системы языке, то он достаточно квалифицирован, чтобы использовать ее.
К сожалению, это не означает, что любой захочет связаться с системой.
Война между сторонниками открытых и закрытых исходных текстов программ в последнее время резко обострилась и в настоящее время находится в самом разгаре. В ней есть много такого, что вызывает сомнения. Но один аргумент может решить исход войны. Возможность разговаривать с кем-либо никогда не следует рассматривать достаточным основанием для предоставления рабочим станциям полномочий или для выдачи им распоряжений выполнить произвольную команду. Следует предусмотреть, чтобы серверы всегда предоставляли что-то, возможно даже пароль, прежде чем они смогут выполнять команды на клиентских машинах сети.
По всей видимости, до тех пор, пока не будет введено это ограничение, серверу вне зависимости от места его расположения будет предоставлено право повсюду управлять другими хостами.
Кто допустил эту ошибку?
Эту ошибку допустили Microsoft и Novell одновременно. Клиентские программы обеих компаний (возможно, исключая сети Windows 2000 с поддержкой технологии аутентификации и шифрования с открытым ключом Kerberos) после подключения не предусматривают какой-либо аутентификации в доменах, через которые они вошли в систему. В действительности домены, работающие с клиентскими программами названных компаний, могут только сказать: «Добро пожаловать в мой домен. Вот для вас сценарий команд, который вы сможете выполнить после подключения». В основе сказанного лежит предположение, что всякий, кто когда-либо подключился к локальной вычислительной сети, является ее законным пользователем. При этом полагается, что физическая безопасность офиса (вероятно, то место, где находится локальная вычислительная сеть) способна предотвратить появление фальсифицированных сервисов. Вот что автор писал в мае l999 года:
...
«В большинстве сетей с архитектурой клиент-сервер можно найти сценарий входа в систему. Сценарий содержит набор команд, которые будут выполнены после ввода правильного имени пользователя и его пароля. Сценарий входа в систему представляет корпоративным системным администраторам средство централизованного управления группами клиентов. К сожалению, то, что представляется хорошим решением для бизнеса, оказалось настоящим бедствием для системы защиты университетской сети, к которой студенты подключаются из своих комнат в общежитиях. Благодаря возможности подключения студентов из своих комнат появилась единая точка получения доступа к любому числу ранее не скомпрометированных клиентов. Последствия этой ошибки очень серьезны, и ее следует немедленно устранить. Даже пользователям корпоративной сети следует принять во внимание этот недостаток и потребовать реализации ряда описанных здесь процедур безопасности, защищающих их сети».
Дэн Каминский (Dan Kaminsky)
...
«При проектировании сетей была допущена ошибка, уменьшающая их надежность: непредвиденные последствия сценариев входа в систему (Insecurity by Design: The Unforeseen Consequences of Login Scripts)».
www.doxpara.com/login.html
Способность доказывать знание разделяемого секрета: «Есть ли секретные данные, известные как мне, так и системе?»
Это первая потенциальная возможность проверки, в которой используются криптографические методы безопасной идентификации. Разделяемые секреты в значительной степени предполагают наличие лексем, которые два хоста совместно используют при общении друг с другом. Разделяемые секреты могут использоваться для установления соединения, которое характеризуется следующим:
• конфиденциальностью. Передаваемые по сети данные воспринимаются всеми хостами как шумовые помехи, за исключением одного хоста, которому они предназначены;
• установлением подлинности. Каждая сторона зашифрованного соединения уверена в подлинности идентификационных данных другой стороны;
• проверкой целостности. Любой поток данных, передаваемый по зашифрованному соединению, не может быть разделен на части, похищен или изменен путем добавления посторонних данных.
Простым примером разделяемого секрета является короткое слово или фраза, известное обоим участникам соединения, которое в общем случае не удовлетворяет трем перечисленным свойствам, но тем не менее позволяет обеспечить разумную безопасность используемым технологиям. Сказанное не означает существования подобных систем в прошлом. Используемый набор паролей во многом определяет успех применения систем, удостоверяющих подлинность своих пользователей. К сожалению, на многих сайтах Telnet занимает лидирующие позиции среди технологий обмена паролями. Вызывает сожаление, что для обмена паролями большинство сайтов не используют профиль сообщения (короткую цифровую строку фиксированной длины, формируемую из более длинного сообщения с использованием специального алгоритма), получаемый с помощью стандарта MD5.
Если пароль каждой компании был бы напечатан в специально выделенной для этой цели колонке газеты New York Times, то могло быть и хуже. Это несколько успокаивает. «Если работает межсетевой экран, то можно не ждать подвоха ни от одного из своих устройств. По крайней мере, хоть пароли не напечатаны в New York Times».
Шутки в сторону. Современные системы разделения секрета – это криптографические системы, которые защищают криптографическими методами охраняемые ими системы. Почти всегда используются приличные протоколы с хорошими функциональными возможностями, но с очень плохой защитой. Пожалуй, следует отметить преимущества протоколов RIPv2 и TACACS+ по сравнению с оригинальными протоколами RIP и TACACS/XTACACS соответственно. Но и они страдают от двух главных проблем.
Во-первых, их криптография не очень хороша. Компания Solar Designer в документе «Анализ протокола TACACS+ и его реализации» приводит пример того, насколько идеально переговоры по поводу TACACS напомнили бы консультацию по вопросам безопасности. Этот документ размещен по адресу www.openwall.com/advisories/0W-00l-tac_plus.txt. Фальсифицировать пакеты таким образом, чтобы они казались бы знающими разделяемый секрет, – не очень трудная задача для подкованного злоумышленника с возможностями активного спуфинга.
