Доклад
Тема
«Технологии безопасности, применяемые компанией Cisco»
По курсу «Защита информации»
Руководитель Батура В.П.
Выполнил студент факультета ЭКТ
Группы ЭКТ-28
Искандаров Т.Р.
Москва 2018
Оглавление
Технологии безопасности данных. 3
Технологии аутентификации. 4
S/Key. 4
Аутентификация с помощью аппаратных средств (Token Password Authentication). 6
Аутентификация PPP. 7
Протокол PPP PAP. 8
Протокол PPP CHAP. 8
Протокол PPP EAP. 10
TACACS+. 12
RADIUS. 14
Технологии целостности и конфиденциальности данных. 16
SSL. 17
SSH.. 17
S-HTTP. 19
SOCKS. 19
IPSec. 21
X.509. 25
Технологии удаленного доступа к виртуальным частным сетям.. 29
L2F. 30
PPTP. 30
L2TP. 30
Технологии безопасности данных
Существует множество технологий безопасности данных, и все они предлагают решения для важнейших компонентов политики в области защиты данных: аутентификации, поддержания целостности данных и активной проверки. Определим аутентификацию как аутентификацию пользователя или конечного устройства (клиента, сервера, коммутатора, маршрутизатора, межсетевого экрана и т.д.) и его местоположения с последующей авторизацией пользователей и конечных устройств. Целостность данных включает такие области как безопасность сетевой инфраструктуры, безопасность периметра и конфиденциальность данных. Активная проверка помогает удостовериться в том, что установленная политика в области безопасности выдерживается на практике, и отследить все аномальные случаи и попытки несанкционированного доступа. Далее опишем технологии безопасности, которые часто применяются для аутентификации и поддержания целостности данных в сети, и продукты компании Cisco, которые уже поддерживают или должны в будущем поддерживать эти технологии. В первую очередь, ставим задачу показать область применения каждой из этих технологий, а потому будем вынуждены опускать некоторые глубокие технические особенности. Все эти технологии уже стандартизированы IETF, либо находятся в процессе стандартизации, поэтому для получения самых последних данных и технических деталей можно обратиться на web-страницу IETF по адресу: https://www.ietf.org. Например, про систему одноразовых паролей S/Key более подробно можно узнать тут https://tools.ietf.org/html/rfc1760 и тут https://tools.ietf.org/html/rfc2289#page-4-19 в приложении D.
Технологии аутентификации
Здесь опишем основные технологии, которые используются для аутентификации центрального компьютера, конечного пользователя или и того, и другого. Первым шагом на пути аутентификации было использование паролей, но для поддержания высокого уровня безопасности пароли приходится часто менять. Методы использования одноразовых паролей применяются по-прежнему широко. Среди них можно упомянуть методы аутентификации по протоколу S/Key или при помощи специальных аппаратных средств (token password authentication). Механизм аутентификации по протоколу Point-to-Point Protocol (PPP) часто применяется в среде модемного доступа и включает использование протоколов Password Authentication Protocol (PAP), Challenge Handshake Protocol (CHAP) и Extensible Authentication Protocol (EAP). Протокол EAP дает возможность более гибкого использования существующих и только появляющихся технологий аутентификации в каналах PPP, TACACS+ и Remote Access Dial-In User Service (RADIUS) — это протоколы, которые поддерживают масштабируемые решения в области аутентификации.
S/Key
Система одноразовых паролей S/Key, определенная в RFC 1760, представляет собой систему генерирования одноразовых паролей на основе стандартов MD4 и MD5. Она предназначена для борьбы с так называемыми «повторными атаками», когда хакер подслушивает канал, выделяет из трафика аутентификатор пользователя и его пароль и в дальнейшем использует их для несанкционированного доступа. Система S/Key основана на технологии клиент/сервер, где клиентом обычно является персональный компьютер, а сервером — сервер аутентификации. Вначале и клиента, и сервер нужно настроить на единую парольную фразу и счет итерации. Клиент начинает обмен S/Key, отправляя серверу пакет инициализации, а сервер в ответ отправляет порядковый номер и случайное число, так называемое «зерно» (seed). После этого клиент генерирует одноразовый пароль в ходе операции, состоящей из трех этапов: подготовительного этапа, этапа генерирования и функции выхода.
На подготовительном этапе клиент вводит секретную парольную фразу любой длины (рекомендуется длина более восьми знаков). Парольная фраза соединяется с «зерном», полученным от сервера в незашифрованном виде. Это несекретное «зерно» дает клиенту возможность использовать одну и ту же парольную фразу на множестве машин (с разными «зернами») и повторно использовать пароли, заменяя «зерно».
Далее, на этапе генерирования, клиент многократно использует хэш-функцию и получает 64-разрядную итоговую величину. При каждом новом использовании количество хэш-циклов уменьшается на один, создавая тем самым уникальную последовательность генерируемых паролей. Для совместимости клиента и сервера они должны использовать одну и ту же защищенную хэш-функцию.
Функция выхода воспринимает 64-разрядный одноразовый пароль и переводит его в читаемую форму. Далее этот пароль может вводиться следующими способами:
• через программу-калькулятор, которая будет включать пароль в поток данных;
• с помощью функции вырезания и сбрасывания (cut and paste);
• с помощью ручного ввода.
В случае ручного ввода одноразовый пароль превращается в последовательность из шести коротких английских слов (от одной до четырех букв каждое). Эти слова выбираются из словаря, в который входит 2048 слов. Таким образом, на одно слово приходится по 11 бит, что позволяет кодировать любые одноразовые пароли. Для совместимости систем S/Key и калькуляторов все они должны пользоваться одним и тем же словарем.
После создания одноразового пароля его нужно проверить. Для этого клиент передает одноразовый пароль на сервер, где он и проверяется. На сервере есть файл (в системе UNIX это /etc/skeykeys), в котором хранится одноразовый пароль, использованный в последнем успешном сеансе связи с каждым отдельным пользователем. Кроме того, эта запись может инициализироваться с помощью ввода первого одноразового пароля из данной последовательности с помощью команды keyinit (название этой команды в разных версиях системы может быть разным). Для проверки аутентификации система однократно пропускает полученный одноразовый пароль через защищенную хэш-функцию. Если результат этой операции совпадает с предыдущим паролем, хранящимся в файле, результат аутентификации считается положительным, а новый пароль сохраняется для дальнейшего использования. Поскольку количество хэш-циклов, которые использует клиент, постоянно сокращается, в какой-то момент пользователю придется инициализировать систему. Это достигается с помощью команды keyinit, которая дает возможность изменить секретную парольную фразу, количество циклов итерации и «зерно».
На рисунке показано, как действует система одноразовых паролей S/Key у пользователя, который пытается подключиться через Telnet к конкретной UNIX-машине, которая одновременно является сервером S/Key.
Более подробную информацию о технологии одноразовых паролей можно получить у рабочей группы IETF, занимающейся этим вопросом (One-Time Password (OTP) Authentication Working Group). Адрес группы: https://datatracker.ietf.org/wg/otp/documents/
Аутентификация с помощью аппаратных средств (Token Password Authentication)
Аутентификация с помощью аппаратных средств работает по одной из двух альтернативных схем: по схеме запрос-ответ или по схеме аутентификации с синхронизацией по времени. В схеме запрос-ответ пользователь подключается к серверу аутентификации, который в свою очередь предлагает ввести персональный аутентификационный номер (PIN) или пользовательский аутентификатор (user ID). Пользователь передает PIN или user ID на сервер, который затем делает «запрос» (передает случайно число, которое появляется на экране пользователя). Пользователь вводит это число в специальное аппаратное устройство, похожее на кредитную карточку, где число запроса шифруется с помощью пользовательского шифровального ключа. Результат шифрования отображается на экране. Пользователь отправляет этот результат на сервер аутентификации. В то время как пользователь подсчитывает этот результат, сервер аутентификации рассчитывает этот же результат самостоятельно, используя для этого базу данных, где хранятся все пользовательские ключи. Получив ответ от пользователя, сервер сравнивает его с результатом собственных вычислений. Если оба результата совпадают, пользователь получает доступ к сети. Если результаты оказываются разными, доступ к сети не предоставляется.
При использовании схемы с синхронизацией по времени на аппаратном устройстве пользователя и на сервере работает секретный алгоритм, который через определенные синхронизированные промежутки времени генерирует идентичные пароли и заменяет старые пароли на новые. Пользователь подключается к серверу аутентификации, который запрашивает у пользователя код доступа. После этого пользователь вводит свой PIN в аппаратное карточное устройство, и в результате на экран выводится некоторая величина, которая представляет собой одноразовый пароль. Этот пароль и отправляется на сервер. Сервер сравнивает его с паролем, который был вычислен на самом сервере. Если пароли совпадают, пользователь получает доступ к сети.
Аутентификация PPP
PPP — это популярное средство инкапсуляции (упаковки), которое часто используется в глобальных сетях. В его состав входят три основных компонента:
• метод инкапсуляции дейтаграмм в последовательных каналах;
• протокол Link Control Protocol (LCP), который используется для установления, конфигурирования и тестирования связи;
• семейство протоколов Network Control Protocols (NCP) для установки и конфигурирования различных протоколов сетевого уровня.
Чтобы установить прямую связь между двумя точками по каналу PPP, каждая из этих точек должна отправить пакеты LCP для конфигурирования связи на этапе ее установления. После установления связи и, прежде чем перейти к этапу работы на протоколах сетевого уровня, протокол PPP дает (при необходимости) возможность провести аутентификацию.
По умолчанию аутентификация является необязательным этапом. На случай, если аутентификация потребуется, в момент установления связи система указывает дополнительную конфигурацию протоколов аутентификации. Эти протоколы используются, в основном, центральными компьютерами и маршрутизаторами, которые связаны с сервером PPP через коммутируемые каналы или линии телефонной связи, а возможно, и через выделенные каналы. Во время согласования на сетевом уровне сервер может выбрать опцию аутентификации центрального компьютера или маршрутизатора.
PAP и CHAP представляют собой два метода аутентификации соединения PPP, EAP — это общий протокол аутентификации PPP, который поддерживает множество аутентификационных механизмов. Аутентификация происходит после согласования LCP и до согласования IP Control Protocol (IPCP), в ходе которого происходит обмен адресами IP. Этот процесс аутентификации происходит в автоматическом режиме и не требует от пользователей ввода в компьютер каких-либо данных при подключении PPP. Часто аутентификация PAP или CHAP занимает место переговорного сценария, который отвечает на запросы о вводе сетевого имени пользователя (login) и пароля. Однако PAP используется чаще. Ниже приведём упрощенный обзор этих трех протоколов. Более подробные технические детали и самую свежую информацию можно получить в рабочей группе IETF по расширениям PPP (pppext) по адресу: https://datatracker.ietf.org/wg/pppext/documents/
Протокол PPP PAP
На рисунке показаны действия по аутентификации с использованием протокола PAP.
Маршрутизатор отделения пытается провести аутентификацию сервера сетевого доступа (NAS) или «аутентификатора». По завершении этапа установления связи маршрутизатор передает пару «аутентификатор-пароль» серверу NAS до тех пор, пока аутентификация не будет проведена или пока связь не прервется.
PAP не является сильным аутентификационным методом. PAP аутентифицирует только вызывающего оператора, а пароли пересылаются по каналу, который считается уже «защищенным». Таким образом, этот метод не дает защиты от использования чужих паролей и неоднократных попыток подбора пароля. Частота и количество неудачных попыток входа в сеть контролируются на уровне вызывающего оператора.
Ещё раз: аутентифицирует только клиент, аутентификация выполняется только один раз во время сеанса, переданную от клиента пару «ID-Password» сервер ищет в полях базы данных.
Протокол PPP CHAP
CHAP используется для периодической аутентификации центрального компьютера или конечного пользователя с помощью согласования по трем параметрам. Аутентификация происходит в момент установления связи, но может повторяться и после ее установления.
На рисунке показан процесс аутентификации CHAP.
Маршрутизатор отделения пытается провести аутентификацию сервера сетевого доступа (NAS) или «аутентификатора». CHAP обеспечивает безопасность сети, требуя от операторов обмена «текстовым секретом». Этот секрет никогда не передается по каналу связи. По завершении этапа установления связи аутентификатор передает вызывающей машине запрос, который состоит из аутентификатора (ID), случайного числа и имени центрального компьютера (для местного устройства) или имени пользователя (для удаленного устройства). Вызывающая машина проводит вычисления с помощью односторонней хэш-функции. Аутентификатор, случайное число и общий «текстовый секрет» один за другим подаются на вход хэш-функции. После этого вызывающая машина отправляет серверу ответ, который состоит из хэша и имени центрального компьютера или имени пользователя удаленного устройства. По получении ответа аутентификатор проверяет проставленное в ответе имя и выполняет те же вычисления. Затем результат этих вычислений сравнивается с величиной, проставленной в ответе. Если эти величины совпадают, результат аутентификации считается положительным, система выдает соответствующее уведомление, и LCP устанавливает связь. Секретные пароли на местном и удаленном устройстве должны быть идентичны. Поскольку сервер не получит адекватный ответ, удаленное устройство не сможет подключиться к местному устройству.
CHAP обеспечивает защиту от использования чужих паролей за счет пошаговых изменений аутентификатора и применения переменной величины запроса. Повторяющиеся запросы предназначены для ограничения времени, в течение которого система теоретически остается подверженной любой отдельной хакерской атаке. Частоту и количество неудачных попыток входа в систему контролирует аутентификатор.
Примечание. Обычно в качестве односторонней хэш-функции CHAP используется MD5, а общий секрет хранится в текстовой форме. У компании Microsoft есть свой вариант протокола CHAP (MS-CHAP), где пароль (на вызывающей машине и на аутентификаторе) хранится в зашифрованном виде. Это дает протоколу MS-CHAP некоторое преимущество: в отличие от стандартного протокола CHAP, он может пользоваться широкодоступными базами данных постоянно зашифрованных паролей.
Протокол PPP EAP
PPP EAP является общим протоколом аутентификации PPP, который поддерживает множество аутентификационных механизмов. EAP не производит выбор конкретного аутентификационного механизма на этапе контроля соединения, но откладывает этот выбор до этапа аутентификации. Этот сценарий позволяет аутентификатору запросить больше информации до определения конкретного аутентификационного механизма. Кроме того, это дает возможность использовать «внутренний» сервер, который реально запускает различные механизмы, тогда как аутентификатор PPP служит лишь для обмена аутентификационными данными.
На рисунке показано как работает PPP EAP.
Маршрутизатор отделения пытается провести аутентификацию сервера сетевого доступа (NAS) или «аутентификатора». По завершении этапа установления связи аутентификатор отправляет один или несколько запросов для аутентификации вызывающей машины. В запросе имеется поле типа запроса, где указано, что именно запрашивается. Так, например, здесь можно указать такие типы запросов, как аутентификация MD5, S/Key, аутентификация с использованием аппаратной карты для генерирования паролей и т.д. Запрос типа MD5 очень сходен с протоколом аутентификации CHAP. Обычно аутентификатор отправляет первоначальный аутентификационный запрос, за которым следует один или несколько дополнительных запросов о предоставлении аутентификационной информации. При этом первоначальный запрос не является обязательным и может опускаться в случаях, когда аутентификация обеспечивается иными способами (при связи по выделенным каналам, выделенным номерам и т. д.). В этих случаях вызывающая машина отправляет пакет ответных данных в ответ на каждый запрос. Как и пакет запроса, пакет ответных данных содержит поле, соответствующее полю типа запроса. И наконец, аутентификатор завершает процесс отправлением пакета, который свидетельствует о положительном или отрицательном результате аутентификации.
TACACS+
TACACS+ является протоколом последнего поколения из серии протоколов 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+ является разделение аутентификации, авторизации и учета (AAA — Authentication, Authorization, Accounting). Это позволяет обмениваться аутентификационными сообщениями любой длины и содержания, и, следовательно, использовать для клиентов TACACS+ любой аутентификационный механизм, в том числе PPP PAP, PPP CHAP, аппаратные карты и Kerberos. Аутентификация не является обязательной. Она рассматривается как опция, которая конфигурируется на месте. В некоторых местах она вообще не требуется, в других местах она может применяться лишь для ограниченного набора услуг.
Авторизация — это процесс определения действий, которые позволены данному пользователю. Обычно аутентификация предшествует авторизации, однако это необязательно. В запросе на авторизацию можно указать, что аутентификация пользователя не проведена (личность пользователя не доказана). В этом случае лицо, отвечающее за авторизацию, должно самостоятельно решить, допускать такого пользователя к запрашиваемым услугам или нет. Протокол TACACS+ допускает только положительную или отрицательную авторизацию, однако этот результат допускает настройку на потребности конкретного заказчика. Авторизация может проводиться на разных этапах, например, когда пользователь впервые входит в сеть и хочет открыть графический интерфейс или когда пользователь запускает PPP и пытается использовать поверх PPP протокол IP с конкретным адресом IP. В этих случаях «демон» сервера TACACS+ может разрешить предоставление услуг, но наложить ограничения по времени или потребовать список доступа IP для канала PPP.
Учет обычно следует за аутентификацией и авторизацией. Учет представляет собой запись действий пользователя. В система TACACS+ учет может выполнять две задачи. Во-первых, он может использоваться для учета использованных услуг (например, для выставления счетов). Во-вторых, его можно использовать в целях безопасности. Для этого TACACS+ поддерживает три типа учетных записей. Записи «старт» указывают, что услуга должна быть запущена. Записи «стоп» говорят о том, что услуга только что окончилась. Записи «обновление» (update) являются промежуточными и указывают на то, что услуга все еще предоставляется. Учетные записи TACACS+ содержат всю информацию, которая используется в ходе авторизации, а также другие данные, такие как время начала и окончания (если это необходимо) и данные об использовании ресурсов.
Транзакции между клиентом TACACS+ и сервером TACACS+ идентифицируются с помощью общего «секрета», который никогда не передается по каналам связи. Обычно этот секрет вручную устанавливается на сервере и на клиенте. TACACS+ можно настроить на шифрование всего трафика, который передается между клиентом TACACS+ и демоном сервера TACACS+.
На рисунке показано взаимодействие между пользователем, с одной стороны, и клиентом и сервером TACACS+, с другой.
В ходе аутентификации TACACS+ используются пакеты трех типов: START, CONTINUE и REPLY. START и CONTINUE всегда отправляются клиентом, а REAPLY всегда отправляется сервером.
Аутентификация начинается, когда клиент отправляет серверу сообщение START. Сообщение START описывает тип будущей аутентификации и может содержать имя пользователя и некоторые аутентификационные данные. Пакет START отправляется только в качестве первого сообщения аутентификационной сессии TACACS+ или сразу же после повторного запуска этой сессии. (Повторный запуск может проводиться по просьбе сервера, которая содержится в пакете REAPLY.) Пакет START всегда имеет порядковый номер, равный единице.
В ответ на пакет START сервер отправляет пакет REAPLY. Сообщение REAPLY указывает, завершилась ли аутентификация или ее следует продолжить. Если пакет REAPLY требует продолжения аутентификации, он также указывает, какую дополнительную информацию ему нужно предоставить. Клиент собирает эту информацию и отправляет ее серверу в сообщении CONTINUE.
По завершении аутентификации клиент может начать процесс авторизации (если она требуется). Сессия авторизации состоит из двух сообщений: сообщения REQUEST (запрос) и следующего за ним сообщения RESPONSE (ответ). Сообщение REQUEST содержит фиксированное количество полей, которые описывают пользователя или процесс, и переменный набор аргументов, которые описывают услуги и опции, требующие авторизации.
На рисунке показан процесс аутентификации TACACS+
На рисунке показан процесс авторизации TACACS+
RADIUS
Протокол RADIUS был разработан компанией Livingston Enterprises, Inc. в качестве протокола аутентификации серверного доступа и учета. В июне 1996 года проектный вариант протокола RADIUS был представлен на рассмотрение IETF. В настоящее время спецификация RADIUS (RFC 2058) и стандарт учета RADIUS (RFC 2059) (текущие версии RFC 2865 и RFC 2866) предложены для утверждения в качестве общепринятых стандартов.
Связь между NAS и сервером RADIUS основана на UDP. В целом считается, что протокол RADIUS не имеет отношения к подключению. Все вопросы, связанные с доступностью сервера, повторной передачей данных и отключениями по истечении времени ожидания, контролируются устройствами, работающими под управлением протокола RADIUS, но не самим протоколом передачи.
Протокол RADIUS основан на технологии клиент/сервер. Клиентом RADIUS обычно является NAS, а сервером RADIUS считается «демон», работающий на машине UNIX или NT. Клиент передает пользовательскую информацию на определенные серверы RADIUS, а затем действует в соответствии с полученными от сервера инструкциями. Серверы RADIUS принимают запросы пользователей на подключение, проводят аутентификацию пользователей, а затем отправляют всю конфигурационную информацию, которая необходима клиенту для обслуживания пользователя. Для других серверов RADIUS или аутентификационных серверов других типов сервер RADIUS может выступать в роли клиента-посредника (proxy).
На рисунке показано взаимодействие между пользователем с одной стороны, и клиентом и сервером RADIUS, с другой.
Сервер RADIUS может поддерживать разные методы аутентификации пользователя. Если пользователь предоставит ему свое имя и оригинальный пароль, этот сервер может поддержать PPP PAP или CHAP, UNIX login и другие механизмы аутентификации. Обычно регистрация пользователя состоит из запроса (Access Request), который поступает NAS на сервер RADIUS, и соответствующего ответа (положительного или отрицательного), который дает сервер. Пакет Access Request содержит имя пользователя, зашифрованный пароль, IP-адрес системы NAS и номер порта. Формат запроса дает возможность пользователю запросить определенный тип сессии. Например, если запрос производится в алфавитно-цифровом режиме, из этого следует, что запрашивается услуга одного типа («Service-Type = Exec-User»), но если запрос делается в пакетном режиме PPP, значит услуга должна быть другой («Service Type = Framed User» или «Framed Type = PPP»).
Когда сервер RADIUS получает от NAS запрос Access Request, он проводит поиск указанного имени пользователя в базе данных. Если в базе данных такого имени нет, то сервер загружает стандартный профиль, используемый по умолчанию, или отправляет пользователю отрицательный ответ. Этот отрицательный ответ может при необходимости сопровождаться текстом, поясняющим причины отказа.
В системе RADIUS функции аутентификации и авторизации совмещены. Если имя пользователя найдено в базе данных и если пароль указан правильно, сервер RADIUS дает положительный ответ, в котором приводится список пар атрибутов для данной сессии. Типичными параметрами этого типа являются тип услуги (shell или framed), тип протокола, адрес IP, присваиваемый пользователю (статический или динамический), список объектов доступа или статический маршрут, который необходимо добавить в таблицу маршрутизации NAS. Конфигурационная информация на сервере RADIUS определяет, какие средства следует установить на машине NAS.
На рисунке показана процедура аутентификации и авторизации RADIUS.
Учетные функции протокола RADIUS могут использоваться независимо от функций аутентификации и авторизации. Учетные функции RADIUS позволяют в начале и в конце каждой сессии отправлять данные о количестве ресурсов (то есть времени, пакетов, байтов и т. д.), использованных в ходе этой сессии. Провайдер услуг Интернет (ISP) может использовать программные средства контроля доступа и учета RADIUS для удовлетворения специальных требований безопасности и биллинга.
Транзакции между клиентом и сервером RADIUS аутентифицируются с помощью общего «секрета», который никогда не передается по сетевым каналам. Кроме того, обмен любыми пользовательскими паролями между клиентом и сервером RADIUS идет только в зашифрованном виде, что исключает подслушивание чужих паролей и последующее злоупотребление ими.
Самую свежую информацию и подробные технические детали можно получить в рабочей группе RADIUS IETF по адресу: https://datatracker.ietf.org/wg/radius/documents/