безопасность сетей и каналов передачи данных. Тема Проблемы информационной безопасности сетей Содержание темы

• Название: Тема Проблемы информационной безопасности сетей Содержание темы
• Дата: 09.10.2022
• Размер: 1.46 Mb.
• Имя файла: безопасность сетей и каналов передачи данных.docx
• Тип: Реферат; #723057
• страница: 7 из 14

Тема 5. Защита на канальном и сеансовом уровнях

 

Содержание темы:

1.   Протоколы формирования защищенных каналов на канальном уровне.

2.   Протоколы формирования защищенных каналов на сеансовом уровне.

3.   Защита беспроводных сетей.

 

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

Средства VPN, применяемые на канальном уровне модели OSI, позволяют обеспечить инкапсуляцию различных видов трафика третьего уровня (и выше) и построение виртуальных туннелей типа «точка-точка» (от маршрутизатора к маршрутизатору или от персонального компьютера к шлюзу ЛВС).

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

 

Вопрос 1. Протоколы формирования защищенных каналов на канальном уровне.

 

Протоколы РРТР (Point to Point Tunneling Protocol), L2F (Layer2 Forwarding) и L2TP (Layer2 Tunneling Protocol) это протоколы туннелирования канального уровня модели OSI. Общим свойством этих протоколов является то, что они используются для организации защищенного многопротокольного удаленного доступа к ресурсам корпоративной сети через открытую сеть, например через Интернет.

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

Клиентское ПО обычно использует для удаленного доступа стандартный протокол канального уровня РРР (Point to Point Protocol). Протоколы РРТР, L2F и L2TP основываются на протоколе РРР и являются его расширениями. Первоначально протокол РРР, расположенный на канальном уровне, был разработан для инкапсуляции данных и их доставки по соединениям типа «точка-точка». Этот протокол служит также для организации асинхронных (например, коммутируемых) соединений. В частности, в настройках коммутируемого доступа удаленных систем Windows 2000 или Windows 9х обычно указывается подключение к серверу по протоколу РРР.

В набор РРР входят протокол управления соединением LCP (Link Control Protocol), ответственный за конфигурацию, установку, работу и завершение соединения «точка-точка», и протокол управления сетью NCP (Network Control Protocol), способный инкапсулировать в РРР протоколы сетевого уровня для транспортировки через соединение «точка-точка». Это позволяет одновременно передавать пакеты Novell IPX и Microsoft IP по одному соединению РРР.

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

На физическом и канальном уровнях протоколы РРТР и L2TP идентичны, но на этом их сходство заканчивается и начинаются различия.

 

Протокол РРТР.

Протокол РРТР (Point to Point Tunneling Protocol), разработанный компанией Microsoft при поддержке других компаний, предназначен для создания защищенных виртуальных каналов при доступе удаленных пользователей к локальным сетям через Интернет. Он предполагает создание криптозащищенного туннеля на канальном уровне модели OSI как для случая прямого соединения удаленного компьютера с открытой сетью, так и для случая подсоединения его к открытой сети по телефонной линии через провайдера.

Протокол РРТР получил практическое распространение благодаря компании Microsoft, реализовавшей его в своих ОС Windows NT/2000. Некоторые производители МЭ и шлюзов VPN также поддерживают этот протокол. Протокол РРТР позволяет создавать защищенные каналы для обмена данными по протоколам IP, IPX или NetBEUI. Данные этих протоколов упаковываются в кадры РРР и затем инкапсулируются посредством протокола РРТР в пакеты протокола IP, с помощью которого переносятся в зашифрованном виде через любую сеть TCP/IP.

Пакеты, передаваемые в рамках сессии РРТР, имеют следующую структуру (Рис. 26.):

     заголовок канального уровня, используемый внутри Интернета, например заголовок кадра Ethernet;

     заголовок IP, содержащий адреса отправителя и получателя пакета;

     заголовок общего метода инкапсуляции для маршрутизации GRE (Generic Routing Encapsulation);

     исходный пакет РРР, включающий пакет IP, IPX или NetBEUI.

 



 

Рис. 26. Структура пакета для пересылки по туннелю PPTP

 

Принимающий узел сети извлекает из пакетов IP кадры РРР, а затем извлекает из кадра РРР исходный пакет IP, IPX или NetBEUI и отправляет его по локальной сети конкретному адресату. Многопротокольность инкапсулирующих протоколов канального уровня, к которым относится протокол РРТР, является их важным преимуществом перед протоколами защищенного канала более высоких уровней. Например, если в корпоративной сети используются IPX или NetBEUI, применение протоколов IPSec или SSL просто невозможно, поскольку они ориентированы только на один протокол сетевого уровня IP.

