د ژغورنې لپاره DDoS: موږ څنګه د فشار او بار ازموینې ترسره کوو

Variti د بوټو او DDoS بریدونو پروړاندې محافظت رامینځته کوي ، او همدارنګه د فشار او بار ازموینې ترسره کوي. د HighLoad++ 2018 کنفرانس کې موږ د مختلف ډول بریدونو څخه سرچینې خوندي کولو څرنګوالي په اړه خبرې وکړې. په لنډه توګه: د سیسټم برخې جلا کړئ، د کلاوډ خدمتونه او CDNs وکاروئ، او په منظمه توګه تازه کړئ. مګر تاسو به لاهم د ځانګړي شرکتونو پرته د محافظت اداره کولو توان ونلرئ :)

مخکې له دې چې متن ولولئ، تاسو کولی شئ لنډ لنډیز ولولئ د کنفرانس په ویب پاڼه کې.
او که تاسو لوستل خوښ نه کړئ یا یوازې ویډیو وګورئ ، زموږ د راپور ثبت کول د سپیلر لاندې لاندې دي.

د راپور ویډیو ثبتول

ډیری شرکتونه دمخه پوهیږي چې څنګه د بار ازموینې ترسره کړي، مګر ټول د فشار ازموینه نه کوي. زموږ ځینې پیرودونکي فکر کوي چې د دوی سایټ زیانمنونکی دی ځکه چې دوی د لوړ بار سیسټم لري، او دا د بریدونو څخه ښه ساتي. موږ وښیو چې دا په بشپړ ډول ریښتیا ندي.
البته، د ازموینو ترسره کولو دمخه، موږ د پیرودونکي څخه اجازه ترلاسه کوو، لاسلیک شوي او ټاپه شوي، او زموږ په مرسته د DDoS برید په هیچا نشي ترسره کیدی. ازموینه په هغه وخت کې ترسره کیږي چې د پیرودونکي لخوا غوره کیږي، کله چې د هغه سرچینې ته ټرافيک لږ وي، او د لاسرسي ستونزې به په پیرودونکو اغیزه ونکړي. سربیره پردې ، ځکه چې یو څه تل ​​د ازموینې پروسې په جریان کې غلط کیدی شي ، موږ د پیرودونکي سره دوامداره اړیکه لرو. دا تاسو ته اجازه درکوي نه یوازې د ترلاسه شوي پایلو راپور ورکړئ ، بلکه د ازموینې پرمهال یو څه بدل کړئ. د ازموینې په بشپړیدو سره، موږ تل یو راپور چمتو کوو په کوم کې چې موږ کشف شوي نیمګړتیاوې په ګوته کوو او د سایټ د ضعفونو له منځه وړلو لپاره سپارښتنې ورکوو.

موږ څنګه کار کوو

کله چې ازموینه کوو، موږ د بوټینیټ تقلید کوو. له هغه ځایه چې موږ د پیرودونکو سره کار کوو چې زموږ په شبکو کې شتون نلري ، د دې لپاره چې ډاډ ترلاسه کړو چې ازموینه په لومړۍ دقیقه کې د محدودیتونو یا محافظت رامینځته کیدو له امله پای ته نه رسیږي ، موږ بار له یو IP څخه نه ، بلکه زموږ له خپل فرعي نیټ څخه ورکوو. سربیره پردې ، د پام وړ بار رامینځته کولو لپاره ، موږ خپل خورا قوي ټیسټ سرور لرو.

پوسټ کوي

ډیر ښه معنی نلري
څومره چې لږ بار موږ کولی شو یوه سرچینه ناکامۍ ته راوړو ، ښه. که تاسو کولی شئ سایټ په یوه ثانیه کې په یوه غوښتنه کې فعالیت ودروي، یا حتی په یوه دقیقه کې یوه غوښتنه، دا خورا ښه ده. ځکه چې د معنی د قانون سره سم، کاروونکي یا برید کونکي به په ناڅاپي توګه د دې ځانګړي زیان سره مخ شي.

