ہمارا سائبر ڈیفنس سنٹر کلائنٹس کے ویب انفراسٹرکچر کی حفاظت کا ذمہ دار ہے اور کلائنٹ کی سائٹس پر ہونے والے حملوں کو پسپا کرتا ہے۔ ہم حملوں سے بچانے کے لیے FortiWeb ویب ایپلیکیشن فائر والز (WAF) کا استعمال کرتے ہیں۔ لیکن یہاں تک کہ بہترین WAF بھی ایک علاج نہیں ہے اور ٹارگٹ حملوں سے باہر کی حفاظت نہیں کرتا ہے۔
لہذا، WAF کے علاوہ ہم استعمال کرتے ہیں . یہ تمام واقعات کو ایک جگہ جمع کرنے میں مدد کرتا ہے، اعداد و شمار جمع کرتا ہے، ان کا تصور کرتا ہے اور ہمیں وقت پر ٹارگٹڈ حملہ دیکھنے کی اجازت دیتا ہے۔
آج میں آپ کو مزید تفصیل سے بتاؤں گا کہ ہم نے WAF کے ساتھ "کرسمس ٹری" کو کیسے عبور کیا اور اس سے کیا نکلا۔
ایک حملے کی کہانی: ELK میں منتقلی سے پہلے سب کچھ کیسے کام کرتا تھا۔
کسٹمر کے پاس ہمارے کلاؤڈ میں ایک ایپلیکیشن تعینات ہے جو ہمارے WAF کے پیچھے ہے۔ روزانہ 10 سے 000 صارفین سائٹ سے جڑے ہوئے ہیں، کنکشنز کی تعداد یومیہ 100 ملین تک پہنچ گئی۔ ان میں سے 000-20 صارفین حملہ آور تھے اور انہوں نے سائٹ کو ہیک کرنے کی کوشش کی۔
FortiWeb نے ایک IP ایڈریس سے معمول کے بروٹ فورس فارم کو آسانی سے بلاک کر دیا۔ سائٹ پر فی منٹ ہٹ کی تعداد جائز صارفین سے زیادہ تھی۔ ہم نے صرف ایک پتے سے سرگرمی کی حدیں مقرر کیں اور حملے کو پسپا کیا۔
"سست حملوں" کا مقابلہ کرنا اس وقت زیادہ مشکل ہوتا ہے جب حملہ آور آہستہ سے کام کرتے ہیں اور اپنے آپ کو عام کلائنٹس کا روپ دھارتے ہیں۔ وہ بہت سے منفرد IP پتے استعمال کرتے ہیں۔ اس طرح کی سرگرمی ڈبلیو اے ایف کے لیے ایک بڑی طاقت کی طرح نہیں لگتی تھی؛ اسے خود بخود ٹریک کرنا زیادہ مشکل تھا۔ عام صارفین کے بلاک ہونے کا خطرہ بھی تھا۔ ہم نے حملے کی دیگر علامات کی تلاش کی اور اس نشانی کی بنیاد پر IP پتوں کو خود بخود بلاک کرنے کے لیے ایک پالیسی ترتیب دی۔ مثال کے طور پر، بہت سے ناجائز سیشنز کے HTTP درخواست کے ہیڈر میں مشترکہ فیلڈز تھے۔ ان فیلڈز کو اکثر FortiWeb ایونٹ لاگز میں دستی طور پر تلاش کرنا پڑتا تھا۔
یہ طویل اور غیر آرام دہ نکلا. معیاری FortiWeb فعالیت میں، واقعات کو متن میں 3 مختلف لاگز میں ریکارڈ کیا جاتا ہے: پتہ چلا حملوں، معلومات کی درخواست، اور WAF آپریشن کے بارے میں سسٹم کے پیغامات۔ ایک منٹ میں درجنوں یا یہاں تک کہ سینکڑوں حملے ہو سکتے ہیں۔
اتنا زیادہ نہیں، لیکن آپ کو دستی طور پر کئی لاگز کے ذریعے چڑھنا پڑتا ہے اور بہت سی لائنوں کے ذریعے اعادہ کرنا پڑتا ہے:
اٹیک لاگ میں ہم صارف کے پتے اور سرگرمی کی نوعیت دیکھتے ہیں۔
صرف لاگ ٹیبل کو اسکین کرنا کافی نہیں ہے۔ حملے کی نوعیت کے بارے میں سب سے دلچسپ اور مفید معلومات حاصل کرنے کے لیے، آپ کو ایک مخصوص واقعہ کے اندر دیکھنا ہوگا:
نمایاں کردہ فیلڈز "سست حملے" کا پتہ لگانے میں مدد کرتی ہیں۔ ماخذ: اسکرین شاٹ منجانب .
ٹھیک ہے، سب سے اہم مسئلہ یہ ہے کہ صرف ایک FortiWeb ماہر ہی اس کا پتہ لگا سکتا ہے۔ اگرچہ کاروباری اوقات کے دوران ہم اب بھی حقیقی وقت میں مشکوک سرگرمی کی نگرانی کر سکتے ہیں، لیکن رات کے وقت ہونے والے واقعات کی تفتیش میں زیادہ وقت لگ سکتا ہے۔ جب فورٹی ویب کی پالیسیاں کسی وجہ سے کام نہیں کرتی تھیں، ڈیوٹی پر موجود نائٹ شفٹ انجینئر WAF تک رسائی کے بغیر صورتحال کا جائزہ لینے سے قاصر رہے اور FortiWeb کے ماہر کو جگا دیا۔ ہم نے کئی گھنٹوں کے نوشتہ جات کو دیکھا اور حملے کا لمحہ پایا۔
معلومات کے اتنے حجم کے ساتھ، پہلی نظر میں بڑی تصویر کو سمجھنا اور فعال طور پر کام کرنا مشکل ہے۔ پھر ہم نے ہر چیز کا بصری شکل میں تجزیہ کرنے کے لیے ایک جگہ پر ڈیٹا اکٹھا کرنے کا فیصلہ کیا، حملے کا آغاز معلوم کیا، اس کی سمت اور بلاک کرنے کا طریقہ معلوم کیا۔
آپ نے کس چیز کا انتخاب کیا؟
سب سے پہلے، ہم نے پہلے سے استعمال شدہ حلوں کو دیکھا تاکہ غیر ضروری طور پر اداروں کو ضرب نہ لگائیں۔
پہلے آپشنز میں سے ایک تھا۔ Nagiosجسے ہم نگرانی کے لیے استعمال کرتے ہیں۔ , ، ہنگامی حالات کے بارے میں انتباہات۔ سیکیورٹی گارڈز مشکوک ٹریفک کی صورت میں ڈیوٹی افسران کو مطلع کرنے کے لیے بھی اس کا استعمال کرتے ہیں، لیکن یہ بکھرے ہوئے نوشتہ جات کو جمع کرنے کا طریقہ نہیں جانتا اور اس لیے اب اس کی ضرورت نہیں ہے۔
استعمال کرتے ہوئے ہر چیز کو جمع کرنے کا ایک آپشن موجود تھا۔ MySQL اور PostgreSQL یا دیگر متعلقہ ڈیٹا بیس۔ لیکن ڈیٹا نکالنے کے لیے، آپ کو اپنی ایپلی کیشن خود بنانا پڑی۔
ہماری کمپنی بھی استعمال کرتی ہے۔ فورٹی اینالائزر۔ Fortinet سے. لیکن یہ اس معاملے میں بھی مناسب نہیں تھا۔ سب سے پہلے، یہ فائر وال کے ساتھ کام کرنے کے لیے زیادہ موزوں ہے۔ فورٹی گیٹ. دوم، بہت سی ترتیبات غائب تھیں، اور اس کے ساتھ تعامل کے لیے SQL سوالات کی بہترین معلومات درکار تھیں۔ اور تیسرا، اس کے استعمال سے گاہک کے لیے سروس کی قیمت بڑھ جائے گی۔
اس طرح ہم اوپن سورس کی شکل میں آئے ELK.
ELK کیوں منتخب کریں۔
ELK اوپن سورس پروگراموں کا ایک سیٹ ہے:
- Elasticsearch - ایک ٹائم سیریز ڈیٹا بیس، جو خاص طور پر متن کی بڑی مقدار کے ساتھ کام کرنے کے لیے بنایا گیا تھا۔
- لاگسٹ - ڈیٹا اکٹھا کرنے کا طریقہ کار جو لاگز کو مطلوبہ فارمیٹ میں تبدیل کر سکتا ہے۔
- کبانا - ایک اچھا ویژولائزر، نیز Elasticsearch کے انتظام کے لیے کافی دوستانہ انٹرفیس۔ آپ اسے گراف بنانے کے لیے استعمال کر سکتے ہیں جن کی ڈیوٹی پر موجود انجینئر رات کو نگرانی کر سکتے ہیں۔
ELK میں داخلے کی حد کم ہے۔ تمام بنیادی خصوصیات مفت ہیں۔ خوشی کے لیے اور کیا چاہیے؟
ہم نے یہ سب ایک ہی نظام میں کیسے رکھا؟
ہم نے اشاریہ جات بنائے اور صرف ضروری معلومات چھوڑ دیں۔. ہم نے تینوں FortiWEB لاگز کو ELK میں لوڈ کیا اور آؤٹ پٹ انڈیکس تھا۔ یہ ایک مدت کے لیے تمام جمع شدہ لاگز والی فائلیں ہیں، مثال کے طور پر، ایک دن۔ اگر ہم فوری طور پر ان کا تصور کریں، تو ہمیں صرف حملوں کی حرکیات نظر آئیں گی۔ تفصیلات کے لیے، آپ کو ہر حملے میں "گرنے" اور مخصوص فیلڈز کو دیکھنے کی ضرورت ہے۔
ہم نے محسوس کیا کہ پہلے ہمیں غیر ساختہ معلومات کا تجزیہ ترتیب دینے کی ضرورت ہے۔ ہم نے سٹرنگز کی شکل میں لمبے فیلڈز لیے، جیسے کہ "پیغام" اور "URL"، اور فیصلہ سازی کے لیے مزید معلومات حاصل کرنے کے لیے ان کا تجزیہ کیا۔
مثال کے طور پر، تجزیہ کا استعمال کرتے ہوئے، ہم نے صارف کے مقام کی الگ الگ شناخت کی۔ اس سے روسی صارفین کی سائٹس پر بیرون ملک سے حملوں کو فوری طور پر اجاگر کرنے میں مدد ملی۔ دوسرے ممالک سے تمام رابطوں کو مسدود کر کے، ہم نے حملوں کی تعداد کو نصف تک کم کر دیا اور روس کے اندر ہونے والے حملوں سے پرسکون طریقے سے نمٹ سکے۔
تجزیہ کرنے کے بعد، ہم نے یہ تلاش کرنا شروع کیا کہ کون سی معلومات کو ذخیرہ کرنا اور تصور کرنا ہے۔ جریدے میں سب کچھ چھوڑنا ناقابل عمل تھا: ایک انڈیکس کا سائز بڑا تھا - 7 جی بی۔ ELK نے فائل پر کارروائی کرنے میں کافی وقت لیا۔ تاہم، تمام معلومات کارآمد نہیں تھیں۔ کچھ ڈپلیکیٹ کیا گیا تھا اور اس نے اضافی جگہ لی تھی - اسے بہتر بنانے کی ضرورت تھی۔
پہلے ہم نے صرف انڈیکس کو اسکین کیا اور غیر ضروری واقعات کو ہٹا دیا۔ یہ فورٹی ویب پر لاگ کے ساتھ کام کرنے سے بھی زیادہ تکلیف دہ اور لمبا ثابت ہوا۔ اس مرحلے پر "کرسمس ٹری" کا واحد فائدہ یہ ہے کہ ہم ایک اسکرین پر وقت کی ایک بڑی مدت کو دیکھنے کے قابل تھے۔
ہم مایوس نہیں ہوئے، کیکٹس کھاتے رہے، ELK کا مطالعہ کرتے رہے اور یقین رکھتے تھے کہ ہم ضروری معلومات حاصل کر سکیں گے۔ اشاریہ جات کو صاف کرنے کے بعد، ہم نے تصور کرنا شروع کیا کہ ہمارے پاس کیا تھا۔ اس طرح ہم بڑے ڈیش بورڈز پر آئے۔ ہم نے کچھ ویجٹ آزمائے - بصری اور خوبصورتی سے، ایک حقیقی کرسمس ٹری!
حملے کا لمحہ ریکارڈ کیا گیا۔. اب ہمیں یہ سمجھنے کی ضرورت تھی کہ گراف پر حملے کی شروعات کیسی ہوتی ہے۔ اس کا پتہ لگانے کے لیے، ہم نے صارف کے لیے سرور کے جوابات (واپسی کوڈز) کو دیکھا۔ ہمیں درج ذیل کوڈز (rc) کے ساتھ سرور کے جوابات میں دلچسپی تھی:
کوڈ (rc)
نام
تفصیل
0
ڈراپ
سرور سے درخواست بلاک ہے۔
200
Ok
درخواست پر کامیابی کے ساتھ کارروائی ہوئی۔
400
غلط فرمائش
غلط درخواست
403
حرام
اجازت دینے سے انکار کر دیا گیا۔
500
اندرونی سرور کی خرابی
سروس دستیاب نہیں ہے۔
اگر کسی نے سائٹ پر حملہ کرنا شروع کیا تو کوڈز کا تناسب بدل گیا:
- اگر کوڈ 400 کے ساتھ مزید غلط درخواستیں تھیں، لیکن کوڈ 200 والی عام درخواستوں کی اتنی ہی تعداد باقی رہی، تو اس کا مطلب ہے کہ کوئی سائٹ کو ہیک کرنے کی کوشش کر رہا تھا۔
- اگر اسی وقت کوڈ 0 کے ساتھ درخواستوں میں بھی اضافہ ہوا، تو FortiWeb کے سیاست دانوں نے بھی اس حملے کو "دیکھا" اور اس پر بلاکس لگائے۔
- اگر کوڈ 500 والے پیغامات کی تعداد میں اضافہ ہوتا ہے، تو اس کا مطلب ہے کہ سائٹ ان IP پتوں کے لیے دستیاب نہیں ہے - یہ ایک طرح کی بلاکنگ بھی ہے۔
تیسرے مہینے تک، ہم نے ایسی سرگرمی کو ٹریک کرنے کے لیے ایک ڈیش بورڈ ترتیب دے دیا تھا۔
ہر چیز کی دستی طور پر نگرانی نہ کرنے کے لیے، ہم نے Nagios کے ساتھ انضمام قائم کیا، جس نے کچھ وقفوں پر ELK کو پول کیا۔ اگر مجھے پتہ چلا کہ کوڈز کے ذریعے پہنچنے والی حد کی قدریں، میں نے ڈیوٹی افسران کو مشکوک سرگرمی کے بارے میں ایک اطلاع بھیجی۔
نگرانی کے نظام میں مشترکہ 4 گرافکس. اب گراف پر اس لمحے کو دیکھنا ضروری تھا جب حملہ روکا نہیں گیا تھا اور انجینئر کی مداخلت کی ضرورت تھی۔ 4 مختلف چارٹس پر ہماری آنکھیں دھندلا گئیں۔ لہذا، ہم نے چارٹس کو یکجا کیا اور ایک اسکرین پر ہر چیز کی نگرانی شروع کردی۔
نگرانی کے دوران، ہم نے دیکھا کہ مختلف رنگوں کے گراف کیسے بدلتے ہیں۔ سرخ رنگ کے چھینٹے نے ظاہر کیا کہ حملہ شروع ہو چکا ہے، جبکہ نارنجی اور نیلے رنگ کے گراف نے FortiWeb کا ردعمل دکھایا:
یہاں سب کچھ ٹھیک ہے: "سرخ" سرگرمی میں اضافہ ہوا، لیکن FortiWeb نے اس کا مقابلہ کیا اور حملے کا شیڈول بے کار ہو گیا۔
ہم نے اپنے لیے ایک گراف کی مثال بھی کھینچی جس میں مداخلت کی ضرورت ہے:
یہاں ہم دیکھتے ہیں کہ FortiWeb کی سرگرمی میں اضافہ ہوا ہے، لیکن سرخ حملے کا گراف کم نہیں ہوا ہے۔ آپ کو اپنی WAF کی ترتیبات کو تبدیل کرنے کی ضرورت ہے۔
رات کے واقعات کی تفتیش بھی آسان ہو گئی ہے۔ گراف فوری طور پر اس لمحے کو ظاہر کرتا ہے جب سائٹ کی حفاظت کا وقت آنے والا ہے۔
رات کو کبھی کبھی ایسا ہوتا ہے۔ ریڈ گراف - حملہ شروع ہو چکا ہے۔ بلیو - فورٹی ویب سرگرمی۔ حملے کو مکمل طور پر روکا نہیں گیا تھا، اس لیے مجھے مداخلت کرنا پڑی۔
ہم کہاں جا رہے ہیں؟
ہم فی الحال ڈیوٹی ایڈمنسٹریٹرز کو ELK کے ساتھ کام کرنے کی تربیت دے رہے ہیں۔ ڈیوٹی پر موجود افراد ڈیش بورڈ پر صورتحال کا جائزہ لینا اور فیصلہ کرنا سیکھتے ہیں: یہ وقت ہے کہ کسی FortiWeb ماہر کے پاس جائیں، یا WAF کی پالیسیاں خود بخود حملے کو پسپا کرنے کے لیے کافی ہیں۔ اس طرح ہم رات کے وقت انفارمیشن سیکیورٹی انجینئرز پر بوجھ کو کم کرتے ہیں اور سسٹم کی سطح پر سپورٹ رولز کو تقسیم کرتے ہیں۔ FortiWeb تک رسائی صرف سائبر ڈیفنس سنٹر کے پاس رہتی ہے، اور جب بالکل ضروری ہو تب ہی وہ WAF کی ترتیبات میں تبدیلیاں کرتے ہیں۔
ہم صارفین کے لیے رپورٹنگ پر بھی کام کر رہے ہیں۔ ہمارا منصوبہ ہے کہ WAF آپریشن کی حرکیات کا ڈیٹا کلائنٹ کے ذاتی اکاؤنٹ میں دستیاب ہوگا۔ ELK خود WAF سے رابطہ کیے بغیر صورتحال کو مزید شفاف بنائے گا۔
اگر صارف حقیقی وقت میں اپنے تحفظ کی نگرانی کرنا چاہتا ہے، تو ELK بھی کام آئے گا۔ ہم WAF تک رسائی نہیں دے سکتے، کیونکہ کام میں کسٹمر کی مداخلت دوسروں کو متاثر کر سکتی ہے۔ لیکن آپ ایک علیحدہ ELK اٹھا سکتے ہیں اور اسے "کھیلنے" کے لیے دے سکتے ہیں۔
یہ "کرسمس ٹری" کو استعمال کرنے کے منظرنامے ہیں جو ہم نے حال ہی میں جمع کیے ہیں۔ اس معاملے پر اپنے خیالات کا اشتراک کریں اور نہ بھولیں۔ ڈیٹا بیس لیک ہونے سے بچنے کے لیے۔
ماخذ: www.habr.com