Мельников Д. А. - Организация и обеспечение безопасности информационно-технологических сетей и систем - 2012

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

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

Когда это приемлемо, НМАС-система должна использоваться как более предпочтительная по сравнению с более старыми спосо­ бами безопасности, особенно это касается вычисления хэшфункций с использованием ключей. Простые хэш-функции с ис­ пользованием ключей на основе алгоритма MD51 (RFC-1321), на­ пример, BGP-протокол (RFC-2385), исключаются из новых протоко­ лов безопасности, что позволяет сделать вывод о низкой надежности таких хэш-функций.

НМАС-система может использоваться совместно с любой хэшфункцией, включая МЭБ-алгоритм и SHA-1-алгоритм (RFC-3174). SHA-1-алгоритм более предпочтителен для новых протоколов безо­ пасности, так как он используется намного чаще в этих целях и мо­ жет быть более надежен.

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

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

IPsec-архитектура. Протоколы аутентификации и шифрования на IP-уровне (сетевом уровне), составляющие основу IPsec-архитек- туры, представлены в стандартах RFC-4301, RFC-4302, RFC-4303, RFC4306 и RFC-4307. По сути, данная архитектура безопасности защищает протоколы верхних уровней, включая TCP- и UDP-протоколы. Она обеспечивает нормальное (однородное) распределение защиты, т.е.

1 В 2 0 0 6 г. чешский исследователь Властимил Клима на основе анализа МЭ5-стандарта синтезировал алгоритм, позволяющий находить уязвимо­ сти MD5 на обычном компьютере с любым начальным вектором (А, В, С, D) при помощи метода, названного им «туннелирование».

«IP-узел*»IP-узел», «IP-узел*»шлюз безопасности» и «шлюз безопас­ ности*»шлюз безопасности». Функциональные свойства IPsecархитектуры позволяет пользователю самому распределять защиту, но это бывает сравнительно редко. По существу, применение IPsecархитектуры теряет всякий смысл, если распределение защиты на самом IP-узле слишком неоднородно.

Так как программный IPsec-модуль встраивается в программ­ ное обеспечение сетевого уровня (IP-уровня), то тогда, скорее всего, оно будет внедряться непосредственно в листинг программы (код программы). Такое встраивание, как правило, требует, либо замены программно-аппаратной части, либо обновления архитектуры, свя­ занной с заменой отдельных протоколов. С другой стороны, IPsecархитектура совершенно прозрачна для прикладных служб. При­ кладные службы, функционирующие над IPsec-протоколами, могут значительно повысить свою защищенность вообще без каких-либо изменений в собственных протоколах. Но сейчас, по крайней мере, пока IPsec-архитектура не нашла своего повсеместного применения в Internet-сети, большинство прикладных служб не должны «га­ дать», что они функционируют над IPsec-протоколами, которые вы­ ступают как альтернатива их собственным способам обеспечения ИБ. Большинство современных операционных систем способны функционировать совместно с программным IPsec-модулем, однако, большинство маршрутизаторов - нет, по крайней мере, с точки зре­ ния управления. Прикладная служба, использующая TLS-протокол (Transport Level Security - TLS, RFC-2246), вероятнее всего имеет больше возможностей для учета собственных особенностей при про­ ведении надежной процедуры аутентификации. Управление ключе­ вой информацией в интересах IPsec-архитектуры может основывать­ ся на использовании электронных сертификатов или распределен­ ных секретных ключей. Очевидно, что по многим причинам серти­ фикаты более предпочтительнее, однако, они могут представлять большую «головную боль» для системного администратора.

В настоящее время существует серьезный конфликт между функционированием IPsec-протоколов и NAT-модулями (RFC-2993). Просто NAT-модуль не может сосуществовать с любым протоколом, сообщения которого содержат дополнительно размещаемые в них IP-адреса. Это касается IPsec-протоколов, каждого IP-пакета с сооб­ щением любого протокола верхнего уровня, содержащего IP-адреса, если только они в заголовках. Этот конфликт иногда может быть преодолен за счет применения режима туннелирования (РТУ), но это не всегда приемлемо по различным причинам. В настоящее время идет работа по созданию стандарта, обеспечивающего более легкое преодоление NAT-модулей IPsec-пакетами.

Наиболее широко IPsec-протоколы используются в виртуальных корпоративных сетях (Virtual Private Network - VPN). Исходя из того, что встречаются и другие ограничения, IPsec-протоколы наиболее применимы в VPN-подобных ситуациях, включая вариант удаленного доступа, когда удаленный компьютер формирует обратный туннель (защищенное виртуальное соединение) в свою корпоративную сеть через Internet, используя для этого IPsec-протоколы.

