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

Создание защищенного канала передачи данных между распределенными информационными ресурсами предприятия

А. А. Теренин, к. т. н.,

специалист по обеспечению качества ИТ и ПО

«Дойче Банк Москва»

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

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

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

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

канал передачи данных должен быть постоянным,

данные, передаваемые по такому каналу, должны сохранять целостность, достоверность и конфиденциальность.

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

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

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

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

Более строгие требования предъявляются к системам обеспечения безопасности информационных транзакций в распределенной информационной среде, но это тема для отдельной статьи.

Как обеспечить подобную защиту канала передачи данных?

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

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

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

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

Рассмотрим подробно, как можно создавать защищенные каналы передачи данных через Интернет.

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

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

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

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

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

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

Из дополнительных требований к реализуемому защитному каналу передачи данных можно выделить:

идентификацию и аутентификацию взаимодействующих сторон;

процедуру защиты от подмены одной из сторон (использование криптоалгоритмов с открытым ключом);

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

конфигурирование и проверку качества канала связи;

компрессию передаваемой информации;

обнаружение и коррекцию ошибок при передаче данных по каналам связи;

аудит и регистрацию событий;

автоматическое восстановление работоспособности.

Построим модель нарушителя и модель объекта защиты (рис. 1).

Алгоритм установления соединения

Для реализации защищенного канала передачи данных используется клиент-серверная модель взаимодействия.

Рассматриваются две стороны: сервер и клиент – рабочая станция, которая хочет установить соединение с сервером для дальнейшей работы с ним.

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

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

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

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

Исходя из предположения, что ЗКС и ОКС уже созданы, причем ОКС известен всем, а ЗКС – только серверу, мы получаем следующий алгоритм:

1. Клиент посылает серверу запрос на соединение.

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

3. Клиент генерирует свои ключи (открытый и закрытый) для работы с сервером (ОКК и ЗКК ).

4. Клиент генерирует ключ сессии (КС ) (симметричный ключ шифрования сообщений).

5. Клиент передает серверу следующие компоненты:

открытый ключ клиента (ОКК );

ключ сессии;

случайное сообщение (назовем его Х ), зашифрованное открытым ключом сервера по алгоритму RSA .

