စင္ကာပူအစိုးရ၊ အေနာနမတ္စ္နဲ႕ ဆကယူရထီ

စင္ကာပူအစိုးရ၊ အေနာနမတ္စ္နဲ႕ ဆကယူရထီ

ဘာမဆိုျဖစ္ႏုိင္တယ္။
software ဆိုတာေတြက ေလေပၚမွာ စိတ္ခ်ရေတာ႔တာမဟုတ္တာၾကာျပီ။ အလြယ္ေျပာရရင္ေတာ႔ အခ်င္းခ်င္းနားနားကပ္ေျပာတာကို အနားက တစ္ေယာက္က ၾကားရသလုိမ်ိဳး၊ သူတုိ႕ဟာသူတို႕ အထာနဲ႕ေျပာလုိ႕ (encrypted) ျဖစ္ေနလို႕ ခ်က္ခ်င္းသေဘာမေပါက္တာသာရိွတယ္။ အဲဒီအထာစကားကို နားလည္တဲ႔သူကို ၾကားခဲ႔တဲ႔စကားကို ျပန္ဖြင္႔ျပႏိုင္ရင္ နားလည္သြားႏုိင္တာနဲ႕ဆင္တယ္။

စင္ကာပူအစိုးရဝဘ္ဆုိဒ္မ်ား။
.gov.sg ေတြမွာ တူညီတာေတြ အမ်ားၾကီးရိွတယ္။ စင္ကာပူက အစိုးရမွာ မူဝါဒတစ္ခ်ိဳ႕ရိွတယ္။ ဥပမာ single sign-on သေဘာမ်ိဳးအတြက္သံုးတာေတြက တစ္ခုနဲ႕တစ္ခုခပ္ဆင္ဆင္ဆိုရမယ္။ Authentication အတြက္ေတာ႔ အဓိက Singpass ကိုသံုးတယ္။ SingPass ကို individual အေနနဲ႕သံုးတယ္ေျပာရမယ္။ စင္ကာပူမွာ လူတုိင္းနီးပါး SingPass ရိွတယ္။ အခြန္ေဆာင္ေဆာင္၊ အစိုးရနဲ႕ပတ္သက္တာဘာလုပ္လုပ္ SingPass က လိုသလိုျဖစ္ေနတယ္။ SingPass ကို Crimson Logic ဆိုတဲ႔ ကုမ္ပနီကေရးတယ္။ Singapore Government websites ေတြရဲ႕ ၉၀ ရာခုိင္ႏႈန္းေက်ာ္ဟာ SingPass authentication ေပၚမူတည္တယ္။ အေနာနမတ္စ္ ေတြဟာ ဒါေတြကို သိမွာပဲ။ စင္ကာပူမွာလည္း အေနာနမတ္စ္ေတြရိွေကာင္းရိွေနမွာကိုး။

SingPass သံုးဖုိ႕ API ကို အစိုးရ websites လုပ္တဲ႔ ရံုးတုိင္းနီးပါးမွာ ရိွတယ္ထင္တယ္။ အဲဒါေတြကလည္း system ေပၚမူတည္တဲ႔အတြက္ system တုိင္းမွာရိွတဲ႔ အားနည္းခ်က္ေတြရိွမွာပဲ။ ေနာက္ထပ္ Authentication ႏွစ္ခုက EASY(e-Services Authorisation System) နဲ႕၊ ကုမ္ပနီေတြအတြက္သံုးတဲ႔ UEN နဲ႕ Login ဝင္တာေတြပဲ။

ေနာက္တစ္ခုက RSA keying လို႕ေခၚတယ္။ ဘဏ္ေတြမွာ 2-factor သံုးသလိုမ်ိဳး၊ စင္ကာပူမွာ အစိုးရ ဝက္ဘ္ဆုိထ္စ္ေတြမွာသံုးတယ္။ first layer provider ေတြထဲမွာေတာ႔ NCS က ေစ်းကြက္ရွယ္ရာေတာ္ေတာ္ရထားတယ္။ medinet.gov.sg ဆိုတာမ်ိဳးပဲ။ အဲဒီကေနမွတစ္ဆင္႔ government network ထဲေနာက္တစ္ဆင္႔ဝင္လုိ႕ရတယ္။ secured channel လုပ္လုိက္တာနဲ႕တူတယ္။ ျပီးေတာ႔ encrypted url ထပ္လုပ္တယ္။ ဆိုလုိတာကေတာ႔ ပထမအဆင္႔ကိုေဖာက္ျပီးမွ ဒုတိယအဆင္႔ကိုေရာက္မယ္။ အဲဒီပထမအဆင္႔ log-in server ကမွသာ ဝန္ၾကီးဌာနအသီးသီးရဲ႕ system ေတြကို သြားႏုိင္တယ္။ အဲဒီမွာ firewall setting ေတြရိွတယ္။ ဆိုလုိတာကေတာ႔ အဲဒါေတြဟာ မိန္းဂိတ္ေပါက္ဝေတြပဲ။ ဒီကေနမွျဖတ္သန္းဝင္ေရာက္ႏုိင္မယ္။ ေနာက္ထပ္ ၾကားေပါက္တစ္ခုေတာ႔ရိွေသးတယ္။ အစိုးရရံုးေတြမွာ ရံုးက အုိင္ပီနဲ႕ဆိုရင္ေတာ႔ production server ကို တိုက္ရိုက္ဖြင္႔ေပးထားတာရိွတယ္။ အဲဒါေတြကေတာ႔ first level authentication ကို bypass လုပ္ႏုိင္တယ္။

Hack တယ္ဆိုတဲ႔ေနရာမွာလည္း web ကေန hack တာက ခက္ခဲပင္ပန္းတဲ႔နည္းလမ္းလို႕ဆုိရမယ္ထင္တယ္။ attack ေတာ္ေတာ္မ်ားမ်ားဟာ os level ေတြေလာက္ကိုပစ္မွတ္ထားကုန္ၾကတာေတြ႕ပါတယ္။ cloud server မွာ Host ထားတာကိုေတာင္ down လုနီးပါးျဖစ္သြားတာ ဟိုတစ္ေလာကပဲၾကားလုိက္ပါေသးတယ္။ ရိုးရိုး စက္စုတ္ေလးေတြဆိုရင္ေတာ႔ ဝပ္စင္းျပီး ျပန္ေတာင္မတက္ေတာ႔ဘူး။ DB ကို ဦးတည္ျပီး တိုက္ခိုက္တာေတြလည္း အလြယ္နည္းေတြရိွပါတယ္။ ဥပမာ FAQ တို႕၊ Feedback တို႕အတြက္ကို main database မွာမ်ား table အေနနဲ႕ထားလိုက္ရင္ေတာ႔ အန္တရာယ္အလြန္ၾကီးသြားတတ္ပါတယ္။ network layer မွာ attack လုပ္တာေတြကလည္း ရိုးရွင္းထိေရာက္ပါတယ္။ ဆာဗာေတြအားလံုး CPU 100%  ျဖစ္ေအာင္လုပ္တာတုိ႕၊ Switch ေတြ၊ Routers ေတြ match ျဖစ္ေအာင္မသံုးထားတဲ႔ Data Center ထဲအထိ သာသာယာယာေလးဝင္လာတာတုိ႕ျဖစ္တတ္ပါတယ္။ ဟိုတေလာက PA ဆိုတဲ႔ အစုိးရစနစ္တုိက္ခိုက္ခံလုိက္ရပါေသးတယ္။ အရင္ေရးတဲ႔သူေတြေရာ၊ အခုလက္ရိွ ထိန္းသိ္မ္းေနတဲ႔သူေတြပါ အေမးျမန္းခံထိပါတယ္။