جزوي ناکامي د بشپړې ناکامۍ څخه غوره ده
موږ تل مشوره ورکوو چې سیسټمونه متفاوت جوړ کړي. سربیره پردې ، دا د دوی په فزیکي کچه جلا کولو ارزښت لري ، نه یوازې د کانټینر کولو له لارې. د فزیکي جلا کولو په حالت کې، حتی که چیرې په سایټ کې یو څه ناکام شي، نو ډیر احتمال شتون لري چې دا به په بشپړه توګه کار ونه کړي، او کاروونکي به د فعالیت لږترلږه برخې ته لاسرسۍ ته دوام ورکړي.

ښه جوړښت د پایښت اساس دی
د سرچینې نیمګړتیا او د بریدونو او بارونو سره د مقابلې وړتیا باید د ډیزاین مرحلې کې تنظیم شي ، په حقیقت کې ، په نوټ پیډ کې د لومړي فلوچارټونو رسم کولو مرحله کې. ځکه چې که وژونکي تېروتنې را منځته شي، نو په راتلونکي کې یې سمول ممکن دي، مګر دا خورا ستونزمن کار دی.

نه یوازې کوډ باید ښه وي، بلکې ترتیب هم وي
ډیری خلک فکر کوي چې یو ښه پرمختیایی ټیم د غلطۍ زغمونکي خدمت تضمین دی. یو ښه پرمختیایی ټیم واقعیا اړین دی، مګر باید ښه عملیات، ښه DevOps هم وي. دا دی، موږ متخصصینو ته اړتیا لرو چې لینکس او شبکه په سمه توګه تنظیم کړي، په نګینکس کې په سمه توګه ترتیبونه ولیکئ، محدودیتونه تنظیم کړي، او نور. که نه نو ، سرچینه به یوازې په ازموینه کې ښه کار وکړي ، او په یو وخت کې به هرڅه په تولید کې مات شي.

د بار او فشار ازموینې ترمینځ توپیر
د بار ازموینې تاسو ته اجازه درکوي د سیسټم فعالیت محدودیتونه وپیژني. د فشار ازموینې هدف په سیسټم کې د ضعفونو موندل دي او د دې سیسټم ماتولو لپاره کارول کیږي او وګورئ چې دا به د ځینې برخو د ناکامۍ په پروسه کې څنګه چلند وکړي. پدې حالت کې ، د بار نوعیت معمولا پیرودونکي ته نامعلوم پاتې کیږي مخکې لدې چې د فشار ازموینې پیل شي.

د L7 بریدونو ځانګړتیاوې

موږ معمولا د L7 او L3 او 4 په کچه د بارونو ډولونه ویشو. L7 د غوښتنلیک په کچه یو بار دی، ډیری وختونه دا یوازې د HTTP معنی لري، مګر موږ د TCP پروتوکول په کچه د هر ډول بار معنی لرو.
د L7 بریدونه ځینې ځانګړي ځانګړتیاوې لري. لومړی، دوی مستقیم غوښتنلیک ته راځي، دا امکان نلري چې دوی به د شبکې وسیلو له لارې منعکس شي. دا ډول بریدونه منطق کاروي، او د دې له امله، دوی CPU، حافظه، ډیسک، ډیټابیس او نور سرچینې په خورا اغیزمنه توګه او لږ ټرافیک سره مصرفوي.

د HTTP سیلاب

د هر برید په صورت کې، بار د سمبالولو په پرتله رامینځته کول اسانه دي، او د L7 په قضیه کې دا هم ریښتیا ده. دا تل اسانه نه وي چې د برید ترافیک له مشروع ترافیک څخه توپیر وکړي ، او ډیری وختونه دا د فریکونسۍ لخوا ترسره کیدی شي ، مګر که هرڅه په سمه توګه پلان شوي وي ، نو بیا د لاګونو څخه پوهیدل ناممکن دي چې برید چیرې دی او مشروع غوښتنې چیرې دي.
د لومړي مثال په توګه، د HTTP سیلاب برید په پام کې ونیسئ. ګراف ښیې چې دا ډول بریدونه معمولا خورا پیاوړي دي؛ په لاندې مثال کې، د غوښتنو لوړ شمیر په یوه دقیقه کې له 600 زرو څخه ډیر دی.

