Топалов

Групі учених зі Швейцарії, Японії, Франції, Нідерландів, Німеччини і США вдалося успішно обчислюти дані, зашифровані за допомогою криптографічного ключа стандарту RSA завдовжки 768 біт. За словами дослідників, після їх роботи в якості надійної системи шифрування можна розглядати тільки RSA -ключі довжиною 1024 біта і більше. Причому, від шифрування ключем завдовжки в 1024 біт варто відмовитися в найближчі три-чотири роки.

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

DSA (Digital Signature Algorithm) – алгоритм з використанням відкритого ключа для створення електронного підпису, але не для шифрування (на відміну від RSA і схеми Эль-Гамаля). Підпис створюється таємно, але може бути публічно перевірений. Це означає, що тільки один суб'єкт може створити підпис повідомлення, але будь-хто може перевірити його коректність. Алгоритм, заснований на обчислювальній складності узяття логарифмів у кінцевих полях.

Алгоритм був запропонований Національним інститутом стандартів і технологій (США) в серпні 1991 і є запатентованим U.S. Patent 5231668 (англ.), але НИСТ зробив цей патент доступним для використання без ліцензійних відрахувань. Алгоритм разом з криптографічною хеш-функцией SHA – 1 є части-

ною DSS (Digital Signature Standard), уперше опублікованого в 1994 (документ FIPS – 186 (Federal Information Processing Standards)). Пізніше були опублікова-

ні 2 оновлених версії стандарту: FIPS 186-2 (27 січня 2000 року) і FIPS 186-

3(червень 2009).

Стандарт X.509 визначає формати даних і процедури розподілу загальних ключів за допомогою сертифікатів з цифровими підписами, які надаються сертифікаційними органами (CA). RFC 1422 створює основу для PKI на базі X.509.

У діючих стандартах визначений сертифікат X.509 версія 3 і список відгуку сертифікатів (CRL) версія 2.

Шифрований зв'язок досягається цифровим підписом довіреного CA під кожним сертифікатом. Сертифікат має обмежений термін дії, вказаний в його підписаному змісті. Оскільки користувач сертифікату може самостійно перевірити його підпис і термін дії, сертифікати можуть поширюватися через незахищені канали зв'язку і серверні системи, а також зберігатися в кеш-пам'яті незахищених призначених для користувача систем. Зміст сертифікату має бути однаковим в межах усього PKI. Нині в цій області пропонується загальний стандарт для Інтернет з використанням формату X.509 v3: номер версії, серійний номер, емітент, суб'єкт, публічний ключ суб'єкта (алгоритм, ключ), період дії, додаткові (необов'язкові) значення, алгоритм підпису сертифікату, значення підпису сертифікату.

SSL (англ. Secure Sockets Layer – рівень захищених сокетів) – криптографічний протокол, який забезпечує встановлення безпечного з'єднання між клієнтом і сервером. SSL спочатку розроблений компанією Netscape Communications. Згодом, на підставі протоколу SSL 3.0 був розроблений і прийнятий стандарт RFC, що отримав ім'я TLS.

201

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

TLS (англ. Transport Layer Security) – криптографічний протокол, що за-

безпечує захищену передачу даних між вузлами в мережі Інтернет.

TLS - протокол заснований на протоколі Netscape SSL версії 3.0 і складається з двох частин – TLS Record Protocol і TLS Handshake Protocol. Відмінності між SSL 3.0 і TLS 1.0 незначні, тому далі в тексті ті

TLS надає можливості автентифікації і безпечної передачі даних через інтернет з використанням криптографічних засобів. Часто відбувається лише автентифікація сервера, тоді як клієнт залишається не автентифікованим. Для взаємної автентифікації кожна із сторін повинна підтримувати інфраструктуру відкритого ключа (PKI), яка дозволяє захистити клієнт-серверні застосування від перехоплення повідомлень, редагування існуючих повідомлень і створення підробних.