ေနာက္တစ္ခုက Shine portal ဆိုတာ ရိွပါတယ္။ NCS ကေနလုပ္ထားတာပါ။ အစိုးရစစ္စစ္လုပ္ငန္းေတြဆိုရင္ အဲဒီကေနပဲသြားဖုိ႕ အစိုးရရဲ႕ ဆုိက္ဘာလံုျခံဳေရးမူထဲမွာပါပါတယ္။ သူတုိ႕ရဲ႕ standard sets ေတြရိွပါတယ္။ အဲဒါေတြကို လုိက္နာရပါတယ္။ email ပို႕ဖုိ႕ကအစ၊ web service သံုးရင္လည္း service တစ္ခုခ်င္းစီလုိက္ ပုိက္ဆံေပးရတဲ႔ central web service system ကေနသာ ျဖတ္သန္းသြားလာဖုိ႕ဆိုတဲ႔ စည္းကမ္းေတြရိွပါတယ္။ security certificate ေတြကိုလည္း အဆင္႔ဆင္႔လုိက္နာၾကရတာေတြရိွပါတယ္။ သုိ႕ေသာ္လည္း ဧည္႕ဆုိးဆိုတာေတာ႔ ဧည္႕စာရင္းတုိင္ရတဲ႔လမ္းဘက္က ဘယ္လာပါ႔မလဲဗ်ာ။

ေနာက္တစ္ခုက အစိုးရေတြဟာ အေျပာင္းအလဲတစ္ခုတစ္ခုအတြက္ အခ်ိန္ေတာ္ေတာ္ယူတယ္။ အဲဒါဟာ တျခားေနရာမွာေတာ႔ ေကာင္းရင္ေကာင္းမယ္။ software အတြက္ေတာ႔ သိပ္မေကာင္းလွဘူး။ Java upgrade ကို ၁.၄ ေတြ အမ်ားၾကီးရိွတယ္။  အဲဒါေတြကို 1.7 ကိုေျပာင္းတယ္။ 2013 ေလာက္မွ ညီညီညာညာ တေပ်ာ္တပါးေျပာင္းၾကတာ။ 1.7 မွာလည္း သူ႕ျပႆနာနဲ႕သူရိွတယ္။ java update ေတြဟာ ျပႆနာရွင္းဖုိ႕ ထုတ္ေနတာကို နားမလည္တဲ႔သူက နားမလည္ဘူး။ တစ္ခ်ိဳ႕ကေတာ႔ နားလည္ပါရဲ႕ သို႕ေသာ္လည္း web server ေတြ၊ app server ေတြက ေနာက္ဆံုးထုတ္ေတြနဲ႕ တစ္ခ်က္တစ္ခ်က္ ခ်က္ခ်င္း သဟဇာတမျဖစ္ေတာ႔ မျပင္ၾကဘူး။ known issue ကို မျပင္ရင္ေတာ႔ ကိုယ္႔ေသတြင္းကို ကိုယ္႔လက္နဲ႕တူးသြားတာမ်ိဳးျဖစ္တတ္တယ္။ Web Logic patch ေတြဆိုလည္း update လုပ္ခ်င္မွ လုပ္တာေတြ႕တယ္။ Strut 2 မွာ vulnerable ရိွတယ္ဆိုတာ ဟိုတစ္ေလာက email ပို႕တယ္။ အမွန္ေတာ႔အဲဒါေတြအတြက္ security team ေတြက ေစာင္႔ၾကည္႕ေလ႔လာေနရမွာ။ vendor ေတြအားကိုးလုိ႕ကေတာ႔ ဘာမွျဖစ္လာမယ္မထင္ဘူး။ Java နဲ႕ေရးထားတဲ႔ application အေဟာင္းေတြ ေတာ္ေတာ္မ်ားမ်ားဟာ ေတာ္ေတာ္ေလး outdated ျဖစ္ေနျပီ။ Spring သံုးတဲ႔ application ေတြမွာလည္း spring security မသံုးၾကတာမ်ားတယ္။ အမ်ားဆံုးအတြဲအစပ္ကေတာ႔ Struts/Spring/Oracle/Weblogic အဲဒါပဲ။ အဲဒီမွာမွ clustering ခပ္စုတ္စုတ္ေလးတစ္ခုေလာက္ပါမယ္။ App1/App2 လုပ္ထားမယ္။ (မစြံတာမ်ားတယ္။) System အေဟာင္းေတြဆိုရင္ sftp ကေန file upload ေတြေတာင္ပါေသး။ အဲဒါမ်ိဳးေတြက မသမာတဲ႔သူနဲ႕ေတြ႕ရင္ အန္တရာယ္သိပ္မ်ားတယ္။ data file uploading ေတြဟာ UI မွာလုိ စစ္ထားေဆးထားတာ မပါတာမ်ားတယ္။ vendor ခ်င္းနားလည္မႈနဲ႕လုပ္စားေနၾကသလုိျဖစ္ေနတယ္။

SingPass မွာလည္း username က FIN/IC no. ဆိုေတာ႔ အဲဒီ အယ္လ္ဂိုရစ္သမ္ကို သိရင္ အလြယ္ေလးပဲ။ အေရွ႕ဆံုးတစ္လံုး၊ ေနာက္ဆံုးတစ္လံုး။ checksum ကို ဘယ္အယ္လ္ဂိုရသမ္နဲ႕စစ္ဆိုတာမ်ိဳးရိွတယ္။ ဒါမွလည္း system ေတြမွာ NRIC လက္ခံတဲ႔အခါ valid ျဖစ္၊မျဖစ္ စစ္ေပးႏုိင္မွာကိုး။

အခုနေျပာခဲ႔တဲ႔ Struts တို႕၊ Spring တို႕လို MVC framework  ေတြက အလကားေပးတာေတြပါ။ အဲဒီေတာ႔ source ကိုလည္း ၾကည္႕လုိ႕ရပါတယ္။ Framework တစ္ခုခ်င္းစီမွာ သူ႕အားသာခ်က္၊ သူ႕အားနည္းခ်က္နဲ႕ပါပဲ။ စနစ္တက်မသံုးရင္ loophole ျဖစ္တတ္ပါတယ္။ ဂ်ာဗားေပၚကာစတုန္းက applet ေတြစိတ္ခ်ရတယ္၊စိတ္ခ်ရတယ္လုပ္ေနရာက applet ခ်င္း session sharing လုပ္ေနတဲ႔ ျပႆနာကို ေစာေစာသိလုိက္လို႕ ျပႆနာသိပ္မၾကီးက်ယ္ဘဲ ျငိမ္းသြားဖူးတယ္။ web ေပၚမွာေတာ႔ ဘာမွ စိတ္ခ်ရတယ္မရိွပါဘူး။ ဖ်က္လိုဖ်က္စီးမလုပ္ခ်င္တဲ႔သူေတြ မဖ်က္လို႕၊ မပ်က္တာပဲရိွတယ္။ NASA က web ကို စမ္းသပ္ျပီးေတာ႔ စိတ္တုိင္းမက်လို႕ လူေတြသံုးဖုိ႕ေပးလုိက္တာဆုိေတာ႔ စကတည္းက အေျခခံျပႆနာေလးေတြရိွျပီးသား။ protocol ေတြက ကိုယ္ျပင္လုိ႕ရတာမဟုတ္ဘူး။ web architecture အတိုင္းရိွျပီးသားကို သံုးၾကရတာ။ browser ေတြကို ႏုိင္နင္းတဲ႔သူမ်ားၾကေတာ႔လည္း လုိသလို ဖ်ားေယာင္းႏုိင္ျပန္ေရာ။