Такой способ инкапсуляции обеспечивает независимость от протоколов сетевого уровня модели OS1 и позволяет осуществлять защищенный удаленный доступ через открытые IP сети к любым локальным сетям (IP, IPX или NetBEUI), Согласно протоколу РРТР при создании защищенного виртуального канала производится аутентификация удаленного пользователя и шифрование передаваемых данных (Рис. 27.).

 



 

Рис. 27. Архитектура протокола PPTP

 

Для аутентификации удаленного пользователя могут использоваться различные протоколы, применяемые для РРР. В реализации РРТР, включенной компанией Microsoft в Windows 98/ NT/2000, поддерживаются следующие протоколы аутентификации: протокол распознавания по паролю PAP (Password Authentication Protocol), протокол распознавания при рукопожатии MSCHAP (Microsoft Challenge Handshaking Authentication Protocol) и протокол распознавания EAPTLS (Extensible Authentication Protocol Transport Layer Security). При использовании протокола PAP идентификаторы и пароли передаются по линии связи в незашифрованном виде, при этом только сервер проводит аутентификацию клиента. При использовании протоколов MSCHAP и EAPTLS обеспечиваются защита от повторного использования злоумышленником перехваченных пакетов с зашифрованным паролем и взаимная аутентификация клиента и VPN сервера.

Шифрование с помощью РРТР гарантирует, что никто не сможет получить доступ к данным при пересылке через Internet. Протокол шифрования МРРЕ (Microsoft Point to Point Encryption) совместим только с MSCHAP (версии 1 и 2) и EAPTLS и умеет автоматически выбирать длину ключа шифрования при согласовании параметров между клиентом и сервером. Протокол МРРЕ поддерживает работу с ключами длиной 40, 56 или 128 бит. Протокол РРТР изменяет значение ключа шифрования после каждого принятого пакета.

Для протокола РРТР определены две основные схемы применения: схема туннелирования при прямом соединении удаленного компьютера с Интернетом; схема туннелирования при подключении удаленного компьютера к Интернету по телефонной линии через провайдера.

Рассмотрим реализацию 1-й схемы туннелирования (Рис. 28.). Удаленный пользователь устанавливает удаленное соединение с локальной сетью с помощью клиентской части сервиса удаленного доступа RAS (Remote Access Service), входящего в состав Windows 98/NT. Затем пользователь обращается к серверу удаленного доступа локальной сети, указывая его IP адрес, и устанавливает с ним связь по протоколу РРТР.

 



 

Рис. 28. Схема туннелирования при прямом подсоединении компьютера удаленного пользователя к Internet

 

Функции сервера удаленного доступа может выполнять пограничный маршрутизатор локальной сети. На компьютере удаленного пользователя должны быть установлены клиентская часть сервиса RAS и драйвер РРТР, которые входят в состав Windows 98/NT, а на сервере удаленного доступа локальной сети сервер RAS и драйвер РРТР, входящие в состав Windows NT Server. Протокол РРТР определяет несколько служебных сообщений, которыми обмениваются взаимодействующие стороны. Служебные сообщения передаются по протоколу TCP. После успешной аутентификации начинается процесс защищенного информационного обмена. Внутренние серверы локальной сети могут не поддерживать протокол РРТР, поскольку пограничный маршрутизатор извлекает кадры РРР из пакетов IP и посылает их по локальной сети в необходимом формате IP, IPX или NetBIOS. 2я схема туннелирования не получила широкого распространения.

 

Протокол L2TP.

Протокол L2F (Layer2 Forwarding) был разработан компанией Cisco Systems для построения защищенных виртуальных сетей на канальном уровне модели OSI как альтернатива протоколу РРТР.

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

Протокол L2TP (Layer2 Tunneling Protocol) разработан в организации IETF (Internet Engineering Task Force) при поддержке компаний Microsoft и Cisco Systems. Протокол L2TP разрабатывался как протокол защищенного туннелирования РРР трафика через сети общего назначения с произвольной средой. Работа над этим протоколом велась на основе протоколов РРТР и L2F, и в результате он вобрал в себя лучшие качества исходных протоколов.