SSL включає три основні фази:

Діалог між сторонами, метою якого є вибір алгоритму шифрування. Обмін ключами на основі криптосистем з відкритим ключем або автен-

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

2.Хід роботи

2.1.Налаштування ядра cервера на ОС Linux

Зазначимо, на цьому етапі треба бути украй обережним і уважним. Ядро повинне містити опції подані нижче. На клієнтові потрібні тільки TUN і ipv4.

У ядрі нам знадобиться наступний функціонал, витяги з конфігурації:

CONFIG_NF_NAT=m CONFIG_NF_NAT_PPTP=m CONFIG_NETFILTER=y CONFIG_TUN=m

Ну і розуміється підтримка ipv4, мережевої карти.

Якщо ці опції встановлені, то пропускаємо пункт конфігурація ядра ОС Linux і переходимо до конфігурації OpenVpn.

Збираємо і встановлюємо ядро. Можна скористатися make, make modules, make modules_install. Перезавантажуємося.

Після перезавантаження, перейдемо до установки ПО OpenVpn. cd /usr/local/src/openvpn – перехід в настановну директорію

configure – задаємо конфігурацію

202

make – збираємо – створюємо бінарні файли make install – встановлюємо ПО

2.2. Генерація ключів

Перейдемо в /еtс/openvpn/easy - rsa/. Відкриємо файл vars і перевіримо нижчеподані параметри, якщо їх немає, то впишемо:

export EASY_RSA="/etc/openvpn/easy - rsa/" #Шлях до easy - rsa.

export KEY_CONFIG='$EASY_RSA/whichopensslcnf $EASY_RSA' #Конфиг

OpenSSL

export KEY_DIR="$EASY_RSA/keys" #Каталог, в якому ми триматимемо клю-

чі.

export KEY_SIZE=1024 # Розмір ключа export CA_EXPIRE=3650 # Термін дії CA export KEY_EXPIRE=3650 # Термін дії ключа export KEY_COUNTRY="UA"

export KEY_PROVINCE="UA" export KEY_CITY="ODAC" export KEY_ORG="ODAC"

export KEY_EMAIL="[e-mail]"

Якщо були зміни, то імпортуємо зміни: source ./vars

Тепер створимо ключі, якщо вони створені і не були змінені, то цей пункт пропускаємо.

./clean - all - Очищаємо старі ключі, якщо вони були. openvpn --genkey --secret ta.key - ключ TLS - auth

./build - dh - ключ Діффі-Хеллмана.

./pkitool --initca – сертифікат автентифікації для сервера.

./pkitool --server vpsrv - сертифікат сервера.

./pkitool vpclient - сертифікат клієнта.

Усе, ключі готові.

2.3. Налаштування сервера Оpenvpn

Переходимо в /etc/openvpn/, відкриваємо openvpn.conf і перевіряємо наступні параметри, якщо якісь параметри відсутні, то змінюємо [2]:

mode server # задаємо режим – сервер; port 1194 # задаємо порт;

proto tcp # задаємо транспортний протокол; dev tun # задаємо тип пристрою;

tls - server # задаємо тип сервера;

local 192.168.0.122 # задаємо локальну адресу сервера;

server 192.168.21.0 255.255.255.0 # задаємо діапазон, що виділяється клієнтам під мережу;

203

keepalive 10 120 # встановлюємо час життя з'єднання; persist - key # використовуємо постійні ключі;

persist - tun # використовуємо постійне тунель-з'єднання; status openvpn - status.log # задаємо log файл;

client - config - dir /etc/openvpn/ccd # вказуємо директорію для клієнтських сертифікатів;

push "route 192.168.21.0 255.255.255.0" # задаємо маршрут за замовчуванням; duplicate - cn # дублюємо cn;

ca /etc/openvpn/keys/ca.crt # кореневий сертифікат verb 3 # рівень деталізації

cert /etc/openvpn/keys/vpnserver.crt # сертифікат сервера key /etc/openvpn/keys/vpnserver.key # ключ сервера

dh /etc/openvpn/keys/1.pem # ключ за Діффі-Хеллмана

Клієнтові необхідно передати файли: ca.crt

vpclient.crt

vpclient.key

І їх також записати на сервері в директорії /etc/openvpn/ccd.

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

Можливі варіанти запуску: openvpn --config /etc/openvpn.conf

openvpn --config /etc/openvpn.conf --dev tunX.

Детальніше можна подивитися за допомогою команди довідки - man openvpn або підказки параметрів - openvpn - h.

Після запуску сервера openvpn потрібно активувати захоплення пакетів за допомогою tcpdump.

Здійснити підключення клієнта openvpn з ОС Windows. Запустити команду ping на адресу сервера.

Від'єднати підключення. Зупинити захоплення пакетів.

3. Ключові питання

1.Що таке SSL ?

2.Що таке TLS ?

3.Які відмінності між TLS і SSL ?

4.Для чого застосовується стандарт X.509 ?

5.Яким алгоритмом згенерований сертифікат клієнта, сервера ОpenVPN в цій лабораторній роботі ?

6.Який алгоритм використовується для шифрування трафіка ?

7.Які пристрою tun або tap застосовуються у OpenVPN ?

204

4. Домашнє завдання

1.Вивчити формування OpenVPN тунелю. Основні можливості

OpenVPN.

2.Визначити, які основні алгоритми авторизації та шифрування застосовуються в OpenVPN.

3.З’ясувати, які основні програмні продукти будуть застосовуватися у лабораторній роботі.

4.Відповісти на ключові питання.

5. Лабораторне завдання

1.Наслідуючи хід роботи в лабораторній роботі та використовуючи довідкове керівництво [1], настроїти OpenVPN тунель на стороні з ОС Linux та з боку клієнта з ОС Windows.

2.Включити Tcpdump або Wireshark - зняти трасування встановлення з'єднання та роз'єднання OpenVPN тунелю.

3.Проаналізувати застосовані методі авторизації та шифрування.

Варіанти завдань для виконання лабораторної роботи:

1.Замість пристрою tun застосувати tap.

2.Для підвищення криптостійкості згенерувати ключі довжиною 2048 бітів.

3.Застосувати компресію даних у OpenVPN тунелі.

4.Підкреслити пакети етапу авторизації OpenVPN тунелю у аналізаторі

Tcpdump або Wireshark.

5.Пропінгувати 192.168.21.211 та знайти ці icmp пакети у аналізаторі

Tcpdump або Wireshark.

6.Замість порта 1194 застосувати 1200 у OpenVPN тунелі.

7.Встановити час життя з’єднання 360 сек.

8.Підкреслити пакети етапу роз’єднання OpenVPN тунелю в аналізаторі

Tcpdump.

6. Зміст протоколу

1.Назва роботи.

2.Мета роботи.

3.Виконане домашнє завдання.

4.Результати виконання лабораторного завдання.

5.Висновки.

Упротоколі роботи мають бути відображені основні положення та дамп пакетів тунелю.

205

7. Список посилань

1.Norbert G. Beginning OpenVPN 2.0.9 // Packt. – 2009. – 356 c.

2.http://www.openvpn.net/

206

Лабораторна робота №12

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

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

Мета роботи. Навчитися налаштовувати сервер доступу racoon на ОС Linux для з'єднання за протоколом IPSec з використанням сертифікатів X.509 і протоколу обміну ключами ISAKMP.

Ключові положення

1. 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 -адресою.

207

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

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

2. Хід роботи

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, де має сенс вказати назву вашого ЦС або щось в цьому

208

роді, наприклад "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.

209

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

cd /usr/ports/security/racoon make

make install

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

cd /usr/local/etc/racoon

cp racoon.conf.dist racoon.conf

viracoon.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;	# максимум інтервал повторної посилки.

210