[Технически анализ] Задълбочено и лесно за разбиране: Въведение в атаката на мрежови атаки и защита

DDoS атаките (Distributed Denial of Service) са едни от най-мощните и трудни за защита, защото основната цел на DDoS атаките е да предотвратят определена цел да предоставя нормални услуги или дори да изчезне от интернет.

DDoS може просто да се раздели на три категории според начина, по който са инициирани.

Първата категория печели със силаМасивни пакети данни се струват от всички краища на Интернет, блокирайки входа на IDC, правейки различни мощни хардуерни защитни системи и бързи и ефективни аварийни процеси безполезни. Типични примери за този тип атака са ICMP Flood и UDP Flood, които сега са рядкост.

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

Третата категория е смесица от горните двеТой не само се възползва от недостатъците на протокола и системата, но и има голям обем трафик, като SYN Flood атака и DNS Query Flood, която е настоящият основен метод на атака.

Тази статия ще опише тези най-често срещани и представителни методи на атака един по един и ще представи техните защитни опции.

SYN Flood е една от най-класическите DDoS атаки в интернет, появяваща се за първи път около 1999 г., като Yahoo е най-известната жертва по това време. SYN Flood атаките експлоатират тройните ръкостискания на TCP недостатъци, които могат да направят целевия сървър неотзивчив и труден за проследяване при малка цена.

Стандартният процес на TCP тристранно ръкостискане е следният:

• Клиентът изпраща TCP пакет, съдържащ SYN флага, SYN се синхронизира, а синхронизационният пакет показва порта, използван от клиента, и началния сериен номер на TCP връзката.
• След получаване на SYN пакета от клиента, сървърът ще върне пакет SYN+ACK (т.е. потвърждение на потвърждение), което показва, че заявката на клиента е приета, а началният сериен номер на TCP автоматично се добавя с 1.
• Клиентът също така връща потвърдително съобщение ACK към сървъра, а серийният номер на TCP също се добавя с 1.
  

След тези три стъпки се установява TCP връзката. За да се постигне надеждно предаване, протоколът TCP е създал някои механизми за обработка на изключения по време на трите ръкостискания. В третата стъпка, ако сървърът не получи последния ACK пакет за потвърждение от клиента, сървърът остава в състояние SYN_RECV, добавя IP адреса на клиента към списъка с чакащи и ще изпрати отново пакета SYN+ACK във втората стъпка. Повторните публикации обикновено се правят 3-5 пъти, а списъкът с чакащи се анкетира веднъж на интервали от около 30 секунди, за да се опита отново всички клиенти. От друга страна, след като сървърът изпрати пакета SYN+ACK, той предварително разпределя ресурси за съхранение на информация за предстоящата TCP връзка, която се запазва, докато чака повторния опит. По-важното е, че ако ресурсите на сървъра са ограничени, SYN_RECV състояние, което може да се поддържа, вече няма да приема нови SYN пакети след превишаване на лимита, тоест нови TCP връзки ще бъдат отхвърлени.

SYN Flood използва горните настройки на TCP протокола, за да постигне целта на атаката. Нападателите прикриват голям брой IP адреси, за да изпращат SYN пакети към сървъра, а тъй като фалшивите IP адреси са почти невъзможни за съществуване, почти никое устройство не връща отговор към сървъра. В резултат на това сървърът поддържа огромен списък на чакащите и постоянно се опитва да изпрати SYN+ACK пакети, което изразходва много ресурси и не може да бъде пуснато. Още по-важно е, че опашката SYN_RECV на атакувания сървър е пълна със злонамерени пакети, новите SYN заявки вече не се приемат, а легитимните потребители не могат да извършат три ръкостискания, за да установят TCP връзки. С други думи, сървърът беше отказан от услуга от SYN Flood.

Ако се интересувате от SYN Flood, можете да разгледате http://www.icylife.net/yunshu/show.php?id=367, който написах през 2006 г., който по-късно направих няколко промени, оправих бъгове и намалих агресивността, и беше използван изцяло за тестване.