В отличие от РРТР, протокол L2TP не привязан к протоколу IP, поэтому он может быть использован в сетях с коммутацией пакетов, например в сетях ATM (Asynchronous Transfer Mode) или в сетях с ретрансляцией кадров (frame relay). Кроме того, в протокол L2TP добавлена важная функция управления потоками данных, а также ряд отсутствующих в спецификации протокола РРТР функций защиты, в частности, включена возможность работы с протоколами АН и ESP стека протоколов IPSec (Рис. 29.).

 



 

Рис. 29. Архитектура протокола L2TP

 

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

Протокол L2TP применяет в качестве транспорта протокол UDP и использует одинаковый формат сообщений как для управления туннелем, так и для пересылки данных.

Хотя протокол РРТР обеспечивает достаточную степень безопасности, но все же протокол L2TP (поверх IPSec) надежнее. Протокол L2TP (поверх IPSec) обеспечивает аутентификацию на уровнях «пользователь» и «компьютер», а также выполняет аутентификацию и шифрование данных.

После того как L2TP (поверх IPSec) завершает процесс аутентификации компьютера, выполняется аутентификация на уровне пользователя.

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

Согласно спецификации протокола L2TP роль сервера удаленного доступа провайдера должен выполнять концентратор доступа LAC (L2TP Access Concentrator), который обеспечивает удаленному пользователю сетевой доступ к его локальной сети через Интернет. В качестве сервера удаленного доступа локальной сети должен выступать сетевой сервер LNS (L2TP Network Server), функционирующий на совместимых с протоколом РРР платформах (Рис. 30.).

 



 

Рис. 30. Схема туннелирования по протоколу L2TP

 

Формирование защищенного виртуального канала в протоколе L2TP осуществляется в три этапа:

     установление соединения с сервером удаленного доступа локальной сети;

     аутентификация пользователя;

     конфигурирование защищенного туннеля.

 

Следует отметить, что протокол L2TP не определяет конкретных методов криптозащиты и предполагает возможность применения различных стандартов шифрования. Если защищенный туннель планируется сформировать в IP сетях, тогда для реализация криптозащиты используется протокол IPSec. Протокол L2TP поверх IPSec обеспечивает более высокую степень защиты данных, чем РРТР, так как использует алгоритм шифрования 3DES или AES. Если такой высокий уровень защиты не нужен, можно использовать алгоритм DES с одним 56разрядным ключом. Кроме того, при помощи алгоритма НМАС (Hash Message Authentication Code) протокол L2TP обеспечивает аутентификацию данных, для чего этот алгоритм создает хэш длиной 128 разрядов.

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

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

       для реализации протокола L2TP необходима поддержка провайдеров ISP;

       протокол L2TP ограничивает трафик рамками выбранного туннеля и лишает пользователей доступа к другим частям Интернета;

       спецификация L2TP обеспечивает стандартное шифрование только в IP сетях с помощью протокола IPSec.

 

Вопрос 2. Протоколы формирования защищенных каналов на сеансовом уровне.

 

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

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

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

Для защиты информационного обмена на сеансовом уровне широкое распространение получил протокол SSL (Secure Sockets Layer). Для выполнения на сеансовом уровне функций посредничества между взаимодействующими сторонами организацией IETF (Internet Engineering Task Force) в качестве стандарта принят протокол SOCKS.

 

Протоколы SSL/TLS.

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

Взаимная аутентификация обеих сторон в SSL выполняется путем обмена цифровыми сертификатами открытых ключей пользователей (клиента и сервера), заверенными цифровой подписью специальных сертификационных центров. Протокол SSL поддерживает сертификаты, соответствующие общепринятому стандарту Х.509, а также стандарты инфраструктуры открытых ключей PKI (Public Key Infrastructure), с помощью которой организуется выдача и проверка подлинности сертификатов.

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

В качестве алгоритмов асимметричного шифрования используются алгоритм RSA, а также алгоритм Диффи Хеллмана. Допустимыми алгоритмами симметричного шифрования являются RC2, RC4, DES, 3DES и AES. Для вычисления хэш функций могут применяться стандарты MD5 и SHA1. В протоколе SSL версии 3.0 набор криптографических алгоритмов является расширяемым.

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

 



 

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

 

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

     установление SSLсессии;

     защищенное взаимодействие.

 

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

     аутентификация сторон;

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

     формирование общего секретного мастер ключа;

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

 

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

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

Протокол SSL 3.0 поддерживает три режима аутентификации:

     взаимную аутентификацию сторон;

     одностороннюю аутентификацию сервера без аутентификации клиента;

     полную анонимность.

 

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

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

