Защита информации, виртуальные частные сети (VPN). Технология ViPNet.

Использование разбиения

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

Пример виртуального маршрутизатора. К примеру, если Global Domination Networks отдаст в аренду Gotham Network Solutions половину емкости маршрутизатора, тогда каждый пакет GNS будет помечаться одним и тем же идентификатором потока, а маршрутизаторы GNS на сетевых маршрутах, оговоренных в контракте, будут отдавать половину своих ресурсов для GNS. В конечном итоге резервирование создает виртуальный маршрутизатор, выделенный для GNS. Мы можем даже представить сценарий, в котором пакеты GNS получают отказ от обслуживания из-за переполнения, хотя части тех же маршрутизаторов, принадлежащие GDN, простаивают.

Может возникнуть впечатление, что если у GDN возникает избыток доступных ресурсов, то она должна предложить их GNS. По здравому размышлению, однако, становится ясно, что решение будет корректным только в том случае, если при достижении уровня, оговоренного в контракте, GNS будет отказываться от обслуживания новых пакетов. Проблема в том, что такие протоколы, как Transmission Control Protocol, разработаны так, что они приостанавливают обработку «лишних» пакетов в том случае, когда возникает переполнение.

Предположим, гипотетически, что GDN позволила GNS использовать полосу пропускания на 20% больше, чем указано в контракте, просто потому, что GNS превысила отведенную ей емкость. TCP теперь будет работать на скорости, которая дает значительную перегрузку. Теперь представьте, что трафик на стороне GDN резко вырос, вынудив тем самым GDN вернуть GNS в границы ресурсов, определенных в контракте. TCP вместо того, чтобы спрогнозировать приближающуюся перегрузку внезапно обнаружит, что скорость потери пакетов резко возросла, а это, скорее всего, приведет к сбою в работе, чего можно было бы избежать, если бы GNS ограничилась бы теми услугами, за которые она заплатила.

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

Отметим, что разбиение маршрутизатора порождает такую сеть с перекрытиями, которую реализует один провайдер Internet за счет другого. Как видно из примера, весь трафик, передаваемый через GDN от имени GNS, существует внутри одной разделяемой сети с перекрытиями, конкурируя с другим трафиком в той же самой надстраиваемой сети, но в любом случае на него не влияет трафик, порожденный другими потоками.

Реализация нескольких сетей с перекрытиями. Для начала представьте, что мы расширили этот существующий механизм до такого, который может поддерживать тысячи, а то и десятки тысяч потоков, но в остальном ведет себя точно также. Gotham Hospital в таком случае может приобрести несколько сетей с перекрытиями у GNS, которая резервируют ресурсы для сетей с перекрытиями на маршрутизаторах, связанных с маршрутизаторами, установленными между конечными точками сети госпиталя Gotham Hospital. В общем, каждая надстраиваемая сеть будет обслуживать некое большое число конечных точек. К примеру, госпитальная система мониторинга, возможно, будет «продолжена» в дома некоторых амбулаторных больных и может включать в себя несколько сотен мониторинговых устройств, которые совместно используют одну сеть с перекрытиями.

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

В этом примере есть два важных момента. Во-первых, каждая сеть с перекрытиями гарантирует изоляцию приложений, взаимодействующих в различных потоках. Эта фундаментальная особенность – ключ к созданию свойств более высокого уровня. А, во-вторых, поскольку каждая сеть с перекрытиями рассматривает поток как объединение, маршрутизаторы сталкиваются с проблемами резервирования, которые растут линейно с увеличением числа сетей с перекрытиями. Госпиталю Gotham Hospital, в котором могут использоваться тысячи компьютеров, потребуется множество VON. В отличие от проблемы O(n2), теперь есть лишь линейная зависимость от числа «предприятий», которые используют сеть, что на порядок меньше числа конечных точек.

Создание VON

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

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

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

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

Итак, можно сказать, что VON походит на то, что специалисты по распределенным вычислениям называют «группой процессов». Необходимые свойства групповых коммуникаций будут зависеть от требований приложения и, в отличие от классической работы по распределенным вычислениям, надстраиваемая сеть сама могла бы обеспечить базовый уровень гарантий, отражающий выделение ресурсов от ее имени.

