„Проектиране на корпоративна vpn мрежа
Изтегляне 2.17 Mb.
|
| Aggressive Mode
Целта на Aggressive Mode е същата, както на Main Mode с тази разлика, че той завършва транзакцията за два пъти по-малко време от Main Mode. Въпреки, че Aggressive Mode е по-бързият от двата режима, разходите се изразяват в невъзможността за договаряне на различни опции. Поради обстоятелството, че повечето payload-и се изпращат в първите две съобщения, не съществуват механизми за селекция или потвърждаване на отделни параметри. Например, публичният ключ на Diffie-Hellman се изпраща в същото съобщение, в което се изпраща и SA payload-ът. Aggressive Mode не е предназначен за защита на идентичността, което се постига в Main Mode чрез криптиране на ID payload-а. Aggressive Mode не криптира ID payload-и и поради тази причина информацията е на публично разположение. Aggressive Mode притежава няколко ограничения, но притежава също така и много предимства. На първо място, наблюдава се по-малък обмен на съобщения, който се отразява върху по-малката натовареност на мрежата и по-бързия отговор. Aggressive Mode изпраща голяма част от необходимата информация за установяването на IKE SA в първите съобщения, които включват ID payload. Като не се предоставя защита на идентичността, ID payload може да бъде изпратен в чист вид. Съдържащата се информация позволява на отговарящия да провери паролата, която се основава на характеристики, различни от IP адреса на инициатора (т.е. потребителското име). В случаи, при които IP адресът на инициатора не е постоянен, като при отдалечен достъп на потребителя, това осигурява средства за позволяване на удостоверяването. Поради тази причинаAggressive Modе се използва предимно за отдалечен достъп, за разлика от Main Mode. Излагането на ID payload-а представлява заплаха за защитата на сесията. За да се намали излагането на потребителското име в ID payload-а – използвайки типа ID_USER_FQDN, съществува идентификационен тип, наречен ID_KEY_ID. ID_KEY_ID, съгласно определението в IP Security Domain of Interpretation (RFC 2407), представлява неразбираема поредица от байтове, които се използват за предаване на специфична за производителя информация, необходима за определяне коя предварително споделена тайна ще се използва. Отделна част от информацията може да бъде получена от пакета на клиента за последваща идентификация на индивида или на системата, инициираща VPN. Тъй като тази информация е крайно неопределена, на атакуващия ще са му необходими много повече стъпки, за да извлече информация с някаква стойност. Aggressive Mode - удостоверяване с предварително споделен ключ Aggressive Mode - удостоверяване със сертификати Използването на Aggressive Mode е ограничено в сравнение с Main Mode, но може да бъде много полезно при решения за отдалечен достъп, където IP адресът на инициатора не е известен и формата за удостоверяване е чрез предварително споделена тайна. Фаза 2 SA, създадена по време на Фаза 1, се използва за защита ISAKMP съобщенията от Фаза 2, които служат за създаване на множество IPSec SA. Операциите във втората фаза са подобни на обмяната на съобщения и на режимите от Фаза 1 с тази разлика, че на удостоверяването се отдава по-малко значение, като се приема, че съобщенията се обменят по удостоверена IKE SA. За създаване на SA за IPSec във Фаза 2 се използват два основни режима. SA се изграждат и имплементират чрез използване на протоколите за сигурност ESP и AH. Начините за имплементиране на протоколите за сигурност, дали в тунелен или транспортен режим, зависи от изискванията на VPN и политиката, дефинирана от администратора. Първата фаза от IKE ISAKMP се използва за създаване на една SA, която да позволи на по-нататъшната комуникация да бъде защитена. Фаза 2 от IKE използва структурата на съобщенията на ISAKMP, за да предостави ключовете и характеристиките за конкретна IPSec VPN. Quick Mode Quick Mode се използва само във Фаза 2 и не съществува във Фаза 1, защото всички предавани данни трябва да бъдат под защитата на IKE SA. SKEYID_a, генериран в първата фаза и свързан с основния SKEYID, се използва за удостоверяване на всички съобщения в Quick Mode, а SKEYID_e се използва, за да ги криптира. Ако първата фаза бъде преодоляна, Фаза 2 ще бъде напълно изложена на атаки. Quick Mode отговаря за имплементирането на пакета за сигурност в първите съобщения на Фаза 1 без значение от използвания режим. ISAKMP хедърът и съпътстващия го SA payload се използват за договаряне на детайлите на защитата - transformset. Договорените атрибути се използват не само във Фаза 1, но и в Quick Mode. По тази причина избраните удостоверяващи и криптиращи алгоритми ще бъдат използвани за Фаза 2. Съобщенията в Quick Mode са защитени чрез ключове, дефинирани във Фаза 1, но се използват за дефиниране на ключове за защита на протоколите за сигурност на IPSec. Quick Mode осигурява механизъм за създаване на SA за защита на специфична за политиката информация в IPSec. Например съгласно политиката на IPSec трафикът на определен тип може да бъде защитен с 3DES криптиране и SHA удостоверяване, докато на всички други данни е предоставено само DES криптиране. За да се изпълнят тези изисквания, трябва да бъдат създадени множество SA. Поради тази причина Quick Mode ще договаря нови SA от името на IPSec политиката. В предишния пример трябва да бъдат създадени минимум четири SA, всяка от които трябва да има една входяща и една изходяща SA. За да се гарантира, че установените SA са валидни и новите ключове са защитени, отново се използват „nonces”, за да може страната да се увери в съществуването и активността на комуникацията. Поради обстоятелството, че в Quick Mode могат да се изпълняват едновременно множество обмени на съобщения, ID на съобщението в ISAKMP хедъра се използва за мултиплексиране на съобщенията в Quick Mode. Всяко ID на ISAKMP хедъра се използва за идентифициране на асоциираното договаряне в Quick Mode, а “бисквитките” на хедъра се използват за идентифициране на състоянието на съобщенията. Предполага се, че ID на страната в Quick Mode е IP адресът на страните във Фаза 1. Това е очевидно предположение, защото всички съобщения в Quick Mode са защитени от ключове, създадени между тези две страни. IKE обаче не притежава толкова ограничения и предлага на клиента ID payload-и, които не са нищодруго освен незадължителни ID payload-и, предавани между страните. ID payload-ите не служат за предоставяне на разширена удостоверяваща информация, както FQDM във Фаза 1. ID-тата на клиента се използват за осигуряване на информация, използвана от SPD и SAD в IPSec. Тази възможност може да бъде използвана за подобряване на филтриращите способности и приложението на пакетите за сигурност, дефинирани от политиката на шлюза за сигурност. Селектор информация се предава във формата на ID payload на клиента в същото съобщение, което съдържа SA payload-и . Чрез комбиниране на SA предложенията със селектор информацията, се постига прилагане на политиката на комуникация. Отговарящият може да прегледа информацията в своята собственa SPD и да провери дали SА е договорено в подходяща и одобрена форма на комуникация, азирана на конфигурираната политика. Ако SPD тестовете за проверка са успешни и заявката за комуникация е валидна, когато е отнесена към политиката, ID payload-ите на съобщението и приетото предложение трябва да бъдат предоставени на SAD. ледователно SAD и SPD ще гарантират, че идентифицираният от ID на съобщението трафик ще преминава само по конфигурирана SA и ще позволят само специфичен трафик, дефиниран от селекторите, идентифицирани в ID payload-а. Едновременно с възможността да се използват ID payload-и на клиента, страните имат възможност да използват и PFS. Ако това се осъществява в съответствие с изискванията на политиката, публичните стойности на Diffie-Hellman трябва да бъдат разменени. Основни обмени На схемата е показан пример за обмяна на съобщения в Quick Mode. Важно е да се отбележи, че всички съобщения са криптирани и удостоверени чрез използване съответно на SKEYID_e и SKEYID_a. Същестуват няколко идентификатора, асоциирани с HASH payload-ите. Всяко съобщение съдържа различни характеристики, които да бъдат включени в хеша (HASH) и които зависят от това коя опция е избрана за използване. Пример за необходимостта от различно съдържание на хешовете (HASH) е имплементацията на PFS и включването в съобщението на KE. Така също, ако трябва да бъде създадена повече от една SA, може да бъде добавен SA payload. Следователно за всеки SA payload ще бъдат създадени две IPSec SA, които са базирани на характеристиките, договорени в оригиналните SA payload-и в Quick Mode. Обяснението на различните HASH payload-и е следното (опциите са показани със знака “( )”). HASH(1)—prf ( SKEYID_a, M-ID | SA offer | Nonce_I | (KE) | (CID_I) | (CID_r)). Съдържанието на HASH(1) е точно такова, каквото е и в съобщението. Необходимо е само да се постави HASH(1) в хеша на пълното съобщение. HASH(2)—prf ( SKEYID_a, M-ID | Nonce_I | SA offer | Nonce_r | (KE) | (CID_I) | (CID_r)). Подобно на HASH(1), HASH(2) покрива цялото съдържание на съобщението, само че е включено „nonce” на инициатора. HASH(3)–prf ( SKEYID_a, 0 | M-ID | Nonce_I | Nonce_r). Третият тип HASH включва само „nonces” и ID на съобщението. Това е така, за да се гарантира съществуването на комуникацията преди започването на IPSec трафика. Без доказателство за активното участие на страната, атакуващият може да използва предварително получени пакети, идентифицирани като Quick Mode, и да приложи повторна атака (replay atack), консумирайки ресурси от отговарящия и накрая постигайки атака “отказ от услуга” (denial-of-service attack). “M-ID” е ID на съобщението от ISAKMP хедъра, което идентифицира обмените на съобщения в Quick Мode за специфична SA. Както във Фаза 1, KE е публичният ключ на Diffie-Hellman, използван между страните за създаване на симетричен ключ за криптиране в протоколите за сигурност на IPSec. CID_I и CID_r са ID payload-и на клиента. Важно е да се отбележи използването на SKEYID_a в HASH за удостоверяване на данните. Формиране на ключовете за IPSec SKEYID_d се създава във Фаза 1, за да се използва за генериране на ключове за криптиране на операциите във Фаза 2, които не са част от IKE. Ключовете за IPSec SA се състоят от няколко компонента от първите две фази. В Quick Mode се договаря SA, която се състои от две SA – по една за всяка посока. Те имат уникален SPI, а в резултат на това, и уникален ключ за всяка SA. Информацията, използвана за създаване на ключове за IPSec, е зависима от опциите в първоначалната размяна на Quick Mode. Ако е конфигурирано използването на PFS, между двете страни трябва да се споделят стойностите на KE, поради което липсата или използването на публичен ключ на Diffie-Hellman ще определи и ключовете за криптиране, използвани в IPSec, както е посочено във формулите: KEY = prf (SKEYID_d, protocol | SPI | Nonce_i | Nonce_r) – без използване на PFS. KEY = prf (SKEYID_d, DH_key(QM) | protocol | SPI | Nonce_i | Nonce_r) – с използване на PFS. Ако PFS е активиран, двете страни ще трябва да изчислят нова стойност на Diffie-Hellman ключовете за операциите в Quick Mode. По време на ISKAMP инициаторът предлага едно или няколко предложения чрез съпътстващи transformsets. Отговарящият трябва да избере само едно от предложенията. Затова към всяко предложение съществува поле SPI и protocol, което позволява на ключа да бъде свързан със SA, за която е създаден. Всяка страна определя SPI за своята входяща SA. Като резултат се договарят две SA и се създават ключове за всяка страна, които са необходими за работата на процесите за сигурност за двете SA. Инициаторът на Quick Mode може да бъде всяка една от страните. Не е задължително това да е инициаторът на режима от Фаза 1. Други обмени в Quick Mode Всички описани до този момент режими и обмени се отнасят до идентификацията, удостоверяването и договарянето на протоколи за сигурност за защитата на IKE съобщения и IPSec комуникации. След стартирането на IPSec операции и завършването на операции в Quick Mode, IKE SA повече не се използва за предаване на още допълнителни данни. След установяване на IKE SA и завършване на Quick Mode много малък трафик използва SA. Изтегляне 2.17 Mb. Сподели с приятели:
|