HTTP سیلاب د بار جوړولو لپاره ترټولو اسانه لار ده. په عموم کې ، دا د بار ازموینې یو ډول وسیله اخلي ، لکه اپاچی بینچ ، او غوښتنه او هدف ټاکي. د داسې ساده تګلارې سره، د سرور کیچ کولو کې د چلولو ډیر احتمال شتون لري، مګر د دې څخه تیریدل اسانه دي. د مثال په توګه، غوښتنې ته د تصادفي تارونو اضافه کول، کوم چې به سرور مجبور کړي چې په دوامداره توګه تازه پاڼې ته خدمت وکړي.
همچنان ، د بار جوړولو په پروسه کې د کارونکي اجنټ په اړه مه هیروئ. د مشهور ازموینې وسیلو ډیری کارونکي اجنټان د سیسټم مدیرانو لخوا فلټر شوي ، او پدې حالت کې بار ممکن په ساده ډول شاته پای ته ونه رسیږي. تاسو کولی شئ په غوښتنلیک کې د براوزر څخه ډیر یا لږ معتبر سرلیک په داخلولو سره پایله د پام وړ ښه کړئ.
لکه څنګه چې د HTTP سیلاب بریدونه ساده دي، دوی د دوی نیمګړتیاوې هم لري. لومړی، د بار جوړولو لپاره لوی مقدار بریښنا ته اړتیا ده. دوهم، دا ډول بریدونه کشف کول خورا اسانه دي، په ځانګړې توګه که دوی د یو پته څخه راځي. د پایلې په توګه، غوښتنې سمدلاسه د سیسټم مدیرانو یا حتی د چمتو کونکي په کچه د فلټر کیدو پیل کوي.

څه وپلټئ

د موثریت له لاسه ورکولو پرته په هره ثانیه کې د غوښتنو شمیر کمولو لپاره ، تاسو اړتیا لرئ یو څه تخیل وښایاست او سایټ وپلټئ. په دې توګه، تاسو کولی شئ نه یوازې چینل یا سرور، بلکې د غوښتنلیک انفرادي برخې هم پورته کړئ، د بیلګې په توګه، ډیټابیس یا فایل سیسټمونه. تاسو کولی شئ په سایټ کې هغه ځایونه هم وپلټئ چې لوی محاسبه کوي: محاسبین، د محصول انتخاب پاڼې، او نور. په نهایت کې ، دا ډیری وختونه پیښیږي چې سایټ یو ډول PHP سکریپټ لري چې د څو سوه زره لینونو پا pageه رامینځته کوي. دا ډول سکریپټ هم د پام وړ سرور باروي او د برید لپاره هدف کیدی شي.

چیرته چې په لټه کې وي

کله چې موږ د ازموینې دمخه سرچینه سکین کوو ، موږ لومړی ګورو ، البته پخپله سایټ کې. موږ د هر ډول ننوتلو ساحو په لټه کې یو، درانه فایلونه - په عموم کې، هرڅه چې کولی شي د سرچینې لپاره ستونزې رامینځته کړي او د هغې عملیات ورو کړي. په ګوګل کروم او فایرفوکس کې د بینال پراختیا وسیلې دلته مرسته کوي ، د پاڼې غبرګون وختونه ښیې.
موږ فرعي ډومینونه هم سکین کوو. د مثال په توګه، یو ځانګړی آنلاین پلورنځی شتون لري، abc.com، او دا یو فرعي ډومین admin.abc.com لري. ډیری احتمال، دا د واک سره د اډمین پینل دی، مګر که تاسو په دې باندې بار واچوئ، دا کولی شي د اصلي سرچینې لپاره ستونزې رامینځته کړي.
سایټ ممکن یو فرعي ډومین ولري api.abc.com. ډیری احتمال، دا د ګرځنده غوښتنلیکونو لپاره سرچینه ده. غوښتنلیک په اپل سټور یا ګوګل پلی کې موندل کیدی شي ، د لاسرسي ځانګړي نقطه نصب کړئ ، API تحلیل کړئ او د ازموینې حسابونه ثبت کړئ. ستونزه دا ده چې خلک ډیری وختونه فکر کوي چې هر هغه څه چې د واک لخوا ساتل کیږي د خدماتو بریدونو څخه انکار کولو لپاره خوندي دی. داسې انګیرل کیږي، اجازه ورکول غوره کیپچا دی، مګر دا نه ده. د 10-20 ازموینې حسابونو رامینځته کول اسانه دي ، مګر د دوی په رامینځته کولو سره ، موږ پیچلي او ناڅرګند فعالیت ته لاسرسی ترلاسه کوو.
په طبیعي توګه، موږ تاریخ ته ګورو، په robots.txt او WebArchive، ViewDNS کې، او د سرچینې زاړه نسخې ګورو. ځینې ​​​​وختونه داسې پیښیږي چې پرمخ وړونکي mail2.yandex.net په لاره اچولي وي، مګر زوړ نسخه، mail.yandex.net، پاتې کیږي. دا mail.yandex.net نور ملاتړ نه کوي، پراختیایي سرچینې دې ته نه دي ځانګړې شوي، مګر دا د ډیټابیس مصرف ته دوام ورکوي. په دې اساس، د زړې نسخې په کارولو سره، تاسو کولی شئ په مؤثره توګه د شالید سرچینې او هر هغه څه چې د ترتیب تر شا دي وکاروئ. البته، دا تل نه پیښیږي، مګر موږ لاهم ډیری وختونه ورسره مخ کیږو.
په طبیعي توګه، موږ د غوښتنې ټول پیرامیټونه او د کوکی جوړښت تحلیل کوو. تاسو کولی شئ، ووایاست، د کوکي دننه د JSON سرې ته یو څه ارزښت ډوب کړئ، ډیری ځالې رامینځته کړئ او سرچینې د غیر معقول اوږدې مودې لپاره کار وکړئ.

