все лекции

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

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

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

мевается некоторая информация, заранее известная обоим сайтам), либо могут по-

требоваться цифровые сертификаты.

VPN соединяет два конкретных объекта, образуя уникальный

канал связи между двумя абонентами.

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

В то время как пользователь имеет VPN-соединение с внутрен-

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

тернета.

Сеть VPN поддерживается отдельным приложением на

компьютере пользователя (рисунок 12.2).

Рисунок 12.2 – Конфигурация пользовательской VPN

В некоторых случаях компьютер пользователя может выступать в роли маршрутизатора (роутера) между интернетом и сетью VPN (и, следовательно,

внутренней сетью организации).

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

Самой большой проблемой безопасности при использовании VPN сотрудником является одновременное соединение с другими сайтами

интернета.

Как правило, программное обеспечение VPN на компьютере пользователя определяет, должен ли трафик передаваться через VPN, ли-

бо его необходимо отправить на какой-либо другой сайт в открытом ви-

де.

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

Рисунок 12.3 – Использование «троянского коня» для проникновения во внутреннюю

сеть организации

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

Пользователи должны проходить аутентификацию перед исполь-

зованием сетей VPN.

Так как VPN позволяет осуществлять удалённый доступ ко внут-

ренней сети организации, эта аутентификация должна быть двухфак-

торной, то есть запрашивать два аутентификационных параметра.

Одним из параметров может являться сам компьютер пользователя.

В этом случае вторым параметром должно быть нечто известное пользователю или непосредственно с ним связанное.

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

Сети с трансляцией адресов.

Еще один момент влияет на использование организацией пользовательской

VPN. Он связан с трансляцией сетевых адресов (NAT) на противо-

положном конце соединения: если ожидается, что сотрудники организации

будут пытаться использовать VPN с узлов, защищённых межсетевыми экрана-

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

ции для абонентов на концах соединения.

Следует решить вопросы, связанные с адресацией: если узловая

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

адресация не представляет какой-либо сложности.

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

На рисунке 12.4 отражена возникшая конфликтная ситуация. Здесь обе

организации используют части одного и того же частного адресного пространства (сеть 10.1.1.x).

Рисунок 12.4 – Узловая VPN вызывает конфликты, связанные с адре-

сацией

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

В данном случае каждая сторона соединения VPN должна выпол-

нять трансляцию сетевых адресов и переадресовывать системы

другой организации на их собственную схему адресации (рисунок 12.5).

Рисунок 12.5 – Узловая VPN использует NAT для предотвращения кон-

фликтов адресации

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

Управление пользовательскими VPN, главным образом, заключается в управлении пользователями и их компьютерами. При разделении сотрудников необходимо выполнять со-

ответствующие процедуры по управлению пользователями.

На компьютерах пользователей должны устанавливаться правильные версии про-

граммного обеспечения VPN и реализовываться соответствующие конфигурации. Если ком-

пьютеры принадлежат организации, это программное обеспечение является стандартным компонентом для каждого компьютера.

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

Одним из ключевых аспектов пользовательской VPN является

установка антивирусной программы на компьютере пользователя.

Этот программный пакет должен обеспечивать регулярное обновление

своих баз для противостояния вирусам и «троянским коням», проникающим на

компьютер пользователя.

УЗЛОВЫЕ ВИРТУАЛЬНЫЕ ЧАСТНЫЕ СЕТИ используются ор-

ганизациями для подключения к удаленным узлам без применения дорогостоящих

выделенных каналов или для соединения двух различных организаций,

между которыми необходима связь.

Как правило, VPN соединяет один межсетевой экран или пограничный маршрутизатор с другим аналогичным устройством (рисунок

12.6).

Чтобы инициировать соединение, один из узлов осуществля-

ет попытку передать трафик другому узлу. Вследствие этого на обоих противоположных узлах соединения VPN инициируется VPN.

Рисунок 12.6 – Межузловое соединение VPN, проходящее через интернет

Оба конечных узла определяют параметры соединения в зависимо-

сти от политик, имеющихся на узлах.

Оба сайта будут аутентифицировать друг друга посредством некоторого общего предопределенного секрета, либо с помощью сертифика-

та с открытым ключом.

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

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

На базе политики организации могут быть разработаны правила,

определяющие, каким образом удаленные сайты будут подключаться

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

Узловые VPN расширяют периметр безопасности организации, добавляя новые удалённые узлы или даже удаленные организации. Если уровень безопасности удалённого узла невелик, VPN может позво-

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

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

