Налаштування взаємодії за протоколом IPSec між ОС Linux на основі сервера доступу racoon і ОС Windows XP/Windows – 2000

З використанням сертифікатів X.509 і протоколу обміну ключами ISAKMP

IPSec

Види VPN на основі IPSec.

Технологія VPN IPSec на даний момент є украй затребуваною із-за своєї доступності, а так само переваг, які вона надає. Серед яких можна виділити наступні ключові особливості для підприємств з декількома відділеннями [1]:

1) Централізований контроль і управління мережі.

2) Єдиний простір у мережі, що дозволяє використовувати такі загальні ресурси мережі, як файл сервери, бази даних і що не маловажно єдину АТС.

3) Безпечна передача голосу відео та даних між видаленими підключеннями.

4) Ефективне використання робочого часу системного адміністратора.

Побудова VPN розпочинається з постановки завдання, найважливішими аспектами є кількість абонентів в кожному відділенні (включаючи устаткування IP телефонії), майбутню топологію мережі, необхідність резервування зв'язку, канали зв'язку підведені до усіх відділень. Усі ці відомості потрібні для вибору устаткування і типу підключення

При цьому залежно від бюджету і вибору топології та устаткування допускається використання наступних технологій :

- IPSec Dynamic Multipoint VPN (DMVPN) – Zero touch provisioning, dynamic mesh VPN tunnels, технологія, яка дозволяє одночасно об'єднувати декілька роутерів, при цьому роутери спілкуються між собою.

- GRE/IPSec з Dynamic Routing Leverage краща маршрутизація у бізнесі і максимальний контроль та гнучкість.

- V3PN кращий в класі QoS з IPSec VPNs для мультисервісної високоякісної передачі, голосу без флуктуацій, відео та високопріоритетних даних.

- IPSec EasyVPN використовується для видаленого доступу користувачів до мережі з будь-якого місця.

Технологія IKE/IPSec представлена набором відкритих міжнародних стандартів (RFC 2401 - 2412, 2451). Стандарти визначають архітектуру системи безпеки (RFC 2401 «Security Architecture for Internet Protocol») і специфікації основних протоколів.

Сфера застосування – передача секретних даних через мережі загального користування або радіоканал між робочою станцією Windows і сервером Linux; між серверами Windows і Linux, і тому подібне (транспортний режим IPSec). Основний упор зроблений на взаємодію сервера і робочої станції з динамічною IP -адресою.

Використання автентифікації з відкритим ключем (сертифікатів X.509) забезпечує вищу безпеку, ніж використання секретного ключа (pre - shared key) або статичних політик шифрування. За умови дотримання належних запобіжних заходів при поводженні із закритим ключем ЦС (Центру сертифікації), що видало клієнтський сертифікат (обмеження доступу, важко підбираний пароль, і тому подібне), сертифікат X.509 на сучаному етапі вважається неможливим підробити. Також, теоретично його неможливо вкрасти з клієнтської машини, оскільки при експорті сертифікату його закритий ключ не експортується.

Для генерації сертифікатів може використовуватися як ЦС на Windows, так і ЦС на Linux (за допомогою пакета OpenSSL, передбачається, що він встановлений у вашій системі). Процес генерації сертифікатів в ЦС Windows розглядати не будемо, обмежимося описом процесу для OpenSSL.

Хід роботи

2.1. Створення сертифікатів

Якщо кореневий сертифікат ЦС ще не створений, його потрібно створити. Існує багато різних способів генерації пари сертифікату і закритого ключа. Один із способів.

Спочатку генерується закритий ключ для майбутнього кореневого сертифікату:

openssl genrsa – des3 – out ca.key 1024;

des3 – означає, що ключ буде зашифрований за алгоритмом Triple – DES;

ca.key – ім'я файла, де буде збережений ключ, що вийшов;

1024 – довжина ключа у бітах, не рекомендується встановлювати її більше цього значення, інакше можуть бути проблеми з деякими реалізаціями SSL.