Протокол SSL прошел проверку временем, работая в популярных браузерах Netscape Navigator и Internet Explorer, а также Webсерверах ведущих производителей. В январе 1999 г. на смену версии SSL 3.0 пришел протокол TLS (Transport Layer Security), который базируется на протоколе SSL и в настоящее время является стандартом Интернета. Различия между протоколами SSL 3.0 и TLS 1.0 не слишком существенны. Протокол SSL стал промышленным протоколом, развиваемым и продвигаемым вне технических координирующих институтов Internet.

Протокол SSL поддерживается ПО серверов и клиентов, выпускаемых ведущими западными компаниями. Существенным недостатком протокола SSL является то, что практически все продукты, поддерживающие SSL, из-за экспортных ограничений доступны за пределами США лишь в усеченном варианте (с длиной сеансового ключа 40 бит для алгоритмов симметричного шифрования и 512 бит для алгоритма RSA, используемого на этапе установления SSLсессии).

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

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

 

Протокол SOCKS.

Протокол SOCKS организует процедуру взаимодействия клиент серверных приложений на сеансовом уровне модели OSI через сервер посредник, или proxy сервер.

В общем случае программы посредники, которые традиционно используются в МЭ, могут выполнять следующие функции:

     идентификацию и аутентификацию пользователей;

     криптозащиту передаваемых данных;

     разграничение доступа к ресурсам внутренней сети;

     разграничение доступа к ресурсам внешней сети;

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

     трансляцию внутренних сетевых адресов для исходящих потоков сообщений.

 

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

На основе протокола SOCKS могут быть реализованы и другие функции посредничества по защите сетевого взаимодействия. Например, протокол SOCKS может применяться для контроля над направлениями информационных потоков и разграничения доступа в зависимости от атрибутов пользователей и информации. Эффективность использования протокола SOCKS для выполнения функций посредничества обеспечивается его ориентацией на сеансовый уровень модели OSI. По сравнению с посредниками прикладного уровня на сеансовом уровне достигается более высокое быстродействие и независимость от высокоуровневых протоколов (HTTP, FTP, РОРЗ, SMTP и др.). Кроме того, протокол SOCKS не привязан к протоколу IP и не зависит от ОС. Например, для обмена информацией между клиентскими приложениями и посредником может использоваться протокол IPX.

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

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

Протокол SOCKS v5 одобрен организацией IETF (Internet Engineering Task Force) в качестве стандарта Internet и включен в RFC 1928.

Общая схема установления соединения по протоколу SOCKS v5 может быть описана следующим образом:

1.     запрос прикладного клиента, желающего установить соединение с каким-либо прикладным сервером в сети, перехватывает установленный на этом же компьютере SOCKS клиент;

2.     соединившись с SOCKS сервером, SOCKS клиент сообщает ему идентификаторы всех методов аутентификации, которые он поддерживает;

3.     SOCKS сервер решает, каким методом аутентификации воспользоваться (если SOCKS сервер не поддерживает ни один из методов аутентификации, предложенных SOCKS клиентом, соединение разрывается);

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

5.     после успешной аутентификации SOCKS клиент передает SOCKS серверу DNS имя или IP адрес запрашиваемого прикладного сервера в сети и далее SOCKS сервер на основе имеющихся правил разграничения доступа принимает решение об установлении соединения с этим прикладным сервером;

6.     в случае установления соединения прикладной клиент и прикладной сервер взаимодействуют друг с другом по цепочке соединений, в которой SOCKS сервер ретранслирует данные, а также может выполнять функции посредничества по защите сетевого взаимодействия; например, если в ходе аутентификации SOCKS клиент и SOCKS сервер обменялись сеансовым ключом, то весь трафик между ними может шифроваться. Аутентификация пользователя, выполняемая SOCKS сервером, может основываться на цифровых сертификатах в формате Х.509 или паролях. Для шифрования трафика между SOCKS клиентом и SOCKS сервером могут быть использованы протоколы, ориентированные на сеансовый или более низкие уровни модели OSI. Кроме аутентификации пользователей, трансляции IP адресов и криптозащиты трафика, SOCKS сервер может выполнять также такие функции, как:

     разграничение доступа к ресурсам внутренней сети;

     разграничение доступа к ресурсам внешней сети;

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

     регистрация событий и реагирование на задаваемые события;

     кэширование данных, запрашиваемых из внешней сети.

 

Протокол SOCKS осуществляет встроенную поддержку популярных Web навигаторов Netscape Navigator и Netscape Communicator компании Netscape, а также Internet Explorer компании Microsoft.

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

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

 



 

