Top-Down Or Bottom-Up

Branch Office တစ်ခုအသစ်ဖွင့်မယ်ဆိုပြီး Design အဖွဲ့ကို အလုပ်တစ်ခုဝင်လာတယ်။ အဲဒီ ရုံးခွဲမှာ ရှိတဲ့ ဝန်ထမ်းအရေအတွက်ရယ်၊ နေရာရယ်၊ ရုံးချုပ်ကို ချိတ်ဆက် ဆက်သွယ်ဖို့လိုတယ်ဆိုတဲ့ အကြောင်း ပဲပါလာတယ်။ Request ကမပြည့်စုံဘူးလို့ဆိုရမယ်။ ဒီတော့ ဒီဇိုင်း အဖွဲ့က သင့်တော်မယ်ထင်တဲ့ Router အမျိုးအစား တစ်ခုကို လုံလောက်မယ်လို့ ထင်ရတဲ့ Bandwidth နဲ့လင့်တစ်ခုနဲ့ချိတ်ဆက်မယ်ဆိုပြီး ပုံစံဆွဲပေးလိုက်တယ်။ နောက်ရက်ကျ အဲဒီ ပုံစံအတွက် အဆင်ပြေမပြေ အစည်းအဝေးထိုင်ကြတယ်။

တစ်ယောက်က လင့်အတွက် အရန်လင့်(Backup) တစ်ခုလိုအပ်မယ်ထင်တယ်ဆိုပြီး အကြံပြုတယ်။ ဒီတော့ ရုံးချုပ်နဲ့ ရုံးခွဲကြားမှာ လင့်၂လင့်ထားမယ်။ ဒါဆို လင့်နဲ့ပတ်သက်ပြီး ပူစရာ မလိုတော့ဘူး။ Link redundancy ရသွားပြီ။ ဒါပေမဲ့ ရုံးခွဲမှာ Router ကတစ်လုံးပဲဆိုတော့ အဲဒီ Router ပျက်သွား ရင် လင့် ၂ လင့်ရှိလဲ အလကားပဲ ဆိုတော့ Router နောက်တလုံးထပ်ထည့်ဖို့ လုပ်ကြတယ်။ ဒါဆို Hardware redundancy ပါရသွား ပြီ။ နောက်ဆက်တွဲ ထပ်ပေါ်လာတာက Router ၂ လုံးနဲ့ အတွင်းက LAN ကိုဘယ်လိုပြန်ပေးကြမလဲ။ ၁ လုံး ပဲဆိုရင် LAN interface ကို Default gateway အနေနဲ့ ထောက်လိုက်ရုံပဲ၊ အဆင်ပြေတယ်။ ၂ လုံးဆိုတော့ ဒီအတိုင်းမရတော့ဘူး။ HSRP ဖြစ်ဖြစ်၊ GLBP ဖြစ်သုံးပြီး အတွင်းက Switch ကိုချိတ်ရမယ်။ Switch ၁ လုံး နဲ့ဆိုရင် Redundancy ပျက်သွား နိုင်တဲ့ အတွက် Switch လည်း ၂ လုံးပေါ့။ ဒါဆိုရင်တော့ အတော် ဟုတ်သွားပြီး အားလုံး ၂ခုနဲ့ Full redundancy ရပြီပေါ့။

Network Design ရဲ့ အရေးကြီးတဲ့ အောက်က အချက်သုံးချက်နဲ့ ကိုက်ညီသွားပြီလို့ဆိုလို့ရတယ်။
-    Network must be reliable and resilient
-    Network must be manageable
-    Network must be scalable

ဒါပေမဲ့ အခုလို၂ စုံသုံးလိုက်လို့ အားလုံးအဆင်ပြေသွားပြီလို့တော့ ဆိုလို့မရသေးဘူး။ Single point of failure မရှိတော့ပေမယ့် Point of failure တွေများလာတာကို သတိထားရမယ်။ ပြီးရင် အသုံးပြုထားတဲ့ configuration ကိုသေချာ ကိုင်တွယ်နိုင်တဲ့ နားလည်နိုင်တဲ့ Network Admin တယောက်လိုလာမယ်။ Static route နဲ့ Plug-n-Play မဟုတ်တော့ဘူး။ တနေရာရာ မှာ တခုခုဖြစ် ရင် ကိုယ့် Network အခြေအနေဟာ ဘယ်လိုဖြစ်နိင်တယ် ဆိုတာ ကြိုတင်မြင်ထားရမယ်။ အဲဒါကို Daily operation ကိုင်ရမယ့် အခုနက Network Admin ကသိရမယ်။ (Security နဲ့ network monitoring ကိစ္စထည့်မပြောသေးဘူး။)

