Variti بوٹس اور DDoS حملوں کے خلاف تحفظ تیار کرتی ہے، اور تناؤ اور بوجھ کی جانچ بھی کرتی ہے۔ HighLoad++ 2018 کانفرنس میں ہم نے مختلف قسم کے حملوں سے وسائل کو محفوظ بنانے کے بارے میں بات کی۔ مختصراً: سسٹم کے حصوں کو الگ تھلگ کریں، کلاؤڈ سروسز اور CDNs استعمال کریں، اور باقاعدگی سے اپ ڈیٹ کریں۔ لیکن آپ اب بھی خصوصی کمپنیوں کے بغیر تحفظ کو سنبھال نہیں پائیں گے :)
متن کو پڑھنے سے پہلے، آپ مختصر خلاصے پڑھ سکتے ہیں۔ .
اور اگر آپ پڑھنا پسند نہیں کرتے یا صرف ویڈیو دیکھنا چاہتے ہیں تو ہماری رپورٹ کی ریکارڈنگ نیچے دی گئی ہے۔
رپورٹ کی ویڈیو ریکارڈنگ
بہت سی کمپنیاں پہلے ہی جانتی ہیں کہ لوڈ ٹیسٹنگ کیسے کی جاتی ہے، لیکن سبھی اسٹریس ٹیسٹنگ نہیں کرتے۔ ہمارے کچھ صارفین کا خیال ہے کہ ان کی سائٹ ناقابل تسخیر ہے کیونکہ ان کے پاس ہائی لوڈ سسٹم ہے، اور یہ حملوں سے اچھی طرح سے محفوظ رکھتا ہے۔ ہم ظاہر کرتے ہیں کہ یہ مکمل طور پر سچ نہیں ہے۔
یقیناً، ٹیسٹ کرنے سے پہلے، ہم گاہک سے اجازت لیتے ہیں، دستخط شدہ اور مہر لگاتے ہیں، اور ہماری مدد سے کسی پر DDoS حملہ نہیں کیا جا سکتا۔ جانچ گاہک کے منتخب کردہ وقت پر کی جاتی ہے، جب اس کے وسائل پر ٹریفک کم سے کم ہو، اور رسائی کے مسائل کلائنٹس کو متاثر نہیں کریں گے۔ اس کے علاوہ، چونکہ جانچ کے عمل کے دوران ہمیشہ کچھ غلط ہو سکتا ہے، اس لیے ہمارا کسٹمر کے ساتھ مسلسل رابطہ رہتا ہے۔ یہ آپ کو نہ صرف حاصل کردہ نتائج کی اطلاع دینے کی اجازت دیتا ہے، بلکہ جانچ کے دوران کچھ تبدیل کرنے کی بھی اجازت دیتا ہے۔ جانچ کی تکمیل کے بعد، ہم ہمیشہ ایک رپورٹ تیار کرتے ہیں جس میں ہم پائی جانے والی کوتاہیوں کی نشاندہی کرتے ہیں اور سائٹ کی کمزوریوں کو دور کرنے کے لیے تجاویز دیتے ہیں۔
ہم کس طرح کام کر رہے ہیں۔
جانچ کرتے وقت، ہم بوٹ نیٹ کی تقلید کرتے ہیں۔ چونکہ ہم ان کلائنٹس کے ساتھ کام کرتے ہیں جو ہمارے نیٹ ورکس پر موجود نہیں ہیں، اس بات کو یقینی بنانے کے لیے کہ ٹیسٹ پہلے ہی منٹ میں ختم نہ ہو جائے کیونکہ حدود یا تحفظ کے محرک ہونے کی وجہ سے، ہم لوڈ ایک IP سے نہیں، بلکہ اپنے اپنے سب نیٹ سے فراہم کرتے ہیں۔ اس کے علاوہ، ایک اہم بوجھ پیدا کرنے کے لیے، ہمارے پاس اپنا کافی طاقتور ٹیسٹ سرور ہے۔
فرض کرتا ہے۔
بہت زیادہ کا مطلب اچھا نہیں ہے۔
جتنا کم بوجھ ہم کسی وسائل کو ناکامی کی طرف لا سکتے ہیں، اتنا ہی بہتر ہے۔ اگر آپ فی سیکنڈ ایک درخواست پر یا فی منٹ ایک درخواست پر سائٹ کو کام کرنا بند کر سکتے ہیں تو یہ بہت اچھا ہے۔ کیونکہ ضابطہ اخلاق کے مطابق، استعمال کرنے والے یا حملہ آور غلطی سے اس خاص خطرے میں پڑ جائیں گے۔
جزوی ناکامی مکمل ناکامی سے بہتر ہے۔
ہم ہمیشہ نظاموں کو متضاد بنانے کا مشورہ دیتے ہیں۔ مزید یہ کہ، یہ جسمانی سطح پر ان کو الگ کرنے کے قابل ہے، نہ کہ صرف کنٹینرائزیشن کے ذریعے۔ جسمانی علیحدگی کی صورت میں، یہاں تک کہ اگر سائٹ پر کوئی چیز ناکام ہوجاتی ہے، اس بات کا بہت زیادہ امکان ہے کہ یہ مکمل طور پر کام کرنا بند نہیں کرے گا، اور صارفین کو فعالیت کے کم از کم حصے تک رسائی حاصل رہے گی۔
اچھا فن تعمیر پائیداری کی بنیاد ہے۔
کسی وسائل کی غلطی برداشت کرنے کی صلاحیت اور حملوں اور بوجھ کو برداشت کرنے کی صلاحیت کو ڈیزائن کے مرحلے پر، درحقیقت، نوٹ بک میں پہلا فلو چارٹ بنانے کے مرحلے پر رکھا جانا چاہیے۔ کیونکہ اگر مہلک غلطیاں سر زد ہو جائیں تو مستقبل میں ان کی اصلاح ممکن ہے لیکن یہ بہت مشکل ہے۔
نہ صرف کوڈ اچھا ہونا چاہیے بلکہ ترتیب بھی
بہت سے لوگوں کا خیال ہے کہ ایک اچھی ترقیاتی ٹیم غلطی برداشت کرنے والی خدمت کی ضمانت ہے۔ ایک اچھی ڈیولپمنٹ ٹیم واقعی ضروری ہے، لیکن اچھی کارروائیاں، اچھی ڈی او اوپس بھی ہونی چاہئیں۔ یعنی، ہمیں ایسے ماہرین کی ضرورت ہے جو لینکس اور نیٹ ورک کو درست طریقے سے ترتیب دیں، nginx میں درست طریقے سے کنفیگرز لکھیں، حدود مقرر کریں، وغیرہ۔ دوسری صورت میں، وسائل صرف جانچ میں اچھی طرح سے کام کرے گا، اور کسی وقت سب کچھ پیداوار میں ٹوٹ جائے گا.
بوجھ اور تناؤ کی جانچ کے درمیان فرق
لوڈ ٹیسٹنگ آپ کو سسٹم کے کام کرنے کی حدود کی شناخت کرنے کی اجازت دیتی ہے۔ تناؤ کی جانچ کا مقصد کسی نظام میں کمزوریوں کو تلاش کرنا ہے اور اس کا استعمال اس نظام کو توڑنے اور یہ دیکھنے کے لیے کیا جاتا ہے کہ یہ بعض حصوں کی ناکامی کے عمل میں کیسا برتاؤ کرے گا۔ اس صورت میں، دباؤ کی جانچ شروع ہونے سے پہلے بوجھ کی نوعیت عام طور پر صارف کے لیے نامعلوم رہتی ہے۔
L7 حملوں کی مخصوص خصوصیات
ہم عام طور پر L7 اور L3 اور 4 کی سطحوں پر بوجھ کی اقسام کو بوجھ میں تقسیم کرتے ہیں۔ L7 ایپلیکیشن کی سطح پر ایک بوجھ ہے، اکثر اس کا مطلب صرف HTTP ہوتا ہے، لیکن ہمارا مطلب TCP پروٹوکول کی سطح پر کوئی بوجھ ہے۔
L7 حملوں میں کچھ مخصوص خصوصیات ہیں۔ سب سے پہلے، وہ براہ راست ایپلی کیشن پر آتے ہیں، یعنی، یہ امکان نہیں ہے کہ وہ نیٹ ورک کے ذرائع سے منعکس ہوں گے۔ اس طرح کے حملے منطق کا استعمال کرتے ہیں، اور اس کی وجہ سے، وہ CPU، میموری، ڈسک، ڈیٹا بیس اور دیگر وسائل کو بہت مؤثر طریقے سے اور بہت کم ٹریفک کے ساتھ استعمال کرتے ہیں۔
HTTP سیلاب
کسی بھی حملے کی صورت میں، بوجھ کو ہینڈل کرنے کے بجائے پیدا کرنا آسان ہے، اور L7 کے معاملے میں یہ بھی درست ہے۔ حملے کی ٹریفک کو جائز ٹریفک سے الگ کرنا ہمیشہ آسان نہیں ہوتا ہے، اور اکثر ایسا فریکوئنسی کے ذریعے کیا جا سکتا ہے، لیکن اگر ہر چیز کو صحیح طریقے سے پلان کیا گیا ہو، تو لاگز سے یہ سمجھنا ناممکن ہے کہ حملہ کہاں ہے اور جائز درخواستیں کہاں ہیں۔
پہلی مثال کے طور پر، HTTP فلڈ اٹیک پر غور کریں۔ گراف سے پتہ چلتا ہے کہ اس طرح کے حملے عام طور پر بہت طاقتور ہوتے ہیں؛ نیچے دی گئی مثال میں، درخواستوں کی چوٹی کی تعداد 600 ہزار فی منٹ سے تجاوز کر گئی۔
HTTP فلڈ لوڈ بنانے کا سب سے آسان طریقہ ہے۔ عام طور پر، یہ کسی قسم کا لوڈ ٹیسٹنگ ٹول لیتا ہے، جیسے کہ ApacheBench، اور ایک درخواست اور ہدف مقرر کرتا ہے۔ اس طرح کے ایک آسان نقطہ نظر کے ساتھ، سرور کیچنگ میں چلنے کا ایک اعلی امکان ہے، لیکن اسے نظرانداز کرنا آسان ہے۔ مثال کے طور پر، درخواست میں بے ترتیب تاریں شامل کرنا، جو سرور کو مسلسل تازہ صفحہ پیش کرنے پر مجبور کرے گا۔
اس کے علاوہ، لوڈ بنانے کے عمل میں صارف کے ایجنٹ کے بارے میں مت بھولنا. مقبول ٹیسٹنگ ٹولز کے بہت سے صارف ایجنٹوں کو سسٹم ایڈمنسٹریٹرز کے ذریعے فلٹر کیا جاتا ہے، اور اس صورت میں بوجھ صرف بیک اینڈ تک نہیں پہنچ سکتا ہے۔ آپ درخواست میں براؤزر سے کم یا زیادہ درست ہیڈر ڈال کر نتیجہ کو نمایاں طور پر بہتر بنا سکتے ہیں۔
HTTP فلڈ حملے جتنے آسان ہیں، ان میں اپنی خامیاں بھی ہیں۔ سب سے پہلے، لوڈ بنانے کے لیے بڑی مقدار میں بجلی کی ضرورت ہوتی ہے۔ دوم، اس طرح کے حملوں کا پتہ لگانا بہت آسان ہے، خاص طور پر اگر وہ ایک پتے سے آئے ہوں۔ نتیجے کے طور پر، درخواستوں کو فوری طور پر یا تو سسٹم ایڈمنسٹریٹرز یا فراہم کنندہ کی سطح پر بھی فلٹر کرنا شروع کر دیتے ہیں۔
کیا تلاش کرنا ہے
کارکردگی کو کھونے کے بغیر فی سیکنڈ درخواستوں کی تعداد کو کم کرنے کے لیے، آپ کو تھوڑا سا تخیل دکھانے اور سائٹ کو دریافت کرنے کی ضرورت ہے۔ اس طرح، آپ نہ صرف چینل یا سرور، بلکہ ایپلیکیشن کے انفرادی حصوں کو بھی لوڈ کر سکتے ہیں، مثال کے طور پر، ڈیٹا بیس یا فائل سسٹم۔ آپ سائٹ پر ایسی جگہیں بھی تلاش کر سکتے ہیں جو بڑے حساب کتاب کرتے ہیں: کیلکولیٹر، پروڈکٹ سلیکشن پیجز وغیرہ۔ آخر میں، اکثر ایسا ہوتا ہے کہ سائٹ میں کچھ قسم کی PHP اسکرپٹ ہوتی ہے جو کئی لاکھ لائنوں کا صفحہ بناتی ہے۔ اس طرح کا اسکرپٹ سرور کو بھی نمایاں طور پر لوڈ کرتا ہے اور حملے کا نشانہ بن سکتا ہے۔
کہاں ڈھونڈنا ہے
جب ہم جانچ سے پہلے کسی وسائل کو اسکین کرتے ہیں، تو ہم سب سے پہلے یقیناً سائٹ پر ہی دیکھتے ہیں۔ ہم تمام قسم کے ان پٹ فیلڈز، بھاری فائلوں کی تلاش کر رہے ہیں - عام طور پر، ہر وہ چیز جو وسائل کے لیے مسائل پیدا کر سکتی ہے اور اس کے کام کو سست کر سکتی ہے۔ گوگل کروم اور فائر فاکس میں بانل ڈویلپمنٹ ٹولز یہاں مدد کرتے ہیں، جو صفحہ کے جواب کے اوقات دکھاتے ہیں۔
ہم ذیلی ڈومینز کو بھی اسکین کرتے ہیں۔ مثال کے طور پر، ایک مخصوص آن لائن اسٹور ہے، 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۔
میں Rest API جیسی مقبول خدمات پر تھوڑی توجہ دینا چاہوں گا۔ ریسٹ API کو محفوظ کرنا ایک باقاعدہ ویب سائٹ سے کہیں زیادہ مشکل ہے۔ پاس ورڈ بروٹ فورس اور دیگر ناجائز سرگرمیوں کے خلاف تحفظ کے معمولی طریقے بھی باقی API کے لیے کام نہیں کرتے۔
باقی API کو توڑنا بہت آسان ہے کیونکہ یہ ڈیٹا بیس تک براہ راست رسائی حاصل کرتا ہے۔ ایک ہی وقت میں، ایسی سروس کی ناکامی کاروبار کے لیے کافی سنگین نتائج کا حامل ہے۔ حقیقت یہ ہے کہ ریسٹ API عام طور پر نہ صرف مرکزی ویب سائٹ کے لیے استعمال ہوتا ہے بلکہ موبائل ایپلیکیشن اور کچھ اندرونی کاروباری وسائل کے لیے بھی استعمال ہوتا ہے۔ اور اگر یہ سب گر جاتا ہے، تو اس کا اثر ایک سادہ ویب سائٹ کی ناکامی کے مقابلے میں زیادہ مضبوط ہوتا ہے۔
بھاری مواد لوڈ ہو رہا ہے۔
اگر ہمیں کچھ عام سنگل پیج ایپلیکیشن، لینڈنگ پیج، یا بزنس کارڈ ویب سائٹ کی جانچ کرنے کی پیشکش کی جاتی ہے جس میں پیچیدہ فعالیت نہیں ہوتی ہے، تو ہم بھاری مواد تلاش کرتے ہیں۔ مثال کے طور پر، بڑی تصاویر جو سرور بھیجتا ہے، بائنری فائلز، پی ڈی ایف دستاویزات - ہم یہ سب ڈاؤن لوڈ کرنے کی کوشش کرتے ہیں۔ اس طرح کے ٹیسٹ فائل سسٹم کو اچھی طرح سے لوڈ کرتے ہیں اور چینلز کو روکتے ہیں، اور اس لیے موثر ہیں۔ یعنی، اگر آپ سرور کو ڈاؤن نہیں کرتے ہیں، ایک بڑی فائل کو کم رفتار سے ڈاؤن لوڈ کرتے ہوئے، آپ صرف ٹارگٹ سرور کے چینل کو بند کردیں گے اور پھر سروس سے انکار ہوجائے گا۔
اس طرح کے ٹیسٹ کی ایک مثال سے پتہ چلتا ہے کہ 30 RPS کی رفتار سے سائٹ نے جواب دینا بند کر دیا یا 500 ویں سرور کی خرابیاں پیدا ہوئیں۔
سرور قائم کرنے کے بارے میں مت بھولنا. آپ اکثر دیکھ سکتے ہیں کہ ایک شخص نے ایک ورچوئل مشین خریدی، وہاں اپاچی انسٹال کی، ہر چیز کو بطور ڈیفالٹ کنفیگر کیا، پی ایچ پی ایپلی کیشن انسٹال کی، اور نیچے آپ نتیجہ دیکھ سکتے ہیں۔
یہاں بوجھ جڑ تک چلا گیا اور صرف 10 آر پی ایس تھا۔ ہم نے 5 منٹ انتظار کیا اور سرور کریش ہو گیا۔ یہ سچ ہے کہ یہ مکمل طور پر معلوم نہیں ہے کہ وہ کیوں گرا، لیکن ایک مفروضہ ہے کہ اس کی یادداشت بہت زیادہ تھی اس لیے اس نے جواب دینا چھوڑ دیا۔
لہر کی بنیاد پر
پچھلے ایک یا دو سال میں لہروں کے حملے کافی مقبول ہو گئے ہیں۔ یہ اس حقیقت کی وجہ سے ہے کہ بہت سی تنظیمیں DDoS تحفظ کے لیے ہارڈویئر کے کچھ مخصوص ٹکڑے خریدتی ہیں، جنہیں حملے کو فلٹر کرنے کے لیے اعداد و شمار جمع کرنے کے لیے ایک خاص وقت درکار ہوتا ہے۔ یعنی، وہ پہلے 30-40 سیکنڈ میں حملے کو فلٹر نہیں کرتے، کیونکہ وہ ڈیٹا اکٹھا کرتے ہیں اور سیکھتے ہیں۔ اس کے مطابق، ان 30-40 سیکنڈز میں آپ سائٹ پر اتنا لانچ کر سکتے ہیں کہ تمام درخواستوں کو صاف کرنے تک وسائل طویل عرصے تک پڑے رہیں گے۔
نیچے حملے کی صورت میں، 10 منٹ کا وقفہ تھا، جس کے بعد حملے کا ایک نیا، تبدیل شدہ حصہ آیا۔
یعنی دفاع نے سیکھا، فلٹرنگ شروع کر دی، لیکن حملے کا ایک نیا، بالکل مختلف حصہ آ گیا، اور دفاع نے دوبارہ سیکھنا شروع کر دیا۔ درحقیقت، فلٹرنگ کام کرنا بند کر دیتی ہے، تحفظ غیر موثر ہو جاتا ہے، اور سائٹ دستیاب نہیں ہوتی۔
لہروں کے حملوں کی خاصیت انتہائی بلند اقدار سے ہوتی ہے، یہ L7 کے معاملے میں فی سیکنڈ ایک لاکھ یا ایک ملین درخواستوں تک پہنچ سکتی ہے۔ اگر ہم L3 اور 4 کے بارے میں بات کریں، تو سینکڑوں گیگا بٹس ٹریفک ہو سکتی ہے، یا اس کے مطابق، سینکڑوں mpps، اگر آپ پیکٹوں میں شمار کرتے ہیں۔
اس طرح کے حملوں کے ساتھ مسئلہ مطابقت پذیری ہے. حملے بوٹ نیٹ سے آتے ہیں اور ایک بہت بڑی ایک وقتی اسپائک بنانے کے لیے اعلیٰ درجے کی مطابقت پذیری کی ضرورت ہوتی ہے۔ اور یہ ہم آہنگی ہمیشہ کام نہیں کرتی ہے: بعض اوقات آؤٹ پٹ کسی قسم کی پیرابولک چوٹی ہوتی ہے، جو کہ قابل رحم دکھائی دیتی ہے۔
اکیلے HTTP نہیں
L7 پر HTTP کے علاوہ، ہم دوسرے پروٹوکول سے فائدہ اٹھانا پسند کرتے ہیں۔ ایک اصول کے طور پر، ایک باقاعدہ ویب سائٹ، خاص طور پر ایک باقاعدہ ہوسٹنگ، میں میل پروٹوکول اور MySQL موجود ہوتا ہے۔ میل پروٹوکول ڈیٹا بیس کے مقابلے میں کم بوجھ کے تابع ہوتے ہیں، لیکن وہ کافی مؤثر طریقے سے لوڈ کیے جاسکتے ہیں اور سرور پر اوورلوڈ CPU کے ساتھ ختم ہوتے ہیں۔
ہم 2016 SSH کمزوری کا استعمال کرتے ہوئے کافی کامیاب رہے۔ اب یہ کمزوری تقریباً ہر ایک کے لیے طے کر دی گئی ہے، لیکن اس کا مطلب یہ نہیں ہے کہ لوڈ SSH کو جمع نہیں کیا جا سکتا۔ کر سکتے ہیں۔ بس اجازتوں کا ایک بہت بڑا بوجھ ہے، SSH سرور پر تقریباً پورا CPU کھا جاتا ہے، اور پھر ویب سائٹ فی سیکنڈ ایک یا دو درخواستوں سے گر جاتی ہے۔ اس کے مطابق، نوشتہ جات پر مبنی ان ایک یا دو درخواستوں کو جائز بوجھ سے الگ نہیں کیا جا سکتا۔
بہت سے کنکشن جو ہم سرورز میں کھولتے ہیں وہ بھی متعلقہ رہتے ہیں۔ پہلے، اپاچی اس کا قصوروار تھا، اب nginx اصل میں اس کا قصوروار ہے، کیونکہ یہ اکثر بطور ڈیفالٹ کنفیگر ہوتا ہے۔ کنکشنز کی تعداد جو nginx کھلے رکھ سکتی ہے محدود ہے، اس لیے ہم کنکشنز کی اس تعداد کو کھولتے ہیں، nginx اب کوئی نیا کنکشن قبول نہیں کرتا، اور نتیجتاً سائٹ کام نہیں کرتی۔
ہمارے ٹیسٹ کلسٹر میں SSL ہینڈ شیک پر حملہ کرنے کے لیے کافی CPU ہے۔ اصولی طور پر، جیسا کہ پریکٹس سے پتہ چلتا ہے، بوٹنیٹس کبھی کبھی ایسا کرنا بھی پسند کرتے ہیں۔ ایک طرف، یہ واضح ہے کہ آپ SSL کے بغیر نہیں کر سکتے، کیونکہ گوگل کے نتائج، درجہ بندی، سیکورٹی۔ دوسری طرف، SSL میں بدقسمتی سے CPU کا مسئلہ ہے۔
L3 اور 4
جب ہم L3 اور 4 کی سطح پر حملے کے بارے میں بات کرتے ہیں، تو ہم عام طور پر لنک کی سطح پر حملے کے بارے میں بات کرتے ہیں۔ اس طرح کا بوجھ تقریباً ہمیشہ جائز سے ممتاز ہوتا ہے، الا یہ کہ یہ SYN- سیلاب کا حملہ ہو۔ سیکورٹی ٹولز کے لیے SYN- سیلاب کے حملوں کا مسئلہ ان کا بڑا حجم ہے۔ زیادہ سے زیادہ L3 اور 4 قدر 1,5-2 Tbit/s تھی۔ اوریکل اور گوگل سمیت بڑی کمپنیوں کے لیے بھی اس قسم کی ٹریفک پر کارروائی کرنا بہت مشکل ہے۔
SYN اور SYN-ACK وہ پیکٹ ہیں جو کنکشن قائم کرتے وقت استعمال ہوتے ہیں۔ لہذا، SYN-flood کو جائز بوجھ سے الگ کرنا مشکل ہے: یہ واضح نہیں ہے کہ آیا یہ SYN ہے جو کنکشن قائم کرنے آیا ہے، یا سیلاب کا حصہ ہے۔
UDP- سیلاب
عام طور پر، حملہ آوروں کے پاس وہ صلاحیتیں نہیں ہوتیں جو ہمارے پاس ہیں، اس لیے حملوں کو منظم کرنے کے لیے ایمپلیفیکیشن کا استعمال کیا جا سکتا ہے۔ یعنی، حملہ آور انٹرنیٹ کو اسکین کرتا ہے اور اسے یا تو کمزور یا غلط طریقے سے ترتیب شدہ سرورز کا پتہ چلتا ہے جو، مثال کے طور پر، ایک SYN پیکٹ کے جواب میں، تین SYN-ACKs کے ساتھ جواب دیتے ہیں۔ ٹارگٹ سرور کے ایڈریس سے سورس ایڈریس کو سپوف کر کے، ایک پیکٹ سے تین گنا پاور بڑھانا اور ٹریفک کو متاثرہ کی طرف بھیجنا ممکن ہے۔
امپلیفیکیشن کے ساتھ مسئلہ یہ ہے کہ ان کا پتہ لگانا مشکل ہے۔ حالیہ مثالوں میں کمزور میمکیچڈ کا سنسنی خیز کیس شامل ہے۔ اس کے علاوہ، اب بہت سارے آئی او ٹی ڈیوائسز، آئی پی کیمرے موجود ہیں، جو بھی زیادہ تر ڈیفالٹ کے ذریعے کنفیگر ہوتے ہیں، اور بطور ڈیفالٹ وہ غلط طریقے سے کنفیگر ہوتے ہیں، یہی وجہ ہے کہ حملہ آور اکثر ایسے آلات کے ذریعے حملے کرتے ہیں۔
مشکل SYN- سیلاب
ڈویلپر کے نقطہ نظر سے SYN-فلڈ ممکنہ طور پر سب سے دلچسپ قسم کا حملہ ہے۔ مسئلہ یہ ہے کہ سسٹم ایڈمنسٹریٹر اکثر تحفظ کے لیے آئی پی بلاکنگ کا استعمال کرتے ہیں۔ مزید برآں، آئی پی بلاک کرنے سے نہ صرف سسٹم ایڈمنسٹریٹر متاثر ہوتے ہیں جو اسکرپٹس کا استعمال کرتے ہوئے کام کرتے ہیں، بلکہ بدقسمتی سے، کچھ سیکیورٹی سسٹمز بھی متاثر ہوتے ہیں جو بہت زیادہ پیسے دے کر خریدے جاتے ہیں۔
یہ طریقہ تباہی میں بدل سکتا ہے، کیونکہ اگر حملہ آور IP ایڈریس کو تبدیل کرتے ہیں، تو کمپنی اپنا سب نیٹ بلاک کر دے گی۔ جب فائر وال اپنے کلسٹر کو روکتا ہے، تو آؤٹ پٹ بیرونی تعاملات میں ناکام ہو جائے گا اور وسائل ناکام ہو جائیں گے۔
مزید یہ کہ آپ کے اپنے نیٹ ورک کو بلاک کرنا مشکل نہیں ہے۔ اگر کلائنٹ کے دفتر میں Wi-Fi نیٹ ورک ہے، یا اگر مختلف مانیٹرنگ سسٹمز کا استعمال کرتے ہوئے وسائل کی کارکردگی کی پیمائش کی جاتی ہے، تو ہم اس مانیٹرنگ سسٹم یا کلائنٹ کے آفس Wi-Fi کا IP ایڈریس لیتے ہیں اور اسے بطور ذریعہ استعمال کرتے ہیں۔ آخر میں، ایسا لگتا ہے کہ وسائل دستیاب ہیں، لیکن ہدف کے IP پتے مسدود ہیں۔ اس طرح، ہائی لوڈ کانفرنس کا وائی فائی نیٹ ورک، جہاں کمپنی کی نئی پروڈکٹ پیش کی جا رہی ہے، کو بلاک کیا جا سکتا ہے، اور اس میں کچھ کاروباری اور اقتصادی اخراجات شامل ہیں۔
جانچ کے دوران، ہم کسی بیرونی وسائل کے ساتھ میم کیچ کے ذریعے ایمپلیفیکیشن کا استعمال نہیں کر سکتے، کیونکہ صرف اجازت شدہ IP پتوں پر ٹریفک بھیجنے کے معاہدے ہیں۔ اس کے مطابق، ہم SYN اور SYN-ACK کے ذریعے ایمپلیفیکیشن کا استعمال کرتے ہیں، جب سسٹم ایک SYN کو دو یا تین SYN-ACKs کے ساتھ بھیجنے کا جواب دیتا ہے، اور آؤٹ پٹ پر حملہ کو دو یا تین گنا سے ضرب دیا جاتا ہے۔
فورم کے اوزار
ایک اہم ٹول جو ہم L7 ورک بوجھ کے لیے استعمال کرتے ہیں وہ Yandex-tank ہے۔ خاص طور پر، ایک پریت کو بندوق کے طور پر استعمال کیا جاتا ہے، اس کے علاوہ کارٹریجز بنانے اور نتائج کا تجزیہ کرنے کے لیے کئی اسکرپٹس موجود ہیں۔
Tcpdump کو نیٹ ورک ٹریفک کا تجزیہ کرنے کے لیے استعمال کیا جاتا ہے، اور Nmap کو سرور کا تجزیہ کرنے کے لیے استعمال کیا جاتا ہے۔ L3 اور 4 کی سطح پر بوجھ بنانے کے لیے، OpenSSL اور DPDK لائبریری کے ساتھ ہمارے اپنے جادو کا تھوڑا سا استعمال کیا جاتا ہے۔ DPDK انٹیل کی ایک لائبریری ہے جو آپ کو لینکس اسٹیک کو نظرانداز کرتے ہوئے نیٹ ورک انٹرفیس کے ساتھ کام کرنے کی اجازت دیتی ہے، اس طرح کارکردگی میں اضافہ ہوتا ہے۔ قدرتی طور پر، ہم نہ صرف L3 اور 4 کی سطح پر، بلکہ L7 کی سطح پر بھی DPDK استعمال کرتے ہیں، کیونکہ یہ ہمیں ایک مشین سے کئی ملین درخواستوں کی حد کے اندر، بہت زیادہ لوڈ بہاؤ پیدا کرنے کی اجازت دیتا ہے۔
ہم کچھ ٹریفک جنریٹر اور خصوصی ٹولز بھی استعمال کرتے ہیں جو ہم مخصوص ٹیسٹوں کے لیے لکھتے ہیں۔ اگر ہم SSH کے تحت کمزوری کو یاد کرتے ہیں، تو مندرجہ بالا سیٹ سے فائدہ نہیں اٹھایا جا سکتا۔ اگر ہم میل پروٹوکول پر حملہ کرتے ہیں، تو ہم میل یوٹیلیٹیز لیتے ہیں یا ان پر اسکرپٹ لکھتے ہیں۔
نتائج
آخر میں میں یہ کہنا چاہوں گا:
- کلاسک لوڈ ٹیسٹنگ کے علاوہ، کشیدگی کی جانچ کرنا ضروری ہے. ہمارے پاس ایک حقیقی مثال ہے جہاں ایک پارٹنر کے ذیلی ٹھیکیدار نے صرف لوڈ ٹیسٹنگ کی ہے۔ اس نے ظاہر کیا کہ وسائل عام بوجھ کو برداشت کر سکتے ہیں۔ لیکن پھر ایک غیر معمولی بوجھ نمودار ہوا، سائٹ دیکھنے والوں نے وسائل کو تھوڑا مختلف طریقے سے استعمال کرنا شروع کر دیا، اور اس کے نتیجے میں ذیلی ٹھیکیدار لیٹ گیا۔ اس طرح، یہ کمزوریوں کو تلاش کرنے کے قابل ہے یہاں تک کہ اگر آپ پہلے سے ہی DDoS حملوں سے محفوظ ہیں۔
- سسٹم کے کچھ حصوں کو دوسروں سے الگ کرنا ضروری ہے۔ اگر آپ کی تلاش ہے، تو آپ کو اسے الگ الگ مشینوں میں منتقل کرنے کی ضرورت ہے، یعنی ڈوکر تک نہیں۔ کیونکہ اگر تلاش یا اجازت نامہ ناکام ہوجاتا ہے، تو کم از کم کچھ کام جاری رہے گا۔ آن لائن اسٹور کی صورت میں، صارفین کیٹلاگ میں پروڈکٹس تلاش کرنا جاری رکھیں گے، ایگریگیٹر سے جائیں گے، خریدیں گے اگر وہ پہلے سے مجاز ہیں، یا OAuth2 کے ذریعے اجازت دیں گے۔
- ہر قسم کی کلاؤڈ سروسز کو نظر انداز نہ کریں۔
- CDN کا استعمال نہ صرف نیٹ ورک کی تاخیر کو بہتر بنانے کے لیے، بلکہ چینل کی تھکن اور محض جامد ٹریفک میں آنے والے حملوں کے خلاف تحفظ کے ایک ذریعہ کے طور پر بھی کریں۔
- خصوصی تحفظ کی خدمات کا استعمال کرنا ضروری ہے۔ آپ اپنے آپ کو چینل کی سطح پر L3 اور 4 حملوں سے محفوظ نہیں رکھ سکتے، کیونکہ آپ کے پاس کافی چینل نہیں ہے۔ آپ کو L7 حملوں سے لڑنے کا بھی امکان نہیں ہے، کیونکہ وہ بہت بڑے ہو سکتے ہیں۔ اس کے علاوہ، چھوٹے حملوں کی تلاش اب بھی خصوصی خدمات، خصوصی الگورتھم کا استحقاق ہے۔
- باقاعدگی سے اپ ڈیٹ کریں۔ یہ نہ صرف دانا پر لاگو ہوتا ہے، بلکہ SSH ڈیمون پر بھی لاگو ہوتا ہے، خاص طور پر اگر آپ نے انہیں باہر سے کھلا رکھا ہو۔ اصولی طور پر، ہر چیز کو اپ ڈیٹ کرنے کی ضرورت ہے، کیونکہ آپ کو خود سے کچھ کمزوریوں کو ٹریک کرنے کا امکان نہیں ہے۔
ماخذ: www.habr.com