Като най-основната и основна услуга в Интернет, DNS естествено е една от важните цели на DDoS атаки. Премахването на DNS услуга може косвено да доведе до срив на целия бизнес на компанията или на мрежова услуга в даден регион. Преди известно време популярната хакерска група anonymous също обяви, че ще атакува 13 DNS сървъра в глобалния интернет, но в крайна сметка не успя.

UDP атаките са най-лесният метод за атака за иницииране на огромен трафик, а случайното фалшифициране на IP адреси е трудно за проследяване. Въпреки това, филтрирането е по-лесно, защото повечето IP адреси не предоставят UDP услуги, така че можете просто да изхвърлите UDP трафика. Затова чистите атаки с UDP трафик вече са сравнително редки и са заменени от DNS Query Flood атаки, пренесени от UDP протокола. Просто казано, DDoS атаките, започнати срещу протокола, колкото по-висок е протоколът, толкова по-трудно е да се защити, защото колкото по-висок е протоколът, толкова по-бизнес е свързан и толкова по-сложна е защитната система.

DNS Query Flood е, когато нападател манипулира голям брой sockpuppet машини, за да стартира голям брой заявки за домейн име към целевата цел. За да се предотврати филтриране, базирано на ACL, случайността на пакетите трябва да се подобри. Често срещана практика е случайно да се фалшифицира изходният IP адрес, да се фалшифицира изходният порт и други параметри на UDP слоя. На слоя DNS протокол ID-то на заявката се фалшифицира случайно заедно с домейн името, което трябва да бъде разрешено. Освен че предотвратява филтрирането, случайно фалшифицираните домейн имена, които трябва да бъдат разрешени, могат също да намалят вероятността да попаднат в DNS кеша и да изразходват колкото се може повече CPU ресурси на DNS сървъра.

Относно кода за DNS Query Flood, написах код през юли 2011 г., за да тествам производителността на сървъра, и линкът е http://www.icylife.net/yunshu/show.php?id=832. По същия начин този код е изкуствено по-малко агресивен и е предназначен само за тестови цели.

SYN Flood и DNS Query Flood, описани по-горе, могат ефективно да бъдат защитени на този етап, а истинското главоболие за големите производители и интернет компании са атаките с HTTP Flood. HTTP Flood е атака срещу уеб услуга върху протокол от седмия слой. Голямата му вреда се проявява основно в три аспекта: удобно иницииране, трудно филтриране и далечно въздействие.

И SYN Flood, и DNS Query Flood изискват нападателите да контролират голям брой ботове с root привилегии. Събирането на голям брой root привилегии отнема време и усилия, а по време на атаката машината с марионетки се възстановява бавно поради бързата загуба на ресурси от нападателя поради ненормален трафик, открит от администратора, което води до значително намаляване на интензивността на атаката и не може да се поддържа дълго време. HTTP Flood атаките са различни – нападателите не трябва да контролират голям брой ботове, а вместо това използват порт скенери, за да открият анонимни HTTP проксита или SOCKS проксита в интернет, чрез които нападателят инициира HTTP заявки към целта. Анонимните проксита са сравнително богат ресурс и не е трудно да се получат проксита за няколко дни, така че атаките са лесни за започване и могат да продължат дълго време.

От друга страна, HTTP flood атаките се стартират на HTTP слоя, който енергично имитира поведението на уеб страници при заявки на обикновените потребители, което е тясно свързано с бизнеса на уебсайта, което затруднява доставчиците на сигурност да предоставят общо решение, което да не влияе на потребителското изживяване. Правила, които работят добре на едно място, променящите се сценарии могат да доведат до голям брой случаи на непредумишлено убийство.

Накрая, HTTP flood атаките могат да предизвикат сериозни верижни реакции, не само директно причинявайки бавен отговор от атакувания уеб интерфейс, но и косвено атакуващи бекенд Java и други бизнес логически и бази данни, увеличавайки натиска им и дори засягайки сървърите за логове.

Интересното е, че HTTP Flood има и исторически прякор, наречен CC атака. CC е съкращение от Challenge Collapsar, което е DDoS защитно устройство от известна китайска компания за сигурност. Съдейки по настоящата ситуация, не само Collapsar, но и цялото хардуерно отбранително оборудване все още е подложено на предизвикателство и рискът не е премахнат.

