ProHoster > Blogs > Administrācija > DDoS palīgā: kā mēs veicam stresa un slodzes testus

DDoS palīgā: kā mēs veicam stresa un slodzes testus

DDoS palīgā: kā mēs veicam stresa un slodzes testus

Variti izstrādā aizsardzÄ«bu pret robotprogrammatÅ«ru un DDoS uzbrukumiem, kā arÄ« veic stresa un slodzes testÄ“Å”anu. HighLoad++ 2018 konferencē mēs runājām par to, kā nodroÅ”ināt resursus no dažāda veida uzbrukumiem. ÄŖsāk sakot: izolējiet sistēmas daļas, izmantojiet mākoņpakalpojumus un CDN un regulāri atjauniniet. Bet jÅ«s joprojām nevarēsit tikt galā ar aizsardzÄ«bu bez specializētiem uzņēmumiem :)

Pirms teksta lasÄ«Å”anas varat izlasÄ«t Ä«sos kopsavilkumus konferences vietnē.
Un, ja jums nepatÄ«k lasÄ«t vai vienkārÅ”i vēlaties skatÄ«ties video, mÅ«su reportāžas ieraksts atrodas zemāk zem spoilera.

Reportāžas video ieraksts

Daudzi uzņēmumi jau zina, kā veikt slodzes testÄ“Å”anu, bet ne visi veic stresa testus. Daži no mÅ«su klientiem uzskata, ka viņu vietne ir neievainojama, jo viņiem ir augstas slodzes sistēma un tā labi aizsargā pret uzbrukumiem. Mēs parādām, ka tā nav pilnÄ«gi taisnÄ«ba.
Protams, pirms testu veikÅ”anas mēs saņemam pasÅ«tÄ«tāja atļauju, parakstÄ«tu un apzÄ«mogotu, un ar mÅ«su palÄ«dzÄ«bu DDoS uzbrukumu nevienam nevar veikt. TestÄ“Å”ana tiek veikta klienta izvēlētā laikā, kad viņa resursa plÅ«sma ir minimāla un piekļuves problēmas klientus neietekmēs. Turklāt, tā kā testÄ“Å”anas procesā vienmēr kaut kas var noiet greizi, mums ir pastāvÄ«gs kontakts ar klientu. Tas ļauj ne tikai ziņot par sasniegtajiem rezultātiem, bet arÄ« kaut ko mainÄ«t testÄ“Å”anas laikā. Pabeidzot testÄ“Å”anu, mēs vienmēr sastādām ziņojumu, kurā norādām uz atklātajiem trÅ«kumiem un sniedzam ieteikumus vietnes nepilnÄ«bu novērÅ”anai.

Kā mēs strādājam

Pārbaudot, mēs emulējam robottÄ«klu. Tā kā mēs strādājam ar klientiem, kuri neatrodas mÅ«su tÄ«klos, lai nodroÅ”inātu, ka pārbaude nebeidzas pirmajā minÅ«tē ierobežojumu vai iedarbinātas aizsardzÄ«bas dēļ, mēs piegādājam slodzi nevis no viena IP, bet gan no sava apakÅ”tÄ«kla. Turklāt, lai radÄ«tu ievērojamu slodzi, mums ir savs diezgan jaudÄ«gs testa serveris.

Postulāti

Pārāk daudz nenozīmē labu
Jo mazāk slodzes mēs varam novest resursu lÄ«dz neveiksmei, jo labāk. Ja jÅ«s varat likt vietnei pārtraukt darbÄ«bu, veicot vienu pieprasÄ«jumu sekundē vai pat vienu pieprasÄ«jumu minÅ«tē, tas ir lieliski. Jo saskaņā ar nelietÄ«bas likumu lietotāji vai uzbrucēji nejauÅ”i nonāks Å”ajā konkrētajā ievainojamÄ«bā.

