Курсов проект по Мрежова сигурност

на тема:

“Виртуални частни мрежи (VPN)”

Изготвили: Радослав Иванов Недков, ф.н. 43515

Владимир Петров Великов, ф.н. 43084

София, 31.01.2004г.

ВЪВЕДЕНИЕ Виртуалната частна мрежа(Virtual Private Network - VPN) е разширение на частна мрежа, която обхваща връзки през споделени или публични мрежи като Интернет. VPN ви дава възможността да изпращате данни между два компютъра през споделена или публична мрежа по начин, който наподобява свойствата на Point-to-Point частна връзка. Акта на конфигуриране и създаване на виртуална частна мрежа се нарича virtual private networking. За да наподоби point-to-point връзка, данните са инкапсулирани или обвити с обвивка, която осигурява маршрутизираща информация позволяваща на данните да прекосяват споделени или публични мрежи и да достигат своята крайна точка. За да наподобят частни връзки, изпратените данни са криптирани за по-голяма поверителност. Пакетите, които са прихванати през споделената или публична мрежа е невъзможно да бъдат декодирани без декодиращия ключ (encrypted key). Частта от връзката, в която частните данни са капсулирани е известна като тунел. Частта от връзката, в която данните са криптирани, е известна като виртуална частна мрежа.

VPN връзките позволяват на потребителите да си работят от вкъщи или на път, да се свързват по сигурен начин към отдалечен сървър, използвайки маршрутизиращата инфраструктура осигурена от публична мрежа (като Интернет). От преспективата на потребителя, VPN връзката е point-to-point връзка с потребителските компютри и сървъра на организацията. И така VPN технологията дава възможност на една корпорация да свърже отделни нейни филиали или да се свърже с компютрите на други корпорации през публични мрежи(като Интернет) като твърди, че това са едни сигурни комуникации. VPN връзките през Интернет логично работят като wide area network(WAN) връзки между обектите. И в двата случая, сигурната комуникация през мрежата се явява пред потребителя като частна комуникация – въпреки факта, че комуникацията се осъществява през публична мрежа - оттук идва и името виртуална частна мрежа. VPN технологията е проектирана към решаване на въпросите обхващащи сегашните бизнес тенденции към увеличаване на телекомуникативността, където служителите трябва да са способни да се свързват към централните ресурси и да бъдат способни да комуникират един с друг.

За да обезпечат служителите със способноста да се свързват към компютърните ресурси на организацията, без значение каде се намират, корпорацията трябва да разгърне мащабно решение за отдалечения достъп. Типично, корпорациите взимат едно от двете решения: или решението за отдел, където отдела за вътрешни информационни системи е натоварен с купуването, инсталирането и поддържането на модемите на организацията и частната мрежова инфраструктура; или те избират решението value-added network (VAN), където те плащат на външна компания да купи, инсталира и поддържа модемите и телекомуникационната инфраструктура. Нито едно от тези две решения не предоставя нужната scalability, от гледище на цената, гъвкаво управление, и търсене за връзки. Следователно, това ни навежда на мисълта да заменим модемите и частната мрежова инфраструктура с по-евтиното решение базирано на Интернет технологията, така че бизнесът да може да се концентрира върху неговите съществени задачи. Чрез Интернет решението, малко на брой Интернет връзки през доставчик на Интернет услуги(Internet service provider - ISP) и VPN сървър компютри могат да обслужват отдалечени мрежови нужди на стотици или хиляди отдалечени клиенти и офиси.

Общо използване на VPN-и Следвашите няколко секции описват повечето общи VPN конфигурации в повече детайли. Отдалечен достъп през Интернет VPNs осигурява отдалечен достъп до ресурси на организацията през публичен Интернет. Фигура 2 показва VPN връзка използвана да свърже отдалечен клиент към Интранет на организацията. Това е известно като отдалечен достъп на VPN връзка.

Фигура 2: Използване на VPN връзка да свърже отдалечен клиент към Intranet на организация. По-добре отколкото да прави отдалечени телефонни връзки до организацията или outsourced network access server(NAS), потребителят набира локален ISP.

Използвайки връзката към локален ISP, VPN клиентът създава VPN връзка между отдалечения компютър и сървъра на организацията през Интернет. Свързване на мрежи през Интернет Има два метода за използването на VPNs за свързването на локални мрежи към отдалечен обект: 1) Използвайки посветени линии за свързването на офис към LAN на

организацията. Например, по-добре от използването на скъпи, далеко-дистантни кабелни връзки между браншовия офис и корпоративния хъб, е и двата рутъра на браншовия офис и корпоративния хъб рутер да използват локална посветена електрическа мрежа и локален ISP за свързване към Интернет. VPN софтуерът използва локалните ISP връзки и Интернет за да създаде виртуална частна мрежа между рутъра на браншовия офис и корпоративния хъб рутер.

2) Използването на dial-up линия за да свърже браншовия офис към Интернет.

VPN клиентът използва връзката към локалния ISP за да създаде VPN връзка между рутъра на браншовия офис и корпоративния хъб рутер през Интернет.

Фигура 3: Използването на VPN връзка за свързването на два отдалечени обекта

И в двата случая, устройствата, които свързват браншовия офис и корпоративните офиси към Интернет, са локални. Корпоративния хъб рутер, който играе ролята на VPN сървър трябва да бъде свързан към локален ISP с посветена линия. Този VPN сървър трябва да е активен 24 часа в денонощието за идващ VPN трафик. Свързването на компютри през Intranet Данните, които се съхраняват в някои вътрешни отдели на организацията, може да бъдат толкова важни и поверителни, че тези LAN мрежи да бъдат отделени от останалите мрежи на организацията. Въпреки, че това предпазва поверителната

информация на отдела, това създава и проблеми с достъпността на тези потребители, които не са във физически контакт с отделната LAN мрежа.

Фигура 4: Използване на VPN връзка за свързване към защитена или скрита мрежа VPNs позволява на LAN-a на отдела да бъде физически свързан към мрежата на организацията, но е отделен посредством VPN сървър. VPN сървърът не изпълнява ролята на рутър между мрежата на организацията и LAN-a на отдела. Рутър щеше да свърже двете мрежи, като позволи на всеки достъп до поверителната мрежа. При използването на VPN сървър, администраторът на мрежата може да осигури, че само тези потребители на мрежата на организацията, които имат подходящи акредитивни писма могат да установят VPN връзка със сървъра и да придобият достъп до защитените ресурси на отдела. В допълнение, всички комуникации през VPN могат да бъдат криптирани за поверителност на данните. Тези потребители, които нямат подходящи акредитивни писма не могат да видят LAN-a на отдела. Основни VPN изисквания Типично, когато се разгръща отдалечено мрежово решение, е необходимо за предприятията да се улесни контролирания достъп до ресурсите и информацията на организацията. Решението трябва да позволява на отдалечен клиент да се свърже към LAN ресурсите, и решението трябва да позволява отдалечени офиси да се свързват един с друг, да споделят ресурси и информация(router-to-router връзка). В допълнение, решението трябва да осигурява цялостта и неделимостта на данните като те прекосяват Интернет. Същата грижа важи и за случая, когато поверителна информация прекосява мрежата на организацията. Затова VPN решението трябва да осигури най-малко всички от следните изисквания:

1) Автентикация на потребителя. Решението трябва да проверява идентичността на VPN клиента и да ограничава VPN достъпа само на упълномощени потребители.

2) Управление на адресите. Решението трябва да назначава VPN клиентите на адрес в Интранет и да осигурява, че използваните в Интранет адреси се съхраняват като частни.

3) Криптиране на данните. Данни трябва да бъдат пренасяни криптирани през публични мрежи.

4) Управление на ключовете. Решението трябва да генерира и обновява декриптиращи ключове за криптираните данни.

Интернет VPN решението базирано на Point-to-Point Tunneling Protocol (PPTP) или Layer Two Tunneling Protocol с Internet Protocol сигурност (L2TP/IPSec) отговаря на всички тези основни изисквания и взима предимство на обширния достъп до Интернет. Други решения, включващи IPSec tunnel mode, отговарят само на някои от тези изисквания, но остават полезни за специални ситуации.

Основи на тунелирането Тунелирането е метод на използване на мрежовата инфраструктура за трансфер на данни за една мрежа през друга мрежа. За да бъдат пренесени данните могат да бъдат рамки или пакети на друг протокол. Вместо да изпрати пакета, така както оригинално е произведен, тунелния протокол го инкапсулира в допълнителни рамки(header). Допълнителните header-и осигуряват маршрутизираща информация, така че капсулираните данни могат да прекосяват посредническите мрежи. Капсулираните пакети тогава се маршрутизират между крайните точки на тунела през мрежата. Логическият път, през който капсулираните пакети пътуват през мрежата се нарича тунел. Когато капсулираните пакети достигнат мрежата, която е нейно предназначение, пакетът се декапсулира и се предава нататък към неговото финално предназначение. Тунелирането включва целия този процес (капсулиране, предаване и декапсулация на пакетите).

