Технологии удаленного доступа к виртуальным частным сетям

Протоколы безопасности

Протоколами безопасности на транспортном уровне являются Secure Socket Layer (SSL) и Secure Shell Protocol (SSH), которые обеспечивают безопасную передачу данных между клиентом и сервером. Оба протокола разработаны рабочей группой IETF по безопасности транспортного уровня (Transport Layer Security — TLS). Безопасный протокол передачи гипертекста (S-HTTP) предоставляет надежный меха­низм web-транзакций. Средст­во SOCKS является рамочной структурой, позволяющей приложениям клиент/сервер в доменах TCP и UDP удобно и безопасно пользоваться услугами межсетевого экрана. Протокол безопасности IP (IPSec) представляет собой набор стандартов поддержки целостности и конфиденциальности данных на сетевом уровне (в сетях IP). X.509 — это стандарт безопасности и аутентификации, который поддерживает структуры безопасности электронного информационного транспорта. Он определяет структуру данных цифрового сертификата и решает вопросы обращения общих ключей. Х.509 является важней­шим компонентом инфраструктуры общих ключей (PKI).

SSL

SSL — это открытый протокол, разработанный компанией Netscape. SSL определяет механизм поддерж­ки безопасности данных на уровне между протоколами приложений (такими как Hypertext Transfer Protocol [HTTP], Telnet, Network News Transfer Protocol [NNTP] или File Transfer Protocol [FTP]) и прото­колом TCP/IP. Он поддерживает шифрование данных, аутентификацию серверов, целостность сообще­ний и (в качестве опции) аутентификацию клиентов в канале TCP/IP. SSL был представлен рабочей груп­пе по безопасности консорциума W3 (W3C) для утверждения в качестве стандартного средства безопас­ности Web-браузеров и серверов в сети Интернет.

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

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

• Участник сеанса связи может быть аутентифицирован средства­ми асимметричной криптографии (например, RSA, DSS).

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

Протокол SSL принят только в рамках HTTP. Другие протоколы доказали свою способность работать с SSL, но используют ее не часто.

SSH

Протокол Secure Shell (SSH) предназначен для защиты удаленного доступа и других сетевых услуг в не­защищенной сети. Он поддерживает безопасный удаленный вход в сеть, безопасную передачу файлов и безопасную эстафетную передачу сообщений по протоколам TCP/IP. SSH может автоматически шифровать, аутентифицировать и сжимать передаваемые данные. В настоящее время SSH достаточно хорошо защищен от криптоанализа и протокольных атак. Он довольно хорошо работает при отсутствии глобальной системы управления ключами и инфраструктуры сертификатов и при необходимости может поддерживать инфраструктуры сертификатов, которые существуют в настоящий момент (например, DNSSEC, простую инфраструктуру общих ключей [SPKI], X.509).

Протокол SSH состоит из трех основных компонентов:

1. Протокол транспортного уровня (SSH-TRANS) обеспечивает аутентификацию сервера, конфиденциальность и целостность соединения. Также может дополнительно обеспечивать сжатие данных. Протокол транспортного уровня обычно выполняется поверх соединения TCP, но может использоваться и поверх любого другого надежного соединения.
2. Протокол аутентификации пользователя (SSH-USERAUTH) аутентифицирует клиента для сервера. Он выполняется поверх протокола транспортного уровня.
3. Протокол соединения (SSH-CONN), мультиплексирует несколько логических каналов в один зашифрованный туннель. Протокол выполняется поверх протокола аутентификации пользователя.

Все сообщения шифруются с помощью IDEA или одного из нескольких других шифровальных средств (тройного DES с тремя ключами, DES, RC4-128, Blowfish). Обмен ключами шифрования происходит с помощью RSA, а данные, использованные при этом обмене, уничтожаются каждый час (ключи нигде не со­храняются). Каждый центральный компьютер имеет ключ RSA, который используется для аутентифика­ции центрального компьютера при использовании специальной технологии аутентификации RSA. Для защиты от подслушивания (спуфинга) сети IP используется шифрование; для защиты от DNS и спуфинга маршрутизации используется аутентификация с помощью общих ключей. Кроме того, ключи RSA ис­пользуются для аутентификации центральных компьютеров.

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

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

Могут использоваться две различные модели:

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

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

S-HTTP

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

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

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