ဒါတင်ပဲလားဆိုတော့ မဟုတ်သေးဘူး။ ဝယ်ရမဲ့ ပစ္စည်းအရေအတွက်အတွက် ကုန်ကျစရိတ်က ၂ ဆ မကတက်သွားတယ်။ ပြီးရင် လစဉ်ပေးရမဲ့ ထိန်းသိမ်းခ ဖြစ်တဲ့ Maintenance cost ကလည်း အရမ်း များသွားတယ်။ ဒီတော့ Business requirement အတွက် အဲဒီလောက် သုံးဖို့အတွက် လိုအပ်ရဲ့လားဆိုတာက ပြန်ပြီး စဉ်းစာ စရာဖြစ်လာပြန်တယ်။ Technical ဖက်ကနေ ဘယ်လောက်ပဲ သေချာတဲ့၊ ကောင်းတဲ့ ဒီဇိုင်း လုပ်ခဲ့ပေမယ့် အဲဒီ ဒီဇိုင်း ဟာ Business requirement နဲ့ မကိုက်ညီဘူး၊ မသင့်တော်ဘူးဆိုရင် ဒီ ဒီဇိုင်း ကိုပြီးပြည့်စုံပြီလို့ပြောလို့မရတော့ ဘူး။ ဒီ Network ပြတ်တောက်သွားခဲ့ရင် Business ဖက်က ဘယ်လောက် အထိတောင့်ခံနိုင်မလဲ။ ဘယ်နှစ်နာရီလောက် အထိပြတ်လို့ရသလဲ ဆိုတာတွေကို ချိန်ရတော့မယ်။ ဒါဆိုရင် တချို့နေရာတွေမှာ ကုန်ကျစရိတ်ကို လျော့သင့်တယ်ထင်ရင် လျော့လို့ရတာပေါ့။ ဥပမာ Hardware maintenance ယူတဲ့အခါ 24x7x4 လား x2 လား၊ ဒါမှမဟုတ် 8x5xNBD လား စသဖြင့်လျော့ချလို့ ရပါတယ်။ Hardware ရွေးတဲ့အခါမှာလည်း Backup device ကို ဈေးနိမ့်တာ ရွေးချယ်တာမျိုးပေါ့။

အခု အပေါ်က ဒီဇိုင်နာ တွေစဉ်းစားသွားတဲ့ပုံက Bottom-up approach လို့ဆိုရမှာပါ။ သူတို့ရဲ့ အတွေ့အကြုံရ လိုအပ်မယ်ထင်တာတွေကို Deign guideline အတွင်းကနေ အဆင်ပြေအောင်လုပ် သွားတာ။ Business requirement ကိုသေချာ မလေ့လာသွားဘူး။ ပြန်မမေးဘူး။ မြန်တော့မြန်တယ် ဒါပေမဲ့ Approval board ရောက်တဲ့ အချိန်မှာ Business unit နဲ့ Finance ဖက်က သူတို့လိုအပ်ချက်နဲ့ မကိုက်ရင် ကိုယ့် ဒီဇိုင်း ဟာ ရှေ့ဆက်ဖို့ ခက်သွားပါပြီ။ Technical goals တခုတည်း ပြည့်စုံတာနဲ့မလုံလောက်ပါဘူး။ ပိုသင့်တော်တာက တော့ Top-down approach နဲ့ Business requirement ကို သေချာနားလည်အောင် Big picture ကိုသိအောင် အရင်လုပ်ပြီးမှ ကိုယ့်ရဲ့ Final design နဲ့ BoM ကိုထုတ်ပေးသင့်ပါတယ်။ အချိန်တော့ ပိုကြာရင် ကြာမယ် ဒါပေမဲ့ ကိုယ့်တင်ပေးလိုက်တဲ့ ဒီဇိုင်း ဟာ ပိုပြီး အဆင်ပြေနိုင်ပြီး Business requirement နဲ့ ကိုက်ညီတဲ့ Design တစ်ခုအနေနဲ့ ထွက်ပေါ်လာမှာ ဖြစ်ပါတယ်။ Business unit ဖက်ကလည်း လိုအပ်တဲ့ အချက်အလက်ကို သေချာစုဆောင်ပီး Technical design team ဘက်ကို သူတို့ရဲ့ ရေတို ရေရှည် အစီအစဉ်တွေကို ပြောပြထားရမှာပါ။ အဓိက ဆိုချင်တာကတော့ Technical တစ်ခုတည်းသာမက တခြားကိစ္စတွေပါ ထည့်ပြီး စဉ်းစားသင့်တယ်ဆိုတဲ့ အကြောင်းပါ။ အားလုံးကို ၂စုံသုံးတိုင်း ရပီလို့ တွက်ထားလို့မရပါဘူး။

