یہ مضمون سیریز کا چوتھا مضمون ہے "اپنے نیٹ ورک کے بنیادی ڈھانچے کو کیسے کنٹرول کریں۔" سیریز کے تمام مضامین کے مواد اور لنکس مل سکتے ہیں۔ یہاں.

В پہلا حصہ اس باب میں، ہم نے ڈیٹا سینٹر کے حصے میں نیٹ ورک سیکیورٹی کے کچھ پہلوؤں کو دیکھا۔ یہ حصہ "انٹرنیٹ رسائی" کے حصے کے لیے وقف کیا جائے گا۔

انٹرنیٹ تک رسائی

سیکورٹی کا موضوع بلاشبہ ڈیٹا نیٹ ورکس کی دنیا میں سب سے پیچیدہ موضوعات میں سے ایک ہے۔ جیسا کہ پچھلے معاملات میں، گہرائی اور مکمل ہونے کا دعوی کیے بغیر، میں یہاں کافی آسان پر غور کروں گا، لیکن، میری رائے میں، اہم سوالات، جن کے جوابات، مجھے امید ہے کہ، آپ کے نیٹ ورک کی سیکیورٹی کی سطح کو بڑھانے میں مدد کریں گے۔

اس طبقہ کا آڈٹ کرتے وقت، درج ذیل پہلوؤں پر توجہ دیں:

• ڈیزائن
• بی جی پی کی ترتیبات
• DOS/DDOS تحفظ
• فائر وال پر ٹریفک فلٹرنگ

ڈیزائن

ایک انٹرپرائز نیٹ ورک کے لیے اس طبقہ کے ڈیزائن کی ایک مثال کے طور پر، میں تجویز کروں گا۔ رہنما اندر سسکو سے محفوظ ماڈلز.

یقینا، شاید دوسرے دکانداروں کا حل آپ کو زیادہ پرکشش لگے گا (دیکھیں۔ گارٹنر کواڈرینٹ 2018)، لیکن آپ کو اس ڈیزائن کی تفصیل سے پیروی کرنے کی ترغیب دیے بغیر، مجھے اب بھی اس کے پیچھے کے اصولوں اور نظریات کو سمجھنا مفید معلوم ہوتا ہے۔

نوٹ

SAFE میں، "ریموٹ ایکسیس" سیگمنٹ "انٹرنیٹ رسائی" سیگمنٹ کا حصہ ہے۔ لیکن مضامین کے اس سلسلے میں ہم اس پر الگ سے غور کریں گے۔

انٹرپرائز نیٹ ورک کے لیے اس سیگمنٹ میں سامان کا معیاری سیٹ ہے۔

• بارڈر راؤٹرز
• فائر والز

ریمارک 1۔

مضامین کے اس سلسلے میں، جب میں فائر والز کے بارے میں بات کرتا ہوں تو میرا مطلب ہے۔ این جی ایف ڈبلیو.

ریمارک 2۔

میں مختلف قسم کے L2/L1 پر غور کرنا چھوڑتا ہوں یا L2 حلوں پر L3 کو اوورلے کرتا ہوں تاکہ L1/L2 کنیکٹیوٹی کو یقینی بنایا جا سکے اور خود کو صرف L3 سطح اور اس سے اوپر کے مسائل تک محدود رکھا جائے۔ جزوی طور پر، باب میں L1/L2 مسائل پر تبادلہ خیال کیا گیا۔صفائی اور دستاویزات".

اگر آپ کو اس سیگمنٹ میں فائر وال نہیں ملا ہے، تو آپ کو کسی نتیجے پر پہنچنے میں جلدی نہیں کرنی چاہیے۔

آئیے ویسا ہی کرتے ہیں جیسا کہ میں ہے۔ پچھلے حصہآئیے سوال کے ساتھ شروع کریں: کیا آپ کے معاملے میں اس سیگمنٹ میں فائر وال کا استعمال ضروری ہے؟