တိုက္ခိုက္ခံရရင္ recovery အတြက္ Contingency Plan ရိွဖုိ႕အင္မတန္အေရးၾကီးပါတယ္။ အထူးသျဖင္႔ database ေတြပါပဲ။ က်န္တာေတြက ျပန္တက္လာေအာင္ တစ္နည္းနည္းနဲ႕ၾကံစည္လုိ႕ရေသးတယ္။ confidential data ေတြ ေပါက္ၾကားသြား၊ ပ်က္သြားရင္ေတာ႔ အစိုးရအေနနဲ႕လည္း အင္မတန္အထိနာႏုိင္တယ္။ တစ္ခ်ိဳ႕စနစ္ေတြမွာ ရံုးတြင္းမွာပဲ ေနာက္ေရြးေကာက္ပြဲအတြက္ အမတ္ေနရာေပးဖုိ႕ ရည္ရြယ္ထားျပီးသားလူေတြစာရင္းတုိ႕ဘာတုိ႕ရိွတတ္ေသးတယ္ဆိုေတာ႔ ဒါေတြလည္းပါသြားလို႕မျဖစ္ဘူး။ database ေတြကလည္း size ေပၚမူတည္ျပီး backup လုပ္ရတာၾကာတယ္။ port ေတြ ip ေတြကို trusted ကပဲ access လုပ္ႏုိင္ေအာင္ ဘယ္ေလာက္လုပ္ထားလုပ္ထား ေရွ႕နားက အကာအရံေတြ၊ မီးတံတုိင္းေတြျပိဳျပီဆိုရင္ေတာ႔ သူ႕မွာလည္း မစြမ္းသာေတာ႔ဘူး၊ရန္သူ႕လက္က်ရတာပဲ။

ဒါေတြကို တန္ျပန္ႏုိင္ဖုိ႕ ရုရွနဲ႕တရုတ္က geek ေတြကို စင္ကာပူအစိုးရက ေမြးစားဦးမယ္ထင္မိတယ္။ မၾကာခင္မွာ DSTA ရဲ႕အသံုးစားရိတ္၊ စင္ကာပူမွာ ယာယီစစ္မႈထမ္းရင္း ေသဆံုးတဲ႔စာရင္း၊ ဆီမီးအစိုးရကုမ္ပနီမ်ားအၾကားသေဘာတူညီမႈ၊ ဝန္ထမ္းအသံုးစားရိတ္၊ အီးအာရ္ပီ ေန႕စဥ္အျမတ္ေငြ၊ အစိုးရတစ္ဖက္လွည္႕လုပ္ငန္းမ်ားျဖစ္ေသာ MRT, singapore POOLS  ေတြရဲ႕ အျမတ္ေငြ၊ CPF စီမံခန္႕ခြဲေရးမူဝါဒ၊ အစိုးရ၏ ဘဏ္လုပ္ငန္းအေပၚစည္းၾကပ္မႈေတြကို ၾကားရင္ၾကားရမယ္။

ဘာေတြဆက္ျဖစ္ဦးမလဲဆုိတာေတာ႔ ကိုယ္႔ဟာကိုယ္ထုိင္ၾကည္႕တာ ပိုေကာင္းပါတယ္။ ဘာမွမျဖစ္ဘဲလည္း ျငိမ္းခ်င္ျငိမ္းသြားမွာ။ ဖုန္းေရႊအစြမ္းနဲ႕ကယ္တင္သြားတာမ်ိဳးမျဖစ္ဘူးမေျပာႏုိင္ဘူး။ ဒီမွာလည္း အဲဒါေတြကို ယံုၾကည္ပါဘိသနဲ႕။                    ။

Regards,
သုည

Explain Plan Oracle

Explain Plan

EXPLAIN PLAN FOR
SELECT * from [table] where [col1]='sth' and  [col2]='sth' and  and [col3]='sth' ;

select * from PLAN_TABLE;

Oracle မွာေတာ႔ အဲဒီလို execute လုပ္ၾကည္႕ေလ႔ရိွၾကတယ္။ ဒါမွ ကိုယ္႔ query က ဘယ္လို ဘယ္လို အလုပ္လုပ္ေနတယ္ဆိုတာ ေသခ်ာသိႏုိင္တယ္။

weblogic errors

weblogic errors

weblogic 8 က error ႏွစ္ခုအေၾကာင္းေျပာမယ္စိတ္ကူးတယ္။

တစ္ခုက stuck thread ပါ။ thread ေတြရဲ႕ maximum time ေက်ာ္သြားတာပါ။ process ေတြၾကာတဲ႔အခါျဖစ္ေလ႔ရိွပါတယ္။ report ေတြဘာေတြ ေႏွးေကြးေလးလံလာရင္ မၾကာမၾကာၾကံဳရပါလိမ္႔မယ္။ အလြယ္လမ္းကေတာ႔ ၁၅ မိနစ္မေလာက္ရင္ မိနစ္ ၂၀ တုိး၊ မိနစ္ ၂၀ မေလာက္ရင္ မိနစ္ ၃၀ တုိးေပါ႔။ ျဖစ္တဲ႔ root cause ကိုေတာ႔ ေနာက္မွ ေအးေဆးရွာေပါ႔။ ေလာေလာဆယ္ error မျမင္ရတာစိတ္ခ်မ္းသာရတာပဲ။ တစ္ခ်ိဳ႕ scenerio ေတြမွာဆိုရင္ အခ်ိန္ၾကာသြားရင္း stuck ျဖစ္ေနရာက unstuck ျပန္ျဖစ္သြားပါတယ္။ အျမဲေတာ႔ အဲဒီေလာက္အထိမၾကာဘူး။ stuck threads ေတြမ်ားလာရင္ instance တစ္ခုလံုး down သြားတာပဲ။

တကယ္ျဖစ္တာက ေရးတဲ႔သူေတြ လက္စြမ္းျပျပီး တလြဲေတြလုပ္ၾကလြန္းတာေၾကာင္႔ျဖစ္တယ္။ နည္းပညာေတြ ဘယ္ေလာက္တုိးတက္တုိးတက္၊ သံုးစြဲတဲ႔သူက နည္းလမ္းမမွန္ရင္ အဲဒါေတြက ၾကံဳျမဲၾကံဳေနရဦးမယ္။

မၾကာမီႏွစ္ေတြမွာ software ေတြကို app store မွာ game ေရာင္းေနသလုိ တစ္ခု တစ္က်ပ္နဲ႕ေရာင္းရေတာ႔မယ္ထင္တယ္။ အဲဒီေခတ္ေရာက္ရင္ေတာ႔ တကယ္ေကာင္းတဲ႔ဟာကိုပဲ တစ္က်ပ္တိတိေပးဝယ္ရလိမ္႔မယ္။ ေတာ္ရိေရာ္ရိေတြကေတာ႔ အလကားေပးေတာင္ မသံုးေလာက္ေတာ႔ဘူး။

ဒုတိယတစ္ခုက major. minor ဆိုလား။
အဲဒီတစ္ခုလည္း မွတ္ထားၾကပါ။ ရွာစားေဖြစားရတာခက္ရတဲ႔အထဲ တျခားသူေတြရဲ႕ျပႆနာေၾကာင္႔ ကိုယ္က်ိဳးမနည္းေအာင္ သတိထားရပါတယ္။ အဲဒါကေတာ႔ deployment လုပ္တဲ႔ Linux သမားေတြေၾကာင္႔ျဖစ္တာပါ။ ပံုမွန္အားျဖင္႔ java ဗာရွင္းတစ္ခုတည္းဆိုရင္ေတာ႔ ဘာမွမျဖစ္ပါဘူး။ production server မွာ jdk တစ္ခုထက္ပိုရိွေနရင္ root account နဲ႕ weblogic ကို restart လုပ္မိရင္ 1.5 နဲ႕တက္လာလိမ္႔မယ္။ အဲဒါဆို 1.4 နဲ႕ app ေတြမွာ compile လုပ္လိုက္တုိင္း jsp version conflict ေတြျဖစ္ျပီး page ေတြ တက္တစ္ခ်ိဳ႕၊မတတက္တစ္ခ်ိဳ႕ျဖစ္ကုန္မယ္။ အဲဒါဆိုရင္ restart လုပ္လုိက္တဲ႔သူကုိ weblogic user account နဲ႕ ျပန္ျပီး restart လုပ္ခုိင္းရတယ္။ အဲဒါေလးေတြက system အေဟာင္းေတြကို ထိန္းသိမ္းေနတဲ႔သူေတြအတြက္ေတာ႔ သိထားရမယ္႔ကိစၥေတြ။

အခုတေလာ log file ေတြၾကည္႕ရင္ အဲဒီ error ႏွစ္ခုကိုအရင္စစ္ျဖစ္တယ္။ မၾကာမၾကာၾကံဳခဲ႔ျပီးျပီ။

ျဖစ္ကတတ္ဆန္းေရးခဲ႔ျခင္း အခ်င္းခ်င္း ကင္းရွင္းၾကပါေစ။
Zero

Maven config

Maven config

Java မွာ ANT build က အေတာ္နာမည္ၾကီးတယ္။ maven ကေတာ႔ dependency ကိစၥေတြအတြက္ပိုအသံုးဝင္သလုိရိွတယ္။ အၾကမ္းဖ်င္း အဲဒီလိုေတာ႔ နားလည္တယ္။ အရင္ရံုးမွာေတာ႔ maven သံုးတယ္။ အခုရံုးနဲ႕က်န္ရံုးေတြမွာေတာ႔ ANT build ပဲသံုးတယ္။

အမွန္ေတာ႔ သိပ္မလိုလွဘူး။
သို႕ေသာ္လည္း တစ္စုတစ္ေဝးျဖစ္သြားေအာင္ အဲဒါေလးေရးလုိက္တယ္။
http://maven.apache.org/download.cgi ကေနျပီး maven ဗာရွင္းတစ္ခုခု download အရင္လုပ္။

ျပီးရင္ extract လုပ္စရာလိုရင္လုပ္။

Environment variable ကေနျပီး MAVEN_HOME လုပ္ခ်င္လုပ္။ JAVA_HOME နဲ႕ခပ္ဆင္ဆင္ပဲ။  PATH ထဲမွာ bin folder ကို point လုပ္။ အဲဒါက အလုပ္ရွဳပ္တယ္ထင္တယ္။ အဲဒီေတာ႔ command line ကပဲ။

set PATH=C:\maven\bin;%PATH%

C:\maven ကေတာ႔ ကိုယ္extract လုပ္ထားတဲ႔ location ေပါ႔။ အဲဒီလိုလုပ္လုိက္ျပီးရင္။ mvn --version ဆိုျပီး command prompt ကေနရိုက္။ အိုေကတယ္ဆိုရင္ maven version ေတြေပၚလာမယ္။ jdk 5 သို႕မဟုတ္ 6 နဲ႕ေတာ႔ရတယ္။ က်န္တဲ႔ ဗာရွင္းေတြေတာ႔ မသိ။ maven ရဲ႕ default local folder က .m2 ဆိုတဲ႔ဟာ။ User folder ေအာက္မွာရိွတယ္။ အဲဒါကိုလည္း ေျပာင္းခ်င္ရင္ maven folder ထဲက config မွာျပင္လုိက္လုိ႕ရတယ္။ ခပ္လြယ္လြယ္ပဲ။

maven ရိွမွ pom.xml ဆိုတဲ႔ build file ေတြကို build လုပ္ႏုိင္မယ္။ web service စာအုပ္ဖတ္ရင္း maven setup လုပ္စရာလိုတာနဲ႕ တစ္ခါတည္းေရးထားလုိက္တာပါ။ web service ေတြအေၾကာင္းဘက္ ဆက္ေရးမယ္စိတ္ကူးတယ္။

ref:
http://maven.apache.org/download.cgi

sequence Vs Max+1

sequence Vs Max+1

Max+1 ေရးတဲ႔သူေတြ အရင္တုန္းက ေတာ္ေတာ္မ်ားမွန္းသတိထားမိတယ္။  unique key တစ္ခုကို ရဖုိ႕ ရိွျပီးသား ေဒတာေတြအားလံုးကိုျပန္ဖတ္ျပီး ၁ေပါင္းရတာ ေရးတဲ႔သူအတြက္လြယ္ေပမယ္႔ ေဒတာေဘ႔စ္အတြက္ေရရွည္မွာ မလြယ္ဘူး။ အဲဒီလိုေရးတာပ်င္းတဲ႔သူေတြထင္တယ္။ table ၾကီးေတြ ဝဝဖုိင္႔ဖုိင္႔ျဖစ္လာတဲ႔အခါ Max+1 က ဒုကၡေပးတတ္ပါတယ္။ sequence table လုပ္ျပီး .nextValue နဲ႕သြားပါ။ အင္မတန္ျမန္ပါလိမ္႔မယ္။

sequence  တစ္ခုနမူနာျပရရင္ ေဟာသလိုေရးပါတယ္။

CREATE SEQUENCE auto_icrrm_attendance_seq
  MINVALUE 1
  MAXVALUE 999999999999999999999999999
  START WITH 2013000079
  INCREMENT BY 1
  CACHE 20;
 
အဲဒီလို create လုပ္ျပီးရင္ ဒီလို သံုးရံုပါပဲ။

  select auto_icrrm_attendance_seq.nextval from dual

Cache 20 ေပးထားတာကေတာ႔ memory မွာ အခု ၂၀ တစ္ခါတည္းသိမ္းထားလုိ႕ရေအာင္ oracle ကိုသတိေပးတာပါ။ အဲဒါက နည္းနည္းပိုျမန္ေစပါတယ္။ ကိုယ္လိုခ်င္တာက unique ျဖစ္ရံုပဲလား။ sequence ျဖစ္ဖုိ႕လုိသလားဆိုတာေပၚမူတည္ျပီး နည္းနည္းေလာက္ေတာ႔ စဥ္းစားျပီးသံုးၾကပါ။

