Variti-k bot eta DDoS erasoen aurkako babesa garatzen du, eta estres eta karga probak ere egiten ditu. HighLoad++ 2018 hitzaldian hainbat eraso motatako baliabideak nola babestu hitz egin genuen. Laburbilduz: isolatu sistemaren zatiak, erabili hodeiko zerbitzuak eta CDNak eta eguneratu aldizka. Baina oraindik ezin izango duzu babesa kudeatu enpresa espezializaturik gabe :)
Testua irakurri aurretik, laburpen laburrak irakur ditzakezu .
Eta irakurtzea gustatzen ez bazaizu edo bideoa ikusi nahi baduzu, gure erreportajearen grabazioa behean dago spoiler azpian.
Txostenaren bideo grabazioa
Enpresa askok dagoeneko badakite karga-probak egiten, baina guztiek ez dute estres-probak egiten. Gure bezero batzuek uste dute beren webgunea zauriezina dela, karga handiko sistema bat dutelako eta erasoetatik ondo babesten duelako. Hau ez dela guztiz egia erakusten dugu.
Noski, probak egin aurretik, bezeroaren baimena lortzen dugu, sinatuta eta zigilatua, eta gure laguntzarekin ezin zaio inori egin DDoS erasorik. Probak bezeroak aukeratutako unean egiten dira, bere baliabiderako trafikoa gutxienekoa denean eta sarbide-arazoek bezeroei eraginik ez dietenean. Horrez gain, proba-prozesuan beti zerbait oker egon daitekeenez, etengabeko harremana dugu bezeroarekin. Horri esker, lortutako emaitzen berri emateaz gain, probetan zerbait alda dezakezu. Probak amaitutakoan, txosten bat egiten dugu beti, eta bertan antzemandako gabeziak adierazi eta gunearen ahuleziak ezabatzeko gomendioak ematen ditugu.
Nola ari gara lanean
Probak egiterakoan, botnet bat emulatzen dugu. Gure sareetan kokatuta ez dauden bezeroekin lan egiten dugunez, mugak edo babesak abiarazi direlako proba lehen minutuan amai ez dadin ziurtatzeko, karga ez dugu IP batetik hornitzen, gure azpisaretik baizik. Gainera, karga garrantzitsua sortzeko, gure proba-zerbitzari nahiko indartsua dugu.
Postulatuak
Gehiegiak ez du esan nahi ona
Zenbat eta karga gutxiago ekarri baliabide bat porrotera, orduan eta hobeto. Guneak funtzionatzeari utz diezaiokezu segundoko eskaera batean, edo minutuko eskaera batean ere, hori bikaina da. Errazkeriaren legearen arabera, erabiltzaileak edo erasotzaileak ustekabean ahultasun berezi horretan eroriko direlako.
Porrot partziala hobe da hutsegite osoa baino
Sistema heterogeneoak egitea aholkatzen dugu beti. Gainera, merezi du maila fisikoan bereiztea, eta ez soilik edukiontziz. Banatze fisikoaren kasuan, gunean zerbaitek huts egiten badu ere, oso-osorik funtzionatzeari uzteko probabilitate handia dago, eta erabiltzaileek funtzionalitatearen zati bat gutxienez sarbidea izaten jarraituko dute.
Arkitektura ona iraunkortasunaren oinarria da
Baliabide baten akatsen tolerantzia eta erasoak eta kargak jasateko duen gaitasuna diseinuaren fasean ezarri behar dira, hain zuzen ere, koaderno batean lehen fluxu-diagramak marrazteko fasean. Zeren akats larriak sartzen badira, etorkizunean zuzentzea posible da, baina oso zaila da.
Kodeak ez ezik, konfigurazioa ere ona izan behar du
Jende askok uste du garapen-talde on bat akatsekiko tolerantzia-zerbitzuaren bermea dela. Garapen talde on bat beharrezkoa da benetan, baina eragiketa onak ere egon behar dira, DevOps onak. Hau da, Linux eta sarea behar bezala konfiguratuko dituzten espezialistak behar ditugu, nginx-en konfigurazioak behar bezala idatziko dituzten, mugak ezarriko dituztenak, etab. Bestela, baliabideak probetan bakarrik funtzionatuko du, eta noizbait dena hautsi egingo da ekoizpenean.
Karga eta tentsio proben arteko desberdintasunak
Karga-probak sistemaren funtzionamenduaren mugak identifikatzea ahalbidetzen du. Estresaren probak sistema baten ahuleziak aurkitzera zuzenduta daude eta sistema hau apurtzeko eta pieza batzuen porrotaren prozesuan nola jokatuko duen ikusteko erabiltzen da. Kasu honetan, kargaren izaera normalean bezeroak ezezaguna izaten jarraitzen du estres probak hasi aurretik.
L7 erasoen ezaugarri bereizgarriak
Normalean karga motak kargatan banatzen ditugu L7 eta L3&4 mailetan. L7 aplikazio mailan karga bat da, gehienetan HTTP bakarrik esan nahi du, baina TCP protokolo mailan edozein karga esan nahi dugu.
L7 erasoek ezaugarri bereizgarri batzuk dituzte. Lehenik eta behin, aplikaziora zuzenean etortzen dira, hau da, nekez islatuko dira sareko bitartekoen bidez. Horrelako erasoek logika erabiltzen dute, eta horregatik, CPU, memoria, diskoa, datu-basea eta bestelako baliabideak oso eraginkortasunez eta trafiko gutxirekin kontsumitzen dituzte.
HTTP Flood
Edozein erasoren kasuan, karga errazago sortzen da maneiatzen baino, eta L7ren kasuan ere egia da. Ez da beti erraza erasoen trafikoa trafiko legitimotik bereiztea, eta gehienetan maiztasunaren arabera egin daiteke, baina dena behar bezala planifikatuta badago, ezinezkoa da erregistroetatik ulertzea non dagoen erasoa eta legezko eskaerak non dauden.
Lehen adibide gisa, kontuan hartu HTTP Flood eraso bat. Grafikoak erakusten du horrelako erasoak oso indartsuak izan ohi direla; beheko adibidean, eskaera kopurua 600 mila minutuko gainditzen du.
HTTP Flood karga sortzeko modurik errazena da. Normalean, karga probatzeko tresna bat behar du, hala nola ApacheBench, eta eskaera eta helburu bat ezartzen ditu. Hain hurbilketa sinple batekin, zerbitzariaren cachean exekutatzeko probabilitate handia dago, baina erraza da hura saihestea. Adibidez, eskaerari ausazko kateak gehitzea, eta horrek zerbitzaria etengabe orri berri bat hornitzera behartuko du.
Gainera, ez ahaztu erabiltzaile-agenteaz karga bat sortzeko prozesuan. Proba tresna ezagunen erabiltzaile-agente asko sistema-administratzaileek iragazten dituzte, eta kasu honetan baliteke karga atzerrira ez iristea. Emaitza nabarmen hobetu dezakezu eskaeran arakatzailearen goiburu baliotsuagoa edo gutxiago txertatuz.
HTTP Flood erasoak bezain sinpleak direnez, bere eragozpenak ere badituzte. Lehenik eta behin, potentzia handia behar da karga sortzeko. Bigarrenik, horrelako erasoak oso erraz detektatzen dira, batez ere helbide batetik badatoz. Ondorioz, eskaerak berehala iragazten hasten dira sistema-administratzaileek edo baita hornitzaile mailan ere.
Zer bilatu
Eraginkortasuna galdu gabe segundoko eskaera kopurua murrizteko, irudimen pixka bat erakutsi eta gunea arakatu behar duzu. Horrela, kanala edo zerbitzaria ez ezik, aplikazioaren zati indibidualak ere karga ditzakezu, adibidez, datu-baseak edo fitxategi sistemak. Kalkulu handiak egiten dituzten tokiak ere bila ditzakezu webgunean: kalkulagailuak, produktuak aukeratzeko orriak, etab. Azkenik, askotan gertatzen da webguneak ehunka mila lerroko orrialde bat sortzen duen PHP script motaren bat duela. Horrelako script batek zerbitzaria ere nabarmen kargatzen du eta eraso baten helburu bihur daiteke.
Non begiratu
Baliabide bat probatu aurretik eskaneatzen dugunean, lehenik eta behin, noski, gunea bera begiratzen dugu. Mota guztietako sarrera-eremuak bilatzen ari gara, fitxategi astunak, oro har, baliabideari arazoak sor ditzakeen guztia eta bere funtzionamendua moteltzea. Google Chrome eta Firefoxeko garapen tresna hutsalek hemen laguntzen dute, orriaren erantzun-denborak erakutsiz.
Azpidomeinuak ere eskaneatzen ditugu. Adibidez, online denda jakin bat dago, abc.com, eta admin.abc.com azpidomeinua du. Seguruenik, baimena duen administrazio-panel bat da, baina karga bat jarriz gero, baliabide nagusirako arazoak sor ditzake.
Guneak api.abc.com azpidomeinu bat izan dezake. Seguruenik, aplikazio mugikorretarako baliabide bat da. Aplikazioa App Store edo Google Play-n aurki daiteke, sarbide-puntu berezi bat instalatu, APIa disekzionatu eta proba-kontuak erregistratu. Arazoa da jendeak askotan uste duela baimenaren bidez babestuta dagoen edozer zerbitzuaren ukazio-erasoetatik immunea dela. Ustez, baimena CAPTCHA onena da, baina ez da. Erraza da 10-20 proba-kontu egitea, baina horiek sortuz gero, funtzionaltasun konplexu eta mozorrorik gabekoetarako sarbidea izango dugu.
Berez, historiari begiratzen diogu, robots.txt eta WebArchive, ViewDNS, eta baliabidearen bertsio zaharrak bilatzen ditugu. Batzuetan gertatzen da garatzaileek zabaldu dutela, adibidez, mail2.yandex.net, baina bertsio zaharra, mail.yandex.net, geratzen da. Mail.yandex.net hau jada ez da onartzen, garapen baliabideak ez zaizkio esleitzen, baina datu-basea kontsumitzen jarraitzen du. Horren arabera, bertsio zaharra erabiliz, backendaren baliabideak eta diseinuaren atzean dagoen guztia modu eraginkorrean erabil ditzakezu. Jakina, hau ez da beti gertatzen, baina hala ere askotan egiten dugu topo.
Jakina, eskaeraren parametro guztiak eta cookieen egitura aztertzen ditugu. Esan, balioren bat cookie baten barruan JSON array batera bota dezakezu, habia asko sortu eta baliabideak arrazoirik gabeko denbora luzez funtziona dezan.
Bilatu karga
Gune bat ikertzerakoan burura datorkigun lehen gauza datu-basea kargatzea da, ia denek baitute bilaketa bat, eta ia denentzat, tamalez, gaizki babestuta dago. Arrazoiren batengatik, garatzaileek ez diote behar adina arreta jartzen bilaketari. Baina gomendio bat dago hemen: ez duzu mota bereko eskaerarik egin behar, cachean topa dezakezulako, HTTP flood-ekin gertatzen den bezala.
Datu-baseari ausazko kontsultak egitea ere ez da beti eraginkorra. Askoz hobe da bilaketarako garrantzitsuak diren gako-hitzen zerrenda sortzea. Online denda baten adibidera itzultzen bagara: demagun guneak autoen pneumatikoak saltzen dituela eta pneumatikoen erradioa, auto mota eta beste parametro batzuk ezartzeko aukera ematen duela. Horren arabera, hitz garrantzitsuen konbinazioak datu-basea baldintza askoz konplexuagoetan lan egitera behartuko du.
Horrez gain, merezi du orrialdeak erabiltzea: bilaketa batentzat askoz zailagoa da bilaketa emaitzen azkenaurreko orria lehena baino itzultzea. Hau da, orrialdearen laguntzaz karga apur bat dibertsifikatu dezakezu.
Beheko adibideak bilaketa-karga erakusten du. Ikusten denez, probaren lehen segundotik segundoko hamar eskaeraren abiaduran, guneak behera egin zuela eta ez zuen erantzun.
Bilaketarik ez badago?
Bilaketarik ez badago, horrek ez du esan nahi guneak ez duenik beste sarrera-eremu zaurgarririk. Eremu hau baimena izan daiteke. Gaur egun, garatzaileek hash konplexuak egitea gustatzen zaie saioa hasteko datu-basea ortzadarraren taula erasoetatik babesteko. Hau ona da, baina horrelako hashek CPU baliabide asko kontsumitzen dituzte. Baimen faltsuen fluxu handi batek prozesadorearen hutsegite bat dakar eta, ondorioz, guneak funtzionatzeari uzten dio.
Webgunean iruzkinak eta iritziak egiteko era guztietako inprimakiak egotea arrazoi bat da oso testu handiak hara bidaltzeko edo, besterik gabe, uholde izugarria sortzeko. Batzuetan, webguneek erantsitako fitxategiak onartzen dituzte, baita gzip formatuan ere. Kasu honetan, 1TBko fitxategi bat hartu, gzip erabiliz hainbat byte edo kilobytetan konprimitu eta gunera bidaliko dugu. Ondoren, deskonprimitzen da eta oso efektu interesgarria lortzen da.
Atseden APIa
Arreta pixka bat eman nahiko nieke Rest API bezalako zerbitzu ezagunei. Rest API bat ziurtatzea webgune arrunt bat baino askoz zailagoa da. Pasahitzaren indar gordinaren eta legezko beste jarduera batzuen aurkako babes metodo hutsalek ere ez dute funtzionatzen Rest APIrako.
Rest APIa oso erraza da hausten, datu-basera zuzenean sartzen delako. Aldi berean, zerbitzu horren porrotak ondorio larriak dakartza negozioentzat. Kontua da Rest APIa webgune nagusirako ez ezik, mugikorretarako aplikaziorako eta barneko negozio-baliabide batzuetarako ere erabiltzen dela. Eta hori guztia erortzen bada, orduan efektua askoz ere indartsuagoa da webgunearen hutsegite soil baten kasuan baino.
Eduki astuna kargatzen
Funtzionalitate konplexurik ez duten orrialde bakarreko aplikazio, lurreratze orri edo bisita-txartelen webgune arrunt batzuk probatzea proposatzen badigute, eduki astunak bilatzen ditugu. Adibidez, zerbitzariak bidaltzen dituen irudi handiak, fitxategi bitarrak, pdf dokumentazioa - hori guztia deskargatzen saiatzen gara. Horrelako probak fitxategi-sistema ondo kargatzen dute eta kanalak trabatu egiten dituzte, eta, beraz, eraginkorrak dira. Hau da, zerbitzaria jartzen ez baduzu ere, fitxategi handi bat abiadura baxuan deskargatuz, helburuko zerbitzariaren kanala besterik gabe itxiko duzu eta, ondoren, zerbitzuaren ukapena gertatuko da.
Proba horren adibide batek erakusten du 30 RPS-ko abiaduran guneak erantzuteari utzi diola edo zerbitzariaren 500. akatsak sortu dituela.
Ez ahaztu zerbitzariak konfiguratzeaz. Askotan aurki dezakezu pertsona batek makina birtual bat erosi zuela, bertan Apache instalatu, dena lehenespenez konfiguratu, PHP aplikazio bat instalatu eta behean emaitza ikusi dezakezu.
Hemen karga errora joan zen eta 10 RPS baino ez zituen. 5 minutu itxaron genuen eta zerbitzaria huts egin zuen. Egia da ez dakiela guztiz zergatik erori zen, baina uste da, besterik gabe, memoria gehiegi zuela eta, beraz, erantzuteari utzi zion.
Uhinetan oinarrituta
Azken urtean edo bitan, olatuen erasoak nahiko ezagunak bihurtu dira. Erakunde askok DDoS babeserako hardware pieza batzuk erosten dituztelako gertatzen da, eta horrek estatistikak pilatzeko denbora jakin bat behar du erasoa iragazten hasteko. Hau da, lehen 30-40 segundoetan ez dute erasoa iragazten, datuak pilatu eta ikasten dutelako. Horren arabera, 30-40 segundo hauetan hainbeste abiarazi dezakezu webgunean, non baliabidea denbora luzez egongo da eskaera guztiak argitu arte.
Beheko erasoaren kasuan, 10 minutuko tartea egon zen, eta ondoren erasoaren zati berri eta aldatua iritsi zen.
Hau da, defentsak ikasi, iragazten hasi zen, baina erasoaren zati berri eta guztiz ezberdina iritsi zen, eta defentsa berriro ikasten hasi zen. Izan ere, iragazteak funtzionatzeari uzten dio, babesa ez da eraginkorra bihurtzen eta gunea ez dago erabilgarri.
Olatuen erasoek gailurrean balio oso altuak dituzte, segundoko ehun mila edo milioi bat eskaera irits daitezke, L7ren kasuan. L3&4 buruz hitz egiten badugu, ehunka gigabit trafiko egon daitezke, edo, horren arabera, ehunka mpps, paketeetan zenbatzen baduzu.
Horrelako erasoen arazoa sinkronizazioa da. Erasoak botnet batetik datoz eta sinkronizazio-maila handia behar dute behin-behineko puntu oso handia sortzeko. Eta koordinazio hori ez da beti funtzionatzen: batzuetan irteera gailur paraboliko moduko bat da, nahiko penagarria dirudiena.
Ez HTTP bakarrik
L7-n HTTPaz gain, beste protokolo batzuk ustiatzea gustatzen zaigu. Oro har, webgune arrunt batek, batez ere ohiko hosting batek, posta-protokoloak eta MySQL kanpoan ditu. Posta-protokoloek datu-baseek baino karga txikiagoa dute, baina nahiko modu eraginkorrean kargatu daitezke eta zerbitzarian gainkargatutako CPU batekin amaitzen dute.
Nahiko errealistan arrakasta izan genuen 2016 SSH ahultasunarekin. Orain ahultasun hau ia guztientzako konpondu da, baina horrek ez du esan nahi karga SSHra bidali ezin denik. Ahal. Baimen karga izugarria besterik ez dago, SSH-k ia CPU osoa jaten du zerbitzarian, eta, ondoren, webgunea segundoko eskaera bat edo bitik erori da. Horren arabera, erregistroetan oinarritutako eskaera bat edo bi hauek ezin dira karga legitimo batetik bereizi.
Zerbitzarietan irekitzen ditugun konexio askok ere garrantzitsuak izaten jarraitzen dute. Lehen, Apache zen honen erruduna, orain nginx da benetan honen erruduna, askotan lehenespenez konfiguratuta baitago. Nginx-ek irekita eduki dezakeen konexio-kopurua mugatua da, beraz, konexio-kopuru hori irekitzen dugu, nginx-ek jada ez du konexio berririk onartzen eta, ondorioz, guneak ez du funtzionatzen.
Gure proba-klusterrak SSL esku-ematea erasotzeko CPU nahikoa du. Printzipioz, praktikak erakusten duen moduan, botnetek batzuetan hori ere egitea gustatzen zaie. Alde batetik, argi dago ezin duzula SSL gabe egin, Google-ren emaitzak, sailkapena, segurtasuna delako. Bestalde, SSL zoritxarrez CPU arazo bat du.
L3&4
L3&4 mailetako eraso bati buruz hitz egiten dugunean, esteka mailan eraso bati buruz ari gara normalean. Karga hori ia beti bereizten da legezko batetik, SYN-flood erasoa ez bada behintzat. Segurtasun tresnetarako SYN-flood erasoen arazoa bolumen handia da. L3&4 gehienezko balioa 1,5-2 Tbit/s izan zen. Trafiko mota hau oso zaila da prozesatzea enpresa handientzat ere, Oracle eta Google barne.
SYN eta SYN-ACK konexio bat ezartzerakoan erabiltzen diren paketeak dira. Beraz, SYN-flood zaila da karga legitimo batetik bereiztea: ez dago argi konexio bat ezartzera etorri den SYN bat den edo uholde baten zati bat den.
UDP-uholdea
Normalean, erasotzaileek ez dituzte guk ditugun gaitasunik, beraz, anplifikazioa erasoak antolatzeko erabil daiteke. Hau da, erasotzaileak Internet arakatzen du eta zerbitzari zaurgarriak edo gaizki konfiguratuta aurkitzen ditu, adibidez, SYN pakete bati erantzunez, hiru SYN-ACKrekin erantzuten dutenak. Iturburu-helbidea xede-zerbitzariaren helbidetik faltifikatuz, posible da potentzia handitzea, esate baterako, hiru aldiz pakete bakar batekin eta trafikoa biktimari birbideratzea.
Anplifikazioen arazoa detektatzeko zailak direla da. Azken adibideen artean, memcached zaurgarriaren kasu sentsagarria dago. Gainera, orain IoT gailu asko daude, IP kamerak, gehienetan ere lehenespenez konfiguratuta daudenak, eta modu lehenetsian gaizki konfiguratuta daude, horregatik erasotzaileek gehienetan horrelako gailuen bidez egiten dituzte erasoak.
SYN-uholde zaila
SYN-flood da ziurrenik garatzaileen ikuspuntutik eraso motarik interesgarriena. Arazoa da sistema-administratzaileek askotan IP blokeoa erabiltzen dutela babesteko. Gainera, IP blokeoak scriptak erabiliz jarduten duten sistema-administratzaileei ez ezik, zoritxarrez, diru askoren truke erosten diren segurtasun-sistema batzuei ere eragiten die.
Metodo hau hondamendia bihur daiteke, erasotzaileek IP helbideak ordezkatzen badituzte, enpresak bere azpisarea blokeatuko duelako. Suebakiak bere clusterra blokeatzen duenean, irteerak huts egingo du kanpoko interakzioetan eta baliabideak huts egingo du.
Gainera, ez da zaila zure sarea blokeatzea. Bezeroaren bulegoak Wi-Fi sare bat badu, edo baliabideen errendimendua hainbat monitorizazio-sistema erabiliz neurtzen bada, monitorizazio-sistema honen IP helbidea edo bezeroaren bulegoko Wi-Fi-a hartzen dugu eta iturri gisa erabiltzen dugu. Azkenean, baliabidea erabilgarri dagoela dirudi, baina helburuko IP helbideak blokeatuta daude. Horrela, konpainiaren produktu berria aurkezten den HighLoad konferentziako Wi-Fi sarea blokeatu egin daiteke, eta horrek zenbait kostu komertzial eta ekonomiko dakartza.
Probetan zehar, ezin dugu anplifikazioa erabili memcached bidez kanpoko edozein baliabiderekin, trafikoa baimendutako IP helbideetara soilik bidaltzeko akordioak daudelako. Horren arabera, SYN eta SYN-ACK bidez anplifikazioa erabiltzen dugu, sistemak SYN bat bi edo hiru SYN-ACKrekin erantzuten duenean, eta irteeran erasoa bi edo hiru aldiz biderkatzen denean.
Tresnak
L7 lan-kargarako erabiltzen dugun tresna nagusietako bat Yandex-tank da. Bereziki, fantasma bat pistola gisa erabiltzen da, gainera kartutxoak sortzeko eta emaitzak aztertzeko hainbat script daude.
Tcpdump sareko trafikoa aztertzeko erabiltzen da, eta Nmap zerbitzaria aztertzeko. L3&4 mailan karga sortzeko, OpenSSL eta gure magia apur bat DPDK liburutegiarekin erabiltzen dira. DPDK Intel-eko liburutegi bat da, eta sareko interfazearekin lan egiteko aukera ematen du Linux pila saihestuz, eraginkortasuna areagotuz. Jakina, DPDK L3&4 mailan ez ezik, L7 mailan ere erabiltzen dugu, oso karga-fluxua sortzeko aukera ematen digulako, makina batetik segundoko milioika eskaeraren tartean.
Proba zehatzetarako idazten ditugun zenbait trafiko-sorgailu eta tresna berezi ere erabiltzen ditugu. SSHren ahultasuna gogoratzen badugu, ezin da goiko multzoa ustiatu. Posta-protokoloari erasotzen badiogu, posta-utilitateak hartzen ditugu edo haietan script-ak idazten ditugu, besterik gabe.
Findings
Ondorio gisa esan nahiko nuke:
- Karga-proba klasikoez gain, estres-probak egitea beharrezkoa da. Benetako adibide bat dugu non bazkide baten azpikontratistak karga probak bakarrik egiten zituen. Baliabideak ohiko karga jasan dezakeela erakutsi zuen. Baina orduan karga anormal bat agertu zen, guneko bisitariak baliabidea apur bat ezberdinean erabiltzen hasi ziren eta, ondorioz, azpikontratista etzan zen. Beraz, merezi du ahuleziak bilatzea DDoS erasoetatik babestuta egon arren.
- Beharrezkoa da sistemaren zati batzuk besteetatik isolatzea. Bilaketa bat baduzu, makina bereizietara eraman behar duzu, hau da, ez Dockerrera ere. Zeren bilaketak edo baimenak huts egiten badu, gutxienez zerbaitek funtzionatzen jarraituko du. Lineako denda baten kasuan, erabiltzaileek katalogoan produktuak aurkitzen jarraituko dute, agregatzailetik joango dira, dagoeneko baimenduta badaude erosten edo OAuth2 bidez baimentzen dute.
- Ez ahaztu hodeiko zerbitzu mota guztiak.
- Erabili CDN sareko atzerapenak optimizatzeko ez ezik, kanala agortzearen eta trafiko estatikoan gainditzearen aurkako erasoen aurkako babes gisa ere.
- Beharrezkoa da babes zerbitzu espezializatuak erabiltzea. Ezin duzu babestu L3&4 erasoetatik kanal mailan, ziurrenik ez duzulako nahikoa kanalik. L7 erasoei ere nekez aurre egingo diezu, oso handiak izan daitezkeelako. Gainera, eraso txikien bilaketa oraindik zerbitzu berezien eskumena da, algoritmo berezien eskumena.
- Eguneratu aldizka. Hau nukleoari ez ezik, SSH deabruari ere aplikatzen zaio, batez ere kanpoaldera irekita badituzu. Printzipioz, dena eguneratu behar da, ziurrenik ez baituzu zure kabuz zenbait ahultasunen jarraipena egiteko gai izango.
Iturria: www.habr.com