Коллектив авторов - Защита от хакеров корпоративных сетей

Относительно разговора о спуфинге протокола 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 года:

Способность доказывать знание разделяемого секрета: «Есть ли секретные данные, известные как мне, так и системе?»

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

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