میں کہہ سکتا ہوں کہ فائر والز کو استعمال کرنے اور پیچیدہ ٹریفک فلٹرنگ الگورتھم کو لاگو کرنے کے لیے یہ سب سے زیادہ جائز جگہ معلوم ہوتی ہے۔ میں حصہ 1 ہم نے 4 عوامل کا ذکر کیا جو ڈیٹا سینٹر کے حصے میں فائر وال کے استعمال کو روک سکتے ہیں۔ لیکن یہاں وہ اب اتنے اہم نہیں رہے۔

مثال 1. تاخیر۔

جہاں تک انٹرنیٹ کا تعلق ہے، تقریباً 1 ملی سیکنڈ کی تاخیر کے بارے میں بات کرنے کا کوئی فائدہ نہیں ہے۔ لہذا، اس حصے میں تاخیر فائر وال کے استعمال کو محدود کرنے والا عنصر نہیں ہو سکتا۔

مثال 2. کارکردگی

بعض صورتوں میں یہ عنصر اب بھی اہم ہو سکتا ہے۔ لہذا، آپ کو کچھ ٹریفک (مثال کے طور پر، لوڈ بیلنسرز سے ٹریفک) کو فائر وال کو بائی پاس کرنے کی اجازت دینی پڑ سکتی ہے۔

مثال 3. وشوسنییتا

اس عنصر کو اب بھی مدنظر رکھنے کی ضرورت ہے، لیکن پھر بھی، خود انٹرنیٹ کی ناقابل اعتباریت کو دیکھتے ہوئے، اس طبقہ کے لیے اس کی اہمیت اتنی نہیں ہے جتنی کہ ڈیٹا سینٹر کے لیے۔

تو، آئیے فرض کریں کہ آپ کی سروس http/https (مختصر سیشنز کے ساتھ) کے اوپر رہتی ہے۔ اس صورت میں، آپ دو آزاد خانوں (HA کے بغیر) استعمال کر سکتے ہیں اور اگر ان میں سے ایک کے ساتھ روٹنگ کا مسئلہ ہو تو تمام ٹریفک کو دوسرے میں منتقل کر دیں۔

یا آپ فائر وال کو شفاف موڈ میں استعمال کر سکتے ہیں اور، اگر وہ ناکام ہو جاتے ہیں، تو ٹریفک کو مسئلے کو حل کرتے ہوئے فائر وال کو بائی پاس کرنے کی اجازت دیں۔

لہذا، زیادہ تر امکان صرف قیمت وہ عنصر ہو سکتا ہے جو آپ کو اس سیگمنٹ میں فائر والز کا استعمال ترک کرنے پر مجبور کر دے گا۔

اہم!

اس فائر وال کو ڈیٹا سینٹر فائر وال کے ساتھ جوڑنے کا ایک لالچ ہے (ان حصوں کے لیے ایک فائر وال استعمال کریں)۔ حل، اصولی طور پر، ممکن ہے، لیکن آپ کو یہ سمجھنے کی ضرورت ہے کیونکہ انٹرنیٹ تک رسائی کا فائر وال درحقیقت آپ کے دفاع میں سب سے آگے ہے اور کم از کم کچھ نقصان دہ ٹریفک کو "لے لیتا ہے"، پھر یقیناً، آپ کو اس بڑھتے ہوئے خطرے کو مدنظر رکھنا ہوگا کہ اس فائر وال کو غیر فعال کر دیا جائے گا۔ یعنی، ان دو حصوں میں ایک جیسے آلات استعمال کرنے سے، آپ اپنے ڈیٹا سینٹر سیگمنٹ کی دستیابی کو نمایاں طور پر کم کر دیں گے۔

ہمیشہ کی طرح، آپ کو یہ سمجھنے کی ضرورت ہے کہ کمپنی جو سروس فراہم کرتی ہے اس پر منحصر ہے، اس سیگمنٹ کا ڈیزائن بہت مختلف ہو سکتا ہے۔ ہمیشہ کی طرح، آپ اپنی ضروریات کے مطابق مختلف طریقوں کا انتخاب کر سکتے ہیں۔

مثال کے طور پر

اگر آپ مواد فراہم کرنے والے ہیں، CDN نیٹ ورک کے ساتھ (دیکھیں، مثال کے طور پر، مضامین کی سیریز)، پھر آپ ٹریفک کو روٹنگ اور فلٹر کرنے کے لیے الگ الگ ڈیوائسز کا استعمال کرتے ہوئے درجنوں یا یہاں تک کہ سینکڑوں مقامات پر انفراسٹرکچر بنانا نہیں چاہتے ہیں۔ یہ مہنگا ہو گا، اور یہ صرف غیر ضروری ہو سکتا ہے.

بی جی پی کے لیے ضروری نہیں کہ آپ کے پاس مخصوص راؤٹرز ہوں، آپ اوپن سورس ٹولز استعمال کر سکتے ہیں جیسے کوآگا. تو شاید آپ کو صرف ایک سرور یا کئی سرورز، ایک سوئچ اور BGP کی ضرورت ہے۔

اس صورت میں، آپ کا سرور یا متعدد سرورز نہ صرف ایک CDN سرور بلکہ ایک روٹر کا بھی کردار ادا کر سکتے ہیں۔ بلاشبہ، ابھی بھی بہت ساری تفصیلات موجود ہیں (جیسے کہ توازن کو یقینی بنانے کا طریقہ)، لیکن یہ قابل عمل ہے، اور یہ ایک ایسا طریقہ ہے جسے ہم نے اپنے شراکت داروں میں سے ایک کے لیے کامیابی کے ساتھ استعمال کیا ہے۔

آپ کے پاس مکمل تحفظ (فائر والز، آپ کے انٹرنیٹ فراہم کنندگان کی طرف سے فراہم کردہ DDOS تحفظ کی خدمات) اور صرف L2 سوئچز اور سرورز کے ساتھ درجنوں یا سینکڑوں "آسان" پوائنٹس موجود ہیں۔

لیکن اس معاملے میں تحفظ کا کیا ہوگا؟

آئیے، مثال کے طور پر، حال ہی میں مقبول کو دیکھتے ہیں۔ ڈی این ایس ایمپلیفیکیشن ڈی ڈی او ایس حملہ. اس کا خطرہ اس حقیقت میں مضمر ہے کہ ٹریفک کی ایک بڑی مقدار پیدا ہوتی ہے، جو آپ کے تمام اپ لنکس کا 100% صرف "بند" کر دیتی ہے۔

ہمارے ڈیزائن کے معاملے میں ہمارے پاس کیا ہے۔

• اگر آپ AnyCast استعمال کرتے ہیں، تو ٹریفک کو آپ کی موجودگی کے مقامات کے درمیان تقسیم کیا جاتا ہے۔ اگر آپ کی کل بینڈوتھ ٹیرا بِٹ ہے، تو یہ بذاتِ خود (تاہم، حال ہی میں ٹیرابِٹس کے آرڈر پر بدنیتی پر مبنی ٹریفک کے ساتھ کئی حملے ہوئے ہیں) آپ کو "اوور فلونگ" اپ لنکس سے بچاتا ہے۔
• اگر، تاہم، کچھ اپ لنکس بند ہو جاتے ہیں، تو آپ صرف اس سائٹ کو سروس سے ہٹا دیں (سابقہ ​​تشہیر بند کریں)
• آپ اپنے "مکمل" (اور، اس کے مطابق، محفوظ) ڈیٹا سینٹرز سے بھیجی جانے والی ٹریفک کا حصہ بھی بڑھا سکتے ہیں، اس طرح نقصاندہ ٹریفک کے ایک اہم حصے کو موجودگی کے غیر محفوظ مقامات سے ہٹا سکتے ہیں۔

اور اس مثال کے لیے ایک اور چھوٹا نوٹ۔ اگر آپ IXs کے ذریعے کافی ٹریفک بھیجتے ہیں، تو یہ اس طرح کے حملوں کے لیے آپ کے خطرے کو بھی کم کرتا ہے۔

