في الآونة الأخيرة لمساعدة العملاء في استكشاف مشاكل غريبة في الشبكة، أقسم الطرف الآخر أن الخادم كان مخترقًا من قبل DDoS، ذهبتُ لألقي نظرة على منحنى حركة المرور على الموسيقى - من الواضح أن طلب عميل IPv6 كان عقد شبكة الإنترنت المدمجة القديمة كحركة مرور شاذة إلى القتل الخطأ. سألني العميل بعيون واسعة: “أين يستخدم أي شخص IPv6 الآن؟” قمت مباشرةً بقطع نقطة اتصال الهاتف المحمول بشبكة الجيل الخامس ومررت له: “جرب بنفسك، الآن نسبة عناوين IPv6 التي تم تعيينها من قبل محطات الجيل الخامس الأساسية هي 90% تقريبًا.”
في هذه الأيام أصبحت بيئة الشبكة أسرع بكثير مما كان متصوراً. في العام الماضي، تجاوز معدل انتشار الإصدار السادس من بروتوكول الإنترنت IPv6 العالمي رسميًا 40%، وقد استحوذ المشغلون المحليون الثلاثة الرئيسيون لشبكة الهاتف المحمول على أكثر من 50%. لكن العديد من الشركات في تكوين شبكة CDN عالية الدفاع لا تزال عالقة في بنية المكدس المزدوج للمرحلة الأساسية، ولم تدرك أن الإصدار السادس من بروتوكول الإنترنت لم يكن “اختياريًا” منذ فترة طويلة بل “إلزاميًا”. "فيما يلي بعض من أهم الأشياء التي يمكنك القيام بها لعملك
الأكثر ضرراً هو مشكلة أمان ترجمة العناوين. إن حل NAT44 التقليدي في بيئة IPv6 يشبه استخدام سياج من الخيزران لمنع الدبابات - في العام الماضي، أدت ثغرة في تحويل IPv6 لشركة تجارة إلكترونية معروفة إلى اختطاف أكثر من 7000 جلسة مستخدم، وكان السبب الجذري هو سوء تكوين قواعد التحويل لدى بائع شبكة CDN.
وجد الاختبار أن معظم شبكات CDN التقليدية عالية الدفاع عالية الدفاع IPv6 تدعم هناك ثلاث إصابات قاتلة رئيسية: تحويل البروتوكول لتجاهل معلومات رأس الأمان ، وعدم وجود قواعد تنظيف حركة المرور الخاصة بـ IPv6 ، والعودة إلى مصدر التدهور الإلزامي لـ IPv4. بائعون معروفون يدعون دعم IPv6 ، ستكون العقدة IPv6 تم مسح حقل تسمية التدفق مباشرة إلى صفر الإرسال ، هذه العملية اللاذعة تقوض مباشرة تحديد تدفق الاستمرارية. هذا النوع من العمليات يدمر مباشرة استمرارية تسمية التدفق.
لا تصدق دعاية البائعين عن “التوافق التام مع IPv6”. لقد اختبرت ثماني خدمات CDN سائدة العام الماضي، ولم تحقق سوى ثلاث منها فقط دعم IPv6 كامل الارتباط. ومن بين هذه الخدمات، كان أداء CDN5 الأكثر إثارة للدهشة، فهي لا تدعم IPv6 الأصلي لـ Anycast فحسب، بل يمكنها أيضًا تكوين عتبات حماية IPv6 DDoS بشكل فردي في وحدة التحكم. على وجه الخصوص، يسمح بروتوكول التوجيه الذكي الخاص بهم بجدولة دقيقة بناءً على الموقع الجغرافي لشرائح عناوين IPv6.
حل 08Host أكثر صعوبة بعض الشيء - تحويل البروتوكول من خلال وكيل من مستويين. على الرغم من أنه يمكن أن يحل مشكلة التوافق، إلا أن التأخير الإضافي البالغ 3 مللي ثانية يعد كارثة بالنسبة للألعاب والسيناريوهات المالية. على العكس من ذلك، طورت CDN07 “مكتبة بصمات IPv6” مثيرة للاهتمام للغاية، والتي يمكنها تحديد أكثر من 500 نمط هجوم خاص ببروتوكول IPv6، مثل هجمات إغراق بروتوكول اكتشاف الجوار (NDP)، وهو روتين كلاسيكي.
من المؤكد أن تكوين شبكة CDN عالية الدفاع لدعم IPv6 ليس بالتأكيد بسيطًا مثل تشغيل مفتاح. بادئ ذي بدء، عليك التحقق مما إذا كانت شهادة SSL تدعم IPv6. في العام الماضي، واجهنا مشكلة فشل شهادة Let's Encrypt في المصافحة على رابط IPv6 خالص. يوصى باستخدام هذا الأمر لاختبار سلامة سلسلة الشهادات:
الأكثر أهمية هو سياسة أمان ترجمة العناوين. الحل السائد الآن هو تركيبة NAT64+DNS64، ولكن العديد من أنظمة التشغيل والإدارة تنسخ مباشرةً قواعد ACL الخاصة بـ IPv4، ونتيجة لذلك، يتم تصفية جميع معلومات الرأس الموسعة لـ IPv6. يجب أن يكون النهج الصحيح هو تكوين مجموعات الأمان على هذا النحو:
تحتاج استراتيجيات تنظيف حركة المرور إلى تحسين استراتيجيات تنظيف حركة المرور بشكل فردي أكثر. كتلة العنوان /48 من IPv6 تعادل مساحة عنوان IPv4 بأكملها. يوصى باستخدام آلية ديناميكية لتسجيل السمعة مثل تلك المطبقة في حل CDN5:
تصميم البنية الخلفية إلى المصدر أسوأ من ذلك. فبعض البائعين ينخرطون مباشرة في تحويل IPv6 إلى IPv4 لتوفير الوقت، وهذا الحل لا بد أن يواجه مشاكل عند مواجهة بروتوكولات اكتشاف PMTU. هناك نهج أكثر أمانًا يتمثل في السماح للعقد الطرفية بالتراكم المزدوج إلى المصدر، مثل CDN07 على تنفيذ اختيار البروتوكول الذكي: عندما تكون جودة IPv6 العائد إلى رابط المصدر أقل من العتبة تتحول تلقائيًا إلى IPv4، مع الحفاظ على اتساق الجلسة.
في الآونة الأخيرة، عندما ساعدنا موقع فيديو على الويب للقيام بالترحيل، وجدنا أيضًا فخًا خفيًا - مشكلة وحدة MTU لـ IPv6. نظرًا لأن IPv6 يحظر التجزئة، يجب تكوين معلمة tcp-mss بشكل صريح عندما تستخدم عقدة CDN 1480 بايت MTU ويستخدم جانب المستخدم 1500 بايت:
يجب أيضًا ترقية جانب المراقبة بشكل شامل. لا تُظهر لوحات معلومات مراقبة IPv4 التقليدية المؤشرات الرئيسية لحركة مرور IPv6، لذلك قمنا بتطوير خريطة ثلاثية الأبعاد لحركة مرور IPv6 مع معلومات جغرافية، والتي يمكن أن تُظهر بصرياً ارتباط الهجمات على قطاعات العناوين المختلفة. استُخدمت هذه الأداة لتحديد حركة المرور الشاذة من شريحة العنوان 2001:db8::/32، والتي تم تتبعها في النهاية إلى برنامج مسح شبكة IPv6 في إحدى الدول.
لكي نكون صادقين، فإن دعم IPv6 للعديد من بائعي الأمن يتعاملون الآن مع عمليات الفحص. في المرة الأخيرة التي رأيت فيها قواعد حماية الثغرات الأمنية للمنتج، فإن القواعد المتعلقة ببروتوكول IPv6 هي فقط عُشر قواعد IPv4، وتأثير هذه الحماية أفضل من مجرد إيقاف التشغيل. إذا كنت تريد حقًا القيام بعمل جيد للحماية، فمن المستحسن الرجوع إلى إرشادات أمان IPv6 التي نشرها المعهد الوطني للمعايير والتكنولوجيا (NIST)، أو على الأقل مراعاة خصائص امتدادات خصوصية العنوان والتناوب المؤقت للعنوان.
بعد أكثر من نصف عام من اختبار المعركة، اخترنا أخيرًا CDN5 كمزود خدمة رئيسي و 08Host لاستعادة البيانات بعد الكوارث والنسخ الاحتياطي. نحن نقدر بشكل خاص وظيفة خريطة التهديدات في الوقت الحقيقي لـ CDN5، والتي يمكن أن تُظهر العلاقة بين سلاسل هجمات IPv4 و IPv6 في نفس الوقت. مرة واحدة عند الدفاع عن هجوم فيضان IPv6 بسرعة 800 جيجابت في الثانية IPv6، يمكن لعقدة التنظيف الخاصة بهم تحديد بصمة جهاز إنترنت الأشياء المختطف وقطع رابط التحكم لخادم C2 مباشرةً.
في الآونة الأخيرة، ساعدت للتو إحدى البورصات على إكمال عملية تحويل IPv6 كاملة، والتجربة الأكثر عمقًا هي أن IPv6 ليس مجرد تغيير بسيط في تنسيق العنوان، بل هو ترقية لنظام الأمان بأكمله. الآن تم تقليل زمن انتقال نظام التداول الخاص بهم بمقدار 171 تيرابايت و3 تيرابايت لأن الإصدار IPv6 يتجنب النفقات العامة لتحويل NAT. والأكثر من ذلك، لم يواجهوا أبداً مشكلة انتحال ARP في عصر IPv4، ففي النهاية يحتوي بروتوكول اكتشاف الجار IPv6 على آلية مصادقة مشفرة.
إذا كان عليَّ أن أوصي بخطة ترحيل الآن، فسأقول: أسرعوا بترقية بنية المكدس المزدوج إلى بنية نقية تعتمد على IPv6 أولاً، وتوقفوا عن التمسك بـ IPv4. تُظهر أحدث البيانات البحثية أن تكلفة مهاجمة رابط IPv6 النقي أعلى بـ 40% من IPv4، لأن كفاءة المسح تنخفض بشكل كبير بسبب مساحة العنوان الكبيرة. هذا ببساطة عائق طبيعي للدفاع.
معلومة أخيرة باردة: تعطي أنظمة ويندوز الأولوية لـ IPv6 بشكل افتراضي، وعندما لا تدعم شبكة CDN الخاصة بك IPv6، يواجه المستخدمون بالفعل تأخيرًا في إرجاع البروتوكول. هذه التفاصيل كافية لشرح سبب تحميل بعض مواقع الويب بنفس التكوين بشكل أسرع وبعضها الآخر أبطأ - يكمن السر في الفرق في الميلي ثانية في حل العنوان.