Daļēja neveiksme ir labāka par pilnīgu neveiksmi
Mēs vienmēr iesakām padarÄ«t sistēmas neviendabÄ«gas. Turklāt ir vērts tos atdalÄ«t fiziskā lÄ«menÄ«, nevis tikai konteinerizējot. Fiziskas atdalÄ«Å”anas gadÄ«jumā, pat ja vietnē kaut kas neizdodas, pastāv liela varbÅ«tÄ«ba, ka tā pilnÄ«bā nepārtrauks darboties, un lietotājiem joprojām bÅ«s piekļuve vismaz daļai funkcionalitātes.

Laba arhitektūra ir ilgtspējas pamats
Resursa defektu tolerance un tā spēja izturēt uzbrukumus un slodzes bÅ«tu jānosaka projektÄ“Å”anas stadijā, faktiski jau pirmo blokshēmu zÄ«mÄ“Å”anas stadijā piezÄ«mjdatorā. Jo, ja piezogas liktenÄ«gas kļūdas, tās ir iespējams izlabot nākotnē, bet tas ir ļoti grÅ«ti.

Labam jābūt ne tikai kodam, bet arī konfigurācijai
Daudzi cilvēki domā, ka laba izstrādes komanda ir kļūmju toleranta servisa garantija. Laba izstrādes komanda patieŔām ir nepiecieÅ”ama, taču ir jābÅ«t arÄ« labām darbÄ«bām, labiem DevOps. Tas ir, mums ir nepiecieÅ”ami speciālisti, kas pareizi konfigurēs Linux un tÄ«klu, pareizi uzrakstÄ«s konfigurācijas nginx, noteiks ierobežojumus utt. Pretējā gadÄ«jumā resurss labi darbosies tikai testÄ“Å”anā, un vienā brÄ«dÄ« viss salÅ«zÄ«s ražoÅ”anā.

AtŔķirÄ«bas starp slodzes un stresa testÄ“Å”anu
Slodzes pārbaude ļauj noteikt sistēmas darbÄ«bas robežas. Stresa testÄ“Å”ana ir vērsta uz sistēmas vājo vietu atraÅ”anu, un to izmanto, lai izjauktu Å”o sistēmu un redzētu, kā tā uzvedÄ«sies atseviŔķu daļu atteices procesā. Šādā gadÄ«jumā slodzes veids parasti klientam paliek nezināms pirms stresa testÄ“Å”anas sākuma.

L7 uzbrukumu atŔķirīgās iezīmes

Mēs parasti sadalām kravas veidus slodzēs L7 un L3 un 4 līmeņos. L7 ir slodze lietojumprogrammas līmenī, visbiežāk tas nozīmē tikai HTTP, bet mēs domājam jebkuru slodzi TCP protokola līmenī.
L7 uzbrukumiem ir noteiktas atŔķirÄ«gas iezÄ«mes. Pirmkārt, tie nonāk tieÅ”i lietojumprogrammā, tas ir, maz ticams, ka tie tiks atspoguļoti, izmantojot tÄ«kla lÄ«dzekļus. Šādi uzbrukumi izmanto loÄ£iku, un tāpēc tie ļoti efektÄ«vi un ar mazu trafiku patērē CPU, atmiņu, disku, datu bāzi un citus resursus.

HTTP plūdi

Jebkura uzbrukuma gadÄ«jumā slodzi ir vieglāk izveidot nekā rÄ«koties, un L7 gadÄ«jumā tas arÄ« ir taisnÄ«ba. Ne vienmēr ir viegli atŔķirt uzbrukuma trafiku no likumÄ«gas, un visbiežāk to var izdarÄ«t pēc biežuma, taču, ja viss ir pareizi izplānots, tad no žurnāliem nevar saprast, kur atrodas uzbrukums un kur ir likumÄ«gi pieprasÄ«jumi.
Kā pirmo piemēru apsveriet HTTP plÅ«du uzbrukumu. Diagrammā redzams, ka Ŕādi uzbrukumi parasti ir ļoti spēcÄ«gi; zemāk esoÅ”ajā piemērā maksimālais pieprasÄ«jumu skaits pārsniedza 600 tÅ«kstoÅ”us minÅ«tē.

DDoS palīgā: kā mēs veicam stresa un slodzes testus