د لټون بار

لومړی شی چې ذهن ته راځي کله چې د سایټ تحقیق کول د ډیټابیس بار کول دي ، ځکه چې نږدې هرڅوک لټون لري ، او د نږدې هرچا لپاره ، له بده مرغه ، دا په خراب ډول خوندي دی. د ځینو دلیلونو لپاره، پراختیا کونکي د لټون لپاره پوره پام نه کوي. مګر دلته یو وړاندیز شتون لري - تاسو باید د ورته ډول غوښتنې ونه کړئ، ځکه چې تاسو ممکن د کیچ کولو سره مخ شئ، لکه څنګه چې د HTTP سیلاب سره قضیه ده.
ډیټابیس ته د تصادفي پوښتنو رامینځته کول هم تل اغیزمن ندي. دا خورا ښه ده چې د کلیمو لیست جوړ کړئ چې د لټون سره تړاو لري. که موږ د آنلاین پلورنځي مثال ته راستون شو: راځئ چې ووایو سایټ د موټر ټایرونه پلوري او تاسو ته اجازه درکوي د ټایرونو وړانګې ، د موټر ډول او نور پیرامیټرې تنظیم کړئ. په دې اساس، د اړوندو کلمو ترکیب به ډیټابیس دې ته اړ کړي چې په ډیرو پیچلو شرایطو کې کار وکړي.
برسېره پردې، دا د پاڼې کولو کارولو ارزښت لري: د لټون لپاره د لومړي په پرتله د لټون پایلو پای پای پاڼې بیرته راستنیدل خورا ستونزمن دي. دا دی، د پاڼې کولو په مرسته تاسو کولی شئ وزن یو څه تنوع کړئ.
لاندې مثال د لټون بار ښیې. دا لیدل کیدی شي چې د ازموینې له لومړۍ ثانیې څخه په هره ثانیه کې د لسو غوښتنو په سرعت سره، سایټ ښکته شو او ځواب یې ونه کړ.

که لټون نه وي؟

که چیرې هیڅ لټون شتون ونلري، دا پدې معنی ندي چې سایټ نور زیان منونکي ان پټ ساحې نلري. دا ساحه کیدای شي جواز وي. نن ورځ ، پراختیا کونکي د رینبو میز برید څخه د ننوتلو ډیټابیس ساتلو لپاره پیچلي هشونه رامینځته کول خوښوي. دا ښه دی، مګر دا ډول هشونه د CPU ډیری سرچینې مصرفوي. د غلط واکونو لوی جریان د پروسیسر ناکامۍ لامل کیږي ، او په پایله کې ، سایټ کار کوي.
په سایټ کې د نظرونو او فیډبیک لپاره د هر ډول ډولونو شتون یو دلیل دی چې هلته خورا لوی متنونه لیږل یا په ساده ډول یو لوی سیلاب رامینځته کوي. ځینې ​​​​وختونه سایټونه ضمیمه شوي فایلونه مني، په شمول د gzip بڼه کې. په دې حالت کې، موږ د 1TB فایل اخلو، دا د gzip په کارولو سره څو بایټونو یا کیلوبایټونو ته فشار ورکړئ او سایټ ته یې لیږئ. بیا دا غیر زپ شوی او خورا په زړه پوري اغیزه ترلاسه کیږي.