S-HTTP поддерживает высокий уровень гибкости криптографических алгоритмов, режимов и параметров. Для того, чтобы клиенты и серверы смогли выбрать единый режим транзакции (так, например, им нужно решить, будет ли запрос только шифроваться или только подписываться или и шифроваться, и подписываться одновременно; такое же решение нужно принять и для ответов), используется механизм согласования опций, криптографических алгоритмов (RSA или DSS для под­писи, DES для шифрования и т.д.), и выбора сертификатов. S-HTTP поддерживает криптографию общих ключей и функцию цифровой подписи и обеспечивает конфиденциальность данных.

SOCKS

SOCKS разработан для того, чтобы дать возможность приложениям клиент/сервер в доменах TCP и UDP удобно и безопасно пользоваться услугами межсетевого экрана. Он дает пользователям возможность преодолевать межсетевой экран организации и получать доступ к ресурсам, расположенным в сети Ин­тернет. SOCKS является «посредником уровня приложений»: он взаимодействует с общими сетевыми средствами (например, Telnet и браузер Netscape) и с помощью центрального сервера (прокси-сервера) от имени компьютера устанавливает связь с другими центральными компьютерами.

SOCKS версия 4 решает вопрос незащищенного пересечения межсетевых экранов приложениями клиент/сервер, осно­ванными на протоколе TCP, включая Telnet, FTP и популярные информационные протоколы, такие как HTTP, Wide Area Information Server (WAIS) и GOPHER. SOCKS версия 5, RFC 1928, является дальнейшим расширением четвертой версии SOCKS. Он включает в себя UDP, расширяет общую рамочную структу­ру, придавая ей возможность использования мощных обобщенных схем аутентификации, и расширяет систему адресации, включая в нее имя домена и адреса IP v6.

В настоящее время предлагается создать механизм управления входящими и исходящими многоадрес­ными сообщениями IP, которые проходят через межсетевой экран. Это достигается определением рас­ширений для существующего протокола SOCKS V.5, что создает основу для аутентифицированного пе­рехода межсетевого экрана одноадресным пользовательским трафиком TCP и UDP. Однако ввиду того, что поддержка UDP в текущей версии SOCKS V.5 имеет проблемы с масштабируемостью и другие недо­статки (и их обязательно нужно разрешить, прежде чем переходить к многоадресной передаче), расши­рения определяются двояко: как базовые расширения UDP и как многоадресные расширения UDP.

Функционирование SOCKS заключается в замене стандартных сетевых системных вызовов в приложе­нии их специальными версиями. Эти новые системные вызовы устанавливают связь с прокси-сервером SOCKS (который конфигурируется самим пользователем в приложении или системным файлом конфи­гурации), подключаясь к хорошо известному порту (обычно это порт 1080/ТСР). После установления свя­зи с сервером SOCKS приложение отправляет серверу имя машины и номер порта, к которому хочет под­ключиться пользователь. Сервер SOCKS реально устанавливает связь с удаленным центральным компь­ютером, а затем прозрачно передает данные между приложением и удаленной машиной.

Трудность с использованием SOCKS состоит в том, что кто-то должен проводить работу по замене сете­вых системных вызовов версиями SOCKS (этот процесс обычно называется «SOCKS-ификацией» прило­жения). Большинство обычных сетевых приложений (Telnet, FTP, finger, whois) уже SOCKS-ифицированы, и многие производители включают поддержку SOCKS в свои коммерческие приложения.

IPSec

Безопасный протокол IP (IPSec) представляет собой набор стандартов, используемых для защиты данных и для аутентификации на уровне IP. Текущие стандарты IPSec включают независимые от алгоритмов базовые спецификации, которые являются стандартными RFC.

IPsec предназначен для безопасного взаимодействия на основе криптографии для IPv4 и IPv6. Набор сервисов безопасности включает управление доступом, целостность соединения, аутентификацию исходных данных, защиту от replay-атак (целостность последовательности), конфиденциальность (шифрование) и конфиденциальный поток трафика. Эти сервисы предоставляются на уровне IP, обеспечивая защиту для IP и/или протоколов более высокого уровня.

IPsec поддерживает две формы целостности: целостность соединения и частичную целостность последовательности. Целостность соединения является сервисом безопасности, который определяет модификацию конкретной IP датаграммы, безотносительно последовательности датаграмм в потоке трафика. Частичная целостность последовательности является anti-reply сервисом, с помощью которого определяется получение дубликатов IP датаграм.

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

Как работает IPsec

IPsec использует два протокола для обеспечения безопасности трафика – Authentication Header (AH) и Encapsulating Security Payload (ESP).

• Authentication Header (AH) обеспечивает целостность соединения, аутентификацию исходных данных и дополнительно может обеспечивать anti-replay сервис.
• Encapsulating Security Payload (ESP) протокол может обеспечивать конфиденциальность (шифрование) трафика. ESP также может обеспечивать целостность соединения, аутентификацию исходных данных и дополнительно anti-replay сервис. Целостность обеспечивается только для протоколов более высокого уровня. Хотя бы один из этих сервисов должен быть задействован при использовании ESP.

Эти протоколы могут применяться как по отдельности так и в комбинации друг с другом для обеспечения необходимого набора сервисов безопасности в IPv4 и IPv6. Каждый протокол поддерживает два режима использования: режим транспорта и режим туннелирования.

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

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

Протокол IPSec включает криптографические методы, удовлетворяющие потребности управления ключами на сетевом уровне безопасности. Протокол управления ключами Ассоциации безопасности Ин­тернет (Internet Security Association Key Management Protocol — ISAKMP) создает рамочную структуру для управления ключами в сети Интернет и предоставляет конкретную протокольную поддержку для со­гласования атрибутов безопасности. Само по себе это не создает ключей сессии, однако эта процедура может использоваться с разными протоколами, создающими такие ключи.

Протокол определения ключей Oakley Key Determination Protocol пользуется гибридным методом Диффи-Хеллмана, чтобы создать ключи сессии Интернет для центральных компьютеров и маршрутизаторов. Протокол Oakley решает важную задачу обеспечения полной безопасности эстафетной передачи дан­ных. Он основан на криптографических методах. Полная защита эстафетной передачи означает, что если хотя бы один ключ раскрыт, раскрыты будут только те данные, которые зашифрованы этим ключом. Что же касается данных, зашифрованных последующими ключами, они останутся в полной безопасности.

Протоколы ISAKMP и Oakley были совмещены в рамках гибридного протокола IKE — Internet Key Exchange. Протокол IKE, включающий ISAKMP и Oakley, использует рамочную структуру ISAKMP для поддержки подмножества режимов обмена ключами Oakley. Новый протокол обмена ключами обеспечи­вает (в виде опции) полную защиту эстафетной передачи данных, полную защиту ассоциаций, согласова­ния атрибутов, а также поддерживает методы аутентификации, допускающие отказ от авторства и не до­пускающие такого отказа. Этот протокол может, к примеру, использоваться для создания виртуальных частных сетей (VPN) и для того, чтобы предоставить пользователям, находящимся в удаленных точках (и пользующимся динамически распределяемыми адресами IP), доступ к защищенной сети.

Стандарт IPSec позволит поддержать на уровне IP потоки безопасных и аутентичных данных между вза­имодействующими устройствами, включая центральные компьютеры, межсетевые экраны (сетевые фильтры) различных типов и маршрутизаторы. Прежде, чем пройти межсетевой экран предприятия, весь трафик, идущий от удаленного маршрутизатора, должен быть аутентифицирован. Маршрутизатор и межсетевой экран должны согласовать «ассоциацию безопасности» (SA), то есть прийти к согласию относительно политики в области безопасности. Понятие «Безопасные Ассоциации» (Security Association – SA) является фундаментальным в IPsec. SA включает:

• алгоритм шифрования;

• алгоритм аутентификации;

• общий ключ сессии;

• срок действия ключа.

SA есть совокупность параметров соединения, которые дают возможность сервисам обеспечивать безопасный трафик. SA определяет использование AH или ESP. Если к потоку трафика применяются оба протокола, AH и ESP, то создаются две SA. При двунаправленном соединении между двумя хостами или между двумя шлюзами безопасности требуется два SA (по одному на каждое направление).

SA однозначно определяется тройкой, состоящей из Security Parameter Index (SPI), IP Destination Address (адресом назначения) и идентификатора протокола безопасности (AH или ESP). В принципе адрес назначения может быть единственным адресом, широковещательным (broadcast) адресом или групповым (multicast) адресом. Однако механизм управления SA в настоящее время определяется только для единственной SA. Следовательно, SA будут описаны в контексте point-to-point соединения, даже если концепция также применяется в случае point-to-multipoint.

