DDoS - Distrubuted Denial of Service

I. Syn flood
Може да се извърши само под ТСР протокол. Атаката е базирана на свойствата на ТСР протокола при първоначално установяване на връзка. първоначалното установяване на връзка на TCP е процес наречен 3way handshake общо взето прездтавлява размяна на 3 пакета, с което се установява статут на връзката. хост 1 праща syn пакет, до хост 2, хост 2 отговаря на хост 1със syn-ack пакет и хост 1 отоваря на хост 2 с финален ack пакет след което формално 2-та хоста имат установена връзка. Syn Flood използва точно това свойство, като в процеса, от атакуващия, към жертвата се пращат огромно количество syn пакети, жертвата, отговаря със syn-ack пакети, очаквайки финалните ack пакети които така и не пристигат. Така жертвата остава с огромен брой полу-отворени TCP връзки. Известно след края на атаката, всичките полу-отворени връзки сами изчезват, ТСР протокола сам си ги изчиства.

Общо взето това се спира от всеки , защото това са връзки, които идват отвън, и това са неочаквани syn пакети, и заради това че са неочаквани, Statefull Packet Inspection Firewall ги дропва, защото няма с какво или с кого да ги асоциира. Тук натварването идва от 2 места.

1 ако няма пряка защита, жертвата, е заделила всичките си ресурси, за да поддържа полу-отворени конекции, към нападателя, който така и няма да се появи, и няма ресурс за да задели за легитимна връзка, от някой юзер.

2 Ако има някаква защита, която да филтрира и преценяа пакетите кой дапусне, кой да спре, дори вездесъщият IPTables, пакета трябва да постъпи в сървъра, после да бъде насочен към защитата, тя да го прегледа, да види и да прецени дали да го пусне или да го дропне. В нашия случай го дропва. Това изисква ресурси от системата. макар системата да не получава тия syn пакети, и да не прави полу-отворени конекции, самият факт че защитата трябва да филтрира и отсява огромен брой пакети, увеличава натоварването на системата. С достатъчно пакети за единица време, всеки пада претоварен.

II. Bandwidth Saturation или Pipe Flood....
това е UDP базирана атака, използвайки факта, че под UDP липсва цялата тая преамбула, от syn пакети ack пакети, и прочието неща на ТСР. UDP работи на много прост принцип пращаш query, получаваш Reply и въпроса приключва бързо конкретно и по същество без допълнителни дейности. Това свойство, на UDP позволява да се направят 2 неща

1 да се спуфне IP на източника

2 просто да "отвориш кранчето" и let the jiuce flow към жертвата. този тип атаки, искат от атакуващият да използва, изключително голям трафик, за да може ефективно да задуши връзката. Нека приемем че жертвата има 100 мегабитова връзка. успешна DDoS от този тип, може да се очаква, ако атакуващият използва своята ботмрежа, да стовари 10 гигабита, върху 100-те мегабита на жертвата. Ако работим със закръглени стойности, атакуващият напада жертвата с трафик, който е 100 пъти повече от колкото жертвата може да понесе, връзкатана жертвата може да понесе само 1% от прииждащия трафик. Тук, пакетите на атакуващият са толкова много, че ако има някъде легитимен пакет, на нормален юзър, няма как този пакет да успее да постигне нещо, докато бива мачкан от трафика на атакуващия.

Ако трябва да смятаме точно без закръгляне,

1024 мегабита правят 1 гигабит, 10 гигабита значи 10240 мегабита

10240 мегабита, делено на 100 мегабита - връзката на жертвата, реално не са 100 пъти, а 102,4 пъти, което значи, че връзката на жертвата не поема 1% а 0,8% - 0,9% от връзката, което практически утежнява положението.

III. Minimum Packet Size flood
Тази атака, също може да се изпълни само по UDP, и пак може да се спуфнат ип-та. В този тип атаки, не е нужно да наводнявате жертвата с безумни количества трафик. Това е по-изтънчен вариант, на горната атака, с не по-малки последици. Тази атака е създадена, за да саботира, всичко което работи с филтриране и разпределение на пакети, като залива рутера или Firewall или IPTables с голям брой пакети с минимален обем - 41 байта.