آرام API

زه غواړم د آرام API په څیر ورته مشهور خدماتو ته لږ پام وکړم. د آرام API خوندي کول د منظم ویب پاڼې په پرتله خورا ستونزمن دي. حتی د پټنوم وحشي ځواک او نورو غیرقانوني فعالیتونو پروړاندې د محافظت کوچنۍ میتودونه د پاتې API لپاره کار نه کوي.
د پاتې API ماتول خورا اسانه دي ځکه چې دا مستقیم ډیټابیس ته لاسرسی لري. په ورته وخت کې، د داسې خدمت ناکامي د سوداګرۍ لپاره خورا جدي پایلې لري. حقیقت دا دی چې آرام API معمولا نه یوازې د اصلي ویب پاڼې لپاره کارول کیږي، بلکې د ګرځنده غوښتنلیک او ځینې داخلي سوداګرۍ سرچینو لپاره هم کارول کیږي. او که دا ټول راټیټ شي، نو اغیز د ساده ویب پاڼې ناکامۍ په پرتله خورا پیاوړی دی.

دروند محتوا بارول

که موږ ته وړاندیز کیږي چې ځینې عادي واحد پاڼې غوښتنلیک، لینډینګ پاڼه، یا د سوداګرۍ کارت ویب پاڼه چې پیچلي فعالیت نلري ازموینه وکړي، موږ د درنو منځپانګو په لټه کې یو. د مثال په توګه، لوی عکسونه چې سرور یې لیږي، بائنری فایلونه، د pdf اسناد - موږ هڅه کوو دا ټول ډاونلوډ کړو. دا ډول ازموینې د فایل سیسټم ښه باروي او چینلونه بندوي، او له همدې امله اغیزمن دي. دا دی ، حتی که تاسو سرور ښکته نه کړئ ، په ټیټ سرعت کې د لوی فایل ډاونلوډ کول ، تاسو به په ساده ډول د هدف سرور چینل بند کړئ او بیا به د خدماتو انکار واقع شي.
د داسې ازموینې یوه بیلګه ښیي چې د 30 RPS په سرعت سره سایټ د ځواب ویلو مخه ونیوله یا د 500 سرور غلطۍ تولید کړې.

د سرورونو تنظیم کولو په اړه مه هېروئ. تاسو ډیری وختونه موندلی شئ چې یو کس یو مجازی ماشین اخیستی، اپاچی هلته نصب کړی، هر څه یې په ډیفالټ ترتیب کړي، د پی ایچ پی غوښتنلیک نصب کړی، او لاندې تاسو پایله لیدلی شئ.

دلته بار ریښی ته لاړ او یوازې 10 RPS ته رسیدلی. موږ 5 دقیقې انتظار وکړ او سرور خراب شو. دا سمه ده چې دا په بشپړه توګه نه ده معلومه چې هغه ولې راوتلی، مګر داسې انګیرل کیږي چې هغه په ​​​​ساده ډول ډیره حافظه درلوده او له همدې امله یې غبرګون ودراوه.

د څپې پر بنسټ

په وروستي یا دوو کلونو کې، د څپې بریدونه خورا مشهور شوي. دا د دې حقیقت له امله دی چې ډیری سازمانونه د DDoS محافظت لپاره د هارډویر ځینې برخې اخلي ، کوم چې د برید فلټر کولو پیل کولو لپاره احصایې راټولولو لپاره یو ټاکلي وخت ته اړتیا لري. دا دی، دوی برید په لومړیو 30-40 ثانیو کې نه فلټر کوي، ځکه چې دوی معلومات راټولوي او زده کوي. په دې اساس، پدې 30-40 ثانیو کې تاسو کولی شئ په سایټ کې دومره ډیر لانچ کړئ چې سرچینه به د اوږدې مودې لپاره دروغ وي تر هغه چې ټولې غوښتنې پاکې نشي.
د لاندې برید په حالت کې، د 10 دقیقو وقفه وه، چې وروسته د برید یوه نوې، بدله شوې برخه راورسیده.

