Variti razvija zaštitu od botova i DDoS napada, a također provodi testiranje stresa i opterećenja. Na konferenciji HighLoad++ 2018 govorili smo o tome kako zaštititi resurse od raznih vrsta napada. Ukratko: izolirajte dijelove sustava, koristite usluge u oblaku i CDN-ove i redovito ažurirajte. Ali ipak se nećete moći nositi sa zaštitom bez specijaliziranih tvrtki :)
Prije čitanja teksta možete pročitati kratke sažetke .
A ako ne volite čitati ili samo želite pogledati video, snimka naše reportaže je ispod pod spojlerom.
Video snimanje reportaže
Mnoge tvrtke već znaju kako napraviti testiranje opterećenja, ali ne rade sve testiranje otpornosti na stres. Neki od naših kupaca misle da je njihova stranica neranjiva jer imaju visokoopterećen sustav, a on dobro štiti od napada. Pokazujemo da to nije sasvim točno.
Naravno, prije provođenja testiranja dobivamo dopuštenje od korisnika, potpisano i pečatirano, te se uz našu pomoć ne može izvesti DDoS napad ni na koga. Testiranje se provodi u vrijeme koje odabere kupac, kada je promet na njegovom resursu minimalan, a problemi s pristupom neće utjecati na klijente. Osim toga, budući da uvijek nešto može poći po zlu tijekom procesa testiranja, imamo stalni kontakt s kupcem. To vam omogućuje ne samo izvješćivanje o postignutim rezultatima, već i promjenu nečega tijekom testiranja. Po završetku testiranja uvijek sastavljamo zapisnik u kojemu ukazujemo na uočene nedostatke i dajemo preporuke za otklanjanje nedostataka stranice.
Kako radimo
Prilikom testiranja emuliramo botnet. Budući da radimo s klijentima koji se ne nalaze na našim mrežama, kako bismo osigurali da test ne završi u prvoj minuti zbog ograničenja ili aktiviranja zaštite, ne dostavljamo opterećenje s jedne IP adrese, već iz vlastite podmreže. Osim toga, da bismo stvorili značajno opterećenje, imamo vlastiti prilično moćan testni poslužitelj.
Postulati
Previše ne znači dobro
Što manjim opterećenjem možemo dovesti resurs do kvara, to bolje. Ako možete učiniti da stranica prestane funkcionirati na jedan zahtjev u sekundi ili čak na jedan zahtjev u minuti, to je sjajno. Jer prema zakonu podlosti, korisnici ili napadači će slučajno pasti u ovu određenu ranjivost.
Djelomični neuspjeh je bolji od potpunog neuspjeha
Uvijek savjetujemo da sustavi budu heterogeni. Štoviše, vrijedi ih odvojiti na fizičkoj razini, a ne samo kontejnerizacijom. U slučaju fizičkog odvajanja, čak i ako nešto zakaže na stranici, velika je vjerojatnost da ona neće potpuno prestati raditi, a korisnici će i dalje imati pristup barem dijelu funkcionalnosti.
Dobra arhitektura temelj je održivosti
Tolerancija na greške resursa i njegova sposobnost da izdrži napade i opterećenja trebaju biti utvrđeni u fazi projektiranja, zapravo, u fazi crtanja prvih dijagrama toka u bilježnicu. Jer ako se fatalne greške potkradu, moguće ih je ispraviti u budućnosti, ali je to vrlo teško.
Ne samo da kod mora biti dobar, već i konfiguracija
Mnogi ljudi misle da je dobar razvojni tim jamstvo usluge otporne na greške. Dobar razvojni tim je zaista potreban, ali moraju postojati i dobre operacije, dobar DevOps. Odnosno, potrebni su nam stručnjaci koji će ispravno konfigurirati Linux i mrežu, ispravno napisati konfiguracije u nginx, postaviti ograničenja itd. U suprotnom, resurs će dobro raditi samo u testiranju, au nekom trenutku sve će se pokvariti u proizvodnji.
Razlike između testiranja opterećenja i testiranja stresa
Testiranje opterećenja omogućuje vam da identificirate granice funkcioniranja sustava. Testiranje otpornosti na stres je usmjereno na pronalaženje slabosti u sustavu i koristi se da se taj sustav razbije i vidi kako će se ponašati u procesu otkazivanja pojedinih dijelova. U ovom slučaju, priroda opterećenja obično ostaje nepoznata korisniku prije početka testiranja otpornosti na stres.
Posebnosti L7 napada
Vrste opterećenja obično dijelimo na opterećenja na razini L7 i L3&4. L7 je opterećenje na razini aplikacije, najčešće se misli samo na HTTP, ali mislimo na svako opterećenje na razini TCP protokola.
L7 napadi imaju određene karakteristične značajke. Prvo, dolaze izravno u aplikaciju, odnosno malo je vjerojatno da će se odraziti putem mreže. Takvi napadi koriste logiku i zbog toga troše CPU, memoriju, disk, bazu podataka i druge resurse vrlo učinkovito i uz malo prometa.
HTTP poplava
U slučaju bilo kojeg napada, opterećenje je lakše stvoriti nego nositi, au slučaju L7 to također vrijedi. Nije uvijek lako razlučiti napadni promet od legitimnog, a najčešće se to može učiniti po učestalosti, ali ako je sve dobro isplanirano, onda je iz logova nemoguće razabrati gdje je napad, a gdje legitimni zahtjevi.
Kao prvi primjer, razmotrite HTTP Flood napad. Grafikon pokazuje da su takvi napadi obično vrlo snažni, u donjem primjeru najveći broj zahtjeva premašio je 600 tisuća u minuti.
HTTP Flood je najlakši način za stvaranje opterećenja. Obično je potrebna neka vrsta alata za testiranje opterećenja, kao što je ApacheBench, i postavlja zahtjev i cilj. S takvim jednostavnim pristupom postoji velika vjerojatnost da ćete naletjeti na predmemoriranje poslužitelja, ali ga je lako zaobići. Na primjer, dodavanje nasumičnih nizova zahtjevu, što će prisiliti poslužitelj da stalno poslužuje novu stranicu.
Također, ne zaboravite na korisničkog agenta u procesu stvaranja opterećenja. Administratori sustava filtriraju mnoge korisničke agente popularnih alata za testiranje i u ovom slučaju opterećenje jednostavno ne može doći do pozadine. Možete značajno poboljšati rezultat umetanjem više ili manje važećeg zaglavlja iz preglednika u zahtjev.
Koliko god su HTTP Flood napadi jednostavni, oni također imaju svoje nedostatke. Prvo, potrebne su velike količine snage za stvaranje opterećenja. Drugo, takve je napade vrlo lako otkriti, pogotovo ako dolaze s jedne adrese. Kao rezultat toga, zahtjeve odmah počinju filtrirati ili administratori sustava ili čak na razini davatelja usluga.
Što tražiti
Da biste smanjili broj zahtjeva u sekundi bez gubitka učinkovitosti, morate pokazati malo mašte i istražiti mjesto. Dakle, možete učitati ne samo kanal ili poslužitelj, već i pojedinačne dijelove aplikacije, na primjer, baze podataka ili datotečne sustave. Također možete potražiti mjesta na web mjestu koja rade velike izračune: kalkulatore, stranice za odabir proizvoda itd. Na kraju, često se dogodi da stranica ima nekakvu PHP skriptu koja generira stranicu od nekoliko stotina tisuća redaka. Takva skripta također značajno opterećuje poslužitelj i može postati meta napada.
Gdje tražiti
Kada skeniramo resurs prije testiranja, prvo pogledamo, naravno, samu stranicu. Tražimo sve vrste polja za unos, teške datoteke - općenito, sve što može stvoriti probleme resursu i usporiti njegov rad. Banalni razvojni alati u Google Chromeu i Firefoxu pomažu ovdje, pokazujući vrijeme odziva stranice.
Također skeniramo poddomene. Na primjer, postoji određena online trgovina, abc.com, i ima poddomenu admin.abc.com. Najvjerojatnije je ovo administratorska ploča s autorizacijom, ali ako je opteretite, može stvoriti probleme za glavni resurs.
Stranica može imati poddomenu api.abc.com. Najvjerojatnije je ovo resurs za mobilne aplikacije. Aplikaciju možete pronaći u App Storeu ili Google Playu, instalirati posebnu pristupnu točku, raščlaniti API i registrirati testne račune. Problem je u tome što ljudi često misle da je sve što je zaštićeno autorizacijom imuno na napade uskraćivanjem usluge. Navodno je autorizacija najbolja CAPTCHA, ali nije. Lako je napraviti 10-20 probnih računa, ali njihovim stvaranjem dobivamo pristup složenoj i neskrivenoj funkcionalnosti.
Naravno, gledamo povijest, robots.txt i WebArchive, ViewDNS, i tražimo stare verzije resursa. Ponekad se dogodi da su programeri izbacili, recimo, mail2.yandex.net, ali stara verzija, mail.yandex.net, ostaje. Ovaj mail.yandex.net više nije podržan, nisu mu dodijeljeni razvojni resursi, ali nastavlja trošiti bazu podataka. Sukladno tome, koristeći staru verziju, možete učinkovito koristiti resurse pozadine i sve što stoji iza izgleda. Naravno, to se ne događa uvijek, ali ipak se s tim često susrećemo.
Naravno, analiziramo sve parametre zahtjeva i strukturu kolačića. Možete, recimo, ubaciti neku vrijednost u JSON niz unutar kolačića, stvoriti puno ugniježđenja i učiniti da resurs radi nerazumno dugo.
Traži opterećenje
Prvo što nam padne na pamet prilikom istraživanja nekog mjesta je učitavanje baze podataka, budući da skoro svi imaju pretragu, a kod gotovo svih je, nažalost, slabo zaštićena. Iz nekog razloga programeri ne obraćaju dovoljno pozornosti na pretraživanje. Ali ovdje postoji jedna preporuka - ne biste trebali postavljati zahtjeve iste vrste, jer možete naići na predmemoriranje, kao što je slučaj s HTTP poplavom.
Postavljanje nasumičnih upita bazi podataka također nije uvijek učinkovito. Mnogo je bolje napraviti popis ključnih riječi koje su relevantne za pretraživanje. Ako se vratimo na primjer internetske trgovine: recimo da stranica prodaje automobilske gume i omogućuje vam da postavite radijus guma, vrstu automobila i druge parametre. Sukladno tome, kombinacije relevantnih riječi natjerat će bazu podataka da radi u mnogo složenijim uvjetima.
Osim toga, vrijedi koristiti paginaciju: pretraživanje je mnogo teže vratiti pretposljednju stranicu rezultata pretraživanja nego prvu. Odnosno, uz pomoć paginacije možete malo diverzificirati opterećenje.
Primjer u nastavku prikazuje opterećenje pretraživanja. Vidljivo je da je od prve sekunde testa pri brzini od deset zahtjeva u sekundi stranica pala i nije odgovarala.
Ako nema pretrage?
Ako nema pretraživanja, to ne znači da stranica ne sadrži druga ranjiva polja za unos. Ovo polje može biti autorizacija. U današnje vrijeme programeri vole stvarati složene hashove kako bi zaštitili bazu podataka za prijavu od napada duginom tablicom. To je dobro, ali takvi hashovi troše puno CPU resursa. Veliki protok lažnih autorizacija dovodi do kvara procesora, a kao rezultat, stranica prestaje raditi.
Prisutnost na web mjestu svih vrsta obrazaca za komentare i povratne informacije razlog je da tamo pošaljete vrlo velike tekstove ili jednostavno stvorite veliku poplavu. Ponekad web-mjesta prihvaćaju priložene datoteke, uključujući gzip format. U ovom slučaju uzimamo datoteku od 1 TB, komprimiramo je na nekoliko bajtova ili kilobajta pomoću gzipa i šaljemo je na stranicu. Zatim se otkopča i dobije se vrlo zanimljiv efekt.
API odmora
Želio bih obratiti malo pozornosti na takve popularne usluge kao što je Rest API. Osiguravanje Rest API-ja puno je teže od obične web stranice. Čak ni trivijalne metode zaštite od brutalne upotrebe lozinke i drugih nelegitimnih aktivnosti ne rade za Rest API.
Rest API vrlo je lako razbiti jer izravno pristupa bazi podataka. Istodobno, neuspjeh takve usluge povlači prilično ozbiljne posljedice za poslovanje. Činjenica je da se Rest API obično koristi ne samo za glavnu web stranicu, već i za mobilnu aplikaciju i neke interne poslovne resurse. A ako sve to padne, onda je učinak mnogo jači nego u slučaju jednostavnog kvara web stranice.
Učitavanje velikog sadržaja
Ako nam se ponudi da testiramo neku običnu jednostraničnu aplikaciju, odredišnu stranicu ili web stranicu s posjetnicama koja nema složenu funkcionalnost, tražimo težak sadržaj. Na primjer, velike slike koje poslužitelj šalje, binarne datoteke, pdf dokumentacija - sve to pokušavamo preuzeti. Takvi testovi dobro opterećuju datotečni sustav i začepljuju kanale, te su stoga učinkoviti. To jest, čak i ako ne isključite poslužitelj, preuzimajući veliku datoteku malim brzinama, jednostavno ćete začepiti kanal ciljnog poslužitelja i tada će doći do uskraćivanja usluge.
Primjer takvog testa pokazuje da je pri brzini od 30 RPS stranica prestala odgovarati ili proizvela 500. grešku poslužitelja.
Ne zaboravite na postavljanje poslužitelja. Često se može dogoditi da je osoba kupila virtualni stroj, tamo instalirala Apache, sve konfigurirala po defaultu, instalirala PHP aplikaciju i ispod možete vidjeti rezultat.
Ovdje je opterećenje otišlo u korijen i iznosilo je samo 10 RPS. Čekali smo 5 minuta i server se srušio. Istina je da nije do kraja poznato zašto je pao, ali postoji pretpostavka da je jednostavno imao previše pamćenja pa se prestao javljati.
Na temelju valova
U posljednjih godinu-dvije valovi napadi postali su prilično popularni. To je zbog činjenice da mnoge organizacije kupuju određene dijelove hardvera za DDoS zaštitu, koji zahtijevaju određeno vrijeme za prikupljanje statistike za početak filtriranja napada. Odnosno, ne filtriraju napad u prvih 30-40 sekundi, jer akumuliraju podatke i uče. U skladu s tim, u ovih 30-40 sekundi možete pokrenuti toliko na web mjestu da će resurs ležati dugo dok se svi zahtjevi ne očiste.
U slučaju donjeg napada bio je interval od 10 minuta, nakon čega je stigao novi, modificirani dio napada.
Odnosno, obrana je naučila, krenula s filtriranjem, ali je stigla nova, potpuno drugačija porcija napada i obrana je ponovno počela učiti. Zapravo, filtriranje prestaje raditi, zaštita postaje neučinkovita, a stranica je nedostupna.
Wave napade karakteriziraju vrlo visoke vrijednosti na vrhuncu, može doseći sto tisuća ili milijun zahtjeva u sekundi, u slučaju L7. Ako govorimo o L3&4, onda može biti stotine gigabita prometa, odnosno, prema tome, stotine mpps, ako računate u paketima.
Problem kod takvih napada je sinkronizacija. Napadi dolaze iz botneta i zahtijevaju visok stupanj sinkronizacije kako bi se stvorio vrlo veliki jednokratni skok. A ova koordinacija ne uspijeva uvijek: ponekad je rezultat neka vrsta paraboličnog vrha, koji izgleda prilično jadno.
Ne samo HTTP
Osim HTTP-a na L7, volimo iskorištavati i druge protokole. U pravilu, obična web stranica, posebno običan hosting, ima protokole za poštu i MySQL koji strše. Protokoli pošte podložni su manjem opterećenju od baza podataka, ali se također mogu učitati prilično učinkovito i završiti s preopterećenim CPU-om na poslužitelju.
Bili smo prilično uspješni koristeći 2016 SSH ranjivost. Sada je ova ranjivost popravljena za gotovo sve, ali to ne znači da se opterećenje ne može poslati na SSH. Limenka. Jednostavno postoji ogromna količina autorizacija, SSH pojede skoro cijeli CPU na serveru, a onda se web stranica uruši od jednog ili dva zahtjeva u sekundi. Sukladno tome, ova jedan ili dva zahtjeva temeljena na zapisima ne mogu se razlikovati od legitimnog učitavanja.
Mnoge veze koje otvaramo na poslužiteljima također ostaju relevantne. Ranije je Apache bio kriv za ovo, sada je nginx zapravo kriv jer je često konfiguriran prema zadanim postavkama. Broj veza koje nginx može držati otvorenima je ograničen, pa mi otvorimo ovaj broj veza, nginx više ne prihvaća novu vezu, i kao rezultat stranica ne radi.
Naš testni klaster ima dovoljno procesora za napad na SSL rukovanje. U principu, kao što praksa pokazuje, botnetovi ponekad vole to učiniti. S jedne strane, jasno je da ne možete bez SSL-a, jer Google rezultati, rangiranje, sigurnost. S druge strane, SSL nažalost ima problem s procesorom.
L3&4
Kada govorimo o napadu na razini L3&4, obično govorimo o napadu na razini veze. Takvo opterećenje se gotovo uvijek razlikuje od legitimnog, osim ako se ne radi o SYN-flood napadu. Problem sa SYN-flood napadima za sigurnosne alate je njihova velika količina. Maksimalna vrijednost L3&4 bila je 1,5-2 Tbit/s. Ovakav promet vrlo je teško obraditi čak i velikim tvrtkama, uključujući Oracle i Google.
SYN i SYN-ACK su paketi koji se koriste prilikom uspostavljanja veze. Stoga je SYN-flood teško razlikovati od legitimnog učitavanja: nije jasno radi li se o SYN-u koji je došao uspostaviti vezu ili je to dio poplave.
UDP-poplava
Tipično, napadači nemaju mogućnosti koje mi imamo, pa se pojačanje može koristiti za organiziranje napada. Odnosno, napadač skenira internet i pronalazi ili ranjive ili neispravno konfigurirane poslužitelje koji, primjerice, kao odgovor na jedan SYN paket odgovaraju s tri SYN-ACK-a. Laženjem izvorne adrese od adrese ciljanog poslužitelja moguće je jednim paketom povećati snagu za recimo tri puta i preusmjeriti promet na žrtvu.
Problem s pojačanjima je taj što ih je teško otkriti. Nedavni primjeri uključuju senzacionalni slučaj ranjivog memcached-a. Plus, sada postoji puno IoT uređaja, IP kamera, koje su također uglavnom standardno konfigurirane, a standardno su krivo konfigurirane, zbog čega napadači najčešće vrše napade preko takvih uređaja.
Teška SYN-poplava
SYN-flood je vjerojatno najzanimljivija vrsta napada sa stajališta programera. Problem je u tome što administratori sustava često koriste IP blokiranje za zaštitu. Štoviše, blokiranje IP-a ne utječe samo na administratore sustava koji djeluju pomoću skripti, već, nažalost, i na neke sigurnosne sustave koji se kupuju za puno novca.
Ova metoda može se pretvoriti u katastrofu, jer ako napadači zamijene IP adrese, tvrtka će blokirati vlastitu podmrežu. Kada vatrozid blokira vlastiti klaster, izlaz neće uspjeti vanjske interakcije i resurs neće uspjeti.
Štoviše, nije teško blokirati vlastitu mrežu. Ako ured klijenta ima Wi-Fi mrežu ili ako se performanse resursa mjere pomoću različitih sustava za nadzor, tada uzimamo IP adresu ovog sustava za nadzor ili Wi-Fi ureda klijenta i koristimo je kao izvor. Na kraju se čini da je resurs dostupan, ali ciljne IP adrese su blokirane. Tako Wi-Fi mreža HighLoad konferencije na kojoj se predstavlja novi proizvod tvrtke može biti blokirana, a to za sobom povlači određene poslovne i ekonomske troškove.
Tijekom testiranja ne možemo koristiti pojačanje kroz memcached s bilo kojim vanjskim resursima, jer postoje sporazumi o slanju prometa samo na dopuštene IP adrese. Sukladno tome koristimo pojačanje putem SYN i SYN-ACK, kada sustav na slanje jednog SYN-a odgovara s dva ili tri SYN-ACK-a, a na izlazu se napad umnožava dva ili tri puta.
Alat
Jedan od glavnih alata koje koristimo za radno opterećenje L7 je Yandex-tank. Konkretno, fantom se koristi kao pištolj, plus postoji nekoliko skripti za generiranje patrona i za analizu rezultata.
Tcpdump se koristi za analizu mrežnog prometa, a Nmap za analizu poslužitelja. Za stvaranje opterećenja na razini L3&4 koristi se OpenSSL i malo naše vlastite magije s DPDK bibliotekom. DPDK je Intelova biblioteka koja vam omogućuje rad s mrežnim sučeljem zaobilazeći Linux stog, čime se povećava učinkovitost. Naravno, koristimo DPDK ne samo na razini L3&4, već i na razini L7, jer nam omogućuje stvaranje vrlo visokog protoka opterećenja, unutar raspona od nekoliko milijuna zahtjeva u sekundi s jednog stroja.
Također koristimo određene generatore prometa i posebne alate koje pišemo za specifične testove. Ako se prisjetimo ranjivosti pod SSH, tada se gornji skup ne može iskoristiti. Ako napadamo protokol pošte, uzimamo pomoćne programe za poštu ili jednostavno pišemo skripte na njima.
Zaključci
Kao zaključak želio bih reći:
- Osim klasičnog testiranja opterećenja, potrebno je provesti testiranje naprezanja. Imamo pravi primjer gdje je partnerov podizvođač izvršio samo ispitivanje opterećenja. Pokazalo se da resurs može izdržati normalno opterećenje. Ali tada se pojavilo nenormalno opterećenje, posjetitelji stranice počeli su koristiti resurs malo drugačije, a kao rezultat toga podizvođač je ležao. Stoga vrijedi potražiti ranjivosti čak i ako ste već zaštićeni od DDoS napada.
- Potrebno je izolirati neke dijelove sustava od drugih. Ako imate pretragu, morate je premjestiti na zasebne strojeve, odnosno ne čak ni na Docker. Jer ako pretraga ili autorizacija ne uspije, barem će nešto nastaviti raditi. U slučaju internetske trgovine, korisnici će nastaviti pronalaziti proizvode u katalogu, ići iz agregatora, kupovati ako su već autorizirani ili se autorizirati putem OAuth2.
- Nemojte zanemariti sve vrste usluga u oblaku.
- Koristite CDN ne samo za optimizaciju kašnjenja mreže, već i kao sredstvo zaštite od napada na iscrpljenost kanala i jednostavno preplavljivanje u statički promet.
- Potrebno je koristiti specijalizirane službe zaštite. Ne možete se zaštititi od L3&4 napada na razini kanala, jer najvjerojatnije jednostavno nemate dovoljan kanal. Također je malo vjerojatno da ćete se oduprijeti L7 napadima, jer oni mogu biti vrlo veliki. Osim toga, potraga za malim napadima još uvijek je prerogativ posebnih usluga, posebnih algoritama.
- Redovito ažurirajte. Ovo se ne odnosi samo na kernel, već i na SSH daemon, pogotovo ako ih imate otvorene prema van. U principu, sve treba ažurirati, jer je malo vjerojatno da ćete moći sami pratiti određene ranjivosti.
Izvor: www.habr.com