تسعى مجموعة الوثائق لهذا المنتج جاهدة لاستخدام لغة خالية من التحيز. لأغراض مجموعة الوثائق هذه، يتم تعريف "خالية من التحيز" على أنها لغة لا تعني التمييز على أساس العمر، والإعاقة، والجنس، والهوية العرقية، والهوية الإثنية، والتوجه الجنسي، والحالة الاجتماعية والاقتصادية، والتمييز متعدد الجوانب. قد تكون الاستثناءات موجودة في الوثائق بسبب اللغة التي يتم تشفيرها بشكل ثابت في واجهات المستخدم الخاصة ببرنامج المنتج، أو اللغة المستخدمة بناءً على وثائق RFP، أو اللغة التي يستخدمها منتج الجهة الخارجية المُشار إليه. تعرّف على المزيد حول كيفية استخدام Cisco للغة الشاملة.
ترجمت Cisco هذا المستند باستخدام مجموعة من التقنيات الآلية والبشرية لتقديم محتوى دعم للمستخدمين في جميع أنحاء العالم بلغتهم الخاصة. يُرجى ملاحظة أن أفضل ترجمة آلية لن تكون دقيقة كما هو الحال مع الترجمة الاحترافية التي يقدمها مترجم محترف. تخلي Cisco Systems مسئوليتها عن دقة هذه الترجمات وتُوصي بالرجوع دائمًا إلى المستند الإنجليزي الأصلي (الرابط متوفر).
قامت Cisco بتنفيذ تحسينات داخل منتجات نظام توصيل المودم الكابلي (CMTS) من Cisco التي تمنع أنواع معينة من هجمات رفض الخدمة استنادا إلى انتحال عنوان IP وسرقة عنوان IP في أنظمة كبلات مواصفات واجهة خدمة البيانات المنقولة عبر الكبلات (DOCSIS). يصف مرجع أوامر كبل Cisco CMTS مجموعة الأوامر كبل source-verify التي تعد جزءا من تحسينات أمان عنوان IP هذه.
للحصول على مزيد من المعلومات حول اصطلاحات المستندات، راجع اصطلاحات تلميحات Cisco التقنية.
لا توجد متطلبات أساسية خاصة لهذا المستند.
لا يقتصر هذا المستند على إصدارات برامج ومكونات مادية معينة.
مجال التحكم في الوصول إلى وسائط DOCSIS (MAC) مماثل في الطبيعة لمقطع إيثرنت. إذا ترك بدون حماية، فإن المستخدمين في الجزء يكونون عرضة لأنواع عديدة من الطبقة 2 والطبقة 3 التي تواجه هجمات رفض الخدمة القائمة. بالإضافة إلى ذلك، من الممكن أن يعاني المستخدمون من انخفاض مستوى الخدمة بسبب عدم تكوين العنونة على معدات المستخدم الآخر. ويمكن أن تشمل الأمثلة على ذلك ما يلي:
تكوين عناوين IP المكررة على عقد مختلفة.
تكوين عناوين MAC المكررة على عقد مختلفة.
الاستخدام غير المصرح به لعناوين IP الثابتة بدلا من عناوين IP المعينة لبروتوكول التكوين الديناميكي للمضيف (DHCP).
الاستخدام غير المصرح به لأرقام الشبكات المختلفة داخل مقطع ما.
تكوين عقد النهاية بشكل غير صحيح للرد على طلبات ARP نيابة عن جزء من شبكة IP الفرعية للمقطع.
في حين أنه من السهل التحكم في هذه الأنواع من المشاكل وتخفيفها في بيئة شبكة LAN الخاصة بالإيثرنت من خلال التعقب المادي للمعدات المخالفة وفصلها، قد يكون من الصعب عزل هذه المشاكل في شبكات DOCSIS وحلها ومنعها بسبب الحجم الكبير المحتمل للشبكة. بالإضافة إلى ذلك، قد لا يتمتع المستخدمون النهائيون الذين يتحكمون في أجهزة العميل المحلية (CPE) ويقومون بتكوينها بميزة فريق دعم داعش المحلي للتأكد من أن محطات العمل وأجهزة الكمبيوتر الخاصة بهم لم يتم تكوينها بشكل غير مقصود أو غير مقصود.
تحافظ مجموعة منتجات CMTS من Cisco على قاعدة بيانات داخلية مأهولة ديناميكيا لعناوين CPE IP و MAC المتصلة. تحتوي قاعدة بيانات CPE أيضا على تفاصيل حول أجهزة مودم الكبلات المطابقة التي تنتمي إليها أجهزة CPE هذه.
يمكن عرض طريقة عرض جزئية لقاعدة بيانات CPE المقابلة لمودم كبل معين عن طريق تنفيذ الأمر show interface cable x/y modem z. هنا، X هو رقم بطاقة الخط، Y هو رقم منفذ الدفق و Z هو معرف الخدمة (SID) لمودم الكبل. قد يتم تعيين z على 0 لعرض تفاصيل حول جميع أجهزة مودم الكبلات و CPE على واجهة تدفق بيانات معينة. راجع المثال التالي لمخرجات نموذجية تم إنشاؤها بواسطة هذا الأمر.
CMTS# show interface cable 3/0 modem 0 SID Priv bits Type State IP address method MAC address 1 00 host unknown 192.168.1.77 static 000C.422c.54d0 1 00 modem up 10.1.1.30 dhcp 0001.9659.4447 2 00 host unknown 192.168.1.90 dhcp 00a1.52c9.75ad 2 00 modem up 10.1.1.44 dhcp 0090.9607.3831
ملاحظة: بما أن هذا الأمر مخفي، فإنه عرضة للتغيير وليس من المضمون أن يكون متوفرا في جميع إصدارات برنامج Cisco IOS®.
في المثال أعلاه، يتم سرد عمود الطريقة للمضيف بعنوان IP 192.168.1.90 على أنه DHCP. هذا يعني أن CMTS علمت عن هذا مضيف ب يراقب ال DHCP حركة بين المضيف وال DHCP نادل.
المضيف مع عنوان IP 192.168.1.77 قائمة مع أسلوب ساكن إستاتيكي. هذا يعني أن CMTS لم يعلم أولا عن هذا المضيف عبر معاملة DHCP بين هذا الجهاز وخادم DHCP. وبدلا من ذلك، رأى CMTS أول أنواع أخرى من حركة مرور IP من هذا المضيف. يمكن أن تكون حركة المرور هذه متصفح ويب أو بريد إلكتروني أو حزم "ping".
في حين يبدو أنه قد تم تكوين 192.168.1.77 باستخدام عنوان IP ثابت، فقد يكون هذا المضيف قد حصل في الواقع على إيجار DHCP، ولكن قد تم إعادة تمهيد CMTS منذ الحدث وبالتالي فإنه لا يتذكر الحركة.
عادة ما يتم نشر قاعدة بيانات CPE بواسطة معلومات التقاط CMTS من حركات DHCP بين أجهزة CPE وخادم DHCP الخاص بموفر الخدمة. وبالإضافة إلى ذلك، يمكن أن تستمع CMTS إلى حركة مرور IP الأخرى الواردة من أجهزة CPE لتحديد عناوين CPE IP و MAC التي تنتمي إليها أجهزة مودم الكبل.
طبقت Cisco أمر واجهة الكبل source-verify [DHCP]. يتسبب هذا الأمر في قيام CMTS باستخدام قاعدة بيانات CPE للتحقق من صحة حزم IP التي تتلقاها CMTS على واجهات الكبلات الخاصة بها ويسمح CMTS باتخاذ قرارات ذكية حول ما إذا كان سيتم إعادة توجيهها أم لا.
يوضح المخطط الانسيابي أدناه المعالجة الإضافية لحزمة IP المستلمة على واجهة الكبل يجب المرور خلالها قبل السماح لها بالمتابعة من خلال CMTS.
مخطط انسيابي 1
يبدأ المخطط الانسيابي بالحزمة التي يتم استقبالها من قبل منفذ للتحميل على CMTS وينتهي بالحزمة إما التي يتم السماح لها بالمتابعة لمزيد من المعالجة أو في الحزمة التي يتم إسقاطها.
يتمثل السيناريو الأول لرفض الخدمة الذي سنعالجه في الحالة التي تتضمن عناوين IP المكررة. لنقل أن العميل A متصل بموفر الخدمة الخاص به وقد حصل على تأجير DHCP صالح لجهاز الكمبيوتر الخاص به. سيعرف عميل عنوان IP الذي تم الحصول عليه باسم X.
في وقت ما بعد شراء إيجار DHCP الخاص به، يقرر العميل B تكوين جهاز الكمبيوتر الخاص به باستخدام عنوان IP ثابت يصادف أنه نفس عنوان IP المستخدم حاليا من قبل أجهزة العميل A. سوف تتغير معلومات قاعدة بيانات CPE فيما يتعلق بعنوان IP X بناء على أي جهاز CPE أرسل آخر طلب ARP نيابة عن X.
في شبكة DOCSIS غير محمية، قد يتمكن العميل B من إقناع موجه الخطوة التالية (في معظم الحالات، CMTS) بأنه لديه الحق في إستخدام عنوان IP X عن طريق إرسال طلب ARP بالنيابة عن X إلى CMTS أو موجه الخطوة التالية. وهذا من شأنه أن يوقف حركة المرور من مزود الخدمة من إعادة توجيهها إلى العميل (أ).
من خلال تمكين التحقق من مصدر الكبل، سيكون CMTS قادرا على رؤية الحصول على حزم IP و ARP لعنوان IP X من مودم الكبل الخاطئ وبالتالي، سيتم إسقاط هذه الحزم، راجع المخطط الانسيابي 2. وهذا يشمل جميع حزم IP التي تحتوي على عنوان المصدر X وطلبات ARP بالنيابة عن X. ستظهر سجلات CMTS رسالة على غرار:
٪uBR7200-3-BADIPSOURCE: Interface Cable3/0، حزمة IP من مصدر غير صالح. IP=192.168.1.10، MAC=0001.422c.54d0، SID المتوقع=10، SID الفعلي=11
مخطط انسيابي 2
باستخدام هذه المعلومات، سيتم تعريف كلا العملاء ويمكن تعطيل مودم الكبل مع عنوان IP المتكرر المتصل.
والسيناريو الآخر هو أن يقوم المستخدم بتعيين عنوان IP غير مستخدم بشكل ثابت إلى جهاز الكمبيوتر الخاص به والذي يقع ضمن النطاق المشروع لعناوين CPE. لا يتسبب هذا السيناريو في أي انقطاع في الخدمات لأي شخص في الشبكة. لنقل أن العميل B قام بتعيين العنوان Y لجهاز الكمبيوتر الخاص به.
المشكلة التالية التي قد تنشأ هي أن العميل C قد يقوم بتوصيل محطة العمل الخاصة به بشبكة مزود الخدمة ويحصل على إيجار DHCP لعنوان IP Y. ستقوم قاعدة بيانات CPE بوضع علامة مؤقتة على عنوان IP Y على أنه ينتمي إلى مودم كبل العميل C. ومع ذلك، قد لا يمر وقت طويل قبل أن يرسل العميل B، المستخدم غير الشرعي التسلسل المناسب لحركة مرور ARP لإقناع الخطوة التالية بأنه هو المالك الشرعي لعنوان IP Y، مما يؤدي إلى مقاطعة خدمة العميل C.
بالمثل، يمكن حل المشكلة الثانية بتشغيل كبل source-verify. عند تشغيل التحقق من مصدر الكبل، لا يمكن ترحيل إدخال قاعدة بيانات CPE الذي تم إنشاؤه بواسطة تفاصيل الالتقاط من معاملة DHCP بواسطة أنواع أخرى من حركة مرور IP. يمكن فقط لحركة DHCP أخرى لعنوان IP هذا أو إدخال ARP في وقت CMTS لعنوان IP هذا إلغاء الإدخال. وهذا يضمن أنه إذا حصل المستخدم النهائي على تأجير DHCP بنجاح لعنوان IP محدد، فلن يضطر هذا العميل إلى القلق من أن CMTS تصبح مشوشة ويعتقد أن عنوان IP الخاص به ينتمي إلى مستخدم آخر.
يمكن حل المشكلة الأولى لمنع المستخدمين من إستخدام عناوين IP غير المستخدمة حتى الآن باستخدام التحقق من مصدر الكبل DHCP. بإضافة معلمة DHCP إلى نهاية هذا الأمر، يمكن ل CMTS التحقق من صحة كل عنوان IP مصدر جديد يسمعه عن طريق إصدار نوع خاص من رسائل DHCP يسمى Leasequery إلى خادم DHCP. راجع المخطط الانسيابي 3.
مخطط انسيابي 3
بالنسبة لعنوان CPE IP محدد، تسأل رسالة Leasequery ما هو عنوان MAC ومودم الكبل المماثلين.
في هذه الحالة، إذا قام العميل B بتوصيل محطة العمل الخاصة به بشبكة الكبلات بالعنوان الثابت Y، فإن CMTS سيقوم بإرسال معيار Leasequery إلى خادم DHCP للتحقق مما إذا كان العنوان Y قد تم تأجيره إلى كمبيوتر العميل B. يمكن لخادم DHCP إعلام CMTS بأنه لم يتم منح أي تأجير لعنوان IP Y وبالتالي سيتم رفض وصول العميل B.
قد يكون لدى المستخدمين محطات عمل تم تكوينها خلف أجهزة مودم الكبلات الخاصة بهم باستخدام عناوين IP الثابتة والتي قد لا تتعارض مع أي من أرقام شبكة موفر الخدمة الحالية، ولكن قد تتسبب في حدوث مشاكل في المستقبل. لذلك، باستخدام الكبل source-verify، يمكن أن يقوم CMTS بتصفية الحزم الواردة من عناوين IP للمصدر التي ليست من النطاق الذي تم تكوينه على واجهة كبل CMTS.
ملاحظة: لكي يعمل هذا بشكل صحيح، يلزمك أيضا تكوين الأمر ip verify unicast reverse-path لمنع عناوين مصدر IP المنتحلة. راجع أوامر الكبل: للحصول على مزيد من المعلومات.
قد يكون لدى بعض العملاء موجه كجهاز CPE وترتيب لمزود الخدمة لتوجيه حركة مرور البيانات إلى هذا الموجه. إذا كان CMTS يتلقى حركة مرور IP من موجه CPE مع عنوان IP للمصدر الخاص ب Z، فعندئذ يقوم مصدر الكبل-verify بالسماح لهذه الحزمة بالمرور إذا كان CMTS لديه مسار إلى الشبكة Z ينتمي إليها عبر جهاز CPE هذا. ارجع إلى المخطط الانسيابي 3.
تأملوا الآن في المثال التالي:
على CMTS لدينا التكوين التالي:
interface cable 3/0 ip verify unicast reverse-path ip address 10.1.1.1 255.255.255.0 ip address 24.1.1.1 255.255.255.0 secondary cable source-verify ! ip route 24.2.2.0 255.255.255.0 24.1.1.2 Note: This configuration shows only what is relevant for this example
بافتراض وصول حزمة ذات عنوان IP للمصدر 172.16.1.10 إلى CMTS من مودم الكبل 24.2.2.10، فإن CMTS سترى أن 24.2.2.10 غير موجودة في قاعدة بيانات CPE، show int cable x/y modem 0، ومع ذلك يقوم ip verify unicast reverse-path بتمكين إعادة توجيه المسار العكسي للبث الأحادي (Unicast RPF)، والذي يتحقق من كل حزمة مستلمة على واجهة للتحقق من ظهور عنوان IP للمصدر للحزمة في جداول التوجيه التي تنتمي إلى الواجهة. يتحقق التحقق من مصدر الكبل لمعرفة ما هي الخطوة التالية ل 24.2.2.10. في التكوين أعلاه، لدينا مسار IP 24.2.2.0 255.255.255.0 24.1.1.2 مما يعني أن الخطوة التالية هي 24.1.1.2. بافتراض أن 24.1.1.2 هو إدخال صالح في قاعدة بيانات CPE، عندئذ يستنتج CMTS أن الحزمة صحيحة ومن ثم سيعالج الحزمة طبقا ل FlowChart 4.
مخطط انسيابي 4
يتضمن تكوين مصدر الكبل - التحقق ببساطة إضافة الأمر cable source-verify إلى واجهة الكبل التي تريد تنشيط الوظيفة عليها. إذا كنت تستخدم تجميع واجهة الكبل، فأنت بحاجة إلى إضافة التحقق من مصدر الكبل إلى تكوين الواجهة الأساسية.
كيف أن يشكل كبل مصدر-verify DHCP
ملاحظة: تم إدخال التحقق من مصدر الكبل لأول مرة في البرنامج Cisco IOS Software، الإصدار 12.0(7)T ويتم دعمه في برنامج Cisco IOS الإصدار 12.0SC و 12.1EC و 12.1T.
يتطلب تكوين مصدر الكبل-verify DHCP بعض الخطوات.
تأكد من أن خادم DHCP يدعم رسالة DHCP Leasequery الخاصة.
من أجل إستخدام وظيفة التحقق من مصدر الكبل من بروتوكول DHCP، يجب أن يستجيب خادم DHCP لديك للرسائل كما هو محدد بواسطة draft-ietf-dhcp-leasequery-xx.txt. يمكن أن يجيب Cisco Network Registrar الإصدار 3.5 والإصدارات الأحدث على هذه الرسالة.
تأكد من أن خادم DHCP يدعم معالجة خيار معلومات وكيل الترحيل. الرجاء مراجعة قسم وكيل الترحيل.
هناك ميزة أخرى يجب أن يدعمها خادم DHCP لديك هي معالجة خيار معلومات ترحيل DHCP. وهذا يعرف بخلاف ذلك باسم معالجة الخيار 82. يتم وصف هذا الخيار في خيار معلومات ترحيل DHCP (RFC 3046). مع ذلك، يجب تنشيط معالجة خيار معلومات وكيل ترحيل الشبكات والإصدارات 3.5 من Cisco لأداة تسجيل الشبكات من خلال الأداة المساعدة لسطر الأوامر Cisco Network Registrar مع التسلسل التالي للأوامر:
nrcmd -u admin -p changeme -c 127.0.0.1 dhcp enable save-relay-agent-data
nrcmd -u admin -p changeme -c 127.0.0.1 save
nrcmd -u admin -p تغيير -c 127.0.0.1 dhcp reload
قد تحتاج إلى إستبدال اسم المستخدم وكلمة المرور وعنوان IP للخادم المناسب، يظهر المبين أعلاه القيم الافتراضية. بدلا من ذلك، إذا كنت في نافذة مطالبة NRCMD، >NRCMD، فعليك كتابة ما يلي:
يمكن dhcp save-relay-agent-data
حفظ
إعادة تحميل DHCP
قم بتشغيل معالجة خيار معلومات ترحيل DHCP على CMTS.
يجب أن يقوم CMTS بتمييز طلبات DHCP من أجهزة مودم الكبلات و CPE باستخدام خيار معلومات وكيل الترحيل لكي يكون التحقق من مصدر الكبل-DHCP فعالا. يجب إدخال الأوامر التالية في وضع التكوين العام على CMTS الذي يشغل برنامج Cisco IOS الإصدار 12.1EC أو 12.1T أو الإصدارات الأحدث من Cisco IOS.
خيار معلومات ترحيل ip dhcp
إذا كان CMTS لديك يعمل ببرنامج Cisco IOS Software الإصدار 12.0SC Train Cisco IOS، فعليك إستخدام أمر واجهة كبل ترحيل الكبل-agent-option بدلا من ذلك.
حريص على إستخدام الأوامر المناسبة، حسب إصدار Cisco IOS الذي تقوم بتشغيله. تأكد من تحديث التكوين الخاص بك إذا قمت بتغيير قطارات Cisco IOS.
تضيف أوامر معلومات الترحيل خيار خاص يسمى خيار 82، أو خيار معلومات الترحيل، إلى حزمة DHCP التي يتم إرسالها عندما يقوم CMTS بترحيل حزم DHCP.
يتم تعميم الخيار 82 بخيار فرعي، هو معرف دائرة الوكيل، الذي يشير إلى الواجهة المادية على CMTS التي تم سماع طلب DHCP عليها. بالإضافة إلى هذا، يتم تعبئة خيار فرعي آخر، هو معرف الوكيل البعيد، بعنوان MAC المكون من 6 بايت لمودم الكبل الذي تم تلقي طلب DHCP منه أو تمريره.
لذلك، على سبيل المثال، إذا قام جهاز كمبيوتر ذو عنوان MAC 99:88:77:66:55:44 وهو خلف مودم الكبل aa:bb:cc:dd:ee:ff بإرسال طلب DHCP، سيقوم CMTS بإعادة توجيه طلب DHCP إعداد الخيار الفرعي للمعرف البعيد للوكيل من الخيار 82 إلى عنوان MAC الخاص بمودم الكبل، aa:bb:cc:dd:ee:ff.
بامتلاك خيار معلومات الترحيل المضمن ضمن ضمن طلب DHCP من جهاز CPE، يكون خادم DHCP قادرا على تخزين المعلومات التي ينتمي إليها CPE خلف أجهزة مودم الكبل. ويصبح هذا مفيدا بشكل خاص عندما يتم تكوين التحقق من مصدر الكبل على CMTS، حيث يمكن لخادم DHCP إعلام CMTS بشكل موثوق ليس فقط حول عنوان MAC الذي يجب أن يكون لدى عميل معين، بل أيضا حول أي عميل مودم كبل يجب الاتصال به.
قم بتمكين الأمر cable source-verify dhcp تحت واجهة الكبل المناسبة.
الخطوة النهائية أن يدخل الكبل source-verify dhcp أمر تحت الكبل قارن على أي أنت تريد السمة نشط. إذا كان CMTS يستخدم تجميع واجهة الكبل، فيجب عليك إدخال الأمر تحت الواجهة الأساسية للحزمة.
تتيح مجموعات التحقق من مصدر الكبل لمزود الخدمة حماية شبكة الكبل من المستخدمين الذين لديهم عناوين IP غير المعتمدة لاستخدام الشبكة.
يعد الأمر cable source-verify بحد ذاته طريقة فعالة وسهلة لتنفيذ أمان عنوان IP. وعلى الرغم من أن هذا البروتوكول لا يغطي جميع السيناريوهات، فإنه يعمل في التأجير على التأكد من أن العملاء الذين لديهم الحق في إستخدام عناوين IP المخصصة، لن يواجهوا أي إضطرابات من خلال إستخدام عنوان IP الخاص بهم من قبل شخص آخر.
في أبسط شكل له كما هو موضح في هذا المستند، لا يمكن لجهاز CPE الذي لم يتم تكوينه عبر DHCP الحصول على وصول الشبكة. هذه هي الطريقة الأفضل لتأمين مساحة عنوان IP وزيادة إستقرار وموثوقية خدمة Data over Cable. ومع ذلك، يريد العديد من مشغلي الخدمة (MSOs) الذين لديهم خدمات مالية تتطلب منهم إستخدام العناوين الثابتة تنفيذ أمان صارم من الأمر cable source-verify dhcp.
يتمتع Cisco Network Registrar الإصدار 5.5 بقدرة جديدة على الاستجابة لاستعلام الإيجار للعناوين "المحجوزة"، حتى وإن لم يتم الحصول على عنوان IP عبر DHCP. يتضمن خادم DHCP بيانات حجز الإيجار في استجابات DHCPwitery. في الإصدارات السابقة من Network Registrar، لم تكن استجابات DHCPloequery ممكنة إلا للعملاء المستأجرين أو المستأجرين سابقا الذين تم تخزين عنوان MAC من أجلهم. على سبيل المثال، تجاهل وكلاء ترحيل uBR مخططات بيانات DHCPexEqual التي ليس لها عنوان MAC ووقت الإيجار (خيار DHCP-Lease-time).
يرجع Network Registrar وقت إيجار افتراضي لمدة سنة واحدة (31536000 ثانية) للإيجار المحجوز في إستجابة DHCMloequery. في حالة تأجير العنوان بالفعل، يقوم Network Registrar بإرجاع وقت الإيجار المتبقي.