Після закінчення генерації ключа, вас попросять ввести пароль. Пам'ятайте, що від довжини і якості пароля залежить, кінець кінцем, стійкість усіх сертифікатів, які будуть видані під цим кореневим сертифікатом. Не забувайте також, що якщо ви забудете пароль, його неможливо буде відновити, і що, не знаючи пароля, ви не зможете видавати нові сертифікати. Фактично, це означає, що ваш ЦС стане непридатний для використання, і вам треба буде створювати його наново, а також видати наново усі клієнтські сертифікати.

Потім створюється кореневий сертифікат ЦС. Кореневий сертифікат буде самопідписаним, тому що він знаходиться вище за усіх у створюваній ієрархії:

openssl req - new - x509 - days 730 - key ca.key - out ca.crt

730 – ця кількість днів від поточного дня (в даному випадку 2 роки); впродовж цього терміну сертифікат вважатиметься діючим. Можливо, для кореневого сертифікату є сенс поставити термін більше, скажімо, 5 або 10 років.

ca.key – ім'я файла із закритим ключем, створеним на попередньому кроці;

ca.crt – ім'я файла, в який буде записаний створений кореневий сертифікат ЦС.

В процесі створення сертифікату вам ставитимуть питання про інформацію, яка буде вказана в створеному сертифікаті. Обов'язковою є тільки відповідь на Common Name, де має сенс вказати назву вашого ЦС або щось в цьому роді, наприклад "Student ODAC Ltd Root CA". В той же час, краще заповнити усі пропоновані поля.

Тепер у вас є пара з кореневого сертифікату ЦС і його закритого ключа, і можна створити сертифікати для сервера і клієнтів.

Розпочнемо з сервера. Генеруємо закритий ключ:

openssl genrsa -out ipsec -server.key 1024

Ключ буде записаний у файл ipsec.server.key.

Генеруємо запит на сертифікат:

openssl req -new -key ipsec -server.key -out ipsec -server.csr

На цьому етапі вам знову запропонують заповнити інформаційні поля сертифікату. У полі Common Name слід вказати FQDN вашого сервера (щось подібне до myserver.mydomain.dom).

І нарешті, видаємо сертифікат і підписуємо його закритим ключем кореневого ЦС:

openssl x509 -req -days 365 -in ipsec - server.csr -CA ca.crt -CAkey \

ca.key –CA createserial -out ipsec - server.crt

Вас попросять ввести пароль до закритого ключа ЦС. Сертифікат буде виданий на 365 днів (можете це змінити). Ключ – CA createserial потрібний для того, щоб OpenSSL вів облік видаваним сертифікатам у своїй внутрішній базі. В принципі, цей ключ можна опустити. Сертифікат буде збережений у файл ipsec - server.crt. Файл запиту на сертифікат ipsec - server.csr можна видалити, швидше за все, він більше вам не знадобиться.

Так само генеруємо сертифікат для клієнта:

openssl genrsa - out ipsec - client.key 1024

openssl req -new -key ipsec -client.key -out ipsec -client.csr

(у полі Common Name слід вказати FQDN комп'ютера клієнта, або його ім'я)

openssl x509 -req -days 365 -in ipsec -client.csr -CA ca.crt -CAkey \

ca.key -CAcreateserial -out ipsec -client.crt

Додатковий крок - перетворення сертифікату і закритого ключа в єдиний файл формату PKCS#12:

openssl pkcs12 -export -inkey ipsec -client.key -certfile ca.crt -in \

ipsec -client.crt -out ipsec -client.p12

Вас попросять ввести пароль, який знадобиться згодом при установці цього сертифікату на комп'ютер Windows.

Тепер треба настроїти комп'ютери сервера і клієнта. Розпочнемо з сервера.

2.2. Налаштування сервера

Передбачається, що в ядрі Linux вже включені опції IPSec і IPSEC_ESP. На сервері має бути встановлений один з сервісів, що забезпечують роботу ISAKMP, протоколу обміну секретними ключами. У колекції портів є два порти найбільш поширених реалізацій: isakmpd і racoon [2]. У цій версії статті розглядається тільки сервіс racoon.