Рис. 32. Схема взаимодействия по протоколу SOCKS

 

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

Помимо защиты локальной сети от НСД, на SOCKS сервер может возлагаться контроль доступа пользователей этой локальной сети к открытым ресурсам Интернета (Telnet, WWW, SMTP, POP и др.). Доступ является полностью авторизованным, так как идентифицируются и аутентифицируются конкретные пользователи, а не компьютеры, с которых они входят в сеть. Правила доступа могут запрещать или разрешать соединения с конкретными ресурсами Интернета в зависимости от полномочий конкретного сотрудника. Действие правил доступа может зависеть и от других параметров, например от метода аутентификации или времени суток.

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

 

Вопрос 3. Защита беспроводных сетей.

 

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

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

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

 

Общие сведения.

Как и все стандарты IEEE 802, базовый стандарт организации беспроводных локальных сетей IEEE 802.11 работает на нижних двух уровнях модели ISO/OSI физическом и канальном. Сетевое приложение, сетевая ОС или протокол (например, TCP/IP) будут так же хорошо работать в сети 802.11, как и в сети Ethernet.

Основная архитектура, особенности и службы определяются в базовом стандарте 802.11 (см. разд. 4.2), который определяет два режима работы беспроводной сети режим клиент/сервер (или режим инфраструктуры) и режим «точка-точка» (Adhoc).

В режиме клиент/сервер беспроводная сеть состоит как минимум из одной точки доступа АР (Access point), подключенной к проводной сети, и некоторого набора беспроводных оконечных станций. Такая конфигурация носит название базового набора служб BSS (Basic Service Set). Два или более BSS, образующих единую подсеть, формируют расширенный набор служб ESS (Extended Service Set). Так как большинству беспроводных станций требуется получать доступ к файловым серверам, принтерам, Интернету, доступным в проводной локальной сети, они будут работать в режиме клиент/сервер.

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

На физическом уровне стандарта 802.11 определены 2 широкополосных радиочастотных метода передачи и 1 в инфракрасном диапазоне. Радиочастотные методы работают в ISM диапазоне 2,4 ГГц и обычно используют полосу 83 МГц от 2,400 ГГц до 2,483 ГГц. Технологии широкополосного сигнала, используемые в радиочастотных методах, увеличивают надежность, пропускную способность, позволяют многим несвязанным друг с другом устройствам разделять одну полосу частот с минимальными помехами друг для друга.

Основное дополнение, внесенное стандартом 802.11b в основной стандарт, это поддержка двух новых скоростей передачи данных 5,5 и 11 Mbps. Для достижения этих скоростей был выбран метод прямой последовательности DSSS (Direct Sequence Spread Spectrum).

Канальный (Data Link) уровень стандарта 802.11 состоит из двух подуровней: управления логической связью LLC (Logical Link Control) и управления доступом к носителю MAC (Media Access Control).

 

Обеспечение безопасности беспроводных сетей.

Система защиты беспроводных сетей WLAN, основанная на протоколе WEP (Wired Equivalent Privacy) первоначального стандарта 802.11, имеет существенные недостатки. Однако появились более эффективные технологии обеспечения информационной безопасности WLAN, которые описаны в стандарте WPA (WiFi Protected Access) организации WiFi Alliance и стандарте 802.1 li института IEEE и призваны устранить недостатки стандарта 802.11. Поскольку процесс разработки стандарта 802.1 li слишком затянулся, организация WiFi Alliance была вынуждена предложить в 2002 г. собственную технологию обеспечения информационной безопасности WLAN стандарт WPA.

Стандарт WPA весьма привлекателен тем, что относительно прост в реализации и позволяет защитить ныне действующие WLAN. Стандарты WPA и 802.1 li совместимы друг с другом, поэтому использование поддерживающих WPA продуктов можно считать начальным этапом перехода к системе защиты на базе стандарта 802.Hi (см. разд. 4.2). Между технологиями стандартов 802.1 li и WPA много общего. Так, в них определена идентичная архитектура системы безопасности с улучшенными механизмами аутентификации пользователей и протоколами распространения и обновления ключей. Но есть и существенные различия. Например, технология WPA базируется на протоколе динамических ключей TKIP (Temporal Key Integrity Protocol), поддержку которого в большинстве устройств WLAN можно реализовать путем обновления их ПО, а в более функциональной концепции стандарта 802.11 i предусмотрено использование нового стандарта шифрования AES (Advanced Encryption Standard), с которым совместимо лишь новейшее оборудование для WLAN.

