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