ලිනක්ස් ගැන මීට කලිනුත් මම ලියලා තියනවනේ විස්තර. අද කථා කරන්න යන්නේ ටිකක් ආකර්ෂණිය මාතෘකාවක් ගැන. ඒ තමයි ලිනක්ස් වල රූට් රහස්‍ය කේතය (root password) අමතක වුනොත් කරන්නේ මොකක්ද කියන එක.
ලිනක්ස් වල රූට් කියලා කියන්නේ "god of the system" කියලා කිව්වාට වරදක් නැහැ. මොකද මෙහෙයුම් පද්ධතියේ පූර්ණ බලතල තියෙන්නේ මෙම රූට් කියන පරිශීලකයාට (user) වන නිසා. ලිනක්ස් පද්ධතිය කෙතරම් නම්‍යශීලීද කියනවා නම් රූට් පරිශීලකයාට ඕනෑම දෙයක් රිසි පරිදි වෙනස් කරන්න පුළුවන් වගේම යම් දෙයක් අවබෝධයකින් තොරව වෙනස් කළහොත් නැවත පණ ගැන්වීමකදී පද්ධතිය ක්‍රියාත්මක නොවී තියෙන්නටද පුළුවන. (මෙය මෙහෙයුම් පද්ධතියේ වරදක් නොව භාවිතා කරන්නාගේ අතපසුවීමක්/වරදක් බව ඔබ තේරුම් ගත යුතුය.)
ඉතිං දැන් මේ රූට් රහස්‍ය කේතය අමතක වුනොත් මොකද වෙන්නේ? පද්ධතියේ පාලනය අවශ්‍ය පරිදි කළ නොහැකි වෙනවා. එනිසා මෙම රහස්‍ය කේතය වෙනස් කරන්නට ක්‍රමයක් තියනවා නම් කොතරම් හොඳ දැයි ඔබට සිතෙන්නට පුළුවන්. පළමුවෙන්ම කිව යුතු දෙය තමයි, නිවැරදි ලෙස ආරක්ෂණ ක්‍රියාමාර්ග (Security Measures) ගෙන තිබේ නම් මෙම ක්‍රියාව (රහස්‍ය කේතය වෙනස් කිරීම) එතරම් පහසු දෙයක් නොවන අතරම සමහර විට කළ නොහැකි දෙයක් බවට පත් වන්නටද පුළුවන. නමුත් අප සලකන්නේ ඔබගේම පුද්ගලික පරිගණකයක් නම් මා මේ හඳුන්වා දෙන්නට යන ක්‍රමය එතරම් අපහසු නොවනු ඇත.
අවශ්‍ය දෑ:
- පළමු පණ ගැන්වීමේ උපකරණය (First Boot Device) සීඩී හෝ ඩීවීඩී ධාවකය වීම හෝ එය BIOS මගින් වෙනස් කිරීමට ඔබට හැකියාව තිබීම. BIOS වැඩසටහන පරිගණකයෙන් පරිගණකයට (එහි BIOS මෘදුකාංගය අනුව) වෙනස් වන අතර සාමාන්‍යයෙන් පණ ගැන්වීමේ උපකරණය "Boot Setting" යන මෙනුව තුළ "Boot Device" හෝ "Boot Sequence" යන උප මෙනුව යටතේ පවතී.
- උබුන්ටු, ලිනක්ස් මින්ට් හෝ ඔබ කැමති ලිනක්ස් ලයිව් සීඩී (Live CD) එකක්. (විස්තර කිරීම සඳහා ලිනක්ස් මින්ට් භාවිතා වේ.
ක්‍රමය:
- පළමු පණ ගැන්වීමේ උපකරණය සීඩී හෝ ඩීවීඩී ධාවකය නම් ඔබගේ ලයිව් සීඩී එක යොදා පරිගණකය එමගින් පණ ගන්වන්න.
- දැන් ලිනක්ස් ඩෙස්ක්ටොප් එකට ආ පසු (After loading everything) රූපයේ පරිදි ඩෙස්ක්ටොප් එක මත රයිට් ක්ලික් කර එන මෙනුවේ "Open in Terminal" තොරන්න. ලැබෙන Terminal එකෙහි පහත රූප වලින් දැක්වෙන අයුරු පිළිවෙලින් විධානයන් ලබා දෙන්න. විධාන සියල්ල ලබා දිය යුත්තේ පෙරළි කොමා විරහිතවය.
- "sudo fdisk -l" මෙමගින් ඔබගේ දෘඩ තැටියේ ලිනක්ස් ස්ථාපනය කර ඇති බෙදුම (Partition) හඳුනා ගත හැක. රූපයේ නම් එය /dev/sda2 වේ.
- දැන් නව ගොනුවක් තනා ගැනීම සඳහා මෙම විධානය ලබා දෙන්න. "sudo mkdir /media/temp". එවිට /media යන ස්ථානයේ temp නමින් ගොනුවක් සෑදේ.
- දැන් කළ යුත්තේ අදාළ බෙදුම temp යන ස්ථානයට ආරූඪ (mounting) කිරීමයි. ඒ සඳහා මෙම විධානය යොදා ගන්න. "sudo mount /dev/sda2 /media/temp"
- ඉන් පසු කළ යුත්තේ මෙම ලිනක්ස් සහිත බෙදුම "root partition" එක හැටියට මෙහෙයුම් පද්ධතියට හඳුන්වා දීමයි. රූපය බලන්න. විධානය, "sudo chroot /media/temp"
- දැන් අවසන් අදියර, කරන්න තියෙන්නේ රහස්‍ය කේතය වෙනස් කිරීම. රූපයේ පරිදි "passwd root" විධානය ලබා දෙන්න. දැන් ඔබට අවශ්‍ය රහස්‍ය කේතය ඇතුල් කළ පසු නැවතත් එයම ඉදිරිපත් කරන්න. අවසානයේ, "passwd: Password updated successfully" යනුවෙන් ලැබෙනු ඇත.
දැන් ඉතිං කරන්න තියෙන්නේ පරිගණකය නැවත පණ ගන්වන එක. රූට් රහස්‍ය කේතය භාවිතා කරලා ලොග් වෙන්න. මේක රූට් රහස්‍ය කේතය විතරක් නෙවෙයි, ඕනෑම පරිශීලකයෙකුගේ රහස්‍ය කේතයක් වෙනස් කරන්න පුළුවන් ක්‍රමයක්. උදාහරණයක් විදියට, guest_user කියන පරිශීලකයාගේ රහස්‍ය කේතය වෙනස් කරන්න නම් 7 වන අදියරේදි "passwd guest_user" කියන විධානයයි භාවිතා කළ යුත්තේ.
15 comments:
දැන් කියමු බලන්න මේකෙන් ආරක්ෂා කරන විදිහ ??
BIOS password දාලා චැසි එකට ඉබ්බෙක් දාන එකද ?
There is no such thing called 100% security.
ඔව් ඇත්තෙන්ම ඒක තමයි කරන්න ඕනේ. ඒක නිසා තමයි ලොකු ලොකු සේවා සපයන (Servers - Mail Sservers, FTP servers, etc) පරිගණක තියන සමාගමක එම ප්‍රදේශයට යන්න පුළුවන් අවසර ඇති අයට පමණයි. ඒක තමයි Computer Security එහෙමත් නැත්තම් පරිගණක සුරකෂණයේ ප්‍රධානම අංගය. මොකද පරිගණකයකට භෞතික වශයෙන් ළඟාවීමේ හැකියාව තියනවා නම් ඉහත සඳහන් කළා වගේ බොහෝ දේවල් කළ හැකියි.
http://www.windowsecurity.com/articles/Windows-2000-2003-Server-Physical-Security-Part1.html
ටිකක් වෙලා අරගෙන මේක කියෙව්වොත් ඒක හොඳට තේරුම් ගතහැකි වේවි.
ශාකුන්තලගේ කථාව හරියට හරි...
@ ශාකුන්තල
"මෙම ක්‍රියාව (රහස්‍ය කේතය වෙනස් කිරීම) එතරම් පහසු දෙයක් නොවන අතරම සමහර විට කළ නොහැකි දෙයක් බවට පත් වන්නටද පුළුවන. "
කියලා තිබ්බ නිසයි ඇහුවෙ සමහර විට කළ නොහැකි දෙයක් කර ගන්න ක්‍රමේ.
There is one 100% secure system, Read about OTP
@Chanaka: කාට හෝ ඔබේ පරිගණකය වෙන OS එකකින් boot කර කර ඉන්න ඉඩත්, වෙලාවත් තිබේනම් software security ගැනට වඩා සිතන්නට දේ ඔබට ඇත. :)
@Kasun: හදිසියකදී සෑහෙන්න වැදගත් වන උපදෙසක්. හොඳ ලිපිය. :)
පොඩි මතක් කිරීම් 2ක් කරන්න ඕන හැබැයි. මේ ක්‍රමය වැඩ කරන්නේ සාමාන්‍ය password file මත පදනම් වූ login පද්ධතියට පමණයි. Linux Desktop පරිගණක හැම එකකම පාහේ භාවිතා කරන්නේ මේ ක්‍රමය නිසා ප්‍රශ්නයක් නෑ.:)
අනිත් කාරණය තමයි, password rest කිරීමට යන පද්ධතියත්, reset කිරීමට යොදා ගන්නා පද්ධතියත් භාවිතා කරන crypt_style ගැලපිය යුතු බව (අඩු තරමේ compatible). මේකත් දැනටනම් ප්‍රශ්නයක් වෙන්න තියන ඉඩ අඩුයි. සාමාන්‍යයෙන් බොහොමයක් distro වල password hashing සඳහා MD5 හා SHA-1 (SHA-256) algorithms භාවිතා වුනත්, Fedora ව්‍යාපෘතිය 11 වන සංස්කරණයේ සිට SHA-512 මාරුවෙමින් පවතින නිසා අනාගතයේදී මේ ගැනත් අවධානයෙන් හිටියොත් හොඳයි.
@Chanaka: මාත් ශාකුන්තල එක්ක එකඟයි. 100% ආරක්‍ෂිත පද්ධති නැහැ, ඇත්තේ සාපේක්‍ෂව ආරක්‍ෂිත පද්ධතො පමණයි. OTP යනුවෙන් ඔබ අදහස් කරන්නේ One-time passwordනම්, එයටත් මේ කාරණය පොදුයි.
@Gaveen
"අනිත් කාරණය තමයි, password rest කිරීමට යන පද්ධතියත්, reset කිරීමට යොදා ගන්නා පද්ධතියත් භාවිතා කරන crypt_style ගැලපිය යුතු බව"
crypt_style Compatibility will not be a trouble for this. Since it is working in chrooted envirronment binaries using are from host OS & not the Guest OS.
But when chrooting for troubleshooting it is more safe to mount & bind proc & dev too
# mount -t proc none /media/temp/proc
# mount -o bind /dev /media/temp/dev
@Gaveen
OTP = One time Pad
It is 100% secure only for encryption algorithm. There is no way of breaking OTP encryption except luck. But 100% security in encryption algorithm does not mean 100% security of whole system. There are other attack @ rest of the system (ex: data transmission etc) & alos it is possible side channel attack for implementation of OTP.
Only 100% secure is theoritical algorithm & not the real world system.
I Just mentioned OTP here because shakunthala is learning Cryptography. All the Stream ciphers are trying to pseudo imitate the OTP
මේ ක්‍රමය ලේසියි නේද?
http://tharaka-lankanet.blogspot.com/2009/03/root-password.html
@Chanaka:
"crypt_style Compatibility will not be a trouble for this. Since it is working in chrooted envirronment binaries using are from host OS & not the Guest OS."
That's exactly the problem. :) If the algos don\t match, hashes generated from the host OS won't do any good to the user. That's because when she's trying to log in with the new password the hash is evaluated under that system not the rescue environment.
About the OTP, you can check the Wikipedia article.
"The theoretical perfect security of the one-time-pad applies only in a theoretically perfect setting; no real-world implementation of any cryptosystem can provide perfect security because practical considerations introduce potential vulnerabilities."
As I said, no system involving interaction with an intelligent being can be absolutely secure. However it can be effectively secure enough.
@ Gaveen
මේ විදිහට CD එකකින් Boot කරලා chroot කරාම PATHs chrooted directory එකට සාපේක්ෂ වෙනවා. එතන ඉඳන් execute කරන commands වලදි පාවිච්චි වෙන්නෙ CD එකේ තියෙන Binaries නෙවෙයි , Hard එකේ තියෙන පරණ OS එකේ files . මෙතනදි execute වෙන 'passwd' වලට අදාල files ගන්නෙ CD එකෙන් නෙවෙයි Hard එකෙන්. ඒක ඒ System එකට සාමාන්‍ය විදිහටම root විදිහට log වෙලා 'passwd' command එක පාවිච්චි කලාට සමානයි.
ෂුවර් නැත්තන් මේක කරලා බලන්න. CD එකකින් boot කරලා මේ විදිහට chroot කරලා ඒ CD එකේ නැති ඒත් System එකට install කරල තියෙන program එකක් run කරලා බලන්න.
මම දන්න විදිහටනම් ඔහොමයි. මම වැරදිද?
There Are Several ways you can try to recover lost root password (Boot in to single user mode, Boot in to root shell, Boot from a CD & chrooting, Accessing from another OS if another OS installed etc ...)
In some methods it is possible to change the password at 1st place & in some methods it will first make root passowrd empty (by editing /etc/passwd & shadow) & then login with empty password & create new password.
How ever the common thing for all these methods is , you have to get write access to the root partition of the host.
It is possible to encrypt the root file system & then none of the above methods will work. In such situation if the root password is lost
1. If you still can log on to system using normal user & if system had some security vulnarability (if you are lucky) then you may write a exploit to get root access.
2. If no 1 above is not worked then only alternative is performing bruteforce
The 2nd thing happened to me once. We had a server wich run well for long period of time without doing any modification. After while we wanted to do some modification, But nobody knew the root password. I was not the admin at the time that server deployed & the previous admin had left & was not responding to any mail. The password he had told @ the time when he left did not work.
Fortunately since system was not upgraded we could find a exploit.
So It is not recommended to encrypt root file system of your personal machine. :)
@Chanaka:
"මම දන්න විදිහටනම් ඔහොමයි. මම වැරදිද?"
නෑ ඒ කතාව හරි. ඒක තමයි මම මුලින්ම කීවේ crypt_style compatible වෙන්න ඕන කියලා. මොකද chrooted පරිසරයක configuration වලින් මොකක් භාවිතයට ගන්න කීවත්, rescue විධියට භාවිතා කරන OS එක ඒ crypt_style එක හඳුනන්න ඕන. වර්තමානයේ algorithms හා crypt() implementations වල විවිධත්වයක් ඇතිවෙමින් පවතින නිසා තමයි මම කීවේ "අනාගතයේදී මේ ගැනත් අවධානයෙන් හිටියොත් හොඳයි" කියලා.
මමත් සෑහෙන දේවල් ඉගෙන ගත්තා මේකෙන්. ස්තුතියි හැමෝටම.
Post a Comment