Переходимо у відповідний каталог дерева портів, компілюємо і встановлюємо його:

cd /usr/ports/security/racoon

make

make install

Конфігураційні файли racoon будуть встановлені в каталог /usr/local/etc/racoon. Переходимо туди, і редагуємо конфігураційний файл:

cd /usr/local/etc/racoon

cp racoon.conf.dist racoon.conf

vi racoon.conf

# racoon.conf.in,

path include "/usr/local/etc/racoon" ;

#include "remote.conf" ;

# search this file for pre_shared_key with various ID key.

#path pre_shared_key "/usr/local/etc/racoon/psk.txt" ;

# racoon will look for certificate file in the directory

# if the certificate/certificate request payload is received.

path certificate "/usr/local/etc/racoon/cert" ; # путь, де знаходиться сертификат

# "log" specifies logging level. It is followed by either "notify", "debug"

# or "debug2".

log debug4; # вмикаємо дебаг пакетів

#log notify;

padding # параметри формування пакетів.

{

maximum_length 20; # максимум довжина pad пакетів.

randomize off; # змінювати випадково довжину.

strict_check off; # вимикаємо пряму перевірку.

exclusive_tail off; # не виключати останній октет.

}

# опис мережних параметрів

listen

{

#isakmp ::1 [7000]; # який порт для isakmp

isakmp 192.168.0.120 [500]; # який порт для isakmp

#admin [7002]; # адміністративний порт для kmpstat.

#strict_address; # необхідно, щоб усі адреси були ідентифіковані.

}

# Specification of default various timer.

timer # часові параметри.

{

# These value can be changed per remote node.

counter 5; # максимум посилок.

interval 20 sec; # максимум інтервал повторної посилки.

persend 1; # кількість пакетів за одну посилку.

# timer for waiting to complete each phase.

phase1 30 sec; # таймер першої фази

phase2 15 sec; # таймер другої фази

}

remote anonymous # у випадку з'єднання клієнтів з динамічними ip адресами.

# Для першої фази.

{

exchange_mode main, aggressive; # режим першої фази: у першу

# застосовується основний режим, у інших випадках агресивний.

doi ipsec_doi; # застосовувається ipsec описаний у RFC 2407.

situation identity_only; # перевірка ідентичності.

#my_identifier address; # адрес локальної сторони з'єднання.

#my_identifier user_fqdn "sakane@kame.net";

#my_identifier asn1dn; # ідентифікатор сервера, що відправляється

#видаленому хосту, буде узятий з поля Subject сертифікату.

#peers_identifier user_fqdn "sakane@kame.net";

#peers_identifier asn1dn; # ідентифікатор видаленої сторони буде узятий з

#поля Subject сертифікату.

#verify_identifier off; # не перевіряти відповідність ідентифікатора

#видаленого хоста та ідентифікатора, що використовується

# в полі ID payload.

#verify_identifier on; # перевіряти відповідність ідентифікатора

#видаленого хоста та ідентифікатора, що використовується в полі ID payload.

certificate_type x509 "ipsec - server.crt" "ipsec - server.key"; # файл

# сертифіката сервера "ipsec - server.crt" та ключ "ipsec - server.key".

peers_certfile "ipsec - client.crt"; # файл сертифіката клієнта

# "ipsec - client.crt".

passive on; # ніколи не ініціювати сесію з боку сервера.

generate_policy on; # генерувати політику безпеки для з'єднання.

nonce_size 16; # кількість біт використовувані лише один раз.

lifetime time 60 min; # sec, min, hour # час “життя” з'єднання до переідентифікаціі першої фази.

initial_contact on; # ініціювати контакт.

#support_mip6 on; # застосувати ipv6

proposal_check obey; # obey, strict or claim # запропонований режим

# перевірки

proposal {

encryption_algorithm 3des; # використання алгоритму шифрування

# 3des. Можливо застосувати des, 3des, blowfish, cast128, aes, camellia.

hash_algorithm sha1; # використання хеш-алгоритму шифрування

# sha1. Можливо застосувати md5, sha1, sha256, sha384, sha512.

authentication_method rsasig ; # використання методу автентифікації

# шифрування rsa. Можливо застосувати pre_shared_key,

# ssapi_krb, hybrid_rsa_server, hybrid_rsa_client, xauth_rsa_server,

# xauth_rsa_client, xauth_psk_server or xauth_psk_client.

dh_group 2 ; # алгоритм Діффи-Хелмена 1 - modp768, 2 - modp1024,

# 5 - modp1536, 14 - modp2048, 15 - modp3072, 16 - modp4096, 17 - modp6144,

# 18 - modp8192.

}

}

