Анатомия на атаки за отказ на услуга; Тестване на практика
Как и в кои моменти в системата може да възникне атака за отказ на услуга? Не само получаваме отговор от тази статия, но и за инструментите, които можем да използваме за тестване на DoS, DDoS атаки.
Моята статия се опитва да представи техническата основа на атаките за отказ на услуга (DoS). От една страна, обикалям какво имаме предвид под DoS и DDoS (разпределени DoS) атаки. По-късно, като се впусна малко по-дълбоко, ще обясня защо тези атаки са възможни и доколко технически работят. И накрая, разглеждаме възможните начини да се защитите, като подчертаваме най-иновативните налични решения.
Атаките за отказ на услуга са, когато един или повече нападатели правят недостъпни за услугите на клиентите, до които потребителите искат достъп. Интересното е, че ако нападателят извършва атака, това обикновено се извършва чрез стартиране на атакуващото устройство (което е специално проектиран софтуер) заедно по координиран начин. Най-запомнящият се пример за това е LOIC, създаден от групата Anonymous (произлизаща от съкращението „Low Orbit Ion Cannon“), която предприе атака срещу Църквата на сциентологията, RIAA (Американската асоциация на издателите) и организациите, атакуващи Wikileaks.
По-нататък ще говорим за мрежови услуги и защо те могат да станат недостъпни. Това може да се дължи, наред с други неща, на факта, че заявките, изпратени по мрежата, не достигат до сървъра или не могат да бъдат обработени от сървъра. Причините могат да включват честотна лента, междинно мрежово устройство или периодично претоварване на сървъра или срив и изключване на някакъв софтуер (уеб сървър, мениджър на база данни, уеб приложение), работещ на сървъра. Ние обработваме естеството на атаките в подходящия ред. За да остане не само на ниво теоретично обяснение, за всяка тема съм описал инструменти, с които читателят може да тества устойчивостта на собственото си приложение и инфраструктура срещу DoS и DDoS атаки.
Атаката на мрежово ниво е възможна от факта, че най-широко използваната в момента комбинация от мрежови протоколи се основава на TCP/IP за изграждане на един вид комуникационен канал (TCP сокет) между сървъра и клиента. При това т.нар. Извършва се TCP 3-посочно ръкостискане. Но какво се случва, ако клиентът никога не изпраща TCP пакет от третата стъпка? Ресурси (памет, CPU време) се разпределят към създадения сокет както на сървъра, така и на някои от междинните мрежови устройства. Те се освобождават само когато изтече зададеното време за изчакване и сървърът освободи ресурси. На ниво инфраструктура това изглежда така: Интернет инфраструктурата е разположена между клиентите (напр. Нападатели) и сървъра, маршрутизатора (ите) на доставчика, предоставящ IP адреса на сървъра, и компанията или организацията, които работят сървъра в добро В случая той също така използва защитна стена, IDS и вероятно IPS. Всяко от тях може да бъде засегнато от отказ на услуга и може да се превърне в пречка.
Програма, наречена hping3, която може да бъде извикана от честотната лента само когато е извикана със съответната параметризация (–flood). Очевиден начин да се защитите е да увеличите наличните ресурси или да намалите латентността за полуотворени TCP връзки. Съвременните мрежови устройства правят това възможно. Вижда се, че с този метод можем да увеличим ресурсните изисквания на атаката, но не постигаме промяна на величината. Промяната на величината изисква по-смело решение, което ще разгледам в края на статията. Блокирането на адреси на източника срещу интелигентни нападатели на практика не е добро решение, тъй като IP адресът на източника в IP пакетите може да бъде подправен. Атакуващият би могъл да използва това за първоначалната му цел, защото ако адресът на източника е фалшифициран постоянно до определен IP или обхват от адреси, той ще бъде забранен. Споменатият hping3 може също да измами адрес на източника, но е добре да знаете, че по-интелигентните рутери няма да позволят изходящи IP пакети, които не идват от диапазона, съответстващ на адреса на източника в IP пакета.