К примеру, рассмотрим протокол TCP. В традиционной сети мы, по сути, не можем утверждать, что соединение TCP надежно. Такое соединение потенциально может быть прервано в случае нарушения инфраструктуры, даже если ни в одной из конечных точек не возник сбой. В случае соединения TCP в пределах VON идентичный протокол может предложить более надежные гарантии, например того, что не работает не более одного сетевого канала или маршрутизатора, и соединение TCP никогда не будет прервано до тех пор, пока сбой не возник ни на одной из конечных точек, которые оно связывает. Эти специфические гарантии могут потребовать определенной избыточности в сети с перекрытиями, но мы можем представить все виды гарантий, формулируемых в терминах низкого уровня, преобразуя их свойства более высоких уровней, «видимые» через TCP и другие протоколы.

Обобщая, можно сказать, что VON создаются из сети с перекрытиями за счет абстрагирования. Иными словами, мы наслаиваем одну или несколько реализованных на программном уровне абстракций на сеть с перекрытиями, так что каждый уровень расширяет стек протоколов и сеть с перекрытиями находится ниже него, во многом так же, как абстрактные типы данных могут улучшать свойства родительского типа. Действительно, мы можем представлять себе сеть с перекрытиями как класс, а VON – как подкласс.

Этот метод создания распределенных протоколов за последние десять лет стал весьма популярным. Он был представлен как «потоковая» архитектура STREAMS, получившая распространение в Unix-системах, а затем обобщен в x-Kernel и адаптирован к групповым приложениям в работе, которую мои коллеги и я проделали при создании систем Horus и Ensemble. Последняя работа показывает, как использовать формальные методы для определения, оптимизации и подтверждения свойств систем, структурированных подобным образом.

Рис. 2. В каждой из конечных точек в группе виртуальных сетей с перекрытиями элементы стека протоколов помогают в преобразовании свойств базовой сети с перекрытиями в требуемые свойства VON.

Принимая во внимание такую перспективу, становится возможным применить многие наработки из области групповых коммуникациях к реализации VON, как показано на рисунке 2. Мы, к примеру, разработали четыре типа систем групповых коммуникаций:

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

Мы можем рассматривать каждый из этих типов систем как некую инфраструктуру, которая поддерживает некоторый класс VON. Подобная поддержка могла бы проявиться двояко.

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

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

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

Суть моего предложения состоит в успешном усилении основных свойств за счет наслаивания программного обеспечения поверх базовых VON и, в конечном итоге, поверх базовой сети с перекрытиями при строгой изоляции и гарантиях резервирования ресурсов. Мы могли бы использовать те же виды протоколов и в Internet, но в Internet отсутствуют какие-либо гарантии. Такое решение может оказаться успешным, но, скорее всего, мы не сможем добиться желаемого результата, потому что многие свойства реализуются именно за счет свойств базовой сети с перекрытиями и изоляции надстраиваемой сети от внешнего вмешательства. Однако, наделив сеть с перекрытиями даже простейшими изоляционными свойствами, мы можем найти способы усилить их. В общем, мы должны представлять себе суть компромисса, в частности, что придется согласиться на дополнительные коммуникации для того чтобы добиться более высокой надежности.

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

Пока остается множество вопросов относительно сетей VON; непонятно даже, насколько они решаемы в принципе. Связанные с ними работы были проведены в сообществе, занимающемся «виртуальными сетями», а также представлено множество исследований, посвященных управлению сетями ATM, предлагающих гарантии качества обслуживания.

Разработчики критически важных приложений столкнутся с немалыми трудностями с появлением Internet следующего поколения. Новая сеть, скорее всего, будет быстрее, но не надежнее. Было бы очень прискорбно, если бы мы не смогли сделать этого теперь, когда внимание исследователей и их ресурсы сосредоточены на этой проблеме, и пока наша жизнь еще не зависит от степени безопасности операций ожидаемой новой волны критически важных сетевых систем.