sainfo anonymous # параметри другої фази.

{

pfs_group 1; # описання групи.

lifetime time 30 sec; # час “життя” 20 сек до переідентифікаціі для другої

# фази.

encryption_algorithm 3des, des ; # використання алгоритмів шифрування

# 3des, des.

authentication_algorithm hmac_sha1, hmac_md5; # використання методів

# автентифікації hmac з sha1, hmac з md5

compression_algorithm deflate ; # використання алгоритму компресії без

# втрат deflate.

}

Пояснення:

- шлях до файла psk.txt закоментований, оскільки pre - shared keys не використовується;

- доданий шлях до каталога з сертифікатами usr/local/etc/racoon/cert (створимо його пізніше);

- включений максимальний рівень налагоджувальної інформації, записаної в syslog (log debug4 ), це може знадобитися при налаштуванні;

- вказано, на якій адресі слухати запити ISAKMP (isakmp 192.168.0.120 [500];), якщо цей параметр закоментувати (#), racoon слухатиме на усіх адресах;

- початок секції <<remote anonymous>> - в секції описуються параметри для випадку, коли клієнт підключається з динамічної (невідомої заздалегідь) IP -адреси

- вказано, що в першій фазі встановлення зв'язку повинен використовуватися основний режим (exchange_mode main, aggressive;), може бути також закоментовано, якщо racoon не виступатиме в ролі ініціатора з'єднання;

- <<generate_policy on;>> - автоматично створювати політикові IPSec. Ми вимушені це робити, оскільки умовилися, що у клієнта динамічна IP -адреса, яку ми не знаємо заздалегідь, і відповідно, не можемо заздалегідь встановити потрібну політику.

Важлива примітка до останнього пункту (man racoon.conf):

"Note that inappropriate policy might be installed into the responder's SPD by the initiator. So that other communication might fail if such policies installed due to some policy mismatches between the initiator and the responder".

На жаль, це спостерігається і на практиці (наприклад, якщо впродовж терміну життя політики сталося відключення і повторне підключення Windows - клієнта до провайдера, або якщо на клієнтові був перезапущений сервіс IPSec). Єдиним виходом у такому разі видається завдання меншого часу життю політики. На ще більший жаль, Windows не дозволяє встановити її менш ніж 300 секунд. Це серйозний недолік, але альтернативи в даному випадку (клієнт з динамічною IP - адресою) немає.

Рядки, що залишилися, відносяться до переважних алгоритмів шифрування, автентифікації і перевірки цілісності даних ESP.

Зберігаємо файл, що вийшов, створюємо каталог /usr/local/etc/racoon/cert, і копіюємо в нього:

- файл сертифікату сервера (ipsec - server.crt);

- файл із закритим ключем сертифікату (ipsec - server.key);

- файл з сертифікатом клієнта (ipsec - client.crt).

Про всяк випадок, виставляємо права доступу 0400 (chmod 400 ім'я_файла) для цих файлів, і перевіряємо, що їх власником вказана root група wheel (chown root ім'я_файла).

Можна запустити racoon в режимі демона (наприклад, командою racoon - f /etc/racoon/racoon.conf), і перейти до налаштування Windows.

Запустити tcpdump або Wireshark для захоплення пакетів. Встановити з'єднання за протоколом IPSec, пропинговати ip адрес сервера або клієнта. Закрити з'єднання за протоколом IPSec. Зупинити tcpdump або Wireshark. Підкресліть пакети, що відносяться до з’єднання IPSec.