BGP قائم کرنا

یہاں دو موضوعات ہیں۔

• کنیکٹوٹی
• BGP قائم کرنا

ہم نے پہلے ہی رابطے کے بارے میں تھوڑی بات کی ہے۔ حصہ 1. نقطہ اس بات کو یقینی بنانا ہے کہ آپ کے گاہکوں کو ٹریفک زیادہ سے زیادہ راستے کی پیروی کرتا ہے. اگرچہ آپٹیملٹی ہمیشہ صرف تاخیر کے بارے میں نہیں ہوتی ہے، لیکن کم تاخیر عام طور پر زیادہ سے زیادہ کا اہم اشارہ ہے۔ کچھ کمپنیوں کے لیے یہ زیادہ اہم ہے، دوسروں کے لیے کم ہے۔ یہ سب آپ کی فراہم کردہ سروس پر منحصر ہے۔

مثال کے طور پر 1

اگر آپ ایک ایکسچینج ہیں، اور آپ کے کلائنٹس کے لیے ملی سیکنڈ سے کم وقت کے وقفے اہم ہیں، تو یقیناً، کسی بھی قسم کے انٹرنیٹ کے بارے میں کوئی بات نہیں ہو سکتی۔

مثال کے طور پر 2

اگر آپ گیمنگ کمپنی ہیں اور دسیوں ملی سیکنڈز آپ کے لیے اہم ہیں، تو یقیناً آپ کے لیے کنیکٹیویٹی بہت اہم ہے۔

مثال کے طور پر 3

آپ کو یہ بھی سمجھنے کی ضرورت ہے کہ، TCP پروٹوکول کی خصوصیات کی وجہ سے، ایک TCP سیشن میں ڈیٹا کی منتقلی کی شرح بھی RTT (راؤنڈ ٹرپ ٹائم) پر منحصر ہے۔ مواد کی تقسیم کے سرورز کو اس مواد کے صارفین کے قریب لے جا کر اس مسئلے کو حل کرنے کے لیے CDN نیٹ ورکس بھی بنائے جا رہے ہیں۔

کنیکٹیویٹی کا مطالعہ اپنے طور پر ایک دلچسپ موضوع ہے، جو اس کے اپنے مضمون یا مضامین کی سیریز کے لائق ہے، اور اس کے لیے اچھی سمجھ کی ضرورت ہے کہ انٹرنیٹ کیسے کام کرتا ہے۔

مفید وسائل:

ripe.net
bgp.he.net

مثال کے طور پر

میں صرف ایک چھوٹی سی مثال دیتا ہوں۔

آئیے فرض کریں کہ آپ کا ڈیٹا سینٹر ماسکو میں واقع ہے، اور آپ کے پاس ایک ہی اپلنک ہے - Rostelecom (AS12389)۔ اس صورت میں (سنگل ہومڈ) آپ کو BGP کی ضرورت نہیں ہے، اور آپ غالباً Rostelecom کے ایڈریس پول کو عوامی پتے کے طور پر استعمال کرتے ہیں۔

آئیے فرض کریں کہ آپ ایک خاص سروس فراہم کرتے ہیں، اور آپ کے پاس یوکرین کے گاہکوں کی کافی تعداد ہے، اور وہ طویل تاخیر کی شکایت کرتے ہیں۔ اپنی تحقیق کے دوران، آپ کو پتہ چلا کہ ان میں سے کچھ کے IP ایڈریس 37.52.0.0/21 گرڈ میں ہیں۔

ٹریسروٹ چلا کر، آپ نے دیکھا کہ ٹریفک AS1299 (Telia) سے گزر رہی ہے، اور پنگ چلانے سے، آپ کو اوسطاً 70 - 80 ملی سیکنڈز کا RTT ملا۔ آپ اسے پر بھی دیکھ سکتے ہیں۔ نظر آنے والا گلاس Rostelecom.

