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

Перевод: Сгибнев Михаил

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

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

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

Вводная
Соображения безопасности
Возможные решения

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

1 фаза аутентификации IPsec
Xauth
Hybrid auth
ISAKMP mode config
NAT Traversal
Фрагментация IKE и ESP
Dead Peer Detection

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

Конфигурация ядра
Маршрутизация пакетов
Создание сертификатов
Конфигурирование racoon(8)
Проблемы фрагментации
Взаимодействие с системами сетевой защиты
Шлюз VPN и RADIUS

VPN клиенты

Cisco VPN client
racoon(8) в качестве клиента: пример конфигурации
Создание и разрыв VPN соединения
Сохранение пароля Xauth

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

Ядро

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

NetBSD-current начиная с мая 2005 года
NetBSD-3.0_BETA начиная с мая 2005 года

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

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

NetBSD-current начиная с мая 2005 года
NetBSD-3.0_BETA начиная с мая 2005 года
Любой релиз NetBSD с установленным из системы пакетов ipsec-tools 0.6.beta2

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

Вводная

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

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

Авторизация пользователя VPN может организовываться несколькими способами:

Групповой пароль (каждый пользователь имеет отдельный пароль)
Логин и пароль
Сертификат x509

Использование группового пароля не обеспечивает должной безопасности, сертификаты 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, позволяющее организовать асимметричную аутентификацию. При использовании этого метода, в ходе первой фазы шлюз подстверждает свою подлинность с использованием сертификата, а клиент нет. Итак, в этом случае, после прохождения первой фазы мы имеем такую ситуацию:

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

После этого шага может последовать авторизация 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

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

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


options INET
options GATEWAY
options PFIL_HOOKS
options IPSEC
options IPSEC_ESP
options IPSEC_NAT_T

pseudo-device   ipfilter

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

Необходимо разрешить перенаправление пакетов IPv4:


# sysctl -w net.inet.ip.forwarding=1

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


net.inet.ip.forwarding=1

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

Если OpenSSL не был сконфигурирован у вас ранее, то давайте просто скопируем образцово-показательный файл конфигурации:


# cp /usr/share/examples/openssl/openssl.cnf /etc/openssl/

Затем создадим частный ключ и используем его в создании запроса на подпись сертификата (CSR):


# cd /etc/openssl
# umask 077
# openssl genrsa > certs/vpngw.key
# umask 022
# openssl req -new -key certs/vpngw.key -out certs/vpngw.csr

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

Если самостоятельно хотите подписать свои сертификаты, выполните следующие шаги для создания частного ключа CA, сертификата и подписывания CSR:


# cd /etc/openssl
# mkdir -p demoCA/newcerts
# touch demoCA/index.txt
# echo "00" > demoCA/serial
# umask 077
# openssl genrsa > certs/ca.key
# umask 022
# openssl req -days 3650 -x509 -key certs/ca.key -new > certs/ca.crt
# openssl ca -in certs/vpngw.csr -keyfile certs/ca.key -cert certs/ca.crt -out certs/vpngw.crt

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

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

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


path certificate "/etc/openssl/certs";

listen {
        adminsock disabled;
}

remote anonymous {
        exchange_mode aggressive;
        certificate_type x509 "vpngw.crt" "vpngw.key";
        my_identifier asn1dn;
        proposal_check claim;
        generate_policy on;		# automatically generate IPsec policies
	dpd_delay 20;			# DPD poll every 20 seconds
        nat_traversal force;		# always use NAT-T
        ike_frag on;			# use IKE fragmentation
        esp_frag 552;			# use ESP fragmentation at 552 bytes
        proposal {
                encryption_algorithm aes;
                hash_algorithm sha1;
                authentication_method hybrid_rsa_server;
                dh_group 2;
        }
}
mode_cfg {
        network4 10.99.99.1;		# 1st address of VPN IPv4 pool
        pool_size 253;			# size of the VPN IP pool: 253 addresses
        auth_source system;		# validate logins against /etc/passwd
        dns4 10.0.12.1;			# IPv4 DNS server
        wins4 10.0.12.1;		# IPv4 WINS server
        banner "/etc/racoon/motd";	# Banner message for clients
	pfs_group 2;
}