В случаях, когда две организации используют узловую VPN для соединения

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

ветствующим образом настроить политики на своих межсетевых экранах.

Аутентификация узловых VPN также является важным условием

для обеспечения безопасности. При установке соединения могут использо-

ваться произвольные секреты, но один и тот же общий секрет не дол-

жен использоваться для более чем одного соединения VPN.

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

Как и в случае с пользовательскими VPN, сервер VPN должен поддерживать дешифрование и шифрование VPN-трафика. Если уровень трафика высок, сервер VPN может оказаться перегруженным.

12.4 Протокол Kerberos как средство защиты соединения и дан-

ных в InterNet

Криптографические системы с симметричными ключами возможны в ограниченном числе случаев из-за проблемы статического распределения клю-

чей в InterNet.

Одним из первых защищённых протоколов обмена был протокол

Kerberos, основанный на статическом распределении ключей для ко-

нечного числа абонентов. Ориентирован, в первую очередь, на клиент-

серверную модель и обеспечивает взаимную аутентификацию – оба пользователя через сервер подтверждают личности друг друга.

Схема работы Kerberos 5 происходит следующим образом.

1 Вход пользователя в систему:

а) Пользователь вводит имя и пароль на клиентской машине.

б) Клиентская машина выполняет над паролем одностороннюю функцию (обычно хэш), и результат становится секретным клю-

чом клиента/пользователя.

2 Аутентификация клиента:

а) Клиент отсылает запрос (AS_REQ) на сервер аутентифика-

ции (СА) (рисунок 12.7) для получения аутентификационных верительных

данных и последующего их предоставления серверу выдачи билетов (TGS-

серверу – Ticket Granting Server). Также, впоследствии он будет их использовать для получения билетов без дополнительных запросов на применение секретного ключа

пользователя. Данный запрос содержит: идентификатор клиента, его метка времени и идентификатор сервера.

б) Если политика центре распределения ключей (ЦРК) требует предварительной аутентификации, то пользователь получает сообщение KRB_ERROR, в ответ на которое посылает повторный запрос, но с уже данными для установления подлинности.

в) СА проверяет, есть ли такой клиент в базе. Если есть, то назад

СА отправляет сообщение (AS_REP) включающее:

– сессионный ключ клиент/TGS, идентификатор TGS и вре-

мя жизни билета, зашифрованные секретным ключом клиента;

– для концепции, позволяющей пользователям аутентифицироваться на несколько сервисов используя свои доверительные данные только один раз, по-

лучает TGT (билет для получения билета), который включает идентификатор и сетевой адрес клиента, метку времени ЦРК, период действия билета и сесси-

онный ключ Клиент/TGS), зашифрованный секретным ключом TGS.

Если СА не предоставляет сессионный ключ, то клиент получает новое сообщение, говорящее о произошедшей ошибке.

д) Получив сообщение, клиент расшифровывает свою часть для получения сессионного ключа Клиент/TGS.

Этот сессионный ключ используется для дальнейшего обмена с сервером TGS. (Клиент не может расшифровать TGT, так как оно зашифровано секретным ключом TGS). В этот момент у пользователя достаточно данных, чтобы авторизоваться на

TGS.

Рисунок 12.7 – Аутентификация клиента

3 Авторизация клиента на TGS:

а) Для запроса сервиса клиент формирует запрос на TGS

(TGS_REQ) содержащий следующие данные (рисунок 12.8):

– TGT, полученный ранее и идентификатор сервиса;

– Аутентификатор (составленный из ID клиента и временного

штампа), зашифрованный на сессионном ключе Клиент/TGS.

б) После получения TGS_REQ, TGS извлекает из него TGT и

расшифровывает его, используя секретный ключ TGS. Это даёт ему сес-

сионный ключ Клиент/TGS. Им он расшифровывает аутентификатор. Затем он

генерирует сессионный ключ клиент/сервис и посылает ответ (TGS_REP) включающий:

– билет сервиса (который содержит ID клиента, сетевой адрес клиента, метку времени ЦРК, время действия билета и сессионный ключ Кли-

ент/сервис) зашифрованный секретным ключом сервиса;

– сессионный ключ Клиент/сервис, идентификатор сервиса и

время жизни билета, зашифрованные на сессионном ключе Client/TGS.

Рисунок 12.8 – Авторизация клиента

4 Запрос сервиса клиентом:

После получения TGS_REP, у клиента достаточно информации для авториза-