whois یوٹیلیٹی (ripe.net یا مقامی یوٹیلیٹی پر) کا استعمال کرتے ہوئے، آپ آسانی سے تعین کر سکتے ہیں کہ بلاک 37.52.0.0/21 کا تعلق AS6849 (Ukrtelecom) سے ہے۔

اگلا، جا کر bgp.he.net آپ دیکھ رہے ہیں کہ AS6849 کا AS12389 کے ساتھ کوئی تعلق نہیں ہے (وہ نہ تو کلائنٹ ہیں اور نہ ہی ایک دوسرے سے اپلنک، اور نہ ہی ان کا پیئرنگ ہے)۔ لیکن اگر آپ دیکھیں ساتھیوں کی فہرست AS6849 کے لیے، آپ دیکھیں گے، مثال کے طور پر، AS29226 (Mastertel) اور AS31133 (Megafon)۔

ایک بار جب آپ کو ان فراہم کنندگان کا نظر آنے والا شیشہ مل جاتا ہے، تو آپ راستے اور RTT کا موازنہ کر سکتے ہیں۔ مثال کے طور پر، Mastertel RTT کے لیے تقریباً 30 ملی سیکنڈ کا ہوگا۔

لہذا، اگر آپ کی سروس کے لیے 80 اور 30 ​​ملی سیکنڈ کا فرق اہم ہے، تو شاید آپ کو کنیکٹیویٹی کے بارے میں سوچنے کی ضرورت ہے، اپنا AS نمبر، RIPE سے اپنا ایڈریس پول حاصل کرنا اور اضافی اپ لنکس کو جوڑنا اور/یا IXs پر موجودگی کے پوائنٹس بنانے کی ضرورت ہے۔

جب آپ BGP استعمال کرتے ہیں، تو آپ کو نہ صرف کنیکٹیویٹی کو بہتر بنانے کا موقع ملتا ہے، بلکہ آپ بے کار طریقے سے اپنا انٹرنیٹ کنکشن برقرار رکھتے ہیں۔

یہ دستاویز BGP کو ترتیب دینے کے لیے سفارشات پر مشتمل ہے۔ اس حقیقت کے باوجود کہ یہ سفارشات فراہم کنندگان کے "بہترین عمل" کی بنیاد پر تیار کی گئی ہیں، اس کے باوجود (اگر آپ کی BGP ترتیبات بالکل بنیادی نہیں ہیں) وہ بلاشبہ کارآمد ہیں اور درحقیقت اس سختی کا حصہ ہونا چاہیے جس پر ہم نے بحث کی ہے۔ پہلا حصہ.

DOS/DDOS تحفظ

اب DOS/DDOS حملے بہت سی کمپنیوں کے لیے روزمرہ کی حقیقت بن چکے ہیں۔ درحقیقت، آپ پر اکثر کسی نہ کسی شکل میں حملہ کیا جاتا ہے۔ حقیقت یہ ہے کہ آپ نے ابھی تک اس پر توجہ نہیں دی ہے اس کا مطلب صرف یہ ہے کہ ابھی تک آپ کے خلاف ٹارگٹڈ حملہ منظم نہیں کیا گیا ہے، اور یہ کہ حفاظتی اقدامات جو آپ استعمال کرتے ہیں، یہاں تک کہ اسے جانے بغیر بھی (آپریٹنگ سسٹم کے مختلف بلٹ ان تحفظات) کے لیے کافی ہیں۔ اس بات کو یقینی بنائیں کہ آپ اور آپ کے صارفین کے لیے فراہم کردہ سروس کی تنزلی کو کم سے کم کیا جائے۔

انٹرنیٹ کے وسائل ہیں جو آلات کے لاگز کی بنیاد پر حقیقی وقت میں حملے کے خوبصورت نقشے تیار کرتے ہیں۔

یہاں آپ ان کے لنکس تلاش کر سکتے ہیں۔

میرا پسندیدہ نقشہ چیک پوائنٹ سے