минималния обем на пакета е 41 байта

пращаме 1 байт информация
добавяме 20 байта за енкапсулране в UDP протокол със Source и Destination портове - стават 21 байта
добавяме 20 байта за енкапсуилиране в IP протокол със Source IP и Destination IP, TTL - стават 41 байта

За разлика от нормалния пакет който е 1500 байта

пращаме 1460 байта информация
добавяме 20 байта за енкапсулране в UDP протокол със Source и Destination портове - стават 1480 байта
добавяме 20 байта за енкапсуилиране в IP протокол със Source IP и Destination IP, TTL - стават 1500 байта

Такааа, сед като уточнихме пакетите, да видим каквае разликата в размера на пакетите - огромна - 1459 байта разлика, което значи че пакета с миминален обем е приблизително 36,6 пъти по-малък. тази подробност ще ни трябва след малко

Ако приемем че жертвата има 100 мегабита връзка, и направим още малко математика, 100 мегабита, делим на 8 за да обърнем битовете в байтове, и получаваме че жертвата може да прекара 12,5 мегабайта реални през тази връзка, говорейки за UDP. При ТСР прекарва по-малко от тези 12,5 заради обратния канал, acknowledgements, packet arrival sequence, transmission retry и другите щуротиики на ТСР които ги няма с UDP. Обърнато в брой пакети с нормален размер, това значи, че един пакет с нормален размер, е повече от един килобайт, 1024 байта = 1 килобайт, 1500 байта = 1,46 килобайта. а обърнем мегабайтите в килобайти, за да работим с единни единици за обем данни, 12,5мБ/сек умножаваме по 1024 - обръщаме мегабайтите в килобайти, и получаваме 12800 килобайта в секунда, делим на обема на пакета с нормален обем 12800/1,46 и получаваме, че за секунда, жертвата може да прекара 8767 пакета с нормален размер, и рутера или там каквато е защитата на жертвата, ще работи под номинално натоварване, и всикчо ще е ок. Обаче тове нормалният трансфер през УДП.

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

Както установихме преди малко, пакета с минимален обем, е с обем 41 байта, и е 36,6 пъти по-малък, което означава, че за да предадем същото количество информация с тия миниатюрни пакетчета, за същото време, ще ни трябват 36,6 пъти повече пакети, и тук става страшното. 8767 са пакетите с нормален обем, но имаме пакети с минимален, и искаме да прекараме същото количество информация, същите 12800 килобайта в секунда, с микроскопичните пакетчета това значи 36,6 пъти повече пакетчета, съответно имаме сметката 8767 умножено по 36,6 което значи 320 876 пакета постъпват в рутера за 1 секунда. Обикновено, обаче рутера се товари около 25 пъти, не 36,6, защото типичният рейтинг на рутера, е 80% нормални по размер пакети/20% минимални по обем пакети. натоварването идва от цялото това преглеждане и филтриране и преценяване на огромен брой малки пакетчета, отхвърлянето на огромна част от тях, които защитата не може да асоциира с нито с връзки нито с хостове след себе си, събирането на тези коит трябва да минат в буфери, декапсулирането им, изваждане на данните, преенкапсулиране в нови пакети с нормален обем, които да бъдат, предадени във вътрешната мрежа ако някой ги очаква, целия тоя къртовск труд трябва да се свърши от рутера или защитата, и докато те правят това, фитриране прекапсулиране, сортиране.... и ако това е 100 мегабита атакуващ трафик, към защитата, просто защитата в един момент се вижда в чудо и в приключение с неизвестен край, докато се оправи с тоя кошмар от огромни бойки, запълнили всички възможни буфери пакетчета с минимален обем. това може и да не задържи жертвата без интернет, но връзката на жертвата, ще е достатъчно бавна, за да е практически неизползваема.