Regards,
Zero
 

xss attack

xss attack

xss attack အတြက္ Java သမားေတြ JSTL သံုးပါ။
အေျခခံကိစၥေတြ နားေအးသြားပါလိမ္႔မယ္။

မဟုတ္ရင္ေတာ႔ secuirty audit လာရင္ ျပင္မဆံုးျဖစ္ေနလိမ္႔မယ္။

Regards,
Zero

submit Vs button

submit vs button

Struts မွာ ေတာ္ေတာ္ေလးၾကံဳရတဲ႔တစ္ခုက အဲဒီျပႆနာပဲ။ input type ကုိ submit လုိ႕ေရးျပီး onclick မွာ javascript submitPage စတဲ႔ function ေရးၾကတာေတြ႕တယ္။ အဲဒါ ျပႆနာရိွတယ္။

double submission ျဖစ္ေစႏုိင္သလို၊ parameter passing တစ္ခုခုကို javascript submitPage မွာ set လုပ္ထားရင္ၾကေတာ႔ တစ္ခါတစ္ခါ အဲဒီ parameter set မလုပ္ခင္ submit button ရဲက submit နဲ႕ form က submit ျဖစ္သြားျပီး set လုပ္ရမယ္႔ variable က null ျဖစ္သြားတတ္ပါတယ္။

အဲဒီေတာ႔ အလြယ္ဆံုးနည္းက submitPage လို javascript နဲ႕ form submit လုပ္မယ္လို႕ရည္ရြယ္ရင္ input type ကို button ပဲေပးပါ။ တစ္ျခားအေထြအထူးဘာမွမလုပ္ဘဲ click ႏွိပ္တာနဲ႕ form submit လုပ္ခ်င္မွ input type=submit သံုးပါ။ 

အဲဒီဟာက ေျပာလုိက္ရင္ အင္မတန္လြယ္တယ္။ ျပႆနာျဖစ္တဲ႔အခါ ရွာၾကည္႕ရင္ေတာ္ေတာ္နဲ႕မေတြ႕ဘူး။ လူမ်ားေတြရဲ႕ အမွားကေန သင္ခန္းစာယူပါ။ ကိုယ္တုိင္မွားၾကည္႕ေနစရာမလိုေတာ႔ဘူးေပါ႔။

Regards,

Zero

Oracle SQL optimization

Oracle SQL optimization

Oracle SQL optimizationနဲ႕ပတ္သက္ျပီး နည္းနည္းေလာက္ေျပာခ်င္တယ္။ background scenerio က ရွင္းရွင္းေလးပဲ။ table တစ္ခုက date ကို minimum function နဲ႕ရွာတာပဲ။ min(attendance_date) ဆိုပါေတာ႔။ အဲဒါကို ဒီအတိုင္းေရးျပီး development database မွာေရာ၊ UAT/QA ေတြမွာေရာအိုေကတယ္။ production မွာၾကေတာ႔ attendance_date မွာက index မေပးထားေတာ႔ ၁၀ နာရီေက်ာ္ၾကာသြားတယ္။ ဒါမ်ိဳးက မျဖစ္ဘူးမေျပာႏုိင္ဘူး။ ျဖစ္တာမ်ားတယ္။ index ေသခ်ာမလုပ္ထားရင္ query လုပ္တဲ႔အခါမွာ oracle က full scanning လုပ္ရတယ္။ အဲဒီမွာ table က ဧရာမၾကီးျဖစ္ေနရင္ query တစ္ေၾကာင္းခ်င္းစီအတြက္ အခ်ိန္က သိပ္ၾကာသြားတတ္တယ္။ အေကာင္းဆံုးကေတာ႔ attendance_date အပါအဝင္ query criteria ေတြကို index ေပးလိုက္တာပဲေပါ႔။

အဲဒီကိစၥကို သံုးေလးငါးရက္ research လုပ္ၾကည္႕တယ္။ oracle မွာက index အမ်ိဳးမ်ိဳးေဆာက္ထားျပီး ကိုယ္သံုးခ်င္တဲ႔ index ကို hint ေပးလုိ႕ရတယ္။

ေနာက္တစ္ခုက ကိုယ္ေရးလုိက္တဲ႔ query ေတြကို Explain Plan လုပ္ၾကည္႕ၾကဖုိ႕ပါ။ အဲဒါဆိုရင္ ေတာ္ရံုတန္ရံု အမ်ားၾကီးၾကီးေတြ မွားစရာသိပ္မရိွေတာ႔ဘူးေပါ႔။

ေနာက္တစ္ခုက သိပ္ကို ေႏွးေကြးေလးလံျပီး ဒုကၡေပးေနတဲ႔ query ေတြကို DBA privilage နဲ႕ဒီလိုရွာၾကည္႕လို႕ရပါတယ္။
SELECT * FROM (SELECT * FROM v$sql ORDER BY cpu_time DESC) WHERE ROWNUM <= 250;

ဒါဆိုရင္ cpu_time အၾကာဆံုး ထိပ္သီး ၂၅၀စာရင္းရပါမယ္။ အဲဒီထဲကမွ ကိုယ္႔ကို ဒုကၡေပးေနတဲ႔ query ကိုရွာၾကည္႕ရင္ေတြ႕ႏုိင္ေလာက္ပါတယ္။

ေနာက္တစ္ခုကေတာ႔ ဘယ္ယူဆာအေကာင္႔ထ္ေတြနဲ႕ကိုယ္႔ database ကိုလာခ်ိတ္ထားသလဲဆိုတာကို session ကိုၾကည္႕ျပီးသိႏုိင္ပါတယ္။
SELECT * FROM v$session WHERE ROWNUM < 250;

index ေတြနဲ႕ပတ္သက္ျပီး rule ေတြရိွပါေသးတယ္။ အၾကမ္းဖ်င္းေျပာရင္ေတာ႔ index ထည္႕လုိက္ရင္ select query ေတြျမန္ျပီး update နဲ႕ insert နဲ႕ေႏွးသြားတတ္ပါတယ္။ ကိုယ္႔ရဲ႕ system ေပၚမူတည္ျပီး အလြန္အကြ်ံမျဖစ္ေအာင္သတိထားျပီးသံုးၾကရတာပါပဲ။

ကိုယ္ၾကံဳလိုက္တာတစ္ခုကို အမွတ္တရအေနနဲ႕ျပန္ေရးလုိက္တာပါ။ သိျပီးသားဆိုရင္ ပိုမွတ္မိေအာင္၊ မသိေသးရင္ သတိထားဖုိ႕။ အဲဒီေလာက္ပဲရည္ရြယ္ပါတယ္။

ref:
http://docs.oracle.com/cd/B19306_01/server.102/b14211/hintsref.htm

Regards,
Zero

Unwanted Emails

Unwanted Emails

ျဖစ္ေလ႔ျဖစ္ထရိွတဲ႔ျပႆနာတစ္ခုပါ။
testing လုပ္ရင္း users အစစ္ေတြဆီကို test enviornment ကေန mails ေတြပို႕မိတဲ႔ျပႆနာပါ။
 development လုပ္တာျဖစ္ျဖစ္၊ maintenance လုပ္တာျဖစ္ျဖစ္ ၃ ႏွစ္နဲ႕ ငါးႏွစ္ၾကားေလာက္ၾကာရင္ ဒီလိုျပႆနာအနည္းဆံုးတစ္ခါေလာက္ေတာ႔ ၾကံဳဖူးတတ္တယ္။

ဘယ္လိုေရွာင္သင္႔သလဲဆိုတာကေတာ႔ နည္းေတြ အမ်ားၾကီးရိွပါတယ္။ အဲဒီအထဲက က်ေနာ္သေဘာက်တဲ႔နည္းတစ္ခ်ိဳ႕ကို နည္းနည္းေဝငွခ်င္ပါတယ္။

Rule1.
production ကေန ေဒတာကို ယူတုိင္း mask လုပ္သင္႔တာေတြကို တစ္ခါတည္း mask လုပ္ျပီးမွ extract လုပ္ပါ။

Name, NRIC, email စတာေတြက confidential ေတြပါ။ ျဖစ္ႏုိင္ရင္ production data ကို functional test လုပ္ဖုိ႕မသံုးတာအေကာင္းဆံုးပဲ။

Rule2.
Switch off Email function

စမ္းခ်င္တာက အီးေမးလ္ပို႕၊မပို႕စမ္းတာမဟုတ္ရင္ အီးေမးလ္ပို႕တဲ႔ function ကို off လုပ္ထားပါ။ ျဖစ္တတ္တာတစ္ခုက စုတ္စုတ္ျပတ္ျပတ္ coding ေတြမွာ ေနရာတကာက အီးေမးလ္ပို႕ေနတတ္တာပါပဲ။ ေသခ်ာလုိက္ရွာျပီး၊ တစ္ခုမက်န္ပိတ္ထားပါ။ ဒါမွမဟုတ္ configuration တစ္ဆင္႔ခံထားျပီး UAT environment ဆိုရင္ auto off ေနေအာင္လုပ္ထားပါ။

မလုိလားအပ္တဲ႔ အီးေမးလ္ကို မပို႕သင္႔တဲ႔ေနရာပို႕မိရင္ ျပႆနာက အက်ယ္အက်ယ္မျငိမ္းဖြယ္ျဖစ္ႏုိင္တယ္ဆိုတာကို သတိထားပါ။ ကိုယ္႔ဖက္က မမွားသင္႔တာမမွားေအာင္ဂရုစိုက္တာအေကာင္းဆံုးပဲ။

Rule3.
Check scheduler for sending out email

Reminder email ေတြကို scheduler နဲ႕ run ေလ႔ရိွပါတယ္။ တတိယေျမာက္အလုပ္မွာ ေရွ႕ကတစ္ေယာက္ထြက္သြားေတာ႔ testing ဝင္လုပ္ရင္း sheduler testing မွာ အဲဒီျပႆနာၾကံဳလုိက္ရပါတယ္။ တစ္ပတ္ကို တစ္ေစာင္ေလာက္ သူ႕ဖာသာသူပို႕ေနတာ။ ေနာက္ေတာ႔မွ တရားခံကိုေတြ႕တယ္။ ေရွ႕လူက ဘာမွမေျပာသြားရင္ အဲဒါေတြသိဖုိ႕မလြယ္ဘူး။ test data ေတြကို production က ကူးထားတာလားကအစ ေသခ်ာေအာင္ေမးထားဖုိ႕လုိတယ္။

တစ္ခါတစ္ေလ ၾကားျဖတ္ျပီး တာဝန္ယူရတဲ႔အခါေတြမွာ ကိုယ္မသိႏုိင္တာေတြ အမ်ားၾကီးရိွမယ္။ အဲဒီလိုဆုိရင္ အလြယ္တကူ assume မလုပ္ပါနဲ႕။ ေသခ်ာေအာင္စစ္ျပီးမွ confirm လုပ္ပါ။

ျပႆနာက ႏွစ္ပိုင္းကြဲေနတာကို သတိျပဳမိမလားမသိဘူး။ တစ္ခုက ကိုယ္တုိင္ အစအဆံုးသိေနတာမ်ိဳး။ အဲဒါမ်ိဳးက သိပ္ျပႆနာမတက္ဘူး။ ေနာက္တစ္ခုက ကိုယ္က အသစ္ဝင္တုန္း၊ ေရွ႕ကဘယ္လိုလုပ္သြားမွန္းမသိတာမ်ိဳးက ပိုအႏၱရာယ္မ်ားတယ္။ အဲဒါကို ေသခ်ာ ဂရုတစုိက္လုပ္ဖုိ႕လိုပါတယ္။

testing အတြက္ Environment ကို သီးသန္႕ျပင္ဆင္ျပီး၊ test data ကိုလည္း ကိုယ္စမ္းခ်င္တဲ႔ fuction အတုိင္း လုိသေလာက္ျပင္ဆင္ထားရင္ ေတာ္ေတာ္ေလး စိတ္ခ်ရပါျပီ။ အဲဒီအျပင္ email ကို config လုပ္တဲ႔အက်င္႔ထားျပီး၊ Environment အလုိက္ သံုးရမယ္႔အီးေမးလ္၊ပို႕ရမယ္႔ အီးေမးလ္ တစ္ခါတည္း pre-defined လုပ္ထားလုိက္ရင္ ေနာင္လားေနာက္သားေတြလည္းအဆင္ေျပတာေပါ႔ခင္ဗ်ာ။

ANT build ေတြကိုလည္း တစ္ခါတည္း UAT,QA,PROD ခြဲထားလုိက္ျပီး၊ build လုပ္တာနဲ႕ အီးေမးလ္ဆက္တင္ေတြ ကိုယ္လုိသလိုအလုပ္လုပ္ေအာင္ ျပင္ဆင္ထားရင္လည္း သင္႔တာပါပဲ။

ဒါက နည္းပညာအခက္အခဲေတာ႔ မဟုတ္ပါဘူး။ အလုပ္ထဲမွာ ၾကံဳရတတ္တာတစ္ခုကို သတိထားႏုိင္ဖုိ႕ေရးလုိက္တာပါ။ သတိထားႏုိင္ရင္ အမွားနည္းတာပါပဲ။


Regards,
Zero

Why CentOS ?

System Engineer ဒါမွမဟုတ္ Unix / Linux engineer လုပ္ဖို႕ ရည္ရြယ္ခ်က္ထားရင္ Ubuntu လို OS မ်ိဳးထက္ CentOS ကို ပိုေလ့လာဖို႕ ေျပာဖူးပါတယ္။ ဘာလို႕လည္း ? Ubuntu လည္း Server သုံးလို႕ရတယ္၊ Debian လည္း ေတာ္ေတာ္ေကာင္းတယ္၊ CentOS က ဘာပိုသာသလည္း ?

ဒီလိုေမးရင္ေတာ့ Technically ဘာမွ ပိုမသာဘူး လို႕ပဲေျဖရပါမယ္။ Package update ေတြမွာဆိုလည္း Debian / Ubuntu ကပိုျမန္တယ္။ Ubuntu နဲ႕ Debian မွာဆိုရင္ေတာ့ Server အတြက္ဆိုရင္ Debian ကပိုေကာင္းေနပါေသးတယ္။ Free Opensource ျဖစ္ခ်င္း community အားေကာင္းျခင္းေတြေၾကာင့္ Debian နဲ႕ Ubuntu က SME server ေတြမွာ Redhat / CentOS ထက္ ေနရာပိုယူလာႏိုင္ပါတယ္။ ဒါေပမယ့္.... ဒါဟာ စာလုံးၾကီးၾကီးနဲ႕ ေရးသင့္တယ့္ 'ဒါေပမယ့္'ပါ ..

