Информационная безопасность в условиях функционирования глобальных сетей

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

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

Любое взаимодействие двух объектов в распределенной ВС должно проходить по виртуальному каналу связи.

Рассмотрим, как в распределенной ВС виртуальный канал (ВК) связи может использоваться для надежной, независимой от топологии и физической организации системы, идентификации ее удаленных объектов.

Для этого при создании ВК могут использоваться криптоалгоритмы с открытым ключом (например, в Internet принят подобный стандарт защиты ВК, называемый Secure Socket Layer - SSL). Данные криптоалгоритмы основаны на результатах исследований, полученных в 70-х годах У. Диффи. Он ввел понятие односторонней функции с потайным входом. Это не просто вычисляемая в одну сторону функция, обращение которой невозможно, она содержит потайной вход (trapdoor), который позволяет вычислять обратную функцию лицу, знающему секретный ключ. Сущность криптографии с открытым ключом (или двухключевой криптографии) в том, что ключи, имеющиеся в криптосистеме, входят в нее парами и каждая пара удовлетворяет следующим двум свойствам:

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

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

В 1976 г. У. Диффи и М. Хеллман предложили следующий метод открытого распределения ключей. Пусть два объекта A и B условились о выборе в качестве общей начальной информации большого простого числа p и примитивного корня степени p - 1 из 1 в поле вычетов по модулю p. Тогда эти пользователи действуют в соответствии с протоколом (рис. 1):

A вырабатывает случайное число x, вычисляет число a^x (mod p) и посылает его B;

B вырабатывает случайное число y, вычисляет число a^y (mod p) и посылает его A;

 

 

затем A и B возводят полученное число в степень со своим показателем и получают число a^xy (mod p).

Рисунок 4. Алгоритм У. Диффи и М. Хеллмана открытого распределения ключей

Это число и является сеансовым ключом для одноключевого алгоритма, например, DES. Для раскрытия этого ключа криптоаналитику необходимо по известным a^x (mod p), a^y (mod p) найти a^xy (mod p) , т.е. найти x или y. Нахождение числа x по его экспоненте ax (mod p) называется задачей дискретного логарифмирования в простом поле. Эта задача является труднорешаемой, и поэтому полученный ключ, в принципе, может быть стойким.

Особенность данного криптоалгоритма состоит в том, что перехват по каналу связи пересылаемых в процессе создания виртуального канала сообщений a^x (mod p) и a^y (mod p) не позволит атакующему получить конечный ключ шифрования a^xy (mod p). Этот ключ далее должен использоваться, во-первых, для цифровой подписи сообщений и, во-вторых, для их криптозащиты. Цифровая подпись сообщений позволяет надежно идентифицировать объект распределенной ВС и виртуальный канал. Шифрование сообщений необходимо для соблюдения Утверждения 2. В заключении к данному пункту сформулируем следующее требование к созданию защищенных систем связи в распределенных ВС и два следствия из него:

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

Необходимо обеспечить цифровую подпись сообщений.

Необходимо обеспечить возможность шифрования сообщений.

5.2. Контроль за маршрутом сообщения в распределенной ВС

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

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

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

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

Из всего вышесказанного следует следующее требование к созданию защищенных систем связи в распределенных ВС:

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

5.3 Контроль за виртуальными соединениями в распределенной ВС

В предыдущей главе было показано, что взаимодействие объектов РВС по виртуальному каналу позволяет надежно защитить соединение от возможных информационно-разрушающих воздействий по каналам связи. Однако взаимодействие по ВК имеет свои минусы. К минусам относится необходимость контроля за соединением. Если в системе связи удаленных объектов РВС не предусмотреть использование надежных алгоритмов контроля за соединением, то, избавившись от одного типа удаленных атак на соединение ("Подмена доверенного объекта"), можно подставить систему под другую типовую УА - "Отказ в обслуживании". Поэтому для обеспечения надежного функционирования и работоспособности (доступности) каждого объекта распределенной ВС необходимо прежде всего контролировать процесс создания соединения. Как уже говорилось ранее, задача контроля за ВК распадается на две подзадачи:

1. контроль за созданием соединения;
2. контроль за использованием соединения.

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

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

Основная задача, которую необходимо решить в данном случае, состоит в том, чтобы не позволить одному субъекту взаимодействия занять все виртуальные каналы системы. Напомним, что при создании ВК полученный системой запрос на создание соединения ставится в очередь запросов, и, когда до него дойдет время, система выработает ответ на запрос и отошлет его обратно отправителю запроса. Задача контроля за созданием соединения заключается как раз в том, чтобы определить те правила, исходя из которых система могла бы либо поставить запрос в очередь, либо нет. Если все пришедшие запросы автоматически ставятся системой в очередь (так построены все сетевые ОС, поддерживающие протокол TCP/IP), то это в случае атаки ведет к переполнению очереди и к отказу в обслуживании всех остальных легальных запросов. Такое происходит из-за того, что атакующий посылает в секунду столько запросов, сколько позволит трафик (тысячи запросов в секунду), а обычный пользователь с легальным запросом на подключение может послать лишь несколько запросов в минуту! Следовательно, вероятность подключения в такой ситуации, при условии переполнения очереди, один к миллиону в лучшем случае. Поэтому необходимо ввести ограничения на постановку в очередь запросов от одного объекта. Однако, если в РВС любой объект системы может послать запрос от имени (с адреса) любого другого объекта системы, то, как отмечалось ранее, решить задачу контроля не представляется возможным. Поэтому для обеспечения этой возможности было введено Утверждение 5, исходя из которого в каждом пришедшем на объект пакете должен быть указан пройденный им маршрут, позволяющий с точностью до подсети подтвердить подлинность адреса отправителя. Учитывая данный факт, позволяющий отсеять все пакеты с неверным адресом отправителя, можно предложить следующее условие постановки запроса в очередь: в системе вводится ограничение на число обрабатываемых в секунду запросов из одной подсети.

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

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

Для обеспечения доступности ресурсов распределенной ВС необходим контроль за виртуальными соединениями между ее объектами.

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

 

 

6. Конкретные примеры атак на TCP/IP

 

6.1 Пассивные атаки на уровне TCP

 

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

Атака заключаются в перехвате сетевого потока и его анализе (Англоязычные термин - "sniffing")

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

Второй вариант - крэкер получает доступ к машине, которая расположена в одном сегменте сети с системой, которой имеет доступ к сетевому потоку. Например, в сети "тонкий ethernet" сетевая карта может быть переведена в режим, в котором она будет получать все пакеты, циркулирующие по сети, а не только адресованной ей конкретно. В данном случае крэкеру не требуется доступ к UNIX - достаточно иметь PC с DOS или Windows (частая ситуация в университетских сетях)

Поскольку TCP/IP-трафик, как правило, не шифруется (мы рассмотрим исключения ниже), крэкер, используя соответствующий инструментарий, может перехватывать TCP/IP-пакеты, например, telnet-сессий и извлекать из них имена пользователей и их пароли.

Следует заметить, что данный тип атаки невозможно отследить, не обладая доступом к системе крэкера, поскольку сетевой поток не изменяется. Единственная надежная защита от подслушивания -- шифрование TCP/IP-потока (например, secure shell - защищенная оболочка) или использование одноразовых паролей (например, S/KEY)