double arrow

Протокол РРР ЕАР

РРР ЕАР (Extensible Authentication Protocol) является общим протоколом аутентификации РРР, который поддерживает множество аутентификационных механизмов. ЕАР не производит выбор конкретного аутентификационного механизма на этапе контроля соединения, но откладывает этот выбор до этапа аутентификации. Этот сценарий позволяет аутентификатору запросить больше информации до определения конкретного аутентификационного механизма. Кроме того, это дает возможность использовать "внутренний" сервер, который реально запускает различные механизмы, тогда как аутентификатор РРР служит лишь для обмена аутентификационными данными.


Рисунок 2. Аутентификация РРР ЕАР

Маршрутизатор отделения пытается провести аутентификацию сервера сетевого доступа (NAS) или “аутентификатора”. По завершении этапа установления связи аутентификатор отправляет один или несколько запросов для аутентификации вызывающей машины. В запросе имеется поле типа запроса, где указано, что именно запрашивается. Так, например, здесь можно указать такие типы запросов, как аутентификация MD5, S/Key, аутентификация с использованием аппаратной карты для генерирования паролей и т.д. Запрос типа MD5 очень схож с протоколом аутентификации CHAP. Обычно аутентификатор отправляет первоначальный аутентификационный запрос, за которым следует один или несколько дополнительных запросов о предоставлении аутентификационной информации. При этом первоначальный запрос не является обязательным и может опускаться в случаях, когда аутентификация обеспечивается иными способами (при связи по выделенным каналам, выделенным номерам и т.д.). В этих случаях вызывающая машина отправляет пакет ответных данных в ответ на каждый запрос.

61. TACACS+

TACACS+ (Terminal Access Controller Access Control System plus) является протоколом последнего поколения из серии протоколов TACACS. TACACS – это простой протокол управления доступом, основанный на стандартах User Datagram Protocol (UDP) и разработанный компанией Bolt, Beranek and Newman, Inc. (BBN) для военной сети Military Network (MIL-NET). Компания Cisco несколько раз совершенствовала и расширяла протокол TACACS, и в результате появилась ее собственная версия TACACS, известная как TACACS+.

TACACS+ пользуется транспортным протоколом TCP. "Демон" сервера "слушает" порт 49, который является портом протокола IP, выделенным для протокола TACACS. Этот порт зарезервирован для выделенных номеров RFC в протоколах UDP и TCP. Все текущие версии TACACS и расширенные варианты этого протокола используют порт 49.

Протокол TACACS+ работает по технологии клиент/сервер, где клиентом TACACS+ обычно является NAS, а сервером TACACS+, как правило, считается "демон" (процесс, запускаемый на машине UNIX или NT). Фундаментальным структурным компонентом протокола TACACS+ является разделение аутентификации, авторизации и учета (ААА – Authentication, Authorization, Accounting). Это позволяет обмениваться аутентификационными сообщениями любой длины и содержания, и, следовательно, использовать для клиентов TACACS+ любой аутентификационный механизм, в том числе РРР PAP, PPP CHAP, аппаратные карты и Kerberos. Аутентификация не является обязательной. Она рассматривается как опция, которая конфигурируется на месте. В некоторых местах она вообще не требуется, в других местах она может применяться лишь для ограниченного набора услуг.

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

В ходе аутентификации TACACS+ используются пакеты трех типов: START, CONTINUE и REPLY. START и CONTINUE всегда отправляются клиентом, a REPLY всегда отправляется сервером.

Аутентификация начинается, когда клиент отправляет серверу сообщение START. Сообщение START описывает тип будущей аутентификации и может содержать имя пользователя и некоторые аутентификационные данные. Пакет START отправляется только в качестве первого сообщения аутентификационной сессии TACACS+ или сразу же после повторного запуска этой сессии. (Повторный запуск может проводиться по просьбе сервера, которая содержится в пакете REPLY.) Пакет START всегда имеет порядковый номер, равный единице.
В ответ на пакет START сервер отправляет пакет REPLY. Сообщение REPLY указывает, завершилась ли аутентификация или ее следует продолжить. Если пакет REPLY требует продолжения аутентификации, он также указывает, какую дополнительную информацию ему нужно предоставить. Клиент собирает эту информацию и отправляет ее серверу в сообщении CONTINUE.