DDOS/DOS کے خلاف تحفظ عام طور پر تہہ دار ہوتا ہے۔ یہ سمجھنے کے لیے کہ کیوں، آپ کو یہ سمجھنا ہوگا کہ کس قسم کے DOS/DDOS حملے موجود ہیں (دیکھیں، مثال کے طور پر، یہاں یا یہاں)

یعنی ہمارے پاس تین قسم کے حملے ہیں:

• حجمی حملے
• پروٹوکول حملے
• درخواست کے حملے

اگر آپ اپنے آپ کو آخری دو قسم کے حملوں سے بچا سکتے ہیں، مثال کے طور پر، فائر والز، تو آپ اپنے آپ کو ان حملوں سے نہیں بچا سکتے جن کا مقصد آپ کے اپ لنکس کو "زبردست" کرنا ہے (یقیناً، اگر آپ کے انٹرنیٹ چینلز کی کل صلاحیت کو ٹیرا بِٹس میں شمار نہیں کیا جاتا ہے، یا اس سے بھی بہتر، دسیوں ٹیرابٹ میں)۔

لہذا، دفاع کی پہلی لائن "وومیٹرک" حملوں کے خلاف تحفظ ہے، اور آپ کے فراہم کنندہ یا فراہم کنندگان کو آپ کو یہ تحفظ فراہم کرنا چاہیے۔ اگر آپ کو ابھی تک اس کا احساس نہیں ہوا ہے، تو آپ ابھی کے لیے خوش قسمت ہیں۔

مثال کے طور پر

مان لیں کہ آپ کے پاس کئی اپ لنکس ہیں، لیکن فراہم کنندگان میں سے صرف ایک ہی آپ کو یہ تحفظ فراہم کر سکتا ہے۔ لیکن اگر تمام ٹریفک ایک فراہم کنندہ سے گزرتی ہے، تو پھر اس کنیکٹیویٹی کا کیا ہوگا جس پر ہم نے تھوڑی دیر پہلے مختصراً بات کی تھی؟

اس صورت میں، آپ کو حملے کے دوران جزوی طور پر رابطے کی قربانی دینا ہوگی۔ لیکن

• یہ صرف حملے کی مدت کے لیے ہے۔ حملے کی صورت میں، آپ BGP کو دستی طور پر یا خود بخود دوبارہ ترتیب دے سکتے ہیں تاکہ ٹریفک صرف اس فراہم کنندہ سے گزرے جو آپ کو "چھتری" فراہم کرتا ہے۔ حملہ ختم ہونے کے بعد، آپ روٹنگ کو اس کی سابقہ ​​حالت میں واپس کر سکتے ہیں۔
• تمام ٹریفک کو منتقل کرنا ضروری نہیں ہے۔ اگر، مثال کے طور پر، آپ دیکھتے ہیں کہ کچھ اپ لنکس یا پیئرنگز کے ذریعے کوئی حملہ نہیں ہوا ہے (یا ٹریفک اہم نہیں ہے)، تو آپ ان BGP پڑوسیوں کے لیے مسابقتی صفات کے ساتھ سابقے کی تشہیر جاری رکھ سکتے ہیں۔

آپ اپنے شراکت داروں کو "پروٹوکول حملوں" اور "ایپلیکیشن حملوں" سے تحفظ بھی سونپ سکتے ہیں۔
یہاں یہاں آپ ایک اچھا مطالعہ پڑھ سکتے ہیں (ترجمہ)۔ یہ سچ ہے کہ مضمون دو سال پرانا ہے، لیکن اس سے آپ کو ان طریقوں کا اندازہ ہو جائے گا کہ آپ DDOS کے حملوں سے کیسے بچ سکتے ہیں۔

