Обеспечение информационной безопасности в сетях IP

Принципы создания защищенных систем связи в распределенных вычислительных системах

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

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

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

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

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

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

Плюсы распределенной ВС с выделенными каналами связи между объектами состоят в следующем:

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

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

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

Итак, в завершение данного пункта сформулируем первый принцип создания защищенных средств связи объектов в РВС:

Утверждение 1.
Наилучшее с точки зрения безопасности взаимодействие объектов в распределенной ВС возможно только по физически выделенному каналу.

Виртуальный канал как средство обеспечения дополнительной идентификации/аутентификации объектов в распределенной ВС

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итак, в завершение очередное требование к защищенным системам связи в распределенных ВС.

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

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

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

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

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

Однако в РВС с неопределенным и достаточно большим числом объектов (например, Internet) спроектировать систему с отсутствием неопределенности практически невозможно. В этом случае отказаться от алгоритмов удаленного поиска не представляется возможным.

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

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

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

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

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

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

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

[Назад] [Содержание] [Вперед]