Перевод: Сгибнев Михаил
Программное обеспечение
- Ядро
- Пользовательское окружение
Удаленный доступ через 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) и будем двигаться дальше.
Вот пример файла конфигурации /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