Variti kehittää suojausta botteja ja DDoS-hyökkäyksiä vastaan sekä suorittaa stressi- ja kuormitustestauksia. HighLoad++ 2018 -konferenssissa keskustelimme resurssien turvaamisesta erityyppisiltä hyökkäyksiltä. Lyhyesti: eristä järjestelmän osat, käytä pilvipalveluita ja CDN-verkkoja ja päivitä säännöllisesti. Mutta et silti selviä suojauksesta ilman erikoisyrityksiä :)
Ennen kuin luet tekstin, voit lukea lyhyet tiivistelmät .
Ja jos et halua lukea tai haluat vain katsoa videon, raporttimme tallenne on alla spoilerin alla.
Videotallenne raportista
Monet yritykset osaavat jo tehdä kuormitustestauksia, mutta kaikki eivät tee stressitestausta. Jotkut asiakkaistamme ajattelevat, että heidän sivustonsa on haavoittumaton, koska heillä on korkea kuormitusjärjestelmä ja se suojaa hyvin hyökkäyksiltä. Osoitamme, että tämä ei ole täysin totta.
Tietenkin ennen testien suorittamista hankimme asiakkaalta allekirjoitetun ja leimatun luvan, eikä meidän avullamme voida suorittaa DDoS-hyökkäystä kenellekään. Testaus suoritetaan asiakkaan valitsemana ajankohtana, jolloin liikenne hänen resurssilleen on minimaalista ja pääsyongelmat eivät vaikuta asiakkaisiin. Lisäksi, koska testauksen aikana voi aina mennä pieleen, olemme jatkuvasti yhteydessä asiakkaaseen. Näin voit paitsi raportoida saavutetut tulokset, myös muuttaa jotain testauksen aikana. Testauksen päätyttyä teemme aina raportin, jossa osoitamme havaitut puutteet ja annamme suosituksia sivuston heikkouksien poistamiseksi.
Miten toimimme
Testattaessa emuloimme bottiverkkoa. Koska työskentelemme asiakkaiden kanssa, jotka eivät sijaitse verkoissamme, jotta varmistetaan, että testi ei pääty ensimmäisellä minuutilla rajoitusten tai laukaisevan suojauksen vuoksi, emme toimita kuormaa yhdestä IP-osoitteesta, vaan omasta aliverkostamme. Lisäksi merkittävän kuormituksen luomiseksi meillä on oma melko tehokas testipalvelin.
Postulaatteja
Liika ei tarkoita hyvää
Mitä vähemmän kuormaa voimme viedä resurssin epäonnistumiseen, sitä parempi. Jos pystyt lopettamaan sivuston toiminnan yhdellä pyynnöllä sekunnissa tai jopa yhdellä pyynnöllä minuutissa, se on hienoa. Koska ilkeyden lain mukaan käyttäjät tai hyökkääjät joutuvat vahingossa tähän haavoittuvuuteen.
Osittainen epäonnistuminen on parempi kuin täydellinen epäonnistuminen
Suosittelemme aina tekemään järjestelmistä heterogeenisiä. Lisäksi ne kannattaa erottaa fyysisellä tasolla, ei vain konttien avulla. Fyysisen erottamisen tapauksessa, vaikka jokin sivustolla epäonnistuisi, on suuri todennäköisyys, että se ei lakkaa toimimasta kokonaan ja käyttäjät pääsevät edelleen käyttämään ainakin osaa toiminnoista.
Hyvä arkkitehtuuri on kestävän kehityksen perusta
Resurssin vikasietoisuus ja kyky kestää hyökkäyksiä ja kuormituksia tulisi määrittää suunnitteluvaiheessa, itse asiassa ensimmäisten vuokaavioiden piirtämisessä muistilehtiöön. Koska jos kohtalokkaita virheitä hiipii, ne on mahdollista korjata tulevaisuudessa, mutta se on erittäin vaikeaa.
Ei vain koodin pitäisi olla hyvä, vaan myös konfiguroinnin
Monien mielestä hyvä kehitystiimi on takuu vikasietoisesta palvelusta. Hyvä kehitystiimi on todella tarpeellinen, mutta pitää olla myös hyvää toimintaa, hyviä DevOppeja. Eli tarvitsemme asiantuntijoita, jotka määrittävät Linuxin ja verkon oikein, kirjoittavat asetukset oikein nginxissä, asettavat rajoituksia jne. Muuten resurssi toimii hyvin vain testauksessa, ja jossain vaiheessa kaikki hajoaa tuotannossa.
Erot kuormitus- ja stressitestauksen välillä
Kuormitustestauksen avulla voit tunnistaa järjestelmän toiminnan rajat. Stressitestauksen tarkoituksena on löytää järjestelmän heikkouksia ja sitä käytetään murtamaan tämä järjestelmä ja katsomaan, miten se käyttäytyy tiettyjen osien vikaantuessa. Tällöin kuorman luonne jää yleensä asiakkaalle tuntemattomaksi ennen rasitustestauksen alkamista.
L7-hyökkäysten erityispiirteet
Tavallisesti jaamme kuormatyypit kuormiin L7- ja L3&4-tasoilla. L7 on kuormitus sovellustasolla, useimmiten se tarkoittaa vain HTTP:tä, mutta tarkoitamme mitä tahansa kuormaa TCP-protokollatasolla.
L7-hyökkäyksillä on tiettyjä erityispiirteitä. Ensinnäkin ne tulevat suoraan sovellukseen, eli on epätodennäköistä, että ne heijastuvat verkon kautta. Tällaiset hyökkäykset käyttävät logiikkaa, ja tämän vuoksi ne kuluttavat suoritinta, muistia, levyä, tietokantaa ja muita resursseja erittäin tehokkaasti ja pienellä liikenteellä.
HTTP-tulva
Minkä tahansa hyökkäyksen tapauksessa kuorma on helpompi luoda kuin käsitellä, ja tämä pitää paikkansa myös L7:n tapauksessa. Hyökkäysliikennettä ei aina ole helppo erottaa laillisesta liikenteestä, ja useimmiten tämä voidaan tehdä taajuudella, mutta jos kaikki on suunniteltu oikein, niin lokeista on mahdotonta ymmärtää, missä hyökkäys on ja missä ovat oikeutetut pyynnöt.
Harkitse ensimmäisenä esimerkkinä HTTP Flood -hyökkäystä. Kaavio osoittaa, että tällaiset hyökkäykset ovat yleensä erittäin voimakkaita; alla olevassa esimerkissä pyyntöjen huippumäärä ylitti 600 tuhatta minuutissa.
HTTP Flood on helpoin tapa luoda kuorma. Tyypillisesti se vaatii jonkinlaisen kuormitustestaustyökalun, kuten ApacheBenchin, ja asettaa pyynnön ja tavoitteen. Tällaisella yksinkertaisella lähestymistavalla on suuri todennäköisyys törmätä palvelimen välimuistiin, mutta se on helppo ohittaa. Esimerkiksi satunnaisten merkkijonojen lisääminen pyyntöön, mikä pakottaa palvelimen jatkuvasti palvelemaan uutta sivua.
Älä myöskään unohda käyttäjäagenttia latauksen luomisen aikana. Järjestelmänvalvojat suodattavat monia suosittujen testaustyökalujen käyttäjäagentteja, ja tässä tapauksessa lataus ei välttämättä yksinkertaisesti saavuta taustajärjestelmää. Voit parantaa tulosta merkittävästi lisäämällä pyyntöön enemmän tai vähemmän kelvollisen selaimen otsikon.
Niin yksinkertaisia kuin HTTP Flood -hyökkäykset ovatkin, niillä on myös haittapuolensa. Ensinnäkin kuorman luomiseen tarvitaan suuria määriä tehoa. Toiseksi tällaiset hyökkäykset on erittäin helppo havaita, varsinkin jos ne tulevat yhdestä osoitteesta. Tämän seurauksena pyyntöjä aletaan välittömästi suodattaa joko järjestelmänvalvojien toimesta tai jopa palveluntarjoajan tasolla.
Mitä etsiä
Jotta voit vähentää pyyntöjen määrää sekunnissa menettämättä tehokkuutta, sinun on näytettävä hieman mielikuvitusta ja tutkittava sivustoa. Siten voit ladata kanavan tai palvelimen lisäksi myös yksittäisiä sovelluksen osia, esimerkiksi tietokantoja tai tiedostojärjestelmiä. Sivustolta voit myös etsiä isoja laskelmia tekeviä paikkoja: laskimia, tuotevalikoimasivuja jne. Lopuksi usein käy niin, että sivustolla on jonkinlainen PHP-skripti, joka luo useita satojatuhansia rivejä sisältävän sivun. Tällainen komentosarja myös kuormittaa merkittävästi palvelinta ja voi tulla hyökkäyksen kohteeksi.
Mistä etsiä
Kun skannaamme resurssia ennen testaamista, katsomme ensin tietysti itse sivustoa. Etsimme kaikenlaisia syöttökenttiä, raskaita tiedostoja - yleensä kaikkea, mikä voi aiheuttaa ongelmia resurssille ja hidastaa sen toimintaa. Tässä auttavat Google Chromen ja Firefoxin banaalit kehitystyökalut, jotka näyttävät sivujen vasteajat.
Skannaamme myös aliverkkotunnuksia. Esimerkiksi on olemassa tietty verkkokauppa, abc.com, ja sillä on aliverkkotunnus admin.abc.com. Todennäköisesti tämä on valtuutettu hallintapaneeli, mutta jos kuormitat sitä, se voi aiheuttaa ongelmia pääresurssille.
Sivustolla voi olla aliverkkotunnus api.abc.com. Todennäköisesti tämä on mobiilisovellusten resurssi. Sovellus löytyy App Storesta tai Google Playsta, asenna erityinen tukiasema, pure API ja rekisteröi testitilit. Ongelmana on, että ihmiset ajattelevat usein, että kaikki, mikä on suojattu valtuutuksilla, on immuuni palvelunestohyökkäyksille. Oletettavasti valtuutus on paras CAPTCHA, mutta se ei ole. 10-20 testitiliä on helppo tehdä, mutta luomalla ne pääsemme käsiksi monimutkaisiin ja peittämättömiin toimintoihin.
Luonnollisesti katsomme historiaa, robots.txt-tiedostoa ja WebArchivea, ViewDNS:ää ja etsimme resurssin vanhoja versioita. Joskus tapahtuu, että kehittäjät ovat ottaneet käyttöön esimerkiksi mail2.yandex.net, mutta vanha versio, mail.yandex.net, säilyy. Tätä mail.yandex.net-osoitetta ei enää tueta, sille ei ole osoitettu kehitysresursseja, mutta se kuluttaa edelleen tietokantaa. Näin ollen vanhaa versiota käyttämällä voit käyttää tehokkaasti taustajärjestelmän resursseja ja kaikkea, mikä on asettelun takana. Tämä ei tietenkään aina tapahdu, mutta kohtaamme tämän silti melko usein.
Luonnollisesti analysoimme kaikki pyyntöparametrit ja evästerakenteen. Voit esimerkiksi upottaa jotain arvoa evästeen sisällä olevaan JSON-taulukkoon, luoda paljon sisäkkäisyyttä ja saada resurssin toimimaan kohtuuttoman pitkään.
Hakukuorma
Ensimmäinen asia, joka tulee mieleen tutkittaessa sivustoa, on ladata tietokanta, koska melkein kaikilla on haku, ja valitettavasti lähes kaikille se on huonosti suojattu. Jostain syystä kehittäjät eivät kiinnitä tarpeeksi huomiota hakuun. Mutta tässä on yksi suositus - sinun ei pitäisi tehdä samantyyppisiä pyyntöjä, koska saatat kohdata välimuistin, kuten HTTP-tulvan tapauksessa.
Satunnaisten kyselyiden tekeminen tietokantaan ei myöskään aina ole tehokasta. On paljon parempi luoda luettelo avainsanoista, jotka liittyvät hakuun. Jos palataan verkkokaupan esimerkkiin: oletetaan, että sivusto myy autonrenkaita ja antaa sinun asettaa renkaiden säteen, auton tyypin ja muut parametrit. Vastaavasti asiaankuuluvien sanojen yhdistelmät pakottavat tietokannan toimimaan paljon monimutkaisemmissa olosuhteissa.
Lisäksi kannattaa käyttää sivutusta: haun on paljon vaikeampi palauttaa hakutulosten toiseksi viimeinen sivu kuin ensimmäinen. Eli sivutuksen avulla voit monipuolistaa kuormaa hieman.
Alla oleva esimerkki näyttää haun kuormituksen. Voidaan nähdä, että testin ensimmäisestä sekunnista alkaen nopeudella kymmenen pyyntöä sekunnissa, sivusto katosi eikä vastannut.
Jos hakua ei ole?
Jos hakua ei ole, tämä ei tarkoita, että sivusto ei sisällä muita haavoittuvia syöttökenttiä. Tämä kenttä voi olla valtuutus. Nykyään kehittäjät haluavat tehdä monimutkaisia tiivisteitä suojatakseen kirjautumistietokantaa sateenkaaritaulukkohyökkäyksiltä. Tämä on hyvä, mutta tällaiset tiivisteet kuluttavat paljon suoritinresursseja. Suuri määrä vääriä valtuutuksia johtaa prosessorivikaan, ja sen seurauksena sivusto lakkaa toimimasta.
Kaikenlaisten kommentti- ja palautelomakkeiden läsnäolo sivustolla on syy lähettää sinne erittäin suuria tekstejä tai yksinkertaisesti luoda massiivinen tulva. Joskus sivustot hyväksyvät liitetiedostoja, myös gzip-muodossa. Tässä tapauksessa otamme 1 Tt:n tiedoston, pakkaamme sen useisiin tavuihin tai kilotavuihin gzipin avulla ja lähetämme sen sivustolle. Sitten se puretaan ja saadaan erittäin mielenkiintoinen vaikutus.
Rest API
Haluaisin kiinnittää hieman huomiota sellaisiin suosittuihin palveluihin kuin Rest API. Rest API:n suojaaminen on paljon vaikeampaa kuin tavallisen verkkosivuston. Edes vähäpätöiset suojausmenetelmät salasanojen raakaa voimaa ja muuta laitonta toimintaa vastaan eivät toimi Rest API:ssa.
Rest API on erittäin helppo murtaa, koska se käyttää tietokantaa suoraan. Samanaikaisesti tällaisen palvelun epäonnistuminen aiheuttaa yrityksille melko vakavia seurauksia. Tosiasia on, että Rest API:ta ei yleensä käytetä vain pääsivustolle, vaan myös mobiilisovellukselle ja joihinkin sisäisiin liiketoimintaresursseihin. Ja jos kaikki tämä putoaa, vaikutus on paljon vahvempi kuin yksinkertaisen verkkosivuston epäonnistumisen tapauksessa.
Ladataan raskasta sisältöä
Jos meille tarjotaan testaamaan jotain tavallista yksisivuista sovellusta, aloitussivua tai käyntikorttisivustoa, jolla ei ole monimutkaisia toimintoja, etsimme raskasta sisältöä. Esimerkiksi suuret kuvat, jotka palvelin lähettää, binaaritiedostot, pdf-dokumentaatio - yritämme ladata kaiken tämän. Tällaiset testit lataavat tiedostojärjestelmän hyvin ja tukkivat kanavia, ja ovat siksi tehokkaita. Eli vaikka et laske palvelinta alas ja lataat suuren tiedoston alhaisilla nopeuksilla, tukkeudut yksinkertaisesti kohdepalvelimen kanavan ja sitten tapahtuu palvelunesto.
Esimerkki tällaisesta testistä osoittaa, että 30 RPS:n nopeudella sivusto lakkasi vastaamasta tai tuotti 500. palvelinvirheitä.
Älä unohda palvelinten määrittämistä. Voit usein huomata, että henkilö osti virtuaalikoneen, asensi sinne Apachen, määritti kaiken oletusarvoisesti, asensi PHP-sovelluksen ja alla näet tuloksen.
Täällä kuorma meni juurille ja oli vain 10 RPS. Odotimme 5 minuuttia ja palvelin kaatui. On totta, että ei täysin tiedetä, miksi hän kaatui, mutta oletetaan, että hänellä oli vain liikaa muistia ja siksi hän lakkasi vastaamasta.
Aaltopohjainen
Viimeisen vuoden tai kahden aikana aaltohyökkäykset ovat tulleet melko suosituiksi. Tämä johtuu siitä, että monet organisaatiot ostavat tiettyjä laitteita DDoS-suojaukseen, jotka vaativat tietyn ajan tilastojen keräämiseen hyökkäyksen suodattamisen aloittamiseksi. Toisin sanoen he eivät suodata hyökkäystä ensimmäisten 30-40 sekunnin aikana, koska ne keräävät tietoja ja oppivat. Näin ollen näissä 30-40 sekunnissa voit käynnistää sivustolla niin paljon, että resurssi makaa pitkään, kunnes kaikki pyynnöt on selvitetty.
Alla olevassa hyökkäyksessä oli 10 minuutin tauko, jonka jälkeen saapui uusi, muokattu osa hyökkäyksestä.
Eli puolustus oppi, alkoi suodattaa, mutta saapui uusi, täysin erilainen osa hyökkäyksestä ja puolustus alkoi taas oppia. Itse asiassa suodatus lakkaa toimimasta, suojauksesta tulee tehoton ja sivusto ei ole käytettävissä.
Aaltohyökkäyksille on ominaista erittäin korkeat arvot huipulla, se voi saavuttaa satatuhatta tai miljoonaa pyyntöä sekunnissa L7: n tapauksessa. Jos puhumme L3&4:stä, liikennettä voi olla satoja gigabittejä tai vastaavasti satoja mpps, jos lasketaan paketteina.
Tällaisten hyökkäysten ongelmana on synkronointi. Hyökkäykset tulevat botnetistä ja vaativat korkeaa synkronointiastetta erittäin suuren kertaluonteisen piikin luomiseksi. Ja tämä koordinointi ei aina toimi: joskus tulos on jonkinlainen parabolinen huippu, joka näyttää melko säälittävältä.
Ei pelkkä HTTP
L7:n HTTP:n lisäksi haluamme hyödyntää muita protokollia. Yleensä tavallisella verkkosivustolla, varsinkin tavallisella isännöinnillä, on sähköpostiprotokollat ja MySQL törmäävät ulos. Postiprotokollia kuormitetaan vähemmän kuin tietokantoja, mutta ne voidaan myös ladata melko tehokkaasti ja päätyä ylikuormitettuun prosessoriin palvelimella.
Onnistuimme käyttämään vuoden 2016 SSH-haavoittuvuutta. Nyt tämä haavoittuvuus on korjattu lähes kaikille, mutta tämä ei tarkoita, että latausta ei voitaisi lähettää SSH:lle. Voi. Valtuutuksia on yksinkertaisesti valtavasti, SSH syö lähes koko palvelimen suorittimen, ja sitten verkkosivusto romahtaa yhdestä tai kahdesta pyynnöstä sekunnissa. Näin ollen näitä yhtä tai kahta lokeihin perustuvaa pyyntöä ei voida erottaa laillisesta latauksesta.
Monet palvelimilla avaamamme yhteydet ovat myös merkityksellisiä. Aikaisemmin Apache syyllistyi tähän, nyt nginx on itse asiassa syyllinen tähän, koska se on usein määritetty oletusarvoisesti. Yhteyksien määrä, joita nginx voi pitää auki, on rajoitettu, joten avaamme tämän määrän yhteyksiä, nginx ei enää hyväksy uutta yhteyttä, minkä seurauksena sivusto ei toimi.
Testiklusterissamme on tarpeeksi suoritinta hyökkäämään SSL-kättelyyn. Periaatteessa, kuten käytäntö osoittaa, myös botnetit haluavat joskus tehdä tämän. Toisaalta on selvää, että et tule toimeen ilman SSL:ää, koska Googlen tulokset, sijoitus, turvallisuus. Toisaalta SSL:ssä on valitettavasti prosessoriongelma.
L3&4
Kun puhumme hyökkäyksestä L3- ja 4-tasoilla, puhumme yleensä hyökkäyksestä linkkitasolla. Tällainen kuorma on lähes aina erotettavissa laillisesta, ellei kyseessä ole SYN-tulvahyökkäys. Suojaustyökalujen SYN-tulvahyökkäysten ongelmana on niiden suuri määrä. Suurin L3&4-arvo oli 1,5-2 Tbit/s. Tällaista liikennettä on erittäin vaikea käsitellä jopa suurille yrityksille, kuten Oracle ja Google.
SYN ja SYN-ACK ovat paketteja, joita käytetään yhteyden muodostamisessa. Siksi SYN-tulva on vaikea erottaa laillisesta kuormasta: ei ole selvää, onko tämä SYN, joka tuli muodostamaan yhteyttä, vai osa tulvaa.
UDP-tulva
Yleensä hyökkääjillä ei ole niitä ominaisuuksia kuin meillä, joten vahvistusta voidaan käyttää hyökkäysten järjestämiseen. Eli hyökkääjä tutkii Internetiä ja löytää joko haavoittuvia tai väärin konfiguroituja palvelimia, jotka esimerkiksi vastauksena yhteen SYN-pakettiin vastaavat kolmella SYN-ACK-kutsulla. Huijaamalla lähdeosoite kohdepalvelimen osoitteesta on mahdollista lisätä tehoa vaikkapa kolme kertaa yhdellä paketilla ja ohjata liikennettä uhrille.
Vahvistusten ongelmana on, että niitä on vaikea havaita. Viimeaikaisia esimerkkejä ovat sensaatiomainen tapaus, jossa haavoittuva memcached. Lisäksi nyt on olemassa paljon IoT-laitteita, IP-kameroita, jotka ovat myös pääosin oletusarvoisesti konfiguroituja, ja oletuksena ne on konfiguroitu väärin, minkä vuoksi hyökkääjät hyökkäävät useimmiten tällaisten laitteiden kautta.
Vaikea SYN-tulva
SYN-floodi on ehkä mielenkiintoisin hyökkäystyyppi kehittäjän näkökulmasta. Ongelmana on, että järjestelmänvalvojat käyttävät usein IP-estoa suojatakseen. Lisäksi IP-esto ei vaikuta vain komentosarjoja käyttäviin järjestelmänvalvojiin, vaan valitettavasti myös joihinkin turvajärjestelmiin, jotka ostetaan suurella rahalla.
Tämä menetelmä voi muuttua katastrofiksi, koska jos hyökkääjät korvaavat IP-osoitteet, yritys estää oman aliverkkonsa. Kun palomuuri estää oman klusterinsa, tulos epäonnistuu ulkoisissa vuorovaikutuksissa ja resurssi epäonnistuu.
Lisäksi oman verkon estäminen ei ole vaikeaa. Jos asiakkaan toimistolla on Wi-Fi-verkko tai jos resurssien suorituskykyä mitataan erilaisilla valvontajärjestelmillä, otamme tämän valvontajärjestelmän IP-osoitteen tai asiakkaan toimiston Wi-Fi-osoitteen ja käytämme sitä lähteenä. Lopulta resurssi näyttää olevan käytettävissä, mutta kohde-IP-osoitteet on estetty. Siten HighLoad-konferenssin Wi-Fi-verkko, jossa esitellään yrityksen uutta tuotetta, voi jäädä tukkeutumaan, mikä aiheuttaa tiettyjä liiketoiminta- ja talouskustannuksia.
Testauksen aikana emme voi käyttää vahvistusta memcachedin kautta minkään ulkoisten resurssien kanssa, koska on sovittu lähettää liikennettä vain sallittuihin IP-osoitteisiin. Vastaavasti käytämme vahvistusta SYN:n ja SYN-ACKin kautta, kun järjestelmä vastaa yhden SYN:n lähettämiseen kahdella tai kolmella SYN-ACK:lla ja lähdössä hyökkäys kerrotaan kahdella tai kolmella kertaa.
Työkalut
Yksi tärkeimmistä työkaluista, joita käytämme L7-työkuormaan, on Yandex-tank. Erityisesti haamua käytetään aseena, ja lisäksi on olemassa useita skriptejä patruunoiden luomiseen ja tulosten analysointiin.
Tcpdumpia käytetään analysoimaan verkkoliikennettä ja Nmapia käytetään palvelimen analysointiin. L3- ja 4-tason kuorman luomiseen käytetään OpenSSL:ää ja vähän omaa taikuuttamme DPDK-kirjaston avulla. DPDK on Intelin kirjasto, jonka avulla voit työskennellä verkkoliitännän kanssa ohittaen Linux-pinon, mikä lisää tehokkuutta. Luonnollisesti käytämme DPDK:ta L3&4-tason lisäksi myös L7-tasolla, koska sen avulla voimme luoda erittäin korkean kuormituksen, useiden miljoonien pyyntöjen sekunnissa yhdeltä koneelta.
Käytämme myös tiettyjä liikennegeneraattoreita ja erikoistyökaluja, jotka kirjoitamme tiettyihin testeihin. Jos muistamme SSH:n haavoittuvuuden, yllä olevaa joukkoa ei voida hyödyntää. Jos hyökkäämme sähköpostiprotokollaa vastaan, otamme sähköpostiohjelmat tai kirjoitamme niihin skriptejä.
Tulokset
Lopuksi haluaisin sanoa:
- Klassisen kuormitustestauksen lisäksi on tarpeen suorittaa stressitestejä. Meillä on todellinen esimerkki, jossa kumppanin alihankkija suoritti vain kuormitustestauksen. Se osoitti, että resurssi kestää normaalin kuormituksen. Mutta sitten ilmestyi epänormaali kuormitus, sivuston vierailijat alkoivat käyttää resurssia hieman eri tavalla, ja seurauksena alihankkija makasi. Siksi haavoittuvuuksia kannattaa etsiä, vaikka olisit jo suojattu DDoS-hyökkäyksiltä.
- Jotkin järjestelmän osat on eristettävä toisista. Jos sinulla on haku, sinun on siirrettävä se eri koneille, eli ei edes Dockeriin. Koska jos haku tai valtuutus epäonnistuu, ainakin jokin toimii edelleen. Verkkokaupan tapauksessa käyttäjät jatkavat tuotteiden löytämistä luettelosta, siirtyvät kokoojasta, ostavat, jos heillä on jo valtuutus, tai valtuuttavat OAuth2:n kautta.
- Älä unohda kaikenlaisia pilvipalveluita.
- Käytä CDN:ää verkon viiveiden optimoinnin lisäksi myös suojautumiskeinona hyökkäyksiltä, jotka kohdistuvat kanavan ehtymiseen ja yksinkertaisesti staattiseen liikenteeseen.
- On tarpeen käyttää erityisiä suojapalveluita. Et voi suojautua L3&4-hyökkäyksiltä kanavatasolla, koska sinulla ei todennäköisesti yksinkertaisesti ole tarpeeksi kanavaa. Et myöskään todennäköisesti taistele L7-hyökkäyksiä vastaan, koska ne voivat olla hyvin suuria. Lisäksi pienten hyökkäysten etsiminen on edelleen erikoispalvelujen, erikoisalgoritmien etuoikeus.
- Päivitä säännöllisesti. Tämä ei koske vain ydintä, vaan myös SSH-demonia, varsinkin jos ne ovat avoinna ulkopuolelle. Periaatteessa kaikki on päivitettävä, koska et todennäköisesti pysty seuraamaan tiettyjä haavoittuvuuksia itse.
Lähde: will.com