HTTP plÅ«di ir vienkārŔākais veids, kā izveidot slodzi. Parasti tam ir nepiecieÅ”ams kāds slodzes pārbaudes rÄ«ks, piemēram, ApacheBench, un tiek iestatÄ«ts pieprasÄ«jums un mērÄ·is. Izmantojot Ŕādu vienkārÅ”u pieeju, pastāv liela varbÅ«tÄ«ba, ka tiks saglabāta servera keÅ”atmiņa, taču to ir viegli apiet. Piemēram, pieprasÄ«jumam pievienojot nejauÅ”as virknes, kas liks serverim pastāvÄ«gi apkalpot jaunu lapu.
Tāpat slodzes izveides procesā neaizmirstiet par lietotāja aÄ£entu. Daudzus populāro testÄ“Å”anas rÄ«ku lietotāju aÄ£entus filtrē sistēmas administratori, un Å”ajā gadÄ«jumā slodze var vienkārÅ”i nesasniegt aizmugursistēmu. Rezultātu var ievērojami uzlabot, pieprasÄ«jumā ievietojot vairāk vai mazāk derÄ«gu pārlÅ«kprogrammas galveni.
Lai cik vienkārÅ”i bÅ«tu HTTP plÅ«du uzbrukumi, tiem ir arÄ« savi trÅ«kumi. Pirmkārt, slodzes izveidoÅ”anai ir nepiecieÅ”ams liels jaudas daudzums. Otrkārt, Ŕādus uzbrukumus ir ļoti viegli atklāt, it Ä«paÅ”i, ja tie nāk no vienas adreses. Tā rezultātā pieprasÄ«jumus nekavējoties sāk filtrēt vai nu sistēmas administratori, vai pat pakalpojumu sniedzēja lÄ«menÄ«.

Ko meklēt

Lai samazinātu pieprasÄ«jumu skaitu sekundē, nezaudējot efektivitāti, jums ir jāparāda nedaudz iztēles un jāizpēta vietne. Tādējādi jÅ«s varat ielādēt ne tikai kanālu vai serveri, bet arÄ« atseviŔķas lietojumprogrammas daļas, piemēram, datu bāzes vai failu sistēmas. Vietnē varat arÄ« meklēt vietas, kurās tiek veikti lieli aprēķini: kalkulatori, preču izvēles lapas utt. Visbeidzot, bieži gadās, ka vietnē ir kaut kāds PHP skripts, kas Ä£enerē vairākus simtus tÅ«kstoÅ”u rindiņu lapu. Šāds skripts arÄ« ievērojami noslogo serveri un var kļūt par uzbrukuma mērÄ·i.

Kur meklēt

Kad mēs skenējam resursu pirms testÄ“Å”anas, mēs, protams, vispirms skatāmies uz paÅ”u vietni. Mēs meklējam visa veida ievades laukus, smagus failus - kopumā visu, kas var radÄ«t problēmas resursam un palēnināt tā darbÄ«bu. Å eit palÄ«dz banāli Google Chrome un Firefox izstrādes rÄ«ki, kas rāda lapas atbildes laikus.
Mēs arÄ« skenējam apakÅ”domēnus. Piemēram, ir noteikts tieÅ”saistes veikals abc.com, un tam ir apakÅ”domēns admin.abc.com. Visticamāk, tas ir administratora panelis ar autorizāciju, taču, ja to noslogojat, tas var radÄ«t problēmas galvenajam resursam.
Vietnei var bÅ«t apakÅ”domēns api.abc.com. Visticamāk, tas ir resurss mobilajām lietojumprogrammām. Lietojumprogrammu var atrast App Store vai Google Play, instalēt Ä«paÅ”u piekļuves punktu, izjaukt API un reÄ£istrēt testa kontus. Problēma ir tā, ka cilvēki bieži domā, ka viss, kas ir aizsargāts ar autorizāciju, ir imÅ«ns pret pakalpojumu atteikuma uzbrukumiem. Domājams, ka autorizācija ir labākā CAPTCHA, bet tā nav. Ir viegli izveidot 10ā€“20 testa kontus, taču, tos izveidojot, mēs iegÅ«stam piekļuvi sarežģītai un neslēptai funkcionalitātei.
Protams, mēs aplÅ«kojam vēsturi, robots.txt un WebArchive, ViewDNS un meklējam resursa vecās versijas. Dažreiz gadās, ka izstrādātāji ir izlaiduÅ”i, teiksim, mail2.yandex.net, bet vecā versija, mail.yandex.net, paliek. Å is mail.yandex.net vairs netiek atbalstÄ«ts, tam netiek pieŔķirti izstrādes resursi, taču tas turpina patērēt datu bāzi. AttiecÄ«gi, izmantojot veco versiju, jÅ«s varat efektÄ«vi izmantot aizmugursistēmas resursus un visu, kas atrodas aiz izkārtojuma. Protams, tas ne vienmēr notiek, bet mēs joprojām ar to sastopamies diezgan bieži.
Protams, mēs analizējam visus pieprasÄ«juma parametrus un sÄ«kfailu struktÅ«ru. Varat, piemēram, sÄ«kfailā ievietot kādu vērtÄ«bu JSON masÄ«vā, izveidot daudz ligzdoÅ”anas un likt resursam darboties nepamatoti ilgu laiku.