Фигура 5: Тунелиране Транзитната мрежа, през която преминават пакетите, може да бъде всяка мрежа – Интернет е публична мрежа и е най-широко известния световен пример. Има много примери на тунели, които пренасят данни през мрежите на дадена организация. И докато Интернет осигурява една от най-широките и ценово-ефективните мрежи, споменаването на Интернет в този доклад може да бъде заменено с всяка публична или частна мрежа, която да играе ролята на транзитна мрежа. Технологиите за тунелиране съществуват от известно време като SNA(System Network Architecture) тунелиране през IP мрежи. Когато SNA трафикът е изпратен по

IP мрежите на организацията, SNA пакетът е капсулиран в IP и UDP header(рамка). Нови технологи за тунелиране са въведени от преди няколко години. Тези нови технологии, които ще разгледаме в този доклад, включват: • Point-to-Point Tunneling Protocol (PPTP). PPTP позволява мултипротоколовият

трафик да бъде криптиран и след това капсулиран в IP header за да бъде предаден на IP мрежата на организацията или на публична IP мрежа като Интернет.

• Layer Two Tunneling Protocol (L2TP). L2TP позволява мултипротоколовият

трафик да бъде криптиран и след това да бъде изпратен на всякаква среда, която поддържа point-to-point предаване на дейтаграмите като IP, X.25, Frame Relay или ATM.

• IPSec tunnel mode. IPSec tunnel mode позволява IP пакетите да бъдат криптирани

и след това капсулирани в IP header за да бъдат изпратени на IP мрежата на организацията или на публична IP мрежа като Интернет. IPSec tunnel mode не е препоръчителна технология за VPN отдалечен достъп, защото няма стандартиризирани методи за потребителската автентикация, назначението на IP адресите и назначението на имената на сървърите. Използването на IPSec tunnel mode за site-to-site VPN връзка е възможно с използването на компютър на който има Windows Server 2003. Tъй като IPSec tunnel mode не е представен като логически интерфейс, по който пакетите могат да бъдат препредавани и получавани, маршрутите не могат да бъдат определяни да използват IPSec tunnel и маршрутизиращите протоколи не работят на IPSec tunnels. Следователно, използването на IPSec tunnel mode е препоръчително само за VPN решение за site-to-site VPN връзка, в която единият край на тунела е third-party VPN сървър или security gateway(вход, шлюз), които не поддържа L2TP/IPSec.

VPN протоколи В тази част ще разгледаме трите типа протоколи, използвани във виртуалните частни мрежи:

• Тунелен протокол – Понякога представян като VPN протoкол, той се използва за изграждане на тунела.

• Протокол за криптиране – Понякога означаван като протокол за сигyрност, той се използва за сигурност на данните.

• Мрежов/транспортен протокол – Понякога означаван като LAN протокол, той се използва за комуникация по частна мрежа.

Тунелни протоколи Тунелният или тунелиращият протокол капсулира данните така, че хедърите на оригиналния протокол се обвиват вътре в капсулиращите хедъри. В следващите секции ше разгледаме следните тунелни протоколи:

• Point-to-Point Tunneling Protocol(PPTP)

• Layer 2 Forwarding(L2F) • Layer Two Tunneling Protocol (L2TP) • IPSec • Secure Shell(SSH) и Secure Shell2(SSH2) • Crypto IP Encapsulation протокол (CIPE)

За да бъде създаден тунела, двамата, тунелният клиент и тунелният сървър, трябва да използват един и същ тунелен протокол. Технологиите за тунелиране може да бъдат базирани на един от двата, Layer 2(слой 2) или Layer 3(слой 3), тунелен протокол. Тези слоеве съответстват на Open System Interconnection (OSI) модела. Тунелирането скрива оригиналния пакет във вътрешноста на нов пакет. За извършване на маршрутизация през тунела адресът на крайната точка на тунела се задава в хедъра на външния(новия) пакет, който се нарича хедър на капсулацията. Адресът на крайното местоназначение се намира вътре в хедъра на оригиналния пакет. Когато пакетът достигне до зададената крайна точка на тунела, хедърът на капсулацията се снема. Сега оригиналният пакет може да бъде доставен до крайното местоназначение. Тунелирането е просто термин, използван за описание на капсулацията, която представлява процесът на маршрутизация и декапсулация. Тунелите могат да бъдат изграждани на различни слоеве на стандартния мрежов модел. Следващите секции ще разгледаме как деиства тунелирането в Слой2(каналният слой на референтния OSI модел) и Слой3(мрежовия слой на референтния OSI модел). Тунелиране от Слой2 VPN мрежите често използват тунелни протоколи, които работят в каналния слой. Тези протоколи осигуряват виртуална връзка от една точка до друга. Протоколът Point-to-Point Tuneling Prtocol(PPTP) работи на това ниво. Друг тунелен протокол от каналния слой е Layer 2 Forwarding(L2F), който може да осигурява тунелиране по ATM и Frame Relay, защото не зависи от Internet Protocol(IP). За разлика от PPTP, един L2F тунел може да поддържа повече от Internetwork Operating System(IOS), използвана от маршрутизаторите на Cisco. В допълнение продуктите на Nortel и Shiva също поддържат L2F. Най-новият тунелен протокол, който работи на това ниво, е Layer 2 Tunnelig Protocol(L2TP), който комбинира елементи на PPTP и L2F. Тези протоколи са подробно разгледани по-нататък в доклада. Тунелиране от Слой3 Тунели могат да бъдат създавани в мрежовия слой и по този начин да се осигуряват IP-базирани виртуални връзки. Тези връзки работят чрез изпращане на IP пакети, капсулирани във вътрешността на специфицирани от Internet Engineering Task Force(IETF) протоколни обвивки(protocol wrappers). Обвивките използват IPSecurity(IPSec), Internet Key Exchange(IKE) и методи за автентикация и криптиране, като Message Digest 5(MD5), Data Encryption Standart(DES) и Secure Hash Algorithm(SHA).

IPSec може да бъде използван заедно с L2TP; L2TP изгражда тунел, а IPSec криптира данните. В този случай IPSec работи в транспортен режим. IPSec може също да бъде използван в тунелен режим, при който той осигурява тунела. В режим на тунелиране IPSec може да бъде конфигуриран за защита на данни или между два IP адреса, или между две IP мрежи. IPSec тунелирането от Слой 3 може да бъде използвано в случаите, когато не е подходящо използването на L2PT. IPSec може да използва един или и двата протокола: Authentication Header(AH) и Encapsulating Security Payload(ESP). В следващите секции ще разгледаме всеки протокол и ще обясним как IPSec може да взаимодейства с различни операционни системи. АН тунелен режим АН тунелният режим, използван сам по себе си, не осигурява криптиране на данните, които пътуват през тунела. Но той верифицира, че данните не са пипани. Също така той автентицира изпращача. При АН не може да бъде направена никаква промяна на адреса на източника или местоназначението от момента, в които пакетът напусне началната точка на тунела. ESP тунелен режим При ESP тунелен режим адресите на първоначалния източник и крайното местоназначение се съдържат в оригиналния (капсулиран) IP хедър. Външният хедър обикновено съдържа адресите на шлюзовете. ESP тунелът криптира данните с помощта на алгоритмите DES или 3DES. Когато се използва ESP, външният IP хедър не е защитен и неговият интегритет не е ограничен. За постигане на криптиране и автентикация, както и на интегритет на целия пакет, може да се използват заедно AH и ESP. Интероперативност на IPSec Операционната система Windows 2000 включва вградена поддръжка на IPSec. IPSec e стандарт на IETF, който работи също с Linux, Unix, Macintosh и други операционни системи, поддържащи фамилията протоколи IP. IPSec автентикацията може да бъде направена по различни методи, като предварително споделени ключове, Kerberos и сертифициращи услуги. FreeS/WAN за Linux представлява реализация на IPSec, която е с отворен сорс и е достъпна за сваляне по Интернет. Важно е да се разбере разликата между VPN мрежите, които използват L2TP за тунелиране и IPSec за криптиране, и VPN мрежите, които използват IPSec в режим на тунелиране. Една важна разлика е тази, че IPSec може да капсулира само IP пакети. L2TP може да осигури касулиране на Internet Packet Exchange(IPX) пакети и на пакети на други протоколи по IP мрежа.

Някои шлюзове не поддържат VPN мрежи, базирани на L2TP или PPTP, като в този случай за осигуряване на тунела може да бъде използван IPSec. IPSec тунелите обикновено работят от шлюз до шлюз. Point-toPoint Tuneling Protocol(PPTP) PPTP на Microsoft е установен стандарт, който реално представлява разширение на протокола за връзка PPP, който се използва за създаването на WAN връзка с отдалечен достъп. Ето как работи той:

1. PPTP kaпсулира PPP фрейма, който може да бъде IP, IPX или NetBEUI пакет, във вътрешността на Generic Routing Encapsulation(GRE) хедър. Също така се добавя IP хедър за осигуряване на IP адресите на източника и местоназначението. Адресът на източника е този на VPN клиента, а адресът на местоназначението е този на VPN сървъра.

2. Данните в оригиналната дейтаграма обикновено са криптирани, за да не може да бъдат прочетени от неоторизирани лица. VPN мрежите на Microsoft използват протокола MPPE(описан по-надолу) заедно с PPTP за

осигуряване на сигурни комуникации. Фигура 6 показва структурата на PPTP пакет, съдържащ IP-dategrama

Фигура 6: Структурата на PPTP пакет, съдържащ IP-datаgram

PPTP-Linux e клиентски софтуер, който се изпълнява на Linux и UNIX машини. Той им позволява да установяват връзка към PPTP сървъри. Софтуерът на PPTP сървъра (наречен PoPToP) е достъпен за Linux, Sun Solaris, FreeBSD и други реализации на UNIX. Той поддържа Windows клиенти, както и PPTP-linux клиенти и се разпрострянява като freeware. Macintosh клиенти могат да се свързват към Windows PPTP сървъри с помощта на софтуер на независими производители, като Network Telesystems TunnelBuilder. Layer 2 Forwarding(L2F) Cisco разработи технологията L2F през 1996 г. и включи в нея своя софтуер IOS. Като алтернатива на PPTP, L2F има възможност да използва АТМ и Frame Relay протоколи за тунелиране. Макар че PPTP изисква IP, за да работи, L2F не изисква. В допълнение L2F осигурява автентикация на крайните точки на тунела. Layer 2 Tunneling Protocol(L2TP)

Microsoft и Cisco koмбинираха възможностите на PPTP и L2F и създадоха L2TP. L2TP капсулира данните за изпращане по IP, както прави това и PPTP. Ho L2TP може също да капсулира данни за изпращане по Asynchronous Transfer Mode (АТМ), Frame Relay и X.25. По този начин той може да бъде използван за изграждане на тунел през Интернет, или може да бъде използван по конкретна WAN медия без необходимост от IP. L2TP е документиран в RFC 2661. L2TP по IP интермрежи използва UDP и серия от L2TP-съобщения за управление на тунела. L2TP използва UDP за да изпрати L2TP-капсулирания PPP фрейм като тунелирани данни. Payloads на капсулирания РРР фрейм може да бъде криптиран и/или компресиран, въпреки че реализацията на Microsoft на L2TP не използва МРРЕ за криптиране на РРР рayloads. На Фигура 7 е показана структурата на L2TP-пакет, съдържащ IP-datagram

Фигура 7: Структурата L2TP пакет, съдържащ IP-datagram Някои предимства на L2TP пред PPTP са следните:

• L2TP поддържа множество тунели между крайни точки. Това позволява създаването на отделни тунели, които осигуряват различни качества на услуга(QoS)

• L2TP поддържа компресиране на хедъри, което спестява допълнителната информация.

• L2TP, за разлика от PPTP, има възможност за тунелна автентикация. • L2TP работи по не-IP интермрежи, използващи ATM или Frame Relay

виртуални вериги В имплементацията на Microsoft на L2TP, IPSec Encapsulating Security Payload (ESP) e използван да криптира L2TP трафика. Комбинацията от L2TP (тунеленият протокол) и IPSec(метод на криптиране) е известна като L2TP/IPSec. L2TP/IPSec e описан в RFC 3193. Резултатът след прилагането на ESP kъм IP пакета съдържащ съобщение на L2TP е показан на фигура 8.

Фигура 8: Криптирането на L2TP трафик с IPSec ESP PPTP сравнен с L2TP/IPSec Двата протокола, РРТР и IPSec, използват РРР за да осигурят начална обвивка за данните и след това добавят допълнителни хедъри за транспортиране през мрежата. Обаче има следните разлики:

• С PРТР криптирането на данните започва след като РРР процеса на свързване (и затова РРР автентикацията) е завършил. С L2TP/IPSec криптирането на данните започва преди РРР процеса на свързване.

• РРТР връзката използва МРРЕ, поточен шифър, който е базиран на Rivest-Shamir-Aldeman (RSA) RC-4 криптиращи алгоритми и използва 40, 56, 128-битов криптиращ ключ. Поточният шифър криптира данните като поток от битове. L2TP/IPSec връзките използват Encryption Standard (DES), който е блок шифър, който използва или един 56-битов ключ за DES или три 56-битови ключа за 3DES. Блок шифър криптира данните в отделни блокове(64-битови блокове в случая на DES).

• РРТР свързването изисква само автентикация на ниво потребител през базиран на РРР автентикацията протокол. L2TP/IPSec свързването изисква същата автентикация на ниво потребител и в допълнение автентикация на компютърно ниво, използваща компютърните сертификати.

Предимства на L2TP/IPSec пред РРТР Следните са предимствата от използването на L2TP/IPSec пред РРТР в Windows Server 2003:

• L2TP/IPSec ESP осигурява за всеки пакет оригинална автентикация (доказателство, че данните са били изпратени от оторизиран потребител), непокътнатост на данните(доказателство, че данните не са били модифицирани при пренасянето), защита от повтаряне(предпазване от повторно пращане на поток от прихванати пакети), и поверителност на данните(известен като криптиране, осигуряващо предпазване от превеждане на прихванатите пакети без криптиращия ключ). За сравнение, РРТР осигурява само за всеки пакет поверителност на данните.

• L2TP/IPSec свързването осигурява по-сигурна автентикация чрез изисквания за автентикация на ниво компютър чрез сертификати и чрез РРР протокол за автентикация.

• РРР пакетите разменени по време на автентикацията на потребителско ниво никога не се изпращат в некриптирана форма, защото процеса на РРР свързване за L2TP/IPSec се случва след като сигурната IPSec връзка е установена. Ако прекъсне, обменената РРР автентикация за някои видове РРР автентикационни протоколи може да бъде използвана за изпълнението на offline dictionary атаки и откриването на паролите на потребителя. При криптирането на обмена на РРР автентикацията, offline dictionary атаките са много по-трудни, като криптираните пакети трябва първо да бъдат успешно декриптирани.

Предимства на PPTP пред L2TP/IPSec Следните са предимствата на РРТР пред L2TP/IPSec в Windows Server 2003:

• РРТР не изисква инфраструктура на сертификати. L2TP/IPSec изисква такава, за да издава сертификати на VPN сървъра и на всички компютри на VPN клиента.

• РРТР клиентът може да бъде поставен зад Network Address Translator(NAT) ако NAT има редактор за РРТР трафик. L2TP/IPSec-базирания VPN клиент или сървър не може да бъде поставен зад NAT, освен ако и двамата, VPN клиентът и VPN сървърът, не поддържат IPSec NAT Traversal(NAT-T). IPSec NAT-T е поддържан от Windows Server 2003 и Miscrosoft L2TP/IPSec VPN Client. Microsoft планира да поддържа IPSec NAT-T за Windows 2000 и Windows XP в бъдещи ъпдейти.

SSH/SSH2 Първоначлно SSH беше предазначен за осигуряване на сигурна алтернатива на UNIX r команди, като с rsh, rlogin и rcp. SSH употребява силно криптиране и автентикация. SSH2 се разви в сигурен тунелен протокол, който може да се използва за създаване на VPN мрежа, работеща под операционни системи Linux или UNIX. Типът на VPN мрежата, изградена с помощта на SSH2, се нарича VPN на ниво верига. SSH клиентски софтуер е достъпен също за Windows. Шлюзовете на ниво верига работят в сесийния слой на референтния OSI модел. Когато данните се предават до отдалечен компютър по шлюз на ниво верига, изглежда, че произлизат от самия шлюз. Това ви позволява да замаскирате информация за защитени мрежи. SSH може да бъде инсталиран на защитната стена, а тунелът да бъде изграден от SSH клиент с Dialup Интернет достъп до защитната стена. Защитната стена може да бъде конфигурирана да препраща трафика до сървър по вътрешната мрежа. Това е просто и лесно решение за VPN връзки, ако не се цели постигане на висока производителност. SSH изисква акаунт за логване, затова е най-подходящ за такива ситуации, като разрешаване на няколко доверени служители да се свържат към малка офис мрежа от вкъщи.

