ဪ 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

SUID ဆိုတာ

Linux / Unix system ေတြအေၾကာင္းေလ့လာရင္ SUID / SGID ဆိုတယ့္ အသုံးအႏွုန္းမ်ိဳး ေတြ႕ရတတ္ပါတယ္ ။ SUID ဆိုတာ Set User ID ကို အတိုေခၚတာပါ။ Executable file ေတြရဲ့ permission မွာ ေပးေလ့ရွိပါတယ္ ။ SUID ေပးရတယ့္ ရည္ရြယ္ခ်က္က executable permission ရွိတယ့္ ဘယ္ user ကပဲ execute လုပ္လုပ္ ၊ ဒီ command / file ကို file owner ရဲ့ identity နဲ႕ run လိုက္ပါတယ္။ ဆိုလိုတာကေတာ့ root user ရဲ့ file တစ္ခုကို everyone executable ေပးထားမယ္၊ ဒါေပမဲ့ SUID set ထားရင္ ဘယ္ user ကပဲ run run ဒီ file က root user အေနနဲ႕ run ပါမယ္။ အနီးစပ္ဆုံး လို႕ ထင္တယ့္ windows ဥပမာကေတာ့ run as administrator နဲ႕ run သလိုေပါ့။ ( သိပ္ေတာ့မတူသလိုပါပဲ။ Run as administrator ကိုေသခ်ာမသိလို႕ မေျပာႏိုင္ပါဘူး)

Linux / Unix မွာ file permission ကို rwx ( Read, Write, Execute) ဆိုျပီး သတ္မွတ္ပါတယ္။ SGID / SUID ေပးထားရင္ေတာ့ s ဆိုတာေလးေတြ႕ရေလ့ရွိပါတယ္။ဥပမာေလး ေျပာရေအာင္ ။

User တိုင္းကို cd တို႕ ls တို႕လို command မ်ိဳးကိုေတာ့ ေပးသုံးရပါတယ္။ အဲလို command တစ္ခုရဲ့ permission ကိုၾကည့္ရင္

$ ls -l /bin/ls
-rwxr-xr-x 1 root root 116688 2010-04-28 23:56 /bin/ls

File ရဲ့ owner က root ျဖစ္ျပီး other users ( Everyone ေပါ့ဗ်ာ Windows မွာေတာ့) ကို Executable permission ေပးထားတာေတြ႕ပါလိမ့္မယ္ ။ Linux File permission ( rwx တို႕ ၊ 700 တို႕ 777 တို႕ )အေၾကာင္းသိျပီးသား လို႕ ယူစလို႕ ဒါကိုမရွင္းေတာ့ပါဘူး။ ls command ကို User တိုင္းက အသုံးျပဳႏိုင္တယ္။ ေနာက္ထပ္ User တိုင္း သုံး လို႕ရတယ့္ command ေလးတစ္ခုကိုၾကည့္ရေအာင္။ Password change တယ့္ passwd command ပါ။

ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 25836 2009-09-14 20:14 /usr/bin/passwd

သူလည္း everyone executable ေပးထားတယ္ ဒါေပမယ့္ တတိယအလုံးမွာ x မဟုတ္ပဲ s ျဖစ္ေနတယ္။ ဒါ SUID set ထားတယ္လို႕ ေဖာ္ျပတာပါ။ ls command တုန္းကလိုပဲ သူ႕မွာလည္း ေနာက္ဆုံးအလုံးက 'x' ၊ ဒါဆို others မွာ executable permission ေပးထားတာေပါ့။ ကြာတာက ၊ ေရွ႕မွာ 's' ျဖစ္ေနတယ္။ ls command တုန္းကလိုပဲ User တိုင္းကသုံးႏိုင္တယ္။ ဒါေပမဲ့ ဒီ passwd command ကို သုံးျပီး လုပ္သမွ်အလုပ္တိုင္းကိုေတာ့ root အေနနဲ႕ လုပ္သြားမွာျဖစ္ပါတယ္။ SUID ကို security consideration တစ္ခုအေနနဲ႕ သတ္မွတ္ၾကေလ့ရွိပါတယ္။ Command တိုင္း file တိုင္းကို အားတိုင္း SUID set မလုပ္ဖို႕ အျပင္းအထန္ ကန္႕ကြက္ပါတယ္။ ဘာလို႕လည္း ?