MeklēŔanas slodze

Pirmā lieta, kas nāk prātā, pētot vietni, ir ielādēt datu bāzi, jo gandrÄ«z ikvienam ir meklÄ“Å”ana, un gandrÄ«z ikvienam tā diemžēl ir slikti aizsargāta. Kādu iemeslu dēļ izstrādātāji nepievērÅ” pietiekamu uzmanÄ«bu meklÄ“Å”anai. Bet Å”eit ir viens ieteikums - jums nevajadzētu veikt viena veida pieprasÄ«jumus, jo jÅ«s varat saskarties ar keÅ”atmiņu, kā tas ir HTTP flood gadÄ«jumā.
ArÄ« izlases veida vaicājumu veikÅ”ana datu bāzē ne vienmēr ir efektÄ«va. Daudz labāk ir izveidot meklÄ“Å”anai atbilstoÅ”u atslēgvārdu sarakstu. Ja atgriežamies pie tieÅ”saistes veikala piemēra: pieņemsim, ka vietne pārdod automaŔīnu riepas un ļauj iestatÄ«t riepu rādiusu, automaŔīnas veidu un citus parametrus. AttiecÄ«gi atbilstoÅ”o vārdu kombinācijas piespiedÄ«s datubāzi strādāt daudz sarežģītākos apstākļos.
Turklāt ir vērts izmantot lappusi: meklÄ“Å”anai ir daudz grÅ«tāk atgriezt meklÄ“Å”anas rezultātu priekÅ”pēdējo lapu nekā pirmo. Tas ir, ar lappuÅ”u palÄ«dzÄ«bu jÅ«s varat nedaudz dažādot slodzi.
Tālāk esoÅ”ajā piemērā ir parādÄ«ta meklÄ“Å”anas slodze. Redzams, ka jau no pirmās testa sekundes ar ātrumu desmit pieprasÄ«jumi sekundē vietne nokrita un nereaģēja.

DDoS palīgā: kā mēs veicam stresa un slodzes testus

Ja nav meklēŔanas?

Ja nav meklÄ“Å”anas, tas nenozÄ«mē, ka vietnē nav citu neaizsargātu ievades lauku. Å is lauks var bÅ«t autorizācija. MÅ«sdienās izstrādātājiem patÄ«k izveidot sarežģītus jaucējus, lai aizsargātu pieteikÅ”anās datu bāzi no varavÄ«ksnes tabulas uzbrukumiem. Tas ir labi, taču Ŕādas hashes patērē daudz CPU resursu. Liela viltus atļauju plÅ«sma izraisa procesora kļūmi, kā rezultātā vietne pārstāj darboties.
Visu veidu komentāru un atsauksmju veidlapu klātbÅ«tne vietnē ir iemesls, lai tur nosÅ«tÄ«tu ļoti lielus tekstus vai vienkārÅ”i radÄ«tu milzÄ«gus plÅ«dus. Dažreiz vietnes pieņem pievienotos failus, tostarp gzip formātā. Å ajā gadÄ«jumā mēs paņemam 1 TB failu, saspiežam to lÄ«dz vairākiem baitiem vai kilobaitiem, izmantojot gzip, un nosÅ«tām uz vietni. Pēc tam to izvelk un iegÅ«st ļoti interesantu efektu.