По завершении аутентификации клиент может начать процесс авторизации (если она требуется).


Рисунок 3. Процесс аутентификации TACACS+.

RADIUS

Протокол RADIUS (R emote A uthentication in D ial- I n U ser S ervice)) был разработан компанией Livingston Enterprises, Inc. в качестве протокола аутентификации серверного доступа и учета. В июне 1996 года пятый проектный вариант протокола RADIUS был представлен на рассмотрение IETF. В настоящее время спецификация RADIUS (RFC 2058) и стандарт учета RADIUS (RFC 2059) предложены для утверждения в качестве общепринятых стандартов.

Связь между NAS (Network Access Server) и сервером RADIUS основана на UDP. В целом считается, что протокол RADIUS не имеет отношения к подключению. Все вопросы, связанные с доступностью сервера, повторной передачей данных и отключениями по истечении времени ожидания, контролируются устройствами, работающими под управлением протокола RADIUS, но не самим протоколом передачи.

Протокол RADIUS основан на технологии клиент/сервер. Клиентом RADIUS обычно является NAS, а сервером RADIUS считается “демон”, работающий на машине UNIX или NT. Клиент передает пользовательскую информацию на определенные серверы RADIUS, а затем действует в соответствии с полученными от сервера инструкциями. Серверы RADIUS принимают запросы пользователей на подключение, проводят аутентификацию пользователей, а затем отправляют всю конфигурационную информацию, которая необходима клиенту для обслуживания пользователя. Для других серверов RADIUS или аутентификационных серверов других типов сервер RADIUS может выступать в роли клиента-посредника (proxy).

На рисунке 1 показано взаимодействие между пользователем, с одной стороны, и клиентом и сервером RADIUS, с другой, которое происходит следующим образом:

  1. Пользователь инициирует соединение РРР с сервером доступа.
  2. Сервер доступа запрашивает у пользователя имя и пароль.
  3. Пользователь отвечает на запрос.
  4. Клиент RADIUS посылает имя пользователя и зашифрованный пароль серверу RADIUS.
  5. Сервер RADIUS отвечает сообщениями Accept, Reject или Challenge.
  6. Клиент RADIUS обрабатывает параметры, полученные от сервера, вместе с сообщениями Accept, Reject или Challenge.

Сервер RADIUS может поддерживать разные методы аутентификации пользователя. Если пользователь предоставит ему свое имя и оригинальный пароль, этот сервер может поддержать РРР РАР или CHAP, UNIX login и другие механизмы аутентификации. Обычно регистрация пользователя состоит из запроса (Access Request), который поступает из NAS на сервер RADIUS, и соответствующего ответа (положительного или отрицательного), который дает сервер. Пакет Access Request содержит имя пользователя, зашифрованный пароль, IP-адрес системы NAS и номер порта. Формат запроса дает возможность пользователю запросить определенный тип сессии. Например, если запрос производится в алфавитно-цифровом режиме, из этого следует, что запрашивается услуга одного типа (“Service-Type == Exec-User”), но если запрос делается в пакетном режиме РРР, значит услуга должна быть другой (“Service Type = Framed User” или “Framed Type = PPP”).

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

В системе RADIUS функции аутентификации и авторизации совмещены. Если имя пользователя найдено в базе данных и если пароль указан правильно, сервер RADIUS дает положительный ответ, в котором приводится список пар атрибутов для данной сессии. Типичными параметрами этого типа являются тип услуги (shell или framed), тип протокола, адрес IP, присваиваемый пользователю (статический или динамический), список объектов доступа или статический маршрут, который необходимо добавить в таблицу маршрутизации NAS. Конфигурационная информация на сервере RADIUS определяет, какие средства следует установить на машине NAS. На рисунке 2 показана процедура аутентификации и авторизации RADIUS.

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

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

