69. Базы данных безопасных ассоциаций и политик безопасности.

При установлении безопасной ассоциации две стороны договариваются о наборе параметров соединения. Эти наборы хранятся на обоих оконечных узлах защищенного канала в виде баз данных безопасных ассоциаций SAD(Security Associations Database).

Каждый узел IPSec поддерживает две базы SAD : одну для исходящего трафика, другую для входящего.

Другой тип базы данных — база данных политики безопасности SPD (Security Policy Database) — задает соответствие между IP-пакетами и правилами обработки. База SPD создается и управляется :

пользователем (подходит для хоста) или сис.админом (для шлюза) или приложением.

Записи базы SPD содержат два типа полей : поле селектора пакета и поле политики защиты пакета с данным значением селектора.

Селектор может содержать следующие признаки для выделения определенного типа трафика

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

-портов источника и назначения (TCP или UDP)

-типов протокола транспортного уровня (TCP, UDP)

-имени пользователя в формате DNS или Х.500

-имени системы в формате DNS или Х.500

Для каждого нового пакета, поступающего в защищенный канал IPSec просматривает SPD и сравнивает значения селекторов записей SPD с соответствующими полями IP-пакета. При совпадении над пакетом выполняются действия, определенные в поле политики безопасности данной записи : - передача пакета без изменения; - отбрасывание; - обработка средствами IPSec

70. Протокол socks

Разработан в 1990 году для организации посредничества при взаимодействии между клиент-серверным приложением на сеансовом уровне OSI. Обеспечивает высокое быстродействие и не зависит от вышележащих протоколов. Не привязан к протоколу ip и не зависит от ОС.

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

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

2. SOCKS-клиент соединяется с SOCKS-сервером и передает ему запрос от клиента.

3.SOCKS-сервер соединяется с запрошенным прикладным сервером.

4.Прикладной клиент и сервер взаимодействуют друг с другом по цепочке соединений, в которые SOCKS-сервер просто ретранслирует данные.

Пятая версия имеет доп. возможности.

1)SOCKS-клиент может передавать SOCKS-серверу не только айпи адрес прикладного протокола, но и его dns-имя, при этом SOCKS-сервер сам может определить айпи-адрес по dns имени, что исключает необходимость локального dns-сервера.

2)Второе отличие - поддерживается не только tcp-протокол, но и UDP, которые покрывают в совокупности почти все множество прикладных протоколов (кроме icmp).

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

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

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

Четвертый шаг - SOCKS-сервер в соответствии с выбранным методом аутентификации аутентифицирует пользователя от имени которого выступает SOCKS-клиент. ПОсле успешной аутентификации SOCKS-клиент передает SOCKS-серверу dns имя или айпи-адрес запрашиваемого прикладного сервера и SOCKS-сервер на основе своих правил разграничения доступа принимает решение об установке соединения с этим прикладным сервером.

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

Аутентификация пользователей SOCKS-сервера может основываться на сертификатах X509 или паролях. Для шифрования траффика между SOCKS-клиентом и SOCKS-сервером могут использоваться любые протоколы сеансового или более низкого модели OSI. Максимальную функциональность по криптозащите обеспечивает протокол SSL.

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

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