Variti развива заштита од ботови и DDoS напади, а исто така спроведува и тестирање на стрес и оптоварување. На конференцијата HighLoad++ 2018 зборувавме за тоа како да ги обезбедиме ресурсите од разни видови напади. Накратко: изолирајте делови од системот, користете облак услуги и CDN и ажурирајте редовно. Но, сепак нема да можете да се справите со заштитата без специјализирани компании :)
Пред да го прочитате текстот, можете да ги прочитате кратките апстракти .
А ако не сакате да читате или само сакате да го гледате видеото, снимката од нашата репортажа е подолу под спојлерот.
Видео снимка од извештајот
Многу компании веќе знаат како да направат тестирање на оптоварување, но не сите прават стрес-тестирање. Некои од нашите клиенти мислат дека нивната страница е неранлива затоа што имаат систем за високо оптоварување и добро заштитува од напади. Покажуваме дека тоа не е сосема точно.
Се разбира, пред да извршиме тестови, добиваме дозвола од клиентот, потпишана и со печат, а со наша помош не може да се изврши DDoS напад врз никого. Тестирањето се врши во време избрано од клиентот, кога сообраќајот до неговиот ресурс е минимален, а проблемите со пристапот нема да влијаат на клиентите. Дополнително, бидејќи нешто секогаш може да тргне наопаку за време на процесот на тестирање, имаме постојан контакт со клиентот. Ова ви овозможува не само да ги пријавите постигнатите резултати, туку и да промените нешто за време на тестирањето. По завршувањето на тестирањето, ние секогаш подготвуваме извештај во кој укажуваме на сите пронајдени недостатоци и даваме препораки за отстранување на слабостите на страницата.
Како работиме
Кога тестираме, имитираме ботнет. Бидејќи работиме со клиенти кои не се лоцирани на нашите мрежи, за да се осигураме дека тестот нема да заврши во првата минута поради активирање на ограничувања или заштита, ние го снабдуваме оптоварувањето не од една IP адреса, туку од нашата сопствена подмрежа. Плус, за да создадеме значителен товар, имаме свој прилично моќен тест-сервер.
Постулати
Премногу не значи добро
Колку помалку оптоварување можеме да донесеме ресурс до неуспех, толку подобро. Ако можете да ја натерате страницата да престане да функционира на едно барање во секунда, па дури и на едно барање во минута, тоа е одлично. Бидејќи според законот за подлост, корисниците или напаѓачите случајно ќе паднат во оваа конкретна ранливост.
Делумниот неуспех е подобар од целосниот неуспех
Секогаш советуваме системите да бидат хетерогени. Покрај тоа, вреди да се одвојат на физичко ниво, а не само со контејнеризација. Во случај на физичко одвојување, дури и ако нешто не успее на страницата, постои голема веројатност таа да не престане целосно да работи, а корисниците ќе продолжат да имаат пристап барем до дел од функционалноста.
Добрата архитектура е основа за одржливост
Толеранцијата на грешки на еден ресурс и неговата способност да издржи напади и оптоварувања треба да се утврдат во фазата на дизајнирање, всушност, во фазата на цртање на првите графикони на текови во тетратка. Затоа што ако навлезат фатални грешки, можно е да се поправат во иднина, но тоа е многу тешко.
Не само кодот треба да биде добар, туку и конфигурацијата
Многу луѓе мислат дека добар тим за развој е гаранција за услуга толерантна за грешки. Добар тим за развој е навистина неопходен, но мора да има и добри операции, добри DevOps. Односно, ни требаат специјалисти кои правилно ќе ги конфигурираат Linux и мрежата, правилно ќе пишуваат конфигурации во nginx, ќе поставуваат ограничувања итн. Во спротивно, ресурсот ќе работи добро само при тестирање, а во одреден момент сè ќе се скрши во производството.
Разлики помеѓу оптоварување и стрес-тестирање
Тестирањето за оптоварување ви овозможува да ги идентификувате границите на функционирањето на системот. Стрес-тестирањето е насочено кон пронаоѓање на слабости во системот и се користи за да се разбие овој систем и да се види како ќе се однесува во процесот на откажување на одредени делови. Во овој случај, природата на товарот обично останува непозната за клиентот пред да започне стрес-тестирањето.
Карактеристични карактеристики на нападите L7
Обично ги делиме типовите на оптоварување на товари на нивоата L7 и L3&4. L7 е оптоварување на ниво на апликација, најчесто значи само HTTP, но ние мислиме на секое оптоварување на ниво на протокол TCP.
L7 нападите имаат одредени карактеристични карактеристики. Прво, тие доаѓаат директно во апликацијата, односно, малку е веројатно дека ќе се рефлектираат преку мрежни средства. Ваквите напади користат логика и поради тоа многу ефикасно и со мал сообраќај трошат процесор, меморија, диск, база на податоци и други ресурси.
HTTP Flood
Во случај на каков било напад, товарот е полесно да се создаде отколку да се справи, а во случајот со L7 тоа е исто така точно. Не е секогаш лесно да се разликува нападниот сообраќај од легитимен сообраќај и најчесто тоа може да се направи по фреквенција, но ако сè е правилно испланирано, тогаш од дневниците е невозможно да се разбере каде е нападот и каде се легитимните барања.
Како прв пример, разгледајте го нападот HTTP Flood. Графиконот покажува дека таквите напади обично се многу моќни; во примерот подолу, максималниот број на барања надмина 600 илјади во минута.
HTTP Flood е најлесниот начин да се создаде оптоварување. Вообичаено, потребно е некој вид алатка за тестирање на оптоварување, како што е ApacheBench, и поставува барање и цел. Со таков едноставен пристап, постои голема веројатност да се вклучи во кеширањето на серверот, но лесно е да се заобиколи. На пример, додавање на случајни низи на барањето, што ќе го принуди серверот постојано да опслужува нова страница.
Исто така, не заборавајте за корисничкиот агент во процесот на создавање товар. Многу кориснички агенти на популарни алатки за тестирање се филтрирани од системските администратори и во овој случај оптоварувањето може едноставно да не стигне до задниот дел. Можете значително да го подобрите резултатот со вметнување на повеќе или помалку валидно заглавие од прелистувачот во барањето.
Колку и да се едноставни нападите на HTTP Flood, тие имаат и свои недостатоци. Прво, потребни се големи количини на енергија за да се создаде товарот. Второ, ваквите напади се многу лесно за откривање, особено ако доаѓаат од една адреса. Како резултат на тоа, барањата веднаш почнуваат да се филтрираат или од системски администратори или дури и на ниво на провајдер.
Што да барате
За да го намалите бројот на барања во секунда без да ја изгубите ефикасноста, треба да покажете малку имагинација и да ја истражите страницата. Така, можете да го вчитате не само каналот или серверот, туку и поединечни делови од апликацијата, на пример, бази на податоци или датотечни системи. Можете исто така да барате места на страницата што прават големи пресметки: калкулатори, страници за избор на производи итн. Конечно, често се случува страницата да има некаква PHP скрипта која генерира страница од неколку стотици илјади линии. Таквата скрипта, исто така, значително го вчитува серверот и може да стане цел за напад.
Каде да барате
Кога скенираме ресурс пред тестирање, прво гледаме, се разбира, на самата локација. Бараме секакви полиња за внесување, тешки датотеки - воопшто, сè што може да создаде проблеми за ресурсот и да го забави неговото работење. Баналните алатки за развој во Google Chrome и Firefox помагаат овде, прикажувајќи го времето на одговор на страницата.
Ние, исто така, скенираме поддомени. На пример, постои одредена онлајн продавница, abc.com, и има поддомен admin.abc.com. Најверојатно, ова е административен панел со овластување, но ако ставите оптоварување на него, може да создаде проблеми за главниот ресурс.
Веб-страницата може да има поддомен api.abc.com. Најверојатно, ова е ресурс за мобилни апликации. Апликацијата може да се најде во App Store или Google Play, да инсталирате специјална пристапна точка, да го расклопите API-то и да регистрирате тест-сметки. Проблемот е што луѓето често мислат дека сè што е заштитено со овластување е имуно на напади со одбивање на услугата. Наводно, авторизацијата е најдобрата CAPTCHA, но не е. Лесно е да се направат 10-20 тест-сметки, но со нивното создавање, добиваме пристап до сложена и нескриена функционалност.
Секако, ја разгледуваме историјата, на robots.txt и WebArchive, ViewDNS и бараме стари верзии на ресурсот. Понекогаш се случува програмерите да имаат пуштено во продажба, да речеме, mail2.yandex.net, но старата верзија, mail.yandex.net, останува. Овој mail.yandex.net повеќе не е поддржан, ресурсите за развој не се доделуваат на него, но продолжува да ја троши базата на податоци. Соодветно на тоа, користејќи ја старата верзија, можете ефективно да ги користите ресурсите на заднината и сè што стои зад распоредот. Се разбира, ова не се случува секогаш, но сепак се среќаваме со ова доста често.
Секако, ги анализираме сите параметри на барањето и структурата на колачињата. Можете, да речеме, да фрлите одредена вредност во низата JSON во колаче, да создадете многу вгнездени и да го натерате ресурсот да работи неразумно долго време.
Пребарување оптоварување
Првото нешто што ви паѓа на ум при истражување на страницата е да ја вчитате базата на податоци, бидејќи скоро секој има пребарување, а скоро за сите, за жал, тоа е слабо заштитено. Поради некоја причина, програмерите не посветуваат доволно внимание на пребарувањето. Но, тука има една препорака - не треба да правите барања од ист тип, бидејќи може да наидете на кеширање, како што е случајот со HTTP flood.
Поставувањето случајни прашања во базата на податоци исто така не е секогаш ефективно. Многу е подобро да креирате листа на клучни зборови кои се релевантни за пребарувањето. Ако се вратиме на примерот на онлајн продавница: да речеме дека страницата продава автомобилски гуми и ви овозможува да го поставите радиусот на гумите, типот на автомобилот и други параметри. Според тоа, комбинациите на релевантни зборови ќе ја принудат базата на податоци да работи во многу посложени услови.
Дополнително, вреди да се користи пагинација: за пребарување е многу потешко да се врати претпоследната страница од резултатите од пребарувањето од првата. Тоа е, со помош на пагинација можете малку да го диверзифицирате товарот.
Примерот подолу го покажува оптоварувањето на пребарувањето. Може да се види дека од првата секунда на тестот со брзина од десет барања во секунда, страницата слезе и не реагираше.
Ако нема пребарување?
Ако нема пребарување, тоа не значи дека страницата не содржи други ранливи полиња за внесување. Ова поле може да биде авторизација. Во денешно време, програмерите сакаат да прават сложени хаши за да ја заштитат базата на податоци за најавување од напад на табелата со виножито. Ова е добро, но таквите хаши трошат многу ресурси на процесорот. Голем проток на лажни овластувања доведува до дефект на процесорот и како резултат на тоа, страницата престанува да работи.
Присуството на страницата на секакви форми за коментари и повратни информации е причина да се испратат многу големи текстови таму или едноставно да се создаде огромна поплава. Понекогаш сајтовите прифаќаат прикачени датотеки, вклучително и во формат gzip. Во овој случај, земаме датотека од 1 TB, ја компресираме на неколку бајти или килобајти користејќи gzip и ја испраќаме на страницата. Потоа се отпакува и се добива многу интересен ефект.
Одморете API
Би сакал да обрнам малку внимание на такви популарни услуги како Rest API. Обезбедувањето на Rest API е многу потешко од обична веб-локација. Дури и тривијалните методи за заштита од брутална сила со лозинка и други нелегитимни активности не функционираат за Rest API.
АПИ-то за одмор е многу лесно да се прекине бидејќи директно пристапува до базата на податоци. Во исто време, неуспехот на таква услуга повлекува доста сериозни последици за бизнисот. Факт е дека Rest API обично се користи не само за главната веб-локација, туку и за мобилната апликација и некои внатрешни деловни ресурси. И ако сето ова падне, тогаш ефектот е многу посилен отколку во случај на едноставен дефект на веб-страницата.
Се вчитува тешка содржина
Ако ни се понуди да тестираме некоја обична апликација на една страница, веб-страница за целна страница или визит-картичка која нема сложена функционалност, бараме тешка содржина. На пример, големи слики што ги испраќа серверот, бинарни датотеки, pdf документација - се обидуваме да го преземеме сето ова. Таквите тестови добро го вчитуваат датотечниот систем и ги затнуваат каналите и затоа се ефективни. Односно, дури и ако не го спуштите серверот, преземајќи голема датотека со мала брзина, едноставно ќе го затнете каналот на целниот сервер и тогаш ќе се случи одбивање на услугата.
Пример за таков тест покажува дека со брзина од 30 RPS страницата престанала да реагира или произведе 500-ти серверски грешки.
Не заборавајте за поставување сервери. Често може да откриете дека некој купил виртуелна машина, инсталирал Apache таму, конфигурирал сè стандардно, инсталирал PHP апликација и подолу можете да го видите резултатот.
Тука товарот отиде до коренот и изнесуваше само 10 RPS. Чекавме 5 минути и серверот падна. Точно е дека не е целосно познато зошто паднал, но постои претпоставка дека едноставно имал премногу меморија и затоа престанал да реагира.
Врз основа на бранови
Во последните година или две, нападите со бранови станаа доста популарни. Ова се должи на фактот што многу организации купуваат одредени делови од хардвер за DDoS заштита, за кои е потребно одредено време за да се акумулира статистика за да се започне со филтрирање на нападот. Односно, тие не го филтрираат нападот во првите 30-40 секунди, бидејќи акумулираат податоци и учат. Според тоа, во овие 30-40 секунди можете да стартувате толку многу на страницата што ресурсот ќе лежи долго време додека не се исчистат сите барања.
Во случајот со нападот подолу, имаше интервал од 10 минути, по што пристигна нов, изменет дел од нападот.
Односно, одбраната научи, почна да се филтрира, но пристигна нов, сосема поинаков дел од нападот и одбраната повторно почна да учи. Всушност, филтрирањето престанува да работи, заштитата станува неефикасна, а страницата е недостапна.
Нападите на брановите се карактеризираат со многу високи вредности на врвот, може да достигне сто илјади или милион барања во секунда, во случајот со L7. Ако зборуваме за L3&4, тогаш може да има стотици гигабити сообраќај, или, соодветно, стотици mpps, ако броите во пакети.
Проблемот со ваквите напади е синхронизацијата. Нападите доаѓаат од ботнет и бараат висок степен на синхронизација за да се создаде многу голем еднократен скок. И оваа координација не секогаш функционира: понекогаш излезот е некој вид параболичен врв, кој изгледа прилично патетично.
Не само HTTP
Покрај HTTP на L7, сакаме да експлоатираме и други протоколи. Како по правило, на обична веб-локација, особено на обичен хостинг, има протоколи за пошта и MySQL. Протоколите за пошта подлежат на помалку оптоварување од базите на податоци, но тие исто така можат да се вчитаат доста ефикасно и да завршат со преоптоварен процесор на серверот.
Бевме доста успешни користејќи ја ранливоста на SSH од 2016 година. Сега оваа ранливост е поправена за речиси сите, но тоа не значи дека оптоварувањето не може да се поднесе до SSH. Може. Едноставно има огромен товар на овластувања, SSH го јаде речиси целиот процесор на серверот, а потоа веб-локацијата пропаѓа од едно или две барања во секунда. Според тоа, овие едно или две барања засновани на дневниците не можат да се разликуваат од легитимно оптоварување.
Многу врски што ги отвораме во серверите исто така остануваат релевантни. Претходно, Apache беше виновен за ова, сега nginx е всушност виновен за ова, бидејќи честопати е стандардно конфигуриран. Бројот на конекции што nginx може да ги одржува отворени е ограничен, така што го отвораме овој број на конекции, nginx повеќе не прифаќа нова врска и како резултат на тоа, страницата не работи.
Нашиот тест кластер има доволно процесор за напад на SSL ракување. Во принцип, како што покажува практиката, и ботнетовите понекогаш сакаат да го прават тоа. Од една страна, јасно е дека не можете без SSL, бидејќи резултатите на Google, рангирањето, безбедноста. Од друга страна, SSL за жал има проблем со процесорот.
L3&4
Кога зборуваме за напад на нивоата L3&4, обично зборуваме за напад на ниво на врска. Таквото оптоварување речиси секогаш се разликува од легитимното, освен ако не е напад од SYN-flood. Проблемот со SYN-flood нападите за безбедносни алатки е нивниот голем волумен. Максималната вредност на L3&4 беше 1,5-2 Tbit/s. Овој вид сообраќај е многу тежок за обработка дури и за големите компании, вклучувајќи ги Oracle и Google.
SYN и SYN-ACK се пакети кои се користат при воспоставување врска. Затоа, SYN-flood е тешко да се разликува од легитимно оптоварување: не е јасно дали ова е SYN што дошол да воспостави врска или дел од поплава.
UDP-поплава
Вообичаено, напаѓачите ги немаат способностите што ги имаме ние, така што засилувањето може да се користи за организирање напади. Односно, напаѓачот го скенира Интернетот и наоѓа или ранливи или неправилно конфигурирани сервери кои, на пример, како одговор на еден SYN пакет, одговараат со три SYN-ACK. Со измама на изворната адреса од адресата на целниот сервер, можно е да се зголеми моќноста, на пример, три пати со еден пакет и да се пренасочи сообраќајот кон жртвата.
Проблемот со засилувањата е што тешко се откриваат. Неодамнешните примери го вклучуваат сензационалниот случај на ранливите мемкеширани. Плус, сега има многу IoT уреди, IP камери, кои исто така се главно стандардно конфигурирани, а стандардно се погрешно конфигурирани, поради што напаѓачите најчесто прават напади преку такви уреди.
Тешко SYN-поплава
SYN-flood е веројатно најинтересниот тип на напад од гледна точка на развивачите. Проблемот е што системските администратори често користат блокирање на IP за заштита. Покрај тоа, блокирањето на IP влијае не само на системските администратори кои дејствуваат користејќи скрипти, туку и, за жал, на некои безбедносни системи што се купени за многу пари.
Овој метод може да се претвори во катастрофа, бидејќи ако напаѓачите ги заменат IP адресите, компанијата ќе ја блокира сопствената подмрежа. Кога заштитниот ѕид го блокира сопствениот кластер, излезот ќе пропадне во надворешните интеракции и ресурсот ќе пропадне.
Покрај тоа, не е тешко да ја блокирате сопствената мрежа. Ако канцеларијата на клиентот има Wi-Fi мрежа или ако перформансите на ресурсите се мери со користење на различни системи за следење, тогаш ја земаме IP адресата на овој систем за следење или на канцеларијата на клиентот Wi-Fi и ја користиме како извор. На крајот, се чини дека ресурсот е достапен, но целните IP адреси се блокирани. Така, Wi-Fi мрежата на конференцијата HighLoad, каде што се презентира новиот производ на компанијата, може да биде блокирана, а тоа повлекува одредени деловни и економски трошоци.
За време на тестирањето, не можеме да користиме засилување преку memcached со какви било надворешни ресурси, бидејќи има договори да се испраќа сообраќај само до дозволените IP адреси. Според тоа, ние користиме засилување преку SYN и SYN-ACK, кога системот реагира на испраќање на еден SYN со два или три SYN-ACK, а на излезот нападот се множи со два или три пати.
Алатки
Една од главните алатки што ги користиме за обемот на работа L7 е Yandex-tank. Особено, фантом се користи како пиштол, плус има неколку скрипти за генерирање касети и за анализа на резултатите.
Tcpdump се користи за анализа на мрежниот сообраќај, а Nmap се користи за анализа на серверот. За да се создаде оптоварување на ниво L3&4, се користи OpenSSL и малку од нашата сопствена магија со библиотеката DPDK. DPDK е библиотека од Интел која ви овозможува да работите со мрежниот интерфејс заобиколувајќи го стекот на Linux, а со тоа ја зголемувате ефикасноста. Секако, ние користиме DPDK не само на ниво L3&4, туку и на ниво L7, бидејќи ни овозможува да создадеме многу висок проток на оптоварување, во опсег од неколку милиони барања во секунда од една машина.
Ние исто така користиме одредени сообраќајни генератори и специјални алатки кои ги пишуваме за специфични тестови. Ако се потсетиме на ранливоста под SSH, тогаш горното множество не може да се експлоатира. Ако го нападнеме протоколот за пошта, земаме алатки за пошта или едноставно пишуваме скрипти на нив.
Наоди
Како заклучок би сакал да кажам:
- Покрај класичното тестирање на оптоварување, неопходно е да се спроведе и стрес-тестирање. Имаме вистински пример каде подизведувачот на партнерот извршил само тестирање на оптоварување. Покажа дека ресурсот може да го издржи нормалното оптоварување. Но, тогаш се појави ненормално оптоварување, посетителите на страницата почнаа да го користат ресурсот малку поинаку, и како резултат на тоа, подизведувачот лежеше. Така, вреди да се бараат ранливости дури и ако веќе сте заштитени од DDoS напади.
- Неопходно е да се изолираат некои делови од системот од други. Ако имате пребарување, треба да го преместите на посебни машини, односно дури ни во Docker. Затоа што ако пребарувањето или овластувањето не успеат, барем нешто ќе продолжи да работи. Во случај на онлајн продавница, корисниците ќе продолжат да наоѓаат производи во каталогот, да одат од агрегаторот, да купуваат ако се веќе овластени или да авторизираат преку OAuth2.
- Не ги занемарувајте сите видови облак услуги.
- Користете го CDN не само за да ги оптимизирате доцнењата на мрежата, туку и како средство за заштита од напади на исцрпување на каналот и едноставно преплавување во статичен сообраќај.
- Неопходно е да се користат специјализирани услуги за заштита. Не можете да се заштитите од нападите L3&4 на ниво на канал, бидејќи најверојатно едноставно немате доволен канал. Исто така, веројатно нема да се борите со нападите L7, бидејќи тие можат да бидат многу големи. Плус, потрагата по мали напади е сè уште привилегија на специјалните служби, специјалните алгоритми.
- Редовно ажурирајте. Ова не се однесува само на кернелот, туку и на демонот на SSH, особено ако ги имате отворени кон надвор. Во принцип, сè треба да се ажурира, бидејќи веројатно нема да можете сами да следите одредени пропусти.
Извор: www.habr.com