CIPE CIPE представлява драйвер за ядрото на Linux, който може да бъде използван за осигуряване на сигурен тунел между две IP подмрежи. Данните се криптират в мрежовия слой на референтния OSI модел. Това се нарича криптиране на ниско ниво. То има предимство пред криптирането на високо ниво, защото не трябва да бъдат правени никакви промени на приложния софтуер, когато две мрежи се свързват с помощта на VPN. Освен това CIPE е по-прост и по-ефикасен от IPSec.

Протоколи за криптиране След изграждането на тунела данните трябва да бъдат криптирани, за да може връзката да бъде считана за сигурна. Протоколите, използвани за криптиране на данни, са следните:

• МРРЕ • IPSec • VPNd криптиране • SSH криптиране

МРРЕ

МРРЕ се използва с РРТР-базирани VPN връзки(или РРР dialup връзки) и може да използва криптиращ алгоритъм с 40, 56 и 128-битов ключ. 128-битовия ключ(силно криптиране) може да бъде използван само в САЩ и Канада.

IPSec криптиране

IPSec използва DES или 3DES за криптиране на данните в L2TP тунел. Използването на комбинация от криптографско-базирани алгоритми и ключове прави информацията много сигурна. Алгоритъмът на Дифи-Хелман позволява сигурен обмен на споделен ключ без изпращане на самия ключ по мрежовата връзка.

VPNd криптиране: Blowfish

VPNd за Linux използва криптиращ алгоритъм Blowfish. Toва е 64-битов алгоритъм, който може да използва ключове с променлива дължина, от 32 бита до 448 бита. Той е бърз и безплатен: реално неговия сорс код е достъпен. Съществуват няколко варианта, включително GOLDFISH, DOSFISH и TWOFISH.

SSH криптиране

UNIX SSH използва криптография с публичен ключ за криптиране на данните.

LAN протоколи

За да могат VPN клиентът и сървърът да комуникират, те трябва са имат общ стек от мрежови/транспортни протоколи. Това може да бъде TCP/IP, но не е задължително да бъде само той. Дори с РРТР връзка, която изисква IP, приложен в обществена мрежа, през която се изгражда тунелът, частната мрежа може да използва IPX/SPX или дори NetBEUI за комуникации.

Autentication, базиран на сертификати (EAP-TLS)

Симетричното криптиране (с частен ключ) се базира на таен ключ, който се поделя между двете комуникиращи страни. Изпращачът използва тайния ключ като част от математическата операция да криптира чист (plain) текст в шифрован (cipher). Получателят използва същия ключ, за да декриптира cipher текста обратно в plain текст. Примери за симетрично криптиране са алгоритъмът RSA RC4, който е в основата на Microsoft Point-to-Point Encryption (MPPE), и Data Encryptiоn Standard (DES), който се използва при IPSec. Асиметричното криптиране (с публични ключове) използва два различни ключа за всяка машина – частен ключ, известен само на този потребител, и съответстващия му публичен ключ, който е достъпен за всеки. Двата ключа са свързани чрез криптографския алгоритъм. Единият ключ се използва за криптиране, а другият за декриптиране. Това криптиране позволява в съобщения да бъдат слагани цифрови подписи (digital signatures). Те използват частния ключ на изпращача, за да криптират част от съобщението. Получателят използва публичния ключ на изпращача да дешифрира цифровия подпис, за да се увери в самоличността му.

Цифрови сертификати (Digital certificates)

Със симетрично криптиране и изпращачът, и получателят имат споделен ключ (shared secret key). Предаването на тайния ключ трябва да стане (с адекватна защита) преди всякаква друга криптирана комуникация. С асиметрично криптиране, обаче, изпращачът използва частен ключ, за да криптира или да подпише цифрово съобщенията, докато получателят прилага публичния ключ, за да ги дешифрира. Публичният ключ може свободно да бъде предоставен на всеки, който иска да получава цифрово подписаните съобщения, а потребителят трябва добре да пази само частния си ключ.

За да се подсигури валидността на публичния ключ, той се публикува със сертификат. Това е структура от данни, която е цифрово подписана от някой certification authority (CA), на когото потребителите могат да вярват. Сертификатът съдържа поредица от стойности, като име на сертификата и използване, информация определяща собственика на публичния ключ, самия ключ, дата на изтичане на валидността и име на CA. CA използва своя частен ключ, за да подпише сертификата. Ако получателят знае публичния ключ на това certification authority, той може да се увери, че сертификатът е точно от него и че, по този начин, съдържа достоверна информация и валиден публичен ключ. Така сертификатите с публичен ключ осигуряват удобен и сигурен метод за удостоверяване на изпращач. IPSec може да използва този метод за автентикация на ниво изпращач-получател (peer-level authentication). Сървъри с отдалечен достъп (Remote access servers) могат да използват сертификати за автентикация на потребител.

Extensible Authentication Protocol (EAP)

Както вече подчертахме, повечето имплементации на PPP осигуряват твърде ограничени методи за автентикация. EAP е IETF стандартно разшрение на PPP, което позволява произволни authentication механизми да се грижат за валидацията на една PPP конекция. EAP е направена да разрешава динамично добавяне на plug-in модули за автентикация, както от клиентската, така и от сървърската страна на връзката. Това позволява на производителите да предложат нова схема за автентикация по всяко време. EAP осигурява голяма гъвкавост по отношение на уникалността и разнообразието на authentication. Поддържа се в Windows Server 2003 и Windows XP.

Extensible Authentication Protocol – Transport Level Security (EAP-TLS)

EAP-TLS е IETF стандарт за силни автентикационни методи, базирани на сертификати с публичен ключ. Чрез него клиентът представя потребителски сертификат пред сървъра, който от своя страна представя сървърски сертификат пред клиента. Първото гарантира силна автентикация на потребителя пред сървъра, а второто - подсигуряване на клиента, че е стигнал точно до сървъра, който е очаквал. И двете системи разчитат на верига от достоверни източници (trusted authorities), за да се уверят във валидността на предложения сертификат. Потребителският сертификат може да се съхранява в компютъра на VPN клиента или на външна smart карта. И в двата случая сертификатът е недостъпен без някаква форма на идентификация на потребителя (PIN код или размяна на име и парола между потребителя и клиентския компютър). Този подход отговаря на критерия на повечето security експерти за нещо, което знаеш плюс нещо, което имаш като начин за удостоверяване на самоличността на потребител.

Атаки върху VPN DoS атаки

През последните няколко години има голям ръст на VPN решенията, които използват TCP като основен протокол за пренос на пакети. Независимо дали е обикновен SSL/TCP tunneling или по-сложен VPN протокол, те всички се базират на концепцията за безсесийна защита на трафика и използват TCP за преминаване през firewall-и и proxy-та. TCP-базираните VPN-и дават сигурност на иначе неподдържани мрежови кофигурации, но идват и със своите проблеми. За разлика от VPN-ите, базирани на IPSec, които пренасят данни през IP или UDP, този вид VPN-и изисква работеща TCP връзка да предава пакетите между машините. Докато TCP е доказан протокол както за голям като обем (FTP), така и за сигурен пренос на данни (HTTPS), той все пак е податлив на някои DoS атаки, които придобиват доста по-голяма важност в контекста на виртуални частни мрежи, работещи по TCP.

Проста TCP атака: Ако имаме една установена TCP сесия между два хостa А и В е възможно трети хост С да прекъсне сесията без съгласието на А и В. Това може да стане като се създаде фалшив FIN пакет, който да се изпрати на всяка от двете машини от името на другата. В случая, когато С има достъп до трафика между А и В (например, ако А,В и С делят един и същ LAN сегмент или wireless група) задачата е съвсем тривиална. Ако С не може да стигне до трафика между А и В директно, той все пак може да предположи настоящите TCP номера на последователност (sequence numbers) като проучи А и В, използвайки анализ върху TCP брояча или по друг начин. Атаката става доста по-трудна да се осъществи, но все пак може да се реализира. Ако тази атака се прави често, А и В или ще установят сериозен овърхед при TCP handshake, или няма да могат да осъществят никакъв пренос на данни. Нека сега разгледаме използването на тази атака срещу TCP връзката във VPN между А и В. Тъй като VPN е на по-висок слой от TCP, неговите услуги за authentication не се прилагат за TCP пакети и не могат да предотвратят или отклонят атака чрез FIN пакет. Това позволява да се направи denial-of-service атака срещу VPN на TCP ниво, евентуално дори преди тя да достигне момента на осигуряване и authentication на конекцията. От своя страна, VPN-и, базирани на IPSec не са податливи на тази атака, тъй като включват мерки за автентикация и проверка на всеки пакет, който може да повлияе на вътрешното състояние на мрежата. Така, разчитайки на неавтентициран сесиен слой за пренос може да изложат VPN-и, базирани на TCP, на значителен риск от загуба на сигурност при едни тривиални

обстоятелства – нещо, което стандартните виртуални частни мрежи не допускат. Едно възможно решение е да се прибави authentication директно в TCP слоя. Идеята е да се използват опции на TCP за пренасяне на хеш код за автентикация на TCP пакет и да се определя хоста по време на handshake. TCP стековете на всяка от страните на връзката се променят, така че да генерират и проверяват хеша на базата на всяка машина и на конекцията като цяло. IPSec ESP, например, използва 96-битови хешове за authentication на пакетите. Използва се моделът на ESP автентикацията за генериране на сигурен пакетен хеш и изпращането му заедно със съответния пакет. 16 байта от стойността на хеша се записват в options полето на TCP header-а. Възможно е да се дефинира и нестандартна TCP опция, но това вероятно би попречило на много рутери, IDS и firewall-и да работят коректно. Все пак може да се използват две timestamp опции, които да пренасят тези 16 байта. Това предполага, че А и В успяват да договорят SA преди да установят автентицирана TCP сесия. SA включва SPI, споделена тайна (shared secret) и хеш алгоритъм. В първия пакет от един TCP handshake, хостът изпраща SPI и хеш, а другата машина отговаря с хеширан пакет с 1 timestamp ако поддържа и 0 ако не поддържа договореността. Всички TCP пакети, които следват по-нататък, включват authentication hash, който се проверява от TCP слоя на получателя преди той да приеме пакета като валиден. Ако хешът е грешен или е очакван, но липсва - пакетът се отхвърля. Хешът се пресмята върху части от TCP header-а или TCP данните. Всички полета на заглавието се хешират, с изключение на портове, контролни суми и опции, които носят самия хеш код. В повечето случаи SA се прави чрез обикновен TCP connection(без автентикация) или чрез ръчно създаване.

Атаки върху криптографски системи

Ще разгледаме два основни аспекта: • как една криптосистема може да бъде пробита • реални практически атаки върху защитени данни

За да се компрометира една криптосистема обикновено се използват два метода: • атака върху самия криптоалгоритъм – изисква много задълбочени

математически и криптографски познания от атакуващия, а освен това шансовете му за успех срещу един добре анализиран алгоритъм като DES са минимални

• предположение за ключовете от криптираните данни – Един добър криптографски алгоритъм се счита за сигурен ако най-добрият начин за пробив в сигурността му е чрез brute force атака, за която е

необходимо огромно време. Тя изпробва всички възможни ключове в пространството от ключове, за да намери използвания от двете страни. Най-добрите алгоритми зависят само от криптографския ключ – колкото е по-дълъг, толкова е по-сигурен алгоритъмът.

Възможни практически атаки върху данни и ключове: • Ciphertext-only атака – атакуващият има cihertext ключа на няколко

съобщения, които са били криптирани със същия криптографски алгоритъм, но не знае нищо за стоящия отдолу plaintext. Той се опитва да предположи ключа (или ключовете) използвани за криптирането на съобщенията, за да може да декриптира други съобщения, направени със същите ключове. За това се използват статистически анализи, но съвременните алгоритми са съобразени с тях, генерирайки псевдослучаен изход.

• Known-plaintext(brute force) атака - атакуващият има cihertext ключа на на няколко съобщения, които са били криптирани със същия криптографски алгоритъм, но знае и нещо за стоящия отдолу plaintext(т.е. протокол, тип на файла и някои низове). Той се опитва да предположи ключа за криптиране на съобщенията чрез brute-force търсене докато декриптиране с правилния ключ доведе до смислен резултат.

• Chosen-plaintext атака – атакуващият може да избира какво е криптирано от криптиращото устройство и да проучи изхода от ciphertext-а. Това е по-силна атака от known-plaintext атаката, защото атакуващият може да избере да декриптира специфични блокове с plaintext, които може да носят повече информация за ключа. Тъй като той получава блок с plaintext и съответстващия му ciphertext, може да приложи brute-force атака, за да намери връзката между избрания plaintext и неговия ciphertext.

• Chosen-ciphertext атака – аналогична на chosen-plaintext атаката. Атакуващият може да избира различни ciphertext-ове, които да бъдат декриптирани като има достъп до декриптиран plaintext. Например, той има достъп до криптиращо устройство с вграден ключ. Задачата му е да предположи какъв е ключа като изпраща данни през устройството.

За увеличаване на сигурността на една криптосистема, нейните сесийни ключове често се подменят по време на операцията. Сесийните ключове имат ограничено време на съществуване и ако един такъв ключ е компрометиран, само данните, които той защитава са също компрометирани, при положение, че криптосистемата използва PFS(Perfect Forward Secrecy). PFS определя, че последователните сесийни ключове не са свързани по никакъв начин и новите ключове се генерират независимо от старите. В системи без PFS новите ключове обикновено се изчисляват чрез старите, използвайки детерминистичен алгоритъм за преобразуване. Тогава, ако един сесиен ключ е компрометиран, копрометирани са и всички останали, тъй като могат да се изчислят въз основа на разгадания вече ключ.

• Атаката “Man in the middle” е основна атака върху мрежовата сигурност. При нея атакуващият има възможността да застане на комуникационния път между двете страни и да spoof-ва другата машина за всяка от комуникиращите страни(той стои по средата и приема съобщения, променя данни и изпраща отново съобщение към получателя). Основният Diffie-Hellman алгоритъм е податлив на тази атака. Решението е да се използва допълнителен authentication механизъм с този алгоритъм(например, HMAC или електронен подпис). Да разиграем въпросната атака. Нека А и В са две машини, които искат да си говорят, разменяйки си Diffie-Hellman съобщения. Първо те се договарят и изчисляват публичните ключове чрез своя собствен частен ключ. След това тези ключове се обменят между машините. Ако атакуващият успее да прихване съобщенията и да пресече тази размяна, той може да размени публичните ключове, които се обменят със свои собствени. В края на алгоритъма вместо да се е осъществила договорка между А и В, има такава между атакуващия и А и между атакуващия и В. А и В мислят, че си говорят един с друг чрез Diffie-Hellman, но всъщност те правят Diffie-Hellman размени с атакуващия и той има достъп до целия материал, който се обменя между двете страни, тъй като улавя всички съобщения.

Обикновено, най-сериозна е опасността атакуващият да получи достъп до важни данни и после да се опита да получи ciphertext-а. Възможни са обаче и други типове атаки – много важна категория атаки срещу защитения трафик е тази на активните атаки. Те включват манипулиране на данни в мрежата – например, промяна или добавяне на данни в криптирани сесии или умишлено повтаряне(replaying) на стари(валидни) данни в тези сесии.

• Insertion атака – атакуващият вкарва свои собствени съобщения в криптирания поток от данни. Дори товарът да е безсмислица, може да се декриптира до нещо, което няма data source authentication. Дори безсмислени данни могат да задействат някои бъгове и да създадат проблеми на получателя на данните. Authentication на пакетите се използва за да се избегне този вид атаки.

• Replay атака – атакуващият хваща част от криптираните данни и по-

късно ги вкарва отново в потока от данни. Това може да доведе до повтаряне на валидни транзакции по мрежата, което да нанесе голяма вреда. Authentication на съобщенията не решава този проблем, тъй като те изглеждат валидни(те са копия на съобщения, вече преминали през authentication). За избягване на replay атаки се реализира наредба на съобщенията в точно определена последователност, като получателят приема съобщения само с нарастващ пореден номер. За да се предпазим от некоректно доставяне на съобщения се използва

прозорец с допустими номера на последователност(sequence numbers) – така е при IPSec.

Изборът на алгоритъм е очевидно един от основните въпроси по сигурността, когато изграждаме криптографски базирано решение. Според ситуацията могат да се използват различни криптографски алгоритми: 1. Симетрични

• DES, 3DES, IDEA и RC4 се считат сигурни по отношение на скриване(privacy)

• SHA-1 е подходящ за по-добра интеграция и HMAC функции 2. Асиметрични криптографски алгоритми

• RSA се смята за сигурен за електронни подписи(digital signatures) и обмяна на ключове

• Автенициран Diffie-Hellman се използва най-вече за договаряне и обмяна на ключове.

Дължината на използваните ключове определя сигурността на една криптосистема. За съответните алгоритми препоръчителната дължина на ключа е:

1. За симетрични алгоритми • 40/56-битов ключ е достатъчно силен за краткотрайна

неприкосновеност • 80-битов ключ гарантира добра сигурност за кратко и среднодълго

използване • поне 112-битов ключ трябва да се използва за подсигуряване на

добра дълготрайна защита 2. Асиметрични алгоритми

• 1024-битов ключ за кратко време • поне 2048-битов ключ за дълготрайна защита.

Други използвани протоколи и възможни атаки ще разгледаме в контекста на Windows Server 2003 Network Access Quarantine Control

Network Access Quarantine Control е новост в Windows Server 2003. Той забавя нормалния отдалечен достъп към частна мрежа, докато конфигурацията на отдалечения компютър не бъде проучена и проверена за валидност чрез администраторски скрипт. Когато отдалечен компютър поиска връзка с remote access сървър, потребителят се автентицира и му се дава IP адрес. Въпреки това, конекцията е поставена в състояние на карантина (quarantine mode), в което достъпът до мрежата е ограничен. След това администраторският скрипт се пуска на отдалечената машина. Когато завърши успешно, той изпраща съобщение на сървъра с отдалечен достъп, че отдалеченият компютър отговаря

на настоящите условия на мрежата. Remote access сървърът премахва състоянието на карантина и отдалеченият компютър е вече одобрен за нормален достъп. Network Access Quarantine Control е комбинация от следните неща:

• Remote access сървър под Windows Server 2003 и услуга listener за съобщения, отнасящи се до състоянието на карантина.

• RADIUS сървър под Windows Server 2003 и Internet Authentication Service (IAS), конфигурирани с карантинните условия за отдалечен достъп (quarantine remote access policy)

• Профил, създаден с Windows Server 2003 Connection Manager Administration Kit, който съдържа скрипт за проверка на мрежовата политика (network policy) и компонент notifier, който трябва да бъде изпратен на сървъра, за да го уведоми за резултатите от нея.

• Отдалечен клиент под Windows Server 2003 или Windows XP/2000/ME/98SE.

Remote Access Account Lockout

Тази възможност се използва за определяне колко пъти отдалечена автентикация за валиден потребителски акаунт е пропаднала преди на потребителя да му бъде отказан отдалечен достъп. Особено е важна за VPN връзки с отдалечен достъп, работещи през Интернет. По Интернет са възможни атаки, опитващи се да получат достъп до intranet на някоя организация като изпращат credentials (валидно потребителско име и предположена парола) по време на процеса на автентикация на VPN конекцията. При тази dictionary атака атакуващият изпраща стотици хиляди credentials, използвайки списък от пароли, базирани на често срещани думи и изрази. Чрез Remote access account lockout dictionary атаката се осуетява след няколко неуспешни опита. Тази техника, обаче не прави разлика между атакуващи потребители и такива, които са забравили паролата си и пробват различни варианти. Възможен е вариант на умишлен lockout на даден потребител, чрез многократни опити на пароли. Remote access account lockout се конфигурира чрез промяна на настройките в регистрите на компютъра, който осъществява автентикация. Ако сървърът за отдалечен достъп е конфигуриран за Windows authentication, трябва да се промени registry-то на remote access сървъра, а ако е за RADIUS автентикация и се използва Internet Authentication Service (IAS), променят се регистрите на IAS сървъра.

Remote Access Policy Profile Packet Filtering

Политиките за отдалечен достъп, които дефинират оторизационните ограничения (constraints) и тези върху конекцията, могат да се използват, за да се определи група филтри за IP пакети, които да се приложат за remote access връзки. Когато конекцията е приета, пакетните филтри определят какви типове IP трафик са разрешени от и към VPN клиента. Това филтриране може да се използва за extranet конекции (extranet е част от мрежата на една организация, която е достъпна за потребители извън организацията) и да се създаде политика за

отдалечен достъп, която поставя условието, че членовете на т.нар. Partners group могат да достигат Web сървърите на точно определени IP адреси или на точно определени подмрежи. Това свойство може да се използва също и за предотвратяване на изпращане на пакети от отдалечени VPN клиенти, които те не са създали. Когато remote access клиентът прави конекцията, той създава маршрут по подразбиране, така че целият трафик, който пасва на този маршрут, се изпраща през VPN връзката. Ако други машини предават трафик на VPN клиента, използвайки го като router, то този трафик също ще се предаде през VPN конекцията. Това е проблем в сигурността, защото VPN сървърът не е автентицирал компютъра, който предава трафик към клиента, а на практика той има същия достъп до мрежата като този на вече автентицирания VPN клиент. За да се предпази сървъра от получаване на трафик през конекцията от компютри различни от тези, които са минали authentication, трябва да се конфигурират пакетни филтри за отдалечен достъп на remote access политиката, която VPN конекцията използва. Remote access политиката по подразбиране за Windows Server 2003 се нарича Connections to Microsoft Routing and Remote Access server и вече има коректните входни пакетни филтри за тази конфигурация.

VPN администрация

За избора на VPN технология е важно да се разгледат и някои администраторски въпроси. Големи мрежи трябва да съхраняват информация за всеки потребител и да предоставят directory service-и, така че администраторите и приложенията да могат да добавят, променят и четат тази информация. За да не се правят множество акаунти на различни сървъри, които трябва да се синхронизират помежду си, повечето администратори правят база данни за потребителски акаунти на directory сървър, RADIUS сървър или primary domain контролер. Като използва директорийната услуга Active Directory като база данни за акаунти, VPN-и, базирани на Windows Server 2003 стават т.нар. single sign-on решения, т.е. едни и същи credentials се използват за двете VPN връзки за логване към домейна на организацията.

Оторизиране на VPN конекции

За да осигури authorization за VPN връзки и да даде метод за ограничаването им, Windows Server 2003 VPN конекциите използват комбинация от dial-in характеристики на потребителските акаунти в локална или domain база данни и политики за отдалечен достъп(remote access policies). Remote access policies са група правила, които определят как конекциите се приемат или отхвърлят, а за приетите конекции те дефинират също и ограничения (restrictions). За всяко правило има по едно или няколко условия, група от профилни опции и опция за разрешение за отдалечен достъп (remote access permission). Опитите за осъществяване на връзка се оценяват от remote access политиките последователно, опитвайки се да определят дали опитът

отговаря на всички условия на всяка от политиките. Ако това не е изпълнено, конекцията се отказва. Ако една връзка бъде приета и й е даден permission за отдалечен достъп, policy profile-ът определя ограниченията за нея. Тези ограничения включват характеристиките на конекцията (като максимално време на съществуване и idle timeout), филтриране на IP пакетите, автентикационните протоколи и изискваното криптиране. Dial-in свойствата на потребителския акаунт също дават набор от рестрикции. Където е подходящо, ограниченията, зададени от акаунта, покриват тези, които са определени от policy profile-а.

Scalability

Redundancy и load balancing се осъществява или чрез DNS, или чрез Network Load Balancing:

• Round-robin DNS се използва за разделени заявки между VPN сървъри, които покриват общ периметър на сигурност (security perimeter). Един security perimeter има едно външно DNS име (например, microsoft.com), но няколко IP адреса и съдържанието е произволно разпределено между тях.

• Чрез Network Load Balancing, клъстер от VPN сървърски компютри може да гарантира голяма гъвкавост и load balancing както за PPTP, така и за L2TP/IPSec конекции.

Remote Authentication Dial-in User Service(RADIUS)

Протоколът RADIUS е популярен метод за осъществяване на отдалечен authentication и authorization, който е базиран на UDP. RADIUS сървъри могат да се разположат навсякъде в Интернет и да предоставят автентикация (включвайки PPP PAP, CHAP, MS-CHAP, MS-CHAPv2, EAP) и оторизация за VPN сървъри. Освен това, RADIUS сървърите могат да осигурят proxy услуга за предаване на автентикационни заявки до далечни RADIUS сървъри. Например, много доставчици на Интернет (ISP) имат договореност да разрешават на roaming абонатите да използват локални услуги от най-близкия ISP за dial-up достъп до Интернет. Roaming обединенията се възползват отлично от proxy услугата на RADIUS. Ако един ISP разпознае даден username като потребител на отдалечена мрежа, доставчикът използва RADIUS proxy, за да препрати заявката за достъп до подходящата мрежа. Windows Server 2003 включва RADIUS сървър и прокси с Internet Authentication Service (IAS), изборен мрежови компонент за Windows, който се инсталира от Control Panel – Network.

Connection Manager и Managed VPN connections

За реализирането на конфигурация от голям брой VPN клиенти с отдалечен достъп за enterprise цели се използва Connection Manager (CM). CM e набор от компоненти включени към Windows Server 2003, сред които са:

• Connection Manager (CM) client dialer • Connection Manager Administration Kit (CMAK) • Connection Point Services (CPS)

Connection Manager Client Dialer

Connection Manager (CM) client dialer e софтуер, които е инсталиран на всеки VPN клиент и включва някои advanced свойства, които го правят подходящ за отдалечен networking. В същото време, CM представя едно опростено избиране. Той ограничава броя на конфигурационните опции, които потребителят може да промени, осигурявайки, че той може винаги да се свърже успешно. Например, с CM client dialer потребителят може:

• да избере от списък с телефонни номера този, който иска да използва, на базата на физическо местоположение

• да използва променени по свое желание графики, икони, съобщения и help • автоматично да създаде dial-up връзка преди VPN конекцията да бъде

направена • да извърши определени действия по време на различни части от процеса

на свързване, като pre-connect и post-connect действия (стартирани преди или след като dial-up или VPN конекцията е завършена).

Customized CM client dialer пакет е саморазархивиращ се изпълним файл, който е създаден от мрежовия администратор с Connection Manager Administration Kit (CMAK). Профилът се разпространява до VPN потребителите чрез CD-ROM, e-mail, Web site или file share. Когато потребителят стартира CM профила, той автоматично конфигурира подходящите dial-up и VPN конекции. Connection Manager profile-ът конфигурира връзки за компютри работещи под Windows Server 2003, Windows XP/2000/NT4/ME/98.

Connection Manager Administration Kit (CMAK)

CMAK е опционално средство, което се инсталира от: • Add/Remove Programs (в Control Panel) на компютър работещ под

Windows Server 2003. В категорията Management and Monitoring Tools от Windows Components трябва да се укаже Connection Manager Components.

• Windows Server 2003 Administration Tools на компютър работещ под Windows XP Professional. Най-напред трябва да се стартира файлът Adminpak.msi от \I386 на Windows Server 2003 CD-ROM-а. След като бъде инсталиран този файл, CMAK може да бъде пуснат от Administrative Tools.

CMAK e wizard, който преминава през голямо разнообразие от настройки при конфигуриране на CM профил и създава профила, който ще бъде даден за VPN потребителите.

Connection Point Services (CPS) CPS предоставя възможността за създаване, представяне и обновяване на собствени телефонни указатели (phone books). Те съдържат един или повече Point of Presence входа (POP entries), всеки от които има телефонен номер, използван за достъп до dial-up мрежа или Интернет. Указателите дават на потребителите пълна POP информация, така че когато те пътуват, могат да се свържат към различни точки на достъп в Интернет или към някоя организация. Тези access points са базирани на местоположение, вместо да се използва номер за далечно избиране. Без възможността да update-ват телефонните указатели, на потребителите не само би се наложило да се свързват с техническата поддръжка, за да направят промяна в своята POP информация, но и да преконфигурират софтуера на своя клиентски dialer. CPS е комбинация от:

• Phone Book Administrator – средство, което се използва за създаване и поддръжка на файловете на телефонните указатели и публикуване на нови или обновени такива файлове на phone book сървъра. Phone Book Administrator се инсталира чрез стартиране на Pbainst.exe от Valueadd\Msft\Mgmt\Pba на диска с Windows Server 2003. Веднъж инсталиран, той може да бъде пуснат от Administrative Tools, но използването му на phone book сървъра не е задължително изискване. Phone Book Administrator може да се използва за създаване на нови указатели и региони и публикуването им в SystemRoot\Program Files\Phone Book Service\Data\PhoneBookFileName на phone book сървъра.

• Phone Book Server – сървър работещ с Windows Server 2003 и Internet

Information Services (IIS), включително FTP Publishing Service, и Internet Server Application Programming Interface (ISAPI) разширение, който изпълнява update заявките за телефонните указатели от CM клиентите.

След като указателят е конфигуриран и публикуван се създава CM профил с CMAK, който се настройва чрез: 1. Автоматично изтеглени update-и за телефонни указатели 2. Phone book файла 3. Името на сървъра за указателите. Accounting, Auditing, Alarming За правилното администриране на една VPN система мрежовите администратори трябва да имат възможността да следят за това кой използва системата, колко конекции са направени, за необичайни дейности, за възникнали грешки и за ситуации, по които може да се установи наличието на хардуерни проблеми.

Например, един администратор може да поиска да узнае кой е свързан към системата и за колко време, за да може да събере данни за съответния потребител. Необичайни дейности могат да покажат неразрешено използване на системата или некоректни ситемни ресурси. Следенето на устройствата може да генерира съобщение към администратора за даден проблем (например, необичайно голяма заетост на един модем и незаетост на друг може да е сигнал за неправилна работа на модема). Тунелният сървър трябва да осигури цялата тази информация, а системата трябва да предостави event log-ове, report-и и възможност за съхранение на данни, за да се използват данните подходящо. RADIUS протоколът дефинира набор от заявки за извикване на акаунти (call-accounting requests), които са независими от автентикационните заявки. Тези съобщения от NAS към RADIUS сървъра казват на RADIUS сървъра да генерира записи за акаунти в началото на обръщение (call), в края на обръщение и на предварително определени интервали по време на обръщение. Рутирането и услугите за отдалечен достъп, които осигуряват функционалността на VPN сървъра в Windows Server 2003, могат да се конфигурират да изпращат тези RADIUS заявки отделно от connection заявките (които могат да отидат до домейн контролера или до RADIUS сървъра). Това позволява на администратора да конфигурира акаунтен RADIUS сървър, който да събере записи за всяка VPN конекция за по-нататъшни анализи. По-нататък може да се използват програми за проверка (auditing packages), които четат тези RADIUS записи за акаунти и дават разнообразни и полезни report-и. В Windows Server 2003 IAS е акаунтен RADIUS сървър и поддържа записване на акаунтна информация за конекцията в log файл или изпращането й директно към SQL база данни.

Linux като VPN клиент към Firewall-1 Сега ще опишем конфигурирането на Linux хост за установяването на VPN тунел към Check Point VPN-1 чрез IKE и IPSec. Конфигуриране на VPN: проста диаграма Следната диаграма описва използваното конфигуриране по време на създаване на този документ:

Преди да инсталирате FreeS/WAN и VPN-1 уверете се, че можете да комуникирате с всяка от машините във вашата мрежа, и че всички маршрутизатори са включени. Конфигуриране на VPN: Linux хост След като инсталираме S/WAN, ние трябва да разберем някои от основните конфигурационни опции. Те се намират в следните два файла: За FreeS/WAN 1.5: /etc/ipsec.conf # # основна конфигурация

# използваният интерфейс е eth0 name config setup interfaces="ipsec0=eth0" klipsdebug=none plutodebug=none manualstart= plutoload= plutostart= # конфигурация за свързване # този тунел се изисква ако искате FreeS/WAN хоста да бъде способен да #комуникира с # Check Point FW/VPN машина т.е. ако искате да можете да ping-нете CP VPN #gateway от FreeS/WAN хост, който определя следното: conn linux-fw1 type=tunnel left=10.0.0.1 leftnexthop=10.0.0.2 right=10.10.10.10 rightnexthop=10.10.10.1 keyexchange=ike auth=esp pfs=no #Този тунел е необходим за да позволи на FreeS/WAN хостът да комуникира с #Encryption Domain зад CP VPN Gateway. conn linux-encdom type=tunnel left=10.0.0.1 leftnexthop=10.0.0.2 leftsubnet=192.168.0.0/16 right=10.10.10.10 rightnexthop=10.10.10.1 keyexchange=ike auth=esp pfs=no Файлът /etc/ipsec.conf ни позволява да специфицираме конфигурацията на нашия интерфейс, както и VPN връзките, които ще поддържаме. Има две секции, които трябва да дефинираме:

1. config setup Тази секция ще ни позволи да прикрепваме виртуален IPSec интерфейс към нашия физически мрежов интерфейс. В примера горе, ipsec е прикрепен към eth0 интерфейса. Ако искате VPN да се стартира автоматично по време на

зареждане на системата, можете да видите “man ipsec.conf” за повече информация относно “plutoload” и “plutostart” .

2. conn <connection name>

Taзи секция трябва да бъде дефинирана за всяка VPN връзка и влияе за това конфигурацията на VPN опциите и маршрутите да бъде добавена по време на създаването на VPN. В примера горе е дефинирана връзка с име linux-fw1 и притежава следните свойства:

type=tunnel Tази опция определя да се използва тунелен режим за VPN, вместо транспорен режим. VPN-1 не поддържа транспортен режим по това време

left=10.0.0.1 Това е лявата крайна точка или страна на VPN. В примера горе, тя е използвана да представи VPN-1 gateway.

leftsubnet=192.168.0.0/16 Това дефинира топологията на лявата страна на VPN. Tъй като използваме лявата страна да представяме VPN-1, това трябва да съответства (изцяло или частично) на дефинирания encryption domain

right=10.10.10.10 Toва е дясната крайна точка или страна на VPN . В примера горе, тя се използва да представи Linux хоста.

rightnexthop=10.10.10.1 Това представя IP адреса на gateway-a, който дясната страна на нашия VPN ще използва да достигне до лявата страна.

keyexchange=ike Използване на IKE за размяна на ключове.

auth=esp Позволяването на ESP хедъри за пакетите.

pfs=no Забраняване на Perfect Forward Secrecy.

/etc/ipsec.secrets:

# Забележете, че всички тайни трябва сега да бъдат заградени в #кавички, # дори и ако нямат бели места вътре в тях. 10.10.10.10 10.0.0.1 "password"

Файлът /etc/ipsec.secrets ни позволява да специфицираме споделени тайни между хостовете в нашата VPN. В примера горе, споделената тайна за 10.10.10.10 и 10.0.0.1 VPN е “password”. Тази тайна трябва да съответства на двата края на VPN, така че трябва да бъдем сигурни, че конфигурираме същата споделена тайна на VPN-1. Конфигуриране на VPN: VPN-1

В тази секция накратко ще обясним конфигурирането на VPN-1. Конфигурираме обект, който да представи Linux хост. В следния пример, това е обект работна станция от тип “Host”.

Ако има ресурси зад Linux хоста, които ще бъдат достъпни през VPN, бъдете сигурни, че сте избрали “Gateway” и oпределете encryption domain за Linux хост. Ще трябва и да дефинирате “RightSubnet” свойство в /etc/ipsec.conf. Използвайте VPN страницата на свойствата на работната станция за да изберете IKE, и дефинирайте IKE споделена-тайна за използване, когато се комуникира с този хост - трябва да бъдете сигурни, че това отговаря на споделената тайна, която сте създали в /etc/ipsec.secrets:

На примера горе маркирахме “Pre-Shared Secret” за автентикация. Маркирайте “Edit Secrets..” и въведете тайната, която ще използвате в /etc/ipsec.secrets на Linux хоста. Обърнете внимание, че дезактивираме “Supports Aggressive Mode”. Създаването на “Encrypt” правило за дефиниране на VPN трябва да изглежда приблизително по следния начин:

Добра идея е да се дезактивира Perfect Forward Secrecy. Направете това като натиснете с дясното копче на мишката върху “Encrypt” в панела с вашите правила. Опцията се намира на IKE диалоговия прозорец:

Тъй като тази версия на S/WAN не поддържа IKE SA време за договаряне по-дълго от 480 минути, трябва да сменим подразбиращата се настройка за VPN-1. Това се прави като изберем Policy ->Properties:

Създаване на VPN След правилното конфигуриране на S/WAN конфигурационните файлове и конфигурирането на VPN-1, e лесно да се установи VPN между S/WAN и VPN-1.

Има две конфигурирания, които ще представим в стъпки, извършени върху Linux хоста.

• S/WAN ще установи връзка с VPN-1 Ако искаме да създадем връзка от Linux хоста към VPN-1, трябва да преминем през следните две стъпки, за да установим VPN тунел и да разрешим криптираната комуникация:

1. Добавяме връзката към таблицата на връзките: Забележка: Ако сте направили промени на файла /etc/ipsec.conf или /etc/ipsec.secrets, откакто за последен път сте въвели нова или изтрили стара връзка, е по-добре да спрете FreeS/WAN и след това да го пуснете отново и да продължите. За да направите това използвайте командите: Ipsec setup --stop Ipsec setup –start Използвайте следния формат:

ipsec auto --config <file> --add <connection>

Конфигурационният файл по подразбиране е /etc/ipsec.conf, така че нашата команда е следната:

ipsec auto --add linux-fw1 and ipsec auto --add linux-encdom Долу е диалогът от примерна сесия:

2. Включването на връзката и установяването на VPN. Използвайте следния формат:

ipsec auto --config <file> --up <connection>

Конфигурационният файл по подразбиране е /etc/ipsec.conf, така че комадата изглежда така:

ipsec auto --up linux-fw1 and ipsec auto –up linux-encdom

Долу е даден примерен диалог на сесията:

Сега VPN връзката трябва да бъде установена.

• VPN-1 ще установи връзката с S/WAN Ako вие ще създадете VPN от VPN-1 до Linux S/WAN клиент, може да използвате следните команди за да позволите на S/WAN да слуша за идващи IKE&IPSec връзки: 1. Добавете вашата връзка към таблицата с връзките:

Използвайте следния формат: sec auto --config <file> --add <connection>

Конфигурационният файл по подразбиране е /etc/ipsec.conf, така че нашата команда е следната:

ipsec auto --add linux-fw1 and ipsec auto --add linux-encdom

2. Разрешете на режима на слушане да приема идващи IKE и IPSec заявки:

ipsec whack –listen

Сега можете да започнете връзката от Encryption Domain зад VPN-1 kутията към FreeS/WAN кутията.

Проверяване на връзката След като сме установили VPN с FreeS/WAN, може да потвърдим връзката по следния начин: ipsec auto –status Изходът трябва да изглежда по следния примерен начин:

Обърнете внимание, че на горния изход информацията за security association (SA) между двата хоста за връзката ‘linux-fw1’ и ‘linux-encdom’ е показана. Това говори, че IKE преговорите между VPN-1 и нашия Linux хост са завършили успешно. Когато сте готови да тествате криптирания трафик през тунела, опитайте се да използвате PING, за да тествате връзката между вашия Linux хост и ресурс в encryption domain на защитната стена. В нашият пример използваме PING за да тестваме свързаността от нашия Linux хост до FTP сървър зад защитна стена. Ако можете успешно да PING-вате от вашия Linux хост до ресурсите в encryption domain, проверете VPN-1 Log Viewer, за да проверите дали трафика е бил криптиран. Следните дейстия се появяват в Log Viewer:

Key Install – представя успешните преговори между Linux хоста и VPN-1. Първият запис показва приключванто на IKE фаза 1, докато записите 2 и 3 показват приключването на IKE фаза 1. Decrypt – представя успешното декриптиране на криптирания трафик идващ от Linux хоста. Encrypt – представя успешното криптиране на трафика отиващ към Linux хоста. Проблеми и дебъгване Има малко на брой опции за дебъгване за S/WAN, особено като се има предвид, че Debug tag може да бъде добавен преди компилацията, за да разреши обширна debugging информация. Следват няколко много полезни команди:

1. ipsec whack –debug-all

Taзи команда казва на Pluto демона да разреши debug изхода за много аспекти на VPN. След като Pluto е настроен да осигурява debugging информация, следните команди може да се използват да се види изходът, както и много конфигурационни аспекти, които въздействат на VPN:

2. ipsec barf

Taзи команда показва debugging информация за S/WAN, както и конфигурационна информация от S/WAN файлове до маршрути и други файлове на системата, които имат ефект върху способноста на S/WAN да установява VPN. Примерен изход от 'ipsec barf' е показан долу: Dec 8 13:15:50 zen Pluto[498]: "linux-fw1" #12: no acceptable Oakley Transform Dec 8 13:15:50 zen Pluto[498]: | state transition function for STATE_MAIN_R0 failed: NO_PROPOSAL_CHOSEN Dec 8 13:15:50 zen Pluto[498]: | next event EVENT_SA_EXPIRE in 0 seconds for #12 Този пример е взет от част на края на изхода, където IKE уговарянето може да бъде проследено. Може да се види на примера горе, че се е срещнала грешка, където VPN-1 и S/WAN не са могли да се уговорят за валидно време за IKE security. Tази грешка се появява само, когато VPN-1 е започнал VPN връзката, тъй като подразбирщото се време за завършване на IKE SA на VPN-1 е 10080 минути и S/WAN може да работи максимум само 480 минути.

3. ipsec eroute

Тази команда ни позволява да конфигурираме виртуални маршрути през VPN тунел. Ако добавим мрежови маршрути след като VPN тунела е установен, може да се наложи да нагласим маршрута с тази команда. Това е пример на “еroute” маршрутизираща таблица на S/WAN хост, когато VPN e установена:

Горните примери трябва да направят относително безболезнено решаване на проблемите свързани с маршрутизирането с S/WAN хоста.

Източници: 1. Virtual Private Networking with Windows Server 2003: Overview, Microsoft Corporation, 2003г. 2. Linux as a VPN Client to FireWall-1, Ron Naken, Elie Bitton, 2000г. 3. Security and Cryptographer Refresher, Cisco Systems inc., 2000г. 4. Trivial Denial of Service Attack against TCP-based VPN, Alex Pankratov, Cipherica Labs, 2003г. 5. “Компютърни мрежи”, Дебра Шиндър, Софтпрес, София, 2003г.