TLS-протокол. Протокол безопасности транспортного уровня (Transport Level Security - TLS, RFC2246) обеспечивает шифрование и аутентификацию канала, который сформирован прикладным протоколом с использованием ТСР-протокола. Несмотря на то, что TLS-протокол был специально разработан для использование в W3серверах, это не означает ограничение сферы его применения. Тем не менее, каждый прикладной протокол, который желает использо­ вать TLS-протокол, должен быть адаптирован к логической и про­ цедурной характеристикам последнего.

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

Несмотря на необходимость внесения изменений в прикладную службу (протокол), требуется использовать TLS-протокол, и особенно там, где имеются в наличии необходимые средства (и бесплатные, и коммерческие), обеспечивающие такую услугу. Такие средства раз­ работаны для встраивания в листинг программы прикладного про­ токола. Прикладная служба, использующая TLS-протокол, вероятнее всего будет способна устанавливать наиболее приемлемые страте­ гии обеспечения безопасности, исходя из собственной функции нальной специфики, по сравнению с прикладной службой, исполь­ зующей только IPsec-протоколы.

SASL-интерфейс. По существу, это параметры уровня защи­ щенности, которые определяются согласованным способом обеспе­ чения ИБ. В частности, если согласованный способ обеспечения ИБ не будет аутентифицировать все последующие сообщения или не будет использовать, лежащий в его основе, протокол безопасности, такой как TLS-протокол, все TCP-сеансы связи будут уязвимы к ата­ кам типа «вторжение в сеанс связи».

Если возникает необходимость использования TLS-протокола (или IPsec-протоколов) совместно с SASL-интерфейсом (Simple Au­ thentication and Security Layer - уровень простой аутентификации и обеспечения безопасности), то тогда возникают вопросы: «Почему надо в первую очередь беспокоиться о SASL-интерфейсе?» и «По­ чему просто не попытаться использовать функциональные возмож­ ности TLS-протокола по осуществлению процедуры аутентифика­ ции и применить их на практике?».

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

SASL-интерфейс позволяет пользователю применять более тра­ диционные способы аутентификации, например, парольные систе­ мы (одноразовые или другие). В таких случаях, было бы полезнее рассматривать комбинацию способов, которая весьма эффективна, т.е. TLS-протокол обеспечивает основную защиту и аутентификацию сервера, а система аутентификации на основе SASL-интерфейса обеспечивает проверку пользователей. Самое серьезное внимание должно быть уделено снижению уязвимости к атакам типа «человек в середине соединения» (Man in the Middle), особенно в тех случаях, когда в разных направлениях дуплексного соединения используют­ ся различные способы аутентификации.

GSS-API-интерфейс. Прикладной программный интерфейс единой службы безопасности (Generic Security Service Application Pro­ gram Interface - GSS-API, RFC-2744) представляет собой программное средство в интересах прикладных служб, когда им понадобится ис­ пользовать процедуры аутентификации, обеспечения целостности и/или конфиденциальности. В отличие от SASL-интерфейса, GSS-API-интерфейс может также легко использоваться прикладными службами, базирующимися на UDP-протоколе. GSS-API-интерфейс позволяет генерировать кодовые метки в интересах процедуры ау­ тентификации, которые могут размещаться в протокольных сооб­ щениях. (Примечание. Уровень защищенности, обеспечиваемый

протоколами безопасности, которые предоставляет GSS-API-интер- фейс, зависит от базового способа обеспечения ИБ, причем последний должен оцениваться независимо. С таких же позиций должна рассмат­ риваться и функциональная совместимость этих протоколов.)

DNSsec-протокол. Основное предназначение DNSsecпротокола (RFC-2535) - защита DNS-записей с помощью ЭЦП. ЭЦП защищает DNS-записи, хранящиеся в кэш-памяти DNS-сервера, от атак типа «загрязнение кэш-памяти». Эти записи, в свою очередь, могут использоваться для нарушения процедуры аутентификации на основе DNS-имени, а также для перенаправления трафика на на­ рушителя или минуя последнего. Последнее делает DNS-систему очень критичным компонентом некоторых других способов обеспе­ чения ИБ, особенно это касается IPsec-архитектуры.

DNSsec-протокол, в принципе, позволяет обеспечить защиту данных при отображении DNS-имен в IP-адреса. Он также может использоваться для защиты и других DNS-данных, связанных с оп­ ределенным DNS-именем.

Такие данные могут быть просто служебными, которые необ­ ходимы для нормального функционирования DNS-сервера, храня­ щего их, или это может быть ключ, используемый протоколами безопасности IPsec-архитектуры при согласовании защищенного виртуального соединения. (.Примечание. Концепция хранения при­ кладных ключей общего назначения в DNS-системе была «опроте­ стована» в стандарте RFC-3445, но, тем не менее, стандартизация процедур хранения ключей в интересах некоторых прикладных служб (и в частности для IPsec-архитектуры) продолжается.)