6. Сервер обрабатывает полученное сообщение и посылает в ответ сообщение Х , зашифрованное ключом сессии (симметричное шифрование) + зашифрованное открытым ключом клиента (асимметричное шифрование, например алгоритм RSA ) + подписанное закрытым ключом сервера (RSA, DSA, ГОСТ ) (то есть если мы на стороне клиента после дешифрования получим опять Х, то это значит, что:

сообщение пришло от сервера (подпись – ЗКС );

сервер принял наш ОКК (и зашифровал нашим ключом);

сервер принял КС (зашифровал этим ключом сообщение).

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

8. В дальнейшем обе стороны начинают обмен сообщениями, которые подписываются закрытыми ключами отправителя и шифруются ключом сессии.

Схема алгоритма установления соединения приведена на рис. 2.

Алгоритм подготовки сообщения к отправке в защищенный канал

Постановка задачи звучит следующим образом: на вход алгоритма поступает исходный (открытый) текст, на выходе путем криптографических преобразований мы получаем закрытый и подписанный файл. Главная задача, поставленная перед этим алгоритмом, состоит в обеспечении безопасной передачи текста, обеспечении защиты в незащищенном канале.

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

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

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

Алгоритм может быть реализован следующим образом (рис. 3):

исходный текст сжимается с помощью алгоритма ZIP;

параллельно этому процессу происходит подпись исходного текста открытым ключом получателя;

сжатый текст шифруется симметричным ключом сессии, этот ключ тоже есть на приемной стороне;

к зашифрованному и сжатому тексту добавляется цифровая подпись, однозначно идентифицирующая отправителя;

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

Алгоритм обработки сообщения при приеме из защищенного канала

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

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

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

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

Алгоритм обработки сообщения при приеме из защищенного канала (рис. 4):

из полученного зашифрованного, сжатого и подписанного сообщения выделяется цифровая подпись;

текст без цифровой подписи дешифруется ключом сессии;

декодированный текст проходит процедуру разархивирования с использованием, например, алгоритма ZIP;

полученный в результате двух предыдущих операций текст используется для проверки цифровой подписи сообщения;

на выходе алгоритма мы имеем исходное открытое сообщение и результат проверки подписи.

Алгоритм подписи сообщения

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

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

Для нахождения значения хэшфункции можно применять известные алгоритмы хэширования (SHA, MD4, MD5, ГОСТ и др.), которые позволяют получить на выходе блок данных фиксированной длины. Именно с этим блоком и будет работать алгоритм цифровой подписи. В качестве алгоритма электронной цифровой подписи можно использовать алгоритмы DSA, RSA, Эль-Гамаля и др.

Опишем алгоритм подписи сообщения по пунктам (рис. 5):

на вход общего алгоритма поступает исходный текст любой длины;

вычисляется значение хэш-функции для данного текста;

ЭЦП ;

используя поступившие данные, вычисляется значение ЭЦП всего текста;

на выходе алгоритма мы имеем цифровую подпись сообщения, которая поступает дальше для присоединения к отправляемому в канал обмена данными пакету информации.

Алгоритм проверки подписи

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

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

Опишем алгоритм проверки подписи сообщения по пунктам (рис. 6):

на вход общего алгоритма поступает исходный текст любой длины и цифровая подпись этого текста фиксированной длины;

вычисляется значение хэш-функции от данного текста;

полученное отображение текста фиксированной длины поступает в следующий блок алгоритмической обработки;

в этот же блок направляется цифровая подпись, которая пришла на вход общего алгоритма;

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

с использованием поступивших данных вычисляется значение электронной цифровой подписи всего текста;

мы получили цифровую подпись сообщения, сравнивая которую с ЭЦП , поступившей на вход общего алгоритма, мы можем делать выводы о достоверности текста;

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

Возможные атаки на предложенную схему реализации защищенного канала связи

Рассмотрим наиболее распространенные примеры возможных атак на защищенный канал передачи данных .

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

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

При использовании для установления связи с сервером браузера (Internet Explorer или Netscape Navigator) мы доверяем этому браузеру и доверяем его проверке сертификатов посещаемых сайтов.

После проверки подписи на апплете можно доверять ОКС , который вшит в загружаемые с сервера данные или программы (апплеты).

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

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

Возможные атаки.

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

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

Для отражения данной атаки необходимо генерировать случайные числа, отвечающие ряду требований. Нельзя, например, использовать для генерации случайных чисел таймер, так как злоумышленник, перехватив первое сообщение (ОКС от сервера), может установить время отправления пакета с точностью до секунд. Если таймер срабатывает каждую миллисекунду, то для вскрытия необходим полный перебор всего лишь 60 000 значений (60 с _ 1000 мс).

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

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

4. При передаче от сервера к клиенту некоторого тестового сообщения Х , зашифрованного КС и ОКК и подписанного ЗКС . Чтобы расшифровать перехваченное сообщение, надо знать и ОКК , и КС , которые будут известны в случае реализации одной из приведенных выше атак после того, как противнику стал известен ЗКС .

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

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

Итак, мы рассмотрели атаки, возможные на этапе реализации процедуры «рукопожатия» (HandShake). Опишем атаки, которые могут осуществляться в процессе передачи данных по нашему каналу.

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

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

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

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

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

В самом начале работы, при подсоединении к серверу, возможна тривиальная атака: подмена DNS-сервера. Защититься от нее не представляется возможным. Решение данной проблемы возложено на администраторов DNS-серверов, находящихся в ведении интернет-провайдеров. Единственное, что может спасти, – это уже описанная выше процедура проверки сертификата сайта браузером, подтверждающая, что произошло подключение именно к нужному серверу.

Заключение

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

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

Подобную технологию организации защищенных соединений организует протокол сетевого взаимодействия SSL. Кроме этого, на основе предложенных принципов строятся виртуальные частные сети (Virtual Private Networks – VPN).

ЛИТЕРАТУРА

1. Медведовский И. Д., Семьянов П. В., Платонов В. В. Атака на Интернет. – СПб.: Изд-во «ДМК» 1999. – 336 с.

2. Карве А. Инфраструктура с открытыми ключами. LAN/Журнал сетевых решений (Russian edition), 8, 1997.

3. Мельников Ю. Н. Электронная цифровая подпись. Возможности защиты. Конфидент № 4 (6), 1995, с. 35–47.

4. Теренин А. А., Мельников Ю. Н. Создание защищенного канала в сети. Материалы семинара «Информационная безопасность – юг России», Таганрог, 28–30 июня 2000.

5. Теренин А. А. Разработка алгоритмов для создания защищенного канала в открытой сети. Автоматизация и современные технологии. – Изд-во «Машиностроение», № 6, 2001, с. 5–12.

6. Теренин А. А. Анализ возможных атак на защищенный канал в открытой сети, созданный программным способом. Материалы XXII Конференции молодых ученых механико-математического факультета МГУ, М, 17–22 апреля 2000.

В июле 1997 г. вышел руководящий документ "Средства вы-числительной техники. Межсетевые экраны. Защита от несанк-ционированного доступа к информации. Показатели защищенно-сти от несанкционированного доступа" Гостехкомиссии при Пре-зиденте РФ (полный текст можно найти в информационном бюл-летене "Jet Info" № 17-18 1997 г. и на узле http://www.infotecs.ru/gtc/RD_ekran.htm ). В этом документе дана классификация МЭ в зависимости от степени обеспечиваемой ими защиты от НСД. Определение самого МЭ таково: МЭ - это ло-кальное (однокомпонентное) или функционально-распределенное средство (комплекс), реализующее контроль за информацией, по-ступающей в автоматизированную систему (АС) и/или выходящей из АС, и обеспечивает защиту АС посредством фильтрации ин-формации, т.е. ее анализа по совокупности критериев и принятия решения о ее распространении в (из) АС.

Устанавливается пять классов защищенности МЭ: 5 (самый низкий) -- применяется для безопасного взаимодействия АС клас-са 1 Д с внешней средой, 4 -- для 1 Г, 3 -- 1 В, 2 -- 1 Б, 1 (самый вы-сокий) -- для 1А. (Напомним, что Гостехкомиссией РФ установ-лено девять классов защищенности АС от НСД, каждый из кото-рых характеризуется определенной совокупностью требований к средствам защиты. Классы подразделяются на три группы, отли-чающиеся спецификой обработки информации. Класс с цифрой "1" включает многопользовательские АС, в которых одновременно обрабатывается и/или хранится информация разных уровней кон-фиденциальности, и не все пользователи имеют равные права дос-тупа.)

В приведена некоторая справочная информация, где даны описания не-скольких систем МЭ. Список сертифицированных Гостехкомиссией РФ МЭ на июнь 1999 г. состоял из десяти наименований:

1) автоматизированная система разграничения доступа Black Hole (Milkyway Networks) версии BSDI-OS;

2) средство защиты от НСД в сетях передачи данных по про-токолу TCP/IP "ПАНДОРА" на базе Gauntlet 3.1.Н (Trusted Information Systems) и компьютера 02 (Silicon Graphics) под управлением IRIX 6.3;

3) аппаратно-программный комплекс "Застава-Джет" компа-нии Jet Infosystems и ЦНИИ-27 Министерства обороны РФ;

4) МЭ "Застава" FortE+ фирмы ЭЛВИС+;

5) партия средств программного обеспечения межсетевого эк-рана FireWall-1 фирмы Checkpoint Software Technologies;

6) комплекс защиты информации от НСД "Data Guard/24S";

7) программный продукт SKIP для регулирования доступа на интерфейсе локальная/глобальная сеть под управлением ОС Windows 3.11 и Solaris 2.4;

8) единичные образцы программного обеспечения МЭ AltaVista Firewall 97 фирмы AltaVista Internet Software;

9) партия из 20 экземпляров МЭ "Cyber Guard" версия 4.0, по-зволяющего создавать защищенные корпоративные сети на базе протокола Х.25 и Frame Relay;

10) Firewall/Plus фирмы Network-1 Software and Technologies.

Список МЭ, сертифицированных Международной ассоциацией компьютерной безопасности, можно найти по адресу http://www.icsa.net. Ниже более подробно описаны функции одного из них.

Межсетевой экран защиты интрасети ПАНДОРА на базе Gauntlet 3.1.1i фирмы Trusted Information Systems и компьютера 02 фирмы Silicon Graphics под управлением IRIX 6.3 надежно ре-шает проблему безопасности сети и позволяет:

* скрыть от пользователей глобальной сети структуру интра-сети (IP-адреса, доменные имена и т.д.);

* определить, каким пользователям, с каких хостов, в на-правлении каких хостов, в какое время, какими сервисами можно пользоваться;

* описать для каждого пользователя, каким образом он дол-жен аутентифицироваться при доступе к сервису;

* получить полную статистику по использованию сервисов, попыткам НСД, графику через ПАНДОРУ и т.д.

ПАНДОРА устанавливается на компьютер с двумя Ethernet-интерфейсами на выходе между интраеетью и сетью общего поль-зования.

ПАНДОРА построена на серверах протоколов прикладного уровня (proxy) и поддерживает следующие сервисы: TELNET, Riogin (терминалы); FTP (передача данных); SMTP, POP3 (почта);

HTTP (WWW); Gopher; XI 1 (X Window System); LP (сетевая пе-чать); Rsh (удаленное выполнение задач); Finger; NNTP (новости Usenet); Whois; RealAudio. Кроме того, в состав ПАНДОРЫ входит сервер общего назначения TCP-уровня, который позволяет безо-пасно транслировать через ПАНДОРУ запросы от базирующихся на TCP протоколов, для которых нет proxy-серверов, а также сер-вер сетевого доступа, который позволяет запускать различные программы в зависимости от того, откуда пришел запрос.

Для аутентификации пользователей ПАНДОРА позволяет при-менять следующие схемы аутентификации:

· обычный Unix-пароль;

· S/Key, MDauth (одноразовые пароли).

· РОРЗ-ргоху дает возможность использовать АРОР-авторизацию и тем самым избежать передачи по сети открытого пароля.

· FTP-proxy позволяет ограничить применение пользователями отдельных команд (например RETR, STOR и т.д.)

· HTTP-proxy позволяет контролировать передачу через ПАНДОРУ фреймов; описаний на языке Java; описаний на языке JavaScript; html-конструкций, не попадающих под стандарт HTML версии 2 и т.д.

Система сбора статистики и генерации отчетов позволяет со-брать и обработать информацию обо всех соединениях, включая время, количество байт, адрес источника, адрес назначения, ID пользователя (если есть), а также аномалии в самой системе.

ПАНДОРА не требует ни внесения изменений в клиентское ПО, ни использования специального ПО.

Прозрачный режим работы proxy-серверов позволяет внутрен-ним пользователям соединяться с нужным хостом за один шаг (т.е. без промежуточного соединения с ПАНДОРОЙ).

