Variti razvija zaštitu od botova i DDoS napada, a također provodi stres i testiranje opterećenja. Na HighLoad++ 2018 konferenciji razgovarali smo o tome kako osigurati resurse od raznih vrsta napada. Ukratko: izolujte dijelove sistema, koristite usluge u oblaku i CDN-ove i redovno ažurirajte. Ali i dalje nećete moći da se nosite sa zaštitom bez specijalizovanih kompanija :)
Prije čitanja teksta, možete pročitati kratke sažetke .
A ako ne volite da čitate ili samo želite da pogledate video, snimak naše reportaže je ispod ispod spojlera.
Video snimak izvještaja
Mnoge kompanije već znaju kako da rade testiranje opterećenja, ali ne rade sve stresno testiranje. Neki od naših kupaca smatraju da je njihov sajt neranjiv jer imaju sistem visokog opterećenja i dobro štiti od napada. Pokazujemo da to nije sasvim tačno.
Naravno, prije izvođenja testova, od kupca dobijemo dozvolu, potpisanu i pečatom, i uz našu pomoć ne može se izvršiti DDoS napad ni na koga. Testiranje se vrši u vrijeme koje odabere korisnik, kada je promet na njegovom resursu minimalan, a problemi s pristupom neće utjecati na klijente. Osim toga, s obzirom da uvijek nešto može poći po zlu tokom procesa testiranja, imamo stalan kontakt sa kupcem. Ovo vam omogućava ne samo da prijavite postignute rezultate, već i da nešto promijenite tokom testiranja. Po završetku testiranja uvijek sastavljamo izvještaj u kojem ukazujemo na uočene nedostatke i dajemo preporuke za otklanjanje slabosti stranice.
Kako radimo
Prilikom testiranja emuliramo botnet. Budući da radimo sa klijentima koji se ne nalaze na našim mrežama, kako bismo osigurali da se test ne završi u prvoj minuti zbog ograničenja ili aktiviranja zaštite, opskrbljujemo opterećenje ne s jedne IP adrese, već iz vlastite podmreže. Osim toga, da bismo stvorili značajno opterećenje, imamo vlastiti prilično moćan test server.
Postulate
Previše ne znači dobro
Što manje opterećenje možemo dovesti do kvara resursa, 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 ranjivost.
Djelomični neuspjeh je bolji od potpunog neuspjeha
Uvijek savjetujemo da sisteme napravite heterogenim. Štaviše, vrijedi ih razdvojiti na fizičkom nivou, a ne samo kontejnerizacijom. U slučaju fizičkog odvajanja, čak i ako nešto pokvari na stranici, postoji velika vjerovatnoća da neće potpuno prestati s radom, a korisnici će i dalje imati pristup barem dijelu funkcionalnosti.
Dobra arhitektura je osnova za održivost
Toleranciju grešaka resursa i njegovu sposobnost da izdrži napade i opterećenja trebalo bi postaviti u fazi projektovanja, zapravo, u fazi crtanja prvih dijagrama toka u notesu. Jer ako se uvuku fatalne greške, moguće ih je ispraviti u budućnosti, ali je to vrlo teško.
Ne samo da bi kod trebao biti dobar, već i konfiguracija
Mnogi ljudi misle da je dobar razvojni tim garancija usluge otporne na greške. Dobar razvojni tim je zaista neophodan, ali mora postojati i dobro poslovanje, dobar DevOps. Odnosno, potrebni su nam stručnjaci koji će ispravno konfigurirati Linux i mrežu, ispravno napisati konfiguracije u nginxu, postaviti ograničenja itd. U suprotnom, resurs će dobro funkcionirati samo u testiranju, a u nekom trenutku će se sve pokvariti u proizvodnji.
Razlike između testiranja opterećenja i stresnog testiranja
Testiranje opterećenja vam omogućava da identifikujete granice funkcionisanja sistema. Stres testiranje je usmjereno na pronalaženje slabosti u sistemu i koristi se da se ovaj sistem razbije i vidi kako će se ponašati u procesu kvara pojedinih dijelova. U ovom slučaju, priroda opterećenja obično ostaje nepoznata kupcu prije početka testiranja na stres.
Posebne karakteristike L7 napada
Tipove opterećenja obično dijelimo na opterećenja na nivoima L7 i L3&4. L7 je opterećenje na nivou aplikacije, najčešće samo HTTP, ali mislimo na svako opterećenje na nivou TCP protokola.
L7 napadi imaju određene karakteristične karakteristike. Prvo, oni dolaze direktno u aplikaciju, odnosno malo je vjerovatno da će se odraziti putem mrežnih sredstava. Takvi napadi koriste logiku i zbog toga troše CPU, memoriju, disk, bazu podataka i druge resurse vrlo efikasno i uz malo prometa.
HTTP Flood
U slučaju bilo kakvog napada, opterećenje je lakše stvoriti nego nositi, a u slučaju L7 to je također istina. Nije uvijek lako razlikovati promet napada od legitimnog, a najčešće se to može učiniti po učestalosti, ali ako je sve ispravno isplanirano, onda je iz logova nemoguće shvatiti gdje je napad, a gdje legitimni zahtjevi.
Kao prvi primjer, razmotrite HTTP Flood napad. Grafikon pokazuje da su takvi napadi obično vrlo moćni; u primjeru ispod, vršni broj zahtjeva premašio je 600 hiljada u minuti.
HTTP Flood je najlakši način za kreiranje opterećenja. Obično je potrebna neka vrsta alata za testiranje opterećenja, kao što je ApacheBench, i postavlja zahtjev i cilj. Sa tako jednostavnim pristupom, postoji velika vjerovatnoća da naletite na keširanje servera, ali ga je lako zaobići. Na primjer, dodavanje nasumičnih stringova zahtjevu, što će prisiliti server da konstantno služi novu stranicu.
Također, ne zaboravite na korisničkog agenta u procesu kreiranja opterećenja. Mnogi korisnički agenti popularnih alata za testiranje filtriraju se od strane administratora sistema, i u ovom slučaju opterećenje možda jednostavno neće doći do backenda. Možete značajno poboljšati rezultat umetanjem manje ili više važećeg zaglavlja iz pretraživača u zahtjev.
Koliko god da su HTTP Flood napadi jednostavni, oni imaju i svoje nedostatke. Prvo, potrebne su velike količine energije za stvaranje opterećenja. Drugo, takve napade je vrlo lako otkriti, posebno ako dolaze s jedne adrese. Kao rezultat, zahtjevi odmah počinju da se filtriraju od strane administratora sistema ili čak na nivou provajdera.
Šta pretraživati
Da biste smanjili broj zahtjeva u sekundi bez gubitka efikasnosti, morate pokazati malo mašte i istražiti stranicu. Tako možete učitati ne samo kanal ili server, već i pojedinačne dijelove aplikacije, na primjer, baze podataka ili sisteme datoteka. Također možete potražiti mjesta na web stranici koja vrše velike proračune: kalkulatore, stranice za odabir proizvoda itd. Konačno, često se dešava da sajt ima neku vrstu PHP skripte koja generiše stranicu od nekoliko stotina hiljada redova. Takav skript također značajno opterećuje server i može postati meta napada.
Gde 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 za resurs i usporiti njegov rad. Tu pomažu banalni razvojni alati u Google Chrome-u i Firefox-u, koji prikazuju vrijeme odgovora stranice.
Skeniramo i poddomene. Na primjer, postoji određena internet prodavnica, abc.com, i ona ima poddomenu admin.abc.com. Najvjerovatnije je ovo admin panel s autorizacijom, ali ako ga opteretite, to može stvoriti probleme za glavni resurs.
Stranica može imati poddomenu api.abc.com. Najvjerovatnije je ovo resurs za mobilne aplikacije. Aplikaciju možete pronaći u App Store-u ili Google Play-u, instalirati posebnu pristupnu tačku, secirati API i registrirati test naloge. Problem je u tome što ljudi često misle da je sve što je zaštićeno autorizacijom imuno na napade uskraćivanja usluge. Navodno je autorizacija najbolja CAPTCHA, ali nije. Lako je napraviti 10-20 probnih naloga, ali njihovim kreiranjem dobijamo pristup složenoj i neskrivenoj funkcionalnosti.
Naravno, gledamo istoriju, robots.txt i WebArchive, ViewDNS, i tražimo stare verzije resursa. Ponekad se dešava da su programeri izbacili, recimo, mail2.yandex.net, ali stara verzija, mail.yandex.net, ostaje. Ovaj mail.yandex.net više nije podržan, razvojni resursi mu nisu dodijeljeni, ali nastavlja da koristi bazu podataka. Shodno tome, koristeći staru verziju, možete efikasno koristiti resurse pozadine i sve ono što stoji iza izgleda. Naravno, to se ne dešava uvek, ali se i dalje često susrećemo sa ovim.
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.
Search load
Prvo što vam padne na pamet kada istražujete neki sajt je učitavanje baze podataka, pošto skoro svi imaju pretragu, a za skoro svakoga je, nažalost, slabo zaštićena. Iz nekog razloga, programeri ne obraćaju dovoljno pažnje na pretragu. Ali ovdje postoji jedna preporuka - ne bi trebali postavljati zahtjeve istog tipa, jer možete naići na keširanje, kao što je slučaj sa HTTP flood-om.
Pravljenje nasumičnih upita bazi podataka takođe nije uvek efikasno. Mnogo je bolje napraviti listu ključnih riječi koje su relevantne za pretragu. Ako se vratimo na primjer online trgovine: recimo da stranica prodaje automobilske gume i omogućava vam da postavite radijus guma, vrstu automobila i druge parametre. U skladu s tim, kombinacije relevantnih riječi će primorati bazu podataka da radi u mnogo složenijim uvjetima.
Osim toga, vrijedi koristiti paginaciju: mnogo je teže pretraživanju vratiti pretposljednju stranicu rezultata pretraživanja nego prvu. Odnosno, uz pomoć paginacije možete malo diverzificirati opterećenje.
Primjer ispod prikazuje opterećenje pretraživanja. Vidi se da je od prve sekunde testa pri brzini od deset zahtjeva u sekundi sajt pao i nije odgovarao.
Ako nema pretrage?
Ako nema pretrage, to ne znači da stranica ne sadrži druga ranjiva polja za unos. Ovo polje može biti autorizacija. Danas programeri vole da prave složene hešove kako bi zaštitili bazu podataka za prijavu od napada duginih tabela. Ovo je dobro, ali takvi hashovi troše mnogo CPU resursa. Veliki protok lažnih autorizacija dovodi do kvara procesora, a kao rezultat, stranica prestaje raditi.
Prisustvo na sajtu svih vrsta obrazaca za komentare i povratne informacije razlog je da se tamo šalju veoma veliki tekstovi ili jednostavno napravi ogromna poplava. Ponekad web lokacije prihvataju priložene datoteke, uključujući i u gzip formatu. U ovom slučaju, uzimamo datoteku od 1TB, kompresujemo je na nekoliko bajtova ili kilobajta koristeći gzip i šaljemo je na stranicu. Zatim se otkopčava i dobija se veoma zanimljiv efekat.
API za odmor
Želio bih da obratim malo pažnje na popularne servise kao što je Rest API. Osiguravanje Rest API-ja je mnogo teže od obične web stranice. Čak i trivijalne metode zaštite od grube sile lozinke i drugih nezakonitih aktivnosti ne rade za Rest API.
Rest API je vrlo lako razbiti jer direktno pristupa bazi podataka. Istovremeno, 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 ovo padne, onda je učinak mnogo jači nego u slučaju jednostavnog kvara web stranice.
Učitavanje teškog sadržaja
Ako nam se ponudi da testiramo neku običnu jednostraničnu aplikaciju, odredišnu stranicu ili web stranicu za posjetnicu koja nema složenu funkcionalnost, tražimo težak sadržaj. Na primjer, velike slike koje server šalje, binarne datoteke, pdf dokumentacija - sve to pokušavamo preuzeti. Takvi testovi dobro učitavaju sistem datoteka i začepljuju kanale, pa su stoga efikasni. To jest, čak i ako ne ugasite server, preuzimajući veliku datoteku malim brzinama, jednostavno ćete začepiti kanal ciljnog servera i tada će doći do uskraćivanja usluge.
Primjer takvog testa pokazuje da je pri brzini od 30 RPS-a stranica prestala da reaguje ili je proizvela 500. grešku servera.
Ne zaboravite na postavljanje servera. Često možete pronaći da je neko kupio virtuelnu mašinu, instalirao Apache tamo, konfigurisao sve podrazumevano, instalirao PHP aplikaciju, a ispod možete videti rezultat.
Ovdje je opterećenje otišlo do korijena i iznosilo je samo 10 RPS. Čekali smo 5 minuta i server se srušio. Istina je da nije potpuno poznato zašto je pao, ali postoji pretpostavka da je jednostavno imao previše pamćenja i zbog toga je prestao da reaguje.
Wave based
U posljednjih godinu-dvije, talasni napadi su postali prilično popularni. To je zbog činjenice da mnoge organizacije kupuju određene dijelove hardvera za DDoS zaštitu, za koje je potrebno određeno vrijeme da se akumuliraju statistički podaci kako bi počeli filtrirati napad. Odnosno, ne filtriraju napad u prvih 30-40 sekundi, jer gomilaju podatke i uče. U skladu s tim, u ovih 30-40 sekundi možete pokrenuti toliko toga na web-lokaciji da će resurs dugo ležati dok se svi zahtjevi ne razjasne.
U slučaju napada ispod, postojao je interval od 10 minuta, nakon čega je stigao novi, izmijenjeni dio napada.
Odnosno, odbrana je naučila, počela da filtrira, ali je stigao novi, potpuno drugačiji deo napada i odbrana je ponovo počela da uči. Zapravo, filtriranje prestaje raditi, zaštita postaje neefikasna, a stranica je nedostupna.
Napade talasa karakterišu veoma visoke vrednosti na vrhuncu, može dostići sto hiljada ili milion zahteva u sekundi, u slučaju L7. Ako govorimo o L3&4, onda može postojati stotine gigabita prometa, ili, shodno tome, stotine mpps, ako se računa u paketima.
Problem kod ovakvih napada je sinhronizacija. Napadi dolaze iz botneta i zahtijevaju visok stepen sinhronizacije da bi se stvorio veoma veliki jednokratni skok. I ova koordinacija ne funkcionira uvijek: ponekad je izlaz neka vrsta paraboličnog vrha, što izgleda prilično patetično.
Ne samo HTTP
Pored HTTP-a na L7, volimo da koristimo i druge protokole. U pravilu, obična web stranica, posebno običan hosting, ima protokole za poštu i MySQL. Protokoli za poštu su podložni manjem opterećenju nego baze podataka, ali se takođe mogu učitati prilično efikasno i završiti sa preopterećenim CPU-om na serveru.
Bili smo prilično uspješni u korištenju 2016 SSH ranjivosti. Sada je ova ranjivost ispravljena za skoro sve, ali to ne znači da se opterećenje ne može predati na SSH. Može. Jednostavno postoji ogromno opterećenje autorizacijama, SSH pojede gotovo cijeli CPU na serveru, a onda web stranica propada od jednog ili dva zahtjeva u sekundi. Shodno tome, ovaj jedan ili dva zahtjeva zasnovana na evidenciji ne mogu se razlikovati od legitimnog opterećenja.
Mnoge veze koje otvaramo na serverima također ostaju relevantne. Ranije je Apache bio kriv za ovo, sada je nginx zapravo kriv za ovo, pošto je često konfigurisan po defaultu. Broj konekcija koje nginx može držati otvorenima je ograničen, tako da otvaramo ovaj broj veza, nginx više ne prihvata novu vezu i kao rezultat toga stranica ne radi.
Naš testni klaster ima dovoljno CPU-a da napadne SSL rukovanje. U principu, kao što praksa pokazuje, i botnetovi to ponekad vole da rade. S jedne strane, jasno je da se bez SSL-a ne može, jer Google rezultati, rangiranje, sigurnost. S druge strane, SSL nažalost ima problem sa procesorom.
L3&4
Kada govorimo o napadu na nivou L3 i 4, obično govorimo o napadu na nivou 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 njihov veliki obim. Maksimalna L3&4 vrijednost je bila 1,5-2 Tbit/s. Ovakav promet je veoma teško obraditi čak i za velike kompanije, 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 opterećenja: nije jasno da li je ovo SYN koji je došao da uspostavi vezu ili je dio poplave.
UDP-poplava
Obično napadači nemaju mogućnosti koje imamo, pa se pojačanje može koristiti za organiziranje napada. Odnosno, napadač skenira Internet i pronalazi ili ranjive ili pogrešno konfigurisane servere koji, na primjer, kao odgovor na jedan SYN paket, odgovaraju sa tri SYN-ACK-a. Pretvaranjem izvorne adrese sa adrese ciljnog servera moguće je povećati snagu za, recimo, tri puta sa jednim paketom i preusmeriti saobraćaj na žrtvu.
Problem sa pojačanjima je što ih je teško otkriti. Nedavni primjeri uključuju senzacionalan slučaj ranjivog memcached-a. Plus, sada postoji puno IoT uređaja, IP kamera, koje su također uglavnom standardno konfigurirane, a po defaultu su pogrešno konfigurirane, zbog čega napadači najčešće vrše napade preko takvih uređaja.
Teška SYN-poplava
SYN-flood je vjerovatno najzanimljiviji tip napada sa stanovišta programera. Problem je što sistemski administratori često koriste IP blokiranje za zaštitu. Štoviše, IP blokiranje ne pogađa samo administratore sistema koji djeluju pomoću skripti, već i, nažalost, neke sigurnosne sisteme koji se kupuju za mnogo novca.
Ova metoda se može pretvoriti u katastrofu, jer ako napadači zamjene IP adrese, kompanija će blokirati vlastitu podmrežu. Kada zaštitni zid blokira svoj vlastiti klaster, izlaz neće uspjeti u vanjskim interakcijama i resurs neće uspjeti.
Štoviše, nije teško blokirati vlastitu mrežu. Ako kancelarija klijenta ima Wi-Fi mrežu, ili ako se performanse resursa mere pomoću različitih sistema za praćenje, onda uzimamo IP adresu ovog sistema za praćenje ili Wi-Fi kancelarije klijenta i koristimo je kao izvor. Na kraju se čini da je resurs dostupan, ali su ciljne IP adrese blokirane. Dakle, Wi-Fi mreža HighLoad konferencije, na kojoj se predstavlja novi proizvod kompanije, može biti blokirana, a to povlači određene poslovne i ekonomske troškove.
Tokom testiranja, ne možemo koristiti pojačanje kroz memcached sa bilo kojim eksternim resursima, jer postoje dogovori da se promet šalje samo na dozvoljene IP adrese. Shodno tome, koristimo pojačanje preko SYN i SYN-ACK, kada sistem na slanje jednog SYN-a odgovori sa dva ili tri SYN-ACK-a, a na izlazu se napad množi dva ili tri puta.
Alati
Jedan od glavnih alata koje koristimo za L7 radno opterećenje 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 saobraćaja, a Nmap se koristi za analizu servera. Za kreiranje opterećenja na nivou L3&4 koristi se OpenSSL i malo naše vlastite magije sa DPDK bibliotekom. DPDK je Intelova biblioteka koja vam omogućava da radite sa mrežnim interfejsom zaobilazeći Linux stek, čime se povećava efikasnost. Naravno, koristimo DPDK ne samo na nivou L3&4, već i na nivou L7, jer nam omogućava da kreiramo veoma visok protok opterećenja, u rasponu od nekoliko miliona zahteva u sekundi sa jedne mašine.
Također koristimo određene generatore prometa i posebne alate koje pišemo za specifične testove. Ako se prisjetimo ranjivosti pod SSH, onda se gornji skup ne može iskoristiti. Ako napadnemo mail protokol, uzimamo uslužne programe za poštu ili jednostavno pišemo skripte na njima.
nalazi
Kao zaključak želio bih reći:
- Osim klasičnog testiranja opterećenja, potrebno je provesti i stres testiranje. Imamo pravi primjer gdje je partnerov podizvođač vršio samo testiranje opterećenja. Pokazalo se da resurs može izdržati normalno opterećenje. Ali tada se pojavilo nenormalno opterećenje, posjetitelji stranice su počeli koristiti resurse malo drugačije, a kao rezultat toga je podizvođač legao. Stoga je vrijedno tražiti ranjivosti čak i ako ste već zaštićeni od DDoS napada.
- Neophodno je izolovati neke delove sistema od drugih. Ako imate pretragu, morate je premjestiti na odvojene mašine, odnosno čak ni na Docker. Jer ako pretraga ili autorizacija ne uspije, barem će nešto nastaviti raditi. U slučaju online trgovine, korisnici će i dalje pronaći proizvode u katalogu, ići iz agregatora, kupovati ako su već ovlašteni ili 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 iscrpljivanje kanala i jednostavno preplavljivanje statičnog saobraćaja.
- Neophodno je koristiti specijalizovane usluge zaštite. Ne možete se zaštititi od L3&4 napada na nivou kanala, jer najvjerovatnije jednostavno nemate dovoljan kanal. Takođe je malo verovatno da ćete se boriti protiv L7 napada, jer oni mogu biti veoma veliki. Osim toga, potraga za malim napadima i dalje je prerogativ specijalnih službi, posebnih algoritama.
- Ažurirajte redovno. Ovo se ne odnosi samo na kernel, već i na SSH daemon, posebno ako ih imate otvorene prema van. U principu, sve treba ažurirati, jer je malo vjerovatno da ćete sami moći pratiti određene ranjivosti.
izvor: www.habr.com