Variti parastina li dijî bot û êrîşên DDoS pêşve dike, û di heman demê de ceribandina stres û barkirinê jî dike. Di konferansa HighLoad ++ 2018 de me li ser çawaniya ewlekariya çavkaniyan ji cûrbecûr êrîşan axivî. Bi kurtasî: parçeyên pergalê veqetînin, karûbarên cloud û CDN bikar bînin, û bi rêkûpêk nûve bikin. Lê dîsa jî hûn ê nikaribin bêyî pargîdaniyên pispor parastinê bikin :)
Berî xwendina nivîsê, hûn dikarin kurtenivîsên kurt bixwînin .
Û heke hûn ji xwendinê hez nakin an tenê dixwazin vîdyoyê temaşe bikin, tomarkirina raporta me li jêr di binê spoilerê de ye.
Tomarkirina vîdyoyê ya raporê
Pir pargîdanî jixwe dizanin meriv çawa ceribandina barkirinê dikin, lê ne hemî ceribandina stresê dikin. Hin xerîdarên me difikirin ku malpera wan bêserûber e ji ber ku pergalek wan a bilind heye, û ew ji êrîşan baş diparêze. Em nîşan didin ku ev bi tevahî ne rast e.
Bê guman, berî ku em ceribandinan bikin, em ji xerîdar destûr, îmze û mohrkirî digirin û bi alîkariya me êrîşek DDoS li ser kesek nayê kirin. Testkirin di demek ku ji hêla xerîdar ve hatî hilbijartin de, dema ku seyrûsefera çavkaniya wî hindik e, û pirsgirêkên gihîştinê dê bandorê li ser xerîdaran neke. Wekî din, ji ber ku di pêvajoya ceribandinê de her gav tiştek xelet dibe, têkiliya me ya domdar bi xerîdar re heye. Ev dihêle hûn ne tenê encamên ku hatine bidestxistin rapor bikin, lê di heman demê de di dema ceribandinê de jî tiştek biguhezînin. Piştî qedandina ceribandinê, em her gav raporek amade dikin ku tê de kêmasiyên ku hatine tespît kirin destnîşan dikin û ji bo rakirina qelsiyên malperê pêşniyaran didin.
Em çawa dixebitin
Dema ceribandinê, em botnetek emilînin. Ji ber ku em bi xerîdarên ku ne li ser torên me ne re dixebitin, ji bo ku em pê ewle bibin ku ceribandin di deqeya yekem de ji ber sînor an parastinê ku tê dest pê kirin bi dawî nebe, em barkirinê ne ji yek IP-yê, lê ji jêrtora xwe peyda dikin. Zêdetir, ji bo ku barek girîng biafirînin, me servera xweya ceribandinê ya pir bi hêz heye.
Postulates
Pir zêde nayê wateya baş
Kêm barê ku em dikarin çavkaniyek têkçûnê bînin, çêtir e. Ger hûn dikarin bihêlin ku malper li ser yek daxwazek her çirkeyê, an jî yek daxwazek di her hûrdemê de bisekine, ew pir baş e. Ji ber ku li gorî zagona nefsbiçûkiyê, bikarhêner an êrîşkar dê bi xeletî têkeve vê qelsiya taybetî.
Têkçûna qismî ji têkçûna tam çêtir e
Em her gav şîret dikin ku pergalên heterojen çêbikin. Digel vê yekê, hêja ye ku wan di asta laşî de veqetînin, û ne tenê bi konteynirkirinê. Di bûyera veqetandina laşî de, her çend tiştek li ser malperê têk nebe, îhtîmalek mezin heye ku ew ê bi tevahî dest ji xebata xwe bernede, û bikarhêner dê bi kêmî ve beşek ji fonksiyonê bigihîjin destkeftiyên xwe.
Mîmariya baş bingeha domdariyê ye
Tolerasyona xeletiya çavkaniyekê û şiyana wê ya li hember êrîş û bargiraniyê divê di qonaxa sêwiranê de were danîn, bi rastî, di qonaxa xêzkirina nexşeyên pêşîn ên di notepad de. Ji ber ku eger xeletiyên kujer bikevin hundir, di pêşerojê de rastkirina wan mimkun e, lê pir dijwar e.
Divê ne tenê kod baş be, lê di heman demê de konfigurasyon jî
Gelek kes difikirin ku tîmek pêşkeftina baş garantiya karûbarê xelet-tolerant e. Tîmek pêşkeftina baş bi rastî hewce ye, lê divê operasyonên baş, DevOpsên baş jî hebin. Ango, em hewceyê pisporên ku dê Linux û torê rast mîheng bikin, konfigurasyonan di nginx de rast binivîsin, sînoran destnîşan bikin, hwd. Wekî din, çavkanî dê tenê di ceribandinê de baş bixebite, û di deverek de dê her tişt di hilberînê de têk bibe.
Cûdahî di navbera ceribandina barkêş û stresê de
Testkirina barkirinê dihêle hûn sînorên xebata pergalê nas bikin. Testkirina stresê bi mebesta dîtina qelsiyên di pergalê de ye û ji bo şikandina vê pergalê û dîtina ku ew ê di pêvajoya têkçûna hin beşan de çawa tevbigere tê bikar anîn. Di vê rewşê de, cewherê barkirinê bi gelemperî ji xerîdar re nenas dimîne berî ku ceribandina stresê dest pê bike.
Taybetmendiyên cûda yên êrîşên L7
Em bi gelemperî celebên barkirinê di asta L7 û L3&4 de li bargiraniyê dabeş dikin. L7 di asta serîlêdanê de barkirinek e, pir caran ew tenê tê wateya HTTP, lê em wateya her barkirinê di asta protokola TCP de ye.
Êrîşên L7 hin taybetmendiyên cihêreng hene. Pêşîn, ew rasterast têne ser serîlêdanê, ango, ne mimkûn e ku ew bi rêgezên torê ve bêne xuyang kirin. Êrîşên bi vî rengî mantiqê bikar tînin, û ji ber vê yekê, ew CPU, bîranîn, dîsk, databas û çavkaniyên din pir bi bandor û bi seyrûseferek hindik dixwin.
HTTP Flood
Di bûyera her êrîşê de, çêkirina bar ji hilgirtinê hêsantir e, û di doza L7 de jî ev rast e. Cûdakirina seyrûsefera êrîşê ji seyrûsefera rewa her gav ne hêsan e, û pir caran ev dikare ji hêla frekansê ve were kirin, lê heke her tişt bi rêkûpêk were plansaz kirin, wê hingê ne mimkûn e ku ji qeydan were fam kirin ku êrîş li ku ye û daxwazên rewa li ku ne.
Wekî mînakek yekem, êrîşek HTTP Flood bifikirin. Grafîk nîşan dide ku êrîşên bi vî rengî bi gelemperî pir bi hêz in; Di mînaka jêrîn de, hejmara lûtkeya daxwaziyan ji 600 hezarî di hûrdemê de derbas kir.
HTTP Flood awayê herî hêsan e ku meriv barkirinê biafirîne. Bi gelemperî, ew cûreyek amûrek ceribandina barkirinê digire, wekî ApacheBench, û daxwazek û armancek destnîşan dike. Bi nêzîkatiyek wusa hêsan, îhtîmalek mezin heye ku meriv di cachkirina serverê de bixebite, lê ew hêsan e ku meriv jê derbas bike. Mînakî, lêzêdekirina rêzikên bêserûber li daxwazê , ku dê server neçar bike ku bi domdarî rûpelek nû xizmet bike.
Di heman demê de, di pêvajoya afirandina barkirinê de bikarhêner-agent ji bîr nekin. Gelek bikarhêner-ajanên amûrên ceribandinê yên populer ji hêla rêveberên pergalê ve têne fîlter kirin, û di vê rewşê de dibe ku bar bi hêsanî negihîje piştê. Hûn dikarin bi xistina sernavek kêm an zêde derbasdar ji gerokê di nav daxwazê de encamê bi girîngî baştir bikin.
Êrîşên HTTP Flood çiqas hêsan in, kêmasiyên wan jî hene. Pêşîn, mîqdarên mezin ên hêzê hewce ne ku barkirinê çêbikin. Ya duyemîn, êrîşên weha pir hêsan in ku werin tespît kirin, nemaze heke ew ji yek navnîşan têne. Wekî encamek, daxwaz tavilê dest bi fîlterkirinê dikin an ji hêla rêveberên pergalê ve an jî di asta pêşkêşker de.
I digerin
Ji bo kêmkirina hejmara daxwazan di çirkeyê de bêyî ku karbidestiyê winda bike, hûn hewce ne ku piçek xeyalek nîşan bidin û malperê bigerin. Bi vî rengî, hûn dikarin ne tenê kanal an serverê, lê di heman demê de beşên kesane yên serîlêdanê jî bar bikin, mînakî databas an pergalên pelan. Her weha hûn dikarin li cîhên ku hesabên mezin dikin li ser malperê bigerin: hesabker, rûpelên hilbijartina hilberê, hwd. Di dawiyê de, pir caran diqewime ku malper xwedan celebek nivîsarek PHP-ê ye ku rûpelek çend sed hezar rêzikan çêdike. Skrîptek wusa jî bi girîngî serverê bar dike û dikare bibe armancek ji bo êrîşê.
Li ku derê digerin
Gava ku em çavkaniyek berî ceribandinê dişoxilînin, em pêşî, bê guman, li malperê bixwe dinêrin. Em li her cûre zeviyên têketinê, pelên giran digerin - bi gelemperî, her tiştê ku dikare ji bo çavkaniyê pirsgirêkan biafirîne û xebata wê hêdî bike. Amûrên pêşkeftina banal ên di Google Chrome û Firefox-ê de li vir dibin alîkar, demên bersivdana rûpelê destnîşan dikin.
Em di heman demê de subdomanan jî dişoxilînin. Mînakî, hin firotgehek serhêl heye, abc.com, û subdomainek wê heye admin.abc.com. Bi îhtîmalek mezin, ev panelek rêveberiyê ya bi destûr e, lê heke hûn barek lê bidin, ew dikare ji bo çavkaniya sereke pirsgirêkan biafirîne.
Dibe ku malper xwedan subdomainek api.abc.com be. Bi îhtîmalek mezin, ev çavkaniyek ji bo serîlêdanên mobîl e. Serlêdan dikare li App Store an Google Play-ê were dîtin, xalek gihîştina taybetî saz bike, API-ê veqetîne û hesabên testê tomar bike. Pirsgirêk ev e ku mirov bi gelemperî difikirin ku her tiştê ku bi destûrnameyê tê parastin ji êrîşên înkarkirina karûbarê bêpar e. Tê texmîn kirin ku destûr CAPTCHA çêtirîn e, lê ew ne wusa ye. Çêkirina 10-20 hesabên testê hêsan e, lê bi afirandina wan, em gihîştina fonksiyonên tevlihev û neveşartî distînin.
Bi xwezayî, em li dîrokê, li robots.txt û WebArchive, ViewDNS dinêrin û li guhertoyên kevn ên çavkaniyê digerin. Carinan diqewime ku pêşdebiran, bêje, mail2.yandex.net derxistine, lê guhertoya kevn, mail.yandex.net, dimîne. Ev mail.yandex.net êdî nayê piştgirî kirin, çavkaniyên pêşkeftinê jê re nayê veqetandin, lê ew berdewam dike ku databasê dixwe. Li gorî vê yekê, bi karanîna guhertoya kevn, hûn dikarin çavkaniyên paşîn û her tiştê ku li pişt sêwiranê ye bi bandor bikar bînin. Bê guman, ev her gav nabe, lê em hîn jî pir caran bi vê yekê re rû bi rû dimînin.
Bi xwezayî, em hemî pîvanên daxwaznameyê û avahiya cookie analîz dikin. Bibêjin, hûn dikarin hin nirxan bavêjin nav rêzek JSON-ê di hundurê kukiyek de, gelek hêlîn biafirînin û çavkaniyê ji bo demek dirêj a bê maqûl bixebitin.
Barkirina lêgerînê
Yekem tiştê ku dema lêkolîna malperek tê bîra meriv barkirina databasê ye, ji ber ku hema hema her kes lêgerînek heye, û hema hema ji bo her kesî, mixabin, ew kêm tê parastin. Ji ber hin sedeman, pêşdebiran têra xwe guh nadin lêgerînê. Lê li vir yek pêşniyarek heye - divê hûn daxwazên heman celebî nekin, ji ber ku hûn dikarin bi cachkirinê re rû bi rû bimînin, wekî ku di lehiya HTTP de ye.
Çêkirina pirsên rasthatî li databasê jî her gav ne bandorker e. Pir çêtir e ku meriv navnîşek peyvên sereke yên ku bi lêgerînê re têkildar in çêbikin. Ger em vegerin ser mînaka firotgehek serhêl: em bibêjin malper lastîkên gerîdeyê difroşe û destûrê dide we ku hûn radiusa tîrêjan, celebê gerîdeyê û pîvanên din destnîşan bikin. Li gorî vê yekê, berhevokên peyvên têkildar dê databasê neçar bike ku di şert û mercên pir tevlihevtir de bixebite.
Digel vê yekê, hêja ye ku pagasyonê bikar bînin: ji bo lêgerînek ji ya yekem vegerandina rûpela paşîn a encamên lêgerînê pir dijwartir e. Ango, bi alîkariya pagasyonê hûn dikarin barkirinê hinekî cihêreng bikin.
Mînaka jêrîn barkirina lêgerînê nîşan dide. Tê dîtin ku ji saniyeya yekem a ceribandinê bi leza deh daxwazî di çirkeyê de, malper daket û bersiv neda.
Ger lêgerîn tune?
Ger lêgerîn tune be, ev nayê vê wateyê ku malper qadên têketina xedar ên din nagire. Ev qad dibe ku destûr be. Naha, pêşdebiran hez dikin ku haşeyên tevlihev çêkin da ku databasa têketinê ji êrîşek tabloya baranê biparêzin. Ev baş e, lê haşeyên weha gelek çavkaniyên CPU-yê dixwe. Rêjeyek mezin a destûrnameyên derewîn dibe sedema têkçûna pêvajoyê, û wekî encamek, malper xebata xwe rawestîne.
Hebûna li ser malperê her cûre form ji bo şîrove û bertekan sedemek e ku hûn nivîsên pir mezin bişînin wir an jî bi tenê lehiyek mezin çêbikin. Carinan malper pelên pêvekirî qebûl dikin, di nav formata gzip de. Di vê rewşê de, em pelek 1TB digirin, bi karanîna gzip-ê li çend bayt an kilobyte kom dikin û dişînin malperê. Dûv re ew tê rakirin û bandorek pir balkêş tê bidestxistin.
API-ê mayîn
Ez dixwazim piçekî bala xwe bidim ser karûbarên populer ên wekî Rest API. Ewlekirina API-ya Rest ji malperek birêkûpêk pir dijwartir e. Tewra rêbazên piçûk ên parastinê li dijî hêza hovane ya şîfreyê û çalakiyên din ên neqanûnî ji bo Rest API-ê naxebitin.
API-ya Rest pir hêsan e ku were şikandin ji ber ku ew rasterast digihîje databasê. Di heman demê de, têkçûna karûbarek weha ji bo karsaziyê encamên pir giran vedigire. Rastî ev e ku Rest API bi gelemperî ne tenê ji bo malpera sereke, lê ji bo serîlêdana mobîl û hin çavkaniyên karsaziya navxweyî jî tê bikar anîn. Û heke ev hemî têkeve, wê hingê bandor ji ya têkçûna malperek hêsan pir bihêztir e.
Barkirina naveroka giran
Ger ji me re tê pêşniyar kirin ku em hin serîlêdana yek-rûpelê ya asayî, rûpela zevî, an malpera qerta karsaziyê ya ku ne xwedan fonksiyonek tevlihev e ceribandin, em li naveroka giran digerin. Mînakî, wêneyên mezin ên ku server dişîne, pelên binary, belgeyên pdf - em hewl didin ku van hemî dakêşin. Testên bi vî rengî pergala pelan baş bar dikin û kanalan digirin, û ji ber vê yekê bi bandor in. Ango, her çend hûn serverê nexin xwarê, pelek mezin bi leza nizm dakêşin, hûn ê bi tenê kanala servera armanc biqewirînin û dûv re redkirina karûbarê çêbibe.
Nimûneyek ceribandinek weha destnîşan dike ku bi leza 30 RPS malperê bersiv rawestand an xeletiyên servera 500-an çêkir.
Sazkirina serveran ji bîr nekin. Hûn pir caran dikarin bibînin ku kesek makîneyek virtual kirî, Apache li wir saz kir, her tişt ji hêla xwerû vesaz kir, serîlêdanek PHP saz kir, û li jêr hûn dikarin encamê bibînin.
Li vir bar çû root û tenê 10 RPS bû. Em 5 hûrdeman li bendê man û server têk çû. Rast e bi temamî nayê zanîn ka çima ket, lê texmînek heye ku bi tenê hafizeya wî zêde bû û ji ber vê yekê dev ji bersivdayînê berda.
Wave bingeha
Di van sal an du salên dawî de, êrîşên pêlan pir populer bûne. Ev ji ber vê yekê ye ku gelek rêxistin ji bo parastina DDoS hin perçeyên hardware dikirin, ku ji bo berhevkirina statîstîkan demek diyar hewce dike da ku dest bi fîlterkirina êrîşê bikin. Ango di 30-40 saniyeyên ewil de êrîşê fîltre nakin, ji ber ku daneyan berhev dikin û fêr dibin. Li gorî vê yekê, di van 30-40 çirkeyan de hûn dikarin ewqas li ser malperê bişopînin ku çavkanî dê demek dirêj derewan bike heya ku hemî daxwaz neyên paqij kirin.
Di bûyera êrîşa li jêr de, navberek 10 hûrdemî hebû, piştî wê jî beşek nû, guhertî ya êrîşê hat.
Ango, parastin hîn bû, dest bi fîlterkirinê kir, lê beşek nû, bi tevahî cûda ya êrîşê hat, û berevaniyê dîsa dest bi fêrbûnê kir. Bi rastî, fîlterkirin kar disekine, parastin bêbandor dibe, û malper tune ye.
Êrîşên pêlan di lûtkeyê de bi nirxên pir bilind têne diyar kirin, ew dikare di saniyeyê de bigihîje sed hezar an mîlyon daxwazî, di doza L7 de. Ger em li ser L3&4 biaxivin, wê hingê dibe ku bi sedan gigabit trafîkê hebe, an jî, li gorî vê, bi sedan mpps, heke hûn di pakêtan de bijmêrin.
Pirsgirêka êrîşên bi vî rengî hevdemkirinê ye. Êrîş ji botnetek têne û pêdivî bi astek bilind a hevdemkirinê heye da ku piçek yek-car pir mezin biafirîne. Û ev hevrêzî her gav ne bi rê ve diçe: carinan encamek celebek lûtkeya parabolîk e, ku pir xemgîn xuya dike.
Ne HTTP tenê
Ji bilî HTTP li L7, em hez dikin ku protokolên din bikar bînin. Wekî qaîdeyek, malperek birêkûpêk, nemaze mêvandarek birêkûpêk, xwedî protokolên e-nameyê û MySQL ye. Protokolên e-nameyê ji databasan kêmtir bargiran in, lê ew di heman demê de dikarin pir bikêrhatî werin barkirin û bi CPU-ya zêde ya li ser serverê bi dawî bibin.
Em bi karanîna lawaziya SSH ya 2016-an pir serfiraz bûn. Naha ev qelsî hema hema ji bo her kesî hatiye rast kirin, lê ev nayê vê wateyê ku bar nikare ji SSH re were şandin. Kanîn. Tenê barek mezin a destûrnameyê heye, SSH hema hema tevahiya CPU-ya serverê dixwe, û dûv re malper ji yek an du daxwazan serê çirkeyê hilweşe. Li gorî vê yekê, ev yek an du daxwazên ku li ser têketin têne damezrandin, ji barek rewa nayê cûda kirin.
Gelek girêdanên ku em di serveran de vedikin jî têkildar dimînin. Berê, Apache ji vê yekê sûcdar bû, naha nginx bi rastî sûcdar e, ji ber ku ew pir caran ji hêla xwerû ve hatî mîheng kirin. Hejmara girêdanên ku nginx dikare vekirî bihêle sînordar e, ji ber vê yekê em vê hejmara pêwendiyan vedikin, nginx êdî girêdanek nû qebûl nake, û di encamê de malper naxebite.
Koma ceribandina me têra CPU heye ku êrîşî destanên SSL bike. Di prensîbê de, wekî ku pratîk nîşan dide, botnet carinan jî dixwazin vê yekê bikin. Ji aliyek ve, diyar e ku hûn nikarin bêyî SSL-ê bikin, ji ber ku encamên Google, rêzkirin, ewlehî. Ji hêla din ve, SSL mixabin pirsgirêkek CPU heye.
L3&4
Dema ku em li ser êrişek di asta L3&4-ê de diaxivin, em bi gelemperî li ser êrişek di asta girêdanê de diaxivin. Barek wusa hema hema her gav ji ya rewa tê cûda kirin, heya ku ew êrîşek SYN-lehiyê nebe. Pirsgirêka êrîşên SYN-flood ji bo amûrên ewlehiyê qebareya wan a mezin e. Nirxa L3&4 ya herî zêde 1,5-2 Tbit/s bû. Ev celeb seyrûsefer ji bo pargîdaniyên mezin jî, tevî Oracle û Google, pir dijwar e.
SYN û SYN-ACK pakêtên ku di dema sazkirina pêwendiyê de têne bikar anîn. Ji ber vê yekê, SYN-flood dijwar e ku meriv ji barek rewa were cûda kirin: ne diyar e ka ev SYN e ku hatî ku têkiliyek saz bike, an beşek ji lehiyê ye.
UDP-lehî
Bi gelemperî, êrîşker ne xwediyê kapasîteyên me ne, ji ber vê yekê zêdekirin dikare ji bo organîzekirina êrîşan were bikar anîn. Ango, êrîşkar Înternetê dişoxilîne û pêşkêşkerên qels an jî bi xeletî vesazkirî dibîne ku, mînakî, di bersiva yek pakêtek SYN de, bi sê SYN-ACK bersivê dide. Bi xapandina navnîşana çavkaniyê ji navnîşana servera armancê, gengaz e ku meriv bi yek pakêtê, bêje, sê caran hêzê zêde bike û seyrûseferê beralî bike qurban.
Pirsgirêka amplifications ev e ku ew zehmet e ku ew werin tespît kirin. Mînakên vê dawiyê jî doza hestiyar a memcachedên bêhêz in. Zêdeyî, naha gelek cîhazên IoT, kamerayên IP-yê hene, ku ew jî bi gelemperî ji hêla xwerû ve têne mîheng kirin, û ji hêla xwerû ve ew bi xeletî têne mîheng kirin, ji ber vê yekê êrîşkar pir caran bi navgîniya cîhazên weha êrîşan pêk tînin.
Dijwar SYN-lehî
SYN-flood belkî ji nêrîna pêşdebiran celeb êrişa herî balkêş e. Pirsgirêk ev e ku rêveberên pergalê pir caran ji bo parastinê astengkirina IP-ê bikar tînin. Digel vê yekê, astengkirina IP-ê ne tenê bandorê li rêveberên pergalê dike ku bi karanîna nivîsan tevdigerin, lê mixabin, li ser hin pergalên ewlehiyê yên ku bi pir drav têne kirîn jî bandor dike.
Ev rêbaz dikare bibe felaketek, ji ber ku heke êrîşkar navnîşanên IP-yê biguhezînin, pargîdanî dê subneta xwe asteng bike. Dema ku Firewall komika xwe asteng dike, dê encam têkeve danûstendinên derveyî û çavkanî dê têk biçin.
Wekî din, ne dijwar e ku hûn tora xwe asteng bikin. Ger nivîsgeha xerîdar xwedan torgilokek Wi-Fi ye, an ger performansa çavkaniyan bi karanîna pergalên çavdêriyê yên cihêreng tê pîvandin, wê hingê em navnîşana IP-ya vê pergala çavdêriyê an Wi-Fi ya nivîsgeha xerîdar digirin û wê wekî çavkaniyek bikar tînin. Di dawiyê de, çavkanî xuya dike ku peyda dibe, lê navnîşanên IP-ê yên armanc têne asteng kirin. Bi vî rengî, tora Wi-Fi ya konferansa HighLoad, ku hilbera nû ya pargîdaniyê tê pêşkêş kirin, dibe ku were asteng kirin, û ev yek hin lêçûnên karsaziyê û aborî vedigire.
Di dema ceribandinê de, em nekarin zêdekirina bi navgîniya memcached-ê bi çavkaniyên derveyî re bikar bînin, ji ber ku peyman hene ku tenê seyrûseferê ji navnîşanên IP-ya destûr re bişînin. Li gorî vê yekê, em bi navgîniya SYN û SYN-ACK ve zêdekirinê bikar tînin, dema ku pergal bersivê dide şandina yek SYN bi du an sê SYN-ACK-an, û di encam de êrîş bi du an sê caran zêde dibe.
Amûr
Yek ji amûrên sereke yên ku em ji bo xebata L7 bikar tînin Yandex-tank e. Bi taybetî, fantomek wekî çekek tê bikar anîn, ji bilî vê yekê gelek nivîsar hene ji bo hilberîna fîşekan û ji bo analîzkirina encaman.
Tcpdump ji bo analîzkirina seyrûsefera torê, û Nmap ji bo analîzkirina serverê tê bikar anîn. Ji bo afirandina barkirinê di asta L3&4 de, OpenSSL û piçûkek sêrbaziya me ya bi pirtûkxaneya DPDK re têne bikar anîn. DPDK pirtûkxaneyek ji Intel-ê ye ku destûrê dide te ku hûn bi navgîniya torê re bixebitin ku ji stacka Linux-ê derbas dibe, bi vî rengî karîgeriyê zêde dike. Bi xwezayî, em DPDK ne tenê di asta L3&4 de, lê di heman demê de di asta L7 de jî bikar tînin, ji ber ku ew rê dide me ku em herikîna bargiraniyek pir bilind, di nav rêza çend mîlyon daxwazî di çirkeyê de ji yek makîneyê biafirînin.
Em di heman demê de hin jeneratorên trafîkê û amûrên taybetî yên ku em ji bo ceribandinên taybetî dinivîsin bikar tînin. Ger em qelsiya di binê SSH-ê de bi bîr bînin, wê hingê koma jorîn nikare were bikar anîn. Ger em êrîşî protokola e-nameyê bikin, em karûbarên e-nameyê digirin an jî tenê li ser wan nivîsan dinivîsin.
vebiguherin
Wek encam ez dixwazim bêjim:
- Digel ceribandina barkirina klasîk, pêdivî ye ku ceribandina stresê were kirin. Mînakek me ya rastîn heye ku taşeronê hevkar tenê ceribandina barkirinê kiriye. Vê yekê destnîşan kir ku çavkanî dikare li ber barê normal bisekinin. Lê dûv re barek nenormal xuya bû, mêvanên malperê dest pê kirin ku çavkaniyê hinekî cûda bikar bînin, û di encamê de taşeron raza. Ji ber vê yekê, hêja ye ku hûn li qelsiyan bigerin her çend hûn berê ji êrîşên DDoS parastî bin.
- Pêwîst e hin beşên pergalê ji yên din bên îzolekirin. Ger lêgerînek we hebe, hûn hewce ne ku wê biguhezînin makîneyên cihê, ango ne jî li Docker. Ji ber ku ger lêgerîn an destûr bi ser nekeve, bi kêmanî tiştek dê berdewam bike. Di doza firotgehek serhêl de, bikarhêner dê berdewam bikin ku hilberan di katalogê de bibînin, ji berhevkarê biçin, heke ew berê destûr dane bikirin, an jî bi OAuth2 ve destûr bidin.
- Her cûre karûbarên cloudê paşguh nekin.
- CDN-ê ne tenê ji bo xweşbînkirina derengiyên torê bikar bînin, lê di heman demê de wekî navgînek parastinê li dijî êrişên li ser westandina kanalê û bi tenê lehiya nav seyrûsefera statîk.
- Pêdivî ye ku karûbarên parastinê yên pispor bikar bînin. Hûn nikarin di asta kanalê de xwe ji êrişên L3&4 biparêzin, ji ber ku hûn bi îhtîmalek pir tenê kanalek têr tune. Di heman demê de ne gengaz e ku hûn li dijî êrîşên L7 şer bikin, ji ber ku ew dikarin pir mezin bin. Zêdetir, lêgerîna êrîşên piçûk hîn jî mafê karûbarên taybetî, algorîtmayên taybetî ye.
- Bi rêkûpêk nûve bikin. Ev ne tenê ji bo kernelê, lê di heman demê de ji bo daemonê SSH-ê jî derbas dibe, nemaze heke hûn wan ji derve vekin. Di prensîbê de, pêdivî ye ku her tişt were nûve kirin, ji ber ku hûn ne mimkûn e ku hûn bi tena serê xwe hin qelsiyan bişopînin.
Source: www.habr.com