Enterprise environment ေတြမွာ Redhat ကို ေက်ာ္ႏိုင္တယ့္ Linux မရွိေသးဘူးလို႕ပဲ ေျပာရပါမယ္။ Commercial support ဆိုတာကို ခဏေမ့ထားျပီး server တစ္ခုအတြက္ တျခားအေၾကာင္းအရာေတြကို ထဲ့စဥ္းစားၾကည့္ရေအာင္။ Enterprise ၾကီးတစ္ခုရဲ့ database server လို႕ေျပာရင္ MySQL , PostgreSQL တို႕မျဖစ္ဖို႕မ်ားပါတယ္။ Oracle ျဖစ္ရင္ျဖစ္မယ္၊ IBM DB2 လည္းျဖစ္ရင္ျဖစ္မယ္၊ ဒီလို giant commercial product ၾကီးေတြက သူတို႕ product အတြက္ support ကို branded OS ေတြအတြက္ပဲ ေပးပါတယ္။ ဆိုလိုတာကေတာ့ Oracle က AIX , HP-UX မွာပဲ support လုပ္တယ္လို႕ ေျပာထားရင္ ၊ တျခား OS မွာသြင္းလို႕ ျဖစ္သမွ် ျပသနာကို သူတို႕တာဝန္မယူပါဘူး။ သုံးေနရင္းနဲ႕မွ ျဖစ္ရင္ သူတို႕ product က ျပသနာဆိုရင္ေတာင္ unsupported configuration ဆိုျပီး technical support ေပးဖို႕ ျငင္းႏိုင္ပါတယ္။ User ဘက္က supported hardware / supported OS မွာမသုံးရင္ သူတို႕ ျပသနာမဟုတ္ဖူးလို႕ သတ္မွတ္ပါတယ္။ အဲေတာ့လည္း Enterprise company ၾကီးေတြက အမွားမခံႏိုင္တယ့္ Server ေတြမွာ branded OS ၾကီးေတြသုံးဖို႕ပဲ စဥ္းစားပါတယ္။ ဒါက Redhat ပိုေနရာရရျခင္း အေၾကာင္းတစ္ခု။

ေနာက္တစ္ခုက stability ပါ။ Redhat မွာ fancy new stuffs ေတြမပါပါဘူး။ Package တိုင္းက ေနာက္ဆုံး up to date ကိုမရႏိုင္ပါဘူး။ ဒါက drawback လို႕ေျပာလို႕လည္း ရပါတယ္။ လုံးဝ stable လို႕သတ္မွတ္တယ့္ version အထိပဲ ေပးပါတယ္။ New feature ေတြကိုစမ္းသပ္ျပီး အဆင္ေျပရင္ေတာ့ back ported လုပ္ေပးပါတယ္။

ေနာက္တစ္ခုက Support။ Commercial Support ဆိုတာ ပိုက္ဆံေပးရတာကိုပဲ တြက္လို႕မရပါဘူး။ တစ္ခုခုျဖစ္ရင္ ေနာက္မွာ ဒီ product ကို specialize လုပ္တဲ့ expert ေတြရွိတယ္လို႕ စိတ္ထဲထားလို႕ရပါတယ္။ Red Hat ရဲ့ L3 support ေတြက အမ်ားအားျဖင့္ RH ရဲ့ သက္ဆိုင္ရာအပိုင္းကို in and out သိတဲ့သူေတြပါ။ ဒါ Commercial Support ေတာ္ေတာ္မ်ားမ်ား အတူတူပါပဲ။ အဲဒီအတြက္ ျပသနာ ေတာ္ေတာ္မ်ားမ်ားကို ေနာက္ဆုံး ကိုယ့္ IT team က မေျဖရွင္းႏိုင္ရင္ေတာင္၊ သက္ဆိုင္ရာ support team က ကူညီႏိုင္လိမ့္မယ္လို႕ ယံုၾကည္လို႕ရပါတယ္။

ဒါေတြက MNC ေတြ Enterprise company ၾကီးေတြက Red Hat ကို Debian ထက္ ပိုသုံးတဲ့ အေၾကာင္းရင္းေတြထဲက တခ်ိဳ႕ပါ။ အဲေတာ့ Debian ကိုကြၽမ္းက်င္တာထက္ Red Hat ကြၽမ္းက်င္တာက Big sh*t company ၾကီးေတြက ေခၚတယ့္ အလုပ္ေတြနဲ႕ ပိုအဆင္ေျပႏိုင္ပါတယ္။ ဒါေၾကာင့္ CentOS ကိုေလ့လာတာက ပိုျပီး အခြင့္အေရးရွိပါတယ္။ (SuSE ေလလာခ်င္ရင္လည္း OpenSuSE ေလ့လာပါ။ )

 တကယ္တမ္း Red Hat expertise လို႕ ေျပာရင္ OS တစ္ခုထဲနဲ႕ မရပါဘူး။ JBoss လို႕ middleware ေတြ၊ RH Cluster ေတြ၊ RHN Satellite တို႕ product ေတြပါ သိဖို႕ လိုလာမွာပါ။ ဒါက Career အရ ေနာက္မွ Advance ျဖစ္သြားပါလိမ့္မယ္။  ဒီ post က ႏိုင္ငံျခားကို ထြက္ျပီး အလုပ္ရွာဖို႕ ရည္ရြယ္ထားၾကတဲ့ Administrator level အတြက္ကို ရည္ရြယ္တာပါ။ Linux ကို Career အျဖစ္ေရြးခ်င္တယ္ဆိုျပီး ၊ ဒါေပမဲ့ ေလ့လာတာ မွားေနရင္ အလုပ္ရွာရင္ အခက္အခဲေလးေတြ ရွိတတ္ပါတယ္။  ႏိုင္ငံျခားကို ထြက္ျပီး အလုပ္လုပ္ၾကရင္ အလုပ္ဝင္ဝင္ခ်င္းမွာ ရွိတတ္တဲ့ stress နဲ႕ ကိုယ္ေသခ်ာမသိတာကို စမ္းတဝါးဝါးလုပ္ရရင္ ျဖစ္တဲ့ stress က တခ်ိဳ႕ကို  လက္ေျမႇာက္ျပီးျပန္ခ်င္ေလာက္ေအာင္ျဖစ္ေစတဲ့အထိ ဆိုးပါတယ္။ အဲဒါေၾကာင့္ Linux သမားလုပ္ခ်င္တယ္၊ ႏိုင္ငံျခားထြက္မယ္ဆိုရင္ေတာ့ CentOS ကိုေလ့လာဖို႕ အၾကံေပးခ်င္ပါတယ္။

.............
ဒီ စာက ေရးထားတာ လြန္ခဲ့တဲ့ ႏွစ္ႏွစ္ကပါ ။ Linux တစ္ရပ္စာ ေမ်ာ္စင္ post သုံးခုျပီးေတာ့ ေရးထားတာ။ အခု စာျပန္ေရးမည္စဥ္းစားေတာ့ ဘာေရးရမွန္းမသိလို႕ ဒါကို ျပန္ရွာျပီး တင္လိုက္တယ္ ဟဲဟဲ ။ စာျပန္ေရးဖို႕ ၾကိဳးစားပါအုန္းမယ္ ။

Divinity

Related Posts
Linux တစ္ရပ္စာ ေမွ်ာ္စဥ္ထက္က ျမင္ကြင္း
Linux တစ္ရပ္စာ ေမွ်ာ္စဥ္ထက္က ျမင္ကြင္း (2)
Linux တစ္ရပ္စာ ေမွ်ာ္စဥ္ထက္က ျမင္ကြင္း (3)

ဪ ssh logon attempt ေတြ

Log file ေတြထဲမွာ လိုခ်င္တာရွာရတာ အခက္ဆုံးနဲ႕ စိတ္ညစ္စရာ အေကာင္းဆုံးက auth.log ျဖစ္မယ္ထင္တယ္။ Internet facing server ေတြမွာ ( Internet ကတိုက္႐ိုက္သုံးလို႕ရတယ့္ ၊ company အတြင္းပဲသုံးတာမဟုတ္တယ့္ server မ်ိဳးကိုေျပာခ်င္တာပါ) တစ္နာရီမွာ failed login attempt က 500 ေလာက္ရွိတတ္ပါတယ္။ ေျပာရရင္ေတာ့.. ဒါပံုမွန္ပါ။ တကယ္ target ထားျပီး လုပ္တာမ်ိဳးမဟုတ္ပါဘူး။ Botnet တစ္ခုက IP range တစ္ခုအတြင္း ရွိသမွ် server ေတြကို dictionary ေသးေသးတစ္ခုနဲ႕ attempt လုပ္ၾကည့္တာေလာက္ပဲရွိမယ္။ ရည္ရြယ္ခ်က္ရွိရွိေတာင္မဟုတ္ဖူး၊ ဒီလိုပဲ ေရာေကာေသာေကာပါသြားတာေတာင္ ဒီေလာက္ေတာ့ရွိမယ္။ ဟုတ္တယ္ တစ္ခါတစ္ေလ ကံေကာင္းရင္ တစ္နာရီေလာက္အတြင္း attempt ေလး ငါးေသာင္းေလာက္လဲျဖစ္ႏိုင္တယ္။ Failed attempt ပဲ ျပသနာမဟုတ္ပါဘူးလို႕ေျပာလို႕ရေပမယ့္ attempt လုပ္ခံရတာဟာ cracked ျဖစ္ဖို႕ တစ္ဆင့္နီးတာပဲ။ ( က်ေနာ္အတြက္ကေတာ့ ဘာပဲျဖစ္ျဖစ္ မ်က္စိေနာက္ပါတယ္။)

SSH service ရွိေနသမွ် ဒါမ်ိဳးေတြရွိမွာပဲ၊ SSH service disable လိုက္တာေကာင္းမယ္။ ဟုတ္တာေပါ့။ ဒါဆို attacker တင္မဟုတ္ဖူး ကိုယ္ပါဝင္လို႕မရေတာ့ဘူး ဟဲဟဲ၊ ဒါဆိုအလုပ္နည္းတာေပါ့။ အမွန္က SSH service run ထားရင္ သတိထားသင့္တာေလးေတြ ေရးမလို႕ပါ။ က်ေနာ္လို failed attempt ေတြကိုမ်က္စိေနာက္တဲ့သူအတြက္ ၊ ဒါမ်ိဳးေတြ နည္းသြားေအာင္လို႕ လုပ္လို႕ရတဲ့ နည္းေလးေတြေပါ့။

1. Root login
SSH ကေန direct root login ကို disable လုပ္ထားသင့္ပါတယ္။ Normal user နဲ႕ပဲဝင္ျပီး sudo သုံးတာျဖစ္ျဖစ္ ၊ root user နဲ႕သုံးရမွ ေက်နပ္ရင္လည္းေနာက္မွ su ျပန္ေျပာင္းျပီးျဖစ္ျဖစ္သုံးသင့္ပါတယ္။ ဘာလို႕လည္းဆို အေၾကာင္းျပခ်က္တစ္ခုက ၊ bot ေတြရဲ့ အဓိက target က known user account ေတြကိုပါ။ Linux / Unix မွန္ရင္ root ဆိုတယ့္ နာမည္နဲ႕ user ကရွိမွာပါပဲ။ အဲေတာ့ username မွန္းစရာမလိုပဲ password ေလာက္ပဲမွန္းရေတာ့မွာေပါ့။ အဲဒါမ်ိဳးမျဖစ္ေအာင္ root login ကို disable ထားျပီး admin ဆိုျပီး user account လုပ္ျပီးသုံးရင္လည္း သိပ္မထူးဘူးေပါ့။ ျဖစ္ႏိုင္ရင္ အဲလို username မ်ိဳးကိုလည္း မသုံးသင့္ပါဘူး။

2. SSH service port
ဒါက မထင္မွတ္စရာ အသုံးတဲ့ပါတယ္။ SSH attempt အေတာ္မ်ားမ်ားက port 22 ကိုပဲ ၾကိဳးစားၾကတာမ်ားပါတယ္။ Port scan တစ္ခါဖတ္၊ တစ္ခါ attempt လုပ္ဆိုတာမ်ိဳးက bot နဲ႕ random စမ္းတယ့္သူမ်ိဳးက သိပ္မၾကိဳးစားပါဘူး။ SSH port ကို တျခား port တစ္ခုေျပာင္းသုံးသင့္ပါတယ္။

3. public-key authentication
ျဖစ္ႏိုင္ရင္ public-key authentication only သုံးသင့္ပါတယ္။ Password နဲ႕ authenticate လုပ္တာကို လံုေလာက္တဲ့ security measure လို႕ မသတ္မွတ္ေတာ့တာ ၾကာပါျပီ။ SSH tunnel ေဆာက္တယ့္အခ်ိန္ username / password အဆင့္မေရာက္ခင္မွာ key အရင္စစ္ပါတယ္။ ( ssh -v နဲ႕ စမ္းၾကည့္ပါ။) တကယ္လို႕ public key authentication only ဆိုရင္ rsa / dsa key မမွန္ရင္၊ မေတြ႕ရင္ကို authentication break out ျဖစ္သြားပါျပီ ။ Username / password အဆင့္ကို မဆက္ေတာ့ပါဘူး။ အဲေတာ့ Security ပိုေကာင္းတယ္ေပါ့။ Log ကေတာ့ တက္အုန္းမွာပါ။

ေျပာလက္စနဲ႕မို႕လို႕ပါ။ Account password ေတြကို လြယ္လြယ္ကူကူမေပးသင့္ပါဘူး။ Username = admin , password = admin ဆိုတာမ်ိဳးကေတာ့ ပါသြားရင္နည္းေတာင္ နည္းေသးတယ္ေျပာရမွာပါပဲ။

ဆယ္မိနစ္မၾကာတယ့္ implementation ပါ။ ဒါေပမယ့္ security အရေတာ့ အမ်ားၾကီးကို ကြာသြားပါတယ္။ SSH brute force ကိုလည္း အတိုင္းအတာ တစ္ခုထိ ကာကြယ္ျပီးသားျဖစ္ပါတယ္။ တစ္ခါတစ္ေလေတာ့လည္း သိပ္မပ်င္းတာ ေကာင္းပါတယ္ :D

Divinity