Определены два режима SA: режим транспорта и режим туннелирования. Транспортный режим SA обеспечивает безопасную связь между двумя хостами. В IPv4 заголовок протокола безопасности транспортного режима появляется сразу после IP заголовка и всех опций и перед любыми протоколами более высокого уровня (ТСР или UDP). В случае ESP транспортный режим SA обеспечивает сервисы безопасности только для протоколов более высокого уровня, но не для IP-заголовка. В случае AH защита также распространяется на отдельные части IP-заголовка.

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

B туннелирующем режиме SA существует «внешний» IP заголовок, который определяет пункт назначения IPsec, и «внутренний» IP заголовок, который определяет конечный пункт назначения для пакета. Заголовок протокола безопасности расположен после внешнего IP заголовка и перед внутренним IP заголовком. Если AH используется в туннелирующем режиме, части внешнего IP заголовка являются защищенными, как и весь туннелируемый IP пакет, т.е. все внутренние заголовки защищены, как и все протоколы более высокого уровня. Если применяется ESP, зашита обеспечивается только для туннелируемого пакета, а не для внешнего IP-заголовка.

Итак:

1. Хост может поддерживать оба режима, как транспортный, так и туннелирующий.
2. Шлюз безопасности может использовать только туннелирующий режим. Если он поддерживает транспортный режим, то этот режим должен использоваться только тогда, когда безопасный шлюз является хостом, например, для управления сетью.

Существуют две БД: БД Политики Безопасности (SPD) и БД Безопасной Ассоциации (SAD). Первая описывает политики, которые определяют характер обработки всего IP трафика. Вторая БД содержит параметры, которые связаны с каждой активной безопасной ассоциацией. Каждый сетевой интерфейс, для которого необходима обработка IPsec, требует определения баз данных для входящего и исходящего трафика.

БД политики безопасности (SPD)

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

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

Каждая реализация IPsec должна иметь программный интерфейс, который позволяет системному администратору управлять SPD. SPD должна определять, какие действия должны быть выполнены в том или ином случае. Таким образом, программный интерфейс должен позволять специфицировать обработку, применяемую к любому пакету, входящему или выходящему из системы. Интерфейс управления для SPD должен допускать создание последовательности записей, и должна поддерживаться упорядоченность этих записей. Возможно использование символа «*» в различных полях.

SPD содержит упорядоченный список записей политики. Каждая запись политики является ключом для одного или более селекторов, которые определяют множество IP трафика, соответствующего данной записи политики. Это определяет детализированность политики и создаваемых SA. Каждая запись включает индикатор, показывающий, что трафик, соответствующий данной политике, должен быть пропущен, отброшен или обработан IPsec. Если применяется обработка IPsec, запись содержит описание SA (или узла SA), список применяемых протоколов, режимов и алгоритмов, включая любые дополнительные требования. Например, запись может указывать, что трафик защищается ESP в транспортном режиме, используя 3DES-CBC с явным IV, и вложен в AH в туннелирующем режиме с помощью НМАС /SHA-1.

База данных Безопасной Ассоциации (SAD)

В IPsec существует База Данных Безопасных Ассоциаций, в которой каждая запись определяет параметры, связанные с конкретной SA. Соответственно, каждая SA имеет запись в SAD. Для выходящей обработки записи ссылаются на записи в SPD. Для входящей обработки каждая запись в SAD индексируется IP адресом назначения, типом протокола IPsec и SPI.

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

Рис.1. Согласование SA через ISAKMP.

После согласования SA принимается решение о том, следует ли использовать средства аутентификации, конфиденциальности и целостности данных или ограничиться только аутентификацией. Если использо­ваться будут только средства аутентификации, текущий стандарт предполагает применение хэш-функ­ции, а точнее алгоритма не ниже MD5 с 128-разрядными ключами. Заголовок пакета и данные пропуска­ются через хэш-функцию, и результаты этого вычисления вводятся в специальное поле заголовка АН, как показано на рисунке 2.

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

Рис.2. Создание нового аутентификационного заголовка IP.

Рис.3. проверка аутентичности и целостности данных.

