Variti disvolvas protekton kontraŭ robotoj kaj DDoS-atakoj, kaj ankaŭ faras streĉajn kaj ŝarĝtestojn. En la HighLoad++ 2018-konferenco ni parolis pri kiel sekurigi rimedojn de diversaj specoj de atakoj. Mallonge: izolu partojn de la sistemo, uzu nubservojn kaj CDN-ojn, kaj ĝisdatigu regule. Sed vi ankoraŭ ne povos trakti protekton sen specialigitaj kompanioj :)
Antaŭ ol legi la tekston, vi povas legi la mallongajn resumojn .
Kaj se vi ne ŝatas legi aŭ nur volas spekti la videon, la registrado de nia raporto estas sube sub la spoiler.
Videoregistrado de la raporto
Multaj kompanioj jam scias kiel fari ŝarĝtestadon, sed ne ĉiuj faras streĉtestadon. Iuj el niaj klientoj opinias, ke ilia retejo estas nevundebla ĉar ili havas altŝarĝan sistemon, kaj ĝi bone protektas kontraŭ atakoj. Ni montras, ke tio ne estas tute vera.
Kompreneble, antaŭ fari provojn, ni akiras permeson de la kliento, subskribita kaj stampita, kaj kun nia helpo DDoS-atako ne povas esti farita kontraŭ iu ajn. Testado estas farita en tempo elektita de la kliento, kiam trafiko al lia rimedo estas minimuma, kaj alirproblemoj ne influos klientojn. Krome, ĉar io ĉiam povas misfunkcii dum la testa procezo, ni havas konstantan kontakton kun la kliento. Ĉi tio permesas vin ne nur raporti la atingitajn rezultojn, sed ankaŭ ŝanĝi ion dum testado. Fininte la testadon, ni ĉiam ellaboras raporton, en kiu ni atentigas la detektitajn mankojn kaj donas rekomendojn por forigi la malfortojn de la retejo.
Kiel ni laboras
Dum testado, ni imitas botneton. Ĉar ni laboras kun klientoj, kiuj ne troviĝas en niaj retoj, por certigi, ke la testo ne finiĝos en la unua minuto pro limoj aŭ protekto estiĝantaj, ni provizas la ŝarĝon ne de unu IP, sed de nia propra subreto. Krome, por krei gravan ŝarĝon, ni havas nian propran sufiĉe potencan testservilon.
Postulatoj
Tro multe ne signifas bonon
Ju malpli da ŝarĝo ni povas alporti rimedon al fiasko, des pli bone. Se vi povas ĉesi funkcii la retejon je unu peto por sekundo, aŭ eĉ unu peto por minuto, tio estas bonega. Ĉar laŭ la leĝo de malnobleco, uzantoj aŭ atakantoj hazarde falos en ĉi tiun apartan vundeblecon.
Parta fiasko estas pli bona ol kompleta fiasko
Ni ĉiam konsilas fari sistemojn heterogenaj. Cetere, indas apartigi ilin je fizika nivelo, kaj ne nur per kontenerigo. En la kazo de fizika disiĝo, eĉ se io malsukcesas en la retejo, estas alta probablo, ke ĝi ne ĉesos funkcii tute, kaj uzantoj daŭre havos aliron al almenaŭ parto de la funkcieco.
Bona arkitekturo estas la bazo por daŭripovo
La faŭltoleremo de rimedo kaj ĝia kapablo rezisti atakojn kaj ŝarĝojn devus esti fiksitaj en la dezajna etapo, fakte, en la stadio de desegnado de la unuaj fludiagramoj en notbloko. Ĉar se enŝteliĝas fatalaj eraroj, eblas korekti ilin estonte, sed ĝi estas tre malfacila.
Ne nur la kodo estu bona, sed ankaŭ la agordo
Multaj homoj opinias, ke bona disvolva teamo estas garantio de mistolerema servo. Bona evolua teamo estas vere necesa, sed ankaŭ devas esti bonaj operacioj, bonaj DevOps. Tio estas, ni bezonas specialistojn, kiuj ĝuste agordos Linukson kaj la reton, skribos ĝuste agordojn en nginx, fiksos limojn ktp. Alie, la rimedo funkcios bone nur en testado, kaj iam ĉio rompiĝos en produktado.
Diferencoj inter ŝarĝo kaj streĉa testado
Ŝarĝotestado permesas vin identigi la limojn de sistema funkciado. Streĉa testado celas trovi malfortojn en sistemo kaj estas uzata por rompi ĉi tiun sistemon kaj vidi kiel ĝi kondutos en la procezo de fiasko de iuj partoj. En ĉi tiu kazo, la naturo de la ŝarĝo kutime restas nekonata al la kliento antaŭ ol strestestado komenciĝas.
Karakterizaĵoj de L7-atakoj
Ni kutime dividas specojn de ŝarĝo en ŝarĝojn ĉe la L7 kaj L3&4-niveloj. L7 estas ŝarĝo ĉe la aplika nivelo, plej ofte ĝi signifas nur HTTP, sed ni signifas ajnan ŝarĝon ĉe la TCP-protokolo-nivelo.
L7-atakoj havas certajn karakterizaĵojn. Unue, ili venas rekte al la aplikaĵo, tio estas, estas neverŝajne, ke ili reflektiĝos per retaj rimedoj. Tiaj atakoj uzas logikon, kaj pro tio ili konsumas CPU, memoron, diskon, datumbazon kaj aliajn rimedojn tre efike kaj kun malmulte da trafiko.
HTTP Flood
En la kazo de ajna atako, la ŝarĝo estas pli facile krei ol manipuli, kaj en la kazo de L7 ĉi tio ankaŭ estas vera. Ne ĉiam estas facile distingi ataktrafikon de legitima trafiko, kaj plej ofte ĉi tio povas esti farita per ofteco, sed se ĉio estas planita ĝuste, tiam estas neeble kompreni el la protokoloj, kie estas la atako kaj kie estas la legitimaj petoj.
Kiel unua ekzemplo, konsideru HTTP Flood-atakon. La grafikaĵo montras, ke tiaj atakoj estas kutime tre potencaj; en la suba ekzemplo, la pinta nombro da petoj superis 600 mil por minuto.
HTTP Flood estas la plej facila maniero krei ŝarĝon. Tipe, ĝi bezonas ian ŝarĝan testan ilon, kiel ApacheBench, kaj starigas peton kaj celon. Kun tia simpla aliro, estas alta probablo renkonti servilon kaŝmemoron, sed estas facile preteriri ĝin. Ekzemple, aldonante hazardajn ŝnurojn al la peto, kio devigos la servilon konstante servi freŝan paĝon.
Ankaŭ ne forgesu pri la uzantagento en la procezo de kreado de ŝarĝo. Multaj uzantagentoj de popularaj testaj iloj estas filtritaj de sistemaj administrantoj, kaj ĉi-kaze la ŝarĝo eble simple ne atingas la backend. Vi povas signife plibonigi la rezulton enmetante pli-malpli validan kaplinion de la retumilo en la peton.
Tiel simplaj kiel HTTP Flood-atakoj estas, ili ankaŭ havas siajn malavantaĝojn. Unue, grandaj kvantoj da potenco estas postulataj por krei la ŝarĝon. Due, tiaj atakoj estas tre facile detekteblaj, precipe se ili venas de unu adreso. Kiel rezulto, petoj tuj komencas esti filtritaj aŭ de sistemadministrantoj aŭ eĉ ĉe la provizanto.
Kion serĉi
Por redukti la nombron da petoj por sekundo sen perdi efikecon, vi devas montri iom da imago kaj esplori la retejon. Tiel, vi povas ŝarĝi ne nur la kanalon aŭ servilon, sed ankaŭ individuajn partojn de la aplikaĵo, ekzemple, datumbazoj aŭ dosiersistemoj. Vi ankaŭ povas serĉi lokojn en la retejo, kiuj faras grandajn kalkulojn: kalkuliloj, produkt-elektopaĝoj, ktp. Fine, ofte okazas, ke la retejo havas ian PHP-skripton, kiu generas paĝon de kelkcent mil linioj. Tia skripto ankaŭ signife ŝarĝas la servilon kaj povas fariĝi celo por atako.
Kie serĉi
Kiam ni skanas rimedon antaŭ testado, ni unue rigardas, kompreneble, la retejon mem. Ni serĉas ĉiajn enigkampojn, pezajn dosierojn - ĝenerale ĉion, kio povas krei problemojn por la rimedo kaj malrapidigi ĝian funkciadon. Banaj evoluiloj en Google Chrome kaj Fajrovulpo helpas ĉi tie, montrante paĝajn respondtempojn.
Ni ankaŭ skanas subdomajnojn. Ekzemple, ekzistas certa reta butiko, abc.com, kaj ĝi havas subdomajnon admin.abc.com. Plej verŝajne, ĉi tio estas administra panelo kun rajtigo, sed se vi ŝarĝas ĝin, ĝi povas krei problemojn por la ĉefa rimedo.
La retejo povas havi subdomajnon api.abc.com. Plej verŝajne, ĉi tio estas rimedo por moveblaj aplikoj. La aplikaĵo troviĝas en la App Store aŭ Google Play, instali specialan alirpunkton, dissekci la API kaj registri testajn kontojn. La problemo estas, ke homoj ofte pensas, ke ĉio, kio estas protektita per rajtigo, estas imuna kontraŭ neado de servo-atakoj. Supozeble, rajtigo estas la plej bona CAPTCHA, sed ĝi ne estas. Estas facile fari 10-20 testajn kontojn, sed kreante ilin, ni ricevas aliron al kompleksaj kaj nekaŝitaj funkcioj.
Nature, ni rigardas historion, ĉe robots.txt kaj WebArchive, ViewDNS, kaj serĉas malnovajn versiojn de la rimedo. Foje okazas, ke programistoj lanĉis, ekzemple, mail2.yandex.net, sed la malnova versio, mail.yandex.net, restas. Ĉi tiu mail.yandex.net ne plu estas subtenata, evoluaj rimedoj ne estas asignitaj al ĝi, sed ĝi daŭre konsumas la datumbazon. Sekve, uzante la malnovan version, vi povas efike uzi la rimedojn de la backend kaj ĉion, kio estas malantaŭ la aranĝo. Kompreneble, ĉi tio ne ĉiam okazas, sed ni ankoraŭ renkontas tion sufiĉe ofte.
Nature, ni analizas ĉiujn petajn parametrojn kaj la kuketan strukturon. Vi povas, ekzemple, forĵeti iom da valoro en JSON-tabelon ene de kuketo, krei multe da nestado kaj igi la rimedon funkcii dum neracie longa tempo.
Serĉa ŝarĝo
La unua afero, kiu venas al la menso, kiam oni esploras retejon, estas ŝarĝi la datumbazon, ĉar preskaŭ ĉiuj havas serĉon, kaj por preskaŭ ĉiuj, bedaŭrinde, ĝi estas malbone protektita. Ial, programistoj ne sufiĉe atentas serĉi. Sed estas unu rekomendo ĉi tie - vi ne faru petojn de la sama tipo, ĉar vi povas renkonti kaŝmemoron, kiel estas la kazo kun HTTP flood.
Fari hazardajn demandojn al la datumbazo ankaŭ ne ĉiam efikas. Estas multe pli bone krei liston de ŝlosilvortoj rilataj al la serĉo. Se ni revenas al la ekzemplo de interreta vendejo: ni diru, ke la retejo vendas aŭtajn pneŭojn kaj permesas al vi agordi la radiuson de la pneŭoj, la tipon de aŭto kaj aliajn parametrojn. Sekve, kombinoj de koncernaj vortoj devigos la datumbazon labori en multe pli kompleksaj kondiĉoj.
Krome, indas uzi paĝigon: estas multe pli malfacile por serĉo redoni la antaŭlastan paĝon de la serĉrezultoj ol la unua. Tio estas, helpe de paĝigo vi povas iomete diversigi la ŝarĝon.
La suba ekzemplo montras la serĉŝarĝon. Oni povas vidi, ke ekde la unua sekundo de la testo kun rapideco de dek petoj sekundo, la retejo malfunkciis kaj ne respondis.
Se ne estas serĉo?
Se ne ekzistas serĉo, tio ne signifas, ke la retejo ne enhavas aliajn vundeblajn enigkampojn. Ĉi tiu kampo povas esti rajtigo. Nuntempe, programistoj ŝatas fari kompleksajn haŝojn por protekti la ensalutan datumbazon de ĉielarka tablo-atako. Ĉi tio estas bona, sed tiaj haŝiŝoj konsumas multajn CPU-rimedojn. Granda fluo de falsaj rajtigoj kondukas al fiasko de procesoro, kaj kiel rezulto, la retejo ĉesas funkcii.
La ĉeesto en la retejo de ĉiaj formoj por komentoj kaj komentoj estas kialo por sendi tre grandajn tekstojn tien aŭ simple krei amasan inundon. Foje retejoj akceptas alfiksitajn dosierojn, inkluzive en gzip-formato. En ĉi tiu kazo, ni prenas 1TB dosieron, kunpremas ĝin al pluraj bajtoj aŭ kilobajtoj uzante gzip kaj sendas ĝin al la retejo. Tiam ĝi estas malzipita kaj tre interesa efiko estas akirita.
Rest API
Mi ŝatus iom atenti tiajn popularajn servojn kiel la Rest API. Sekurigi Rest-API estas multe pli malfacila ol regula retejo. Eĉ bagatelaj metodoj de protekto kontraŭ pasvorta krudforto kaj alia ekstergeedza agado ne funkcias por la Rest-API.
La Rest-API estas tre facile rompi ĉar ĝi rekte aliras la datumbazon. Samtempe, la fiasko de tia servo kunportas sufiĉe gravajn konsekvencojn por komerco. Fakte, la Rest API estas kutime uzata ne nur por la ĉefa retejo, sed ankaŭ por la movebla aplikaĵo kaj iuj internaj komercaj rimedoj. Kaj se ĉio ĉi falas, tiam la efiko estas multe pli forta ol en la kazo de simpla retejo-fiasko.
Ŝarĝante pezan enhavon
Se oni proponas al ni testi iun ordinaran unupaĝan aplikaĵon, landpaĝon aŭ vizitkartan retejon, kiu ne havas kompleksajn funkciojn, ni serĉas pezan enhavon. Ekzemple, grandaj bildoj, kiujn la servilo sendas, binaraj dosieroj, pdf-dokumentado - ni provas elŝuti ĉion ĉi. Tiaj testoj bone ŝarĝas la dosiersistemon kaj ŝtopas kanalojn, kaj tial estas efikaj. Tio estas, eĉ se vi ne demetas la servilon, elŝutante grandan dosieron je malaltaj rapidoj, vi simple ŝtopos la kanalon de la cela servilo kaj tiam okazos neo de servo.
Ekzemplo de tia provo montras, ke kun rapido de 30 RPS la retejo ĉesis respondi aŭ produktis 500-ajn servilojn.
Ne forgesu pri agordo de serviloj. Vi ofte povas trovi, ke persono aĉetis virtualan maŝinon, instalis Apache tie, agordis ĉion defaŭlte, instalis PHP-aplikaĵon, kaj sube vi povas vidi la rezulton.
Ĉi tie la ŝarĝo iris al la radiko kaj sumiĝis al nur 10 RPS. Ni atendis 5 minutojn kaj la servilo kraŝis. Estas vere, ke oni ne tute scias, kial li falis, sed oni supozas, ke li simple havis tro da memoro kaj tial ĉesis respondi.
Ondo bazita
En la lastaj jaroj aŭ du, ondo-atakoj fariĝis sufiĉe popularaj. Ĉi tio estas pro la fakto, ke multaj organizoj aĉetas certajn aparataĵojn por DDoS-protekto, kiuj postulas certan tempon por amasigi statistikojn por komenci filtri la atakon. Tio estas, ili ne filtras la atakon en la unuaj 30-40 sekundoj, ĉar ili amasigas datumojn kaj lernas. Sekve, en ĉi tiuj 30-40 sekundoj vi povas lanĉi tiom multe sur la retejo, ke la rimedo kuŝos dum longa tempo ĝis ĉiuj petoj estos klarigitaj.
En la kazo de la atako malsupre, ekzistis intervalo de 10 minutoj, post kiu nova, modifita parto de la atako alvenis.
Tio estas, la defendo lernis, komencis filtri, sed nova, tute malsama parto de la atako alvenis, kaj la defendo eklernis denove. Fakte, filtrado ĉesas funkcii, protekto fariĝas neefika, kaj la retejo estas neatingebla.
Ondaj atakoj estas karakterizitaj per tre altaj valoroj ĉe la pinto, ĝi povas atingi cent mil aŭ milionon da petoj sekundo, en la kazo de L7. Se ni parolas pri L3&4, tiam povas esti centoj da gigabitoj da trafiko, aŭ, laŭe, centoj da mpps, se vi kalkulas en pakoj.
La problemo kun tiaj atakoj estas sinkronigado. La atakoj venas de botneto kaj postulas altan gradon de sinkronigo por krei tre grandan unufojan pikilon. Kaj ĉi tiu kunordigo ne ĉiam funkcias: foje la eligo estas ia parabola pinto, kiu aspektas sufiĉe kompatinda.
Ne HTTP sole
Krom HTTP ĉe L7, ni ŝatas ekspluati aliajn protokolojn. Kiel regulo, regula retejo, precipe regula gastigado, havas poŝtajn protokolojn kaj MySQL elstarantajn. Poŝtprotokoloj estas submetataj al malpli da ŝarĝo ol datumbazoj, sed ili ankaŭ povas esti ŝarĝitaj sufiĉe efike kaj finiĝi kun troŝarĝita CPU sur la servilo.
Ni estis sufiĉe sukcesaj uzante la 2016 SSH-vunereblecon. Nun ĉi tiu vundebleco estis riparita por preskaŭ ĉiuj, sed ĉi tio ne signifas, ke ŝarĝo ne povas esti sendita al SSH. Povas. Simple estas grandega ŝarĝo da rajtigoj, SSH manĝas preskaŭ la tutan CPU sur la servilo, kaj tiam la retejo kolapsas de unu aŭ du petoj sekundo. Sekve, ĉi tiuj unu aŭ du petoj bazitaj sur la protokoloj ne povas esti distingitaj de laŭleĝa ŝarĝo.
Multaj konektoj, kiujn ni malfermas en serviloj, ankaŭ restas gravaj. Antaŭe, Apache estis kulpa pri tio, nun nginx fakte suferas de tio, ĉar ĝi ofte estas agordita defaŭlte. La nombro da konektoj kiujn nginx povas konservi malfermitaj estas limigita, do ni malfermas ĉi tiun nombron da konektoj, nginx ne plu akceptas novan konekton, kaj kiel rezulto la retejo ne funkcias.
Nia testa areto havas sufiĉe da CPU por ataki SSL-manpremon. Principe, kiel praktiko montras, botnetoj foje ŝatas fari ĉi tion ankaŭ. Unuflanke, estas klare, ke vi ne povas malhavi SSL, ĉar Google rezultoj, rangotabelo, sekureco. Aliflanke, SSL bedaŭrinde havas CPU-problemon.
L3&4
Kiam ni parolas pri atako ĉe la L3 & 4-niveloj, ni kutime parolas pri atako ĉe la lignivelo. Tia ŝarĝo preskaŭ ĉiam estas distingebla de legitima, krom se ĝi estas SYN-inunda atako. La problemo kun SYN-inundaj atakoj por sekurecaj iloj estas ilia granda volumo. La maksimuma L3&4-valoro estis 1,5-2 Tbit/s. Tia trafiko estas tre malfacile prilaborebla eĉ por grandaj kompanioj, inkluzive de Oracle kaj Google.
SYN kaj SYN-ACK estas pakaĵoj kiuj estas uzataj dum establado de konekto. Tial, SYN-inundo malfacilas distingi de legitima ŝarĝo: estas ne klare ĉu tio estas SYN kiu establis ligon, aŭ parton de inundo.
UDP-inundo
Tipe, atakantoj ne havas la kapablojn kiujn ni havas, do plifortigo povas esti uzata por organizi atakojn. Tio estas, la atakanto skanas la Interreton kaj trovas aŭ vundeblajn aŭ neĝuste agorditajn servilojn kiuj, ekzemple, en respondo al unu SYN-pakaĵo, respondas per tri SYN-ACK-oj. Falsigante la fontadreson de la adreso de la cela servilo, eblas pliigi la potencon per, ekzemple, trifoje per ununura pako kaj redirekti trafikon al la viktimo.
La problemo kun plifortigoj estas ke ili estas malfacile detekteblaj. Lastatempaj ekzemploj inkludas la sensacian kazon de la vundebla memcached. Krome, nun ekzistas multaj IoT-aparatoj, IP-fotiloj, kiuj ankaŭ estas plejparte agorditaj defaŭlte, kaj defaŭlte ili estas agorditaj malĝuste, tial atakantoj plej ofte faras atakojn per tiaj aparatoj.
Malfacila SYN-inundo
SYN-flood estas verŝajne la plej interesa speco de atako el la vidpunkto de programisto. La problemo estas, ke sistemadministrantoj ofte uzas IP-blokadon por protekto. Krome, IP-blokado influas ne nur sistemajn administrantojn, kiuj agas per skriptoj, sed ankaŭ, bedaŭrinde, iujn sekurecajn sistemojn, kiuj estas aĉetitaj por multe da mono.
Ĉi tiu metodo povas iĝi katastrofo, ĉar se atakantoj anstataŭigas IP-adresojn, la kompanio blokos sian propran subreton. Kiam la Fajroŝirmilo blokas sian propran areton, la eligo malsukcesos eksterajn interagojn kaj la rimedo malsukcesos.
Krome, ne estas malfacile bloki vian propran reton. Se la oficejo de la kliento havas reton Wi-Fi, aŭ se la rendimento de rimedoj estas mezurita per diversaj monitoraj sistemoj, tiam ni prenas la IP-adreson de ĉi tiu monitora sistemo aŭ la oficejo de la kliento Wi-Fi kaj uzas ĝin kiel fonton. Fine, la rimedo ŝajnas esti disponebla, sed la celaj IP-adresoj estas blokitaj. Tiel, la reto Wi-Fi de la HighLoad-konferenco, kie la nova produkto de la kompanio estas prezentita, povas esti blokita, kaj tio kunportas certajn komercajn kaj ekonomiajn kostojn.
Dum testado, ni ne povas uzi plifortigon per memcached kun iuj eksteraj rimedoj, ĉar ekzistas interkonsentoj por sendi trafikon nur al permesitaj IP-adresoj. Sekve, ni uzas plifortigon per SYN kaj SYN-ACK, kiam la sistemo respondas al sendado de unu SYN per du aŭ tri SYN-ACK-oj, kaj ĉe la eligo la atako estas multobligita je du aŭ tri fojojn.
Iloj
Unu el la ĉefaj iloj, kiujn ni uzas por L7-laborŝarĝo, estas Yandex-tanko. Aparte, fantomo estas uzata kiel pafilo, krome ekzistas pluraj skriptoj por generi kartoĉojn kaj por analizi la rezultojn.
Tcpdump estas uzata por analizi retan trafikon, kaj Nmap estas uzata por analizi la servilon. Por krei la ŝarĝon ĉe la L3&4-nivelo, OpenSSL kaj iom de nia propra magio kun la DPDK-biblioteko estas uzataj. DPDK estas biblioteko de Intel, kiu permesas vin labori kun la reto-interfaco preterpasante la Linuksan stakon, tiel pliigante efikecon. Kompreneble, ni uzas DPDK ne nur ĉe la nivelo L3 & 4, sed ankaŭ ĉe la nivelo L7, ĉar ĝi permesas al ni krei tre altan ŝarĝan fluon, ene de la gamo de pluraj milionoj da petoj sekundo de unu maŝino.
Ni ankaŭ uzas certajn trafikajn generantojn kaj specialajn ilojn, kiujn ni skribas por specifaj provoj. Se ni memoras la vundeblecon sub SSH, tiam la supra aro ne povas esti ekspluatata. Se ni atakas la poŝtan protokolon, ni prenas poŝtajn utilecojn aŭ simple skribas skriptojn sur ili.
trovoj
Kiel konkludo mi ŝatus diri:
- Krom klasika ŝarĝtestado, necesas fari streĉan provon. Ni havas realan ekzemplon, kie la subkontraktisto de partnero nur faris ŝarĝtestadon. Ĝi montris, ke la rimedo povas elteni la normalan ŝarĝon. Sed tiam aperis nenormala ŝarĝo, la vizitantoj de la retejo komencis uzi la rimedon iomete alie, kaj sekve la subkontraktisto kuŝiĝis. Tiel, indas serĉi vundeblecojn eĉ se vi jam estas protektita kontraŭ DDoS-atakoj.
- Estas necese izoli iujn partojn de la sistemo de aliaj. Se vi havas serĉon, vi devas movi ĝin al apartaj maŝinoj, tio estas, eĉ ne al Docker. Ĉar se serĉado aŭ rajtigo malsukcesas, almenaŭ io daŭre funkcios. En la kazo de reta vendejo, uzantoj daŭre trovos produktojn en la katalogo, iros de la agregatoro, aĉetos se ili jam estas rajtigitaj aŭ rajtigos per OAuth2.
- Ne neglektu ĉiajn nubajn servojn.
- Uzu CDN ne nur por optimumigi retajn prokrastojn, sed ankaŭ kiel rimedon de protekto kontraŭ atakoj kontraŭ kanala elĉerpiĝo kaj simple inundado en senmovan trafikon.
- Necesas uzi specialigitajn protektajn servojn. Vi ne povas protekti vin kontraŭ L3&4-atakoj ĉe la kanalnivelo, ĉar vi plej verŝajne simple ne havas sufiĉan kanalon. Vi ankaŭ neprobablas kontraŭbatali L7-atakojn, ĉar ili povas esti tre grandaj. Krome, la serĉo de malgrandaj atakoj ankoraŭ estas la privilegio de specialaj servoj, specialaj algoritmoj.
- Ĝisdatigu regule. Ĉi tio validas ne nur por la kerno, sed ankaŭ por la SSH-demono, precipe se vi havas ilin malfermitaj ekstere. Principe ĉio devas esti ĝisdatigita, ĉar vi verŝajne ne povos spuri certajn vundeblecojn memstare.
fonto: www.habr.com