Atpūtas API

Es vēlētos pievērst nelielu uzmanÄ«bu tādiem populāriem pakalpojumiem kā Rest API. AtpÅ«tas API nodroÅ”ināŔana ir daudz grÅ«tāka nekā parasta vietne. Pat triviālas metodes aizsardzÄ«bai pret paroles brutālu spēku un citām nelikumÄ«gām darbÄ«bām nedarbojas Rest API.
Rest API ir ļoti viegli uzlauzt, jo tā tieÅ”i piekļūst datu bāzei. Tajā paŔā laikā Ŕāda pakalpojuma neveiksme rada diezgan nopietnas sekas uzņēmējdarbÄ«bai. Fakts ir tāds, ka Rest API parasti izmanto ne tikai galvenajai vietnei, bet arÄ« mobilajai lietojumprogrammai un dažiem iekŔējiem biznesa resursiem. Un, ja tas viss nokrÄ«t, tad efekts ir daudz spēcÄ«gāks nekā vienkārÅ”as vietnes kļūmes gadÄ«jumā.

Notiek smaga satura ielāde

Ja mums piedāvā testēt kādu parastu vienas lapas aplikāciju, galveno lapu vai vizÄ«tkarÅ”u vietni, kurai nav sarežģītas funkcionalitātes, mēs meklējam smagu saturu. Piemēram, lieli attēli, kurus serveris sÅ«ta, binārie faili, pdf dokumentācija - mēs cenÅ”amies to visu lejupielādēt. Šādi testi labi ielādē failu sistēmu un aizsprosto kanālus, tāpēc tie ir efektÄ«vi. Tas ir, pat ja jÅ«s nenoliekat serveri, lejupielādējot lielu failu ar mazu ātrumu, jÅ«s vienkārÅ”i aizsērēsit mērÄ·a servera kanālu un pēc tam notiks pakalpojuma atteikums.
Šādas pārbaudes piemērs parāda, ka ar ātrumu 30 RPS vietne pārstāja reaģēt vai radÄ«ja 500. servera kļūdas.

DDoS palīgā: kā mēs veicam stresa un slodzes testus

Neaizmirstiet par serveru iestatÄ«Å”anu. Bieži var konstatēt, ka cilvēks nopirka virtuālo maŔīnu, instalēja tur Apache, pēc noklusējuma visu konfigurēja, instalēja PHP aplikāciju un zemāk var redzēt rezultātu.

DDoS palīgā: kā mēs veicam stresa un slodzes testus

Å eit slodze devās uz sakni un sasniedza tikai 10 RPS. Mēs gaidÄ«jām 5 minÅ«tes un serveris avarēja. Tiesa, lÄ«dz galam nav zināms, kāpēc viņŔ krita, taču pastāv pieņēmums, ka viņam vienkārÅ”i bija pārāk daudz atmiņas un tāpēc viņŔ pārstāja reaģēt.

Uz viļņiem balstīta

Pēdējā gada vai divu laikā viļņu uzbrukumi ir kļuvuÅ”i diezgan populāri. Tas ir saistÄ«ts ar faktu, ka daudzas organizācijas pērk noteiktas aparatÅ«ras daļas DDoS aizsardzÄ«bai, kurām ir nepiecieÅ”ams noteikts laiks, lai uzkrātu statistiku, lai sāktu filtrēt uzbrukumu. Tas ir, viņi nefiltrē uzbrukumu pirmajās 30-40 sekundēs, jo viņi uzkrāj datus un mācās. AttiecÄ«gi Å”ajās 30ā€“40 sekundēs vietnē varat palaist tik daudz, ka resurss ilgi gulēs, lÄ«dz visi pieprasÄ«jumi tiks notÄ«rÄ«ti.
Zemāk redzamā uzbrukuma gadÄ«jumā bija 10 minÅ«Å”u intervāls, pēc kura pienāca jauna, modificēta uzbrukuma daļa.

