كيفية الوقاية من هجمات انتحال عناوين IP
أين ينبغي وضع ترشيح المصدر، ومتى تؤدي فحوص المسار العكسي الصارمة إلى كسر حركة المرور المشروعة، ولماذا تحتاج المصادقة وIPv6 إلى عناية منفصلة.
التحقق من مسار التسليم وتحديد من يُسمح له بالدخول مهمتان منفصلتان. ويحتاج التحقق من المصدر والمصادقة إلى ضوابط خاصة بكل منهما.
يمكن لمكتب الاستقبال التحقق من أن عملية التسليم جاءت عبر مسار متوقع. لكن على الشخص الذي يتلقاها أن يقرر أيضاً من يُسمح له بدخول المبنى. ولدى الشبكات تقسيم مماثل للعمل: التحقق من المكان الذي تدّعي حركة المرور أنها جاءت منه، ثم مصادقة الوصول إلى الخدمة.
ضع الفحص الأول بالقرب من المصدر
يعرف مشغّل الشبكة نطاقات العناوين التي ينبغي أن تصل عبر اتصال العميل. ويمكن رفض الحزم التي تدّعي مصدراً غير ذي صلة هناك، قبل أن تسافر أبعد. وهذا هو نهج التحقق من المصدر الموصوف في BCP 38.
في شبكة الشركة، افحص حركة المرور الخارجة نحو الإنترنت وكذلك حركة المرور الواردة من الخارج. فالحد نفسه يمثل خروجاً من شبكة ودخولاً إلى أخرى. حدّد المصادر المتوقعة لكل اتصال، بما في ذلك النطاقات المفوّضة المشروعة، بدلاً من تطبيق قاعدة شاملة واحدة في كل مكان.
لا يحدد فحص النطاق الشخص الذي يقف وراء الحزمة. كما قد يترك مجالاً للانتحال داخل نطاق مسموح به. لذلك عامله بوصفه ضابطاً حدودياً مفيداً، لا شهادة هوية.
اجعل فحوص المسار العكسي ملائمة للمسارات الفعلية
يقارن إعادة التوجيه أحادي الإرسال عبر المسار العكسي، أو uRPF، مصدر الحزمة بمعلومات التوجيه. وفي الوضع الصارم، يجب أن تطابق الواجهة الواردة مسار العودة المحدد. وقد يعمل ذلك جيداً حيث تكون المسارات قابلة للتنبؤ.
لكن حركة المرور المشروعة قد تصل عبر اتصال، بينما يستخدم أفضل مسار عودة اتصالاً آخر. ويحدث ذلك مع التوجيه غير المتماثل والشبكات التي تستخدم عدة مزوّدين. وقد تؤدي الفحوص الصارمة حينها إلى إسقاط حركة مرور صحيحة. يشرح RFC 3704 هذه المفاضلات. وتنظر أساليب المسار الممكن في البدائل المسموح بها؛ أما الفحوص المتساهلة فتسأل عموماً عما إذا كان هناك مسار، ولذلك توفر اختباراً أضعف. اختر الوضع وتحقق منه مقابل البنية الفعلية، بما في ذلك التحويل الاحتياطي.
صادِق الخدمة والمستخدم
أبقِ قيود العناوين حيث تكون مفيدة، لكن لا تجعلها الدليل الوحيد على الهوية عند الوصول الحساس. استخدم TLS موثّقاً على نحو صحيح لخدمات الويب، وبروتوكولات موثّقة مناسبة للإدارة ونظراء الشبكة. وما تزال لمصادقة الحسابات والصلاحيات وظائفها الخاصة.
يقوم TLS 1.3 بمصادقة الخادم، ويمكنه أيضاً مصادقة العميل، ويحمي حركة مرور التطبيق. لكنه لا يصدّق كل عنوان مصدر IP ولا يمنع إغراقاً يستنزف وصلة. فالتشفير والتحقق من المصدر يحميان أشياء مختلفة.
قلّل فرص الانعكاس
إذا كنت تشغّل DNS عودياً، فاقصر العودية على العملاء الذين تقصد خدمتهم. وهذا يختلف عن DNS السلطوي، الذي قد يحتاج إلى الإجابة علناً عن نطاقاتك. يشرح RFC 5358 سبب قدرة العودية المفتوحة على تحويل خادم إلى عاكس.
افحص الخدمات المكشوفة الأخرى بحثاً عن إمكانية وصول غير ضرورية واستجابات كبيرة بصورة مفرطة. وخطّط للحصول على مساعدة من مزوّد خدمة علوي في حالات DDoS قبل وقوع الحادثة؛ فالترشيح على خادمك وحده لا يستطيع إعادة وصلة تشبعت بالفعل قبل وصول حركة المرور إليها.
يحتاج IPv6 إلى هذه القرارات أيضاً
لا يؤدي الانتقال إلى IPv6 تلقائياً إلى تشغيل التشفير أو منع انتحال المصدر. ويتطلب IPsec تهيئة متعمدة وإدارة للمفاتيح، ويمكن استخدامه مع كلا الإصدارين من IP. وتتناول إرشادات الأمن التشغيلي لـ IPv6 الضوابط المطلوبة فعلياً. وفي شبكة ثنائية المكدس، قيّم واختبر المسارين معاً.
تحقق من عمل الحماية من دون كسر الخدمة
سجّل النطاقات والمسارات المتوقعة، واختبر حركة المرور المصرّح بها والتحويل الاحتياطي، ثم افحص عمليات الإسقاط وصحة الخدمة. ويمكن لنظام كشف التسلل أن ينبهك إلى الأنماط؛ أما الحجب فيتطلب وظيفة منع أو استجابة من مشغّل. وينبغي للسجلات أن تساعد في تفسير ما حدث، لا أن تحوّل مصدراً مُدّعى إلى هوية مفترضة.
بصفتك مستخدم إنترنت عادياً، ركّز على التحديثات والاتصالات الموثّقة وأمن الحساب. واسأل مزوّد الخدمة عن ترشيح المصدر عند الحاجة؛ فلا يمكنك إصلاح التحقق من الحزم في جهة المزوّد من خلال متصفح. وللاطلاع على الخلفية، اقرأ كيفية عمل المصدر المزوّر أو نمط الهجوم الذي يعالجه كل ضابط.