„Проектиране на корпоративна vpn мрежа
Изтегляне 2.17 Mb.
|
| 8.2 Проста 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 (без автентикация) или чрез ръчно създаване. Изтегляне 2.17 Mb. Сподели с приятели:
|