DDoS palīgā: kā mēs veicam stresa un slodzes testus

Tas ir, aizsardzÄ«ba mācÄ«jās, sāka filtrēt, bet nāca jauna, pavisam cita uzbrukuma daļa, un aizsardzÄ«ba sāka mācÄ«ties no jauna. Faktiski filtrÄ“Å”ana pārstāj darboties, aizsardzÄ«ba kļūst neefektÄ«va un vietne nav pieejama.
Viļņu uzbrukumiem ir raksturÄ«gas ļoti augstas vērtÄ«bas maksimumā, tas var sasniegt simts tÅ«kstoÅ”us vai miljonu pieprasÄ«jumu sekundē L7 gadÄ«jumā. Ja runājam par L3&4, tad trafika var bÅ«t simtiem gigabitu vai attiecÄ«gi simtiem mpps, ja skaita paketēs.
Problēma ar Ŕādiem uzbrukumiem ir sinhronizācija. Uzbrukumi nāk no robottÄ«kla, un tiem ir nepiecieÅ”ama augsta sinhronizācijas pakāpe, lai izveidotu ļoti lielu vienreizēju smaili. Un Ŕī koordinācija ne vienmēr izdodas: dažreiz iznākums ir kaut kāds parabolisks maksimums, kas izskatās diezgan nožēlojami.

Ne tikai HTTP

Papildus HTTP pie L7 mums patÄ«k izmantot citus protokolus. Parasti parastai vietnei, Ä«paÅ”i parastai mitināŔanai, ir pasta protokoli un MySQL izceļas. Pasta protokoli ir pakļauti mazākai slodzei nekā datubāzes, taču tos var arÄ« ielādēt diezgan efektÄ«vi un rezultātā servera centrālais procesors ir pārslogots.
Mēs diezgan veiksmÄ«gi izmantojām 2016. gada SSH ievainojamÄ«bu. Tagad Ŕī ievainojamÄ«ba ir novērsta gandrÄ«z visiem, taču tas nenozÄ«mē, ka ielādi nevar iesniegt SSH. Var. VienkārÅ”i ir milzÄ«ga autorizāciju slodze, SSH apēd gandrÄ«z visu CPU serverÄ«, un tad vietne sabrÅ«k no viena vai diviem pieprasÄ«jumiem sekundē. AttiecÄ«gi Å”os vienu vai divus pieprasÄ«jumus, kuru pamatā ir žurnāli, nevar atŔķirt no likumÄ«gas slodzes.
ArÄ« daudzi savienojumi, ko atveram serveros, joprojām ir aktuāli. IepriekÅ” Apache bija vainÄ«gs pie tā, tagad nginx faktiski cieÅ” no tā, jo tas bieži tiek konfigurēts pēc noklusējuma. Savienojumu skaits, ko nginx var paturēt atvērtus, ir ierobežots, tāpēc mēs atveram Ŕādu savienojumu skaitu, nginx vairs nepieņem jaunu savienojumu, un rezultātā vietne nedarbojas.
MÅ«su testa klasterim ir pietiekami daudz CPU, lai uzbruktu SSL rokasspiedienam. Principā, kā liecina prakse, dažreiz robottÄ«kliem arÄ« patÄ«k to darÄ«t. No vienas puses, ir skaidrs, ka bez SSL neiztikt, jo Google rezultāti, rangs, droŔība. No otras puses, SSL diemžēl ir CPU problēma.

L3&4

Kad mēs runājam par uzbrukumu L3 un 4 lÄ«menÄ«, mēs parasti runājam par uzbrukumu saites lÄ«menÄ«. Šāda slodze gandrÄ«z vienmēr ir atŔķirama no likumÄ«gas, ja vien tas nav SYN plÅ«du uzbrukums. Problēma ar SYN plÅ«du uzbrukumiem droŔības rÄ«kiem ir to lielais apjoms. Maksimālā L3&4 vērtÄ«ba bija 1,5-2 Tbit/s. Šāda veida trafiku ir ļoti grÅ«ti apstrādāt pat lieliem uzņēmumiem, tostarp Oracle un Google.
SYN un SYN-ACK ir paketes, kas tiek izmantotas savienojuma izveidei. Tāpēc SYN-plÅ«dus ir grÅ«ti atŔķirt no likumÄ«gas slodzes: nav skaidrs, vai tas ir SYN, kas nāca, lai izveidotu savienojumu, vai plÅ«du daļa.