دا دی، دفاع زده کړه، فلټر کول پیل کړل، مګر د برید یوه نوې، په بشپړه توګه مختلف برخه راغله، او دفاع بیا زده کړه پیل کړه. په حقیقت کې، فلټر کول کار کوي، محافظت غیر اغیزمن کیږي، او سایټ شتون نلري.
د څپې بریدونه په لوړ پوړ کې د خورا لوړ ارزښتونو لخوا مشخص شوي ، دا د L7 په حالت کې په هر ثانیه کې سل زره یا ملیون غوښتنې ته رسي. که موږ د L3 او 4 په اړه وغږیږو، نو کیدای شي په سلګونو ګیګابایټ ټرافيک وي، یا په وینا، په سلګونو mpps، که تاسو په پیکټونو کې حساب کړئ.
د دې ډول بریدونو سره ستونزه همغږي ده. بریدونه د بوټنیټ څخه راځي او د لوړې کچې همغږي ته اړتیا لري ترڅو د یو وخت خورا لوی سپیک رامینځته کړي. او دا همغږي تل کار نه کوي: ځینې وختونه محصول یو ډول پارابولیک چوټي وي ، کوم چې خورا زړه راښکونکي ښکاري.

یوازې HTTP نه

په L7 کې د HTTP سربیره، موږ غواړو چې د نورو پروتوکولونو څخه ګټه پورته کړو. د یوې قاعدې په توګه، یو منظم ویب پاڼه، په ځانګړې توګه منظم کوربه کول، د میل پروتوکولونه او د MySQL پاتې کیدل لري. د میل پروتوکولونه د ډیټابیسونو په پرتله د لږ بار سره مخ دي ، مګر دا هم په خورا مؤثره توګه بار کیدی شي او په سرور کې د ډیر بار شوي CPU سره پای ته رسیږي.
موږ د 2016 SSH زیان مننې په کارولو سره خورا بریالي وو. اوس دا زیانمنتیا د نږدې هرچا لپاره ټاکل شوې ، مګر دا پدې معنی ندي چې بار SSH ته نشي سپارل کیدی. کولی شي. دلته په ساده ډول د واکونو خورا لوی بار شتون لري ، SSH په سرور کې نږدې ټول CPU خوري ، او بیا ویب پاڼه په هر ثانیه کې د یو یا دوه غوښتنو څخه سقوط کوي. په دې اساس، دا یو یا دوه غوښتنې د لاګونو پر بنسټ د مشروع بار څخه توپیر نشي کولی.
ډیری اړیکې چې موږ یې په سرورونو کې خلاصوو هم اړونده پاتې کیږي. پخوا، اپاچی د دې لپاره مجرم و، اوس نګینکس په حقیقت کې د دې لپاره مجرم دی، ځکه چې دا ډیری وختونه د ډیفالټ لخوا ترتیب شوی. د اتصالونو شمیر چې نګینکس کولی شي خلاص وساتي محدود دی ، نو موږ د ارتباطاتو دا شمیره پرانیزو ، نګینکس نور نوی اړیکه نه مني ، او په پایله کې سایټ کار نه کوي.
زموږ د ټیسټ کلستر کافي CPU لري چې د SSL لاسوند برید وکړي. په اصولو کې، لکه څنګه چې تمرین ښیي، بوټینټ ځینې وختونه دا هم کوي. له یوې خوا، دا روښانه ده چې تاسو د SSL پرته نشئ کولی، ځکه چې د ګوګل پایلې، درجه بندي، امنیت. له بلې خوا، SSL له بده مرغه د CPU مسله لري.

L3&4

کله چې موږ د L3 او 4 په کچه د برید په اړه خبرې کوو، موږ معمولا د لینک په کچه د برید په اړه خبرې کوو. دا ډول بار تقریبا تل د مشروع څخه د توپیر وړ دی، پرته لدې چې دا د SYN سیلاب برید وي. د امنیتي وسیلو لپاره د SYN- سیلاب بریدونو سره ستونزه د دوی لوی حجم دی. د L3 او 4 اعظمي ارزښت 1,5-2 Tbit/s و. دا ډول ترافیک حتی د لوی شرکتونو لپاره پروسس کول خورا ستونزمن دي ، پشمول د اوریکل او ګوګل.
SYN او SYN-ACK هغه پاکټونه دي چې د پیوستون رامینځته کولو په وخت کې کارول کیږي. له همدې امله، د SYN سیلاب د مشروع بار څخه توپیر کول ستونزمن دي: دا روښانه نده چې آیا دا یو SYN دی چې د ارتباط رامینځته کولو لپاره راغلی، یا د سیلاب برخه.