“Design a network that meet a customer’s business and technical goals.”

ကိုဖြိုး

RTBH

DDoS Attacks တွေကြုံလာရင် ဖြေရှင်းဖို့အတွက် RTBH လို့ခေါ်တဲ့ Remotely Triggered Black Hole Filtering ဆိုတာ လေ့လာကြည့်ရအောင်။ ဒါကိုလေ့လာဖို့အတွက် BGP ရဲ့အလုပ်လုပ်ပုံ၊ BGP Community တွေကို Route-map နဲ့တွဲပြီး အသုံးပြုပုံ၊ Null 0 ရဲ့အကြောင်းနဲ့ သူရဲ့ အသုံးဝင်ပုံ၊ နောက်တခါ uRPF လို့ ခေါ် တဲ့ Unicast Reverse Path Forwarding စတဲ့ အကြောင်းအရာတွေကို သိထားဖို့ လိုပါတယ်။ ဒါတွေ အားလုံး ကို ရေးထားပြီးပါပြီ၊ အရင် ပို့စ် အဟောင်းတွေမှာ ပြန်ရှာဖတ် ကြည့်ပါ။

RTBH ဟာ အဲဒီအရာတွေအားလုံးကိုပေါင်းစပ်ပြီး အသုံးပြုရတဲ့ လုပ်ဆောင်ပုံတစ်ခုဖြစ်ပါတယ်။ DDoS Attack တွေလာရင် ကြုံသလို၊ ကြုံတော့မှ ဖြေရှင်းတာထက် ကြုံလာတဲ့အခါမှာ ခလုတ် တစ်ချက်နှိပ် ပြီး လုပ်ဆောင်ခိုင်းဖို့အတွက် စနစ်တကျပြင်ဆင်ထားတဲ့ပုံစံမျိုးပါ။ ကျွန်တော်တို့ ငယ်ငယ်က တိုက်ကွမ်ဒိုတို့ ကရာတေးတို့ ကစားတဲ့အခါမှာ လေ့ကျင့်ထားသလိုမျိုးပေါ့။ အရင်ဆုံး လက်သီးထိုးနည်း၊ ပြီးရင်ခြေကန် နည်း၊ နောက်တခါ လက်နဲ့ကာတဲ့ပုံစံ၊ ခြေလှမ်း အတက်အဆင်း၊ စတာတွေကို တစ်ခုစီ အရင်လေ့ကျင့် ရပါတယ်။ ပြီးတော့မှ အားလုံးပေါင်းစပ်ပြီး အတွဲတွေ ကစား ရပါတယ်။ အခု RTBH ဆိုတာလည်း BGP/ Null 0/ uPRF/ ACL/ Route-map စတာတွေ နဲ့ ပေါင်းစပ် ထားတဲ့ အတွဲတစ်ခုပါပဲ။

DDoS တွေဝင်လာတဲ့အခါမှာ Target တစ်ခုတည်းသာ ခံရတာမျိုးမဟုတ်ပဲ Target ကိုသွားတဲ့ လမ်းကြောင်း တစ်လျှောက် မှာရှိတဲ့ Devices တွေ၊ Link တွေ အားလုံးကိုပါ Attack ဒဏ်ကိုခံရပါ တယ်။ DDos ကိုရပ်ဖို့ အတွက်ဆိုရင် DDoS စဝင်နိင်တဲ့နေရာကနေ ပိတ်ဆို့ခြင်းဟာ အကောင်းဆုံး ပါ။ အဲဒီလိုမပိတ်နိုင်ရင် သူဝင် လာနိုင်သမျှ လမ်းကြောင်းတစ်ခုလုံးပါထိခိုက်နိုင်ပြီး Target အပြင် တခြားအရာတွေကိုပါ (Collateral Damage) ထိခိုက်လာနိုင်ပါတယ်။ ဘယ်နေရာတွေကနေ စဝင်လာမလဲဆိုတာကတော့ Edge တွေမှာရှိတဲ့ Provider Edge (PE) တွေနဲ့ ISP Edge Router တွေပါ။ Internet (အပြင်) ကနေ ISP ရဲ့ Infra အတွင်း ကို တိုက်ခိုက်တာမျိုး၊ ISP ရဲ့ အောက်က Customer Network တွေကို တိုက်ခိုက်တာမျိုး၊ နောက်တခါ Customer Network ဖက်ကနေ ပြန်ပြီးဝင်လာတာမျိုး၊ စသဖြင့်ရှိပါတယ်။ ဘယ်လိုပဲ ဖြစ်ဖြစ် Edge တွေကနေ ဝင်လာ ကြပါတယ်။ ဒီတော့ DDoS ကို Edge တွေကနေ တာဆီးနိုင်ဖို့ ကြိုးစားရပါတယ်။

Edge က တစ်လုံးပဲဆိုရင်တော့ ကိစ္စမရှိဘူး ဖြစ်လာမှ ဝင်ပြီး လိုအပ်သလိုပိတ်ရင်လည်း အလုပ်ဖြစ်ကောင်း ဖြစ်ပါလိမ့်မယ်။ ဒါပေမဲ့ Edge တွေက အများကြီးဆိုရင်တော့ ဖြစ်လာတဲ့ အချိန်မှာ အချိန်တိုတိုအတွင်းမှာ အားလုံးကိုလိုက် ပြင်နေဖို့အတွက် အချိန်ပိုပေးရပါတယ်။ အချိန်ပိုပေးရလေ ကိုယ့် Network ကိုထိခိုက်လေ ပါပဲ။ အဲဒီအတွက် RTBH အတွဲက အချိန်တို အတွင်း မှာမြန်မြန်ဆန်ဆန်နဲ့ အလုပ်ဖြစ်ဖို့အတွက်  ပြင်ဆင် ထား ခြင်း ဖြစ်ပါတယ်။ အရေးပေါ် လာတဲ့အခါမှာ RTBH စမယ်ဟေ့ဆိုပြီး ခလုတ်နှိပ်သလိုမျိုး စတင်လိုက် ခြင်းဖြစ်ပါတယ်။ ဘာတွေပြင်ဆင် ထားရမလည်းဆိုတာကို ဆက်ကြည့်ရအောင်။

အရင်ဆုံးအနေနဲ့ ခလုတ်နှိပ်ရမဲ့နေရာဖြစ်တဲ့ Trigger လိုပါတယ်။ BGP Router/Device တစ်ခုပါပဲ ဒါပေမဲ့ အဲဒီ BGP router ဟာ Edge တွေအားလုံးနဲ့ iBGP Peer ဖြစ်နေရပါမယ်။ တကယ်လို့ RR (Router Reflector) ရှိတဲ့ Network တွေမှာဆိုရင် RR ကို ချိတ်ဆက်ထားရပါမယ်။ ပြီးရင် Static Route တွေကို BGP အတွင်းကို Redistribute လုပ်ဖို့ ထည့်ထားရပါမယ်။ အဲဒီ Static Route ဟာ Trigger point ပါ။ DDoS ဝင်လာတဲ့အခါ Target ကိုသိပြီဆိုတာနဲ့ Target ကိုသွားဖို့အတွက် Static route ထည့်ပြီး Trigger လုပ်ရပါတယ်။ Next-Hop အနေနဲ့ကတော့ RTBH အတွက် သုံးဖို့ စီစဉ်ထားတဲ့ Network အတွင်းက IP ကိုထောက်ပေးထားရပါတယ်။ နောက်တခုကတော့ PE တွေပါ။ PE တွေမှာ Next-Hop ကို Null 0 ကိုထောက်ထားတဲ့ Static route တစ်ခုထည့်ထားရပါမယ်။

ဥပမာ Target host က 172.18.192.1 ဆိုပါတော့။ RTBH အတွက် IP ကတော့ 192.0.2.1/32 ဆိုပြီး သတ်မှတ်ထားမယ်။ ဒါဆိုရင် Trigger Router မှာထည့်မဲ့ Static route က

# ip route 172.18.192.1 255.255.255.255 192.0.2.1

PE router တွေမှာ အမြဲထည့်ထားရမဲ့ Static route က
#ip route 192.0.2.1 255.255.255.0 null 0

Trigger လုပ်တဲ့ static route ကို Trigger router မှာထည့်လိုက်တာနဲ့ အဲဒီ Static route ဟာ BGP အတွင်းကို Redistribute လုပ်ပြီးဝင်သွားပါတယ်။ ပြီးတော့ iBGP update ကတဆင့် RR နဲ့ PE တွေဆီကို ရောက်သွားပါ တယ်။ အဲဒီ route မှာပါလာတဲ့ Next-hop က RTBH မှာအသုံးပြုတဲ့ IP ပါ။ ဒီတော့ အပြင်က လာတဲ့ DDoS attack ဟာ Target IP ကိုလာတဲ့အခါမှာ PE ကနေ Target IP ကိုသွားမဲ့ Next-Hop က Null 0 ဖြစ်နေတဲ့ အတွက် ဆက်မသွားတော့ပဲ Black hole ဖြစ်တဲ့ Null 0 အထဲကိုထည့်ချလိုက်ပြီး Traffic flow ကို အဆုံး သတ် ပေးလိုက် ပါတယ်။

DDoS Attack ပျောက်သွားပြီ၊ မရှိတော့ဘူးဆိုရင်တော့ Trigger router မှာထည့်ထားတဲ့ Static route ကိုပြန်ဖြုတ်လိုက်ရင် ရပါပြီ။ Static route ဖျက်လိုက်ရင် Redistribution ကနေ BGP အတွင်းကိုထည့်ထား တာပါ ပျောက်သွားတဲ့အတွက် PE ဟာလည်း နဂို Routing table အတိုင်းပဲ ပြန်အလုပ်လုပ်ပါတော့တယ်။ ဒီနည်းကိုတော့ Destination-based RTBH လို့ခေါ်ပါတယ်။ ဒီနည်းနဲ့ DDoS Attack ကိုကာကွယ်နိုင်ပေမယ့် တခြားအမှန်တကယ် အသုံးပြုတဲ့ နေရာကလာတဲ့ Source တွေပါ ပါသွားတဲ့ အတွက် အကုန်လုံးသုံးမရတော့ တာ မျိုးဖြစ်တတ်ပါတယ်။

(Fig source: Cisco RTBH Whitepaper)

တကယ်လို့ Attack လာတဲ့ Source IP/Range ကို လိုက်လို့ရပြီ၊ သိပြီဆိုရင်တော့ Source-based RTBH ကို အသုံးပြုလို့ရပါတယ်။ Destination based လို အကုန်လုံးကို Drop လုပ်ပစ်တာမျိုးမဟုတ်တော့ပဲ Source အပေါ်မှာ မူတည်ပြီး Drop လုပ်တဲ့ ပုံစံမျိုးပါ။ ဒါကိုတော့ uRPF အကူအညီနဲ့ လုပ်ရပါတယ်။ uRPF ရဲ့ လုပ်ဆောင်ပုံအတိုင်း Reverse path fail ဖြစ်အောင် လုပ်လိုက်ခြင်းအားဖြင့် ဝင်ရောက်လာတဲ့ Attack traffic တွေဟာ uRPF ရဲ့ policy အရ ညှိသွားပြီး Edge မှာတင် Drop ဖြစ်သွားပါတယ်။ Destination based နဲ့ ကွာသွား တာက Trigger router မှာ ထည့်ရမည့် Static route ဟာ Target IP အစား Attacker ရဲ့ Source IP range ဖြစ်သွားပါတယ်။ PE တွေမှာတော့ Null 0 Route အပြင် Loose uRPF ကို Edge Interface တွေ အားလုံး မှာ ထည့်ထားပေးပါတယ်။ ဒီနည်းနဲ့ဆိုရင်တော့ Target ကိုသွားမဲ့ တခြား Traffic တွေကို မထိ ခိုက်စေတော့ပဲ DDos Attack source ကိုသာ ရွေးပိတ်လို့ရသွားပါပြီ။ ဒါပေမဲ့ Source IP/Range အားလုံး ကိုသိဖို့ ကတော့ သိပ်လွယ်တဲ့ ကိစ္စမဟုတ်ပါဘူး။ ကိုယ့်ရဲ့  RTBH အပြင်အဆင် ဟာ Source based ရော၊ Destination based အတွက်ပါ အသုံးပြုလို့ ရအောင် ပြင်ထားရပါတယ်။