UDP plūdi

Parasti uzbrucējiem nav tādu iespēju, kādas ir mums, tāpēc uzbrukumu organizÄ“Å”anai var izmantot pastiprinājumu. Tas ir, uzbrucējs skenē internetu un atrod vai nu neaizsargātus, vai nepareizi konfigurētus serverus, kas, piemēram, reaģējot uz vienu SYN paketi, atbild ar trim SYN-ACK. Izkrāpjot avota adresi no mērÄ·a servera adreses, ir iespējams palielināt jaudu, piemēram, trÄ«s reizes ar vienu paketi un novirzÄ«t trafiku uz upuri.

DDoS palīgā: kā mēs veicam stresa un slodzes testus

Problēma ar pastiprinājumiem ir tā, ka tos ir grÅ«ti noteikt. Nesenie piemēri ietver sensacionālo gadÄ«jumu ar ievainojamo atmiņu. Turklāt tagad ir ļoti daudz IoT ierīču, IP kameru, kuras arÄ« lielākoties ir konfigurētas pēc noklusējuma, un pēc noklusējuma tās ir konfigurētas nepareizi, tāpēc uzbrucēji visbiežāk veic uzbrukumus caur Ŕādām ierÄ«cēm.

DDoS palīgā: kā mēs veicam stresa un slodzes testus

Grūti SYN-plūdi

SYN-plÅ«di, iespējams, ir visinteresantākais uzbrukuma veids no izstrādātāja viedokļa. Problēma ir tā, ka sistēmas administratori aizsardzÄ«bai bieži izmanto IP bloÄ·Ä“Å”anu. Turklāt IP bloÄ·Ä“Å”ana skar ne tikai sistēmu administratorus, kuri darbojas, izmantojot skriptus, bet diemžēl arÄ« dažas droŔības sistēmas, kas tiek iegādātas par lielu naudu.
Å Ä« metode var pārvērsties par katastrofu, jo, ja uzbrucēji nomainÄ«s IP adreses, uzņēmums bloķēs savu apakÅ”tÄ«klu. Kad ugunsmÅ«ris bloķē savu klasteru, izvade neizdosies ārējā mijiedarbÄ«bā un resurss neizdosies.
Turklāt nav grÅ«ti bloķēt savu tÄ«klu. Ja klienta birojā ir Wi-Fi tÄ«kls vai ja resursu veiktspēja tiek mērÄ«ta, izmantojot dažādas uzraudzÄ«bas sistēmas, tad mēs ņemam Ŕīs uzraudzÄ«bas sistēmas IP adresi vai klienta biroja Wi-Fi un izmantojam to kā avotu. Beigās Ŕķiet, ka resurss ir pieejams, taču mērÄ·a IP adreses ir bloķētas. Tādējādi var tikt bloķēts HighLoad konferences Wi-Fi tÄ«kls, kurā tiek prezentēts uzņēmuma jaunais produkts, un tas rada zināmas biznesa un ekonomiskās izmaksas.
Pārbaudes laikā mēs nevaram izmantot pastiprinājumu, izmantojot memcached ar ārējiem resursiem, jo ā€‹ā€‹ir lÄ«gumi sÅ«tÄ«t trafiku tikai uz atļautajām IP adresēm. AttiecÄ«gi mēs izmantojam pastiprināŔanu caur SYN un SYN-ACK, kad sistēma uz viena SYN nosÅ«tÄ«Å”anu reaģē ar diviem vai trim SYN-ACK, un izejā uzbrukums tiek reizināts ar divām vai trÄ«s reizēm.

Darbarīki