Кеннет Бирман – профессор факультета информатики Корнеллского университета. К области его научных интересов относятся отказоустойчивость, надежность и безопасность распределенных компьютерных систем. С ним можно связаться по электронной почте по адресу: ken@cs.cornell.edu. (опубликовано в журнале "Открытые Системы", #09/2000)

[Apr 17-25] Security Info digest #30 (по материалам Аналитического центра компьютерной безопасности (АЦ) www.sert.ru)

По данным http://www.attrition.org/mirror/attrition/ за период с 17 по 25 апреля было взломано 495 Веб сайтов, в том числе в домене .ru - Yuri M. Kikvadze (www.kikvadze.ru)

В функции glob(3) обнаружено переполнение буфера. Практически воспользоваться ей можно, используя сервер сервер ftpd ( в частности, он поставляеется в дистрибутиве OS FreeBSD). Уязвимости подвержены FreeBSD 3.x (все релизы), FreeBSD 4.x (все релизы), FreeBSD 3.5-STABLE до 2001-04-17 и 4.3-RC до 2001-04-17. Используя уязвимость можно выполнить специальный код и получить полномочия пользователя, под которым запущен процесс ftpd сервера - обычно root.

Уже выпущено несколько патчей:
- для FreeBSD 3.x:
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-01:33/glob.4.x.patch

- для FreeBSD 4.x:
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-01:33/glob.3.x.patch

Подробнее:
http://www.securityfocus.com/

В дистрибутиве BIND 4.9.7, поставляемом SGI и идентифицирующим себя как "eoe.sw.named" в поле VERSION.BIND, обнаружена уязвимость, позволяющая удаленному пользователю получить полномочия пользователя под которым запущен сам named, обычно root.
Подробне о уязвимостях в BIND 4.x:
http://www.cert.org/advisories/CA-2001-02.html

Подробнее о исправлении бага:
http://www.securityfocus.com/

В порте samba (и самой samba 2.0.7 и более ранних версий) OS Trustix Secure Linux (TSL) обнаружена уязвимость, позволяющая локальному пользователю, имеющему имеющему право пользоваться samba, получить полномочия пользователя root. Уязвимости подвержены следующие версии:
TSL 1.01, 1.1, 1.2. Проблема заключается в функции mktemp(3), используемой для создания временных файлов.
Подробнее:
http://www.trustix.net/errata/misc/2001/TSLSA-2001-0005-samba.asc.txt

В одной из самых популярных утилит для работы с почтой - The Bat! версии 1.51 - обнаружена возможность ДоС атаки. Дело в том, что при
приеме почты через POP3 сервис (IMAP не тестировался) The Bat! неправильно обрабатывает 0x0D (CR) символ в случае, если за ним не следует 0x0A (LF). Следствием этого является некорректный подсчет длины сообщения и его часть интерпретируется как ответ от POP3
сервера. Соответственно, The Bat! не может закончить прием оставшихся сообщений и может стереть уже принятые им сообщения с сервера.
Подробнее:
http://www.securityfocus.com/

В порте sudo (версия sudo 1.6.3.7 и предыдущие) OS FreeBSD содержится уязвимость (переполнение буфера командной строки), которая может привести к получению локальным пользователем полномочия root. Для устранения уязвимости необходимо установить исправленную версию:

- Для FreeBSD 4.2-STABLE:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/security/sudo-1.6.3.7.tgz

- Для FreeBSD 5.x-CURRENT:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/security/sudo-1.6.3.7.tgz

Подробнее:
http://www.securityfocus.com/

В апреле 2001 года компания Инфотекс и компания Крипто-Про заключили соглашение о взаимовыгодном сотрудничестве.

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

ОАО Инфотекс (Информационные Технологии и Коммуникационные Системы) уже больше 10 лет развивает собственные запатентованные продукты в области корпоративных сетевых решений и средств защиты информации, осуществляет управление крупными проектами по созданию корпоративных сетей и сетей связи общего пользования. Решения компании Инфотекс учитывают интересы всех категорий пользователей от крупных корпораций до индивидуальных заказчиков.

В основу программных продуктов положена уникальная разработка ПО "Корпоративная наложенная сеть ИНФОТЕКС", распространяемая на рынке под торговой маркой ViPNet. Предлагаемое сетевое решение одновременно является:

- Гибким и эффективным средством построения корпоративных VPN совместимых с любым сетевым и коммуникационным оборудованием ранее закупленным корпоративным клиентом, что позволяет резко сократить расходы на организацию VPN
- Сетевым экраном обеспечивающим защиту не только локальных сегментов сети, но и каждую рабочую станцию, мобильных пользователей, серверов WWW, FTP, баз данных и т.д.
- Шифратором IP потоков (криптоядро Домен-К) создаваемых каждым элементом сети и прикладными программами в сети.

Сетевое решение компании Инфотекс сертифицировано Гостехкомиссией по классу защиты информации 1В для автоматизированных систем и 3 классу - для межсетевых экранов. Это дает возможность хранить, обрабатывать и пересылать конфиденциальную информацию. Криптоядро Домен-К, обеспечивающее высокоскоростное абонентское шифрование IP трафика, согласно Заключению ФАПСИ удовлетворяет "Требованиям к средствам криптографической защиты конфиденциальной информации по классам КС1 и КС2"

Основным направлением деятельности компании Крипто-Про является разработка средств защиты информации и развитие Инфраструктуры Открытых Ключей (Public Key Infrastructure) на основе использования международных рекомендаций и российских криптографических алгоритмов.
Средство криптографической защиты информации КриптоПро CSP реализует российские криптографические алгоритмы и разработано в соответствии с криптографическим интерфейсом фирмы Microsoft - Cryptographic Service Provider (CSP), что обеспечивает широчайшее применение на рынке ввиду повсеместного использования продуктов Microsoft.

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

К стандартным приложениям, которые теперь могут использовать российские алгоритмы электронной цифровой подписи и шифрования, относятся:
- Центр Сертификации - Microsoft Certification Authority
- Электронная почта - Microsoft Outlook
- Электронная почта - Microsoft Outlook Express
- Средства контроля целостности ПО - Microsoft Authenticode
- Защита соединений в Интернете (протокол TLS/SSL в стандартном Internet Explorer)

Для встраивания в приложения используются функции Microsoft CryptoAPI 2.0, подробное описание которых приведено в программной документацией MSDN (Microsoft Developer Network). Использование функций CryptoAPI 2.0, а также дополнительных средств разработки (Certificate Enrollment Control, Certificate Services) позволяет использовать огромный инструментарий фирмы Microsoft, для реализации различных защищенных систем документооборота и электронной коммерции, с использованием Инфраструктуры Открытых Ключей (PKI), соответствующей международным рекомендациям X.509, RFC 2459.

Согласно сертификатам ФАПСИ, СКЗИ КриптоПро CSP соответствует требованиям ГОСТ 28147-89, ГОСТ Р34.11-94, ГОСТ Р34.11-94 и требованиям ФАПСИ к стойкости СКЗИ и может использоваться для формирования ключей шифрования и ключей электронной цифровой подписи, шифрования и имитозащиты данных, обеспечения целостности и подлинности информации, не содержащей сведений, составляющих государственную тайну. СКЗИ КриптоПро CSP обеспечивает безопасность информации по уровню "КС1" и "КС2" в соответствии с классификацией ФАПСИ уровней безопасности средств криптографической защиты конфиденциальной информации.

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

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

Главными свойствами совместного продукта компаний Инфотекс и Крипто-Про
- возможность создания VPN на основе шифрования IP-трафика,
- использование международных стандартов PKI, столь необходимых для развития всевозможных приложений Интернет-коммерции и развертывания сети удостоверяющих центров
- возможность встраивания средств защиты информации в общеизвестные системы электронной почты и документооборота (Outlook, Lotus Notes),
- использование аппаратных криптоакселераторов для ускорения выполнения криптографических функций до 1 ГГб в секунду и для защиты от несанкционированного доступа.

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

Руководством Главного управления безопасности связи ФАПСИ утверждено Заключение (2/5/2-292 от 20.04.01) о соответствии средства криптографической защиты информации (СКЗИ) "Домен-К" требованиям к средствам криптографической защиты конфиденциальной информации.

В соответствии с указанным заключением следует, что:

1. СКЗИ "Домен-К" удовлетворяет "Требованиям к средствам криптографической защиты конфиденциальной информации по классу КС2 при выполнении требований нормативных документов

2. СКЗИ "Домен-К" разрешается эксплуатировать до 1 мая 2004 года.

3. Для использования СКЗИ после указанного срока, фирма "Инфотекс" до1 мая 2003 года должна установленным порядком заказать работы по проведению контрольных тематических исследований.

Полнофункциональные демо-версии продуктов ViPNet Desk, TermiNet, ViPNet Office, ViPNet Tunnel находятся по адресу 
http://www.infotecs.ru/demo.htm

Если у вас есть какие-нибудь пожелания или вопросы по поводу дальнейших выпусков рассылки, мы с удовольствием рассмотрим их.