UDP - سیلاب

عموما، برید کونکي هغه وړتیاوې نلري چې موږ یې لرو، نو د بریدونو تنظیم کولو لپاره پراخوالی کارول کیدی شي. دا دی، برید کوونکی انټرنیټ سکین کوي ​​او یا هم زیانمنونکي یا په غلط ډول ترتیب شوي سرورونه ومومي چې د مثال په توګه، د یو SYN پاکټ په ځواب کې، د دریو SYN-ACKs سره ځواب ووایی. د هدف سرور له ادرس څخه د سرچینې پته سپوفی کولو سره ، دا ممکنه ده چې ځواک د یو واحد کڅوړې سره درې ځله زیات کړئ او قرباني ته ترافیک واستوئ.

د امپلیفیکیشن ستونزه دا ده چې دوی کشف کول ستونزمن دي. په وروستي مثالونو کې د زیان منونکي یاد شوي حساس قضیه شامله ده. برسېره پردې، اوس ډیری IoT وسایل، IP کیمرې شتون لري، چې ډیری یې د ډیفالټ لخوا ترتیب شوي، او د ډیفالټ لخوا دوی په غلط ډول ترتیب شوي، له همدې امله برید کونکي اکثرا د ورته وسیلو له لارې بریدونه کوي.

ستونزمن SYN - سیلاب

SYN- سیلاب شاید د پراختیا کونکي له نظره د برید ترټولو زړه پورې ډول وي. ستونزه دا ده چې د سیسټم مدیران اکثرا د محافظت لپاره د IP بلاک کول کاروي. سربیره پردې ، د IP بلاک کول نه یوازې د سیسټم مدیران اغیزه کوي چې د سکریپټونو په کارولو سره عمل کوي ، بلکه له بده مرغه ، ځینې امنیتي سیسټمونه چې د ډیرو پیسو لپاره پیرودل کیږي.
دا طریقه کولی شي په ناورین بدله شي، ځکه چې که برید کوونکي د IP پتې ځای په ځای کړي، شرکت به خپل فرعي شبکه بنده کړي. کله چې فایروال خپل کلستر بند کړي، نو محصول به بهرنۍ تعاملات ناکام کړي او سرچینه به ناکامه شي.
سربیره پردې، دا ستونزمنه نده چې ستاسو خپل شبکه بنده کړئ. که چیرې د پیرودونکي دفتر د وائی فای شبکه ولري، یا که د سرچینو فعالیت د مختلف څارنې سیسټمونو په کارولو سره اندازه شي، نو موږ د دې څارنې سیسټم IP پته یا د پیرودونکي دفتر Wi-Fi اخلو او د سرچینې په توګه یې کاروو. په پای کې، سرچینې داسې ښکاري چې شتون لري، مګر د هدف IP پتې بندې شوي. په دې توګه، د HighLoad کنفرانس Wi-Fi شبکه، چیرې چې د شرکت نوی محصول وړاندې کیږي، ممکن بند شي، او دا ځینې سوداګریز او اقتصادي لګښتونه لري.
د ازموینې په جریان کې ، موږ نشو کولی د کومې بهرنۍ سرچینې سره د میمکیچ له لارې امپلیفیکیشن وکاروو ، ځکه چې یوازې اجازه ورکړل شوي IP پتې ته د ترافیک لیږلو تړونونه شتون لري. په دې اساس، موږ د SYN او SYN-ACK له لارې پراخوالی کاروو، کله چې سیسټم د دوه یا دریو SYN-ACKs سره یو SYN لیږلو ته ځواب ووایی، او په تولید کې برید دوه یا درې ځله ضرب کیږي.

توکي