(Fig source: Cisco RTBH Whitepaper)

BGP Update လုပ်တဲ့နေရမှာလည်း PE router တွေကို ရောက်သွားရင် အဲဒီရောက်လာတဲ့ RTBH အတွက် Route ဟာ Best route ပုံစံမျိုးဖြစ်အောင် Local preference နဲ့ အမြင့်ဆုံးဖြစ်အောင် ချိန်ကိုက်ထားရပါ တယ်။ ဒီထက်ပိုပြီး စီမံဖို့ အတွက် ဆိုရင်တော့ Route tag တို့ BGP Community တို့ကို အသုံးပြုရပါတယ်။ Trigger router ရဲ့ Static to BGP Redistribution လုပ်တဲ့အခါမှာ အသုံးပြုလိုက်တဲ့ Route tag နဲ့ Community အပေါ်မှာ မူတည်ပြီး PE တွေမှာ ဘယ်လို လုပ်ဆောင်မယ် ဆိုတာမျိုး စီစဉ်ထားလို့ရပါတယ်။ ဥပမာ Attack ဝင်လာတဲ့ နေရာက PE တွေကို ရွေးပြီး အသုံးပြုတဲ့ ပုံစံမျိုး။ Community ဟာ ဘယ်လောက် အသုံးဝင်သလဲဆိုရင် တချို့  ISP တွေဆို RTBH service  အနေနဲ့ Customer တွေကိုပေးထားတာမျိုး ရှိပါ တယ်။ Customer ဖက်မှာ DDoS ထိပြီဆိုရင် Customer တွေကိုယ်တိုင် ကာကွယ်စရာမလိုပဲ ISP ကနေ ပိတ်ပေးပို့ အတွက် ISP က ပေးထားတဲ့ Community ကို CE router ဖက်ကနေ RTBH Trigger router အနေနဲ့ PE တွေကို BGP update ကနေ အကြောင်းကြားလိုက်ရင် ရပါပြီ။ ဒါဆိုရင် Customer အနေနဲ့ ISP ကို email ပို့ပြီး ပိတ်ပေးဖို့ ကိစ္စတွေ၊ ISP ဖက်ကနေ Service request ကို ကြည့်ပြီး ပိတ်လိုက် ဖွင့်လိုက်လုပ်ရမဲ့ ကိစ္စတွေ သက်သာသွားပြီး အချိန်တို အတွင်းမှာ DDoS ကို ကာကွယ်ပေးလို့ရသွား ပါတယ်။ နောက်တခါ DDoS traffic တွေကို Drop လုပ်မဲ့အစား ပြန်လည် စစ်ဆေးဖို့ အတွက် Sink Hole Network အတွင်းကို Next Hop အနေနဲ့ ထည့်လိုက်လို့လည်း ရပါတယ်။ လုပ်ရမဲ့ Action အားလုံးကို BGP Update က ဝင်လာတဲ့ Community အရ ဘယ်လိုလုပ်မလဲဆိုတာကို စီစဉ်ထားလို့ရပါတယ်။

အခုလောက်ဆို RTBH ဆိုတာဘာလည်း ဘယ်လိုအလုပ်လုပ်လည်းဆိုတာ သိလောက်ပါပြီ။ Configuration အနေနဲ့ အစပိုင်းမှာပြောထားတဲ့ ကိစ္စတွေဖြစ်တဲ့ Null 0/ BGP/ uRPF စတဲ့ အရာတွေကို သိထားပြီ၊ လုပ်ထားပြီးပြီဆိုရင် အခက်အခဲ မရှိလုပ်ဆောင်နိုင်မှာဖြစ်ပါတယ်။

ကိုဖြိုး