Nagkakaroon ng proteksyon ang Variti laban sa mga bot at pag-atake ng DDoS, at nagsasagawa rin ng stress at load testing. Sa HighLoad++ 2018 conference, napag-usapan namin kung paano i-secure ang mga mapagkukunan mula sa iba't ibang uri ng pag-atake. Sa madaling salita: ihiwalay ang mga bahagi ng system, gumamit ng mga serbisyo sa cloud at CDN, at regular na mag-update. Ngunit hindi mo pa rin mahawakan ang proteksyon nang walang mga espesyal na kumpanya :)
Bago basahin ang teksto, maaari mong basahin ang mga maikling abstract .
At kung ayaw mong magbasa o gusto mo lang panoorin ang video, ang pag-record ng aming ulat ay nasa ibaba sa ilalim ng spoiler.
Pag-record ng video ng ulat
Alam na ng maraming kumpanya kung paano mag-load testing, ngunit hindi lahat ay gumagawa ng stress testing. Iniisip ng ilan sa aming mga customer na hindi maaapektuhan ang kanilang site dahil mayroon silang highload system, at mahusay itong nagpoprotekta mula sa mga pag-atake. Ipinapakita namin na hindi ito ganap na totoo.
Siyempre, bago magsagawa ng mga pagsubok, kukuha kami ng pahintulot mula sa customer, nilagdaan at naselyohan, at sa aming tulong ay hindi maisagawa ang pag-atake ng DDoS sa sinuman. Ang pagsubok ay isinasagawa sa oras na pinili ng customer, kapag ang trapiko sa kanyang mapagkukunan ay minimal, at ang mga problema sa pag-access ay hindi makakaapekto sa mga kliyente. Bilang karagdagan, dahil laging may mali sa panahon ng proseso ng pagsubok, palagi kaming nakikipag-ugnayan sa customer. Ito ay nagbibigay-daan sa iyo hindi lamang upang iulat ang mga resulta na nakamit, ngunit din upang baguhin ang isang bagay sa panahon ng pagsubok. Sa pagkumpleto ng pagsubok, palagi kaming gumagawa ng isang ulat kung saan itinuturo namin ang mga nakitang pagkukulang at nagbibigay ng mga rekomendasyon para sa pag-aalis ng mga kahinaan ng site.
Kung paano kami gumagana
Kapag sumusubok, tinutularan namin ang isang botnet. Dahil nakikipagtulungan kami sa mga kliyenteng hindi matatagpuan sa aming mga network, upang matiyak na ang pagsubok ay hindi matatapos sa unang minuto dahil sa mga limitasyon o proteksyon na nati-trigger, ibinibigay namin ang load hindi mula sa isang IP, ngunit mula sa aming sariling subnet. Dagdag pa, upang lumikha ng isang makabuluhang pagkarga, mayroon kaming sariling medyo malakas na server ng pagsubok.
Postulates
Ang sobra ay hindi nangangahulugang mabuti
Ang mas kaunting pagkarga na maaari nating dalhin sa isang mapagkukunan sa pagkabigo, mas mabuti. Kung magagawa mong ihinto ang paggana ng site sa isang kahilingan sa bawat segundo, o kahit isang kahilingan kada minuto, maganda iyon. Dahil ayon sa batas ng kakulitan, ang mga gumagamit o umaatake ay hindi sinasadyang mahuhulog sa partikular na kahinaan na ito.
Ang bahagyang pagkabigo ay mas mahusay kaysa sa kumpletong kabiguan
Palagi naming pinapayuhan na gawing heterogenous ang mga system. Bukod dito, ito ay nagkakahalaga ng paghihiwalay sa kanila sa pisikal na antas, at hindi lamang sa pamamagitan ng containerization. Sa kaso ng pisikal na paghihiwalay, kahit na may mabibigo sa site, may mataas na posibilidad na hindi ito ganap na titigil sa pagtatrabaho, at ang mga user ay patuloy na magkakaroon ng access sa kahit man lang bahagi ng functionality.
Ang magandang arkitektura ay ang batayan para sa pagpapanatili
Ang fault tolerance ng isang mapagkukunan at ang kakayahang makatiis sa mga pag-atake at pag-load ay dapat na ilatag sa yugto ng disenyo, sa katunayan, sa yugto ng pagguhit ng mga unang flowchart sa isang notebook. Dahil kung ang mga nakamamatay na pagkakamali ay gumagapang, posible na itama ang mga ito sa hinaharap, ngunit ito ay napakahirap.
Hindi lang dapat maganda ang code, pati na rin ang config
Maraming mga tao ang nag-iisip na ang isang mahusay na pangkat ng pag-unlad ay isang garantiya ng serbisyong hindi mapagparaya. Ang isang mahusay na pangkat ng pag-unlad ay talagang kinakailangan, ngunit dapat ding magkaroon ng mahusay na mga operasyon, mahusay na DevOps. Iyon ay, kailangan namin ng mga espesyalista na wastong i-configure ang Linux at ang network, isulat nang tama ang mga config sa nginx, magtakda ng mga limitasyon, atbp. Kung hindi, ang mapagkukunan ay gagana lamang nang maayos sa pagsubok, at sa ilang mga punto ang lahat ay masisira sa produksyon.
Mga pagkakaiba sa pagitan ng load at stress testing
Binibigyang-daan ka ng pagsubok sa pag-load na matukoy ang mga limitasyon ng paggana ng system. Ang stress testing ay naglalayong maghanap ng mga kahinaan sa isang sistema at ginagamit upang sirain ang sistemang ito at makita kung paano ito kikilos sa proseso ng pagkabigo ng ilang bahagi. Sa kasong ito, ang likas na katangian ng load ay karaniwang nananatiling hindi alam ng customer bago magsimula ang stress testing.
Mga natatanging tampok ng pag-atake ng L7
Karaniwan naming hinahati ang mga uri ng load sa mga load sa L7 at L3&4 na antas. Ang L7 ay isang load sa antas ng aplikasyon, kadalasan ito ay nangangahulugan lamang ng HTTP, ngunit ang ibig naming sabihin ay anumang load sa antas ng TCP protocol.
Ang mga pag-atake sa L7 ay may ilang mga natatanging tampok. Una, direkta silang pumunta sa application, iyon ay, malamang na hindi sila makikita sa pamamagitan ng mga paraan ng network. Ang ganitong mga pag-atake ay gumagamit ng lohika, at dahil dito, ginagamit nila ang CPU, memorya, disk, database at iba pang mga mapagkukunan nang napakahusay at may kaunting trapiko.
HTTP Flood
Sa kaso ng anumang pag-atake, ang pag-load ay mas madaling gawin kaysa hawakan, at sa kaso ng L7 ito ay totoo rin. Hindi palaging madaling makilala ang trapiko ng pag-atake mula sa lehitimong trapiko, at kadalasan ito ay maaaring gawin sa pamamagitan ng dalas, ngunit kung ang lahat ay pinlano nang tama, kung gayon imposibleng maunawaan mula sa mga log kung saan ang pag-atake at kung saan ang mga lehitimong kahilingan.
Bilang unang halimbawa, isaalang-alang ang isang HTTP Flood attack. Ipinapakita ng graph na ang mga naturang pag-atake ay kadalasang napakalakas; sa halimbawa sa ibaba, ang pinakamataas na bilang ng mga kahilingan ay lumampas sa 600 libo kada minuto.
Ang HTTP Flood ay ang pinakamadaling paraan para gumawa ng load. Karaniwan, nangangailangan ito ng ilang uri ng tool sa pagsubok sa pag-load, gaya ng ApacheBench, at nagtatakda ng kahilingan at target. Sa ganoong simpleng diskarte, may mataas na posibilidad na tumakbo sa server caching, ngunit madaling i-bypass ito. Halimbawa, ang pagdaragdag ng mga random na string sa kahilingan, na pipilitin ang server na patuloy na maghatid ng bagong pahina.
Gayundin, huwag kalimutan ang tungkol sa user-agent sa proseso ng paglikha ng isang load. Maraming user-agent ng mga sikat na tool sa pagsubok ang na-filter ng mga administrator ng system, at sa kasong ito ay maaaring hindi lang maabot ng load ang backend. Mapapabuti mo nang malaki ang resulta sa pamamagitan ng paglalagay ng higit pa o hindi gaanong wastong header mula sa browser sa kahilingan.
Kasing simple ng mga pag-atake ng HTTP Flood, mayroon din silang mga kakulangan. Una, ang malaking halaga ng kapangyarihan ay kinakailangan upang lumikha ng pagkarga. Pangalawa, ang mga naturang pag-atake ay napakadaling matukoy, lalo na kung nagmula sila sa isang address. Bilang resulta, ang mga kahilingan ay agad na magsisimulang i-filter alinman ng mga administrator ng system o kahit na sa antas ng provider.
Ano ang hahanapin
Upang bawasan ang bilang ng mga kahilingan sa bawat segundo nang hindi nawawala ang kahusayan, kailangan mong magpakita ng kaunting imahinasyon at galugarin ang site. Kaya, maaari mong i-load hindi lamang ang channel o server, kundi pati na rin ang mga indibidwal na bahagi ng application, halimbawa, mga database o file system. Maaari ka ring maghanap ng mga lugar sa site na gumagawa ng malalaking kalkulasyon: mga calculator, mga pahina ng pagpili ng produkto, atbp. Sa wakas, madalas na nangyayari na ang site ay may ilang uri ng PHP script na bumubuo ng isang pahina ng ilang daang libong linya. Ang ganitong script ay makabuluhang naglo-load sa server at maaaring maging target para sa isang pag-atake.
Kung saan hahanapin
Kapag nag-scan kami ng mapagkukunan bago ang pagsubok, tinitingnan muna namin, siyempre, ang mismong site. Naghahanap kami ng lahat ng uri ng mga input field, mabibigat na file - sa pangkalahatan, lahat ng bagay na maaaring lumikha ng mga problema para sa mapagkukunan at pabagalin ang operasyon nito. Ang mga tool sa pag-develop ng banal sa Google Chrome at Firefox ay tumutulong dito, na nagpapakita ng mga oras ng pagtugon sa page.
Nag-scan din kami ng mga subdomain. Halimbawa, mayroong isang partikular na online na tindahan, abc.com, at mayroon itong subdomain na admin.abc.com. Malamang, ito ay isang admin panel na may pahintulot, ngunit kung maglalagay ka ng load dito, maaari itong lumikha ng mga problema para sa pangunahing mapagkukunan.
Maaaring may subdomain na api.abc.com ang site. Malamang, ito ay isang mapagkukunan para sa mga mobile application. Ang application ay matatagpuan sa App Store o Google Play, mag-install ng isang espesyal na access point, i-dissect ang API at magrehistro ng mga test account. Ang problema ay madalas na iniisip ng mga tao na anumang bagay na protektado ng awtorisasyon ay immune sa pagtanggi sa mga pag-atake ng serbisyo. Kumbaga, ang pahintulot ay ang pinakamahusay na CAPTCHA, ngunit hindi. Madaling gumawa ng 10-20 pansubok na account, ngunit sa paggawa ng mga ito, nakakakuha kami ng access sa kumplikado at hindi nakikilalang functionality.
Naturally, tinitingnan namin ang kasaysayan, sa robots.txt at WebArchive, ViewDNS, at naghahanap ng mga lumang bersyon ng mapagkukunan. Minsan nangyayari na ang mga developer ay naglunsad, sabihin, mail2.yandex.net, ngunit ang lumang bersyon, mail.yandex.net, ay nananatili. Ang mail.yandex.net na ito ay hindi na suportado, ang mga mapagkukunan ng pag-unlad ay hindi inilalaan dito, ngunit patuloy itong kumonsumo ng database. Alinsunod dito, gamit ang lumang bersyon, mabisa mong magagamit ang mga mapagkukunan ng backend at lahat ng nasa likod ng layout. Siyempre, hindi ito palaging nangyayari, ngunit madalas pa rin kaming nakakaharap nito.
Naturally, sinusuri namin ang lahat ng mga parameter ng kahilingan at ang istraktura ng cookie. Maaari mong, sabihin, maglagay ng ilang halaga sa isang JSON array sa loob ng isang cookie, gumawa ng maraming nesting at gawin ang mapagkukunan sa loob ng hindi makatwirang mahabang panahon.
Paghahanap load
Ang unang bagay na pumapasok sa isip kapag nagsasaliksik ng isang site ay ang pag-load ng database, dahil halos lahat ay may paghahanap, at para sa halos lahat, sa kasamaang-palad, ito ay hindi gaanong protektado. Para sa ilang kadahilanan, hindi binibigyang pansin ng mga developer ang paghahanap. Ngunit mayroong isang rekomendasyon dito - hindi ka dapat gumawa ng mga kahilingan ng parehong uri, dahil maaari kang makatagpo ng pag-cache, tulad ng kaso sa HTTP flood.
Ang paggawa ng mga random na query sa database ay hindi rin palaging epektibo. Mas mainam na gumawa ng listahan ng mga keyword na may kaugnayan sa paghahanap. Kung babalik tayo sa halimbawa ng isang online na tindahan: sabihin nating nagbebenta ang site ng mga gulong ng kotse at pinapayagan kang itakda ang radius ng mga gulong, ang uri ng kotse at iba pang mga parameter. Alinsunod dito, ang mga kumbinasyon ng mga nauugnay na salita ay pipilitin ang database na gumana sa mas kumplikadong mga kondisyon.
Bilang karagdagan, ito ay nagkakahalaga ng paggamit ng pagination: mas mahirap para sa isang paghahanap na ibalik ang penultimate page ng mga resulta ng paghahanap kaysa sa una. Iyon ay, sa tulong ng pagination maaari mong bahagyang pag-iba-ibahin ang pag-load.
Ipinapakita ng halimbawa sa ibaba ang load ng paghahanap. Makikita na mula sa unang segundo ng pagsubok sa bilis na sampung kahilingan sa bawat segundo, bumaba ang site at hindi tumugon.
Kung walang paghahanap?
Kung walang paghahanap, hindi ito nangangahulugan na ang site ay hindi naglalaman ng iba pang mga vulnerable na input field. Ang field na ito ay maaaring awtorisasyon. Sa ngayon, ang mga developer ay gustong gumawa ng mga kumplikadong hash upang protektahan ang database ng pag-login mula sa isang rainbow table attack. Ito ay mabuti, ngunit ang gayong mga hash ay kumonsumo ng maraming mapagkukunan ng CPU. Ang isang malaking daloy ng mga maling pahintulot ay humahantong sa isang pagkabigo ng processor, at bilang isang resulta, ang site ay huminto sa paggana.
Ang pagkakaroon sa site ng lahat ng uri ng mga form para sa mga komento at feedback ay isang dahilan upang magpadala ng napakalaking mga teksto doon o lumikha lamang ng isang napakalaking baha. Kung minsan ang mga site ay tumatanggap ng mga naka-attach na file, kasama ang nasa gzip na format. Sa kasong ito, kumuha kami ng 1TB file, i-compress ito sa ilang byte o kilobytes gamit ang gzip at ipadala ito sa site. Pagkatapos ito ay i-unzip at isang napaka-kagiliw-giliw na epekto ay nakuha.
Pahinga ng API
Gusto kong bigyan ng kaunting pansin ang mga sikat na serbisyo gaya ng Rest API. Ang pag-secure ng Rest API ay mas mahirap kaysa sa isang regular na website. Kahit na ang maliit na paraan ng proteksyon laban sa password brute force at iba pang hindi lehitimong aktibidad ay hindi gumagana para sa Rest API.
Ang Rest API ay napakadaling masira dahil direktang ina-access nito ang database. Kasabay nito, ang pagkabigo ng naturang serbisyo ay nangangailangan ng medyo malubhang kahihinatnan para sa negosyo. Ang katotohanan ay ang Rest API ay karaniwang ginagamit hindi lamang para sa pangunahing website, kundi pati na rin para sa mobile application at ilang panloob na mapagkukunan ng negosyo. At kung ang lahat ng ito ay bumagsak, kung gayon ang epekto ay mas malakas kaysa sa kaso ng isang simpleng pagkabigo sa website.
Naglo-load ng mabibigat na nilalaman
Kung inaalok kami na subukan ang ilang ordinaryong single-page na application, landing page, o website ng business card na walang kumplikadong functionality, naghahanap kami ng mabibigat na content. Halimbawa, malalaking larawan na ipinapadala ng server, binary file, dokumentasyong pdf - sinusubukan naming i-download ang lahat ng ito. Ang ganitong mga pagsubok ay naglo-load ng maayos sa file system at nakakabara sa mga channel, at samakatuwid ay epektibo. Iyon ay, kahit na hindi mo ibinaba ang server, ang pag-download ng isang malaking file sa mababang bilis, ikaw ay barado lamang sa channel ng target na server at pagkatapos ay isang pagtanggi ng serbisyo ay magaganap.
Ang isang halimbawa ng naturang pagsubok ay nagpapakita na sa bilis na 30 RPS ang site ay huminto sa pagtugon o gumawa ng ika-500 na mga error sa server.
Huwag kalimutan ang tungkol sa pag-set up ng mga server. Madalas mong makita na ang isang tao ay bumili ng virtual machine, nag-install ng Apache doon, na-configure ang lahat bilang default, nag-install ng PHP application, at sa ibaba makikita mo ang resulta.
Dito napunta ang load sa ugat at umabot lamang ng 10 RPS. Naghintay kami ng 5 minuto at nag-crash ang server. Totoong hindi lubos na nalalaman kung bakit siya nahulog, ngunit mayroong isang palagay na siya ay nagkaroon lamang ng labis na memorya at samakatuwid ay tumigil sa pagtugon.
Batay sa alon
Sa nakaraang taon o dalawa, ang mga pag-atake ng alon ay naging napakapopular. Ito ay dahil sa katotohanan na maraming organisasyon ang bumibili ng ilang partikular na piraso ng hardware para sa proteksyon ng DDoS, na nangangailangan ng tiyak na tagal ng oras upang makaipon ng mga istatistika upang simulan ang pag-filter ng pag-atake. Iyon ay, hindi nila sinasala ang pag-atake sa unang 30-40 segundo, dahil nag-iipon sila ng data at natututo. Alinsunod dito, sa loob ng 30-40 segundong ito maaari kang maglunsad ng napakaraming site na ang mapagkukunan ay magsisinungaling nang mahabang panahon hanggang sa ma-clear ang lahat ng mga kahilingan.
Sa kaso ng pag-atake sa ibaba, mayroong pagitan ng 10 minuto, pagkatapos ay dumating ang isang bago, binagong bahagi ng pag-atake.
Iyon ay, natutunan ng depensa, nagsimulang mag-filter, ngunit dumating ang isang bago, ganap na naiibang bahagi ng pag-atake, at nagsimulang matuto muli ang depensa. Sa katunayan, ang pag-filter ay huminto sa paggana, ang proteksyon ay nagiging hindi epektibo, at ang site ay hindi magagamit.
Ang mga pag-atake ng alon ay nailalarawan sa pamamagitan ng napakataas na halaga sa tuktok, maaari itong umabot sa isang daang libo o isang milyong mga kahilingan sa bawat segundo, sa kaso ng L7. Kung pag-uusapan natin ang tungkol sa L3&4, maaaring mayroong daan-daang gigabits ng trapiko, o, nang naaayon, daan-daang mpps, kung bibilang ka sa mga packet.
Ang problema sa gayong mga pag-atake ay ang pag-synchronize. Ang mga pag-atake ay nagmula sa isang botnet at nangangailangan ng isang mataas na antas ng pag-synchronize upang lumikha ng isang napakalaking isang beses na spike. At ang koordinasyong ito ay hindi palaging gumagana: kung minsan ang output ay isang uri ng parabolic peak, na mukhang nakakalungkot.
Hindi nag-iisa ang HTTP
Bilang karagdagan sa HTTP sa L7, gusto naming pagsamantalahan ang iba pang mga protocol. Bilang isang patakaran, ang isang regular na website, lalo na ang isang regular na pagho-host, ay may mga protocol ng mail at MySQL na lumalabas. Ang mga mail protocol ay napapailalim sa mas kaunting pag-load kaysa sa mga database, ngunit maaari rin silang mai-load nang mahusay at magtatapos sa isang overload na CPU sa server.
Medyo matagumpay kami gamit ang 2016 SSH vulnerability. Ngayon ang kahinaan na ito ay naayos na para sa halos lahat, ngunit hindi ito nangangahulugan na ang pag-load ay hindi maaaring isumite sa SSH. Pwede. Mayroon lamang isang malaking pagkarga ng mga pahintulot, kinakain ng SSH ang halos buong CPU sa server, at pagkatapos ay nag-collapse ang website mula sa isa o dalawang kahilingan sa bawat segundo. Alinsunod dito, ang isa o dalawang kahilingang ito batay sa mga log ay hindi maaaring makilala sa isang lehitimong pagkarga.
Maraming koneksyon na binubuksan namin sa mga server ay nananatiling may kaugnayan din. Dati, ang Apache ay nagkasala nito, ngayon ang nginx ay talagang nagkasala nito, dahil ito ay madalas na naka-configure bilang default. Ang bilang ng mga koneksyon na maaaring panatilihing bukas ng nginx ay limitado, kaya binuksan namin ang bilang ng mga koneksyon, ang nginx ay hindi na tumatanggap ng isang bagong koneksyon, at bilang isang resulta ang site ay hindi gumagana.
Ang aming test cluster ay may sapat na CPU para atakehin ang SSL handshake. Sa prinsipyo, tulad ng ipinapakita ng kasanayan, minsan ay gustong gawin din ito ng mga botnet. Sa isang banda, malinaw na hindi mo magagawa nang walang SSL, dahil ang mga resulta ng Google, pagraranggo, seguridad. Sa kabilang banda, ang SSL sa kasamaang palad ay may isyu sa CPU.
L3&4
Kapag pinag-uusapan natin ang tungkol sa isang pag-atake sa mga antas ng L3&4, karaniwang pinag-uusapan natin ang tungkol sa isang pag-atake sa antas ng link. Ang ganitong pagkarga ay halos palaging nakikilala mula sa isang lehitimong isa, maliban kung ito ay isang SYN-flood attack. Ang problema sa SYN-flood attacks para sa mga tool sa seguridad ay ang kanilang malaking volume. Ang maximum na halaga ng L3&4 ay 1,5-2 Tbit/s. Ang ganitong uri ng trapiko ay napakahirap iproseso kahit para sa malalaking kumpanya, kabilang ang Oracle at Google.
Ang SYN at SYN-ACK ay mga packet na ginagamit kapag nagtatatag ng koneksyon. Samakatuwid, ang SYN-flood ay mahirap makilala mula sa isang lehitimong load: hindi malinaw kung ito ay isang SYN na dumating upang magtatag ng isang koneksyon, o bahagi ng isang baha.
UDP-baha
Karaniwan, ang mga umaatake ay walang mga kakayahan na mayroon kami, kaya ang amplification ay maaaring gamitin upang ayusin ang mga pag-atake. Ibig sabihin, ini-scan ng attacker ang Internet at nahahanap ang alinman sa mga vulnerable o hindi wastong na-configure na mga server na, halimbawa, bilang tugon sa isang SYN packet, tumugon sa tatlong SYN-ACK. Sa pamamagitan ng panggagaya sa source address mula sa address ng target na server, posibleng dagdagan ang kapangyarihan sa pamamagitan ng, halimbawa, tatlong beses gamit ang isang packet at i-redirect ang trapiko sa biktima.
Ang problema sa mga amplification ay mahirap silang matukoy. Kasama sa mga kamakailang halimbawa ang kahindik-hindik na kaso ng mahinang memcached. Dagdag pa, ngayon ay maraming mga IoT device, mga IP camera, na kadalasang naka-configure din bilang default, at bilang default, mali ang pagkaka-configure ng mga ito, kaya naman ang mga umaatake ay kadalasang gumagawa ng mga pag-atake sa pamamagitan ng mga naturang device.
Mahirap SYN-baha
Ang SYN-flood ay marahil ang pinakakawili-wiling uri ng pag-atake mula sa pananaw ng isang developer. Ang problema ay ang mga system administrator ay madalas na gumagamit ng IP blocking para sa proteksyon. Bukod dito, ang pag-block ng IP ay nakakaapekto hindi lamang sa mga tagapangasiwa ng system na kumikilos gamit ang mga script, ngunit din, sa kasamaang-palad, ang ilang mga sistema ng seguridad na binili para sa maraming pera.
Ang pamamaraang ito ay maaaring maging isang sakuna, dahil kung papalitan ng mga umaatake ang mga IP address, haharangin ng kumpanya ang sarili nitong subnet. Kapag hinarangan ng Firewall ang sarili nitong cluster, mabibigo ang output sa mga panlabas na pakikipag-ugnayan at mabibigo ang mapagkukunan.
Bukod dito, hindi mahirap i-block ang iyong sariling network. Kung ang opisina ng kliyente ay may Wi-Fi network, o kung ang pagganap ng mga mapagkukunan ay sinusukat gamit ang iba't ibang mga sistema ng pagsubaybay, pagkatapos ay kukunin namin ang IP address ng sistema ng pagsubaybay na ito o ang opisina ng Wi-Fi ng kliyente at ginagamit ito bilang isang mapagkukunan. Sa dulo, ang mapagkukunan ay tila magagamit, ngunit ang mga target na IP address ay naharang. Kaya, ang Wi-Fi network ng HighLoad conference, kung saan ipinakita ang bagong produkto ng kumpanya, ay maaaring ma-block, at nangangailangan ito ng ilang partikular na gastos sa negosyo at ekonomiya.
Sa panahon ng pagsubok, hindi kami maaaring gumamit ng amplification sa pamamagitan ng memcached sa anumang panlabas na mapagkukunan, dahil may mga kasunduan na magpadala lamang ng trapiko sa mga pinapayagang IP address. Alinsunod dito, gumagamit kami ng amplification sa pamamagitan ng SYN at SYN-ACK, kapag tumugon ang system sa pagpapadala ng isang SYN na may dalawa o tatlong SYN-ACK, at sa output ang pag-atake ay pinarami ng dalawa o tatlong beses.
Tools
Ang isa sa mga pangunahing tool na ginagamit namin para sa L7 workload ay Yandex-tank. Sa partikular, ang isang phantom ay ginagamit bilang isang baril, kasama ang ilang mga script para sa pagbuo ng mga cartridge at para sa pagsusuri ng mga resulta.
Ang Tcpdump ay ginagamit upang pag-aralan ang trapiko sa network, at ang Nmap ay ginagamit upang pag-aralan ang server. Upang lumikha ng pag-load sa antas ng L3&4, OpenSSL at kaunti sa aming sariling mahika sa DPDK library ay ginagamit. Ang DPDK ay isang library mula sa Intel na nagbibigay-daan sa iyong magtrabaho kasama ang interface ng network na lumalampas sa stack ng Linux, at sa gayon ay tumataas ang kahusayan. Naturally, gumagamit kami ng DPDK hindi lamang sa antas ng L3&4, kundi pati na rin sa antas ng L7, dahil nagbibigay-daan ito sa amin na lumikha ng napakataas na daloy ng pagkarga, sa loob ng hanay ng ilang milyong kahilingan bawat segundo mula sa isang makina.
Gumagamit din kami ng ilang partikular na generator ng trapiko at mga espesyal na tool na isinusulat namin para sa mga partikular na pagsubok. Kung aalalahanin natin ang kahinaan sa ilalim ng SSH, hindi maaaring samantalahin ang hanay sa itaas. Kung inaatake namin ang mail protocol, kumukuha kami ng mga mail utilities o sumusulat lang ng mga script sa mga ito.
Natuklasan
Bilang konklusyon, nais kong sabihin:
- Bilang karagdagan sa klasikong pagsusuri sa pagkarga, kinakailangan na magsagawa ng pagsubok sa stress. Mayroon kaming isang tunay na halimbawa kung saan ang subcontractor ng isang kasosyo ay nagsagawa lamang ng pagsubok sa pagkarga. Ipinakita nito na ang mapagkukunan ay makatiis sa normal na pagkarga. Ngunit pagkatapos ay lumitaw ang isang abnormal na pag-load, ang mga bisita sa site ay nagsimulang gumamit ng mapagkukunan nang medyo naiiba, at bilang isang resulta ang subcontractor ay humiga. Kaya, sulit na maghanap ng mga kahinaan kahit na protektado ka na mula sa mga pag-atake ng DDoS.
- Kinakailangang ihiwalay ang ilang bahagi ng system mula sa iba. Kung mayroon kang paghahanap, kailangan mong ilipat ito sa magkahiwalay na mga makina, iyon ay, hindi kahit sa Docker. Dahil kung nabigo ang paghahanap o awtorisasyon, hindi bababa sa isang bagay ay patuloy na gagana. Sa kaso ng isang online na tindahan, ang mga user ay patuloy na maghahanap ng mga produkto sa catalog, pumunta mula sa aggregator, bibili kung sila ay awtorisado na, o magpapahintulot sa pamamagitan ng OAuth2.
- Huwag pabayaan ang lahat ng uri ng mga serbisyo sa ulap.
- Gamitin ang CDN hindi lamang upang i-optimize ang mga pagkaantala sa network, ngunit bilang isang paraan din ng proteksyon laban sa mga pag-atake sa channel exhaustion at simpleng pagbaha sa static na trapiko.
- Kinakailangang gumamit ng mga espesyal na serbisyo sa proteksyon. Hindi mo mapoprotektahan ang iyong sarili mula sa mga pag-atake ng L3&4 sa antas ng channel, dahil malamang na wala kang sapat na channel. Malamang na hindi mo malalabanan ang mga pag-atake ng L7, dahil maaaring napakalaki ng mga ito. Dagdag pa, ang paghahanap para sa maliliit na pag-atake ay prerogative pa rin ng mga espesyal na serbisyo, mga espesyal na algorithm.
- Regular na mag-update. Nalalapat ito hindi lamang sa kernel, kundi pati na rin sa SSH daemon, lalo na kung bukas ang mga ito sa labas. Sa prinsipyo, ang lahat ay kailangang ma-update, dahil malamang na hindi mo masusubaybayan ang ilang mga kahinaan sa iyong sarili.
Pinagmulan: www.habr.com