Viens no galvenajiem rÄ«kiem, ko izmantojam L7 darba slodzei, ir Yandex-tank. Jo Ä«paÅ”i fantoms tiek izmantots kā ierocis, kā arÄ« ir vairāki skripti patronu Ä£enerÄ“Å”anai un rezultātu analÄ«zei.
Tcpdump tiek izmantots, lai analizētu tÄ«kla trafiku, un Nmap tiek izmantots servera analÄ«zei. Lai izveidotu slodzi L3 un 4 lÄ«menÄ«, tiek izmantots OpenSSL un nedaudz mÅ«su paÅ”u burvju ar DPDK bibliotēku. DPDK ir Intel bibliotēka, kas ļauj strādāt ar tÄ«kla interfeisu, apejot Linux steku, tādējādi palielinot efektivitāti. Dabiski, ka DPDK izmantojam ne tikai L3&4, bet arÄ« L7 lÄ«menÄ«, jo tas ļauj izveidot ļoti augstu slodzes plÅ«smu, vairāku miljonu pieprasÄ«jumu diapazonā sekundē no vienas maŔīnas.
Mēs izmantojam arÄ« noteiktus trafika Ä£eneratorus un Ä«paÅ”us rÄ«kus, ko rakstām konkrētiem testiem. Ja atceramies SSH ievainojamÄ«bu, iepriekÅ” minēto kopu nevar izmantot. Ja mēs uzbrÅ«kam pasta protokolam, mēs izmantojam pasta utilÄ«tus vai vienkārÅ”i rakstām uz tiem skriptus.

Atzinumi

Nobeigumā es gribētu teikt:

  • Papildus klasiskajai slodzes pārbaudei ir nepiecieÅ”ams veikt stresa testÄ“Å”anu. Mums ir reāls piemērs, kur partnera apakÅ”uzņēmējs veica tikai slodzes testÄ“Å”anu. Tas parādÄ«ja, ka resurss var izturēt normālu slodzi. Bet tad parādÄ«jās nenormāla slodze, vietnes apmeklētāji sāka izmantot resursu nedaudz savādāk, un rezultātā apakÅ”uzņēmējs apgÅ«lās. Tādējādi ir vērts meklēt ievainojamÄ«bas pat tad, ja esat jau aizsargāts pret DDoS uzbrukumiem.
  • Ir nepiecieÅ”ams izolēt dažas sistēmas daļas no citām. Ja jums ir meklÄ“Å”ana, jums tas ir jāpārvieto uz atseviŔķām maŔīnām, tas ir, pat ne uz Docker. Jo, ja meklÄ“Å”ana vai autorizācija neizdodas, vismaz kaut kas turpinās darboties. TieÅ”saistes veikala gadÄ«jumā lietotāji turpinās atrast produktus katalogā, pāriet no apkopotāja, iegādāsies, ja tie jau ir pilnvaroti, vai autorizēs, izmantojot OAuth2.
  • Nepalaidiet uzmanÄ«bu visu veidu mākoņpakalpojumiem.
  • Izmantojiet CDN ne tikai, lai optimizētu tÄ«kla aizkaves, bet arÄ« kā lÄ«dzekli aizsardzÄ«bai pret uzbrukumiem kanāla izsmelÅ”anai un vienkārÅ”i iepludināŔanai statiskā trafikā.
  • NepiecieÅ”ams izmantot specializētus aizsardzÄ«bas dienestus. JÅ«s nevarat pasargāt sevi no L3&4 uzbrukumiem kanālu lÄ«menÄ«, jo, visticamāk, jums vienkārÅ”i nav pietiekama kanāla. Maz ticams, ka jÅ«s arÄ« cÄ«nÄ«sities pret L7 uzbrukumiem, jo ā€‹ā€‹tie var bÅ«t ļoti lieli. Turklāt mazu uzbrukumu meklÄ“Å”ana joprojām ir speciālo dienestu, Ä«paÅ”u algoritmu prerogatÄ«va.
  • Regulāri atjauniniet. Tas attiecas ne tikai uz kodolu, bet arÄ« uz SSH dēmonu, it Ä«paÅ”i, ja tie ir atvērti ārpusei. Principā viss ir jāatjaunina, jo maz ticams, ka jÅ«s pats spēsiet izsekot noteiktām ievainojamÄ«bām.

Avots: www.habr.com

Pievieno komentāru