Когато става въпрос за атаки, първата реакция е огромен трафик и огромни пакети. Но има атака, която прави обратното, известна с това, че е бавна, така че някои цели са убити, без да знаят как умират, а именно бавната връзка атака, най-представителната е Slowloris, изобретена от rsnake.

HTTP протоколът постановява, че HTTP заявките завършват на \r\n\r\n, което означава, че клиентът е приключил с изпращането и сървърът е започнал обработка. Какво става, ако никога не изпратиш \r\n\r\n? Slowloris използва това в своя полза при DDoS атаки. Нападателят задава Connection на Keep-Alive в HTTP заявката заглавие, моли уеб сървъра да запази TCP връзката несвързана и след това бавно изпраща формат с ключова стойност към сървъра на всеки няколко минути, като a:b\r\n, карайки сървъра да мисли, че HTTP заглавието не е получено и чака. Ако нападателят използва мултитрединг или марионетка за същото, уеб контейнерът на сървъра бързо ще бъде претоварен от нападателя и вече няма да приема нови заявки.

Скоро започнаха да се появяват различни варианти на Слоулорис. Например, методът POST подава данни към уеб сървъра, запълва голям Content-Length, но бавен байт по байт POST реално съдържание на данни и т.н. Относно атаката на Slowloris, rsnake също дава тестов код, виж http://ha.ckers.org/slowloris/slowloris.pl.

Горното въвежда няколко основни метода за атака, всеки от които може да се използва за атака на мрежата и дори за победа над гигантски уебсайтове като Alibaba, Baidu и Tencent. Но това не е всичко, различни нива на нападатели могат да извършват напълно различни DDoS атаки, а използването им е едно и също.

Напредналите нападатели никога не използват един вектор за атака, а ги комбинират гъвкаво според целевата среда. Обикновеният SYN Flood е лесен за филтриране от устройства за почистване на трафика чрез обратно детекция, SYN бисквитки и други технически средства, но ако SYN+ACK пакетите се смесят в SYN Flood, така че всеки фалшифициран SYN пакет да има съответния фалшифициран клиентски пакет за потвърждение, съответстващият тук се отнася до изходния IP адрес, изходния порт, дестинационния IP, дестинационния порт, размера на TCP прозореца, TTL и др., които са в съответствие с характеристиките на един и същ хост и същия TCP поток. Натискът върху производителността на обратното детекция и SYN бисквитките на оборудването за почистване на потока ще се увеличи значително. Всъщност, SYN пакетите с данни и различни други флагови битове имат специални ефекти на атака, които тук не са въведени. Съществуват и уникални техники за DNS Query Flood.

Първо, DNS може да бъде разделен на обикновен DNS и оторизиран домейн DNS, като атакува обикновен DNS, IP адресът трябва да бъде фалшифициран на случаен принцип, а сървърът изисква рекурсивна резолюция; Въпреки това, при атака на разрешения домейн DNS, фалшифицираният изходен IP адрес не трябва да бъде изцяло случаен, а трябва да бъде DNS адресите на интернет доставчиците по целия свят, събрани предварително, за да се постигне максимален ефект на атаката, така че устройството за почистване на трафика да бъде в неудобна ситуация да добави IP черен списък или да не добави IP черен списък. Добавянето му ще доведе до голям брой непредумишлени убийства, а ако не добавите черен списък, всеки пакет трябва да бъде обърнат от проверка, което увеличава натиска върху производителността.

От друга страна, както беше споменато по-рано, за да се увеличи напрежението при почистване на устройството, е необходимо да се рандомизира поисканото домейн име без да се достигне кешът, но трябва да се отбележи, че домейн името, което трябва да бъде разрешено, трябва да има определена редовност във фалшифицирането, като например фалшифициране само на определена част от домейна и укрепване на част, за да пробие белия списък, зададен от почистващото устройство. Причината е проста – сървърите на Tencent могат да разрешават само домейн имената на Tencent, а напълно случайните домейн имена могат да бъдат директно изхвърлени и да трябва да бъдат консолидирани. Но ако е напълно оправена, лесно може да бъде изхвърлена директно, затова трябва да бъде фалшифицирана.