SSL

Протоколами безопасности на транспортном уровне являются SSL и Secure Shell Protocol (SSH), которые обеспечивают безопасную передачу данных между клиентом и сервером.

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, RC4 и т.д.).
  • Участник сеанса связи может быть аутентифицирован и с помощью общих ключей, то есть средствами асимметричной криптографии (например, RSA, DSS и т.д.).
  • Надежность связи. Транспортные средства проводят проверку целостности сообщений с помощью зашифрованного кода целостности (MAC). Для вычисления кодов MAC используются безопасные хэш-функции (например, безопасный хэш-алгоритм [SHA], МD5 и т.д.).

SSL (англ. Secure Sockets Layer — протокол защищённых сокетов) — криптографический протокол, обеспечивающий безопасную передачу данных по сети Интернет. При его использовании создаётся защищённое соединение между клиентом и сервером. SSL изначально разработан компанией Netscape Communications, в настоящее время принят IETF как стандарт.

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

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

Для доступа к страницам, защищённым протоколом SSL, в URL вместо обычного префикса (schema) http, как правило, применяется префикс https (порт 443), указывающий на то, что будет использоваться SSL-соединение.

Для работы SSL требуется, чтобы на сервере имелся SSL сертификат.

SSH

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

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

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

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

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

Преимущества средств безопасности транспортного уровня (например, SSL или SSH) включают:

  • возможность действий на сквозной основе (end-to-end) с существующими стеками TCP/IP, существующими интерфейсами прикладного программирования (API) (WinSock, Berkeley Standard Distribution [BSD] и т.д.);
  • повышенная эффективность по сравнению с медленными каналами, поддержка технологии Van Jacobson для компрессии заголовков, поддержка различных средств контроля за переполнением сети, просматривающих заголовки TCP/IP;
  • отсутствие каких-либо проблем с фрагментацией, определением максимального объема блоков, передаваемых по данному маршруту (MTU) и т.д.;
  • сочетание компрессии с шифрованием. На этом уровне такое сочетание оказывается гораздо более эффективным, чем на уровне пакетов.

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, вам никогда не придется отправлять важные данные по сети в незащищенном виде.

S-HTTP поддерживает высокий уровень гибкости криптографических алгоритмов, режимов и параметров. Для того чтобы клиенты и серверы смогли выбрать единый режим транзакции (так, например, им нужно решить, будет ли запрос только шифроваться или только подписываться или и шифроваться, и подписываться одновременно; такое же решение нужно принять и для ответов), используется механизм согласования опций, криптографических алгоритмов (RSA или Digital Signature Standard [DSA] для подписи, DES или RC2 для шифрования и т.д.), и выбора сертификатов (например: “Подписывайтесь своим сертификатом Verisign”). S-HTTP поддерживает криптографию общих ключей и функцию цифровой подписи и обеспечивает конфиденциальность данных.

SOCKS

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

SOCKS был разработан много лет назад Дейвом Кобласом из компании SGI, и сегодня этот код можно бесплатно получить через Интернет. С момента первого выпуска этот код пережил несколько крупных модификаций, но каждая из них распространялась совершенно бесплатно. 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 (этот процесс обычно называется “SOCKS-ификацией” приложения). К счастью, большинство обычных сетевых приложений (Telnet, FTP, finger, whois) уже SOCKS-ифицированы, и многие производители включают поддержку SOCKS в свои коммерческие приложения. Кроме того, SOCKS V.5 включает эти процедуры в свою общую библиотеку: на некоторых системах (например, на машинах Solaris) можно автоматически SOCKS-ифицировать приложение, поставив общую библиотеку SOCKS перед “shared libc” в вашей строке поиска библиотек (переменная среды LD__LIBRARY_PATH в системах Solaris).

IPSec

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

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

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

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

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

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

  • алгоритм шифрования;
  • алгоритм аутентификации;
  • общий ключ сессии;
  • срок действия ключа.

Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:  



Сейчас читают про: