Интернет информационно списание

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

• МРРЕ
• 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 (без автентикация) или чрез ръчно създаване.

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

Ще разгледаме два основни аспекта:

1. как една криптосистема може да бъде пробита
2. реални практически атаки върху защитени данни

За да се компрометира една криптосистема обикновено се използват два метода:

атака върху самия криптоалгоритъм – изисква много задълбочени математически и криптографски познания от атакуващия, а освен това шансовете му за успех срещу един добре анализиран алгоритъм като 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.

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

Симетрични

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

SHA-1 е подходящ за по-добра интеграция и HMAC функции

2. Асиметрични криптографски алгоритми

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

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

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

За симетрични алгоритми

• 40/56-битов ключ е достатъчно силен за краткотрайна неприкосновеност
• 80-битов ключ гарантира добра сигурност за кратко и среднодълго използване
• поне 112-битов ключ трябва да се използва за подсигуряване на добра дълготрайна защита
• 2. Асиметрични алгоритми
• 1024-битов ключ за кратко време
• поне 2048-битов ключ за дълготрайна защита.

Сходни статии:

1. NetBEUI и IP протоколи в мрежите NetBEUI мрежи Малка проста локална мрежа, използваща операционни системи на Microsoft, която може да комуникира с помощта на протокола NetBEUI. NetBEUI (съкращение от NetBIOS Extended User Interface) е базиран на протоколите NetBIOS (Network Basic Input/Output System), разработени от IBM за...
2. Сигурност на приложенията (Application security) В сигурността на приложния слой са концентрирани голямо количество очаквания за защита. Лошо (слабо) защитените приложения могат да осигурят лесен достъп до конфиденциални бази данни и записи. Истина е, че повечето от проектантите и програмистите създават софтуер без мисъл за...
3. Протоколи и услуги ориентирани към пренасяне на информация TCP (Transfer Control Protocol) – протокол за управление на обмена на информация. Този протокол обслужва връзките. Данните се изпращат на пакети, които съдържат заглавна част и данни. Надеждността на обмена се осигурява от контролни суми и сравнения между изпратената и...
4. Проектиране на базата данни При проектирането на базата от данни основен етап е моделирането й. При него се очертават редица правила и принципи, които трябва да бъдат спазени, за да се осигури  ефективната и надеждната й работа. Правила за моделиране на базата от данни....