Система контроля целостности позволяет контролировать безопасность модулей самой системы.

Графический интерфейс управления служит для настройки, администрирования и просмотра статистики ПАНДОРЫ.

ПАНДОРА поставляется вместе с исходными текстами основ-ных программ, для того чтобы можно было убедиться в отсутствии закладок и разобраться, как он работает.

ПАНДОРА сертифицирована Государственной Технической Комиссией при Президенте России. Сертификат N 73 выдан 16 ян-варя 1997 г. и действителен до 16 января 2000 г: " ...система защи-ты информации от НСД в сетях передачи данных по протоколу TCP/IP - межсетевой экран "ПАНДОРА" (ТУ N 1-97) на базе меж-сетевого экрана "Gauntlet" версии 3.1.Н..., функционирующая на платформе операционной системы IRIX v.6.3 фирмы Silicon Graphics, является средством зашиты информации и обеспечивает защиту участка интрасети от доступа извне, не снижая уровня за-щищенности участка интрасети, соответствует техническим усло-виям № 1-97 и требованиям Руководящего документа Гостехко-миссии России "Автоматизированные системы. Защита от несанк-ционированного доступа к информации. Классификация автомати-зированных систем и требования по защите информации" в части администрирования для класса ЗБ".

Задача выбора МЭ для каждого конкретного применения - это, главным образом, вопрос верного соотношения требований пользователей к доступу и вероятности несанкционированного доступа. В идеале система должна предотвращать всякое несанк-ционированное вторжение. Однако, учитывая широкий спектр не-обходимых пользователям сервисов (Web, ftp, telnet, SNMP, NFS, телефония и видео в Internet, электронная почта и др.), наряду с изначальной открытостью комплекта протоколов TCP/IP, - этого идеала достигнуть очень тяжело. В действительности, мерой эф-фективности МЭ служит вовсе не его способность к отказу в пре-доставлении сервисов, но его способность предоставлять сервисы пользователям в эффективной, структурированной и надежной среде. МЭ должны уметь анализировать приходящий и исходящий сетевой трафик и правильно определять, какие действия санкцио-нированы без ненужного замедления работы системы.

И в заключение данного раздела приведем некоторые рекомен-дации по выбору МЭ, которые выработала Ассоциация "Конфидент".

1). Цена. Она колеблется существенно -- от 1000 до 15000 долл. при покупке непосредственно у фирм-производителей, большинство которых находится в США; у российских дилеров эти цифры значительно выше из-за таможенных и налоговых сборов. Интересна и такая цифра - цена МЭ для Windows NT в сред-нем составляет 6000 долл. К этой цене надо добавить расходы на аппаратную платформу и ОС, которые могут быть весьма значи-тельными и соизмеримыми со стоимостью самого МЭ -- напри-мер, как в случае использования компьютеров Sun под управлени-ем ОС Solaris. Поэтому с точки зрения экономии разумно приме-нять МЭ, ориентированные на Intel-платформу и ОС DOS, Windows NT, Novel 1 NetWare.

2). Фильтрация. Большинство МЭ работает только с семейст-вом протоколов TCP/IP, что связано с ориентацией разработчиков на потребности западного рынка. Этого достаточно, если МЭ при-меняется в классическом варианте -- для контроля графика между интрасетью и Internet. Но в России, согласно имеющейся статисти-ке, 90 % рынка сетевых ОС составляет Novell Netware и поэтому важна фильтрация IPX-трафика. Кроме того, совершенно необхо-димой для внутреннего МЭ является способность фильтрации на уровне соединения -- например, фильтрации Ethernet-фреймов. К сожалению, эта возможность реализована в очень немногих про-дуктах (например. Firewall Plus и Eiron Firewall).

3). Построение интрасети -- при объединении сети организа-ции с Internet в качестве транспортной магистрали нужно исходить из имеющейся инфраструктуры. С этой точки зрения много воз-можностей, имеется в Netware: службы каталогов, управления, пе-чати, защиты и работы с файлами; GroupWise и ManageWise управляют электронным документооборотом и сетью; входящий в состав IntranetWare шлюз IPX/IP организует прозрачный доступ с IPX-станций к сервисам TCP/IP с помощью Winsock-совместимого клиентского ПО. Тогда IPX-сервер и IPX-станция не имеют IP-адресов и из Internet в принципе не видны. Поэтому организация атаки на их информационные ресурсы практически невозможна и защита IP-хостов гетерогенной сети IP-IPX решается проще, так как шлюз выполняет по отношению к ним функции МЭ. Примеры таких МЭ: BorderManager фирмы Novell и NetRoad FireWALL фирмы UkiahSoft.

4). Простота эксплуатации. Чтобы снизить текущие эксплуа-тационные расходы, лучше отдать предпочтение простым в экс-плуатации продуктам с интуитивно понятным графическим ин-терфейсом, иначе богатые возможности по настройке МЭ могут оказаться невостребованными. Этому критерию хорошо соответ-ствуют два продукта -- Firewall Plus фирмы Network-1 и NetRoad FireWALL фирмы UkiahSoft.

Отечественные защищенные системы

