Variti huendeleza ulinzi dhidi ya mashambulizi ya bots na DDoS, na pia hufanya dhiki na kupima mzigo. Katika mkutano wa HighLoad++ 2018 tulizungumza kuhusu jinsi ya kupata rasilimali kutoka kwa aina mbalimbali za mashambulizi. Kwa kifupi: tenga sehemu za mfumo, tumia huduma za wingu na CDN, na usasishe mara kwa mara. Lakini bado hutaweza kushughulikia ulinzi bila makampuni maalumu :)
Kabla ya kusoma maandishi, unaweza kusoma vifupisho vifupi .
Na ikiwa hupendi kusoma au unataka tu kutazama video, rekodi ya ripoti yetu iko chini ya mharibifu.
Kurekodi video ya ripoti hiyo
Makampuni mengi tayari yanajua jinsi ya kufanya upimaji wa mzigo, lakini si wote wanaofanya kupima matatizo. Baadhi ya wateja wetu wanafikiri kuwa tovuti yao haiwezi kuathiriwa kwa sababu wana mfumo wa upakiaji wa juu, na hulinda vyema dhidi ya mashambulizi. Tunaonyesha kwamba hii si kweli kabisa.
Bila shaka, kabla ya kufanya vipimo, tunapata ruhusa kutoka kwa mteja, iliyosainiwa na kupigwa muhuri, na kwa msaada wetu shambulio la DDoS haliwezi kufanywa kwa mtu yeyote. Upimaji unafanywa kwa wakati uliochaguliwa na mteja, wakati trafiki kwa rasilimali yake ni ndogo, na matatizo ya upatikanaji hayataathiri wateja. Kwa kuongeza, kwa kuwa kitu kinaweza kwenda vibaya wakati wa mchakato wa majaribio, tunawasiliana mara kwa mara na mteja. Hii hukuruhusu sio tu kuripoti matokeo yaliyopatikana, lakini pia kubadilisha kitu wakati wa majaribio. Baada ya kukamilika kwa majaribio, kila wakati tunatoa ripoti ambayo tunaashiria mapungufu yaliyotambuliwa na kutoa mapendekezo ya kuondoa udhaifu wa tovuti.
Jinsi tunavyofanya kazi
Wakati wa kupima, tunaiga botnet. Kwa kuwa tunafanya kazi na wateja ambao hawako kwenye mitandao yetu, ili kuhakikisha kuwa jaribio haliishii katika dakika ya kwanza kwa sababu ya mipaka au ulinzi unaoanzishwa, tunasambaza mzigo sio kutoka kwa IP moja, lakini kutoka kwa mtandao wetu mdogo. Zaidi ya hayo, ili kuunda mzigo mkubwa, tuna seva yetu wenyewe ya majaribio yenye nguvu.
Machapisho
Kupita kiasi haimaanishi mema
Mzigo mdogo tunaweza kuleta rasilimali kushindwa, bora zaidi. Ikiwa unaweza kufanya tovuti kuacha kufanya kazi kwa ombi moja kwa sekunde, au hata ombi moja kwa dakika, hiyo ni nzuri. Kwa sababu kulingana na sheria ya udhalimu, watumiaji au wavamizi wataangukia katika mazingira magumu haya kimakosa.
Kushindwa kwa sehemu ni bora kuliko kutofaulu kabisa
Tunashauri kila wakati kufanya mifumo kuwa tofauti. Kwa kuongezea, inafaa kuwatenganisha katika kiwango cha mwili, na sio tu kwa uwekaji wa vyombo. Katika kesi ya kujitenga kimwili, hata ikiwa kitu kinashindwa kwenye tovuti, kuna uwezekano mkubwa kwamba haitaacha kufanya kazi kabisa, na watumiaji wataendelea kupata angalau sehemu ya utendaji.
Usanifu mzuri ndio msingi wa uendelevu
Uvumilivu wa makosa ya rasilimali na uwezo wake wa kuhimili mashambulizi na mizigo inapaswa kuwekwa katika hatua ya kubuni, kwa kweli, katika hatua ya kuchora chati za kwanza kwenye daftari. Kwa sababu ikiwa makosa mabaya yanaingia, inawezekana kurekebisha katika siku zijazo, lakini ni vigumu sana.
Sio tu nambari inapaswa kuwa nzuri, lakini pia usanidi
Watu wengi wanafikiri kuwa timu nzuri ya maendeleo ni dhamana ya huduma inayostahimili makosa. Timu nzuri ya maendeleo ni muhimu sana, lakini lazima pia kuwe na uendeshaji mzuri, DevOps nzuri. Hiyo ni, tunahitaji wataalamu ambao watasanidi kwa usahihi Linux na mtandao, kuandika usanidi kwa usahihi katika nginx, kuweka mipaka, nk. Vinginevyo, rasilimali itafanya kazi vizuri tu katika kupima, na kwa wakati fulani kila kitu kitavunja katika uzalishaji.
Tofauti kati ya kupima mzigo na dhiki
Upimaji wa mzigo hukuruhusu kutambua mipaka ya utendaji wa mfumo. Upimaji wa mkazo unalenga kutafuta udhaifu katika mfumo na hutumiwa kuvunja mfumo huu na kuona jinsi utakavyofanya katika mchakato wa kushindwa kwa sehemu fulani. Katika kesi hiyo, asili ya mzigo kawaida hubakia haijulikani kwa mteja kabla ya kupima dhiki kuanza.
Vipengele tofauti vya mashambulizi ya L7
Kwa kawaida tunagawanya aina za mizigo katika viwango vya L7 na L3&4. L7 ni mzigo kwenye kiwango cha programu, mara nyingi inamaanisha HTTP tu, lakini tunamaanisha mzigo wowote katika kiwango cha itifaki ya TCP.
Mashambulizi ya L7 yana sifa fulani tofauti. Kwanza, wanakuja moja kwa moja kwenye programu, ambayo ni, hakuna uwezekano kwamba wataonyeshwa kupitia njia za mtandao. Mashambulizi hayo hutumia mantiki, na kutokana na hili, hutumia CPU, kumbukumbu, disk, database na rasilimali nyingine kwa ufanisi sana na kwa trafiki kidogo.
Mafuriko ya HTTP
Katika kesi ya mashambulizi yoyote, mzigo ni rahisi kuunda kuliko kushughulikia, na katika kesi ya L7 hii pia ni kweli. Si rahisi kila wakati kutofautisha trafiki ya shambulio kutoka kwa trafiki halali, na mara nyingi hii inaweza kufanywa kwa mzunguko, lakini ikiwa kila kitu kimepangwa kwa usahihi, basi haiwezekani kuelewa kutoka kwa magogo ambapo shambulio liko na wapi maombi halali.
Kama mfano wa kwanza, zingatia shambulio la Mafuriko ya HTTP. Grafu inaonyesha kuwa mashambulizi kama hayo kawaida huwa na nguvu sana; katika mfano hapa chini, idadi ya juu ya maombi ilizidi elfu 600 kwa dakika.
Mafuriko ya HTTP ndiyo njia rahisi zaidi ya kuunda mzigo. Kwa kawaida, inachukua aina fulani ya zana ya kupima upakiaji, kama vile ApacheBench, na kuweka ombi na lengo. Kwa njia rahisi kama hiyo, kuna uwezekano mkubwa wa kukimbia kwenye caching ya seva, lakini ni rahisi kuipita. Kwa mfano, kuongeza masharti ya nasibu kwa ombi, ambayo italazimisha seva kutumikia ukurasa mpya kila wakati.
Pia, usisahau kuhusu wakala wa mtumiaji katika mchakato wa kuunda mzigo. Mawakala wengi wa watumiaji wa zana maarufu za kupima huchujwa na wasimamizi wa mfumo, na katika kesi hii mzigo hauwezi kufikia tu nyuma. Unaweza kuboresha matokeo kwa kiasi kikubwa kwa kuingiza kichwa halali zaidi au kidogo kutoka kwa kivinjari kwenye ombi.
Rahisi kama vile mashambulizi ya Mafuriko ya HTTP yalivyo, pia yana mapungufu yao. Kwanza, kiasi kikubwa cha nguvu kinahitajika kuunda mzigo. Pili, mashambulizi kama haya ni rahisi sana kugundua, haswa ikiwa yanatoka kwa anwani moja. Kama matokeo, maombi huanza kuchujwa mara moja na wasimamizi wa mfumo au hata katika kiwango cha mtoaji.
Nini cha kutafuta
Ili kupunguza idadi ya maombi kwa sekunde bila kupoteza ufanisi, unahitaji kuonyesha mawazo kidogo na kuchunguza tovuti. Kwa hivyo, unaweza kupakia sio tu chaneli au seva, lakini pia sehemu za kibinafsi za programu, kwa mfano, hifadhidata au mifumo ya faili. Unaweza pia kutafuta maeneo kwenye tovuti ambayo hufanya mahesabu makubwa: calculators, kurasa za uteuzi wa bidhaa, nk. Hatimaye, mara nyingi hutokea kwamba tovuti ina aina fulani ya hati ya PHP ambayo hutoa ukurasa wa mistari laki kadhaa. Hati kama hiyo pia hupakia seva kwa kiasi kikubwa na inaweza kuwa lengo la shambulio.
Mahali pa kuangalia
Tunapochanganua rasilimali kabla ya kujaribu, kwanza tunaangalia, bila shaka, kwenye tovuti yenyewe. Tunatafuta kila aina ya mashamba ya pembejeo, faili nzito - kwa ujumla, kila kitu ambacho kinaweza kuunda matatizo kwa rasilimali na kupunguza kasi ya uendeshaji wake. Zana za ukuzaji banal katika Google Chrome na Firefox husaidia hapa, kuonyesha nyakati za majibu ya ukurasa.
Pia tunachanganua vikoa vidogo. Kwa mfano, kuna duka fulani la mtandaoni, abc.com, na lina kikoa kidogo admin.abc.com. Uwezekano mkubwa zaidi, hii ni jopo la admin na idhini, lakini ikiwa unaweka mzigo juu yake, inaweza kuunda matatizo kwa rasilimali kuu.
Tovuti inaweza kuwa na kikoa kidogo api.abc.com. Uwezekano mkubwa zaidi, hii ni rasilimali ya programu za rununu. Programu inaweza kupatikana katika Duka la Programu au Google Play, sakinisha kituo maalum cha kufikia, tenga API na usajili akaunti za majaribio. Tatizo ni kwamba watu mara nyingi hufikiri kwamba kitu chochote ambacho kinalindwa na idhini hakiwezi kunyimwa mashambulizi ya huduma. Eti, idhini ndiyo CAPTCHA bora zaidi, lakini sivyo. Ni rahisi kutengeneza akaunti 10-20 za majaribio, lakini kwa kuziunda, tunapata ufikiaji wa utendakazi changamano na usiofichwa.
Kwa kawaida, tunaangalia historia, katika robots.txt na WebArchive, ViewDNS, na kutafuta matoleo ya zamani ya rasilimali. Wakati mwingine hutokea kwamba watengenezaji wamejitokeza, sema, mail2.yandex.net, lakini toleo la zamani, mail.yandex.net, linabaki. Barua hii ya mail.yandex.net haitumiki tena, rasilimali za maendeleo hazijatengwa kwake, lakini inaendelea kutumia hifadhidata. Ipasavyo, kwa kutumia toleo la zamani, unaweza kutumia kwa ufanisi rasilimali za nyuma na kila kitu kilicho nyuma ya mpangilio. Kwa kweli, hii haifanyiki kila wakati, lakini bado tunakutana na hii mara nyingi.
Kwa kawaida, tunachambua vigezo vyote vya ombi na muundo wa kuki. Unaweza, sema, kutupa thamani fulani kwenye safu ya JSON ndani ya kidakuzi, kuunda viota vingi na kufanya rasilimali ifanye kazi kwa muda mrefu bila sababu.
Tafuta mzigo
Jambo la kwanza linalokuja akilini wakati wa kutafiti tovuti ni kupakia hifadhidata, kwani karibu kila mtu ana utaftaji, na kwa karibu kila mtu, kwa bahati mbaya, inalindwa vibaya. Kwa sababu fulani, watengenezaji hawazingatii vya kutosha kutafuta. Lakini kuna pendekezo moja hapa - haupaswi kufanya maombi ya aina sawa, kwa sababu unaweza kukutana na caching, kama ilivyo kwa mafuriko ya HTTP.
Kuuliza maswali nasibu kwenye hifadhidata pia sio kazi kila wakati. Ni bora zaidi kuunda orodha ya maneno muhimu ambayo yanafaa kwa utafutaji. Ikiwa tunarudi kwenye mfano wa duka la mtandaoni: hebu sema tovuti inauza matairi ya gari na inakuwezesha kuweka radius ya matairi, aina ya gari na vigezo vingine. Ipasavyo, mchanganyiko wa maneno husika utalazimisha hifadhidata kufanya kazi katika hali ngumu zaidi.
Kwa kuongeza, inafaa kutumia pagination: ni ngumu zaidi kwa utaftaji kurudisha ukurasa wa mwisho wa matokeo ya utaftaji kuliko ule wa kwanza. Hiyo ni, kwa msaada wa pagination unaweza kubadilisha mzigo kidogo.
Mfano hapa chini unaonyesha mzigo wa utafutaji. Inaweza kuonekana kuwa kutoka kwa pili ya kwanza ya mtihani kwa kasi ya maombi kumi kwa pili, tovuti ilishuka na haikujibu.
Ikiwa hakuna utafutaji?
Ikiwa hakuna utafutaji, hii haimaanishi kuwa tovuti haina sehemu zingine zinazoweza kuathirika. Sehemu hii inaweza kuwa idhini. Siku hizi, wasanidi programu wanapenda kutengeneza heshi changamano ili kulinda hifadhidata ya kuingia kutokana na shambulio la jedwali la upinde wa mvua. Hii ni nzuri, lakini heshi kama hizo hutumia rasilimali nyingi za CPU. Mtiririko mkubwa wa idhini ya uwongo husababisha kutofaulu kwa processor, na kwa sababu hiyo, tovuti huacha kufanya kazi.
Uwepo kwenye tovuti ya kila aina ya fomu za maoni na maoni ni sababu ya kutuma maandiko makubwa sana huko au tu kuunda mafuriko makubwa. Wakati mwingine tovuti hukubali faili zilizoambatishwa, ikiwa ni pamoja na katika umbizo la gzip. Katika kesi hii, tunachukua faili ya 1TB, itapunguza kwa byte kadhaa au kilobytes kwa kutumia gzip na kuituma kwenye tovuti. Kisha haijafunguliwa na athari ya kuvutia sana inapatikana.
Pumzika API
Ningependa kuzingatia kidogo huduma maarufu kama API ya Rest. Kupata API ya kupumzika ni ngumu zaidi kuliko tovuti ya kawaida. Hata mbinu ndogo za ulinzi dhidi ya nguvu ya kikatili ya nenosiri na shughuli nyingine zisizo halali hazifanyi kazi kwa API ya Mapumziko.
API ya mapumziko ni rahisi sana kuvunja kwa sababu inapata hifadhidata moja kwa moja. Wakati huo huo, kutofaulu kwa huduma kama hiyo kunajumuisha athari mbaya kwa biashara. Ukweli ni kwamba API ya mapumziko kawaida hutumiwa sio tu kwa wavuti kuu, bali pia kwa programu ya rununu na rasilimali zingine za ndani za biashara. Na ikiwa yote haya yanaanguka, basi athari ni nguvu zaidi kuliko katika kesi ya kushindwa kwa tovuti rahisi.
Inapakia maudhui mazito
Ikiwa tutapewa kujaribu programu ya kawaida ya ukurasa mmoja, ukurasa wa kutua, au tovuti ya kadi ya biashara ambayo haina utendakazi changamano, tunatafuta maudhui mazito. Kwa mfano, picha kubwa ambazo seva hutuma, faili za binary, nyaraka za pdf - tunajaribu kupakua yote haya. Vipimo vile hupakia mfumo wa faili vizuri na kuziba njia, na kwa hiyo zinafaa. Hiyo ni, hata ikiwa hautaweka seva chini, kupakua faili kubwa kwa kasi ya chini, utaziba tu kituo cha seva inayolengwa na kisha kukataliwa kwa huduma kutatokea.
Mfano wa mtihani kama huo unaonyesha kuwa kwa kasi ya 30 RPS tovuti iliacha kujibu au kutoa makosa 500 ya seva.
Usisahau kuhusu kusanidi seva. Mara nyingi unaweza kupata kwamba mtu alinunua mashine ya kawaida, aliweka Apache huko, alisanidi kila kitu kwa default, aliweka programu ya PHP, na chini unaweza kuona matokeo.
Hapa mzigo ulikwenda kwenye mzizi na ulifikia RPS 10 tu. Tulisubiri dakika 5 na seva ikaanguka. Ni kweli kwamba haijulikani kabisa kwa nini alianguka, lakini kuna dhana kwamba alikuwa na kumbukumbu nyingi na kwa hiyo aliacha kujibu.
Msingi wa wimbi
Katika mwaka mmoja au miwili iliyopita, mashambulizi ya mawimbi yamekuwa maarufu sana. Hii ni kutokana na ukweli kwamba mashirika mengi hununua vipande fulani vya vifaa kwa ajili ya ulinzi wa DDoS, ambayo inahitaji kiasi fulani cha muda kukusanya takwimu ili kuanza kuchuja mashambulizi. Hiyo ni, hawana kuchuja mashambulizi katika sekunde 30-40 za kwanza, kwa sababu hukusanya data na kujifunza. Ipasavyo, katika sekunde hizi 30-40 unaweza kuzindua sana kwenye wavuti kwamba rasilimali italala kwa muda mrefu hadi maombi yote yamefutwa.
Katika kesi ya shambulio hapa chini, kulikuwa na muda wa dakika 10, baada ya hapo sehemu mpya, iliyorekebishwa ya shambulio hilo ilifika.
Hiyo ni, ulinzi ulijifunza, ulianza kuchuja, lakini sehemu mpya, tofauti kabisa ya shambulio ilifika, na ulinzi ulianza kujifunza tena. Kwa kweli, uchujaji huacha kufanya kazi, ulinzi unakuwa haufanyi kazi, na tovuti haipatikani.
Mashambulizi ya mawimbi yana sifa ya maadili ya juu sana kwenye kilele, inaweza kufikia maombi laki moja au milioni kwa sekunde, katika kesi ya L7. Ikiwa tunazungumza juu ya L3&4, basi kunaweza kuwa na mamia ya gigabits ya trafiki, au, ipasavyo, mamia ya mpps, ikiwa utahesabu katika pakiti.
Tatizo la mashambulizi hayo ni maingiliano. Mashambulizi hutoka kwenye botnet na yanahitaji kiwango cha juu cha ulandanishi ili kuunda spike kubwa sana ya wakati mmoja. Na uratibu huu haufanyi kazi kila wakati: wakati mwingine matokeo ni aina fulani ya kilele cha parabolic, ambacho kinaonekana kuwa cha kusikitisha.
Sio HTTP pekee
Kando na HTTP katika L7, tunapenda kutumia itifaki zingine. Kama sheria, tovuti ya kawaida, haswa mwenyeji wa kawaida, ina itifaki za barua na MySQL inabaki nje. Itifaki za barua ziko chini ya upakiaji mdogo kuliko hifadhidata, lakini pia zinaweza kupakiwa kwa ufanisi kabisa na kuishia na CPU iliyojaa kwenye seva.
Tulifaulu kwa kutumia athari ya SSH ya 2016. Sasa athari hii imerekebishwa kwa karibu kila mtu, lakini hii haimaanishi kuwa mzigo hauwezi kuwasilishwa kwa SSH. Je! Kuna mzigo mkubwa wa uidhinishaji, SSH hula karibu CPU nzima kwenye seva, na kisha tovuti huanguka kutoka kwa ombi moja au mbili kwa sekunde. Ipasavyo, maombi haya moja au mawili kulingana na magogo hayawezi kutofautishwa na mzigo halali.
Miunganisho mingi tunayofungua kwenye seva pia inabaki kuwa muhimu. Hapo awali, Apache alikuwa na hatia ya hii, sasa nginx ina hatia ya hii, kwani mara nyingi husanidiwa kwa chaguo-msingi. Idadi ya miunganisho ambayo nginx inaweza kuweka wazi ni mdogo, kwa hivyo tunafungua nambari hii ya viunganisho, nginx haikubali tena muunganisho mpya, na kwa sababu hiyo tovuti haifanyi kazi.
Kundi letu la majaribio lina CPU ya kutosha kushambulia kupeana mkono kwa SSL. Kimsingi, kama inavyoonyesha mazoezi, boti wakati mwingine hupenda kufanya hivi pia. Kwa upande mmoja, ni wazi kwamba huwezi kufanya bila SSL, kwa sababu matokeo ya Google, cheo, usalama. Kwa upande mwingine, SSL kwa bahati mbaya ina suala la CPU.
L3&4
Tunapozungumza juu ya shambulio katika viwango vya L3&4, kwa kawaida tunazungumza juu ya shambulio katika kiwango cha kiungo. Mzigo kama huo karibu kila wakati unaweza kutofautishwa na ule ulio halali, isipokuwa ikiwa ni shambulio la mafuriko ya SYN. Tatizo la mashambulizi ya mafuriko ya SYN kwa zana za usalama ni kiasi chao kikubwa. Thamani ya juu ya L3&4 ilikuwa 1,5-2 Tbit/s. Aina hii ya trafiki ni ngumu sana kuchakata hata kwa makampuni makubwa, ikiwa ni pamoja na Oracle na Google.
SYN na SYN-ACK ni pakiti zinazotumika wakati wa kuanzisha muunganisho. Kwa hiyo, SYN-mafuriko ni vigumu kutofautisha kutoka kwa mzigo halali: haijulikani ikiwa hii ni SYN iliyokuja kuanzisha uhusiano, au sehemu ya mafuriko.
UDP-mafuriko
Kwa kawaida, washambuliaji hawana uwezo tulionao, kwa hivyo ukuzaji unaweza kutumiwa kupanga mashambulizi. Hiyo ni, mshambuliaji huchanganua Mtandao na kupata seva zilizo hatarini au zilizosanidiwa vibaya ambazo, kwa mfano, kwa kujibu pakiti moja ya SYN, hujibu na SYN-ACK tatu. Kwa kuharibu anwani ya chanzo kutoka kwa anwani ya seva inayolengwa, inawezekana kuongeza nguvu kwa, sema, mara tatu na pakiti moja na kuelekeza trafiki kwa mhasiriwa.
Tatizo la amplifications ni kwamba ni vigumu kutambua. Mifano ya hivi majuzi ni pamoja na kisa cha kustaajabisha cha watu walio katika mazingira magumu walionakiliwa. Pamoja, sasa kuna vifaa vingi vya IoT, kamera za IP, ambazo pia zimeundwa zaidi na chaguo-msingi, na kwa chaguo-msingi zimeundwa vibaya, ndiyo sababu washambuliaji mara nyingi hufanya mashambulizi kupitia vifaa vile.
Ngumu SYN-mafuriko
SYN-mafuriko pengine ndiyo aina ya mashambulizi ya kuvutia zaidi kutoka kwa mtazamo wa msanidi programu. Tatizo ni kwamba wasimamizi wa mfumo mara nyingi hutumia kuzuia IP kwa ulinzi. Zaidi ya hayo, kuzuia IP huathiri tu wasimamizi wa mfumo wanaofanya kwa kutumia maandiko, lakini pia, kwa bahati mbaya, baadhi ya mifumo ya usalama ambayo inunuliwa kwa pesa nyingi.
Njia hii inaweza kugeuka kuwa maafa, kwa sababu ikiwa washambuliaji watabadilisha anwani za IP, kampuni itazuia subnet yake mwenyewe. Firewall inapozuia nguzo yake yenyewe, matokeo yatashindwa mwingiliano wa nje na rasilimali itashindwa.
Aidha, si vigumu kuzuia mtandao wako mwenyewe. Ikiwa ofisi ya mteja ina mtandao wa Wi-Fi, au ikiwa utendaji wa rasilimali unapimwa kwa kutumia mifumo mbalimbali ya ufuatiliaji, basi tunachukua anwani ya IP ya mfumo huu wa ufuatiliaji au ofisi ya mteja Wi-Fi na kuitumia kama chanzo. Mwishoni, rasilimali inaonekana inapatikana, lakini anwani za IP zinazolengwa zimezuiwa. Kwa hivyo, mtandao wa Wi-Fi wa mkutano wa HighLoad, ambapo bidhaa mpya ya kampuni inawasilishwa, inaweza kuzuiwa, na hii inajumuisha gharama fulani za biashara na kiuchumi.
Wakati wa majaribio, hatuwezi kutumia ukuzaji kupitia memcached na rasilimali yoyote ya nje, kwa sababu kuna makubaliano ya kutuma trafiki tu kwa anwani za IP zinazoruhusiwa. Ipasavyo, tunatumia ukuzaji kupitia SYN na SYN-ACK, wakati mfumo unajibu kutuma SYN moja na SYN-ACK mbili au tatu, na kwa pato shambulio linazidishwa mara mbili au tatu.
Vyombo vya
Moja ya zana kuu tunazotumia kwa mzigo wa kazi wa L7 ni Yandex-tank. Hasa, phantom hutumiwa kama bunduki, pamoja na kuna maandishi kadhaa ya kutengeneza cartridges na kuchambua matokeo.
Tcpdump inatumika kuchanganua trafiki ya mtandao, na Nmap inatumiwa kuchanganua seva. Ili kuunda mzigo katika kiwango cha L3&4, OpenSSL na uchawi wetu mdogo na maktaba ya DPDK hutumiwa. DPDK ni maktaba kutoka kwa Intel ambayo hukuruhusu kufanya kazi na kiolesura cha mtandao kwa kupita mrundikano wa Linux, na hivyo kuongeza ufanisi. Kwa kawaida, tunatumia DPDK sio tu kwa kiwango cha L3 & 4, lakini pia katika kiwango cha L7, kwa sababu inatuwezesha kuunda mtiririko wa juu sana wa mzigo, ndani ya maombi ya milioni kadhaa kwa pili kutoka kwa mashine moja.
Pia tunatumia jenereta fulani za trafiki na zana maalum ambazo tunaandika kwa majaribio mahususi. Ikiwa tutakumbuka kuathirika kwa SSH, basi seti iliyo hapo juu haiwezi kutumiwa. Ikiwa tutashambulia itifaki ya barua, tunachukua huduma za barua au tu kuandika hati juu yao.
Matokeo
Kama hitimisho ningependa kusema:
- Mbali na upimaji wa mzigo wa classic, ni muhimu kufanya upimaji wa dhiki. Tuna mfano halisi ambapo mkandarasi mdogo wa mshirika alifanya majaribio ya upakiaji pekee. Ilionyesha kuwa rasilimali inaweza kuhimili mzigo wa kawaida. Lakini basi mzigo usio wa kawaida ulionekana, wageni wa tovuti walianza kutumia rasilimali tofauti kidogo, na kwa sababu hiyo mkandarasi mdogo alilala. Kwa hivyo, inafaa kutafuta udhaifu hata kama tayari umelindwa kutokana na mashambulizi ya DDoS.
- Ni muhimu kutenganisha baadhi ya sehemu za mfumo kutoka kwa wengine. Ikiwa una utaftaji, unahitaji kuihamisha kwa mashine tofauti, ambayo ni, hata kwa Docker. Kwa sababu ikiwa utafutaji au idhini itashindwa, angalau kitu kitaendelea kufanya kazi. Kwa upande wa duka la mtandaoni, watumiaji wataendelea kupata bidhaa katika katalogi, kutoka kwa kikokoteni, kununua ikiwa tayari zimeidhinishwa, au kuidhinisha kupitia OAuth2.
- Usipuuze kila aina ya huduma za wingu.
- Tumia CDN sio tu kuboresha ucheleweshaji wa mtandao, lakini pia kama njia ya ulinzi dhidi ya mashambulio ya uchovu wa chaneli na mafuriko kwenye trafiki tuli.
- Ni muhimu kutumia huduma maalum za ulinzi. Huwezi kujilinda kutokana na mashambulizi ya L3&4 katika kiwango cha kituo, kwa sababu kuna uwezekano mkubwa kwamba huna chaneli ya kutosha. Pia huna uwezekano wa kupigana na mashambulizi ya L7, kwa kuwa yanaweza kuwa makubwa sana. Zaidi ya hayo, utafutaji wa mashambulizi madogo bado ni haki ya huduma maalum, algorithms maalum.
- Sasisha mara kwa mara. Hii inatumika sio tu kwa kernel, lakini pia kwa daemon ya SSH, haswa ikiwa unayo wazi kwa nje. Kimsingi, kila kitu kinahitaji kusasishwa, kwa sababu hakuna uwezekano wa kuwa na uwezo wa kufuatilia udhaifu fulani peke yako.
Chanzo: mapenzi.com