اصولی طور پر، آپ اپنے تحفظ کو مکمل طور پر آؤٹ سورس کرتے ہوئے خود کو اس تک محدود کر سکتے ہیں۔ اس فیصلے کے فائدے تو ہیں لیکن ایک واضح نقصان بھی ہے۔ حقیقت یہ ہے کہ ہم کاروبار کی بقا کے بارے میں بات کر سکتے ہیں (دوبارہ، اس پر منحصر ہے کہ آپ کی کمپنی کیا کرتی ہے)۔ اور ایسی چیزوں پر تیسرے فریق پر بھروسہ کریں...

لہذا، آئیے دیکھتے ہیں کہ دفاع کی دوسری اور تیسری لائنوں کو کیسے منظم کیا جائے (فراہم کرنے والے سے تحفظ کے اضافے کے طور پر)۔

لہذا، دفاع کی دوسری لائن آپ کے نیٹ ورک کے داخلی راستے پر فلٹرنگ اور ٹریفک محدود کرنے والے (پولیسرز) ہیں۔

مثال کے طور پر 1

آئیے فرض کریں کہ آپ نے فراہم کنندگان میں سے ایک کی مدد سے اپنے آپ کو DDOS کے خلاف چھتری سے ڈھانپ لیا ہے۔ آئیے فرض کریں کہ یہ فراہم کنندہ اپنے نیٹ ورک کے کنارے پر ٹریفک اور فلٹرز کو فلٹر کرنے کے لیے Arbor کا استعمال کرتا ہے۔

بینڈوڈتھ جس پر آربر "پراسیس" کر سکتا ہے، وہ محدود ہے، اور فراہم کنندہ، یقیناً، اپنے تمام شراکت داروں کی ٹریفک کو مستقل طور پر منتقل نہیں کر سکتا جو فلٹرنگ آلات کے ذریعے اس سروس کا آرڈر دیتے ہیں۔ لہذا، عام حالات میں، ٹریفک کو فلٹر نہیں کیا جاتا ہے.

آئیے فرض کریں کہ SYN سیلاب کا حملہ ہے۔ یہاں تک کہ اگر آپ نے ایسی سروس کا آرڈر دیا ہے جو حملے کی صورت میں ٹریفک کو خودکار طور پر فلٹرنگ میں تبدیل کر دیتی ہے، یہ فوری طور پر نہیں ہوتا ہے۔ ایک منٹ یا اس سے زیادہ کے لیے آپ حملے کی زد میں رہتے ہیں۔ اور یہ آپ کے آلات کی ناکامی یا سروس کے انحطاط کا باعث بن سکتا ہے۔ اس صورت میں، کنارے کی روٹنگ پر ٹریفک کو محدود کرنا، اگرچہ یہ اس حقیقت کی طرف لے جائے گا کہ اس دوران کچھ TCP سیشنز قائم نہیں ہوں گے، یہ آپ کے بنیادی ڈھانچے کو بڑے پیمانے پر مسائل سے بچائے گا۔

مثال کے طور پر 2

غیر معمولی طور پر بڑی تعداد میں SYN پیکٹس نہ صرف SYN سیلاب کے حملے کا نتیجہ ہو سکتے ہیں۔ فرض کریں کہ آپ ایک ایسی سروس فراہم کرتے ہیں جس میں آپ بیک وقت تقریباً 100 ہزار TCP کنکشن رکھ سکتے ہیں (ایک ڈیٹا سینٹر سے)۔

چلیں یہ کہتے ہیں کہ آپ کے اہم فراہم کنندگان میں سے ایک کے ساتھ مختصر مدت کے مسئلے کے نتیجے میں، آپ کے آدھے سیشنز کو لات مار دی گئی ہے۔ اگر آپ کی درخواست کو اس طرح سے ڈیزائن کیا گیا ہے کہ، دو بار سوچے بغیر، یہ فوری طور پر (یا کچھ وقت کے وقفے کے بعد جو تمام سیشنز کے لیے یکساں ہے) کنکشن کو دوبارہ قائم کرنے کی کوشش کرتا ہے، تو آپ کو کم از کم 50 ہزار SYN پیکٹ ملیں گے۔ ایک ہی وقت میں.

