Variti arendab kaitset robotite ja DDoS rünnakute vastu ning viib läbi ka stressi- ja koormusteste. HighLoad++ 2018 konverentsil rääkisime, kuidas kaitsta ressursse erinevat tüüpi rünnakute eest. Lühidalt: isoleerige süsteemi osad, kasutage pilveteenuseid ja CDN-e ning värskendage regulaarselt. Kuid ilma spetsialiseeritud ettevõteteta ei saa te ikkagi kaitsega hakkama :)
Enne teksti lugemist saate lugeda lühikokkuvõtteid .
Ja kui teile ei meeldi lugeda või soovite lihtsalt videot vaadata, on meie reportaaži salvestus allpool spoileri all.
Aruande videosalvestus
Paljud ettevõtted juba teavad, kuidas koormusteste teha, kuid mitte kõik ei tee stressiteste. Mõned meie kliendid arvavad, et nende sait on haavamatu, kuna neil on kõrge koormusega süsteem ja see kaitseb hästi rünnakute eest. Näitame, et see pole täiesti tõsi.
Loomulikult saame enne testide läbiviimist kliendilt allkirjastatud ja templiga loa ning meie abiga ei saa DDoS-i ründe sooritada kellelegi. Testimine toimub kliendi valitud ajal, mil tema ressursi liiklus on minimaalne ja juurdepääsuprobleemid kliente ei mõjuta. Lisaks, kuna testimise käigus võib alati midagi valesti minna, on meil kliendiga pidev kontakt. See võimaldab mitte ainult raporteerida saavutatud tulemustest, vaid ka testimise käigus midagi muuta. Testimise lõppedes koostame alati akti, milles juhime tähelepanu avastatud puudustele ja anname soovitusi saidi nõrkade külgede kõrvaldamiseks.
Kuidas me töötame
Testimisel emuleerime botnetti. Kuna töötame klientidega, kes ei asu meie võrkudes, siis tagamaks, et test ei lõpeks piirangute või rakenduva kaitse tõttu esimesel minutil, tarnime koormust mitte ühest IP-st, vaid oma alamvõrgust. Lisaks on meil märkimisväärse koormuse tekitamiseks oma üsna võimas testserver.
Postulaadid
Liiga palju ei tähenda head
Mida vähem koormust suudame ressursi ebaõnnestuda, seda parem. Kui saate saidi peatada ühe taotluse sekundis või isegi ühe päringu minutis, on see suurepärane. Sest õeluse seaduse järgi satuvad kasutajad või ründajad kogemata sellesse konkreetsesse haavatavusesse.
Osaline ebaõnnestumine on parem kui täielik ebaõnnestumine
Soovitame alati muuta süsteemid heterogeenseks. Pealegi tasub need eraldada füüsilisel tasandil, mitte ainult konteineriseerimise teel. Füüsilise eraldamise korral, isegi kui saidil midagi ebaõnnestub, on suur tõenäosus, et see ei lakka täielikult töötamast ja kasutajatel on jätkuvalt juurdepääs vähemalt osale funktsioonidest.
Hea arhitektuur on jätkusuutlikkuse aluseks
Ressursi tõrketaluvus ning rünnakutele ja koormustele vastupidavus tuleks kindlaks määrata projekteerimisetapis, tegelikult juba esimeste vooskeemide märkmikusse joonistamise etapis. Sest kui saatuslikud vead sisse hiilivad, on neid võimalik edaspidi parandada, kuid see on väga raske.
Hea peaks olema mitte ainult kood, vaid ka konfiguratsioon
Paljud arvavad, et hea arendusmeeskond on tõrketaluvuse garantii. Hea arendusmeeskond on tõesti vajalik, kuid seal peavad olema ka head toimimised, head DevOps. See tähendab, et vajame spetsialiste, kes konfigureerivad Linuxi ja võrgu õigesti, kirjutavad nginxis õigesti konfiguratsioonid, seavad piirangud jne. Vastasel juhul töötab ressurss hästi ainult testimisel ja ühel hetkel läheb tootmises kõik katki.
Koormus- ja stressitestide erinevused
Koormustestimine võimaldab tuvastada süsteemi toimimise piirid. Stressitestimise eesmärk on leida süsteemi nõrkusi ja seda kasutatakse selle süsteemi lõhkumiseks ja selle kontrollimiseks, kuidas see teatud osade rikke korral käitub. Sellisel juhul jääb koormuse iseloom kliendile tavaliselt enne stressitesti algust teadmata.
L7 rünnakute iseloomulikud tunnused
Tavaliselt jagame koormatüübid L7 ja L3&4 tasemel koormusteks. L7 on koormus rakenduse tasemel, enamasti tähendab see ainult HTTP-d, kuid me peame silmas mis tahes koormust TCP-protokolli tasemel.
L7 rünnakutel on teatud eripärad. Esiteks tulevad need otse rakendusse, see tähendab, et on ebatõenäoline, et need kajastuvad võrgu kaudu. Sellised ründed kasutavad loogikat ning tänu sellele tarbivad väga efektiivselt ja vähese liiklusega protsessorit, mälu, ketast, andmebaasi ja muid ressursse.
HTTP üleujutus
Iga rünnaku puhul on koormust kergem tekitada kui käsitseda ja L7 puhul on see ka tõsi. Ründeliiklust pole alati lihtne eristada legitiimsest liiklusest ja enamasti saab seda teha sageduse järgi, kuid kui kõik on õigesti planeeritud, siis pole logidest aru saada, kus rünnak on ja kus on õigustatud päringud.
Esimese näitena kaaluge HTTP üleujutuse rünnakut. Graafik näitab, et sellised rünnakud on tavaliselt väga võimsad, allolevas näites ületas päringute tipparv 600 tuhat minutis.
HTTP Flood on lihtsaim viis koormuse loomiseks. Tavaliselt kulub selleks mingisugune koormuse testimise tööriist, näiteks ApacheBench, ning seab päringu ja eesmärgi. Sellise lihtsa lähenemise korral on suur tõenäosus sattuda serveri vahemällu, kuid sellest on lihtne mööda minna. Näiteks juhuslike stringide lisamine päringule, mis sunnib serverit pidevalt värsket lehte teenindama.
Samuti ärge unustage koormuse loomise protsessis kasutajaagenti. Paljud populaarsete testimistööriistade kasutajaagendid on süsteemiadministraatorite poolt filtreeritud ja sellisel juhul ei pruugi koormus lihtsalt taustaprogrammi jõuda. Tulemust saate oluliselt parandada, kui sisestate päringusse brauserist enam-vähem kehtiva päise.
Nii lihtsad kui HTTP üleujutuse rünnakud on, on neil ka oma puudused. Esiteks on koormuse loomiseks vaja palju võimsust. Teiseks on selliseid rünnakuid väga lihtne tuvastada, eriti kui need tulevad ühelt aadressilt. Selle tulemusena hakkavad taotlusi kohe filtreerima kas süsteemiadministraatorid või isegi teenusepakkuja tasemel.
Mida otsida
Et vähendada taotluste arvu sekundis ilma tõhusust kaotamata, peate näitama veidi kujutlusvõimet ja uurima saiti. Seega saate laadida mitte ainult kanalit või serverit, vaid ka rakenduse üksikuid osi, näiteks andmebaase või failisüsteeme. Samuti saab lehelt otsida kohti, kus tehakse suuri arvutusi: kalkulaatorid, tootevaliku lehed jne. Lõpuks juhtub sageli, et saidil on mingi PHP-skript, mis genereerib mitmesaja tuhande rea lehe. Selline skript koormab oluliselt ka serverit ja võib saada rünnaku sihtmärgiks.
Kust otsida
Kui me enne testimist ressurssi skannime, vaatame esmalt loomulikult saiti ennast. Otsime kõikvõimalikke sisestusvälju, raskeid faile – üldiselt kõike, mis võib ressursile probleeme tekitada ja selle tööd aeglustada. Siin aitavad Google Chrome'is ja Firefoxis banaalsed arendustööriistad, mis näitavad lehe reageerimisaegu.
Skaneerime ka alamdomeene. Näiteks on olemas teatud veebipood abc.com ja sellel on alamdomeen admin.abc.com. Tõenäoliselt on see volitusega administraatoripaneel, kuid kui te seda koormate, võib see peamise ressursi jaoks probleeme tekitada.
Saidil võib olla alamdomeen api.abc.com. Tõenäoliselt on see mobiilirakenduste ressurss. Rakenduse leiate App Store'ist või Google Playst, installige spetsiaalne pääsupunkt, lahkake API-d ja registreerige testkontod. Probleem on selles, et inimesed arvavad sageli, et kõik, mis on autoriseerimisega kaitstud, on teenuse keelamise rünnakute suhtes immuunne. Väidetavalt on autoriseerimine parim CAPTCHA, kuid see pole nii. 10–20 testkontot on lihtne teha, kuid nende loomisega pääseme ligi keerukatele ja varjamatutele funktsioonidele.
Loomulikult vaatame ajalugu, faili robots.txt ja WebArchive'i, ViewDNS-i ning otsime ressursi vanu versioone. Mõnikord juhtub, et arendajad on välja lasknud näiteks mail2.yandex.net, kuid vana versioon mail.yandex.net jääb alles. Seda mail.yandex.net ei toetata enam, sellele ei eraldata arendusressursse, kuid see tarbib jätkuvalt andmebaasi. Sellest lähtuvalt saate vana versiooni kasutades tõhusalt kasutada taustaprogrammi ressursse ja kõike, mis on paigutuse taga. Muidugi ei juhtu seda alati, kuid me kohtame seda siiski üsna sageli.
Loomulikult analüüsime kõiki päringu parameetreid ja küpsise struktuuri. Näiteks saate küpsise sees asuvasse JSON-massiivi lisada väärtust, luua palju pesastusi ja panna ressurss ebamõistlikult kauaks tööle.
Otsingukoormus
Esimene asi, mis saidi uurimisel meelde tuleb, on andmebaasi laadimine, kuna peaaegu kõigil on otsing ja peaaegu kõigi jaoks on see kahjuks halvasti kaitstud. Millegipärast ei pööra arendajad otsingule piisavalt tähelepanu. Kuid siin on üks soovitus – te ei tohiks teha sama tüüpi päringuid, sest võite kokku puutuda vahemällu salvestamisega, nagu HTTP üleujutuse puhul.
Samuti ei ole andmebaasi juhuslike päringute tegemine alati efektiivne. Palju parem on koostada otsingu jaoks asjakohaste märksõnade loend. Kui pöördume tagasi veebipoe näite juurde: oletame, et sait müüb autorehve ja võimaldab teil määrata rehvide raadiuse, auto tüübi ja muud parameetrid. Sellest tulenevalt sunnivad asjakohaste sõnade kombinatsioonid andmebaasi töötama palju keerulisemates tingimustes.
Lisaks tasub kasutada lehekülgedele viitamist: otsingul on palju raskem tagastada otsingutulemuste eelviimast lehekülge kui esimest. See tähendab, et lehekülgede muutmise abil saate koormust veidi mitmekesistada.
Allolev näide näitab otsingukoormust. On näha, et alates testi esimesest sekundist kiirusel kümme päringut sekundis sait läks alla ega vastanud.
Kui otsingut pole?
Kui otsingut ei toimu, ei tähenda see, et sait ei sisalda muid haavatavaid sisestusvälju. See väli võib olla autoriseerimine. Tänapäeval meeldib arendajatele teha keerukaid räsi, et kaitsta sisselogimisandmebaasi vikerkaaretabeli rünnakute eest. See on hea, kuid sellised räsid tarbivad palju protsessori ressursse. Suur valelubade voog põhjustab protsessori rikke ja selle tulemusena lakkab sait töötamast.
Kõikvõimalike kommentaaride ja tagasiside vormide olemasolu saidil on põhjus, miks saata sinna väga suuri tekste või tekitada lihtsalt tohutu üleujutus. Mõnikord aktsepteerivad saidid manustatud faile, sealhulgas gzip-vormingus. Sel juhul võtame 1TB faili, tihendame selle gzipi abil mitmeks baidiks või kilobaidiks ja saadame saidile. Seejärel tehakse see lahti ja saadakse väga huvitav efekt.
Puhkuse API
Tahaksin pöörata veidi tähelepanu sellistele populaarsetele teenustele nagu Rest API. Rest API turvalisus on palju keerulisem kui tavalise veebisaidi puhul. Isegi triviaalsed kaitsemeetodid parooli toore jõu ja muu ebaseadusliku tegevuse eest ei tööta Rest API puhul.
Rest API-d on väga lihtne murda, kuna see pääseb otse andmebaasile. Samas toob sellise teenuse ebaõnnestumine ettevõtlusele kaasa üsna tõsiseid tagajärgi. Fakt on see, et Rest API-t kasutatakse tavaliselt mitte ainult põhiveebisaidi jaoks, vaid ka mobiilirakenduse ja mõne ettevõttesisese ressursi jaoks. Ja kui see kõik ära kukub, siis on mõju palju tugevam kui lihtsa veebilehe rikke korral.
Raske sisu laadimine
Kui meile pakutakse testida mõnda tavalist ühelehelist rakendust, maandumislehte või visiitkaartide veebisaiti, millel pole keerukat funktsionaalsust, siis otsime rasket sisu. Näiteks suured pildid, mida server saadab, binaarfailid, pdf-dokumentatsioon – me proovime seda kõike alla laadida. Sellised testid laadivad failisüsteemi hästi ja ummistavad kanaleid ning on seetõttu tõhusad. See tähendab, et isegi kui te serverit maha ei pane, laadite väikese kiirusega alla suure faili, ummistate lihtsalt sihtserveri kanali ja seejärel tekib teenuse keelamine.
Sellise testi näide näitab, et kiirusel 30 RPS lakkas sait reageerimast või tekitas 500. serverivigu.
Ärge unustage serverite seadistamist. Tihti võib juhtuda, et inimene ostis virtuaalmasina, installis sinna Apache, seadistas kõik vaikimisi, installis PHP rakenduse ja allpool näete tulemust.
Siin läks koormus juurele ja ulatus vaid 10 RPS-ni. Ootasime 5 minutit ja server jooksis kokku. Tõsi, pole täielikult teada, miks ta kukkus, kuid oletatakse, et tal oli lihtsalt liiga palju mälu ja ta lõpetas seetõttu reageerimise.
Lainepõhine
Viimase aasta-paari jooksul on lainerünnakud muutunud üsna populaarseks. Selle põhjuseks on asjaolu, et paljud organisatsioonid ostavad DDoS-i kaitseks teatud riistvara, mille jaoks kulub teatud aja jooksul statistika kogumine rünnaku filtreerimise alustamiseks. See tähendab, et nad ei filtreeri rünnakut esimese 30–40 sekundi jooksul, sest nad koguvad andmeid ja õpivad. Sellest lähtuvalt saate selle 30–40 sekundi jooksul saidil nii palju käivitada, et ressurss lamab pikka aega, kuni kõik taotlused on kustutatud.
Alltoodud rünnaku puhul oli 10-minutiline intervall, mille järel saabus uus, muudetud rünnakuosa.
See tähendab, et kaitse õppis, hakkas filtreerima, kuid saabus uus, täiesti erinev osa rünnakust ja kaitse hakkas uuesti õppima. Tegelikult lakkab filtreerimine töötamast, kaitse muutub ebaefektiivseks ja sait pole saadaval.
Lainerünnakuid iseloomustavad tipptasemel väga kõrged väärtused, L7 puhul võib see ulatuda saja tuhande või miljoni päringuni sekundis. Kui me räägime L3&4-st, siis võib seal olla sadu gigabitte liiklust või vastavalt sadu mpps, kui arvestada pakettide kaupa.
Selliste rünnakute probleem on sünkroonimine. Rünnakud pärinevad robotvõrgust ja nõuavad väga suure ühekordse hüppe tekitamiseks suurt sünkroniseerimist. Ja see koordineerimine ei õnnestu alati: mõnikord on väljundiks mingi paraboolne tipp, mis tundub üsna haletsusväärne.
Mitte ainult HTTP
Lisaks L7 HTTP-le meeldib meile kasutada ka teisi protokolle. Reeglina on tavalisel veebisaidil, eriti tavalisel hostimisel, meiliprotokollid ja MySQL paistavad silma. Meiliprotokollid on vähem koormatud kui andmebaasid, kuid neid saab laadida ka üsna tõhusalt ja lõppeda serveris ülekoormatud protsessoriga.
2016. aasta SSH haavatavust kasutasime üsna edukalt. Nüüd on see haavatavus parandatud peaaegu kõigi jaoks, kuid see ei tähenda, et laadimist ei saaks SSH-le esitada. Saab. Volitusi on lihtsalt tohutult palju, SSH sööb peaaegu kogu serveri CPU ära ja siis kukub veebisait kokku ühest-kahest päringust sekundis. Sellest tulenevalt ei saa neid logidel põhinevaid ühte või kahte päringut eristada seaduslikust laadimisest.
Paljud ühendused, mille me serverites avame, jäävad samuti asjakohaseks. Varem oli selles süüdi Apache, nüüd on selles süüdi tegelikult nginx, kuna see on sageli vaikimisi konfigureeritud. Ühenduste arv, mida nginx saab avatuna hoida, on piiratud, seega avame selle arvu ühendusi, nginx ei aktsepteeri enam uut ühendust ja selle tulemusena sait ei tööta.
Meie testklastril on SSL-i käepigistuse ründamiseks piisavalt protsessorit. Põhimõtteliselt, nagu praktika näitab, meeldib mõnikord ka botnetidele seda teha. Ühest küljest on selge, et ilma SSL-ita ei saa, sest Google'i tulemused, järjestus, turvalisus. Teisest küljest on SSL-is kahjuks protsessori probleem.
L3&4
Kui me räägime rünnakust L3 ja 4 tasemel, siis tavaliselt räägime rünnakust lingi tasemel. Selline koormus on peaaegu alati eristatav legitiimsest, välja arvatud juhul, kui tegemist on SYN-i üleujutuse rünnakuga. Turvatööriistade SYN-üleujutusrünnakute probleem on nende suur maht. Maksimaalne L3&4 väärtus oli 1,5-2 Tbit/s. Sellist liiklust on väga raske töödelda isegi suurtel ettevõtetel, sealhulgas Oracle ja Google.
SYN ja SYN-ACK on paketid, mida kasutatakse ühenduse loomisel. Seetõttu on SYN-üleujutust raske eristada legitiimsest koormusest: pole selge, kas see on SYN, mis tuli ühenduse loomiseks või üleujutuse osa.
UDP-üleujutus
Tavaliselt pole ründajatel selliseid võimalusi, mis meil on, seega saab rünnakute korraldamiseks kasutada võimendust. See tähendab, et ründaja skannib Internetti ja leiab kas haavatavad või valesti konfigureeritud serverid, mis reageerivad näiteks ühele SYN-paketile kolme SYN-ACK-iga. Lähteaadressi võltsimisel sihtserveri aadressist on võimalik ühe paketiga võimsust näiteks kolm korda suurendada ja liiklust ohvrile ümber suunata.
Võimendite probleem seisneb selles, et neid on raske tuvastada. Hiljutised näited hõlmavad sensatsioonilist haavatavate memcached juhtumit. Lisaks on praegu palju IoT-seadmeid, IP-kaameraid, mis on samuti enamasti vaikimisi seadistatud ja vaikimisi on need valesti seadistatud, mistõttu ründajad ründavad kõige sagedamini just selliste seadmete kaudu.
Raske SYN-üleujutus
SYN-Flood on arendaja vaatevinklist ilmselt kõige huvitavam ründetüüp. Probleem on selles, et süsteemiadministraatorid kasutavad kaitseks sageli IP blokeerimist. Veelgi enam, IP-blokeerimine ei mõjuta mitte ainult skripte kasutavaid süsteemiadministraatoreid, vaid kahjuks ka mõningaid turvasüsteeme, mida ostetakse suure raha eest.
See meetod võib muutuda katastroofiks, sest kui ründajad asendavad IP-aadressid, blokeerib ettevõte oma alamvõrgu. Kui tulemüür blokeerib oma klastri, ebaõnnestub väljund väliste interaktsioonide korral ja ressurss ebaõnnestub.
Lisaks pole keeruline oma võrku blokeerida. Kui kliendi kontoris on Wi-Fi võrk või kui ressursside jõudlust mõõdetakse erinevate seiresüsteemide abil, siis võtame selle seiresüsteemi või kliendi kontori Wi-Fi IP-aadressi ja kasutame seda allikana. Lõpuks näib ressurss olevat saadaval, kuid siht-IP-aadressid on blokeeritud. Seega võib HighLoadi konverentsi Wi-Fi võrk, kus esitletakse ettevõtte uut toodet, olla blokeeritud ning sellega kaasnevad teatud äri- ja majanduskulud.
Testimise ajal ei saa me memcachedi kaudu võimendust kasutada ühegi välise ressursi abil, kuna on sõlmitud kokkulepped liikluse saatmiseks ainult lubatud IP-aadressidele. Vastavalt sellele kasutame võimendamist SYN-i ja SYN-ACK-i kaudu, kui süsteem vastab ühe SYN-i saatmisele kahe või kolme SYN-ACK-iga ja väljundis korrutatakse rünnak kahe või kolmekordsega.
Töövahendid
Üks peamisi tööriistu, mida me L7 töökoormuse jaoks kasutame, on Yandex-tank. Eelkõige kasutatakse relvana fantoomi, lisaks on mitu skripti padrunite genereerimiseks ja tulemuste analüüsimiseks.
Tcpdumpi kasutatakse võrguliikluse analüüsimiseks ja Nmapi kasutatakse serveri analüüsimiseks. Koormuse loomiseks L3 ja 4 tasemel kasutatakse OpenSSL-i ja natuke meie enda võlu DPDK teegiga. DPDK on Inteli teek, mis võimaldab teil töötada võrguliidesega Linuxi pinust mööda minnes, suurendades seeläbi tõhusust. Loomulikult kasutame DPDK-d mitte ainult L3&4, vaid ka L7 tasemel, sest see võimaldab meil luua väga suure koormusvoo, mis jääb ühest masinast mitme miljoni päringu vahemikku sekundis.
Samuti kasutame teatud liikluse generaatoreid ja spetsiaalseid tööriistu, mida kirjutame konkreetsete testide jaoks. Kui tuletame meelde SSH haavatavust, siis ülaltoodud komplekti ei saa kasutada. Kui ründame meiliprotokolli, võtame meiliutiliite või kirjutame neile lihtsalt skripte.
Järeldused
Kokkuvõtteks tahaksin öelda:
- Lisaks klassikalisele koormustestile on vaja läbi viia stressitestid. Meil on ehe näide, kus partneri alltöövõtja tegi ainult koormustesti. See näitas, et ressurss peab normaalsele koormusele vastu. Kuid siis ilmnes ebanormaalne koormus, saidi külastajad hakkasid ressurssi veidi teisiti kasutama ja selle tulemusena jäi alltöövõtja pikali. Seega tasub turvaauke otsida ka siis, kui oled juba DDoS-i rünnakute eest kaitstud.
- Mõned süsteemi osad on vaja teistest isoleerida. Kui teil on otsing, peate selle teisaldama eraldi masinatesse, st isegi mitte Dockerisse. Sest kui otsing või autoriseerimine ebaõnnestub, töötab vähemalt midagi edasi. Veebipoe puhul leiavad kasutajad jätkuvalt tooteid kataloogist, lähevad koondajast, ostavad, kui neil on juba volitus, või autoriseerivad OAuth2 kaudu.
- Ärge jätke tähelepanuta igasuguseid pilveteenuseid.
- Kasutage CDN-i mitte ainult võrgu viivituste optimeerimiseks, vaid ka kaitsevahendina kanali ammendumise ja lihtsalt staatilise liikluse üleujutamise eest.
- Vajalik on kasutada spetsiaalseid kaitseteenuseid. Kanali tasemel ei saa te end L3&4 rünnakute eest kaitsta, sest suure tõenäosusega pole teil lihtsalt piisavalt kanalit. Samuti ei suuda te tõenäoliselt L7 rünnakuid tõrjuda, kuna need võivad olla väga suured. Lisaks on väikeste rünnakute otsimine endiselt eriteenistuste, erialgoritmide eesõigus.
- Värskendage regulaarselt. See kehtib mitte ainult kerneli, vaid ka SSH-deemoni kohta, eriti kui need on väljapoole avatud. Põhimõtteliselt tuleb kõike värskendada, sest tõenäoliselt ei suuda te teatud turvaauke iseseisvalt jälgida.
Allikas: www.habr.com