The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Организация доступа удаленных пользователей по VPN на сервер NetBSD (vpn netbsd ipsec radius cisco racoon)


<< Предыдущая ИНДЕКС Правка src / Печать Следующая >>
Ключевые слова: vpn, netbsd, ipsec, radius, cisco, racoon,  (найти похожие документы)
From: Михаил Сгибнев <mixa(@).dreamcatcher.ru> Date: 2006-09-13 11:32:22 Subject: Организация доступа удаленных пользователей по VPN на сервер NetBSD
Перевод: Сгибнев Михаил

Программное обеспечение

Ядро

В этом документе подразумевается, что используется:

Пользовательское окружение

В этой статье используются следущие версии програмного обеспечения(setkey(8), racoon(8), racoonctl(8) и libipsec): :

Удаленный доступ через VPN

Вводная

Многие организации имеют сервер удаленного доступа (RAS), для соединения пользователей с помощью телефонной сети общего пользования (POTS).

С учетом быстрого развития DSL-подключений, значение модемного соединения уменьшается, но потребность в защищенных соединениях остается. Здесь нам на помощь приходит VPN.

Авторизация пользователя VPN может организовываться несколькими способами: Использование группового пароля не обеспечивает должной безопасности, сертификаты x509 наиболее защищенный вариант, но достаточно сложны в настройке. Если вы хотите рассмотреть эти варианты, то обратитесь к IPsec FAQ. логин и пароль обеспечивают средний уровень защиты, хотя тут есть опасность при использовании этих данных для доступа к другим службам (pop, ftp...), которые можно проcлушать.

В этой статье мы рассмотрим доступ только через логин/пароль.

Соображения безопасности

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

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

Возможные решения

Итак, мы хотим авторизовывать пользователя по имени/паролю и подтверждать подлинность шлюза, используя сертификат на стороне шлюза. Решений имеется не так много. Это OpenVPN, решение, базирующееся на SSL и IPsec, который мы и возьмем за основу.

Доступ удаленных пользователей через IPsec

1 фаза аутентификации IPsec

Первой фазой IPSec является IPsec Key Exchange (IKE) (обмен ключами) и выполняется демоном IKE, в NetBSD больше известным как racoon(8). Эта фаза предназначена для подтверждения подлинности удаленных концов соединения и установки ключей, использующихся во второй фазе. Вторая фаза применяется при смене ключей, которыми шифруется трафик, и может происходить несколько раз за сессию. ПЕрвая фаза может быть организована двумя способами - предопределенными (pre-shared) ключами и сертификатами. Это не совсем нас устраивает по следующим причинам:

Xauth

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

Hybrid auth

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

Уровень защиты IPsec + Xauth + Hybrid auth соответствует использованию SSH с аутентификацией по паролю.

ISAKMP mode config

Проблему аутентификации мы решили, используя IPsec + Xauth + Hybrid auth. Для большего удобства, нам необходимо сделать автоматическую конфигурацию удаленной машины. Режим конфигурации ISAKMP - это очередное расширение IKE, дающее возможность VPN шлюзу установить сетевую конфигурацию для машины отдаленного пользователя: внутренний IP адрес, адрес сервера DNS, имя домена, и так далее.

NAT Traversal

Так как удаленный пользователь может быть скрыт за Network Address Translator (NAT), встает проблема применения IPsec. При шифрации трафика IPsec использует протокол 4 уровня, известный как Encapsulated Security Payload (ESP). В отличие от TCP или UDP, ESP не имеет номера порта и не может корректно проходить через NAT.

В RFC 3947 и 3948 описывается метод инкапсуляции ESP в UDP и расширения IKE для управления NAT между конечными точками IPSec. Инкапсуляция и расширения больше известны как NAT Traversal (NAT-T).

NAT-T защищена US патентом.

Фрагментация IKE и ESP

Большинство удаленных пользователей, в конечном итоге, будет соединяться через xDSL-модемы. Такие модемы достаточно часто обрывают связь под большой нагрузкой UDP-пакетами, так как производители почему-то полагают, что UDP используется только для DNS-запросов и отбрасывают большие или фрагментированные запросы. А как мы помним, ESP поверх UDP как раз и использует большие UDP пакеты. Для решения этой проблемы, мы будем использовать IKE фрагментацию, еще одно расширение IKE, позволяющее фрагментировать большие пакеты. Проблема больших пакетов решается путем фрагментации IP перед инкапсуляцией в ESP, то есть вместо frag(IP/UDP/ESP/IP) получается IP/UDP/ESP/frag(IP), поэтому устройства между оконечными точками не фидят никаких фрагментированных пакетов.

Dead Peer Detection

Последняя проблема: удаленное соединение может быть не постоянным, время от времени обрываясь. Встроенный механизм IPsec должен вызывать время от времени вторую фазу IKE для повторной передачи ключей и при неудачной попытке обрывать сессию. Этот механизм не очень удобен. Для регулярной проверки соединения используется расширение IKE, называемое Dead Peer Detection (DPD). DPD способно проверять доступность крайних точек с кратностью в несколько секунд.

Настройка шлюза VPN

Конфигурация ядра

Сперва необходимо сконфигурировать и установить ядро со следующими опциями:

Маршрутизация пакетов

Необходимо разрешить перенаправление пакетов IPv4: Для задания этой опции в период начальной загрузки, добавьте стору в /etc/sysctl.conf:

Создание сертификатов

Если OpenSSL не был сконфигурирован у вас ранее, то давайте просто скопируем образцово-показательный файл конфигурации: Затем создадим частный ключ и используем его в создании запроса на подпись сертификата (CSR): Посылаем CSR, vpngw.csr в центр авторизации (CA) на подпись. Вы получите обратно сертификат x509, который мы назовем vpngw.crt.