Если стороны пожелают использовать средства поддержки конфиденци­альности, SA указывает, что весь трафик, поступающий из удаленного маршрутизатора на межсетевой экран предприятия, должен аутентифицироваться и шифроваться. В противном случае межсетевой экран его не пропустит. ESP поддерживает аутентификацию, целостность и конфиденциальность данных и работает в двух режимах: туннельном и транспортном, как показано на рисунках 4 и 5.

Рис.4. Туннельный режим ESP.

Рис.5. Транспортный режим ESP.

В туннельном режиме вся датаграмма IP, заголовок IP и данные встраиваются в заголовок ESP. В транс­портном режиме шифруются только данные, а заголовок IP передается в незашифрованном виде. Совре­менные стандарты требуют использования DES в режиме цепочки зашифрованных блоков (СВС).

Преимущества поддержки безопасности на сетевом уровне с помощью IPSec включают:

§ поддержку совершенно немодифицированных конечных систем, хотя в этом случае шифрование нельзя назвать в полном смысле слова сквозным (end-to-end);

§ частичную поддержку виртуальных частных сетей (VPN) в незащищенных сетях;

§ поддержку транспортных протоколов, иных, чем TCP (например, UDP);

§ защиту заголовков транспортного уровня от перехвата и, следовательно, более надежную защиту от анализа трафика;

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

Х.509

Многие протоколы и приложения, которые пользуются услугами Интернет, применяют в целях безопасности технологию общих ключей. Для безопасного управления общими ключами в среде широкораспределенных пользователей или систем им необходим PKI. Стандарт Х.509 определяет форматы данных и процедуры распреде­ления общих ключей с помощью сертификатов с цифровыми подписями, которые проставляются сертификационными органами (СА). RFC 1422 создает основу для PKI на базе Х.509, что позволяет удовлетворить потребности электронной почты с повышенным уровнем защищенности, передаваемой через Интернет (РЕМ). В действующих стандартах определен сертификат Х.509 версии 3 и список отзыва сертификатов (CRL) версии 2.

Для технологии общих ключей необходимо, чтобы пользователь общего ключа был уверен, что этот ключ принадлежит именно тому удаленному субъекту (пользователю или системе), который будет использо­вать средства шифрования или цифровой подписи. Такую уверенность дают сертификаты общих ключей, то есть структуры данных, которые связывают величины общих ключей с субъектами. Эта связь до­стигается цифровой подписью доверенного СА под каждым сертификатом. Сертификат имеет ограниченный срок действия, указанный в его подписанном содержании. Поскольку пользователь сертификата может самостоятельно проверить его подпись и срок действия, сертификаты могут распространяться через незащищенные каналы связи и серверные системы, а также храниться в кэш-памяти незащищен­ных пользовательских систем. Содержание сертификата должно быть одинаковым в пределах всего PKI. В настоящее время в этой области предлагается общий стандарт для Интернет с использованием формата Х.509 v3 (рис.6).

Рис.6. Формат сертификата X.509 v3.

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

Рис.7. Создание цифровой подписи для сертификата X.509 v3.

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

CRL представляет собой список отозванных сертификатов с указанием времени. Он подписывается СА и свободно распространяется через общедоступный репозиторий. В списке CRL каждый отозванный сертификат опознается по своему серийному номеру. Когда у какой-то системы возникает необходимость в использовании сертификата (например, для проверки цифровой подписи удаленного пользователя), эта система не только проверяет подпись сертифи­ката и срок действия, но и просматривает последний из доступных списков CRL, проверяя, не отозван ли этот сертификат. Значение термина «последний из доступных» зависит от местной политики в области безопасности, но обычно здесь имеется в виду самый последний список CRL. СА составляет новые списки CRL на регулярной основе с определенной периодичностью (напри­мер, каждый час, каждый день или каждую неделю). Отозванные сертификаты немедленно вносятся в список CRL. Записи об отозванных сертификатах удаляются из списка в момент истечения официально­го срока действия сертификатов.

На рисунке 8 показан пример связи между системами и единым СА при помощи цифровых сертификатов.

Рис.8. Передача цифрового сертификата.

Оба маршрутизатора и СА имеют свои пары общих/частных ключей. Вначале СА должен передать обоим маршрутизаторам по защищенным каналам сертификат Х.509 v3. Кроме того, оба маршрутизатора должны получить по защищенным каналам копию общего ключа СА. После этого, если маршрутизатор 1 имеет трафик для отправки маршрутизатору 2 и хочет передать этот трафик ау­тентичным и конфиденциальным способом, он должен предпринять следующие шаги:

1. Маршрутизатор 1 направляет запрос в СА для получения общего ключа маршрутизатора 2.

2. СА отправляет ему сертификат маршрутизатора 2, подписанный своим частным ключом.

3. Маршрутизатор 1 проверяет подпись общим ключом СА и убеждается в аутентичности общего ключа маршрутизатора 2.

4. Маршрутизатор 2 направляет запрос в СА для получения общего ключа маршрутизатора 1.

5. СА отправляет ему сертификат маршрутизатора 1, подписанный своим частным ключом.

6. Маршрутизатор 2 проверяет подпись общим ключом СА и убеждается в аутентичности общего ключа маршрутизатора 1.

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

Технологии удаленного доступа к виртуальным частным сетям

Виртуальные частные сети с удаленным доступом (Virtual Private Dialup Networks — VPDN) позволяют крупным компаниям расширять свои частные сети, используя линии удаленной связи. Новые технологии снимают проблему высокой стоимости междугородней или международной связи и проблему низкой защищенности общих телефонных линий и каналов Интернет, через которые удаленный пользователь по­лучает доступ к корпоративной сети. Новые технологии предоставляют удаленным офисам и пользовате­лям безопасный доступ к инфраструктуре предприятия через местное подключение к сети Интернет. В настоящее время для этого используются три протокола: протокол эстафетной передачи на втором уров­не (Layer 2 Forwarding — L2F), сквозной туннельный протокол (Point-to-Point Tunneling Protocol — РРТР) и туннельный протокол второго уровня (Layer 2 Tunneling Protocol — L2TP).

L2F

Протокол эстафетной передачи на втором уровне (Layer 2 Forwarding — L2F) был разработан компанией Cisco Systems. Он обеспечивает туннелирование протоколов канального уровня (то есть фреймов High-Level Data Link Control [HDLC], async HDLC или Serial Line Internet Protocol [SLIP]) с использованием про­токолов более высокого уровня, например, IP. С помощью таких туннелей можно разделить местополо­жение сервера удаленного доступа, к которому подключается пользователь, используя местные комму­тируемые линии связи, и точки, где происходит непосредственная обработка протокола удаленного дос­тупа (SLIP, PPP), и пользователь получает доступ в сеть. Эти туннели дают возможность использовать приложения, требующие удаленного доступа с частными адресами IP, IPX и AppleTalk через протокол SLIP/PPP по существующей инфраструктуре Интернет. Поддержка таких многопротокольных приложе­ний виртуального удаленного доступа очень выгодна конечным пользователям и независимым постав­щикам услуг, поскольку позволяет разделить на всех расходы на средства доступа и базовую инфрастру­ктуру и дает возможность осуществлять доступ через местные линии связи. Кроме того, такой подход за­щищает инвестиции, сделанные в существующие приложения, работающие не по протоколу IP, предос­тавляя защищенный доступ к ним и в то же время поддерживая инфраструктуру доступа к Интернет.

РРТР

Сквозной туннельный протокол Point-to-Point Tunneling Protocol (РРТР) создан корпорацией Microsoft. Он никак не меняет протокол РРР, но предоставляет для него новое транспортное средство. В рамках это­го протокола определяется архитектура клиент/сервер, предназначенная для разделения функций, кото­рые существуют в текущих NAS, и для поддержки виртуальных частных сетей (VPN). Сервер сети РРТР (PNS) должен работать под управлением операционной системы общего назначения, а клиент, который называется концентратором доступа к РРТР (РАС), работает на платформе удаленного доступа. РРТР определяет протокол управления вызовами, который позволяет серверу управлять удаленным коммутиру­емым доступом через телефонные сети общего пользования (PSTN) или цифровые каналы ISDN или ини­циализировать исходящие коммутируемые соединения. РРТР использует механизм общей маршрутной инкапсуляции (GRE) для передачи пакетов РРР, обеспечивая при этом контроль потоков и сетевых зато­ров. Безопасность данных в РРТР может обеспечиваться при помощи протокола IPSec.

L2TP

Протоколы L2F и РРТР имеют сходную функциональность. Компании Cisco и Microsoft согла­сились вместе (в рамках IETF) разработать единый стандартный протокол, который получил название туннельного протокола второго уровня (Layer 2 Tunneling Protocol — L2TP).