Logo GenDocs.ru

Поиск по сайту:  

Загрузка...

Ответы для экзамена - Информационная безопасность - файл 1.doc


Ответы для экзамена - Информационная безопасность
скачать (974 kb.)

Доступные файлы (1):

1.doc974kb.16.11.2011 00:46скачать

1.doc

1   ...   4   5   6   7   8   9   10   11   12
^

2.3.3. Механизмы вирусной атаки


Все вирусы различаются способом размещения, методом распространения в вычислительной среде, способом активизации, характером наносимого ущерба [5, 7, 8, 28, 30, 64 и др.].

Компьютерный вирус может находиться в операционной среде, где он сцепляется с программами, расположенными в системной части накопителя на гибком или жестком магнитном диске. Его внутренние поля могут располагаться в структуре файлов типа EXE – в области между таблицей адресов и загрузочным модулем программы или в свободной памяти файла за программой, в библиотеках компиляторов (наиболее эффективный вариант размещения вируса, поскольку он при этом может автоматически внедряться в любую программу, составляемую компилятором), в сетевом драйвере, в “плохих” или специальных секторах на диске, в постоянном запоминающем устройстве (ПЗУ) в качестве программно-технической закладки.

Компьютерный вирус может распространяться транзитно или резидентно. В первом случае, находясь в оперативном запоминающем устройстве (ОЗУ) компьютера, вирус дописывает себя в другие программы, хранимые на диске. Во втором случае вирус, введенный в память ЭВМ (в часть, где находятся программы ОС), при обращениях к ОС “заражает” программы (диски), вызываемые на выполнение.

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

Среди вирусов есть такие, которые не создают серьезных помех работе средств вычислительной техники, вызывают нарушения, поддающиеся исправлению, и производят необратимые изменения и разрушения. Наибольшую опасность представляют вирусы, имеющие деструктивную функцию. Эти вирусы наносят следующие виды ущерба вычислительным средствам: 1) изменение данных в файлах, изменение назначенного магнитного диска, в результате чего данные записываются на другой диск. Например, данные могут быть направлены на квазидиск в ОС и потеряны после выключения ЭВМ; 2) уничтожение специальных файлов, содержащих выполняемые программы и данные; 3) уничтожение информации форматированием диска или отдельных треков на нем; 4) уничтожение каталога диска; 5) уничтожение (выключение) программ, постоянно находящихся в ОС; 6) нарушение работоспособности ОС, при которой она не воспринимает внешних воздействий и требует полной загрузки.

57. Протоколы

58. Протокол РРР РАР

PPP (Point-to-Point Protocol) РАР (Password Authentication Protocol) не является сильным аутентификационным методом. РАР аутентифицирует только вызывающего оператора, а пароли пересылаются по каналу, который считается уже "защищенным". Таким образом, этот метод не дает защиты от использования чужих паролей и неоднократных попыток подбора пароля. Частота и количество неудачных попыток входа в сеть контролируются на уровне вызывающего оператора.

^ 59. Протокол РРР CHAP

CHAP (Challenge Handshake Authentication Protocol) используется для периодической аутентификации центрального компьютера или конечного пользователя с помощью согласования по трем параметрам. Аутентификация происходит в момент установления связи, но может повторяться и после ее установления.
На рисунке 1 показан процесс аутентификации CHAP. Маршрутизатор и сервер доступа используют общий секретный ключ "trustme".


Рисунок 1. Аутентификация РРР CHAP

Маршрутизатор отделения пытается провести аутентификацию сервера сетевого доступа (NAS) или "аутентификатора". CHAP обеспечивает безопасность сети, требуя от операторов обмена "текстовым секретом". Этот секрет никогда не передается по каналу связи. По завершении этапа установления связи аутентификатор передает вызывающей машине запрос, который состоит из аутентификатора (ID), случайного числа и имени центрального компьютера (для местного устройства) или имени пользователя (для удаленного устройства). Вызывающая машина проводит вычисления с помощью односторонней хэш-функции. Аутентификатор, случайное число и общий "текстовый секрет" один за другим подаются на вход хэш-функции. После этого вызывающая машина отправляет серверу ответ, который состоит из хэша и имени центрального компьютера или имени пользователя удаленного устройства. По получении ответа аутентификатор проверяет проставленное в ответе имя и выполняет те же вычисления. Затем результат этих вычислений сравнивается с величиной, проставленной в ответе. Если эти величины совпадают, результат аутентификации считается положительным, система выдает соответствующее уведомление, и LCP устанавливает связь. Секретные пароли на местном и удаленном устройстве должны быть идентичны. Поскольку "текстовый секрет" никогда не передается по каналам связи, никто не может подслушать его с помощью каких-либо устройств и использовать для нелегального входа в систему. Пока сервер не получит адекватный ответ, удаленное устройство не сможет подключиться к местному устройству.

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

^ 60. Протокол РРР ЕАР

РРР ЕАР (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+.


62. RADIUS

Протокол RADIUS (Remote Authentication in Dial-In User Service)) был разработан компанией 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 и Secure Shell Protocol (SSH), которые обеспечивают безопасную передачу данных между клиентом и сервером. Оба протокола разработаны рабочей группой IETF по безопасности транспортного уровня (Transport Layer Security – TLS). Безопасный протокол передачи гипертекста (S-HTTP) предоставляет надежный механизм web-транзакций, однако в настоящее время наиболее популярным средством является SSL. Средство SOCKS является рамочной структурой, позволяющей приложениям клиент/сервер в доменах TCP и UDP удобно и безопасно пользоваться услугами сетевого межсетевого экрана. Протокол безопасности IP (IPSec) представляет собой набор стандартов поддержки целостности и конфиденциальности данных на сетевом уровне (в сетях IP). X.509 – это стандарт безопасности и аутентификации, который поддерживает структуры безопасности электронного информационного транспорта. Он определяет структуру данных цифрового сертификата и решает вопросы обращения общих ключей. Х.509 является важнейшим компонентом инфраструктуры общих ключей (PKI).

63. SSL

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

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

  • Защищенность связи. После первоначального квитирования связи применяются средства шифрования и определяется секретный ключ. Для шифрования данных используются средства симметричной криптографии (например, DES, 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 сертификат.


64. 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) и т.д.;

  • сочетание компрессии с шифрованием. На этом уровне такое сочетание оказывается гораздо более эффективным, чем на уровне пакетов.

65. 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 поддерживает криптографию общих ключей и функцию цифровой подписи и обеспечивает конфиденциальность данных.

66. 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).

67. IPSec

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

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

  • RFC 2401 (Security Architecture for the Internet Protocol) – Архитектура защиты для протокола IP.

  • RFC 2402 (IP Authentication header) – Аутентификационный заголовок IP.

  • RFC 2403 (The Use of HMAC-MD5-96 within ESP and АН) – Использование алгоритма хэширования MD-5 для создания аутентификационного заголовка.

  • RFC 2404 (The Use of HMAC-SHA-1-96 within ESP and АН) – Использование алгоритма хэширования SHA-1 для создания аутентификационного заголовка.

  • RFC 2405 (The ESP DES-CBC Cipher Algorithm With Explicit TV) – Использование алгоритма шифрования DES.

  • RFC 2406 (IP Encapsulating Security Payload (ESP)) – Шифрование данных.

  • RFC 2407 (The Internet IP Security Domain of Interpretation for ISAKMP) – Область применения протокола управления ключами.

  • RFC 2408 (Internet Security Association and Key Management Protocol (ISAKMP)) – Управление ключами и аутентификаторами защищенных соединений.

  • RFC 2409 (The Internet Key Exchange (IKE)) – Обмен ключами.

  • RFC 2410 (The NULL Encryption Algorithm and Its Use With IPsec) – Нулевой алгоритм шифрования и его использование.

  • RFC 2411 (IP Security Document Roadmap) – Дальнейшее развитие стандарта.

  • RFC 2412 (The OAKLEY Key Determination Protocol) – Проверка аутентичности ключа.

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

Протокол 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 включает:

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

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

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

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

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



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



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



Заметим, что вставка заголовка АН расширяет пакет, и поэтому для данного пакета может потребоваться фрагментация, которая производится после заголовка АН для исходящих пакетов и перед ним для входящих пакетов.

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

1   ...   4   5   6   7   8   9   10   11   12



Скачать файл (974 kb.)

Поиск по сайту:  

© gendocs.ru
При копировании укажите ссылку.
обратиться к администрации