ခုနက passwd command ေလးကိုပဲ ၾကည့္ရေအာင္။ User တစ္ေယာက္ရဲ့ password ဟာ /etc/shadow ဆိုတယ့္ file ထဲမွာ hash အေနနဲ႕ ရွိပါတယ္။ တကယ္လို႕သာ ဒီ hash ေတြကို ရရင္ rainbow table ေတြဘာေတြနဲ႕ decipher လုပ္ႏိုင္ေကာင္းလုပ္ႏိုင္ပါတယ္။ Root user ရဲ့ password လည္း hash အေနနဲ႕ ရွိပါတယ္။ အဲေတာ့ ဒီ /etc/shadow file ထဲက data က အရမ္းအေရးၾကီးတယ့္ sensitive data ပါ။ ျဖစ္ႏိုင္ရင္ ဘယ္ user ကိုမွ ေပးမၾကည့္သင့္ဖူးေပါ့။ ဒီ /etc/shadow file ရဲ့ owner က default အေနနဲ႕ root ျဖစ္ျပီး permission က 700 ( Owner သာလွ်င္ rwx ရွိျပီး က်န္တယ့္လူေတြ read ေတာင္လုပ္လို႕မရတယ့္ permission) ေပးထားေလ့ရွိပါတယ္။

အဲမွာ စတာပါပဲ ၊ User တစ္ေယာက္က password change ရင္ passwd command ရဲ့ process တစ္ခုအေနနဲ႕ password အသစ္ကို hash ေျပာင္းျပီး ဒီ /etc/shadow file ထဲမွာရွိတယ့္ သူ႕ရဲ့ password hash ကို ျပင္ရပါမယ္။ ဒါမွ password အသစ္ျဖစ္မွာကိုး။ ဒါေပမယ့္ root user ကပဲ ဒီ file ကို edit လို႕ရတယ္။ ဒါဆို password change တိုင္း root ကိုလွမ္း change ခိုင္းရမွာလား ။ ဒါဆိုလည္း မဟုတ္ေသးဘူး။ ဒါေတြေၾကာင့္ password change ရာမွာသုံးတယ့္ passwd command ကို root အေနနဲ႕ SUID set ထားလိုက္ပါတယ္။ passwd command က လုပ္တယ့္ အလုပ္မွန္သမွ် ၊ /etc/shadow မွာ hash update လုပ္တာအပါအဝင္၊ အားလုံးကို ဒီ file ရဲ့ owner ျဖစ္တယ့္ root user အေနနဲ႕ လုပ္သြားလိုက္တယ္။ /etc/shadow ကို everyone editable ေပးရတာထက္ အမ်ားၾကီးေကာင္းတာေပါ့။ ဒီေလာက္ဆိုရင္ SUID ဆိုတာ ဘာလုပ္တယ္၊ ဘယ္လိုဆိုတာ သိေလာက္ပါျပီ။

အေပၚမွာ ေျပာခဲ့သလိုပဲ SUID set ရင္ အလြန္သတိထားရပါတယ္။ ဒီ executable file က ဘာေတြလုပ္သလည္းဆိုတာရယ္ သူ႕ source ရယ္ကို သိသင့္ပါတယ္။ SGID set ထားတယ့္ file တစ္ခုက တစ္ျခား user ကို write permission မေပးရပါဘူး။ Edit လုပ္ျပီး သူလိုခ်င္တယ့္ command ေတြေျပာင္းသြားရင္ ကိုယ္ပဲ ျပသနာျဖစ္ပါမယ္။ Shell script လိုဟာမ်ိဳး ၊ source file လိုဟာမ်ိဳးကို SUID မေပးသင့္ပါဘူး။ Content ကိုျမင္ေနရလို႕ Buffer Over Flow(BOF) flaw ရွိတာတို႕ဘာတို႕ ျဖစ္ႏိုင္ပါတယ္။ ျဖစ္ႏိုင္ရင္ Compiled binary ကိုပဲ SUID ေပးသင့္ပါတယ္။ ဒါေတာင္ safe လို႕ေျပာလို႕မရပါဘူး။

ခုတစ္ေလာ စာမေရးျဖစ္တာၾကာလို႕ Clonezilla ေလးနဲ႕ server တစ္ခုကို image အျဖစ္ေျပာင္းေနတာ ထိုင္ေစာင့္ရင္း ဒီ post ကိုေရးလိုက္ပါတယ္။ SGID ေတာ့ ေနာက္မွေပါ့ ။ ဘာေရးရမွန္းမသိသလို စာစီမရတာလည္းၾကာျပီ ။ :D


Regards
Divinity