یو له اصلي وسیلو څخه چې موږ یې د L7 کاري بار لپاره کاروو د Yandex-tank دی. په ځانګړې توګه، یو فینټم د ټوپک په توګه کارول کیږي، سربیره پردې د کارتریجونو تولید او د پایلو تحلیل لپاره ډیری سکریپټونه شتون لري.
Tcpdump د شبکې ترافیک تحلیل لپاره کارول کیږي، او Nmap د سرور تحلیل لپاره کارول کیږي. د L3 او 4 په کچه د بار جوړولو لپاره، OpenSSL او د DPDK کتابتون سره زموږ یو څه جادو کارول کیږي. DPDK د انټیل څخه یو کتابتون دی چې تاسو ته اجازه درکوي د لینکس سټیک په واسطه د شبکې انٹرفیس سره کار وکړئ ، په دې توګه موثریت ډیروي. په طبیعي توګه، موږ DPDK نه یوازې د L3 او 4 په کچه، بلکې د L7 په کچه هم کاروو، ځکه چې دا موږ ته اجازه راکوي چې د یو ماشین څخه په هره ثانیه کې د څو میلیونو غوښتنو په لړ کې، د خورا لوړ بار جریان رامینځته کړو.
موږ ځینې ټرافيکي جنراتورونه او ځانګړي وسیلې هم کاروو چې موږ د ځانګړو ازموینو لپاره لیکو. که موږ د SSH لاندې زیان منونکي یادونه وکړو، نو پورته سیټ نشي کارول کیدی. که موږ د میل پروتوکول برید وکړو، موږ د بریښنالیک اسانتیاوې اخلو یا په ساده ډول په دوی باندې سکریپټونه لیکو.

موندنو

په پایله کې زه غواړم ووایم:

• د کلاسیک بار ازموینې سربیره ، د فشار ازموینې ترسره کول اړین دي. موږ یو ریښتینی مثال لرو چیرې چې د ملګري فرعي قراردادي یوازې د بار ازموینه ترسره کړې. دا وښودله چې سرچینې کولی شي د نورمال بار سره مقاومت وکړي. مګر بیا یو غیر معمولي بار راښکاره شو، د سایټ لیدونکو د سرچینې څخه یو څه بل ډول کارول پیل کړل، او د پایلې په توګه فرعي قراردادي ښکته شو. په دې توګه، دا د زیانونو په لټه کې دي حتی که تاسو دمخه د DDoS بریدونو څخه خوندي یاست.
• دا اړینه ده چې د سیسټم ځینې برخې له نورو څخه جلا کړئ. که تاسو لټون لرئ ، تاسو اړتیا لرئ دا جلا ماشینونو ته واړوئ ، دا دی حتی ډاکر ته هم نه. ځکه چې که لټون یا اختیار ناکام شي، لږترلږه یو څه به کار ته دوام ورکړي. د آنلاین پلورنځي په حالت کې ، کارونکي به په کتلاګ کې محصولاتو موندلو ته دوام ورکړي ، له راټولونکي څخه لاړ شي ، پیرود که چیرې دوی دمخه مجاز وي ، یا د OAuth2 له لارې اجازه ورکړي.
• د بادل خدماتو هر ډول غفلت مه کوئ.
• CDN نه یوازې د شبکې ځنډونو اصلاح کولو لپاره وکاروئ ، بلکه د چینل ستړیا او په ساده ډول جامد ترافیک کې سیلابونو باندې د بریدونو پروړاندې د محافظت وسیلې په توګه هم وکاروئ.
• دا اړینه ده چې د ځانګړو محافظتي خدماتو څخه کار واخلئ. تاسو نشئ کولی د چینل په کچه د L3 او 4 بریدونو څخه ځان وژغورئ، ځکه چې تاسو ډیری احتمال په ساده ډول کافي چینل نلرئ. تاسو د L7 بریدونو سره مبارزه هم امکان نلري، ځکه چې دوی خورا لوی کیدی شي. برسیره پردې، د کوچنیو بریدونو لټون لاهم د ځانګړو خدماتو، ځانګړي الګوریتمونو لومړیتوب دی.
• په منظمه توګه تازه کړئ. دا نه یوازې د کرنل لپاره ، بلکه د SSH ډیمون لپاره هم پلي کیږي ، په ځانګړي توګه که تاسو دا بهر ته خلاص یاست. په اصولو کې، هرڅه باید نوي شي، ځکه چې تاسو د دې توان نلري چې ځینې زیانمننې پخپله تعقیب کړئ.

سرچینه: www.habr.com