Thursday, February 7, 2013

ဪ 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

2 comments:

Zephyr said...

တကယ္လြယ္တဲ႔နည္းက ျမန္မာျပည္ကလာတယ္။
ဘယ္ဟက္ကာမွ ဟက္လို႕ကိုမရဘူး။

power off ထားလိုက္ရံုပဲ။

:P

Divinity said...

ျမန္မာျပည္မွာ ဒါမ်ိဳးမျဖစ္ဖူးဗ် ၊ attempt တစ္ခုနဲ႕ တစ္ခုၾကား သုံးမိနစ္ေလာက္ျခားတယ္ ။ connection ေႏွးလို႕။ ISP ကေနစျပီး အဲလို infra နဲ႕ထိန္းထားတာ :D