الـ uRPF: الحماية من العناوين المزوّرة

enable
configure terminal
hostname R1
no ip domain-lookup
interface g0/0/0
ip address 203.0.113.1 255.255.255.252
no shutdown
interface g0/0/1
ip address 192.168.1.1 255.255.255.0
no shutdown
ip route 0.0.0.0 0.0.0.0 203.0.113.2
end

enable
configure terminal
hostname R2
no ip domain-lookup
interface g0/0/0
ip address 203.0.113.2 255.255.255.252
no shutdown
interface lo1
ip address 192.168.1.50 255.255.255.255
interface lo2
ip address 10.99.99.1 255.255.255.255
ip route 192.168.1.0 255.255.255.0 203.0.113.1
end

حيّاك الله. كثير من الهجمات تعتمد على عنوان مصدر مزوّر: DoS بعناوين عشوائية عشان ما تقدر تحظرها، أو packet بعنوان من داخل شبكتك عشان تعدّي من ACL تثق في الشبكة الداخلية. والـ uRPF فكرته ذكية: لما تدخل packet من واجهة، الراوتر يشوف عنوان المصدر، ويسأل جدول التوجيه: لو بغيت أوصل للعنوان هذا، أطلع من وين؟

الـ strict mode، reachable-via rx: لازم الطريق للمصدر يطلع من نفس الواجهة اللي وصلت منها الـ packet. وهذا الأقوى، لكنه ما يصلح مع الـ routing غير المتماثل، زي شركة متصلة بمزوّدين. والـ loose mode، reachable-via any: يكفي إن المصدر له طريق في الجدول من أي واجهة. يرفض بس العناوين اللي ما لها وجود. والـ default route ما تنحسب، إلا لو كتبت allow-default. المعمل: R1 راوتر الشركة، و R2 جهة الإنترنت. و R2 فيه عنوانين نستخدمهم كمصدر مزوّر: one ninety two dot one sixty eight dot one dot fifty، يعني عنوان من داخل شبكتنا، و ten dot ninety nine dot ninety nine dot one، عنوان R1 ما له أي طريق محدد. نطبّق الـ strict على واجهة R1 الخارجية، وبعدها R2 يرسل للـ PC من المصدرين.

configure terminal
interface g0/0/0
ip verify unicast source reachable-via rx
end
show ip interface g0/0/0 | include verif

ping 192.168.1.10 source lo1
ping 192.168.1.10 source lo2

تسع verification drops: كل packets المصدرين انرمت، ما عدا أول وحدة، ضاعت قبل في الـ ARP حق R2. يعني المزوّر بعنوان داخلي، والمزوّر بعنوان ما له طريق، الاثنين انرموا. الأولى: R1 يعرف إن one ninety two dot one sixty eight dot one dot zero ورا g zero slash zero slash one، فـ packet من هذا المصدر داخلة من g zero slash zero slash zero أكيد مزوّرة. والثانية: الطريق الوحيد لـ ten dot ninety nine dot ninety nine dot one هو الـ default، والـ default ما ينحسب. والسؤال: متى نستخدم الـ loose؟ لما الشركة متصلة بأكثر من مزوّد، والترافيك ممكن يدخل من مزوّد ويطلع من الثاني. الـ strict بيرمي ترافيك حقيقي. والـ loose يرمي بس اللي ما له أي طريق. الحين دورك. غيّر R1 للـ loose mode، وأعد الإرسال من المصدرين، وتوقّع: أي واحد ينرمى؟ وقّف الفيديو، وجرّب.

تمرين: على R1، interface g0/0/0: ip verify unicast source reachable-via any. بعدها من R2: ping 192.168.1.10 source lo1، و ping 192.168.1.10 source lo2، و show ip interface g0/0/0 | include verif على R1.

الحل.

configure terminal
interface g0/0/0
ip verify unicast source reachable-via any
end
show ip interface g0/0/0 | include verif

ping 192.168.1.10 source lo1
ping 192.168.1.10 source lo2

العداد زاد خمسة بس، يعني عدّى المزوّر بعنوان داخلي، وانرمى ten dot ninety nine dot ninety nine dot one. لأن one ninety two dot one sixty eight dot one dot fifty له طريق في الجدول، والـ loose ما يهتم بالواجهة. يعني الـ loose أضعف: يحمي من العناوين اللي ما لها وجود، لكن ما يحمي من تزوير عناوينك الداخلية. فاختار الـ strict على أي واجهة الترافيك فيها متماثل، زي واجهات المستخدمين. الخلاصة: الـ strict نفس الواجهة، والـ loose أي طريق، والـ default ما ينحسب بدون allow-default. والدرس الجاي: حماية الـ control plane نفسه، بالـ CoPP.