sainfo anonymous {
	pfs_group 2;
        lifetime time 1 hour;
        encryption_algorithm aes;
        authentication_algorithm hmac_sha1;
        compression_algorithm deflate;
}

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

В разделе 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):


# racoon

Для запуска его во время начальной загрузки, добавляем следущую строку в /etc/rc.conf:


racoon=YES

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

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


map ex0 10.99.99.0/24 -> 0/0 mssclamp 552

Загружаем конфигурацию:


# ipf -E; ipnat -f /etc/ipnat.conf

Для активации правила в период начальной загрузки внесем в /etc/rc.conf следущее:


ipfilter=YES
ipnat=YES

Обратите внимание, что система не будет загружаться с 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:


mode_cfg {
	pool_size 253;			# IPv4 pool size
	auth_source radius;		# login validated against RADIUS
	conf_source radius;		# IPv4 address obtained by RADIUS
	accounting radius;		# RADIUS accounting
        dns4 10.0.12.1;			# IPv4 DNS server
        wins4 10.0.12.1;		# IPv4 WINS server
        banner "/etc/racoon/motd";	# Banner message for clients
	pfs_group 2;
}

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


auth radius.example.net MyDirtySecret
acct radius.example.net MyDirtySecret

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:


path certificate "/etc/openssl/certs";
path pre_shared_key "/etc/racoon/psk.txt";

listen {
	# socket used for communication between racoon and racoonctl
        adminsock "/var/racoon/racoon.sock" "root" "operator" 0660;
}

# Here is the address of the VPN gateway
remote 192.0.2.50 {
        exchange_mode aggressive;
        ca_type x509 "ca.crt";
        proposal_check obey;
        mode_cfg on;		# accept config through ISAKMP mode config
	dpd_delay 20;
        nat_traversal force;
        ike_frag on;
        esp_frag 552;
        script "/etc/racoon/phase1-up.sh" phase1_up;
        script "/etc/racoon/phase1-down.sh" phase1_down;
        passive off;
        proposal {
                encryption_algorithm aes;
                hash_algorithm sha1;
                authentication_method hybrid_rsa_client;
                dh_group 2;
       }
}


sainfo anonymous {
        lifetime time 1 hour;
        encryption_algorithm aes;
        authentication_algorithm hmac_sha1;
        compression_algorithm deflate ;
}

Скрипты phase1-up.sh и phase1-down.sh вызываются после установления и завершения IKE phase 1, то есть во время подключения к VPN и отключения от него. Они отвечают за установку правил IPsec Security Policies (SP), IP адрес и маршруты. Обычно хватает типовых сценариев, но вы можете отредактировать их для своих нужд.


# cp /usr/share/examples/ipsec-tools/roadwarrior/client/*.sh /etc/racoon/

Запускаем racoon(8):


# racoon

При необходимости, добавляем racoon=YES в /etc/rc.conf.

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

Для создания и разрыва соединения используется racoonctl(8). Имя пользователя указывается с помощью опции -u, пароль вводится в рамках соединения:


$ racoonctl vc -u username 192.0.2.50
Pasword: password
Bound to address 10.99.99.3
==========================================================
                     Flying pigs LTD

 Welcome to our internal network, remote user.
==========================================================
$ racoonctl vd 192.0.2.50
VPN connection terminated

В этом примере вместо IP адресов может использоваться DNS имя. Обратите внимание, что если по каким-либо причинам таблица маршрутизации или Security Policy Database (SPD) будут искажены, то DNS работать не будет. Если такая ситуация возникла, то исправить ее можно следующим образом:


# setkey -F
# setkey -FP
# route flush
# route add default your_default_gateway

Любой, имеющий права чтения/записи в сокет racoon(8) по имени /var/racoon/racoon.sock, может запускать и останавливать VPN соединение. Права доступа к сокету можно задать с помощью adminsock в секции listen файла /etc/racoon/racoon.conf.

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

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


xauth_login "username";

Затем в файл /etc/racoon/psk.txt добавьте имя пользователя и пароль:


username	password

Теперь, выполнив нижеследующую команду, вы создадите соединение, не вводя пароль:


$ racoonctl vc 192.0.2.50