Российский стандарт шифрования данных ГОСТ 28147-89

Единственный в настоящее время коммерческий российский алгоритм ГОСТ 28147-89 является универсальным алгоритмом криптографической защиты данных как для крупных информационных систем, так и для локаль-ных вычислительных сетей и автономных компьютеров.

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

В алгоритме ГОСТ 28147-89 используется 256-разрядный ключ, представляемый в виде восьми 32-разрядных чисел, причем, расшифровываются данные с помощью того же ключа, посредством которого они были зашифрованы.

Необходимо отметить, что алгоритм ГОСТ 28147-89 полностью удовле-творяет всем требованиям криптографии и обладает всеми достоинствами алгоритма DES, но лишен его недостатков. В частности, за счет использова-ния специально разработанных имитовставок он позволяет обнаруживать как случайные, так и умышленные модификации зашифрованной информации. В качестве недостатка российского алгоритма надо отметить большую слож-ность его программной реализации и недостаточно высокую скорость работы.

СУБД “Линтер-ВТ” , разработанной ВНИИ автоматизации управления в непромышленной сфере воронежской фирмой “Рэлекс”, производство которых сертифицировано. Специалисты Лос-Аламосской лаборатории в США считают, что СУБД “Линтер-ВТ” не уступает СУБД фирмы Oracle (“родная” Oracle, чтобы быть сертифицированной, требует доработки, а, кроме того, любой западный продукт может получить сертификат только на определенные партии продуктов, поскольку их производство находится за рубежом).

Криптографические средства семейства “Верба-О” производства МОПНИЭИ(сертифицированы ФАПСИ) . Универсальность установок по умолчанию. Внутренние изменения интерфейса при смене средств незначительны. Спектр применения интерфейса системы защиты информации, приведенного в качестве примера,продукта, приведённого в качестве примера, в весьма широк. Это системы контроля доступа к ресурсам банковской системы (как локальное использование в офисе банка для операторов и клиентов, так и контроль удаленного доступа), системы “банк-клиент”, платежи через Интернет, защищенная почта и многие другие.

Данная настройка Iptables рассчитана на схему с использованием 2 сетевых интерфейсов.

Рис 5

Программа позволяет задать правила, которым должны соответствовать проходящие через брандмауэр IP-пакеты. Эти правила, как и все настройки Linux, записываются в текстовый файл, находящийся в папке /etc. Последовательность правил называется цепочкой (CHAIN). Для одного и того же сетевого интерфейса используются несколько цепочек. Если проходящий пакет не соответствует ни одному из правил, то выполняется действие по умолчанию.

Для определений правил используются несколько таблиц:

Используется для изменения заголовка пакета. Допускается выполнять только нижеперечисленные действия:

• · TOS
• · TTL
• · MARK

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

Действие TTL используется для установки значения поля TTL (Time To Live) пакета. Есть одно неплохое применение этому действию. Мы можем присваивать определенное значение этому полю, чтобы скрыть наш брандмауэр от чересчур любопытных провайдеров (Internet Service Providers). Дело в том, что отдельные провайдеры очень не любят когда одно подключение разделяется несколькими компьютерами. и тогда они начинают проверять значение TTL приходящих пакетов и используют его как один из критериев определения того, один компьютер "сидит" на подключении или несколько.

Действие MARK устанавливает специальную метку на пакет, которая затем может быть проверена другими правилами в iptables или другими программами, например iproute2 . С помощью "меток" можно управлять маршрутизацией пакетов, ограничивать траффик и т.п.

Используется для выполнения преобразований сетевых адресов NAT (Network Address Translation). Только первый пакет из потока проходит через цепочки этой таблицы, трансляция адресов или маскировка применяются ко всем последующим пакетам в потоке автоматически. Для этой таблицы характерны действия:

• · DNAT
• · SNAT
• · MASQUERADE

Действие DNAT (Destination Network Address Translation) производит преобразование адресов назначения в заголовках пакетов. Другими словами, этим действием производится перенаправление пакетов на другие адреса, отличные от указанных в заголовках пакетов.

SNAT (Source Network Address Translation) используется для изменения исходных адресов пакетов. С помощью этого действия можно скрыть структуру локальной сети, а заодно и разделить единственный внешний IP адрес между компьютерами локальной сети для выхода в Интернет. В этом случае брандмауэр, с помощью SNAT , автоматически производит прямое и обратное преобразование адресов, тем самым давая возможность выполнять подключение к серверам в Интернете с компьютеров в локальной сети.

Маскировка (MASQUERADE ) применяется в тех же целях, что и SNAT , но в отличие от последней, MASQUERADE дает более сильную нагрузку на систему. Происходит это потому, что каждый раз, когда требуется выполнение этого действия - производится запрос IP адреса для указанного в действии сетевого интерфейса, в то время как для SNAT IP адрес указывается непосредственно. Однако, благодаря такому отличию, MASQUERADE может работать в случаях с динамическим IP адресом, т.е. когда вы подключаетесь к Интернет, скажем через PPP, SLIP или DHCP.

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

Так же можно осуществлять фильтрацию по состоянию соединения. Допустимыми являются состояния NEW, ESTABLISHED, RELATED и INVALID. В таблице, приводимой ниже, рассматриваются каждое из возможных состояний.

Состояние	Описание
	Признак NEW сообщает о том, что пакет является первым для данного соединения. Это означает, что это первый пакет в данном соединении, который увидел модуль трассировщика. Например если получен SYN пакет являющийся первым пакетом для данного соединения, то он получит статус NEW. Однако, пакет может и не быть SYN пакетом и тем не менее получить статус NEW. Это может породить определенные проблемы в отдельных случаях, но может оказаться и весьма полезным, например когда желательно "подхватить" соединения, "потерянные" другими брандмауэрами или в случаях, когда таймаут соединения уже истек, но само соединение не было закрыто.
	Состояние RELATED одно из самых "хитрых". Соединение получает статус RELATED если оно связано с другим соединением, имеющим признак ESTABLISHED. Это означает, что соединение получает признак RELATED тогда, когда оно инициировано из уже установленного соединения, имеющего признак ESTABLISHED. Хорошим примером соединения, которое может рассматриваться как RELATED, является соединение FTP-data, которое является связанным с портом FTP control, а так же DCC соединение, запущенное из IRC. Обратите внимание на то, что большинство протоколов TCP и некоторые из протоколов UDP весьма сложны и передают информацию о соединении через область данных TCP или UDP пакетов и поэтому требуют наличия специальных вспомогательных модулей для корректной работы.
	Состояние ESTABLISHED говорит о том, что это не первый пакет в соединении. Схема установки состояния ESTABLISHED достаточна проста для понимания. Единственное требование, предъявляемое к соединению, заключается в том, что для перехода в состояние ESTABLISHED необходимо чтобы узел сети передал пакет и получил на него ответ от другого узла (хоста). После получения ответа состояние соединения NEW или RELATED будет заменено на ESTABLISHED.
	Признак INVALID говорит о том, что пакет не может быть идентифицирован и поэтому не может иметь определенного статуса. Это может происходить по разным причинам, например при нехватке памяти или при получении ICMP-сообщения об ошибке, которое не соответствует какому либо известному соединению. Наверное наилучшим вариантом было бы применение действия DROP к таким пакетам.

Протокол Kerberos

Протоколы аутентификации:

3. Аутентификация с помощью открытого ключа

Описание DSA

p = простое число длинной L битов, где L принимает значение, кратное 64, в диапазоне от 512 до 1024.

q= 160-битовой простое число - множитель p-1

g = , где h - любое число, меньшее p-1, для которого больше 1

x = число, меньшее q

Используется однонаправленная хэш-функция: Н(m).

Первые три параметра, p, q, g, открыты и могут быть общими для пользователей сети. Закрытым ключом является х, а открытым - у. Чтобы подписать сообщение, m:

1. А генерирует случайное число k, меньше q

2. А генерирует

Его подписью служат параметры r и s, он посылает их В

3. В проверяет подпись, вычисляя

Если v=r, то подпись правильна.

Резюме

Система стандартов IPSec вобрала в себя прогрессивные методики и достижения в области сетевой безопасности. Система IPSec прочно занимает лидирующие позиции в наборе стандартов для создания VPN. Этому способствует ее открытое построение, способное включать все новые достижения в области криптографии. IPsec позволяет защитить сеть от большинства сетевых атак, «сбрасывая» чужие пакеты еще до того, как они достигнут уровня IP на принимающем компьютере. В защищаемый компьютер или сеть могут войти только пакеты от зарегистрированных партнеров по взаимодействию.

IPsec обеспечивает:

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

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

Защита на прикладном уровне

Протокол SSL

Протокол SSL (Secure Socket Layer - уровень защищенных сокетов), разработанный Netscape Communications при участии RSA Data Security, предназначен для реализации защищенного обмена информацией в клиент/серверных приложениях. На практике SSL широко реализуется только совместно с протоколом прикладного уровня HHTP.

Функции безопасности, предоставляемые протоколом SSL:

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

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

Рисунок 9 Криптозащищенные туннели, сформированные на основе протокола SSL

Согласно протоколу SSL криптозащищенные туннели создаются между конечными точками виртуальной сети. Клиент и сервер функционируют на компьютерах в конечных точках туннеля (рис. 9)

Протокол диалога SSL имеет два основных этапа формирования и поддержки защищаемого соединения:

• установление SSL-сессии;
• защищенное взаимодействие.

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

В процессе установления SSL - сессии решаются следующие задачи:

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

Рисунок 10 Процесс аутентификации клиента сервером

В протоколе SSL предусмотрено два типа аутентификации:

• аутентификация сервера клиентом;
• аутентификация клиента сервером.

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

Схема применения протокола

До передачи сообщение по линии передачи данных, сообщение проходит следующие этапы обработки:

1.Сообщение фрагментируется на блоки, пригодные для обработки;

2.Данные сжимаются (опционально);

3.Генерируется MAC ключ ;

4.Данные зашифровываются с помощью ключа ;

1.Используя ключ , данные расшифровываются;

2.Проверяется MAC ключ ;