Второ, атаките срещу DNS не трябва да се фокусират само върху UDP портове, които също са стандартни услуги според DNS протокола. В случай на атака могат да се извършват едновременно както UDP, така и TCP атаки.

Фокусът на HTTP Flood е да пробие кеша на фронтенда и да достигне директно до самия уеб сървър чрез настройките на полето в HTTP заглавието. Освен това, HTTP Flood е много важен за избора на цели, а обикновените нападатели избират страници, които изискват много заявки за данни, като например търсене като цел на атаката, което е много точно и може да изразходва колкото се може повече ресурси на сървъра. Но тази атака лесно се идентифицира чрез почистване на оборудване чрез идентификация човек-машина, така че как да се реши този проблем? Много е просто – опитайте се да изберете страници, до които обикновените потребители също имат достъп чрез приложението, общо взето, различни уеб API-та. Обикновените потребители и злонамереният трафик идват от приложението, а разликата между човек и машина е много малка и е трудно да се различи основната интеграция.

Всяка TCP връзка съществува от страна на сървъра и сама по себе си, и също така трябва да консумира ресурси, за да поддържа състоянието на TCP, така че връзката не може да се поддържа прекалено много. Ако това може да бъде решено, агресивността ще бъде значително увеличена, т.е. Slowloris може да извършва атаки без състояние, да улавя TCP серийния номер и да потвърди поддържането на TCP връзките на клиента чрез подсмукване, а системното ядро не трябва да обръща внимание на различни промени в състоянието на TCP, а лаптопът може да генерира до 65 535 TCP връзки.

Предишните описания са всички технически подобрения за атаки. От човешка страна има и други средства. Ако SYN Flood изпрати голям брой пакети и е придружен от бавни връзки на Slowloris, колко души ще открият тайната? Дори ако сървърът спре, може да се открият само SYN атаки, които се опитват да засилят почистването на TCP слоя и да игнорират поведението на приложния слой. Всички видове атаки могат да работят заедно, за да постигнат максимален ефект. Изборът на време на атака също е ключов момент, като например избора на персонал по поддръжката, когато обядват, когато техният персонал е заседнал на пътя след работа или когато няма сигнал на безжичната мрежа в метрото, както и когато целевото предприятие провежда мащабно събитие и трафикът се увеличава.

Това е чиста атака, затова не се предоставя код или задълбочено обяснение.

Предишните методи за атака изискваха повече или по-малко ботове, дори HTTP Flood изискваше търсене на голям брой анонимни проксита. Ако има атака, трябва само да издадете инструкции и машината автоматично ще се появи, за да я изпълни, което е перфектното решение. Тази атака вече се появи, и то от P2P мрежи.

Както всички знаем, P2P потребителите и трафикът в интернет са изключително голям брой. Ако всички отидат на определено място, за да изтеглят данни и да свързват хиляди реални IP адреси, никое устройство не може да го поддържа. Вземете BT download като пример – фалшифицирането на торенти на някои популярни видеа и публикуването им в търсачки е достатъчно, за да заблуди много потребители и трафик, но това е само основна атака.

Напредналите P2P атаки са директно фалшифициране на сървъри за управление на ресурси. Например, клиентът на Thunder ще качи намерените ресурси на сървъра за управление на ресурси и след това ще ги изпрати на други потребители, които трябва да изтеглят същите ресурси, така че да бъде публикуван линк. Чрез обръщане на протокола, нападателите фалшифицират голямо количество популярна ресурсна информация и я разпространяват чрез центъра за управление на ресурсите, който може да бъде незабавно разпространен из цялата P2P мрежа. Още по-страшно е, че тази атака не може да бъде спряна, дори от самия нападател, и тя продължава, докато P2P служителят не открие проблема и не обнови сървъра, а потребителят за изтегляне рестартира изтегления софтуер.

Това е всичко, което има в началото на DDoS атаките, и не искам да навлизам по-нататък — достатъчно е да разберем, че толкова много защита е достатъчна.

Общо взето, DDoS атаките могат да бъдат сръчни и грациозни. Красотата на приложението се крие в единството на ума.