Если самостоятельно хотите подписать свои сертификаты, выполните следующие шаги для создания частного ключа CA, сертификата и подписывания CSR: Храните ключи в тайне, поскольку ваше соединение не будет безопасным при их компрометации. Давайте передадим удаленным пользователям сертификат ca.crt центра авторизации (CA) и будем двигаться дальше.

Конфигурирование racoon(8)

Вот пример файла конфигурации /etc/racoon/racoon.conf:

Проблемы фрагментации

В разделе mode_cfg определяется конфигурация, посылаемая VPN шлюзом клиенту, использующему ISAKMP. В настоящее время поддерживается только IPv4. Здесь определяется пул адресов, выделяемых VPN-клиентам, через параметры network4 и pool_size. auth_source указывает на метод проверки пользователей, возможными значениями являются system, когда авторизация происходит из системной базы пользователей, pam, когда используется Pluggable Authentication Module (PAM) (будет задействован /etc/pam.d/racoon) и radius для проверки пользователей через RADIUS. . После редактирования и сохранения /etc/racoon/racoon.conf, запускаем racoon(8): Для запуска его во время начальной загрузки, добавляем следущую строку в /etc/rc.conf: В приведенной конфигурации имеется параметр esp_frag, который указывает на использование ESP фрагментации, для того, чтобы избежать появления пакетов, больших, чем 552 байт. Это достаточно маленькое значение для работы на любых xDSL модемах, но в тоже время, чем больше esp_frag, тем выше скорость передачи.

Используя фрагментацию ESP можно обмениваться через туннель IP пакетами любого размера. Но, есть специфика при работе с TCP, так как могут появиться проблемы с Path Maximum Transmission Unit (PMTU). Решение состоит в фиксации Maximum Segment Size (MSS). Сделать это можно внеся следущюю строку в /etc/ipnat.conf: Загружаем конфигурацию: Для активации правила в период начальной загрузки внесем в /etc/rc.conf следущее: Обратите внимание, что система не будет загружаться с ipfilter=YES, если файл /etc/ipf.conf отсутствует. Вы можете создать пустой файл, если не нуждаетесь в правилах фильтрации.

Взаимодействие с системами сетевой защиты

В описанном нами решении клиент должен послать UDP пакеты на порт 500 и принимать с порта 4500 VPN шлюза. Первые пакеты обмениваются между 500 портами, а затем NAT-T перемещает обмен на порт 4500. Для работы VPN необходимо соответствующим образом скорректировать правила на межсетевом экране.

Шлюз VPN и RADIUS

RADIUS может использоваться для проверки имени пользователя, назначения IP адреса и ведения аккаунтинга. Приведем пример секции mode_cfg для /etc/racoon/racoon.conf, показывающий работу с RADIUS: Дополнительно, необходимо создать файл /etc/radius.conf, который будет содержать адрес сервера RADIUS и пароль на доступ к нему. Для обеспечения безопасности этот файл должен принадлежать пользователю root и права доступа 0600. Вот пример radius.conf(5):

VPN клиенты

Cisco VPN client

Представленный выше VPN шлюз совместим с Cisco VPN Client, сконфигурированном на групповой режим (тоже самое, что и Hybrid authentication). Требуемые имя группы и групповой пароль игнорируются racoon(8), но на безопасность соединения не влияют.

Не забудьте направить IPsec через UDP и задействовать NAT-T.

racoon(8) в качестве клиента: пример конфигурации

racoon(8) можно использовать в качестве клиента. Для этого надо иметь сертификат CA в /etc/openssl/certs/ca.crt и нижеследующую конфигурацию в /etc/racoon/racoon.conf: Скрипты phase1-up.sh и phase1-down.sh вызываются после установления и завершения IKE phase 1, то есть во время подключения к VPN и отключения от него. Они отвечают за установку правил IPsec Security Policies (SP), IP адрес и маршруты. Обычно хватает типовых сценариев, но вы можете отредактировать их для своих нужд. Запускаем racoon(8): При необходимости, добавляем racoon=YES в /etc/rc.conf.

Создание и разрыв VPN соединения

Для создания и разрыва соединения используется racoonctl(8). Имя пользователя указывается с помощью опции -u, пароль вводится в рамках соединения: В этом примере вместо IP адресов может использоваться DNS имя. Обратите внимание, что если по каким-либо причинам таблица маршрутизации или Security Policy Database (SPD) будут искажены, то DNS работать не будет. Если такая ситуация возникла, то исправить ее можно следующим образом: Любой, имеющий права чтения/записи в сокет racoon(8) по имени /var/racoon/racoon.sock, может запускать и останавливать VPN соединение. Права доступа к сокету можно задать с помощью adminsock в секции listen файла /etc/racoon/racoon.conf.

Сохранение пароля Xauth

Если вы не хотите печатать каждый раз пароль Xauth, вы можете сохранить кго в файле предустановленных ключей Pre-Shared Key (PSK). Добавьте в секцию remote файла /etc/racoon/racoon.conf: Затем в файл /etc/racoon/psk.txt добавьте имя пользователя и пароль: Теперь, выполнив нижеследующую команду, вы создадите соединение, не вводя пароль:

<< Предыдущая ИНДЕКС Правка src / Печать Следующая >>

Обсуждение [ RSS ]
  • 1, Аноним (1), 07:22, 17/07/2013 [ответить]  
  • +/
    кто-нибудь такое реализовывал на фре? поделитесь опытом.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2021 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру