Why Shared Responsibilities is important on Cloud?

ကျ တော် CompTIA CySA+ Course လေ့လာတုန်းက သင်တဲ့ ဆရာပြောတာလေးက On-Premise ထက်စာရင် Cloud Service Provider တွေရဲ့ Infra က ပို Secure ဖြစ်တယ်ဆိုတာပါပဲ။

တကယ်လဲမှန်ပါတယ်။

ဒါပေမယ့် Cloud Service ကိုသုံးပြီဆိုတာနဲ့ လိုက်နာရမယ့် Share Responsibilities ဆိုတာရှိပါတယ်။

အောက်ကပုံလေးကို ကြည့်လိုက်ရင် အကျဉ်းအားဖြင့် နားလည်ပါတယ်။



ပိုတိတိကျကျ သိချင်ရင် တော့ လိုက်နာရမယ့် Best Practice တွေကို အတိအကျလိုက်နာဖို့ လိုပါတယ်။

ကျ တော်တို့ Cloud ပေါ်တက်လာပြီး အလုပ် တွေ လုပ်ကြတဲ့ အခါ တော်တော်ကို ကြီးမားတဲ့ အမှားတွေ လုပ်ကြပါတယ်။

ဘာတွေလုပ်တာလဲ ဆိုရင် User Account တွေ ရဲ့ Role နဲ့ Policy ကို Identity Access Management မှာ သေချာ Control မလုပ်ကြပါဘူး။
Network Access Control List  မှာ ဘာလာလာ ပေးဝင်တဲ့ အလှူဒါန ရက် ရော ကြပါတယ်။
Security Group တွေ ကို လည်း Upstream , Downstream Security Group တွေနဲ့ Tag မလုပ်ကြပဲ NACL မှာ လို ဘာလာလာ ပေးဝင်တဲ့ အလှူမျိုး ထပ်လုပ်ကြပါတယ်။
ပိုဆိုးတာက တော့ Test EC2 Instance တွေကို Programmatic Access Key တွေ နဲ့ Public က နေ Access လှမ်းလုပ်လို့ရ အောင် လုပ်ထားတာမျိုးပါပဲ။
အလားတူ API Key, SSH Key စတာမျိုးတွေကို Limited Access လုပ်မထားတဲ့ Test EC2 Instance တွေမှာ သိမ်းထားတာပါပဲ။
S3 Bucket တွေကို အလှူပေးထားတာမျိုးတွေလည်း ပါသေးတာပေါ့။
ဒါတွေက လက် တွေ့မှာ အဖြစ်များ အ တွေ့များနေတဲ့ Human Error, Misconfiguration Error တွေပါပဲ။

ဒါမျိုးတွေက ကျ တော်တို့ချည်းပဲ ဖြစ် နေ လုပ် နေတာတော့ မဟုတ်ပြန်ဘူးဗျ။
ထင်သာမြင်သာတဲ့ ဖြစ်ရပ်တခုကို ဥပမာ အ နေနဲ့ ပြရမယ်ဆိုရင် လွန်ခဲ့ တဲ့ လပိုင်းလောက်က ဖြစ်သွားတဲ့ Imperva Security Breach ကိုပဲ အောက်က လင့်က နေ ဖတ်ကြည့်နိုင်ပါတယ်။

Imperva Data Breach Caused by Stolen AWS API Key

ဒီနေ့လို ခေတ်မှာ Scanning/Probing ဆိုတာ လူကိုယ်တိုင်က လုပ် နေစရာ မလိုတော့ပါဘူး။
ဒီတော့ ကိုယ့်က Test လုပ် နေတာပါဆိုပြီး ကိုယ့် Cloud Resource ကို လာသမျှ ပေးဝင်တဲ့ အလှူမျိုး လုပ်ထားလို့က တော့ လူတကာ ဝင် မွှေသွားတာ ခံရပြီး အခန့်မသင့်ရင် Priviliege Escalation, APT စတဲ့ အ မွှေစိန် တွေနဲ့ နဖူးတွေ့ ဒူးတွေ့ ရင်ဆိုင် ရမှာပါ။ ဒါတောင် ဒင်းတို့ ကိုယ့် Infra ထဲရှိနေတယ်ဆိုတာကို ၅ နှစ် လောက် နေမှ သိတာမျိုး ဖြစ်ချင်ဖြစ် နေမှာဗျ။

အ ပြောပဲ ရှိ တာ မဟုတ်ဘူးဗျာ။

မယုံရင် အောက်က လင့်တွေမှာ ကမ္ဘာတလွှားက Cyber Attack တွေရဲ့ Live ကို ကြည့်နိုင်ပါတယ်။ သက်ဆိုင်ရာ Vendor တွေရဲ့ Device Sensor တွေက ပို့ပေးတဲ့ အချက်အလက်ဆိုတော့ အတိအကျ တော့ မရနိုင်ဘူးပေါ့။

Live Cyber Threat Map by Checkpoint

Live Cyber Threat Map by Fortinet

FireEye Cyber Threat Map

Cyber Threat Live Map by Kaspersky

ဒါပါပဲ။

ကိုယ်တိုင်က AWS နဲ့ အဓိက လုပ်နေရလို့ AWS နဲ့ ယှဉ်ပြီး ပြောတာပါ။
ဒါတွေကို Cloud ပေါ်မှာ သတိထားသင့်ပါတယ်။

အ ပေါ်က အမှားမျိုးကို ခဏခဏ တွေ့ရသလို ကိုယ်တိုင်လဲ နဖူးတွေ့ ဒူးတွေ့ ကြုံဖူးတဲ့ အတွက် ကိုယ့်လို မဖြစ်ရ အောင် သတိထားနိုင်ကြ စေဖို့ ဒီစာရေးရင်း  ၂၀၁၉ ကို နှုတ်ဆက်လိုက်ပါပြီဗျာ။

ပျော်ရွှင်ပါစေဗျာ။
(Be knowledgeable, pass it on then)

Infrastructure as code with Terraform on AWS

Netflix လို ထောင်နဲ့သောင်းနဲ့ ချီတဲ့ AWS Resource တွေကို Manually Manage လုပ်ဖို့ဆိုတာ အတော်ခက်ခဲပါတယ်။
Blue/Green Architecture လိုမျိုး Continuous Integration/Continuous Deployment လုပ်ဖို့ အတွက်ဆို ကျတော်တို့တွေ အရင်လို Manual လုပ်နေလို့မရပါဘူး။

Cloud Computing ခေတ်မှာ Resource တွေက ကြိုက်သလောက်သုံးကျသလောက် ရှင်းပုံစံနဲ့ သွားနေသလို။ Compute/Resource တခုခုကို Start/Stop လုပ်ရတာလဲ အရမ်းကို လွယ်ကူမြန်ဆန်လာပါတယ်။

ဒီတော့ ခုနောက်ပိုင်း Infrastructure as Code ဆိုတာ အရမ်းခေတ်စားလာတော့တာပေါ့။

Cloud ပေါ်မှာ Business Application တခုကို Distributed System, Micro-Service ပုံစံတွေ ဆောက်တဲ့ အခါ Resource တွေကို မြန်မြန်ဆန်ဆန်ဆောက်ပြီး စမ်းကြပါတယ်။ Staging, UAT လို မျိုးက အမြဲတမ်း Run ထားဖို့ မလိုပဲ လိုအပ်တဲ့ အခါမှ Resource တွေကို ချက်ချင်းဆောက်ပြီး Run and Test လုပ်နိုင်လာကြပါပြီ။

 ဒီတော့  လိုချင်တဲ့ Infrastructure မျိုးကို Code ရေး၊Template ထုတ်သိမ်းထားပြီး လိုအပ်တဲ့ အချိန်မှာ ကောက် Run လိုက်တဲ့အခါ အချိန်လဲကုန် သက်သာ အမှားကင်းတဲ့ Infra မျိုးရပြီး စမ်းလို့ရတာပေါ့။ စမ်းပြီး မလိုတော့တဲ့ အချိန်မှာလဲ Resource တွေကို Terminate လုပ်ပြီး ငွေကြေးကုန်ကျမှုကို ခြွေတာနိုင်ပါသေးတယ်။

ဒီအတွက် Infra as a code ဆိုတာဘာလဲ။ ဘယ်လိုမျိုးလဲဆိုတာ သိရအောင် အောက်က Youtube Video မှာ ကျတော်က Terraform ကို သုံးပြီး AWS ပေါ်မှာ VPC, Subnet နဲ့ EC2 Instance တွေကို အခြေခံ နမူနာ ဆောက်ပြထားပါတယ်။

https://youtu.be/dkJ1fr8-6h0

ကျေးဇူးတင်ပါတယ်။

ပျော်ရွှင်ပါစေဗျာ။
(Be knowledgeable, pass it on then)

Installing Python, Paramiko and Netmiko on Windows


Python နဲ့ပတ်သက်ပြီး Video Tutorial တွေ၊ Blog post တွေထဲမှာ ရှင်းပြထားတာက Program ကို Linux ပေါ်မှာ Run ပြတာပါပဲ။ ကိုယ်တွေလိုက်လုပ်ရင်လဲ Emulator, Simulator ပေါ်မှာတော့ Linux နဲ့ စမ်းတာပေါ့။ ဒါပေမယ့် ကျတော်တို့ ကြုံရတဲ့ ပြဿနာက တကယ့် Real World မှာ သုံးချင်တဲ့ အခါ လုပ်ငန်းခွင်သုံး တွေက Windows အများဆုံး ဖြစ်နေတာပါပဲ။
ဒီတော့ Network သမားတယောက်ရဲ့ Windows System ပေါ်မှာ Python နဲ့ သူ့ကို Run ဖို့ လိုအပ်တဲ့ Module တွေ ဘယ်လို Install လုပ်လဲ ဆိုတာကို ပြန်ဝေမျှချင်ပါတယ်။
ပထမဆုံး Python ကို အောက်က လင့်မှာ Download လုပ်ပြီး Install လုပ်ပါ။ (ဒါကတော့ လွယ်ကူတဲ့ အတွက် Screenshot တွေနဲ့ မပြတော့ပါဘူး။)

ပြီးတာနဲ့ Anaconda ကို အောက်က လင့်မှာ Download လုပ်ပြီး Install လုပ်ပါ။ (ဒါကတော့ လွယ်ကူတဲ့ အတွက် Screenshot တွေနဲ့ မပြတော့ပါဘူး။)

နောက်တဆင့်က Windows အတွက် Git ကို အောက်က လင့်မှာ Download လုပ်ပြီး Install လုပ်ပါ။ (ဒါကတော့ လွယ်ကူတဲ့ အတွက် Screenshot တွေနဲ့ မပြတော့ပါဘူး။)

လိုတာတွေ Download လုပ်ပြီး Install လုပ်တဲ့ပြီး အခါ Anaconda ရဲ့ Shell ကို Run as administrator နဲ့ ဖွင့်ပြီး အောက်က ပုံတွေမှာ ပြထားတဲ့ Command တခုချင်းစီ ရိုက်ထည့်ပြီး download and install လုပ်ပါ။
၁) Installing Paramiko
 

၂) Installing SCP

Anaconda နဲ့ အပေါ်က ၂ ခု လုပ်ပြီးတဲ့ အခါ Git Bash Shell ကို Run as administrator နဲ့ ဖွင့်ပြီး Github က Netmiko Repo ကို clone လုပ်ယူပါ။ အောက်က ပုံမှာ ပြထားတဲ့ အတိုင်း Command တွေလိုက်ရိုက်ပြီး လုပ်သွားပါ။


ပြီးရင် အောက်ကပုံထဲက အတိုင်း Python Setup Script ကို install လုပ်ပါ။


အပေါ်က အဆင့်တွေကို ဘာပြဿနာမှ မရှိပဲ လုပ်ပြီးပြီဆိုရင် Command Prompt ဖွင့်ပြီး အောက်ကပုံထဲကလို Python ကို ဝင်ပြီး Paramiko နဲ့ Netmiko Module တွေ Import လုပ်ထားပြီး မပြီး စစ်နိုင်ပါတယ်။


ပုံထဲကလို တွေ့ပြီဆိုရင်တော့ Python Program တွေ သုံးဖို့ အဆင်သင့်ဖြစ်ပါပြီ။

Paramiko နဲ့ Netmiko ကို Windows မှာ ဘယ်လို Install လုပ်ရလဲ နဲ့ import netmiko , import paramiko တွေ run တိုင်း ပေါ်လာတဲ့ error တွေကြောင့် ခေါင်းကိုက်ရခြင်း ကင်းဝေးကြပါစေ။

ကျေးဇူးတင်ပါတယ်။

ပျော်ရွှင်ပါစေဗျာ။
(Be knowledgeable, pass it on then)

What are AWS VPC Endpoints and when to use them?

ကျတော်တို့ အိုင်တီလောက မှာ least privilege access ဆိုတာ အရေးကြီးပါတယ်။

ဒါက On-premise မှာတင် သုံးဖို့ မဟုတ်ပဲ Cloud ပေါ်ထိ သက်ရောက်ပါတယ်။

ကျတော်တို့ AWS VPC တခုဆောက်တဲ့ အခါ Public, Private Subnet တွေထဲက Instance တခု သို့မဟုတ် များစွာသော Instance တွေအတွက် ကိုယ့် VPC အပြင်ဖက်မှာ ရှိတဲ့ AWS Service တွေရဲ့ API တွေကို Access လုပ်ဖို့ လိုပါတယ်။ ဥပမာ အနေနဲ့ Amazon S3 , DynamoDB နဲ့ Kinesis တို့လိုပေါ့။

ဒီအခါ မှာ ပုံမှန်ဆိုရင် ကိုယ့် VPC ထဲက Instance တွေက အပေါ်က Service API တွေကို Access လုပ်ဖို့ Internet ကိုထွက်ပြီး Access လုပ်ရမယ်ပေါ့။

ဒါကို ကျတော်တို့က မလိုချင်ဘူးဗျာ။ အကောင်းဆုံး အကြောင်းပြချက်တချို့ကို ပြရမယ်ဆိုရင် လုံခြုံရေးအရရယ်၊ Latency , Speed နဲ့ Bandwidth အသုံးပြုမှုတွေပေါ့။ ဒါတွေကြောင့် ကျတော်တို့က ကိုယ့် VPC ထဲက Instance တွေ Internet ပေါ်တက်ပြီး S3 တို့ဘာတို့ကို Access လုပ်စရာ မလိုပဲ သုံးဖို့ AWS VPC Endpoint ဆိုတာ ပေါ်လာတာပေါ့။

AWS VPC Endpoint မှာ
- Gateway VPC Endpoint နဲ့
- Interface VPC Endpoint ဆိုပြီး နှစ်မျိုးရှိပါတယ်။

Gatway VPC Endpoint ကတော့ ရှင်းပါတယ်။ တခုထက်ပိုတဲ့ Instance တွေ VPC အပြင်က Service API တွေကို သုံးချင်တဲ့ အခါ သုံးတာပေါ့။

အောက်က ပုံမှာလို Subnet 2 က Instance တွေ S3 ကို Access လုပ်သလိုမျိုးပေါ့။


Interface VPC Endpoint ကတော့ အောက်ကပုံထဲကလို Subnet 1 က Instance တခုထဲ အတွက် သုံးတာမျိုးဗျ။



VPC Endpoint ကို သုံးလိုက်ရင် လိုတာထက်ပြီး Access ပေးရတဲ့ VPC Peering တွေလဲ မသုံးပဲနေလို့ရတယ်။

သူ့ကို တခြား AWS Service တွေလိုပဲ Identity Access Management သုံးပြီး Role, Policy တွေ နဲ့ Access Control လုပ်နိုင်ပါသေးတယ်။

ဒါကတော့ VPC Endpoint တွေအကြောင်း ယေဘုယျ ရှင်းပြတာပါ။
ပိုပြီး အသေးစိတ်သိချင်ရင်တော့ အောက်က AWS Website ရဲ့ VPC Endpoint FAQ page မှာ လေ့လာနိုင်ပါတယ်။

https://aws.amazon.com/vpc/faqs/

ကျေးဇူးတင်ပါတယ်။

ပျော်ရွှင်ပါစေဗျာ။
(Be knowledgeable, pass it on then)

Automating Web Application Firewall Creation in AWS

Web Application Firewall တခု မှာ ဝင်လာတဲ့ Web Request Traffic ကို စစ်ဖို့

-          - Conditions
-          - Rules
-          - Web Access List
-          - Default Action ဆိုပြီး အစိတ်အပိုင်း (၄) ပိုင်းပါပါတယ်။
Conditions မှာတော့ Cross-Side Scripting, Geo Match, IP Blacklist, SQL Injection, Packet Size Constraint နဲ့ Regular String Match စတာတွေ ပါပြီး၊ Conditions ပေါင်း များစွာကို ပေါင်းပြီး condition တခုအနေနဲ့ configure လုပ်ထားနိုင်ပါတယ်။

Rule မှာတော့ အပေါ်က Conditions တွေကို ထပ်ပေါင်းပြီး configure လုပ်နိုင်ပါသေးတယ်။
Web Access List ကျတော့မှ Rule တွေကို Top-Down ပုံစံ configure လုပ်ရတာပါ။

နောက်ဆုံး Default Action ဆိုတာကတော့ ကျတော်တို့ Firewall တို့ရဲ့ ထုံးစံအတိုင်း Implicit Deny/Permit ကို သတ်မှတ်ပေးရတာပါ။

ဒီတော့ Web Application Firewall တခုလုပ်တော့မယ်ဆိုရင် အပေါ်က အချက်တွေ တခုချင်းစီကို Configure လုပ်ရပါတယ်။
အဲ့ဒီလို လုပ်တဲ့ အခါ ကိုယ့် Web Application တခုချင်းစီအတွက် Condition, Rule, Access List တွေ setup လုပ်ရတာ အတော်ကို အချိန်ယူပါတယ်။
တခုထက်ပိုများတဲ့ Web Application တွေအတွက်ဆိုရင် ပိုဆိုးတာပေါ့။

ဒီတော့ အချိန်ကုန်သက်သာအောင် AWS ပေါ်မှာ  Open Web Application Security Project (OWASP) ရဲ့ Top Ten WAF Rules နဲ့ AWS WAF ကို CloudFormation သုံးပြီး  ဘယ်လို Auto Implementation လုပ်လဲ ဆိုတာ ပြပါမယ်။

ပထမဆုံး လိုတာကတော့ OWASP Top Ten WAF Rule တွေပါတဲ့ YAML Template ကို အောက်က လင့်မှာ Download လုပ်ပါ။


ပြီးရင်
- AWS Management Console ကို သွားပြီး Login ဝင်ပါ။
- CloudFormation ကို သွားပါ။ အရင်က ဖွင့်မထားဘူးရင် Search မှာ ရှာလို့ရပါတယ်။


- Create stack ကို နှိပ်ပါ။


-      Template is ready ကို နှိပ်ပြီး Template Source နေရာမှာ S3 URL ကနေ ပဲ ယူ မလား။ Download လုပ်ထားတဲ့ YAML Template ကိုပဲ သုံးမလားရွေးပါ။


စမ်းချင်တာဆိုရင် တော့ အပေါ်မှာ ပြောခဲ့ တဲ့ လင့်ကိုပဲ S3 URL မှာ ထည့်လိုက်ရင် ရပါတယ်။
Customize လုပ်ချင်ရင်တော့ YAML Template ကို ပြင်ပြီးတော့မှ Upload လုပ်ပြီး Next နှိပ်ပါ။
-          Stack Name, Prefix နဲ့ WAF ကို ဘယ်မှာထားချင်တာလဲ  (Global လား Regional လား) စတာတွေကို မိမိ လိုချင်တဲ့ အတိုင်း ထည့်ပြီး Next နှိပ်ပါ။


-          Stack Name, Tagging တွေနဲ့ IAM Role တွေ နဲ့ တခြား မိမိ Customize လုပ်ချင်တဲ့ Setting တွေရှိရင် ထည့်ပြီး Next နှိပ်ပါ။

-         
နောက်ဆုံး အဆင့်မှာတော့ ကိုယ့် WAF က ကိုယ်လိုချင်တဲ့ Setting တွေအတိုင်း ဟုတ်မဟုတ် စစ်ပြီး Create Stack ကို နှိပ်ပြီး Stack Creation ပြီးတဲ့ အထိစောင့်ပါ။
-          

၁၅ မိနစ်ကနေ မိနစ် ၃၀ အတွင်းမှာ WAF ရလာပါလိမ့်မယ်။
ဒါဆို ရင် ပုံမှန် အတိုင်း Manual ဆောက်မယ်ဆိုရင် ၃ နာရီလောက်ကြာနိုင်မယ့် Web Application Firewall ကို CloudFormation နဲ့ ဆောက်လိုက်တဲ့ အခါ နာရီဝက်လောက်နဲ့ ပြီးသွားတာကို တွေ့ရမှာပဲ ဖြစ်ပါတယ်။

 

ဒါက ကျတော် Demo အနေနဲ့ အလွယ်ဆုံး အရိုးရှင်းဆုံး လုပ်ပြတာပါ။
တကယ်လို့ ပိုမိုပြည့်စုံပြီး တိကျတဲ့ OWASP Top (10) Base WAF တခု လိုချင်ရင်တော့ YAML Template ကို မိမိစိတ်ကြိုက်ပြင်ပြီး တော့မှ Stack လုပ်ပေါ့။ တခုသိထားရမှာက WAF နဲ့ သူ့ရဲ့ အစိတ်အပိုင်းတွေက Create လုပ်ပြီးသွားရင် ပြန်ပြင်လို့ မရပါဘူး။ နာမည်လေးတောင် ပြင်လို့မရပါဘူး။ ဖျက်လို့ပဲ ရပါတယ်။ ဒါကြောင့် Create မလုပ်ခင် မိမိစိတ်ကြိုက် သေချာ ပြင်ပါလို့ အကြံပေးချင်ပါတယ်။
နောက်ဆုံး တခု ပြောချင်တာက WAF က AWS မှာ Free မဟုတ်ပါဘူး။ Free-Tier သမားတွေ သတိထားဖို့ပါ။ Create လုပ်ပြီးတာနဲ့ Rule တခုစီအတွက် ပိုက်ဆံ စ ကောက်တာပါ။ စမ်းချင်ရင်တော့ မြန်မြန်စမ်းပြီး မြန်မြန်ဖျက်ဖို့ မမေ့ပါနဲ့။ မေ့ရင်တော့ ကိုယ့်ဒေါသနဲ့ ကိုယ်ပေါ့ဗျာ။

Screenshot လေးတွေ သေးပြီး မမြင်ရရင် တပုံချင်းစီ ကလစ်နှိပ်ပြီးကြည့်ပါဗျာ။
ပုံအကြီးတွေတင်ရင် Blog Template နဲ့ မဆန့်လို့ပါ။

ပျော်ရွှင်ပါစေဗျာ။
(Be knowledgeable, pass it on then)







Payment Card Industry Data Security Standard (PCI DSS)

Master, Visa, American Express, JCB အစရှိတဲ့ Credit Card တွေနဲ့ ကိုယ့် Infra နဲ့ ချိတ်ဆက် အလုပ်လုပ်ရတော့မယ်ဆိုရင် PCI DSS ဆိုတာကြီးကို ခေါင်းထဲ ထည့်ထားရပါတယ်။

အဲလို Industry အတွက် Network Design လုပ်တဲ့ အခါ သတ်မှတ်ထားတဲ့ PCI Level နဲ့ PCI Requirement ဆိုတာတွေကို အခြေခံလောက်တော့ သိထားဖို့လိုပါတယ်။

ဒီအတွက် ကျတော် အနည်းငယ် ပြန်လည်ဝေမျှချင်ပါတယ်။

PCI DSS ကောင်စီက PCI Level ကို

Level 1 - တနှစ်ကို Credit Card Transaction ပေါင်း ၆ မီလီယံ နဲ့ အထက်

Level 2 - တနှစ်ကို Credit Card Transaction ပေါင်း ၁ မီလီယံ နဲ့ ၆ မီလီယံ ကြား

Level 3 - တနှစ်ကို Credit Card Transaction ပေါင်း ၂ သောင်း နဲ့ ၁ မီလီယံ ကြား

Level 4 - တနှစ်ကို Credit Card Transaction ပေါင်း ၂ သောင်း အောက်

ဆိုပြီး ၄ မျိုး ခွဲထားပါတယ်။

PCI DSS ကောင်စီရဲ့ Requirement တွေကို Compliant ဖြစ်ဖို့ အတွက်ဆိုရင် အောက်က အခြေခံ ၁၂ ချက်လိုပါတယ်။

၁) Data Protection အတွက် Firewall ရှိရပါမယ်။
၂) Vendor ရဲ့ Default Configuration, Default User Account, Password တွေ မသုံးရပါဘူး။ (ဒါကတော့ တော်တော်များများ မလိုက်နာကြပါဘူး :P)
၃) Store လုပ်ထားတဲ့ Data မှန်သမျှ Protection ရှိရပါမယ်။
၄) Cardholder ရဲ့ Data နဲ့ Sensitive အချက်အလက်တွေအားလုံးကို Public Network တွေကနေဖြတ်သန်းစေတဲ့ အခါ Encrypt လုပ်ရပါမယ်။
၅) Antivirus Software တွေ update အမြဲဖြစ်နေရပါမယ်။
၆) Develop လုပ်တဲ့ Infra နဲ့ Application တွေ ကို အမြဲ Secure ဖြစ်နေစေရပါမယ်။ (Plain Text အစား Encrypted Hash password လိုမျိုးပေါ့)
၇) Data Access မှန်သမျှ Access လုပ်သင့်တာထက် လုပ်ဖို့လိုတဲ့သူထက် ပိုမပေးထားရပါဘူး။ (HR က Finance ကို မကြည့်ရသလို။ HR Staff က HR Manager ပဲကြည့်ရတဲ့ Data ကို access မရသင့်သလိုပေါ့)
၈) System Access တွေအတွက် တယောက်ကို ID တခု Unique ID ပဲ ဖြစ်ရပါမယ်။
၉) Cardholder ရဲ့ Data ကို Physically access ရတဲ့နေရာ တိုင်း restricted access ဖြစ်နေရပါမယ်။
၁၀) Infra Resource နဲ့ Cardholder Data တွေ ရဲ့ access လုပ်သမျှကို အမြဲစောင့်ကြည့်နေရပါမယ်။
၁၁) System တွေနဲ့ Process တွေရဲ့ Security ကို ပုံမှန် စစ်ဆေးမှုရှိရပါမယ်။
၁၂) Information Security နဲ့ ပတ်သက်တဲ့ Policy ရှိနေရမှာ ဖြစ်ပြီး အချိန်နဲ့ တပြေးညီ update ဖြစ်နေရပါမယ်။


ဒါတွေကတော့ Credit Card Company တွေ စုပေါင်းဖွဲ့ထားတဲ့ PCI DSS ကောင်စီရဲ့ Requirement တွေပဲ ဖြစ်ပြီး Credit Card Company တခုချင်းစီမှာလဲ သူတို့ ကိုယ်ပိုင် Requirement တွေရှိပါသေးတယ်။

ကျတော်တို့ ပုံမှန် System, Network သမားတွေက PCI DSS ဆိုရင် မြင်ဖူးကြားဖူးပေးမယ့် အပေါ်က PCI DSS requirement တွေကို တော့ သတိမထားမိတတ်ပါဘူး။


တကယ်လို့များ အခုဖတ်ကြည့်ရင်း ကိုယ့် Infra ကို စစ်ကြည့်ပါ။ ပြီးရင် ဘယ်အချက်တွေတော့ Compliance မဖြစ်ဖူးလဲ တွေးကြည့်ပြီး ပြုံးလိုက်ပါအုံး။
နောက်ဆုံး ဒါတွေကို တီးမိခေါက်မိသွားပြီဆိုရင် ရေးရတဲ့ ကျတော် ကျေနပ်ပါပြီ။

ပျော်ရွှင်ပါစေဗျာ။
(Be knowledgeable, pass it on then)




Solving NTP Sync issue in Cisco FirePower IPS

Cisco FirePower IPS Sensor နဲ့ Management Centre တွေမှာ NTP configuration တွေလုပ်ရတာ GUI မှာ လက်ဝင်ပါတယ်။

ဒီတော့ CLI ကနေ NTP Server တွေ ထည့်ပုံနဲ့ basic troubleshooting လုပ်ပုံလေးကို အောက်မှာ ရှင်းပြထားပါတယ်။

FMC (FirePower Management Centre) မှာ ဆိုရင်

NTP Server နဲ့ Peering Connection ကို စစ်ဖို့

"show ntp" နဲ့ "ntpq -pn" ဆိုတဲ့ command ကို သုံးပါတယ်.

တကယ်လို့ NTP Server က ကိုယ် sync စေချင်တဲ့ Server မဟုတ်ခဲ့ရင် "sudo ntpdate -u <ကိုယ် Sync စေချင်တဲ့ Server IP address>" ဆိုတဲ့ command ကို သုံးပြီး force sync လုပ်ပါ။

Clock Time က မတိကျသေးရင် "sudo pmtool restartbyid ntpd" command ကို သုံးပြီး ntp daemon ကို restart လုပ်ပါ။

Hardware Clock Time ကို ကြည့်ဖို့ကတော့ "sudo hwclock" ဆိုတဲ့ command ကို သုံးပါတယ်။

ဒါကတော့ FMC ရဲ့ NTP ကို troubleshooting လုပ်တာပါ။

တကယ်လို့ Sensor တွေရဲ့ NTP ကို troubleshoot လုပ်မယ်ဆိုရင်တော့။ အပေါ်က Command တွေ အတိုင်း လုပ်နိုင်ပါတယ်။
လုပ်ရင်းနဲ့မှ မရရင်တော့ ntp.conf ကို manual ဝင်ပြင်ရပါမယ်။
ပြင်ဖို့အတွက် "sudo cat /etc/ntp.conf" ဆိုပြီး ntp.conf ထဲက NTP Server တွေ မှန် မမှန် အရင် စစ်ပါ။
မမှန်ရင်တော့ ကိုယ်လိုချင်တဲ့ NTP Server IP ကို vi text editor သုံးပြီး ထည့်ပြီး ntp daemon ကို restart လုပ်ပေါ့။
ပြီးရင် hardware clock time ပြန်စစ်ပါ။ အချိန်မှန်ပြီဆိုရင် ပျော်လိုက်ပါတော့။

တခုတော့ ရှိတာပေါ့။ ကိုယ့် NTP Server က FMC, Sensor တွေ ping (တနည်းအားဖြင့် reachability ရှိနေဖို့) လို့တော့ ရမှ ဖြစ်မှာနော်။

ပျော်ရွှင်ပါစေဗျာ။
(Be knowledgeable, pass it on then)



How to enable DNS Support option for Route 53 Private DNS in AWS VPC?

AWS ပေါ်မှာ Route 53 ကို Private DNS အနေနဲ့ သုံးချင်ရင် ကိုယ့်ရဲ့ VPC က
DNS Hostnames နဲ့ DNS Support options နှစ်ခုကို Enable လုပ်ထားဖို့လိုပါတယ်။

DNS Hostname option က GUI ကနေ Enable လုပ်လို့ရပေမယ့် DNS Support option ကတော့ AWS CLI ကနေပဲ လုပ်မှရပါမယ်။

ဒီအတွက် လိုအပ်တဲ့ AWS CLI tool ကို ကိုယ့် AWS ကို Manage လုပ်မယ့် Laptop/Desktop မှာ download လုပ်ပြီး install လုပ်ပါ။

ပြီးတာနဲ့ အောက်က အတိုင်းသာ လိုက်လုပ်လိုက်ပါ။

အဆင်ပြေသွားပါလိမ့်မယ်

Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Windows\system32>cd ..

C:\Windows>cd ..

C:\>cd "Program Files"

C:\Program Files>cd Amazon

C:\Program Files\Amazon>cd AWSCLI


C:\Program Files\Amazon\AWSCLI>aws configure
AWS Access Key ID [****************AYJ6]: Access Key ID ထည့်ပါ။
AWS Secret Access Key [****************gfv2]: Access Key ထည့်ပါ။
Default region name [us-east-1a]: Region ထည့်ပါ။
Default output format [json]: လိုချင်တဲ့ Output ထည့်ပါ။

C:\Program Files\Amazon\AWSCLI>aws ec2 enable-vpc-classic-link-dns-support --vpc-id "ဒီနေရာမှာ VPC ID ထည့်ပါ။ ဉပမာ - vpc-02e86816fc57d99d5"
{
    "Return": true
}

C:\Program Files\Amazon\AWSCLI>

ကဲ...ခုဆို ရင် Route 53 မှာ Private DNS အတွက် setup လုပ်လို့ရပါပြီ။

ပျော်ရွှင်ပါစေဗျာ။
(Be knowledgeable, pass it on then)

AWS Transit Gateway

အလုပ်နဲ့ ပတ်သက်ပြီး AWS VPC Architect တခု Discuss လုပ်ရင်း VPC Peer တွေ မွထနေအောင် လုပ်ထားတာ မြင်ရတာက စပြီး ဒီပို့စ်လေး ရေးဖြစ်ပါတယ်။

AWS re:Invent 2018 မတိုင်ခင်က ကျတော်တို့တွေ AWS ပေါ်မှာ VPC တွေ Peer လုပ်တဲ့ အခါ VPC ကိုယ်တိုင်က Transit ဖြစ်လို့မရတဲ့ အတွက် အဲ့ဒီ VPC ထဲကို Third Party Router တွေထည့်ပြီး Transit VPC ဖြစ်အောင် လုပ်ကြရပါတယ်။
အဲဒီလို လုပ်လို့ အလုပ်ဖြစ်သွားပေမယ့် VPC Management လုပ်ရတဲ့ အခါ... Scaling လုပ်ရတဲ့ အခါ အတော်ကို တိုင်ပတ်ပြီး လက်ဝင်ပါတယ်။

အခုတော့ အဲဒီလောက် အလုပ်မရှုပ်တော့ပဲ နဲ့ VPC Peering လုပ်နိုင်ဖို့ Transit Gateway ဆိုတာ ကို AWS က Lunch လုပ်ပေးထားတဲ့ အတွက် နောက်ပိုင်း VPC တွေအတွက် သတင်းကောင်းပါပဲ။

Transit Gateway မရခင်က VPC Peering လုပ်တဲ့ အခါ အောက်က ပုံလိုဖြစ်ပြီး Route Table, NACL နဲ့ Security Group တွေ ဖန်တီးရတာ အတော်ခေါင်းခဲရပါတယ်။


Transit Gateway ရလာတဲ့ အခါ VPC Peering လုပ်ရင် အောက်က ပုံလို ဖြစ်သွားတဲ့ အတွက် Route တွေ ACL တွေ Manage လုပ်ရတာ လွယ်ကူလာပါတယ်။


Transit Gatway ကို Shared Services VPC, Outbound NAT, SD WAN နဲ့ တွဲသုံးဖို့ Edge VPC  အစရှိသဖြင့် သုံးလို့ရတဲ့ Use case တွေက တော့ အများကြီးပါ။

လက်တွေ့ပြဖို့ အခွင့်အရေးရတဲ့ အခါ လုပ်ပြပါအုံးမယ်။

Cloud ခေတ်မှာ တော်တော်များများက Free Simulate/Emulate လုပ်မရတော့ နည်းနည်းတော့ ခက်သား။

ကျတော်ရဲ့ တကယ့် ယေဘုယျဆန်ဆန်ပြောထားတာထက် ပိုသိချင်ရင် အောက်က youtube လင့်မှာ သွားကြည့်နိုင်ပါတယ်။
https://www.youtube.com/watch?v=ar6sLmJ45xs

ပျော်ရွှင်ပါစေဗျာ။
(Be knowledgeable, pass it on then)

AWS Certifications Path

AWS Solution Architect စာမေးပွဲ အကြောင်း သိချင်တဲ့သူတွေ အတွက် နည်းနည်း ဝေမျှချင်ပါတယ်။

Cloud Computing ခေတ်မှာတော့ AWS က လောလောဆယ် Global Market မှာ Leader ပေါ့။
သူ့နောက်မှာ Microsoft Azure နဲ့ Google Cloud တို့က လိုက်နေပါတယ်။

AWS Exam တွေဖြေမယ်ဆိုရင်

1) Architect
2) Developer
3) Operations
4) Storage
5) Media Services
6) Speciality
ဆိုပြီး (၆) ပိုင်း ရှိပါတယ်။

1) ကနေ 3) အထိ တပိုင်းစီအတွက် Associate Level , Professional Level ဆိုပြီးခွဲထားပါတယ်။
6) ကတော့ Specialist ပိုင်းအတွက်ပါ။
တခုချင်းစီကို အောက်မှာ ပြန်ရှင်းပြပါမယ်။

အရင်က သက်ဆိုင်ရာ exam တခုချင်းစီအတွက် Associate ပြီးမှ Professional သို့မဟုတ် Speciality ဖြေလို့ရမယ် ဆိုတဲ့ Pre-requisite တွေရှိပေမယ့် အခုတော့ မရှိတော့ပါဘူး။
ကြိုက်တဲ့ Level ကို တန်းဖြေလို့ရပါတယ်။

Architect စာမေးပွဲမှာတော့ AWS မှာ ရတဲ့ Service တွေထဲက Core Service တွေအကြောင်းနဲ့ တခြား အရေးပါတဲ့ Service တွေ အကြောင်းကို Solution Architect တယောက်အနေနဲ့ စစ်တာပါ။
စစ်တဲ့ အခါ 
- Operational Excellence
- Security
- Reliability
- Performance Efficiency
- Cost Optimization
ဆိုပြီး အပိုင်း (၅) ခု ခွဲပြီးစစ်ပါတယ်။

မေးခွန်းတွေက Scenarios Base တွေဖြစ်ပြီး ပေးထားတဲ့ အချက်အလက်တွေနဲ့ requirement တွေပေါ်မူတည်ပြီး Solution ထုတ်ပေးရတဲ့ ပုံစံမျိုးပါ။ Multiple Choice ပါပဲ။
မေးခွန်းက (၆၅) ခု ဖြေရပြီး၊ ဖြေဆိုချိန်က မိနစ် (၁၃၀) ပေးပါတယ်။ မိနစ် (၁၃၀) အတွင်းမှာ မေးခွန်းတွေကို ရှေ့နောက်ကြိုက်သလို ကျော်လို့ရပါတယ်။ ဖြေထားတဲ့ အဖြေကို မကြိုက်ရင်လဲ ပြန်ပြင်နိုင်ပါတယ်။ မသေချာလို့ နောက်မှ ပြန်လာကြည့်ချင်တယ်ဆိုရင်လဲ ကြည့်လို့ရအောင် Flag လုပ်ထားပြီး မှတ်ထားခဲ့လို့ရပါတယ်။ အချိန်စေ့သွားရင်တော့ ဘာမှပြန်လုပ်မရဘူးပေါ့။ Answer တွေကို Submit လုပ်ထားဖို့ပဲ လိုပါတယ်။
အောင်တယ် မအောင်ဘူးဆိုတာကို ဖြေပြီးတာနဲ့ တန်းသိရပေမယ့် Score Report နဲ့ Certificate ကိုတော့ 5 business days စောင့်ရမယ်လို့ ပြောပါတယ်။ ကျတော့်တုန်းကတော့ တရက်ပဲ စောင့်ရပါတယ်။
ဒါက Architect Exam အတွက်ပါ။ ကျန်တဲံ့ Exam တွေလဲ မေးခွန်း အရေအတွက်နဲ့ အချိန်က လွဲလို့ ကျန်တာ ပုံစံ အတူတူပါပဲ။

Developer နဲ့ Operations အတွက်တော့
Associate Level တွေမှာ Developer Associate နဲ့ SysOps Associate ဆိုပြီး Exam မတူပေမယ့် Professional Level Exam မှာ ကျတော့ DevOps Engineer Professional Exam ဆိုပြီး တခုထဲ ပဲ ရှိပါတယ်။

Specialty လိုင်းမှာတော့
- Advanced Networking
- Big Data
- Security
ဆိုပြီး (၃) မျိုးရှိပါတယ်။

စာမေးပွဲကြေးက Associate Level Exam တွေအတွက် US Dollars 150  ဖြစ်ပြီး၊ Professional နဲ့ Speciality Level Exam တွေ အတွက်ကတော့ US Dollars 300 ပါ။

Certification လမ်းကြောင်းအတွက် AWS က Pre-requisite တွေ မကန့်သတ်ထားတော့ပေမယ့် Recommand Path တော့ ပေးထားပါတယ်။
ဘယ်စာမေးပွဲကိုပဲ ဖြေချင် ဖြေချင် ပထမဆုံး အနေနဲ့ Cloud Practitioner သို့ မဟုတ် Tech Essentials Class တခုခု ကို အရင် တက်သင့်ပါတယ်။
ပြီးတော့မှ Associate Level Class အတွက် တက်သင့်ပါတယ်။
နောက်တော့မှ Professional Level ကိုသွားချင်သွား ဒါမှမဟုတ် Specialty Level ကို သွားပေါ့။
ကျတော့် အတွေ့အကြုံအရတော့ Cloud ပိုင်း  Hands-on Experience မရှိပဲ (သို့မဟုတ်) သက်ဆိုင်ရာ Domain Knowledge မရှိပဲ Associate ကနေ Specialty ကို တန်းမသွားသင့်ပါဘူး။
ဘာလို့လဲ ဆိုတော့ Cloud ပေါ်မှာ Trial Run မရပါဘူး။ အားလုံးက Pay as you go ချည်းပါပဲ။ ဒီတော့ သေချာ မသိပဲ လုပ်ရင် ပိုက်ဆံတွေ ကုန်နေမှာ ဖြစ်လို့ပါပဲ။

ကျတော် Solution Architect - Associate လမ်းကြောင်းအတွက် Tech Essentials နဲ့ Architecting on AWS Class နှစ်ခုရယ် Exam Readiness Prepration Class ကိုတက်ပြီး Project  သုံး လေး ခု လောက်ကို (၈) လောက်လောက် လုပ်ပြီး မှ စာမေးပွဲ ဖြေတာပါ။
Exam က အတော်လေး ခက်တယ်လို့ဆိုနိုင်ပါတယ်။ Professional Exam တွေကတော့ အခက်ဆုံးလို့ ပြောကြပါတယ်။ အခြေအနေ ပေးရင်တော့ ဖြေကြည့်သေးတာပေါ့။

ကဲ ဒီလောက်ဆိုရင် AWS Certification and Exam အကြောင်း တီးမိခေါက်မိ လောက်ပြီ ထင်ပါတယ်။

အသေးစိတ် သိချင်ရင်အောက် အောက်က လင့် တွေမှာ သွားဖတ်နိုင်ပါသေးတယ်။

https://aws.amazon.com/training/path-architecting/
https://aws.amazon.com/training/path-developing/
https://aws.amazon.com/training/path-operations/
https://aws.amazon.com/training/paths-specialty/

Storage နဲ့ Media Services အတွက်တော့ ကျတော် သေချာမသိတဲ့ အတွက် အောက်က လင့်မှာ သွားဖတ်ကြည့်နိုင်ပါတယ်။
https://aws.amazon.com/training/path-storage/

ကျေးဇူးတင်ပါတယ်။

ပျော်ရွှင်ပါစေဗျာ။
(Be knowledgeable, pass it on then)










Limiting advertise routes/prefixes from neighbor in BGP

Memory နည်းတဲ့ Router တွေသုံးပြီး BGP run ထားတဲ့ Network တွေမှာ route/prefix တွေ advertise လုပ်တဲ့ အခါ သတိထားရပါတယ်။
CE ကနေ PE , iBGP peer တွေကနေ RR ကို route တွေ advertise လုပ်တဲ့ အခါ လက်ခံမယ့် PE/RR Router ရဲ့ memory က handle လုပ်နိုင်တာထက် ပိုပြီး advertise မလုပ်မိဖို့ လိုပါတယ်။
လက်ခံမယ့် Router က အရေးကြီးတဲ့ Route တွေကို ပါ ကိုင်တွယ်နေတာဆိုရင် Handle လုပ်နိုင်တဲ့ Memory ထက်ပိုခိုင်းတဲ့အခါ network တခုလုံး ကမောက်ကမ ဖြစ်သွားမှာမို့လို့ပါ။

ဒီတော့ ကျတော်တို့တွေက BGP မှာ advertise လုပ်နိုင်တဲ့ route/prefix တွေကို လက်ခံမယ့် router ဖက်မှာ limit လုပ်ထားရပါတယ်။

ဘယ်လိုလုပ်တာလဲ ဆိုတော့ အောက်က ပုံမှာ ကြည့်ပါ။



R1 နဲ့ R2 ကို ပုံထဲက အတိုင်း ကျတော် eBGP ကို configure လုပ်ထားပြီး point to point link ရဲ့ network ကိုပဲ advertise လုပ်ထားပါတယ်။

bgp neighbor နဲ့ bgp routing table ကို ကြည့်ရင် အောက်ကအတိုင်း မြင်ရပါမယ်။



အခု ကျတော်က R1 က R2 ကို route advertise လုပ်နိုင်မယ့် limit ကို configure လုပ်ပါမယ်။ အောက်ကပုံမှာ ကြည့်ပါ။

R1 ကနေ R2 ကို route/prefix  (၅) ခုပဲ advertise လုပ်ခိုင်းပါမယ်။
(၅) ခုထက်ကျော်တာနဲ့ bgp peering ကို ဖြုတ်ချလိုက်မှာပါ။ ဒါက Default Setting ပါ။
အောက်ကပုံကိုကြည့်ပါ။ R1 ကနေ route/prefix (၄) ခုမြောက်ကို advertise လုပ်တာနဲ့ R2 မှာ warning message ပေါ်လာတာ မြင်ရပါမယ်။
(၆) ခုမြောက်ကို လက်ခံရတာနဲ့ တပြိုင်နက်ထဲ bgp peering ကို ဖြုတ်ပစ်လိုက်တာ တွေ့ရမှာပါ။
ဒီတော့ bgp peering ပြန်ရချင်ရင် limit ကို တိုးရင်တိုး (ဒါကတော့ လက်တွေ့မှာ သိပ်မဖြစ်နိုင်ပါဘူး) ဒါမှမဟုတ်ရင် advertise route/prefix ကို ပြန်ဖြုတ်မှပဲ ရပါမယ်။




eBGP တင်မဟုတ်ပဲ iBGP မှာလဲ သုံးနိုင်ကြောင်းကို မှတ်ထားရင်း တခြား default မဟုတ်တဲ့ configuration တွေကို စမ်းကြည့်ကြပေါ့။
default route limit က 75% ကိုရောက်တာနဲ့ Warning Message ပြပေးတာပါ။ အပေါ်က ပုံမှာ တွေ့နိုင်ပါတယ်။

ဒီလို configuration မျိုးကို MPLS Provider နဲ့ BGP run တဲ့ Network တွေရှိတဲ့ Enterprise လုပ်ငန်းတွေမှာ သုံးကြတာကို တွေ့ရမှာပါ။
အခုလို lab အသေးလေးနဲ့ လုပ်ကြည့်ရင်းနဲ့ ကိုယ့်အနေနဲ့ တကယ်ကြုံတဲ့ အခါ route/prefix လေး တကြောင်း advertise လုပ်လိုက်တာနဲ့ bgp peering ပြုတ်သွားတာမျိုးကို မတုန်လှုပ်တော့ပဲ ဖြေရှင်းနိုင်သွားတာပေါ့ဗျာ။

ပုံ Quality ကိုတော့ သည်းခံပေးပါ။ တပုံချင်းစီ Screenshot လုပ်ပြီးတင်ရတာ အချိန်ကုန်လို့ပါ။ ဒီအတိုင်း မမြင်ရရင် ပုံတပုံချင်းစီ Click လုပ်ပြီး ကြည့်ရင် မြင်ရပါတယ်။

ကျေးဇူးတင်ပါတယ်။

ပျော်ရွှင်ပါစေဗျာ။
(Be knowledgeable, pass it on then)

How to select right NMS for your network?

ကိုယ့် Network ထဲမှာ ဘာတွေဖြစ်နေလဲဆိုတာကို စောင့်ကြည့် စီမံခန့်ခွဲဖို့ အတွက် Network Monitoring and Management Solution ရွေးချယ်ရတော့မယ်ဆိုရင် တော်တော်များများ ခေါင်းကိုက်ကြပါတယ်။

ခေါင်းကိုက်ရတဲ့ အကြောင်းအရင်းတွေထဲက အဖြစ်များဆုံးနဲ့ အမေးများဆုံးကတော့ ဘယ် Solution ကို သုံးရမယ်ဆိုတာပါပဲ။

တကယ်တော့ SNMP နဲ့ ICMP သုံးလို့ရတဲ့ Host တိုင်းကို Monitor and Manage လုပ်နိုင်ပါတယ်။

ဘယ်လိုပုံစံတွေနဲ့ လုပ်လဲဆိုတော့ ISO Standard ဖြစ်တဲ့ (FCAPS) အတိုင်းလုပ်တယ်ပေါ့ဗျာ။ နောက်ပိုင်းမှာ FCAPS ဆိုတာဘာလဲ ဆိုတာကို ပြန်ရှင်းပြထားပါတယ်။

ဒီ FCAPS ကို အောက်က ပုံစံလေးတွေအတိုင်း ခွဲခြားမြင်နိုင်ပါတယ်။

၁) Fault Management
Network ထဲက Host တွေ Alive/Dead, Interface တွေ Up/Down, Memory/CPU usage အစရှိတာတွေကို SNMP တို့ ICMP တို့သုံးပြီး စောင့်ကြည့်ပေးတဲ့ Solution
(ဒီပုံစံကို လက်တွေ့မှာ အတော်သုံးကြတာ သတိထားမိကြမှာပါ။)

၂) Performance Management
SNMP နဲ့ NetFlow, sFlow , J-Flow စတာတွေသုံးပြီး Network ထဲက ဘယ်သူက Bandwdith တွေ အများဆုံးသုံးနေလဲတို့ ၊ Application response တွေက နှေးနေလား မြန်နေလားတို့ကို စောင့်ကြည့်ပေးတဲ့ Solution

၃) Configuration Management
ကိုယ့် Network ထဲက Host တွေရဲ့ Configuration တွေက Security Harden ဖြစ်နေရဲ့လား၊ Vendor recommended best practice တွေရော လုပ်ထားရဲ့လား၊ Backup လိုမျိုး အမြဲတမ်းထပ်ခါခါလုပ်နေရတဲ့ အလုပ်မျိုးကို Auto လုပ်ပေးတာမျိုး စတာတွေလုပ်ပေးနိုင်တဲ့ Solution

၄) Event and Logging Management
ဒါကတော့ ရှင်းပါတယ်။ Log အမျိုးအစားအများကြီးထဲက ကိုယ်လိုချင်တဲ့ log မျိုးကို Syslog ဒါမှမဟုတ် Host ရဲ့ buffer ကနေ ယူပြီး စောင့်ကြည့်ပေးတဲ့ Solution

၅) Desktop Management
သူကတော့ Network ထဲက End User Device တွေကို Software update, OS update/patching စတာတွေလုပ်ပေးတဲ့ Solution

၆) Security Management
ဒီအပိုင်းမှာတော့
- Policy Management လို့ပြောနိုင်တဲ့
Traffic hit မရှိတဲ့ Firewall policy တနည်းအားဖြင့် လုံးဝကို မသုံးတော့ပေမယ့် မဖျက်ရသေးတဲ့ Firewall policy တွေ၊
အပေါ်က Firewall Rule က အောက်မှာ ထပ်ထည့်ထားတဲ့ Firewall Rule ကို cover ဖြစ်နေတဲ့ Overlap Firewall Policy တွေ၊
နောက်ပြီး ကိုယ်လုပ်ငန်းအမျိုးအစားပေါ်မူတည်ပြီး Audit အတွက် Compliance report ထုတ်ပေးနိုင်တဲ့ Solution နဲ့
(ဥပမာ ကိုယ့်လုပ်ငန်းက ဘဏ်ဖြစ်နေရင် Visa, Master, MPU Card တွေအတွက် Payment Card Industry Compliance အတွက် Audit Report တွေဘာတွေထုတ်ပေးနိုင်တာမျိုးပေါ့။)

- Protection and Enable Management ဆိုတဲ့
Network ထဲက Host တွေကို Login ဝင်ဖို့ Authentication, Authorization နဲ့ Accounting ကို စောင့်ကြည့် စီမံပေးတဲ့ Solution ဆိုပြီးတွေ့ရမှာပါ။

 
ဒီတော့ အပေါ်က ပြောခဲ့တဲ့ Management Solution တွေကို ဈေးကွက်ထဲမှာ Product တခုချင်းစီအနေနဲ့လဲ ရောင်းကြသလို၊  All-in-one solution ရဲ့ Module တခုချင်းစီလို သို့မဟုတ် Module အားလုံးပါတဲ့ solution တခုလိုလဲ ရောင်းကြပါတယ်။

အားလုံးထဲကမှ တချို့ကလဲ Free ရတဲ့ Open Source ကို Customize လုပ်ပြီး သုံးကြသလို၊ Paid Open Source Service နဲ့ Product ကိုလဲ သုံးတတ်ကြပါတယ်။
ဒီလိုမှ မဟုတ်ရင် လဲ တခြား Open Source မဟုတ်တဲ့ Paid Product and Service တွေကို သုံးကြတယ်ပေါ့။

ကျတော်သုံးဖူးတဲ့ Solution တချို့ကို ပြောပြရမယ်ဆိုရင်တော့
Fault Management အတွက် Nagios, SolarWinds
Performance Management အတွက် SolarWinds , Cacti, PRTG, MRTG
Configuration Management အတွက် Cisco Prime, , HP Intelligent Management Center, Symantec
Event and Loggging Management အတွက် ArcSight, Splunk, Graylog, Kiabana, Kiwi, AWS CloudTrail, AWS VPC Flowlogs
Desktop Management အတွက် SpiceWorks, Hitachi JP1
Security Management အတွက် RSA, Cisco ACS  အစရှိတာတွေပေါ့ဗျာ။ တချို့ဟာတွေ နာမည်မေ့ကုန်တာနဲ့ အပြည့်အစုံ မမှတ်မိတာတွေတော့ မရေးတော့ပါဘူး။

HP Intelligent Management Center (IMC) ဆိုရင် Complete All-in-one solution အနေနဲ့ကို သုံးဖူးပါတယ်။ လိုအပ်ချက်တွေကတော့ ရှိတာပေါ့လေ။

အပေါ်က FCAPS ဆိုတာက Network တခုကို ဘယ်လို ပုံစံတွေနဲ့ Monitor and Manage လုပ်မလဲဆိုတာကို International Standard Organization (ISO) က (FCAPS)
- Fault Management
- Configuration Management
- Accounting Management
- Performance Management
- Security Management
ဆိုပြီး စံအနေနဲ့ Framework တခု ထုတ်ပေးထားတာကို ပြောတာပါဗျာ။

ကျတော် အပေါ်မှာ ရှင်းပြခဲ့တဲ့ Solution တွေက ဒီ Framework ကို အခြေခံထားတယ်ပဲ ဆိုပါတော့။

 ဒီတော့ တကယ်လို့များ NMS တခုရွေးရတော့မယ်ဆိုရင် အပေါ်မှာ ပြောထားခဲ့သလို ကိုယ်ဘာလုပ်ချင်တာလဲ သိအောင်လုပ်ပြီးရင် မှန်ကန်သင့်တော်တဲ့ NMS တခုရွေးချယ်နိုင်မယ်လို့ ယုံကြည်ပါတယ်။


 ပျော်ရွှင်ပါစေဗျာ။
(Be knowledgeable, pass it on then)


BGP Load Sharing with Dual Home to Single ISP



ပြထားတဲ့ topology ပုံထဲက အတိုင်း Router တွေကို Configure လုပ်ထားတယ်ဆိုရင်...
ကျတော်တို့ရဲ့ R1 က R4 ရဲ့ Loopback 0 (4.4.4.4) ကို ရောက်ဖို့ R2 သို့ မဟုတ် R3 ဖက်ကနေ သွားပါလိမ့်မယ်။
ဆိုလိုချင်တာက Upstream Link ၂ ခု ရှိတာကို တခုထဲပဲ သုံးနေတယ်ပေါ့။
ဒါဆိုရင် ကျတော်တို့ က ISP ကို ပိုက်ဆံပေးရတာ မတန်တော့ဘူးပေါ့။
ဒီတော့ ကျတော်တို့ Link ၂ ခုလုံးကို Load Sharing လုပ်ပြီး သုံးချင်တယ်ဗျာ။
ဒါပေမယ့် BGP ရဲ့ Default Path Selection က Best Path တခုကိုပဲ ရွေးတယ်လေ။
ဒါကို ကျတော်တို့က Best Path ၂ ခု ရွေးအောင် လုပ်ကြတာပေါ့။

မလုပ်ခင် R1 ရဲ့ Routing Table မှာ 4.4.4.4 ကို ဘယ်လိုသွားလဲ ကြည့်ပါမယ်။
ပြီးရင် Trace လုပ်ကြည့်ပါမယ်။

R1#sh ip route | Begin Gateway
Gateway of last resort is not set

      1.0.0.0/32 is subnetted, 1 subnets
C        1.1.1.1 is directly connected, Loopback0
      2.0.0.0/32 is subnetted, 1 subnets
B        2.2.2.2 [20/0] via 172.16.12.2, 00:22:18
      3.0.0.0/32 is subnetted, 1 subnets
B        3.3.3.3 [20/0] via 172.16.13.3, 00:22:18
      4.0.0.0/32 is subnetted, 1 subnets
B        4.4.4.4 [20/0] via 172.16.13.3, 00:22:18
      172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
C        172.16.12.0/24 is directly connected, Ethernet0/0
L        172.16.12.1/32 is directly connected, Ethernet0/0
C        172.16.13.0/24 is directly connected, Ethernet0/1
L        172.16.13.1/32 is directly connected, Ethernet0/1
R1#
R1#sh ip route 4.4.4.4
Routing entry for 4.4.4.4/32
  Known via "bgp 65001", distance 20, metric 0
  Tag 65023, type external
  Last update from 172.16.13.3 00:22:27 ago
  Routing Descriptor Blocks:
  * 172.16.13.3, from 172.16.13.3, 00:22:27 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 65023
      MPLS label: none
R1#

Output တွေအရဆိုရင် ကျတော်တို့ R4 ကို R3 ဖက်ကနေသွားနေပါတယ်။

အခု ကျတော်တို့ R2 ဖက်ကနေပါ load sharing လုပ်ချင်တဲ့ အတွက် R1 ရဲ့ BGP configuration အောက်မှာ "maximum-paths 2" ဆိုတဲ့ Command တခု ထည့်ပါမယ်။
R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#router bgp 65001
R1(config-router)#maximum-paths 2
R1(config-router)#

ပြီးတာနဲ့ Routing Table ကို ပြန်စစ်ပါမယ်။

R1#sh ip route | begin Gateway
Gateway of last resort is not set

      1.0.0.0/32 is subnetted, 1 subnets
C        1.1.1.1 is directly connected, Loopback0
      2.0.0.0/32 is subnetted, 1 subnets
B        2.2.2.2 [20/0] via 172.16.13.3, 00:01:07
                 [20/0] via 172.16.12.2, 00:01:07
      3.0.0.0/32 is subnetted, 1 subnets
B        3.3.3.3 [20/0] via 172.16.13.3, 00:01:07
                 [20/0] via 172.16.12.2, 00:01:07
      4.0.0.0/32 is subnetted, 1 subnets
B        4.4.4.4 [20/0] via 172.16.13.3, 00:01:07
                 [20/0] via 172.16.12.2, 00:01:07
      172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
C        172.16.12.0/24 is directly connected, Ethernet0/0
L        172.16.12.1/32 is directly connected, Ethernet0/0
C        172.16.13.0/24 is directly connected, Ethernet0/1
L        172.16.13.1/32 is directly connected, Ethernet0/1
R1#
R1#sh ip route 4.4.4.4
Routing entry for 4.4.4.4/32
  Known via "bgp 65001", distance 20, metric 0
  Tag 65023, type external
  Last update from 172.16.13.3 00:01:12 ago
  Routing Descriptor Blocks:
    172.16.13.3, from 172.16.13.3, 00:01:12 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 65023
      MPLS label: none
  * 172.16.12.2, from 172.16.12.2, 00:01:12 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 65023
      MPLS label: none
R1#

ဒီတခါမှာတော့ Routing Table ထဲမှာ Entry ၂ ခု စီရှိနေတာကို တွေ့ရပါပြီ။
4.4.4.4 ကို Trace လုပ်ကြည့်ရင် R2 ဖက်ကရော R3 ဖက်ကရော load sharing လုပ်ပြီးသွားတာကို တွေ့ရမှာပါ။

R1#trace 4.4.4.4 num
Type escape sequence to abort.
Tracing the route to 4.4.4.4
VRF info: (vrf in name/id, vrf out name/id)
  1 172.16.12.2 [AS 65023] 1 msec
    172.16.13.3 [AS 65023] 1 msec
    172.16.12.2 [AS 65023] 2 msec
  2 172.16.34.4 1 msec
    172.16.24.4 2 msec *
R1#

ဒါဆိုရင် Dual Home Single ISP အခြေအနေမျိုးမှာ BGP Load Sharing ကို အခြေခံအားဖြင့် ဘယ်လိုလုပ်လို့ရတယ်ဆိုတာကို နားလည်မယ်လို့ ထင်ပါတယ်။

ကျေးဇူးတင်ပါတယ်။
(Be knowledgeable, pass it on then)

How to setup VPC Peering on AWS?

အကြောင်းအမျိုးမျိုးကြောင့် AWS မှာ VPC တွေကို peering လုပ်ကြရပါတယ်။
ဒါမှပဲ Internet ပေါ်က ဖြတ်သွားစရာမလိုတဲ့ VPC to VPC traffic တွေအတွက် ကုန်ကျစရိတ် သက်သာမှာပါ။
အရင်ကဆို Cross Region VPC peering လုပ်မရပေမယ့် အခုဆို ရသွားပြီဖြစ်တဲ့ အတွက် Multi-Region VPC ရှိတဲ့ အဖွဲ့အစည်းတွေအတွက် ပိုအဆင်ပြေတာပေါ့။

VPC peering လုပ်ဖို့ အတွက် VPC CIDR address တွေတော့ Overlap ဖြစ်နေလို့မရသလို၊ Transitive VPC peering လဲ လုပ်လို့မရပါဘူး။

ကဲ အခုပြောနေတဲ့ VPC Peering ကို ဘယ်လိုလုပ်လဲ ဘာကြောင့်လုပ်လဲ ဆိုတာ ကို အောက်က Youtube Video မှာကြည့်လို့ရပါတယ်။

https://youtu.be/TcH6miFXa_4


ကြည့်ပြီးလို့ တခုခု အကျိုးများခဲ့တယ်ဆိုရင် လုပ်ရတဲ့ ကျတော် ပျော်ပါပြီ။

ပျော်ရွှင်ပါစေဗျာ။
(Be knowledgeable, pass it on then)

How to setup Web Servers with Application Load Balancer in AWS

တရုတ်နှစ်ကူး ရုံးပိတ်ရက်မှာ ဘယ်မှ မထွက်ဖြစ်ပဲ။
AWS Cloud နဲ့ ပတ်သက်ပြီး Video Tutorial တခု လုပ်ဖြစ်ပါတယ်။

ဒါလုပ်ရခြင်း ရည်ရွယ်ချက်ကတော့ ...
ကျတော်တို့ Network Professional တွေ Console လေး ဖွင့်ပြီး
Command တွေ ချောက်ချက် ချောက်ချက် ရိုက်နေတဲ့ ဘဝမှာပဲ ပျော်မနေစေချင်လို့ပါ။

ဒီ Video ကို ကြည့်တဲ့ အခါ Cloud ပေါ်မှာ Infra တခုကို  နာရီပိုင်း အတွင်း ဆောက်ပြီး သုံးလို့ ရတာကို တွေ့ပါလိမ့်မယ်။

ဒီတော့ Cloud ဆိုတာ ကျတော်တို့ မေ့ထားလို့ မရတော့ပဲ မဖြစ်မနေလေ့လာရတော့မယ့် အရာ တခု ဖြစ်နေပါပြီလို့။

ဒီ Video ဖြစ်ဖို့ ကျတော် တော်တော်လုပ်ယူရပါတယ်။

ပထမ ကိုယ့်အသံနဲ့ Record လုပ်ကြည့်တာ တော်တော် ကို အဆင်မပြေတာနဲ့ Notepad လေးမှာ စာရိုက်ပြီးတော့ပဲ နောက်ခံ တီးလုံးလေးထည့်ပြီး Record ပြန်လုပ်ထားပါတယ်။

ကြည့်ပြီး တစုံတခု အကျိုးများခဲ့တယ်ဆိုရင်ပဲ အချိန်ကုန်ခံပြီး လုပ်ရတဲ့ ကျတော် ပျော်ပါပြီ။

အောက်က Youtube link မှာ ကြည့်နိုင်ပါတယ်ဗျာ။

https://youtu.be/Xmp9Ks0O144

ပျော်ရွှင်ပါစေဗျာ။
(Be knowledgeable, pass it on then)

Ephemeral Ports

Network တခုရဲ့ Client က request တခု initiate လုပ်လိုက်ပြီဆိုတဲ့ အခါ ...

Linux ဆိုရင် port 32768 ကနေ 61000
Windows Server 2003 ဆိုရင် port 1025 ကနေ 5000
Windows Server 2008 နောက်ပိုင်းတွေဆိုရင် port 49152 ကနေ 65535
AWS ရဲ့ Elastic Load Balancer ဆိုရင် port 1024 ကနေ 65535
AWS ရဲ့ NAT Gateway ဆိုရင် port 1024 ကနေ 65535

ဆိုပြီး Client ရဲ့ Operating System ပေါ်မူတည်လို့  အသုံးပြုတဲ့ Port တွေ ကွဲပြားကြပါတယ်။

ဒီတော့ Cloud ပေါ်က Network Access Control List (NACL) လိုမျိုး နဲ့ Stateless Firewall တွေ ကိုင်ရတဲ့ အခါ Client ရဲ့ request initiate လုပ်မယ့်ဖက်မှာ သူ့ Operating System ပေါ် မူတည်ပြီး Port Range ကို ဖွင့်ပေးထားဖို့ လိုတယ်ဆိုတာကို သတိရကြပါလို့။
အဲဒီ Port Range ကြီးကို ဘိုလို Ephemeral Ports ဆိုပြီး ခေါ်တာကို မေ့တတ်ကြလွန်းလို့ ပြန် အမှတ်ရစေချင်တာလေးပါ။

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

ကျေးဇူးတင်ပါတယ်။

ပျော်ရွှင်ပါစေဗျာ။
(Be knowledgeable, pass it on then)

Packet capturing in Cisco ASA

အလုပ်ထဲက လုပ်ဖော်ကိုင်ဖက်တယောက် Network Troubleshoot တခုလုပ်နေရင်း ASA GUI Log Monitoring နဲ့ တိုင်ပတ်နေတာ တွေ့လို့ လွယ်ကူရိုးရှင်းပြီး ကြည့်ရရှင်းတဲ့ Packet Capturing ကို CLI ကနေ လုပ်နည်း ပြပေးလိုက်တော့မှ သူတော်တော် အဆင်ပြေသွားပါတယ်။

တခြားသူတွေလဲ  မသိသေးရင် သိရအောင် အောက်က နည်းလေးအတိုင်း လုပ်ကြည့်နိုင်တယ်လို့ လက်တို့ပါရစေ။

ASA ရဲ့ Command Line ကို ဝင်ပြီး အောက်က Command လေးတွေရိုက်ထည့်ပါ။

capture "Capture Name" interface "Interface Name" match "Protocol Type" host "Source IP" host "Destination IP" eq "Port"

ဥပမာ
192.168.1.1 ကနေ 172.16.1.1 ကို TCP port 80 သုံးပြီး သွားမယ့် Traffic ကို capture လုပ်ချင်ရင် အောက်ကလိုရိုက်တာပေါ့။

capture PCAP1 interface LAN match tcp host 192.168.1.1 host 172.16.1.1 eq 80

ပြီးတာနဲ့ capture လုပ်နေတာကို အောက်မှာ ပြထားတဲ့ နည်းလမ်း (၂) မျိုးနဲ့  ကြည့်နိုင်ပါတယ်။

ပထမ နည်းလမ်းက
show capture "Capture Name"
ဥပမာ
show capture PCAP1 ဆိုပြီးတော့ ASA ရဲ့ CLI ထဲမှာပဲ တိုက်ရိုက်ကြည့်တာပါ။

နောက် နည်းလမ်းက
https://"firewall management ip address"/admin/capture/PCAP1/pcap
ဥပမာ
https://192.168.100.1/admin/capture/PCAP1/pcap
ဆိုပြီး Browser မှာရိုက်ထည့်လိုက်ပါ။ Username , Password တောင်းပါလိမ့်မယ်။ ထည့်ပေးပြီးတာနဲ့ pcap file ကို Download လုပ်ပါလိမ့်မယ်။
Download လုပ်လို့ရတဲ့ ဖိုင်ကို .pcap extension လေးထည့်ပေးပြီး Wireshark နဲ့ ကြည့်နိုင်ပါတယ်။

တကယ်လို့ logging buffer ပြည့်သွားလို့ clear လုပ်ချင်ရင်တော့

clear capture "capture name"
ဥပမာ
clear capture "PCAP1" ဆိုပြီး ရိုက်ပေါ့။

လုံးဝကို မလိုတော့ဘူး remove လုပ်ချင်ရင်တော့
no capture "capture name"
ဥပမာ
no capture "PCAP1" လို့သာ ရိုက်လိုက်ပေတော့ပေါ့။

အပေါ်က command တွေ အကုန်လုံးကို Privileged EXEC mode မှာတင် configure လုပ်ရတာပါ။

ဒီလို command တွေကို Cisco ID သာရှိရင် IOS, IOS-XE and ASA devices တွေအတွက် အောက်က လင့်က Generator Tool နဲ့ Generate လုပ်လို့ရပါတယ်ဗျ။
https://cway.cisco.com/tools/CaptureGenAndAnalyse/


ကျေးဇူးတင်ပါတယ်။

ပျော်ရွှင်ပါစေဗျာ။
(Be knowledgeable, pass it on then)




IPv6 for dummies

IPv6 က Network သမားတွေရဲ့ အမေ့ခံတခုထဲမှာ ပါပါတယ်။ အရင်က မေ့ထားလို့ရပေမယ့် အခုမေ့လို့မရတော့ပါဘူး။
ကိုယ်တိုင်လဲ ခုနောက်ပိုင်း IP design တွေလုပ်တဲ့အခါ IPv6 တွေပါ ထည့်လုပ်လာရတယ်ဆိုတာတော့ အသိပေးချင်ပါတယ်။

Binary နဲ့ ချပြရမယ်ဆိုရင် IPv4 က 32 bits ရှိပြီး IPv6 က 128 bits ရှိတယ်ပေါ့။

128 bits  ရှိတဲ့ IPv6 ကို  ရှေ့ 64 bits နဲ့ နောက် 64 bits ဆိုပြီးပိုင်းလိုက်တယ်ဗျာ။
ရှေ့  64 bits က Routing  အတွက် လို့ သတ်မှတ်ထားပြီး
နောက် 64 bits  က IPv6 enable လုပ်ထားတဲ့ host interface တွေအတွက်ပေါ့။
နောက် 64 bits  ကို Network Interface ရဲ့ MAC address  ကိုယူပြီး IEEE ရဲ့ EUI-64 နည်းနဲ့ တွက်ပြီး Generate လုပ်တယ်လို့ မှတ်ထားပေးပါ။

ရှေ့ 64 bits  ကို ပထမ 48 bits နဲ့ ဒုတိယ 16 bits ဆိုပြီး နှစ်ပိုင်း ထပ်ပိုင်းပါတယ်။
ပထမ 48 bits က အင်တာနက်ပေါ်မှာ လျှောက်သွားဖို့  Global Routing အတွက် ဖြစ်ပြီး (နောက်တမျိုးခေါ်ရမယ်ဆိုရင် Global Unicast Address တဲ့)၊
ဒုတိယ 16 bits ကတော့ Network သမားတွေ Internal Network ထဲ က Subnet တွေမှာ Subnet ID အဖြစ်သုံးဖို့ပါတဲ့။


IPv6 Address အမျိုးအစားတွေကတော့...

၁) Global Unicast Address
၂)  Unique Local Address
၃) Link Local Address

တို့ပါပဲ။


Global Unicast Address တွေကို IPv4 နဲ့ ယှဉ်ပြောရမယ်ဆိုရင် အင်တာနက်ပေါ်မှာ လျှောက်သွားနိုင်တဲ့ Public Address တွေလို့ မှတ်သားနိုင်ပါတယ်။
သူ့ရဲ့ Address က 2001 နဲ့ စပါတယ်။

Unique Local Address တွေကတော့ IPv4 မှာဆိုရင် 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 တို့လို
အင်တာနက်ပေါ်မှာ လျှောက်မသွားနိုင်ပေမယ့် Internally (or) Local Area Network ထဲမှာ လျှောက်လစ်နိုင်တဲ့ Private Address တွေပေါ့။
သူ့ရဲ့ Address က fc00 နဲ့ စပါတယ်။

Link Local Address တွေကျတော့ IPv4 ရဲ့ 169.254.0.0/16 လိုမျိုးဗျ။
IPv6 enable လုပ်ထားတဲ့ Interface တိုင်းမှာ သူ့ဟာသူ Auto Generate လုပ်ပြီး Assign လုပ်ထားတာ။
ဒီကောင်ကတော့ Unique Local Address လို LAN ထဲမှာတော့ Route မလုပ်နိုင်ပါဘူး။
သူ့ရဲ့ Address က fe80 နဲ့ စပါတယ်။


IPv4 မှာ Address ကို ရေးရင် 192.168.1.1 ဘာညာဆိုပြီး "." လေးတွေနဲ့ ခံရေးပေမယ့်
IPv6 ကျတော့ 2001:db8:85a3:8d3:1319:8a2e:370:7348, FE80:0000:0000:0000:0202:B3FF:FE1E:8329 ဆိုပြီး ":" လေးတွေနဲ့ ခြားရေးပါတယ်။

IPv6 address တွေက ရေးရတာ ရှည်ပြီး ဖတ်ရခက်လို့ အတိုချုံ့ ရေးကြပါတယ်။
ချုံ့ရေးနည်းတွေကတော့
သုညတွေ ကြီးပဲ ဆက်တိုက်ပါတဲ့ အပိုင်းကို သုည တလုံးထဲရေးပြီးတဲ့ ":" ၂ ခု ထဲ့ရေးနည်း၊

ဉပမာ။
FE80:0000:0000:0000:0202:B3FF:FE1E:8329 ကို
FE80::0202:B3FF:FE1E:8329 အဖြစ် ပြောင်းရေးနိုင်ပါတယ်။

ရှေ့ဆုံးက သုညပါတဲ့ အပိုင်းကို သုညဖြုတ်ပြီးရေးတဲ့ နည်း

ဉပမာ။
2001:0db8:0000:000b:0000:0000:0000:001A ကို 2001:db8:0:b:0:0:0:1A အဖြစ် ပြောင်းရေးနိုင်ပါတယ်။


IPv4 ကို Browser တွေမှာ ရိုက်တဲ့ အခါ http://192.168.1.1:80 ဆိုပြီး ရိုက်လို့ရပေမယ့်
IPv6 ကို Browser တွေမှာ ရိုက်ချင်ရင် http://[2001:db8:0:1]:80 ဆိုပြီး ရိုက်ရပါတယ်။

IPv6 မှာ မဖြစ်မနေသိထားရမယ့် Address တွေ အများကြီးရှိတဲ့ အထဲက Loopback address ကိုတော့ ပြောပြလိုက်ပါရစေ။

သူကတော့ ::1 ပါတဲ့။

ကဲ ဒီလောက်ဆို IPv6 အကြောင်း တီးမိခေါက်မိလောက်ပြီပေါ့။

ကျေးဇူးတင်ပါတယ်။

ပျော်ရွှင်ပါစေဗျာ။
(Be knowledgeable, pass it on then)