اگر، مثال کے طور پر، آپ کو ان سیشنز کے سب سے اوپر ssl/tls ہینڈ شیک چلانا ہے، جس میں سرٹیفکیٹس کا تبادلہ شامل ہے، تو آپ کے لوڈ بیلنس کے وسائل کو ختم کرنے کے نقطہ نظر سے، یہ ایک سادہ سے زیادہ مضبوط "DDOS" ہوگا۔ SYN سیلاب۔ ایسا لگتا ہے کہ توازن رکھنے والوں کو اس طرح کے واقعات کو سنبھالنا چاہئے، لیکن... بدقسمتی سے، ہمیں اس طرح کی پریشانی کا سامنا ہے۔

اور، یقینا، کنارے روٹر پر ایک پولیسر اس معاملے میں بھی آپ کے سامان کو بچائے گا۔

DDOS/DOS کے خلاف تحفظ کی تیسری سطح آپ کی فائر وال کی ترتیبات ہیں۔

یہاں آپ دوسری اور تیسری قسم کے حملوں کو روک سکتے ہیں۔ عام طور پر، فائر وال تک پہنچنے والی ہر چیز کو یہاں فلٹر کیا جا سکتا ہے۔

ٹپ

فائر وال کو جتنا ممکن ہو کم کام دینے کی کوشش کریں، دفاع کی پہلی دو لائنوں پر جتنا ممکن ہو فلٹر کریں۔ اور اسی لیے۔

کیا آپ کے ساتھ کبھی ایسا ہوا ہے کہ اتفاق سے، چیک کرنے کے لیے ٹریفک پیدا کرتے ہوئے، مثال کے طور پر، آپ کے سرورز کا آپریٹنگ سسٹم DDOS حملوں کے خلاف کتنا مزاحم ہے، آپ نے اپنی فائر وال کو "مار دیا"، اسے 100 فیصد لوڈ کر کے، ٹریفک معمول کی شدت کے ساتھ ? اگر نہیں، تو شاید یہ صرف اس لیے ہے کہ آپ نے کوشش نہیں کی؟

عام طور پر، فائر وال، جیسا کہ میں نے کہا، ایک پیچیدہ چیز ہے، اور یہ معلوم کمزوریوں اور آزمائشی حلوں کے ساتھ اچھی طرح کام کرتی ہے، لیکن اگر آپ کچھ غیر معمولی، صرف کچھ ردی کی ٹوکری یا غلط ہیڈر کے ساتھ پیکٹ بھیجتے ہیں، تو آپ کچھ کے ساتھ ہیں، نہیں کے ساتھ۔ اتنا چھوٹا امکان (میرے تجربے کی بنیاد پر)، آپ اوپر والے سامان کو بھی حیران کر سکتے ہیں۔ لہذا، مرحلہ 2 پر، باقاعدہ ACLs کا استعمال کرتے ہوئے (L3/L4 سطح پر)، صرف اپنے نیٹ ورک میں ٹریفک کی اجازت دیں جو وہاں داخل ہو۔

فائر وال پر ٹریفک کو فلٹر کرنا

آئیے فائر وال کے بارے میں بات چیت جاری رکھیں۔ آپ کو یہ سمجھنے کی ضرورت ہے کہ DOS/DDOS حملے صرف ایک قسم کے سائبر حملے ہیں۔

DOS/DDOS تحفظ کے علاوہ، ہمارے پاس درج ذیل خصوصیات کی فہرست کی طرح کچھ بھی ہو سکتا ہے:

• ایپلی کیشن فائر والنگ
• خطرے کی روک تھام (اینٹی وائرس، اینٹی اسپائی ویئر، اور کمزوری)
• یو آر ایل فلٹرنگ
• ڈیٹا فلٹرنگ (مواد فلٹرنگ)
• فائل بلاکنگ (فائل کی قسمیں مسدود کرنا)

یہ آپ پر منحصر ہے کہ آپ کو اس فہرست سے کیا ضرورت ہے۔

جاری رکھنا

ماخذ: www.habr.com