Безопасность многоблочных сообщений. Стандарт RFC-1847 определяет способ защиты сообщений электронной почты, которые могут иметь многоблочную (многоэлементную) структуру (Securi­ ty/ Multiparts), определяемую MIME-протоколом (RFC-2045). Более точно, Security/ Multiparts-способ дополняет MIME-протокол, так как определяет порядок и правила шифрования MIME-сообщений и/ или размещение ЭЦП в них. Фактически два протокола S/MIME (RFC-3156) и OpenPGP (RFC-4880) используют Security/Multipartsспособ при защите своих сообщений. Зная структуру многоблочного почтового сообщения, получатель может легко определить и рас­ шифровать зашифрованные элементы письма.

Security/ Multiparts-способ представляет собой одну из форм обеспечения «персональной (абонентской) безопасности» («object security»), когда для конечного пользователя защита его персоналы ных сообщений является основным требованием вне зависимости от способа доставки и промежуточного хранения этих сообщений и др. В настоящее время в Internet-сети нет единой формы обеспече­ ния «персональной безопасности».

Хорошим примером использования S /MIME-протокола в со­ вершенно иной области, отличной от электронной почты, является протокол инициирования сеанса связи (Session Initiation Protocol, RFC-3261).

ЭЦП. Применение ЭЦП при аутентификации взаимодейст­ вующих сторон в режиме «запрос/ответ» («challenge/ response») обеспечивает высокую надежность аутентификации. Применение криптографии с открытыми ключами является наиболее предпоч­ тительным в системах, в которых используются секретные ключи, так как сервер не нуждается в хранении копии секретного ключа пользователя. Предпочтительнее, чтобы пользователь имел секрет­ ный ключ, а серверы имели соответствующий ему открытый ключ.

Строго говоря, применение ЭЦП - дело сложное. Пользователь никогда не должен подписывать сообщение/запрос, переданное для него, так как известно несколько «хитрых» атак, которые могут быть предприняты в таких ситуациях.

Стандарт DSS-ЭЦП (Digital Signature Standard - DSS, феде­ ральный стандарт США) и RSA-ЭЦП являются хорошими ЭЦПалгоритмами, каждый из которых имеет свои достоинства. Приме­ нение DSS-ЭЦП требует использования генератора случайных чи­ сел с хорошими вероятностными характеристиками (RFC-4086, Ran­ domness Requirements for Security). Если нарушитель способен реге­ нерировать случайное число для какой-либо ЭЦП, или если пользо­ ватель использует одно и то же случайное число в двух разных до­ кументах, то может быть обнаружен секретный ключ пользователя. DSS-ЭЦП имеет гораздо лучшие параметры по сравнению с RSAЭЦП, с точки зрения генерации новых секретных ключей, и отчасти лучшие параметры, с точки зрения вычисления ЭЦП, в то время как RSA-ЭЦП имеет гораздо лучшие параметры, с точки зрения про­ верки ЭЦП.

OpenPGP-протокол и S/MIME-протокол. ЭЦП могут исполь­ зоваться при построении прикладных служб, обеспечивающих «персональную безопасность», которые можно будет применять для защиты данных в протоколах хранения и доставки сообщений, та­ ких как протокол электронной почты.

Как отмечалось ранее, два различных защищенных протоко­ ла электронной почты, OpenPGP (RFC-3156, RFC-4880) и S/MIME (RFC-2633), предполагались для замены усовершенствованного про­ токола защищенной электронной почты (Privacy Enhanced Mail - РЕМ). И совершенно не ясно, какой из них, если не оба, будет иметь успех. Несмотря на то, что они оба разрабатывались для совместного функционирования с защищенной электронной почтой, они оба адаптированы для защиты данных, которые транспортируются дру­

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

Исторически сложилось так, что главное различие между поч­ товыми службами (протоколами доставки сообщений электронной почты), OpenPGP и S/MIME, заключается в типе связности электрон­ ных сертификатов между собой. В S /MIME-службе пользователи об­ ладают Х.509-сертификатами (Рекомендация ITU-T Х.509), а структу­ ра связности сертификатов (граф сертификации) представляет собой «дерево», содержащее очень небольшое количество «корневых уз­ лов». Совсем противоположная ситуация в PGP-службе, которая ис­ пользует так называемую «сеть доверенных серверов», причем любой пользователь может подписать чей-нибудь ещё сертификат. В такой ситуации граф сертификации представляет собой в действительно­ сти произвольный граф или совокупность графов.

В любой схеме сертификации надежность системы зависит от двух основных составляющих. Во-первых, сертификационная схема должна начинаться в известном достоверном «источнике», либо в корневом Х.509-узле, либо высоко надежном узле, которому доверя­ ет лично проверяющий. Во-вторых, последовательность ЭЦП долж­ на быть достоверной, т.е. каждый узел в графе сертификации явля­ ется определяющим. Если какой-либо узел в графе сертификации «нечестен» или скомпрометирован, то любые сертификаты, заве­ ряемые таким узлом, не могут быть надёжными. Все другие факто­ ры надёжности эквивалентны (или почти эквивалентны), в обеих службах короткие последовательности сертификатов являются наи­ более предпочтительными.

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

В S /MIME-службе основной акцент сделан на «защиту от ду­ раков», т.е. она предусматривает (требует) очень незначительные дополнительные настройки в программном модуле пользователя. В частности, конечным пользователям не нужно знать ничего о на­ дежности соединений и др. Идея состоит в том, что если S /MIMEпользователь говорит, что «... эта ЭЦП приемлема», то тогда поль­ зователь должен «принимать» это состояние «за чистую монету», т.е. доверять ему без каких-либо объяснений относительно щих прикладных процессов.

Для достижения этого S / MIME-служба, как правило, базиру­ ется на ограниченном количестве корневых Удостоверяющих цен-

ТР0В (УЦ). Целью этой службы является создание глобальной ин­ фраструктуры надёжных УЦ.

Слабая сторона S /MIME-службы заключается в том, что она требует развитой инфраструктуры открытых ключей, без которой эта служба не работает. Два оконечных пользователя просто не спо­ собны после загрузки программных S /MIME-модулей сразу начать устанавливать защищенное соединение. Однако это не есть функ­ циональное ограничение самого протокола, просто типовая на­ стройка запрещает применение единого доступного программного обеспечения. Одному или обоим пользователям может понадобить­ ся получение электронного сертификата в предварительно прове­ ренном УЦ. Это означает, что УЦ уже должен быть проверен про­ граммным S/ MIME-модулем в «ручном» режиме сразу после его за­ грузки. Этот процесс может повлечь за собой определенные финан­ совые затраты и принятие юридических обязательств. В конечном счете, последние условия затрудняют широкое внедрение этой поч­ товой системы, особенно в Internet-сети, в которой пользователи не стараются оценить результат, достигнутый без особых трудностей.

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

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

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

Но с другой стороны, S /MIME-служба функционирует нор­ мально в корпоративных сетевых сегментах, в которых может быть развернута внутренняя защищенная система УЦ. И это не требует от пользователей больших и серьезных знаний в области ИБ. S/MIME-служба может использоваться между различными корпора­ тивными сетями, если между ними обеспечивается сквозная защи­

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

СЭ функционируют лучше, если они используются в качестве одного из элементов общей структуры безопасности. Например, точ­ но настроенный СЭ может использоваться для функционального разделения демонстрационного W 3-cepBepa и сервера с базой данных при условии, что между последними существует только открытый (без шифрования трафика) канал связи. То же самое касается и СЭ, который «пропускает через себя» только зашифрованный трафик в режиме туннелирования. Такой СЭ можно использовать для защиты одного сегмента VPN-сети. Но с другой стороны, в таком случае дру­ гой сегмент VPN-сети должен быть защищён таким же образом.

Kerberos-протокол. Этот протокол (RFC-4120) определяет спо­ соб обоюдной аутентификации двух взаимодействующих сторон и обмена ключевой информацией. Пользовательский программный Kerberos-модуль обладает специальными «билетом» и «веритель­ ным документом». Оба этих документа (которые должны храниться в зашифрованном виде) в дальнейшем используются для установ­ ления соединения между пользователем и сервером. Сервер может потом проверить подлинность этих документов. После этого сервер и пользователь могут запросить программный Kerberos-модуль вы­ делить им сеансовый ключ, который будет использоваться для за­ щиты целостности или шифрования данных.

Программный Kerberos-модуль может использоваться в рамках собственного протокола. Однако он также используется как способ обеспечения ИБ с помощью SASL-интерфейса и GSSAPI-интерфейса. В настоящее время известны некоторые уязвимые места этого про­ токола, но, тем не менее, он может использоваться в защищенном варианте.

SSH-протокол. Этот протокол (Secure Shell - SSH), входящий в состав программного обеспечения UNIX-подобных систем, обеспе­ чивает защиту соединения «клиент** сервер». Функционально он напоминает TLS-протокол, однако, он оптимизирован для обслужи­ вания удаленных соединений с терминалами. Одно из наиболее ра­ циональных свойств SSH-протокола заключается в том, что он обес­ печивает туннельный режим доставки сообщений других приклад­ ных протоколов, расположенных над TCP-протоколом, защищен­ ным SSH-протоколом. Это свойство позволило пользователям, хо­ рошо осведомленным в области ИБ, выполнять различные функ­ ции, среди которых чтение и передача почтовых сообщений или