Защита от хакеров корпоративных сетей
Шрифт:
• возможность изменять некоторые или все необработанные биты данных либо пакеты в уже существующем потоке данных прежде, чем они достигнут своего адресата. Возможности передачи данных увеличиваются. Появляется возможность первичной обработки некоторых битов данных или даже целых пакетов, если это будет необходимо;
• возможность генерировать некоторые или все необработанные биты или пакеты из потока данных как реакцию на перехват и прослушивание пакетов. Последствия этой возможности очевидны, как очевидно и то, что они не единственны;
• возможность модифицировать некоторые или все необработанные
• возможность удалять некоторые или все необработанные биты данных либо пакеты в зависимости от их содержания. Выборочное удаление данных реализовать сложнее модуляции, потому что получаемый при этом сигнал будет рассинхронизирован со своим оригиналом. Изохронному потоку данных (потоку данных с одинаковой скоростью передачи) требуется задержка для предотвращения передачи ложных указателей. (Нужно что-то послать, не так ли? Спертый воздух и будет этим чем-то.)
Вполне возможно, что любая из этих дополнительных возможностей может быть использована для законного подтверждения подлинности пользователя. За исключением случаев повреждения пакета (которые имеют место только тогда, когда удаление или изящная модификация данных невозможна, а пакет в любом случае не должен достичь своего адресата), все эти операции обычны для межсетевых экранов, концентраторов частных виртуальных сетей VPN и даже маршрутизаторов шлюзов.
Что из себя представляет переменная? Немного уже упоминалось о переменной, которая может потребоваться для прослушивания, вероятной генерации или представления какой-либо характеристики хоста с целью фальсификации потенциальной способности протокола отвечать на запросы.
Так что это за переменная?
Рассмотренные две возможности передать и ответить по своему значению чуть превосходят центральные концепции, которые лежат в основе представления бит на цифровом носителе и позволяют интерпретировать их одним из возможных способов. Обе эти возможности не представляют ни одну из форм интеллектуального знания относительно предназначения этих бит в контексте управления данными идентификации. Такими знаниями обладают упоминавшиеся возможности обработки потока данных, которые в большей степени основаны на общих криптографических конструкциях установления подлинности.
Способность к кодированию: «Система может говорить на моем языке?»
Способность к передаче предполагает, что пользователь может послать биты, а если у него есть возможность ответить, то получить, прочитать их и при необходимости ответить на полученные биты. Но как узнать, что нужно каждой из сторон? Так
Относительно разговора о спуфинге протокола IP. TCP/IP – это стек (набор) протоколов, и протокол IP – один из них, причем он требует поддержки. Для защиты протокола IP от спуфинга следует использовать протоколы (подобные протоколу TCP), в которых при инициализации соединения предусмотрен обязательный ответ и которые могут лишить возможности передачи, бесцеремонно сбрасывая полученные данные в битоприемник (bit bucket) (это гипотетическая корзина, в которую сбрасываются «мусорные» записи базы данных), тем самым защищая сеть от входящих и выходящих пакетов, относительно содержимого которых появилось подозрение, что оно фальсифицировано отправителем пакета.
Всесторонняя защита протоколов TCP/IP может быть реализована с использованием методов, описываемых автором. В них большое значение имеет кодирование удостоверения, например кодового числа, которое защищает сообщение от несанкционированного изменения. (В протоколе TCP далеко не все построено на простом кодировании. Возвращаемые при каждом ответе случайные порядковые номера, по своей сути, являются недолговечным разделяемым секретом для каждого соединения. Разделяемые двумя сторонами секретные данные будут обсуждены в следующем разделе.)
Хотя очевидно, что кодирование необходимо для взаимодействия с другими хостами, тем не менее эта глава не о взаимодействии. Эта глава об идентификации. Достаточно ли предусмотренной в протоколе возможности понимать и говорить с другим хостом, для того чтобы подтвердить свою подлинность при получении доступа?
Для общедоступных сервисов это очень важный вопрос.
В большинстве случаев Интернет обслуживает внутренние потоки данных, не тревожа своих клиентов. Доказательство их подлинности может быть сведено к одному запросу HTTP с методом GET/. (В данном случае точка является знаком препинания, завершающим предложение, а не ссылкой слэш-точка. Обязательная ссылка слэш-точка в тексте выделяется курсивом.)
Описанный в RFCl945 метод запроса GET протокола HTTP известен многим. Есть возможность реализовать аутентификацию на более высоких уровнях, если они поддерживаются этим протоколом. Причем их модернизация может быть выполнена в достаточно мягкой форме. В основном доступ к системе зависит от знания протокола HTTP и возможности установить успешное соединение по протоколу TCP c использованием его стандартного порта 80.
Но не все протоколы открыты для общественности. Из-за недокументированных возможностей или наложенных ограничений на примеры программного кода внутренняя часть многих протоколов скрыта от постороннего взгляда. Для многих протоколов простой возможности говорить оказывается достаточным, чтобы считать собеседника достойным для предоставления затребованных им прав и уровня доверительных отношений. Считается, что если собеседник может разговаривать на понятном для системы языке, то он достаточно квалифицирован, чтобы использовать ее.