3.Происходит декомпрессия данных (если использовалось сжатие);

4.Сообщение собирается из блоков и получатель читает сообщение.

Аутентичное распределение ключей

A , Клиент	CA Удостоверяющий центр	B , Сервер
Генерация пары ключей цифровой подписи: . Передача в УЦ	- симметричная схема шифрования; - схема открытого шифрования; - схема ЦП; - любые функции (лучше ОНФ)	Генерация пары ключей схемы открытого шифрования: . Передача в УЦ
K - случайный сеансовый ключ.
		Если , то K принимается как аутентичный общий секретный ключ

Рабочий этап

A		B
	Симметричная схема шифрования
. . .	и т.д.	. . .

Атаки на протокол SSL

Как и другие протоколы, SSL подвержен атакам, связанным с не доверенной программной средой, внедрение программ-закладок и др.:

• Атака отклика. Заключается в записи злоумышленником успешной коммуникационной сессии между клиентом и сервером. Позднее, он устанавливает соединение с сервером, используя записанные сообщения клиента. Но при помощи уникального идентификатора соединения "nonce" SSL отбивает эту атаку. Коды этих идентификаторов имеют длину 128 бит, в связи с чем злоумышленнику необходимо записать 2^64 идентификаторов, чтобы вероятность угадывания была 50%. Количество необходимых записей и низкую вероятность угадывания делают эту атаку бессмысленной.
• Атака протокола рукопожатия. Злоумышленник может попытаться повлиять на процесс обмена рукопожатиями для того, чтобы стороны выбрали разные алгоритмы шифрования. Из-за того, что многие реализации поддерживают экспортированное шифрование, а некоторые даже 0-шифрование или MAC-алгоритм, эти атаки представляют большой интерес. Для реализации такой атаки злоумышленнику необходимо подменить одно или более сообщений рукопожатия. Если это происходит, то клиент и сервер вычислят различные значения хэшей сообщения рукопожатия. В результате чего стороны не примут друг от друга сообщения "finished". Без знания секрета злоумышленник не сможет исправить сообщение "finished", поэтому атака может быть обнаружена.
• Раскрытие шифров. SSL зависит от нескольких криптографических технологий. Шифрование с общедоступным ключом RSA используется для пересылки ключей сессии и аутентификации клиента/сервера. В качестве шифра сессии применяются различные криптографические алгоритмы. Если осуществлена успешная атака на эти алгоритмы, SSL не может уже считаться безопасным. Атаки против определенных коммуникационных сессий могут производиться путем записи сессии, и затем предпринимается попытка подобрать ключ сессии или ключ RSA. В случае успеха открывается возможность прочесть переданную информацию.
• Злоумышленник посередине. Man-in-the-Middle атака предполагает наличие трех сторон: клиента, сервера и злоумышленника. Злоумышленник, находясь между ними, может перехватывать обмен сообщениями между клиентом и сервером. Атака является эффективной только если для обмена ключами применяется алгоритм Диффи-Хэлмана, так как целостность принимаемой информации и ее источник проверить невозможно. В случае SSL такая атака невозможна из-за использования сервером сертификатов, заверенных центром сертификации.

Протокол TLS

Цель создания и преимущества

Цель создания TLS - повышение защиты SSL и более точное и полное определение протокола:

• Более надежный алгоритм MAC
• Более детальные предупреждения
• Более четкие определения спецификаций "серой области"

TLS предоставляет следующие усовершенствованные способы защиты:

• Хэширование ключей для идентификации с помощью сообщений - TLS применяет в коде идентификации сообщения (HMAC) хэширование, предотвращающее от изменения записи при передаче по незащищенной сети, например в Internet. SSL версии 3.0 также поддерживает идентификацию сообщений с помощью ключей, но HMAC считается более надежным, чем функция MAC, применяемая в SSL версии 3.0.
• Улучшенная псевдослучайная функция (PRF) С помощью PRF создаются данные ключа. В TLS функция PRF определена с помощью HMAC. PRF применяет два алгоритма хэширования, обеспечивающих ее защиту. Если один из алгоритмов будет взломан, данные будут защищены вторым алгоритмом.
• Улучшенная проверка сообщения "Готово" - Протоколы TLS версии 1.0 и SSL версии 3.0 отправляют обеим конечным системам сообщение "Готово", означающее, что доставленное сообщение не было изменено. Однако в TLS эта проверка основана на значениях PRF и HMAC, что обеспечивает более высокий уровень защиты по сравнению с SSL версии 3.0.
• Согласованная обработка сертификатов - В отличие от SSL версии 3.0, TLS пытается указать тип сертификата, который может применяться различными реализациями TLS.
• Особые предупреждающие сообщения - TLS предоставляет более точные и полные предупреждения о неполадках, обнаруженных одной из конечных систем. TLS также содержит информацию о том, когда какие сообщения с предупреждениями следует отправлять.

Протокол SSH

Протокол SSH (Secure Shell-оболочка безопасности) - это набор протоколов аутентификации с открытым ключом, позволяющий пользователю на стороне клиента безопасно регистрироваться на удалённом сервере.

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

Все сообщения шифруются с помощью IDEA .

Архитектура протокола SSH

SSH выполняется между двумя ненадёжными компьютерами, работающими в незащищенной сети(клиент - сервер).

Набор протоколов SSH состоит из трех компонентов:

• Протокол транспортного уровня SSH (SSH Transport Layer Protocol), обеспечивает аутентификацию сервера. Для этого используется открытый ключ. Исходной информацией для этого протокола как со стороны сервера, так и со стороны клиента, является пара открытых ключей - "ключи головного компьютера". Итогом протоколом является взаимно аутентифицированный защищённый канал, который гарантирует секретность и целостность данных.

• Протокол аутентификации пользователя SSH (SSH User Authentication Protocol). Выполняется по каналу односторонней аутентификации, установленному протоколом транспортного уровня SSH. Для выполнения аутентификации от клиента к серверу, поддерживаются различные протоколы односторонней аутентификации. Эти протоколы могут применять либо открытый ключ, либо пароль. Например, они могут быть созданы на основе протокола аутентификации с помощью простого пароля. Результатом протокола является взаимно аутентифицированный защищённый канал между сервером и пользователем. Применяются следующие методы:

publickey - клиент высылается ЭЦП , сервер проверяет доверие открытому ключу клиента по имеющейся на сервере копии ключа, затем проверяет аутентичность клиента по Sc.

password - клиент подтверждает свою аутентичность паролем.

hostbased - аналогично publickey, только используется пара ключей для клиентского хоста; подтвердив аутентичность хоста, сервер доверяет имени пользователя.

• Протокол связи SSH (SSH Connection Protocol) выполняется по взаимно аутентифицированному защищённому каналу, установленному предыдущими протоколами. Протокол обеспечивает работу защищённого канала при этом разделяя его на несколько защищённых логических каналов.

Протокол распределения ключами

Протокол включает в себя 3 этапа. Первый этап - "Hello" phase, где первый идентификатор это строка, I, отправляется, чтобы начать протокол, за которым следует список поддерживаемых алгоритмов - X.

На 2-й стадии стороны согласуют секретный ключ, s. Для этого применяется алгоритм Диффи-Хеллмана . Сервер подтверждает свою идентичность, отправляя клиенты свой открытый ключ, , верифицированный цифровой подписью, , и подпись дайджеста, h. В качестве идентификатора sid устанавливается значение h.

На стадии 3 секретный ключ, идентификатор сессии и дайджест используются для создании 6 "apllication keys", вычисленных с помощью .

Резюме

К преимуществам протокола относится:

• возможность действий на сквозной основе (end - to - end) с осуществляющими стеками TCP/IP, существующими интерфейсами прикладного программирования;
• повышенная эффективность по сравнению с медленными каналами;
• отсутствие каких-либо проблем с фрагментацией, определением максимального объёма блоков, передаваемых по данному маршруту;
• сочетание компрессии с шифрованием.

Организация защищенного канала связи

Максим Илюхин,
к.т.н., ОАО "ИнфоТеКС"

КОНЕЦ XX века был отмечен лавинообразным распространением Интернета: в геометрической прогрессии росли скорости доступа, охватывались все новые и новые территории, практически между любыми двумя точками в мире можно было установить быструю связь через сеть. Но передача информации не была безопасной, злоумышленники могли перехватить, украсть, изменить ее. В это время стала набирать популярность идея организации надежного канала, который для связи будет использовать общедоступные коммуникации, но защитит передаваемые данные за счет применения криптографических методов. Стоимость организации такого канала была во много раз меньше стоимости прокладки и поддержания выделенного физического канала. Таким образом, организация защищенного канала связи становилась доступной средним и малым предприятиям и даже частным лицам.

Система ViPNet

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

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

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

Программное обеспечение системы ViPNet функционирует в операционных средах Windows, Linux.

ViPNet CUSTOM

ViPNet CUSTOM - многофункциональная технология создания защищенных VPN-сетей с возможностью развертывания полноценной PKI-структуры, ориентированная на организацию защищенного взаимодействия "клиент - клиент", в то время как большинство VPN-решений других производителей обеспечивают только соединения уровня "сервер - сервер" или "сервер -клиент". Это дает возможность реализовать любую необходимую политику разграничения доступа в рамках всей защищенной сети, а также снизить нагрузку на VPN-серверы, так как в общем случае при взаимодействии "клиент - клиент" VPN-сервер не задействован в операциях шифрования трафика между этими клиентами. Большое внимание в ViPNet CUSTOM уделено решению проблемы функционирования в условиях наличия разнообразного сетевого оборудования и программного обеспечения, реализующего динамическую или статическую трансляцию адресов/портов (NAT/PAT), что существенно облегчает процесс интеграции системы защиты в существующую инфраструктуру сети. В большинстве случаев ручной настройки клиентского ПО ViPNet Client вообще не требуется.

Каждый компонент ViPNet CUSTOM содержит встроенный сетевой экран и систему контроля сетевой активности приложений, что позволяет получить надежную распределенную систему межсетевых и персональных сетевых экранов.

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