Variti kuria apsaugą nuo robotų ir DDoS atakų, taip pat atlieka streso ir apkrovos testavimą. HighLoad++ 2018 konferencijoje kalbėjome apie tai, kaip apsaugoti išteklius nuo įvairių tipų atakų. Trumpai tariant: izoliuokite sistemos dalis, naudokite debesies paslaugas ir CDN ir reguliariai atnaujinkite. Tačiau be specializuotų įmonių vis tiek neapsieisite su apsauga :)
Prieš skaitydami tekstą, galite perskaityti trumpas santraukas .
O jei nemėgstate skaityti ar tiesiog norite žiūrėti vaizdo įrašą, mūsų reportažo įrašas yra žemiau po spoileriu.
Pranešimo vaizdo įrašas
Daugelis įmonių jau žino, kaip atlikti apkrovos testavimą, tačiau ne visos atlieka testavimą nepalankiausiomis sąlygomis. Kai kurie mūsų klientai mano, kad jų svetainė yra nepažeidžiama, nes jie turi didelės apkrovos sistemą ir gerai apsaugo nuo atakų. Mes parodome, kad tai nėra visiškai tiesa.
Žinoma, prieš atlikdami testus gauname kliento leidimą, pasirašytą ir antspauduotą, o su mūsų pagalba DDoS ataka negali būti įvykdyta prieš nieką. Testavimas atliekamas kliento pasirinktu laiku, kai srautas į jo išteklius yra minimalus, o prieigos problemos neturės įtakos klientams. Be to, kadangi testavimo metu visada kažkas gali nepavykti, su klientu palaikome nuolatinį ryšį. Tai leidžia ne tik pranešti apie pasiektus rezultatus, bet ir ką nors pakeisti testavimo metu. Baigę testavimą visada surašome ataskaitą, kurioje nurodome aptiktus trūkumus ir pateikiame rekomendacijas, kaip pašalinti svetainės trūkumus.
Kaip mes dirbame
Bandydami imituojame robotų tinklą. Kadangi dirbame su klientais, kurie nėra mūsų tinkluose, todėl norėdami, kad testas nesibaigtų pirmą minutę dėl limitų ar suveikiančios apsaugos, apkrovą tiekiame ne iš vieno IP, o iš savo potinklio. Be to, norėdami sukurti didelę apkrovą, turime savo gana galingą bandomąjį serverį.
Postulatai
Per daug nereiškia gerai
Kuo mažiau apkrovos galime sugadinti išteklius, tuo geriau. Jei galite priversti svetainę nustoti veikti pateikę vieną užklausą per sekundę arba net vieną užklausą per minutę, puiku. Nes pagal niekšybės dėsnį vartotojai ar užpuolikai netyčia pateks į šį pažeidžiamumą.
Dalinė nesėkmė yra geriau nei visiška nesėkmė
Visada patariame sistemas padaryti nevienalytes. Be to, verta juos atskirti fiziniu lygmeniu, o ne tik konteinerizuojant. Fizinio atskyrimo atveju, net jei svetainėje kažkas nepavyks, yra didelė tikimybė, kad ji visiškai nenustos veikti, o vartotojai ir toliau turės prieigą prie bent dalies funkcijų.
Gera architektūra yra tvarumo pagrindas
Ištekliaus atsparumas gedimams ir jo gebėjimas atlaikyti atakas ir apkrovas turėtų būti nustatytas projektavimo etape, iš tikrųjų – pirmųjų struktūrinių schemų piešimo bloknote etape. Nes jei užklumpa lemtingos klaidos, jas ateityje galima ištaisyti, bet tai labai sunku.
Ne tik kodas turi būti geras, bet ir konfigūracija
Daugelis žmonių mano, kad gera kūrėjų komanda yra gedimams atsparaus aptarnavimo garantas. Gera kūrėjų komanda tikrai reikalinga, bet turi būti ir geros operacijos, geri DevOps. Tai yra, mums reikia specialistų, kurie teisingai sukonfigūruos „Linux“ ir tinklą, teisingai parašys konfigūracijas „nginx“, nustatys apribojimus ir pan. Priešingu atveju išteklius gerai veiks tik testuojant, o gamyboje tam tikru momentu viskas suges.
Skirtumai tarp apkrovos ir testavimo nepalankiausiomis sąlygomis
Apkrovos testavimas leidžia nustatyti sistemos veikimo ribas. Testavimas nepalankiausiomis sąlygomis yra skirtas rasti sistemos silpnybes ir yra naudojamas sulaužyti šią sistemą ir pamatyti, kaip ji elgsis sugedus tam tikroms dalims. Tokiu atveju apkrovos pobūdis paprastai lieka nežinomas klientui prieš pradedant testavimą nepalankiausiomis sąlygomis.
Išskirtiniai L7 atakų bruožai
Paprastai krovinių tipus skirstome į L7 ir L3&4 lygius. L7 yra apkrova programos lygiu, dažniausiai tai reiškia tik HTTP, bet mes turime omenyje bet kokią apkrovą TCP protokolo lygiu.
L7 atakos turi tam tikrų išskirtinių bruožų. Pirma, jie patenka tiesiai į programą, tai yra, mažai tikėtina, kad jie bus atspindėti tinklo priemonėmis. Tokios atakos naudoja logiką ir dėl to labai efektyviai ir su nedideliu srautu sunaudoja procesorių, atmintį, diską, duomenų bazę ir kitus resursus.
HTTP potvynis
Bet kokios atakos atveju apkrovą sukurti lengviau nei valdyti, o L7 atveju tai taip pat tiesa. Ne visada lengva atskirti atakų srautą nuo teisėto srauto ir dažniausiai tai galima padaryti pagal dažnumą, tačiau jei viskas suplanuota teisingai, tada iš žurnalų neįmanoma suprasti, kur yra ataka ir kur yra teisėti užklausos.
Kaip pirmąjį pavyzdį apsvarstykite HTTP užtvindymo ataką. Grafike matyti, kad tokios atakos dažniausiai būna labai galingos, žemiau pateiktame pavyzdyje didžiausias užklausų skaičius viršijo 600 tūkst. per minutę.
HTTP Flood yra lengviausias būdas sukurti apkrovą. Paprastai reikia tam tikro apkrovos testavimo įrankio, pvz., ApacheBench, ir nustato užklausą bei tikslą. Taikant tokį paprastą metodą, yra didelė tikimybė patekti į serverio talpyklą, tačiau ją lengva apeiti. Pavyzdžiui, prie užklausos pridėjus atsitiktines eilutes, kurios privers serverį nuolat teikti naują puslapį.
Be to, kurdami apkrovą, nepamirškite apie vartotojo agentą. Daugelį populiarių testavimo įrankių vartotojų agentų filtruoja sistemos administratoriai, ir tokiu atveju apkrova gali tiesiog nepasiekti backend. Galite žymiai pagerinti rezultatą, į užklausą įterpę daugiau ar mažiau galiojančią naršyklės antraštę.
Kad ir kokios paprastos būtų HTTP Flood atakos, jos turi ir trūkumų. Pirma, norint sukurti apkrovą, reikia daug energijos. Antra, tokias atakas labai lengva aptikti, ypač jei jos ateina iš vieno adreso. Dėl to užklausas iš karto pradeda filtruoti sistemos administratoriai arba net teikėjo lygiu.
Ko ieškoti
Norėdami sumažinti užklausų skaičių per sekundę neprarandant efektyvumo, turite parodyti šiek tiek vaizduotės ir ištirti svetainę. Taigi galite įkelti ne tik kanalą ar serverį, bet ir atskiras programos dalis, pavyzdžiui, duomenų bazes ar failų sistemas. Taip pat svetainėje galite ieškoti vietų, kuriose atliekami dideli skaičiavimai: skaičiuotuvai, prekių pasirinkimo puslapiai ir kt. Galiausiai dažnai atsitinka taip, kad svetainė turi kažkokį PHP scenarijų, kuris sugeneruoja kelių šimtų tūkstančių eilučių puslapį. Toks scenarijus taip pat gerokai apkrauna serverį ir gali tapti atakos taikiniu.
Kur ieškoti
Kai prieš testavimą nuskaitome išteklius, pirmiausia, žinoma, žiūrime į pačią svetainę. Ieškome visų rūšių įvesties laukų, sunkių failų – apskritai visko, kas gali sukelti problemų ištekliui ir sulėtinti jo veikimą. Čia padeda banalūs Google Chrome ir Firefox kūrimo įrankiai, rodantys puslapio atsako laiką.
Taip pat nuskaitome subdomenus. Pavyzdžiui, yra tam tikra internetinė parduotuvė abc.com ir jos padomenis admin.abc.com. Greičiausiai tai yra administratoriaus skydelis su įgaliojimu, tačiau jei jį apkrausite, tai gali sukelti problemų pagrindiniam šaltiniui.
Svetainėje gali būti api.abc.com padomenis. Labiausiai tikėtina, kad tai yra mobiliųjų programų šaltinis. Programą galite rasti „App Store“ arba „Google Play“, įdiegti specialų prieigos tašką, išardyti API ir užregistruoti bandomąsias paskyras. Problema ta, kad žmonės dažnai mano, kad viskas, kas yra apsaugota autorizacija, yra apsaugota nuo paslaugų atsisakymo atakų. Manoma, kad autorizacija yra geriausia CAPTCHA, bet taip nėra. Nesunku sukurti 10–20 bandomųjų paskyrų, tačiau jas sukūrę gauname prieigą prie sudėtingų ir neslepiamų funkcijų.
Natūralu, kad žiūrime į istoriją, robots.txt ir WebArchive, ViewDNS ir ieškome senų šaltinio versijų. Kartais nutinka taip, kad kūrėjai išleido, tarkime, mail2.yandex.net, tačiau senoji versija mail.yandex.net išlieka. Šis mail.yandex.net nebepalaikomas, kūrimo resursai jam neskiriami, tačiau jis ir toliau naudoja duomenų bazę. Atitinkamai, naudodamiesi senąja versija, galite efektyviai naudoti užpakalinės programos išteklius ir viską, kas yra už išdėstymo. Žinoma, taip nutinka ne visada, bet vis tiek su tuo susiduriame gana dažnai.
Natūralu, kad analizuojame visus užklausos parametrus ir slapukų struktūrą. Galite, tarkime, įdėti tam tikrą vertę į JSON masyvą slapuko viduje, sukurti daug įdėjimo ir priversti išteklius veikti nepagrįstai ilgai.
Paieškos apkrova
Pirmas dalykas, kuris ateina į galvą tiriant svetainę, yra įkelti duomenų bazę, nes beveik visi atlieka paiešką, o beveik visiems ji, deja, yra prastai apsaugota. Kažkodėl kūrėjai neskiria pakankamai dėmesio paieškai. Tačiau čia yra viena rekomendacija - neturėtumėte teikti to paties tipo užklausų, nes galite susidurti su talpyklos kaupimu, kaip yra HTTP užtvindymo atveju.
Atsitiktinių užklausų pateikimas duomenų bazėje taip pat ne visada efektyvus. Daug geriau sudaryti raktinių žodžių, susijusių su paieška, sąrašą. Jei grįšime prie internetinės parduotuvės pavyzdžio: tarkime, kad svetainė parduoda automobilių padangas ir leidžia nustatyti padangų spindulį, automobilio tipą ir kitus parametrus. Atitinkamai, atitinkamų žodžių deriniai privers duomenų bazę dirbti daug sudėtingesnėmis sąlygomis.
Be to, verta naudoti puslapių žymėjimą: paieškoje daug sunkiau grąžinti priešpaskutinį paieškos rezultatų puslapį nei pirmąjį. Tai yra, puslapių numeravimo pagalba galite šiek tiek paįvairinti apkrovą.
Toliau pateiktame pavyzdyje parodyta paieškos apkrova. Matyti, kad nuo pat pirmos testo sekundės dešimties užklausų per sekundę greičiu svetainė sunyko ir nereagavo.
Jei nėra paieškos?
Jei nėra paieškos, tai nereiškia, kad svetainėje nėra kitų pažeidžiamų įvesties laukų. Šis laukas gali būti įgaliotas. Šiais laikais kūrėjai mėgsta kurti sudėtingas maišas, kad apsaugotų prisijungimo duomenų bazę nuo vaivorykštės lentelės atakų. Tai gerai, bet tokios maišos sunaudoja daug procesoriaus resursų. Didelis klaidingų leidimų srautas sukelia procesoriaus gedimą, todėl svetainė nustoja veikti.
Visų rūšių komentarų ir atsiliepimų formų buvimas svetainėje yra priežastis ten siųsti labai didelius tekstus arba tiesiog sukelti didžiulį potvynį. Kartais svetainės priima pridėtus failus, įskaitant gzip formatą. Tokiu atveju paimame 1 TB failą, suspaudžiame jį iki kelių baitų arba kilobaitų naudodami gzip ir išsiunčiame į svetainę. Tada jis atsegamas ir gaunamas labai įdomus efektas.
Poilsio API
Norėčiau šiek tiek atkreipti dėmesį į tokias populiarias paslaugas kaip „Rest API“. Apsaugoti „Rest“ API yra daug sunkiau nei įprastą svetainę. Net trivialūs apsaugos nuo slaptažodžio brutalios jėgos ir kitos neteisėtos veiklos metodai neveikia Rest API.
„Rest“ API labai lengva sulaužyti, nes ji tiesiogiai pasiekia duomenų bazę. Tuo pačiu metu tokios paslaugos gedimas verslui sukelia gana rimtų pasekmių. Faktas yra tas, kad „Rest“ API dažniausiai naudojama ne tik pagrindinei svetainei, bet ir mobiliajai programai bei kai kuriems vidiniams verslo ištekliams. Ir jei visa tai nukrenta, tada poveikis yra daug stipresnis nei paprasto svetainės gedimo atveju.
Įkeliamas sunkus turinys
Jei mums siūloma išbandyti įprastą vieno puslapio aplikaciją, nukreipimo puslapį ar vizitinės kortelės svetainę, kuri neturi sudėtingų funkcijų, ieškome sunkaus turinio. Pavyzdžiui, dideli paveikslėliai, kuriuos siunčia serveris, dvejetainiai failai, pdf dokumentacija – visa tai bandome parsisiųsti. Tokie testai gerai įkelia failų sistemą ir užkemša kanalus, todėl yra veiksmingi. Tai yra, net jei nenustatote serverio, mažu greičiu atsisiųsdami didelį failą, tiesiog užkimšite tikslinio serverio kanalą ir tada atsiras paslaugos atsisakymas.
Tokio testo pavyzdys rodo, kad esant 30 RPS greičiui, svetainė nustojo reaguoti arba sukėlė 500 serverio klaidų.
Nepamirškite apie serverių nustatymą. Dažnai galima pastebėti, kad žmogus nusipirko virtualią mašiną, ten įsidiegė Apache, viską sukonfigūravo pagal nutylėjimą, įdiegė PHP aplikaciją ir žemiau matosi rezultatas.
Čia apkrova nukeliavo į šaknį ir siekė tik 10 RPS. Laukėme 5 minutes ir serveris sudužo. Tiesa, iki galo nežinoma, kodėl jis krito, tačiau yra prielaida, kad jis tiesiog turėjo per daug atminties ir todėl nustojo reaguoti.
Bangų pagrindu
Per pastaruosius metus ar dvejus bangų atakos tapo gana populiarios. Taip yra dėl to, kad daugelis organizacijų perka tam tikras DDoS apsaugos aparatūros dalis, kurioms reikia tam tikro laiko kaupti statistinius duomenis, kad būtų galima pradėti filtruoti ataką. Tai yra, jie nefiltruoja atakos per pirmąsias 30–40 sekundžių, nes kaupia duomenis ir mokosi. Atitinkamai, per šias 30–40 sekundžių svetainėje galite paleisti tiek daug, kad ištekliai gulės ilgą laiką, kol bus išvalytos visos užklausos.
Žemiau esančios atakos atveju buvo 10 minučių intervalas, po kurio atėjo nauja, modifikuota atakos dalis.
Tai yra, gynyba išmoko, pradėjo filtruoti, bet atėjo nauja, visiškai kitokia puolimo dalis, o gynyba vėl pradėjo mokytis. Iš tikrųjų filtravimas nustoja veikti, apsauga tampa neveiksminga, o svetainė nepasiekiama.
Bangos atakoms būdingos labai didelės vertės piko metu, L7 atveju jos gali siekti šimtą tūkstančių arba milijoną užklausų per sekundę. Jei mes kalbame apie L3 ir 4, tai gali būti šimtai gigabitų srauto arba, atitinkamai, šimtai mpps, jei skaičiuojate paketais.
Tokių atakų problema yra sinchronizavimas. Atakos kyla iš botneto ir reikalauja didelio sinchronizavimo, kad būtų sukurtas labai didelis vienkartinis šuolis. Ir šis derinimas ne visada pasiteisina: kartais išėjimas yra kažkokia parabolinė smailė, kuri atrodo gana apgailėtinai.
Ne tik HTTP
Be HTTP L7, mes mėgstame išnaudoti kitus protokolus. Paprastai įprastoje svetainėje, ypač įprastoje priegloboje, yra pašto protokolai ir išryškėja MySQL. Pašto protokolai yra mažiau apkraunami nei duomenų bazės, tačiau jie taip pat gali būti įkeliami gana efektyviai ir gali būti perkrauti serverio CPU.
Mums gana sėkmingai pavyko panaudoti 2016 m. SSH pažeidžiamumą. Dabar šis pažeidžiamumas buvo ištaisytas beveik visiems, tačiau tai nereiškia, kad įkėlimas negali būti pateiktas SSH. Gali. Tiesiog yra didžiulis autorizacijų krūvis, SSH suvalgo beveik visą serveryje esantį procesorių, o tada svetainė sugenda nuo vienos ar dviejų užklausų per sekundę. Atitinkamai, šios vienos ar dviejų užklausų, pagrįstų žurnalais, negalima atskirti nuo teisėtos apkrovos.
Daugelis ryšių, kuriuos atidarome serveriuose, taip pat išlieka aktualūs. Anksčiau dėl to kaltas „Apache“, o dabar „nginx“ iš tikrųjų dėl to kaltas, nes dažnai sukonfigūruojamas pagal numatytuosius nustatymus. Ryšių, kuriuos nginx gali išlaikyti atidarytą, skaičius yra ribotas, todėl atidarome tiek jungčių, nginx nebepriima naujo ryšio, todėl svetainė neveikia.
Mūsų bandymų grupėje yra pakankamai procesoriaus, kad galėtų atakuoti SSL rankos paspaudimą. Iš esmės, kaip rodo praktika, botnetai kartais taip pat mėgsta tai daryti. Viena vertus, aišku, kad be SSL neapsieisite, nes Google rezultatai, reitingas, saugumas. Kita vertus, SSL, deja, turi procesoriaus problemą.
L3 ir 4
Kai kalbame apie ataką L3 ir 4 lygiuose, dažniausiai kalbame apie ataką nuorodos lygiu. Tokią apkrovą beveik visada galima atskirti nuo teisėtos, nebent tai būtų SYN potvynio ataka. Saugos įrankių SYN užtvindymo atakų problema yra didelė jų apimtis. Maksimali L3&4 reikšmė buvo 1,5-2 Tbit/s. Tokį srautą labai sunku apdoroti net didelėms įmonėms, įskaitant „Oracle“ ir „Google“.
SYN ir SYN-ACK yra paketai, naudojami užmezgant ryšį. Todėl SYN-potvynį sunku atskirti nuo teisėtos apkrovos: neaišku, ar tai SYN, kuris atėjo užmegzti ryšį, ar potvynio dalis.
UDP potvynis
Paprastai užpuolikai neturi tokių galimybių kaip mes, todėl stiprinimas gali būti naudojamas atakoms organizuoti. Tai yra, užpuolikas nuskaito internetą ir randa pažeidžiamus arba neteisingai sukonfigūruotus serverius, kurie, pavyzdžiui, reaguodami į vieną SYN paketą, atsako trimis SYN-ACK. Suklastojus šaltinio adresą iš tikslinio serverio adreso, vienu paketu galima padidinti galią, tarkime, tris kartus ir nukreipti srautą į auką.
Su stiprintuvais susijusi problema yra ta, kad juos sunku aptikti. Naujausi pavyzdžiai apima sensacingą pažeidžiamų asmenų atmintį. Be to, dabar yra daug IoT įrenginių, IP kamerų, kurios taip pat dažniausiai yra sukonfigūruotos pagal nutylėjimą, o pagal nutylėjimą yra sukonfigūruotos neteisingai, todėl užpuolikai dažniausiai atakas per tokius įrenginius.
Sunkus SYN potvynis
SYN-flood yra turbūt įdomiausias atakų tipas kūrėjo požiūriu. Problema ta, kad sistemos administratoriai dažnai naudoja IP blokavimą apsaugai. Be to, IP blokavimas paliečia ne tik sistemų administratorius, kurie veikia naudodami scenarijus, bet, deja, ir kai kurias apsaugos sistemas, kurios perkamos už didelius pinigus.
Šis metodas gali virsti katastrofa, nes jei užpuolikai pakeis IP adresus, įmonė blokuos savo potinklį. Kai ugniasienė blokuoja savo klasterį, išvestis nepavyks atlikti išorinės sąveikos, o išteklius nepavyks.
Be to, nėra sunku užblokuoti savo tinklą. Jei kliento biure yra Wi-Fi tinklas arba resursų našumas matuojamas naudojant įvairias stebėjimo sistemas, tai imame šios stebėjimo sistemos arba kliento biuro Wi-Fi IP adresą ir naudojame jį kaip šaltinį. Pabaigoje atrodo, kad išteklius yra, tačiau tiksliniai IP adresai yra užblokuoti. Taigi konferencijos „HighLoad“, kurioje pristatomas naujas įmonės produktas, Wi-Fi tinklas gali būti užblokuotas, o tai pareikalaus tam tikrų verslo ir ekonominių kaštų.
Testavimo metu negalime naudoti stiprinimo per atmintinę su jokiais išoriniais ištekliais, nes yra susitarimų srautą siųsti tik leistinais IP adresais. Atitinkamai, mes naudojame stiprinimą per SYN ir SYN-ACK, kai sistema reaguoja į vieno SYN siuntimą dviem ar trimis SYN-ACK, o išėjime ataka padauginama iš dviejų ar trijų kartų.
Įrankiai
Vienas iš pagrindinių įrankių, kurį naudojame L7 darbo krūviui, yra „Yandex-tank“. Visų pirma, fantomas naudojamas kaip ginklas, be to, yra keletas scenarijų, skirtų kasetėms generuoti ir rezultatams analizuoti.
Tcpdump naudojamas tinklo srautui analizuoti, o Nmap naudojamas serveriui analizuoti. Norint sukurti apkrovą L3 ir 4 lygiu, naudojamas OpenSSL ir šiek tiek mūsų pačių magijos su DPDK biblioteka. DPDK yra „Intel“ biblioteka, leidžianti dirbti su tinklo sąsaja apeinant „Linux“ krūvą ir taip padidinti efektyvumą. Natūralu, kad DPDK naudojame ne tik L3&4, bet ir L7 lygyje, nes tai leidžia sukurti labai didelį apkrovos srautą, kelių milijonų užklausų per sekundę diapazone iš vienos mašinos.
Taip pat naudojame tam tikrus srauto generatorius ir specialius įrankius, kuriuos rašome konkretiems testams. Jei prisiminsime SSH pažeidžiamumą, aukščiau pateikto rinkinio išnaudoti negalima. Jei atakuojame pašto protokolą, imamės pašto paslaugų arba tiesiog rašome ant jų scenarijus.
išvados
Baigdamas norėčiau pasakyti:
- Be klasikinio apkrovos testavimo, būtina atlikti testavimą nepalankiausiomis sąlygomis. Turime realų pavyzdį, kai partnerio subrangovas atliko tik apkrovos testavimą. Tai parodė, kad resursas gali atlaikyti įprastą apkrovą. Bet tada atsirado nenormalus krūvis, svetainės lankytojai resursą pradėjo naudoti kiek kitaip, o dėl to subrangovas atsigulė. Taigi, verta ieškoti pažeidžiamumų, net jei jau esate apsaugoti nuo DDoS atakų.
- Būtina atskirti kai kurias sistemos dalis nuo kitų. Jei turite paiešką, turite ją perkelti į atskirus įrenginius, tai yra, net ne į Docker. Nes jei nepavyks paieška ar autorizacija, bent kažkas veiks toliau. Internetinės parduotuvės atveju vartotojai ir toliau ras produktus kataloge, eis iš kaupiklio, pirks, jei jau yra įgalioti, arba autorizuos naudodami OAuth2.
- Nepamirškite visų rūšių debesies paslaugų.
- Naudokite CDN ne tik norėdami optimizuoti tinklo vėlavimus, bet ir kaip apsaugos priemonę nuo atakų dėl kanalo išeikvojimo ir tiesiog užtvindymo statiniame sraute.
- Būtina naudotis specializuotomis apsaugos paslaugomis. Negalite apsisaugoti nuo L3 ir 4 atakų kanalo lygiu, nes greičiausiai tiesiog neturite pakankamai kanalo. Taip pat mažai tikėtina, kad atsispirsite L7 atakoms, nes jos gali būti labai didelės. Be to, mažų atakų paieška vis dar yra specialiųjų tarnybų, specialių algoritmų prerogatyva.
- Reguliariai atnaujinkite. Tai taikoma ne tik branduoliui, bet ir SSH demonui, ypač jei jie yra atviri išorėje. Iš esmės viską reikia atnaujinti, nes vargu ar pavyks savarankiškai atsekti tam tikras spragas.
Šaltinis: www.habr.com