В стандарте WPA предусмотрено использование защитных протоколов 802.1х, ЕАР, TKIP и RADIUS.

Механизм аутентификации пользователей основан на протоколе контроля доступа 802.1х (разработан для проводных сетей) и протоколе расширенной аутентификации ЕАР (Extensible Authentication Protocol). Последний позволяет сетевому администратору задействовать алгоритмы аутентификации пользователей посредством сервера RADIUS.

Функции обеспечения конфиденциальности и целостности данных базируются на протоколе TKIP, который в отличие от протокола WEP использует более эффективный механизм управления ключами, но тот же самый алгоритм RC4 для шифрования данных. Согласно протоколу TKIP, сетевые устройства работают с 48битовым вектором инициализации (в отличие от 24битового вектора инициализации протокола WEP) и реализуют правила изменения последовательности его битов, что исключает повторное использование ключей и осуществление replay атак.

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

Система сетевой безопасности стандарта WPA работает в двух режимах: PSK (PreShared Key) и Enterprise (корпоративный). Для развертывания системы, работающей в режиме PSK, необходим разделяемый пароль. Такую систему несложно устанавливать, но она защищает WLAN не столь надежно, как это делает система, функционирующая в режиме Enterprise с иерархией динамических ключей. Хотя протокол TKIP работает с тем же самым блочным шифром RC4, который предусмотрен спецификацией протокола WEP, технология WPA защищает данные надежнее последнего.

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

Чтобы корпоративные точки доступа работали в системе сетевой безопасности стандарта WPA или 802.1b, они должны поддерживать аутентификацию пользователей по протоколу RADIUS и реализовывать предусмотренный стандартом метод шифрования TKIP или AES, что потребует модернизации их ПО. И еще одно требование быстро осуществлять повторную аутентификацию пользователей после разрыва соединения с сетью. Это особенно важно для нормального функционирования приложений, работающих в реальном масштабе времени.

Если сервер RADIUS, применяемый для контроля доступа пользователей проводной сети, поддерживает нужные методы аутентификации ЕАР, то его можно задействовать и для аутентификации пользователей WLAN. В противном случае следует установить сервер WLAN RADIUS. Этот сервер работает следующим образом: сначала он проверяет аутентифицирующую информацию пользователя (на соответствие содержимому своей БД об их идентификаторах и паролях) или его цифровой сертификат, а затем активизирует динамическую генерацию ключей шифрования точкой доступа и клиентской системой для каждого сеанса связи.

Для работы технологии WPA требуется механизм EAPTLS (Transport Layer Security), тогда как в стандарте IEEE 802.1 применение конкретных методов аутентификации ЕАР не оговаривается. Выбор метода аутентификации ЕАР определяется спецификой работы клиентских приложений и архитектурой сети. Чтобы ноутбуки и карманные ПК работали в системе сетевой безопасности стандарта WPA или 802.1b, он! должны быть оснащены клиентскими программами, поддерживающими стандарт 802.1х.

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

Предприятиям целесообразно внедрять у себя системы сетевой безопасности стандарта WPA с серверами RADIUS. Большинство компаний предпочитают именно такие системы, поскольку работающие в режиме PSK решения сложнее администрировать и они более уязвимы для хакерских атак. До тех пор пока средства стандарта 802.1 не станут доступными на рынке, WPA будет оставаться самым подходящим стандартом для защиты WLAN.

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

Физическая защита. При развертывании WiFi сети необходимо физически ограничить доступ к беспроводным точкам.

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

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

Традиционные меры. Эффективная работа компьютера в сети немыслима без классических мер защиты своевременной установки обновлений, использования защитных механизмов, встроенных в ОС и приложения, а также антивирусов. Однако этих мер на сегодня недостаточно, так как они ориентированы на защиту от уже известных угроз. Мониторинг сети. Слабое звено в корпоративной сети - самовольно установленные точки доступа. Актуальной является задача локализации несанкционированных точек доступа. Специальные средства локализации точек доступа позволяют графически отображать место расположения «чужого» терминала на карте этажа или здания. Если классические методы не спасают от вторжения, следует применять системы обнаружения атак.

VPN агенты. Многие точки доступа работают в открытом режиме, поэтому необходимо использовать методы защиты передаваемых данных. На защищаемом компьютере должен быть установлен VPN клиент, который возьмет на себя решение этой задачи. Практически все современные ОС (например, Windows ХР) содержат в своем составе такие программные компоненты.