Dear reader, please download one of Myanmar unicode font and install it on your PC to see my blog well.Thanks.

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)



Contact Form for ictformyanmar.com

Name

Email *

Message *