Variti razvija zaščito pred roboti in napadi DDoS, izvaja pa tudi stresno testiranje in testiranje obremenitve. Na konferenci HighLoad++ 2018 smo govorili o tem, kako zavarovati vire pred različnimi vrstami napadov. Na kratko: izolirajte dele sistema, uporabljajte storitve v oblaku in CDN-je ter redno posodabljajte. Ampak brez specializiranih podjetij še vedno ne boste mogli rešiti zaščite :)
Pred branjem besedila lahko preberete kratke povzetke .
Če pa se vam ne ljubi brati ali pa bi radi samo gledali video, je posnetek naše reportaže spodaj pod spojlerjem.
Video posnetek poročila
Mnoga podjetja že vedo, kako izvajati obremenitveno testiranje, vendar ne izvajajo vsa stresnega testiranja. Nekatere naše stranke menijo, da je njihova stran neranljiva, ker imajo visoko obremenjen sistem, ki dobro ščiti pred napadi. Pokažemo, da to ni povsem res.
Seveda pred izvedbo testov pridobimo dovoljenje stranke, podpisano in žigosano, in z našo pomočjo DDoS napada ni mogoče izvesti na nikogar. Testiranje se izvaja v času, ki ga izbere stranka, ko je promet na njegovem viru minimalen in težave z dostopom ne bodo vplivale na stranke. Poleg tega, ker gre lahko med testiranjem vedno kaj narobe, imamo stalni stik s stranko. To vam omogoča, da ne samo poročate o doseženih rezultatih, ampak tudi spremenite nekaj med testiranjem. Po opravljenem testiranju vedno sestavimo zapisnik, v katerem izpostavimo ugotovljene pomanjkljivosti in podamo priporočila za odpravo slabosti strani.
Kako delamo
Pri testiranju emuliramo botnet. Ker delamo z odjemalci, ki se ne nahajajo v naših omrežjih, da zagotovimo, da se test ne konča v prvi minuti zaradi omejitev ali sprožene zaščite, obremenitev ne dovajamo iz enega IP-ja, temveč iz lastnega podomrežja. Poleg tega imamo za ustvarjanje znatne obremenitve lasten precej zmogljiv testni strežnik.
Postulati
Preveč ne pomeni dobro
Manj kot lahko obremenimo vir do okvare, tem bolje. Če lahko naredite, da spletno mesto preneha delovati na eno zahtevo na sekundo ali celo eno zahtevo na minuto, je to super. Ker bodo po zakonu zlobnosti uporabniki ali napadalci slučajno padli v to posebno ranljivost.
Delna odpoved je boljša od popolne
Vedno svetujemo, da so sistemi heterogeni. Še več, vredno jih je ločiti na fizični ravni in ne samo s kontejnerizacijo. V primeru fizične ločitve, tudi če na strani kaj odpove, obstaja velika verjetnost, da le-ta ne bo povsem prenehala delovati, uporabniki pa bodo še naprej imeli dostop do vsaj dela funkcionalnosti.
Dobra arhitektura je osnova za trajnost
Odpornost na napake vira in njegovo sposobnost, da prenese napade in obremenitve, je treba določiti v fazi načrtovanja, pravzaprav v fazi risanja prvih diagramov poteka v zvezku. Kajti če se prikradejo usodne napake, jih je mogoče v prihodnosti popraviti, a zelo težko.
Dobra mora biti ne samo koda, ampak tudi konfiguracija
Mnogi mislijo, da je dobra razvojna ekipa jamstvo za storitev, ki je tolerantna na napake. Dobra razvojna ekipa je res potrebna, vendar mora biti tudi dobro delovanje, dober DevOps. To pomeni, da potrebujemo strokovnjake, ki bodo pravilno konfigurirali Linux in omrežje, pravilno napisali konfiguracije v nginx, postavili omejitve itd. V nasprotnem primeru bo vir dobro deloval le pri testiranju, v proizvodnji pa se bo na neki točki vse pokvarilo.
Razlike med obremenitvenim in stresnim testiranjem
Obremenitveno testiranje vam omogoča, da ugotovite meje delovanja sistema. Stresno testiranje je namenjeno iskanju slabosti v sistemu in se uporablja za zlom tega sistema ter opazovanje, kako se bo obnašal v procesu odpovedi določenih delov. V tem primeru narava obremenitve običajno ostane neznana stranki, preden se začne stresno testiranje.
Posebnosti napadov L7
Vrste obremenitev običajno delimo na obremenitve na ravni L7 in L3&4. L7 je obremenitev na nivoju aplikacije, najpogosteje pomeni samo HTTP, mislimo pa na vsako obremenitev na ravni protokola TCP.
Napadi L7 imajo nekatere posebnosti. Prvič, pridejo neposredno v aplikacijo, kar pomeni, da je malo verjetno, da se bodo odražali prek omrežnih sredstev. Takšni napadi uporabljajo logiko in zaradi tega zelo učinkovito in z malo prometa porabljajo CPU, pomnilnik, disk, bazo podatkov in druge vire.
HTTP poplava
Pri vsakem napadu je obremenitev lažje ustvariti kot obvladati, kar velja tudi za L7. Napadalnega prometa ni vedno lahko ločiti od zakonitega prometa in največkrat je to mogoče narediti po frekvenci, a če je vse pravilno načrtovano, potem iz dnevnikov ni mogoče razbrati, kje je napad in kje so legitimne zahteve.
Kot prvi primer razmislite o napadu HTTP Flood. Iz grafa je razvidno, da so tovrstni napadi običajno zelo močni, v spodnjem primeru je največje število zahtev preseglo 600 tisoč na minuto.
HTTP Flood je najlažji način za ustvarjanje obremenitve. Običajno potrebuje nekakšno orodje za testiranje obremenitve, kot je ApacheBench, ter nastavi zahtevo in cilj. S tako preprostim pristopom obstaja velika verjetnost, da naletite na predpomnjenje strežnika, vendar ga je enostavno zaobiti. Na primer, dodajanje naključnih nizov v zahtevo, kar bo prisililo strežnik, da nenehno streže novo stran.
Prav tako ne pozabite na uporabniškega agenta v procesu ustvarjanja obremenitve. Številne uporabniške agente priljubljenih orodij za testiranje sistemski skrbniki filtrirajo in v tem primeru obremenitev morda preprosto ne doseže zaledja. Rezultat lahko bistveno izboljšate tako, da v zahtevo vstavite bolj ali manj veljavno glavo iz brskalnika.
Čeprav so napadi HTTP Flood preprosti, imajo tudi svoje pomanjkljivosti. Prvič, za ustvarjanje obremenitve so potrebne velike količine moči. Drugič, takšne napade je zelo enostavno odkriti, še posebej, če prihajajo z enega naslova. Posledično se zahteve takoj začnejo filtrirati s strani sistemskih skrbnikov ali celo na ravni ponudnika.
Kaj iskati
Če želite zmanjšati število zahtev na sekundo, ne da bi pri tem izgubili učinkovitost, morate pokazati malo domišljije in raziskati spletno mesto. Tako lahko naložite ne samo kanal ali strežnik, temveč tudi posamezne dele aplikacije, na primer baze podatkov ali datotečne sisteme. Na spletnem mestu lahko poiščete tudi mesta, kjer se izvajajo veliki izračuni: kalkulatorji, strani z izbiro izdelkov itd. Končno se pogosto zgodi, da ima spletno mesto nekakšen PHP skript, ki ustvari stran z več sto tisoč vrsticami. Takšna skripta tudi precej obremenjuje strežnik in lahko postane tarča napada.
Kje iskati
Ko skeniramo vir pred testiranjem, najprej pogledamo seveda samo spletno mesto. Iščemo vse vrste vnosnih polj, težke datoteke - na splošno vse, kar lahko povzroči težave za vir in upočasni njegovo delovanje. Tukaj so v pomoč banalna razvojna orodja v brskalnikih Google Chrome in Firefox, ki prikazujejo odzivne čase strani.
Skeniramo tudi poddomene. Na primer, obstaja določena spletna trgovina abc.com in ima poddomeno admin.abc.com. Najverjetneje je to skrbniška plošča z avtorizacijo, vendar če jo obremenite, lahko povzroči težave za glavni vir.
Spletno mesto ima lahko poddomeno api.abc.com. Najverjetneje je to vir za mobilne aplikacije. Aplikacijo lahko najdete v App Store ali Google Play, namestite posebno dostopno točko, secirate API in registrirate testne račune. Težava je v tem, da ljudje pogosto mislijo, da je vse, kar je zaščiteno z avtorizacijo, imuno na napade z zavrnitvijo storitve. Menda je avtorizacija najboljša CAPTCHA, pa ni. Enostavno je narediti 10-20 testnih računov, vendar z njihovim ustvarjanjem dobimo dostop do kompleksne in neprikrite funkcionalnosti.
Seveda pogledamo zgodovino, robots.txt in WebArchive, ViewDNS ter poiščemo stare različice vira. Včasih se zgodi, da so razvijalci uvedli, recimo, mail2.yandex.net, vendar stara različica, mail.yandex.net, ostane. Ta mail.yandex.net ni več podprt, razvojni viri mu niso dodeljeni, vendar še naprej porablja bazo podatkov. Skladno s tem lahko s staro različico učinkovito uporabite vire ozadja in vse, kar je za postavitvijo. Seveda se to ne zgodi vedno, a se s tem vseeno pogosto srečujemo.
Seveda analiziramo vse parametre zahteve in strukturo piškotkov. Lahko, recimo, odložite nekaj vrednosti v matriko JSON znotraj piškotka, ustvarite veliko gnezdenja in omogočite, da vir deluje nerazumno dolgo.
Obremenitev iskanja
Prva stvar, ki pride na misel pri raziskovanju spletnega mesta, je nalaganje baze podatkov, saj skoraj vsi imajo iskanje in skoraj vsi so na žalost slabo zaščiteni. Iz nekega razloga razvijalci ne posvečajo dovolj pozornosti iskanju. Vendar obstaja eno priporočilo - ne postavljajte zahtev iste vrste, ker lahko naletite na predpomnjenje, kot je to v primeru poplave HTTP.
Izvajanje naključnih poizvedb v zbirki podatkov tudi ni vedno učinkovito. Veliko bolje je ustvariti seznam ključnih besed, ki so pomembne za iskanje. Če se vrnemo k primeru spletne trgovine: recimo, da spletno mesto prodaja avtomobilske pnevmatike in vam omogoča nastavitev polmera pnevmatik, vrste avtomobila in drugih parametrov. Skladno s tem bodo kombinacije ustreznih besed prisilile bazo podatkov, da deluje v veliko bolj zapletenih pogojih.
Poleg tega je vredno uporabiti paginacijo: iskanje je veliko težje vrniti predzadnjo stran rezultatov iskanja kot prvo. To pomeni, da lahko s pomočjo paginacije nekoliko diverzificirate obremenitev.
Spodnji primer prikazuje obremenitev iskanja. Vidimo, da je že od prve sekunde testa pri hitrosti desetih zahtevkov na sekundo stran padla in se ni odzvala.
Če ni iskanja?
Če iskanja ni, to ne pomeni, da spletno mesto ne vsebuje drugih ranljivih vnosnih polj. To polje je lahko avtorizacija. Dandanes razvijalci radi izdelujejo zapletene zgoščene vrednosti, da zaščitijo prijavno bazo podatkov pred napadom mavrične tabele. To je dobro, vendar takšni zgoščevalci porabijo veliko virov procesorja. Velik tok lažnih avtorizacij povzroči okvaro procesorja in posledično spletno mesto preneha delovati.
Prisotnost vseh vrst obrazcev za komentarje in povratne informacije na spletnem mestu je razlog, da tja pošljete zelo velika besedila ali preprosto ustvarite ogromno poplavo. Včasih spletna mesta sprejmejo priložene datoteke, tudi v formatu gzip. V tem primeru vzamemo 1TB veliko datoteko, jo stisnemo na več bajtov ali kilobajtov s pomočjo gzipa in pošljemo na spletno mesto. Nato se odpne in dobi se zelo zanimiv učinek.
API za počitek
Rad bi posvetil malo pozornosti tako priljubljenim storitvam, kot je Rest API. Zavarovanje API-ja Rest je veliko težje kot običajno spletno mesto. Celo trivialne metode zaščite pred grobo uporabo gesel in drugimi nelegitimnimi dejavnostmi ne delujejo za Rest API.
Rest API je zelo enostavno zlomiti, ker neposredno dostopa do baze podatkov. Hkrati ima neuspeh takšne storitve precej resne posledice za poslovanje. Dejstvo je, da se Rest API običajno uporablja ne samo za glavno spletno stran, ampak tudi za mobilno aplikacijo in nekatere notranje poslovne vire. In če vse to pade, potem je učinek veliko močnejši kot v primeru preproste okvare spletne strani.
Nalaganje težke vsebine
Če nam ponudijo, da testiramo navadno enostransko aplikacijo, ciljno stran ali spletno mesto vizitke, ki nima kompleksne funkcionalnosti, iščemo težko vsebino. Na primer velike slike, ki jih pošlje strežnik, binarne datoteke, pdf dokumentacija - vse to poskušamo prenesti. Takšni testi dobro obremenijo datotečni sistem in zamašijo kanale, zato so učinkoviti. To pomeni, da tudi če strežnika ne zaustavite in prenašate veliko datoteko pri nizkih hitrostih, boste preprosto zamašili kanal ciljnega strežnika in nato bo prišlo do zavrnitve storitve.
Primer takega testa kaže, da se je stran pri hitrosti 30 RPS prenehala odzivati ali pa je povzročila 500. napako strežnika.
Ne pozabite na nastavitev strežnikov. Pogosto lahko ugotovite, da je oseba kupila virtualni stroj, tam namestila Apache, vse konfigurirala privzeto, namestila PHP aplikacijo in spodaj lahko vidite rezultat.
Tu je obremenitev šla v korenino in znašala le 10 RPS. Čakali smo 5 minut in strežnik se je zrušil. Res je, da ni povsem znano, zakaj je padel, obstaja pa domneva, da je imel preprosto preveč spomina in se zato ni več odzival.
Na podlagi valov
V zadnjem letu ali dveh so valovni napadi postali precej popularni. To je posledica dejstva, da številne organizacije kupujejo določene dele strojne opreme za zaščito pred napadi DDoS, ki zahtevajo določen čas, da zberejo statistiko in začnejo filtrirati napad. To pomeni, da ne filtrirajo napada v prvih 30-40 sekundah, ker kopičijo podatke in se učijo. V skladu s tem lahko v teh 30-40 sekundah na spletnem mestu zaženete toliko, da bo vir ležal dolgo časa, dokler ne bodo razčiščene vse zahteve.
Pri spodnjem napadu je bil interval 10 minut, po katerem je prišel nov, spremenjen del napada.
Se pravi, obramba se je naučila, začela filtrirati, prišel pa je nov, popolnoma drugačen del napada in obramba se je spet začela učiti. Dejansko filtriranje preneha delovati, zaščita postane neučinkovita in spletno mesto ni na voljo.
Za valovne napade so značilne zelo visoke vrednosti na vrhuncu, lahko doseže sto tisoč ali milijon zahtev na sekundo, v primeru L7. Če govorimo o L3 in 4, potem je lahko na stotine gigabitov prometa ali v skladu s tem na stotine mpps, če štejete v paketih.
Težava pri takih napadih je sinhronizacija. Napadi prihajajo iz botneta in zahtevajo visoko stopnjo sinhronizacije, da ustvarijo zelo velik enkratni skok. In to usklajevanje ne deluje vedno: včasih je rezultat nekakšen parabolični vrh, ki izgleda precej patetično.
Ne samo HTTP
Poleg HTTP na L7 radi izkoriščamo še druge protokole. Običajno spletno mesto, še posebej običajno gostovanje, praviloma štrli poštne protokole in MySQL. Poštni protokoli so manj obremenjeni kot baze podatkov, vendar jih je mogoče tudi precej učinkovito naložiti in na koncu povzročijo preobremenjen CPE na strežniku.
Z uporabo ranljivosti SSH iz leta 2016 smo bili zelo uspešni. Zdaj je bila ta ranljivost odpravljena za skoraj vse, vendar to ne pomeni, da obremenitve ni mogoče poslati v SSH. Lahko. Enostavno je ogromno avtorizacij, SSH požre skoraj ves CPU na strežniku, nato pa spletna stran propade od ene ali dveh zahtev na sekundo. V skladu s tem teh ene ali dveh zahtev, ki temeljita na dnevnikih, ni mogoče razlikovati od zakonitega nalaganja.
Številne povezave, ki jih odpremo v strežnikih, ostajajo tudi pomembne. Prej je bil za to kriv Apache, zdaj je za to dejansko kriv nginx, saj je pogosto konfiguriran privzeto. Število povezav, ki jih lahko nginx pusti odprte, je omejeno, zato odpremo to število povezav, nginx ne sprejme več nove povezave in posledično stran ne deluje.
Naša testna gruča ima dovolj procesorja za napad na rokovanje SSL. Načeloma, kot kaže praksa, to včasih radi počnejo tudi botneti. Po eni strani je jasno, da brez SSL-ja ne gre, saj Google rezultati, uvrstitev, varnost. Po drugi strani pa ima SSL na žalost težavo s procesorjem.
L3&4
Ko govorimo o napadu na ravni L3 in 4, običajno govorimo o napadu na ravni povezave. Takšno obremenitev je skoraj vedno mogoče razlikovati od legitimne, razen če gre za napad SYN-flood. Težava pri napadih SYN-flood za varnostna orodja je njihov velik obseg. Največja vrednost L3&4 je bila 1,5-2 Tbit/s. Tovrsten promet je zelo težko obdelati tudi za velika podjetja, vključno z Oracle in Google.
SYN in SYN-ACK sta paketa, ki se uporabljata pri vzpostavljanju povezave. Zato je SYN-poplavo težko ločiti od zakonite obremenitve: ni jasno, ali je to SYN, ki je prišel vzpostaviti povezavo, ali je del poplave.
UDP-poplava
Običajno napadalci nimajo zmogljivosti, ki jih imamo mi, zato se lahko ojačanje uporabi za organizacijo napadov. To pomeni, da napadalec pregleda internet in najde ranljive ali nepravilno konfigurirane strežnike, ki na primer v odgovor na en paket SYN odgovorijo s tremi SYN-ACK. S ponarejanjem izvornega naslova iz naslova ciljnega strežnika je mogoče z enim paketom povečati moč za recimo trikrat in promet preusmeriti na žrtev.
Težava z ojačanji je, da jih je težko zaznati. Nedavni primeri vključujejo senzacionalen primer ranljivega predpomnilnika memcached. Poleg tega je zdaj veliko IoT naprav, IP kamer, ki so prav tako večinoma privzeto konfigurirane, privzeto pa so napačno konfigurirane, zato napadalci najpogosteje izvajajo napade preko takih naprav.
Težavna SYN-poplava
SYN-flood je verjetno najbolj zanimiva vrsta napada z vidika razvijalca. Težava je v tem, da sistemski skrbniki za zaščito pogosto uporabljajo blokiranje IP. Poleg tega blokiranje IP ne vpliva le na sistemske skrbnike, ki delujejo s skripti, ampak na žalost tudi na nekatere varnostne sisteme, ki so kupljeni za veliko denarja.
Ta metoda se lahko spremeni v katastrofo, saj če napadalci zamenjajo naslove IP, bo podjetje blokiralo lastno podomrežje. Ko požarni zid blokira lastno gručo, izhod ne bo uspel pri zunanjih interakcijah in vir bo odpovedal.
Poleg tega ni težko blokirati lastnega omrežja. Če ima naročnikova pisarna Wi-Fi omrežje ali če se zmogljivost virov meri z različnimi nadzornimi sistemi, potem vzamemo IP naslov tega nadzornega sistema ali naročnikove pisarne Wi-Fi in ga uporabimo kot vir. Na koncu se zdi, da je vir na voljo, vendar so ciljni naslovi IP blokirani. Tako je Wi-Fi omrežje konference HighLoad, kjer se predstavlja nov produkt podjetja, lahko blokirano, kar ima za seboj določene poslovne in ekonomske stroške.
Med testiranjem ne moremo uporabiti ojačanja prek memcached z nobenimi zunanjimi viri, ker obstajajo dogovori za pošiljanje prometa samo na dovoljene naslove IP. V skladu s tem uporabljamo ojačanje prek SYN in SYN-ACK, ko se sistem na pošiljanje enega SYN odzove z dvema ali tremi SYN-ACK-i, na izhodu pa se napad pomnoži dvakrat ali trikrat.
Orodja
Eno glavnih orodij, ki jih uporabljamo za delovno obremenitev L7, je Yandex-tank. Zlasti fantom se uporablja kot pištola, poleg tega obstaja več skriptov za generiranje kartuš in za analizo rezultatov.
Tcpdump se uporablja za analizo omrežnega prometa, Nmap pa za analizo strežnika. Za ustvarjanje obremenitve na ravni L3 in 4 se uporablja OpenSSL in malo naše lastne čarovnije s knjižnico DPDK. DPDK je Intelova knjižnica, ki vam omogoča delo z omrežnim vmesnikom mimo sklada Linux in s tem poveča učinkovitost. Seveda DPDK ne uporabljamo samo na nivoju L3&4, temveč tudi na nivoju L7, ker nam omogoča ustvarjanje zelo visokega pretoka obremenitve, v obsegu več milijonov zahtev na sekundo z enega stroja.
Uporabljamo tudi določene generatorje prometa in posebna orodja, ki jih pišemo za specifične teste. Če se spomnimo ranljivosti pod SSH, potem zgornjega niza ni mogoče izkoristiti. Če napademo poštni protokol, vzamemo poštne pripomočke ali preprosto napišemo skripte nanje.
Ugotovitve
Za zaključek bi rad povedal:
- Poleg klasičnega obremenitvenega testiranja je potrebno izvesti tudi obremenitveno testiranje. Imamo realen primer, ko je partnerjev podizvajalec izvedel samo obremenitveni preizkus. Pokazalo se je, da lahko vir prenese normalno obremenitev. Potem pa se je pojavila nenormalna obremenitev, obiskovalci strani so začeli vir uporabljati nekoliko drugače, posledično je podizvajalec ležal. Zato je vredno iskati ranljivosti, tudi če ste že zaščiteni pred napadi DDoS.
- Potrebno je izolirati nekatere dele sistema od drugih. Če imate iskanje, ga morate premakniti na ločene stroje, torej niti na Docker. Ker če iskanje ali avtorizacija ne uspe, bo vsaj nekaj delovalo naprej. V primeru spletne trgovine bodo uporabniki še naprej iskali izdelke v katalogu, šli iz agregatorja, kupovali, če so že avtorizirani, ali avtorizirali prek OAuth2.
- Ne zanemarjajte vseh vrst storitev v oblaku.
- Uporabite CDN ne samo za optimizacijo zamud v omrežju, ampak tudi kot sredstvo za zaščito pred napadi na izčrpanost kanala in preprosto poplavljanje v statični promet.
- Treba je uporabiti specializirane storitve zaščite. Ne morete se zaščititi pred napadi L3&4 na ravni kanala, ker najverjetneje preprosto nimate zadostnega kanala. Prav tako je malo verjetno, da se boste ubranili napadov L7, saj so lahko zelo veliki. Poleg tega je iskanje majhnih napadov še vedno prednost posebnih storitev, posebnih algoritmov.
- Redno posodabljajte. To ne velja le za jedro, ampak tudi za demon SSH, še posebej, če jih imate odprte navzven. Načeloma je treba posodobiti vse, saj določenim ranljivostim verjetno ne boste mogli slediti sami.
Vir: www.habr.com