OpenSSH Emergency Fix: Alpine Linux Login Bypass ର ବ୍ୟାଖ୍ୟା, ଏକ ବ୍ୟବହାରିକ ଉଦାହରଣ ସହିତ

କଳ୍ପନା କରନ୍ତୁ ଏପରି ଏକ server account ଯାହାର କୌଣସି password ନାହିଁ। ବର୍ତ୍ତମାନ କଳ୍ପନା କରନ୍ତୁ ଯେ ଜଣେ attacker ତଥାପି ଏଥିରେ log in କରିପାରିବେ, କାରଣ ଏକ password ଯାଞ୍ଚ ଏକ error message କୁ ସଠିକ୍ ଉତ୍ତର ବୋଲି ଭୁଲ୍ ଭାବରେ ଗ୍ରହଣ କରିନେଲା। ଏହି ସପ୍ତାହର OpenSSH ଜରୁରୀକାଳୀନ release ର ମୂଳ କାରଣ ହେଉଛି ଏହି bug।

ଆଜି ହେଉଛି ୬ ନଭେମ୍ବର, ୨୦୨୬, ଏବଂ ଏହା ବର୍ତ୍ତମାନ ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ କାରଣ Portable OpenSSH 10.6p2 ଗତକାଲି ହିଁ ୫ ନଭେମ୍ବରରେ ଏହି ପ୍ରକଳ୍ପରୁ ଏକ ଜରୁରୀ ଅନୁରୋଧ ସହିତ ପ୍ରକାଶ ପାଇଛି। ଯଦି ଆପଣ password authentication ଚାଲୁ ଥିବା musl-ଆଧାରିତ Linux servers ଚଳାଉଛନ୍ତି, ତେବେ ଡେଭଲପରମାନେ ଚାହାଁନ୍ତି ଯେ ଆପଣ ପଦକ୍ଷେପ ନେବା ପର୍ଯ୍ୟନ୍ତ ତୁରନ୍ତ password logins କୁ disable କରନ୍ତୁ କିମ୍ବା SSH କୁ disable କରନ୍ତୁ।

ଅନେକ ଟିମ୍ ଏହି ହେଡଲାଇନ୍ ପଢ଼ି ଭୟଭୀତ ହୋଇପାରନ୍ତି କିମ୍ବା ଅଣଦେଖା କରିପାରନ୍ତି। ଉଭୟ ହିଁ ଭୁଲ୍। ଅଧିକାଂଶ Linux servers ପ୍ରଭାବିତ ନୁହଁନ୍ତି, କିନ୍ତୁ ଯେଉଁ ସର୍ଭରଗୁଡ଼ିକ ପ୍ରଭାବିତ, ସେଥିରେ ଆପଣ ସର୍ବଦା "key-only" ବୋଲି କହୁଥିବା ସର୍ଭର ମଧ୍ୟ ଅନ୍ତର୍ଭୁକ୍ତ ହୋଇପାରେ। ଏହି ଗାଇଡ୍ ସରଳ ଭାଷାରେ bug ବିଷୟରେ ବୁଝାଏ, ଏକ ସର୍ଭରକୁ କିପରି ଯାଞ୍ଚ କରିବେ ତାହା ସଠିକ୍ ଭାବରେ ଦର୍ଶାଏ, ଏବଂ ଆବିଷ୍କାରଠାରୁ ଆରମ୍ଭ କରି ଯାଞ୍ଚ ହୋଇଥିବା ସମାଧାନ ପର୍ଯ୍ୟନ୍ତ ଏକ ସମ୍ପୂର୍ଣ୍ଣ ଉଦାହରଣ ପ୍ରଦାନ କରେ।

ସରଳ ଭାଷାରେ, ପ୍ରକୃତରେ କ’ଣ ଘଟିଲା

ସର୍ଭରଗୁଡ଼ିକରେ ରିମୋଟ୍ ଭାବରେ log in କରିବା ପାଇଁ administrator ମାନେ SSH tool ବ୍ୟବହାର କରନ୍ତି। OpenSSH ହେଉଛି ଏହାର ସର୍ବାଧିକ ବ୍ୟବହୃତ ସଂସ୍କରଣ।

ପ୍ରତ୍ୟେକ Linux program ଏକ C library ଉପରେ ନିର୍ଭର କରେ, ଯାହା ମୌଳିକ functions ର ଏକ shared collection। ଅଧିକାଂଶ Linux systems glibc ନାମକ ଏକ library ବ୍ୟବହାର କରନ୍ତି। Alpine Linux musl ନାମକ ଏକ ଛୋଟ library ବ୍ୟବହାର କରେ, ଯାହା containers ଏବଂ ଛୋଟ cloud servers ପାଇଁ Alpine ଏତେ ଲୋକପ୍ରିୟ ହେବାର ଏକ ବଡ଼ କାରଣ।

ଏହି bug ସେହି ଦୁଇଟି ସଫ୍ଟୱେର୍ ମଧ୍ୟବର୍ତ୍ତୀ ସଂଯୋଗ ସ୍ଥଳରେ ରହିଛି। OpenSSH ର developers ମାନେ ମନେ କରନ୍ତି ଯେ ମୂଳ କାରଣ OpenSSH ବାହାରେ ଅଛି, କିନ୍ତୁ ସେମାନେ ଏହା ମଧ୍ୟ ସ୍ୱୀକାର କରନ୍ତି ଯେ SSH server ଏହାକୁ exploit କରିବାର ମାଧ୍ୟମ ଏବଂ ଏହାକୁ block କରିବା ପାଇଁ ଏକ ବ୍ୟବହାରିକ ସ୍ଥାନ ପ୍ରଦାନ କରେ। ତେଣୁ 10.6p2 ଏକ workaround ଯୋଡ଼ିଥାଏ। ଏହି ତ୍ରୁଟି Wakefield ର Özgün Kültekin ଙ୍କ ଦ୍ୱାରା ଖୋଜା ଯାଇଥିଲା।

କିପରି ଏକ error ଏକ ସଫଳ login ରେ ପରିଣତ ହୁଏ

କୌଣସି exploit ବିବରଣୀ ବିନା, ଏଠାରେ ପାହାଚ ପରେ ପାହାଚ logic ଦିଆଯାଇଛି।

ଯେତେବେଳେ ଏକ server ବିନା PAM (Pluggable Authentication Modules, logins ପରିଚାଳନା କରିବା ପାଇଁ ଏକ ସାଧାରଣ ସିଷ୍ଟମ୍) ରେ password ଯାଞ୍ଚ କରେ, ଏହା ଏକ ସରଳ କାମ କରେ। ଏହା visitor ଟାଇପ୍ କରିଥିବା password କୁ hash କରେ, ତା'ପରେ ସେହି account ପାଇଁ store ହୋଇଥିବା value ସହିତ ଫଳାଫଳକୁ ତୁଳନା କରେ।

ଏକ hash ପାଇଁ ଏକ salt ଆବଶ୍ୟକ ହୁଏ, ଯାହା ମିଶ୍ରିତ ହୋଇଥିବା ଏକ ଛୋଟ random value ଯାହାଫଳରେ ଏକାଭଳି passwords ଭିନ୍ନ ଭିନ୍ନ ଫଳାଫଳ ଦିଅନ୍ତି। ଯଦି ଏକ account ପାଇଁ store ହୋଇଥିବା value ଏକ salt ଯୋଗାଇବା ପାଇଁ ବହୁତ ଛୋଟ ହୋଇଥାଏ, OpenSSH ସେହି ମେସିନର ଅନ୍ୟ ଏକ account ରୁ ଗୋଟିଏ ଉଧାର ନେଇପାରେ। ଏହା ଏକ ଉଚିତ କାରଣ ପାଇଁ ଏପରି କରେ: 2016 ମସିହାରୁ ଏହା ଆକ୍ରମଣକାରୀମାନଙ୍କୁ କେଉଁ usernames ଅସ୍ତିତ୍ୱରେ ଅଛି ତାହା ଅନୁମାନ କରିବାରୁ ରୋକିବାକୁ ଚେଷ୍ଟା କରିଆସୁଛି, ଯାହା CVE-2016-6210 ତ୍ରୁଟିର ଏକ ପ୍ରତିକ୍ରିୟା ଥିଲା।

ବର୍ତ୍ତମାନ ସଂଘର୍ଷ। ଯେତେବେଳେ musl ର crypt() function କୁ କିଛି ନିର୍ଦ୍ଦିଷ୍ଟ hash types ପାଇଁ ଅତ୍ୟଧିକ ଲମ୍ବା ଥିବା ଏକ password ଦିଆଯାଏ, ଏହା ପ୍ରତ୍ୟାଖ୍ୟାନ କରେ ଏବଂ ଏକକ character * ଫେରାଇ ଏକ error ସୂଚିତ କରେ।

କିନ୍ତୁ * ମଧ୍ୟ ଅନେକ systems ଏପରି ଏକ account ର password field ରେ store କରନ୍ତି ଯାହାର କୌଣସି password ରହିବା ଉଦ୍ଦିଷ୍ଟ ନୁହେଁ।

ତେଣୁ server ଦୁଇଟି value ତୁଳନା କରେ:

• ଏହା ଯାହା calculate କଲା: *, ଯାହାର ପ୍ରକୃତ ଅର୍ଥ ହେଉଛି "error"।
• ଏହା ଯାହା store କରି ରଖିଛି: *, ଯାହାର ପ୍ରକୃତ ଅର୍ଥ ହେଉଛି "no usable password"।

ସେଗୁଡ଼ିକ match ହୋଇଯାଏ। login ସଫଳ ହୁଏ।

ଏକ ତାଲିକା ସହିତ ନାମ ଯାଞ୍ଚ କରୁଥିବା ଜଣେ ବାଉନ୍ସର (bouncer) କଥା ଭାବନ୍ତୁ। ସ୍କାନର ଖରାପ ହୋଇଯାଏ ଏବଂ "ERROR" ପ୍ରିଣ୍ଟ କରେ। କର୍ମଚାରୀଙ୍କ ପାଇଁ ଏକ ନୋଟ୍ ଭାବରେ ଯୋଡ଼ା ଯାଇଥିବା ତାଲିକାର ଏକ ଏଣ୍ଟ୍ରିରେ ମଧ୍ୟ "ERROR" ଲେଖାଥାଏ। ବାଉନ୍ସର ଦୁଇଟି ସମାନ ଶବ୍ଦ ଦେଖି ସେହି ବ୍ୟକ୍ତିଙ୍କୁ ଭିତରକୁ ଛାଡ଼ିଦିଅନ୍ତି। କେହି ମିଛ କହି ନଥିଲେ, ଏବଂ ପ୍ରତ୍ୟେକ ଅଂଶ ନିଜ କାମ କରିଥିଲେ। ଗୋଟିଏ value ର ଦୁଇଟି ଭିନ୍ନ ଅର୍ଥ ଥିବାରୁ ଏହି ବିପଦ ସୃଷ୍ଟି ହୋଇଥିଲା।

ଗବେଷକ ଏହି interaction କୁ 2012 ମସିହାର musl ପରିବର୍ତ୍ତନ ଏବଂ 2016 ର OpenSSH ପରିବର୍ତ୍ତନ ସହିତ ଯୋଡ଼ି ଦେଖାଇଛନ୍ତି। ସେ AI agents ର ସହାୟତାରେ, build ଏବଂ login combinations ମଧ୍ୟରେ ପ୍ରାୟ 17,600 test logins ମାଧ୍ୟମରେ ଏହାକୁ ଖୋଜି ପାଇଥିବା ରିପୋର୍ଟ କରିଛନ୍ତି।

ଆପଣ ପ୍ରଭାବିତ କି? ଚାରୋଟି ସର୍ତ୍ତ

Alpine advisory ଚାରୋଟି ସର୍ତ୍ତ ଉଲ୍ଲେଖ କରେ, ଏବଂ ସେଗୁଡ଼ିକ ସମସ୍ତ ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ:

1. OpenSSH ବିନା PAM ରେ passwords ଯାଞ୍ଚ କରେ।
2. PasswordAuthentication enable ଅଛି।
3. Target account ର password field ରେ ରହିଥାଏ *.
4. ଅନ୍ୟ ଏକ local account ର password hash ଆରମ୍ଭ ହୋଇଥାଏ $5$ କିମ୍ବା $6$.

Alpine ର standard openssh-server package PAM ବ୍ୟବହାର କରେ ନାହିଁ। ଏପରିକି openssh-server-pam install କରିବା ମଧ୍ୟ ଏହାର ସମାଧାନ କରେ ନାହିଁ, କାରଣ ଆପଣ ତଥାପି exposed ରହିବେ ଯଦି UsePAM no set ହୋଇଥାଏ।

ଏଗୁଡ଼ିକ ଉଲ୍ଲିଖିତ ପରିସର ବାହାରେ ଅଛି:

• Non-Linux platforms।
• glibc ବ୍ୟବହାର କରୁଥିବା Linux systems।
• PAM ମାଧ୍ୟମରେ passwords ଯାଞ୍ଚ କରୁଥିବା Linux systems।
• କୌଣସି SSH server ଚାଲୁ ନଥିବା Containers।
• Password authentication disabled ଥିବା Systems।
• Accounts ଯାହା ! ସହିତ lock ହୋଇଛି, ନା କି *.

ସେହି ଶେଷ ଗ୍ରୁପ୍ ହେଉଛି କାରଣ ଯେଉଁଥିପାଇଁ "ଆମେ Alpine ବ୍ୟବହାର କରୁଛୁ" ର ଅର୍ଥ "ଆମେ vulnerable (ଅସୁରକ୍ଷିତ)" ସହିତ ସମାନ ନୁହେଁ। ଅଧିକାଂଶ Alpine containers ରେ କୌଣସି SSH server ଆଦୌ ଚାଲେ ନାହିଁ। ସେହିପରି, "OpenSSH is installed" ଆପଣଙ୍କୁ ବହୁତ କମ୍ ସୂଚନା ଦିଏ। ଆପଣଙ୍କୁ C library, package, running configuration ଏବଂ account data ଜାଣିବାକୁ ପଡ଼ିବ।

ବିପଜ୍ଜନକ ପରିସ୍ଥିତି: official cloud images

Alpine ବିଶେଷ ଭାବରେ ଏକ scenario ବିଷୟରେ ଉଲ୍ଲେଖ କରେ। ଏହାର official tiny-cloud images, version 3.18.11 ରୁ 3.24.3 ପର୍ଯ୍ୟନ୍ତ, ଏକ alpine account ଅନ୍ତର୍ଭୁକ୍ତ କରେ ଯାହାର ଥାଏ ଏକ * password field ଏବଂ passwordless doas rights। doas ହେଉଛି ଏକ ଛୋଟ tool, ଯାହା sudoସହିତ ସମାନ, ଯାହା ଜଣେ user ଙ୍କୁ root ଭାବରେ commands run କରିବାକୁ ଦିଏ।

ସେହି images ପ୍ରାରମ୍ଭରେ ସୁରକ୍ଷିତ ଥାଏ, କାରଣ ଚତୁର୍ଥ ସର୍ତ୍ତ ଅନୁପସ୍ଥିତ ଥାଏ। ମେସିନରେ କୌଣସି qualifying password hash ନଥାଏ।

ତା'ପରେ କେହି ଜଣେ ସାଧାରଣ password ସହିତ ଜଣେ user ଯୋଡ଼ିଦିଅନ୍ତି, ବୋଧହୁଏ console access ପାଇଁ। ସେହି ଗୋଟିଏ ନିୟମିତ ପରିବର୍ତ୍ତନ ସମସ୍ତ ସର୍ତ୍ତ ପୂରଣ କରିପାରେ। ଜଣେ attacker ପ୍ରବେଶ କରିପାରିବେ alpine ଭାବରେ ଏବଂ root ହୋଇପାରିବେ।

ଡିଫଲ୍ଟ PermitRootLogin prohibit-password setting ଏଠାରେ ସାହାଯ୍ୟ କରେ ନାହିଁ। ଏହା root ପାଇଁ direct password logins କୁ ବନ୍ଦ କରେ, କିନ୍ତୁ ଏହି ଉପାୟ ପରୋକ୍ଷ ଭାବରେ root ପାଖରେ ପହଞ୍ଚିଯାଏ।

ଏକ ବ୍ୟବହାରିକ ଉଦାହରଣ: Acme ର jump host

ଆସନ୍ତୁ ଏକ କାଳ୍ପନିକ କମ୍ପାନୀ ବିଷୟରେ ଦେଖିବା। Acme ଏକ ଛୋଟ Alpine server ଚଳାଏ, bastion.example.com, ଯାହା ମାଧ୍ୟମରେ କର୍ମଚାରୀମାନେ internal systems କୁ reach କରିବା ପାଇଁ connect କରନ୍ତି। ସମସ୍ତେ କହନ୍ତି ଏହା key-only। ଜଣେ ନୂତନ engineer, Rohit, ଙ୍କୁ ଏହା ପ୍ରମାଣ କରିବାକୁ କୁହାଯାଇଛି।

Step 1: Platform ନିଶ୍ଚିତ କରନ୍ତୁ

Rohit log in କରନ୍ତି ଏବଂ system ଯାଞ୍ଚ କରନ୍ତି:

cat /etc/alpine-release
ldd --version
apk info -e openssh-server openssh-server-pam

ପ୍ରଥମ command Alpine version ଦେଖାଏ। ଦ୍ୱିତୀୟଟି musl ନାମ ଦର୍ଶାଏ। ତୃତୀୟଟି ଦୁଇଟି packages ମଧ୍ୟରୁ କେଉଁଟି install ହୋଇଛି ତାହା ତାଲିକାଭୁକ୍ତ କରେ। Acme ର ସର୍ଭରରେ, କେବଳ openssh-server ଦେଖାଯାଏ, ତେଣୁ ସେଠାରେ କୌଣସି PAM ନାହିଁ।

ଯଦି ldd --version ଏହା ବଦଳରେ glibc ନାମ ଦର୍ଶାଏ, କିମ୍ବା ମେସିନରେ କୌଣସି SSH server ଚାଲୁ ନାହିଁ, ସେମାନେ ଅଟକି ଯାଇ ପରବର୍ତ୍ତୀ system କୁ ଯାଇପାରିବେ।

Step 2: sshd ପ୍ରକୃତରେ କ’ଣ enforce କରୁଛି ତାହା ପଢ଼ନ୍ତୁ

ଏହି ପଦକ୍ଷେପକୁ ଟିମ୍‌ଗୁଡ଼ିକ ଛାଡ଼ିଦିଅନ୍ତି। କେବଳ config file ପଢ଼ି ଅନୁମାନ କରନ୍ତୁ ନାହିଁ। ସର୍ଭରକୁ ଏହାର effective settings ବିଷୟରେ ପଚାରନ୍ତୁ:

sshd -T | grep -iE '^(passwordauthentication|usepam|permitrootlogin|authenticationmethods)'

Rohit ଏହା ଦେଖନ୍ତି:

permitrootlogin prohibit-password
passwordauthentication yes
authenticationmethods any

ଏଠାରେ ହିଁ ଆଶ୍ଚର୍ଯ୍ୟଜନକ କଥା। Password logins ଚାଲୁ ଅଛି। କର୍ମଚାରୀମାନେ ସର୍ବଦା keys ବ୍ୟବହାର କରୁଥିଲେ, ତେଣୁ କେହି ଲକ୍ଷ୍ୟ କରିନଥିଲେ। PAM ବିନା ଥିବା ଏକ build ହୁଏତ usepam ଆଦୌ print କରିନପାରେ, ଯେଉଁ କାରଣରୁ ଏହି output ରେ ସେପରି କୌଣସି line ନାହିଁ।

Settings ମଧ୍ୟ ପ୍ରତ୍ୟେକ connection ଅନୁସାରେ ପରିବର୍ତ୍ତନ ହୋଇପାରେ Match rules ମାଧ୍ୟମରେ, ତେଣୁ ସେମାନେ ଏକ ନିର୍ଦ୍ଦିଷ୍ଟ user ଏବଂ address ପାଇଁ view ପରୀକ୍ଷା କରନ୍ତି:

sshd -T -C user=deploy,host=bastion.example.com,addr=203.0.113.10 | grep -i '^passwordauthentication'

Step 3: Account data ଯାଞ୍ଚ କରନ୍ତୁ

Root ଭାବରେ run କଲେ, ଏହି ଦୁଇଟି commands କେବଳ account names ପ୍ରିଣ୍ଟ କରନ୍ତି, କଦାପି hashes ନୁହେଁ:

awk -F: '$2 == "*" {print "star: " $1}' /etc/shadow
awk -F: '$2 ~ /^\$[56]\$/ {print "hash: " $1}' /etc/shadow

Rohit ଙ୍କ ଫଳାଫଳ:

star: deploy
hash: backup-admin

ତେଣୁ deploy, "key-only" account ର ଅଛି ଏକ * field। ଏବଂ backup-admin, ଯାହା console access ପାଇଁ ଗତ ବର୍ଷ create କରାଯାଇଥିଲା, ତାହାର ଏକ qualifying hash ଅଛି। ସମସ୍ତ ଚାରୋଟି ସର୍ତ୍ତ ପୂରଣ ହୋଇଛି। ଏହି server exposed ଅଛି।

Step 4: ପ୍ରଥମେ ଦ୍ୱାର ବନ୍ଦ କରନ୍ତୁ, ତା'ପରେ patch କରନ୍ତୁ

Rohit ସେମାନଙ୍କର ବର୍ତ୍ତମାନର session କୁ open ରଖନ୍ତି ଏବଂ ଏକ ଦ୍ୱିତୀୟ ଟର୍ମିନାଲରୁ ସେମାନଙ୍କର key କାମ କରୁଛି ବୋଲି ନିଶ୍ଚିତ କରନ୍ତି। ଏଠାରେ ଗୋଟିଏ ଭୁଲ୍ ସମସ୍ତଙ୍କୁ lock out କରିପାରେ, ଏବଂ open session ହେଉଛି ସେମାନଙ୍କର safety rope।

ସେମାନେ ଏହି setting କୁ ଯୋଡ଼ନ୍ତି /etc/ssh/sshd_config:

PasswordAuthentication no

ଏକ ଫାନ୍ଦ: ଅଧିକାଂଶ settings ପାଇଁ OpenSSH ପ୍ରଥମେ ପଢ଼ିଥିବା value କୁ ବ୍ୟବହାର କରେ। ଯଦି ଫାଇଲର ଉପର ଭାଗରେ ଏକ Include line ଥାଏ, କିମ୍ବା ତଳ ଭାଗରେ ଏକ Match block ଥାଏ, ତେବେ ନୂତନ line ହୁଏତ ପ୍ରଭାବଶାଳୀ ନହୋଇପାରେ। ସେଥିପାଇଁ edit କରିବା ପରେ ତୁରନ୍ତ check କରାଯାଏ:

sshd -t
sshd -T | grep -i '^passwordauthentication'

sshd -t errors ପାଇଁ configuration ପରୀକ୍ଷା କରେ। ଯଦି ଏହା pass ହୁଏ, ସେମାନେ ପ୍ରକାଶିତ Alpine fix ପ୍ରୟୋଗ କରନ୍ତି। Alpine 3.21.10, 3.22.8, 3.23.8 ଏବଂ 3.24.4 ରିଲିଜ୍ କରିଛି, ଏବଂ OpenRC systems ରେ remediation ହେଉଛି:

apk upgrade -U -a
rc-service sshd restart

Restart କରିବା ଐଚ୍ଛିକ (optional) ନୁହେଁ। ଏକ package install କରିବା ଦ୍ୱାରା memory ରେ ପୂର୍ବରୁ ଚାଲୁଥିବା SSH server ବଦଳିଯାଏ ନାହିଁ।

Step 5: ବାହାରୁ ଏହାକୁ ପ୍ରମାଣ କରନ୍ତୁ

ବର୍ତ୍ତମାନ Rohit ଜଣେ ବାହାର ବ୍ୟକ୍ତି ଭଳି ଅନ୍ୟ ଏକ ମେସିନରୁ ନିଜ ସର୍ଭର ବିରୁଦ୍ଧରେ ପରୀକ୍ଷା କରନ୍ତି:

ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password [email protected]

ସେମାନେ ଚାହୁଁଥିବା ଉତ୍ତର ହେଉଛି ଏକ ପ୍ରତ୍ୟାଖ୍ୟାନ ଯେପରିକି Permission denied (publickey)। ଏହାର ଅର୍ଥ ହେଉଛି server ଆଉ ଆଦୌ passwords offer କରୁନାହିଁ। କର୍ମଚାରୀମାନେ ତଥାପି ଭିତରକୁ ଯାଇପାରୁଛନ୍ତି କି ନାହିଁ ତାହା ନିଶ୍ଚିତ କରିବା ପାଇଁ ସେମାନେ ଏକ ନୂତନ ଟର୍ମିନାଲରେ ଏକ ସାଧାରଣ key-based session ଖୋଲନ୍ତି।

Step 6: ଅତୀତର ଅପବ୍ୟବହାର ଖୋଜନ୍ତୁ

Patching ଦ୍ୱାର ବନ୍ଦ କରିଦିଏ, କିନ୍ତୁ ଏହା କିଏ ପୂର୍ବରୁ ଏହା ଦେଇ ପ୍ରବେଶ କରିସାରିଛି ସେ ବିଷୟରେ କିଛି କହେ ନାହିଁ। Alpine ଏହି ନିର୍ଦ୍ଦିଷ୍ଟ entry ପାଇଁ logs ସମୀକ୍ଷା କରିବାକୁ ସୁପାରିଶ କରେ:

grep 'Accepted password for' /var/log/messages

ଯେଉଁ ସର୍ଭରରେ କର୍ମଚାରୀମାନେ କେବଳ keys ବ୍ୟବହାର କରନ୍ତି, ସେଠାରେ ଏକ ସଫଳ password login ହେଉଛି ଧ୍ୟାନ ଦେବା ଯୋଗ୍ୟ ସଙ୍କେତ। ବାରମ୍ବାର failure ଉପରେ ନଜର ରଖୁଥିବା Monitoring ଏହାକୁ ସମ୍ପୂର୍ଣ୍ଣ ରୂପେ miss କରିପାରେ, କାରଣ ଏଠାରେ attacker ର ପ୍ରୟାସ ଏକ ସଫଳତା ପରି ଦେଖାଯାଏ।

Rohit କୌଣସିଟି ପାଆନ୍ତି ନାହିଁ। ଯଦି ସେମାନେ ଏପରି କିଛି ପାଇଥାନ୍ତେ deployପାଇଁ, ତେବେ କାମଟି patching ରୁ incident response ରେ ପରିଣତ ହୋଇଥାନ୍ତା। Alpine privilege escalation, ନୂତନ users, ନୂତନ files ଏବଂ ପରିବର୍ତ୍ତିତ authorised keys ଯାଞ୍ଚ କରିବାକୁ ପରାମର୍ଶ ଦିଏ, ଏବଂ ଯଦି unauthorised login କୁ ଏଡ଼ାଇ ଦିଆଯାଇ ନପାରେ ତେବେ host କୁ compromised ବୋଲି ଧରିନେବାକୁ କହେ। Stored credentials ଏବଂ deployment secrets ସମେତ ସେହି account ପହଞ୍ଚିପାରୁଥିବା ଯେକୌଣସି ଜିନିଷର ସମୀକ୍ଷା ଏବଂ replacement ଆବଶ୍ୟକ ହେବ।

ଯେକୌଣସି ସନ୍ଦେହଜନକ login ସମୟରେ account କିପରି ଥିଲା ତାହା ମଧ୍ୟ ଯାଞ୍ଚ କରନ୍ତୁ। ଏହାର ବର୍ତ୍ତମାନର ସ୍ଥିତି ଏକ ପରବର୍ତ୍ତୀ ପରିବର୍ତ୍ତନକୁ ପ୍ରତିଫଳିତ କରିପାରେ।

Step 7: କେବଳ product ନୁହେଁ, factory କୁ ମଧ୍ୟ ଠିକ୍ କରନ୍ତୁ

Acme ଏକ saved image ରୁ servers ନିର୍ମାଣ କରେ। ଯଦି Rohit Step 6 ରେ ଅଟକି ଯାଇଥାନ୍ତେ, ପରବର୍ତ୍ତୀ rebuild କିମ୍ବା autoscaling event ପୁରୁଣା settings କୁ ସିଧାସଳଖ ଫେରାଇ ଆଣିଥାନ୍ତା। ସେମାନେ template କୁ update କରନ୍ତି, ସେଠାରେ set କରନ୍ତି PasswordAuthentication no , ଏବଂ ପଚାରନ୍ତି ଯେ କାହିଁକି backup-admin ର ଆଦୌ ଏକ password ଆବଶ୍ୟକ।

Scanner ଫଳାଫଳ କିପରି ପଢ଼ିବେ

ଏହି ସପ୍ତାହରେ noisy reports ଆସିବାର ଆଶା କରନ୍ତୁ। ଦୁଇଟି ଧାରଣାକୁ ପୃଥକ୍ ରଖନ୍ତୁ।

Upstream version string ଏବଂ ଏକ distribution ର patch status ହେଉଛି ଭିନ୍ନ ପ୍ରମାଣ। ଜଣେ vendor headline version ପରିବର୍ତ୍ତନ ନକରି ମଧ୍ୟ ଏକ fix କୁ backport କରିପାରନ୍ତି, ତେଣୁ ଆପଣଙ୍କ distribution ର package guidance ଅନୁସରଣ କରନ୍ତୁ। ଯଦି ଆପଣ ନିଜେ OpenSSH compile କରନ୍ତି, ତେବେ 10.6p2 release notes ବ୍ୟବହାର କରନ୍ତୁ।

ପ୍ରତ୍ୟେକ server ପାଇଁ ଚାରୋଟି ପୃଥକ୍ ତଥ୍ୟ ଟ୍ରାକ୍ କରନ୍ତୁ: vulnerable package ଚିହ୍ନଟ, replacement install, service restart, configuration ଯାଞ୍ଚ। ଏକ ticket ରେ "Patched" ର ଅର୍ଥ ପ୍ରାୟତଃ କେବଳ ଦ୍ୱିତୀୟଟିକୁ ବୁଝାଏ।

ଏହି ସମାଧାନ ଏତେ ଶୀଘ୍ର କାହିଁକି ଆସିଲା

Damien Miller କହିଛନ୍ତି ଯେ OpenSSH ଟିମ୍ workaround release କରିବାର ଗୋଟିଏ ଦିନ ପୂର୍ବରୁ ଏହି ସମସ୍ୟା ବିଷୟରେ ଜାଣିବାକୁ ପାଇଥିଲେ। ସେ କିଛି ଘଣ୍ଟା ମଧ୍ୟରେ AI agents ସ୍ୱାଧୀନ ଭାବରେ vulnerabilities ପୁନଃ ଆବିଷ୍କାର କରୁଥିବାର ସାମ୍ପ୍ରତିକ ଘଟଣାଗୁଡ଼ିକୁ ସୂଚାଇ ଯୁକ୍ତି କରିଛନ୍ତି ଯେ ଦୀର୍ଘ embargoes ଆକ୍ରମଣକାରୀମାନଙ୍କୁ ସୁବିଧା ଦେଇପାରେ।

Release notes ରେ scheduled releases ପାଇଁ changes କୁ ଅଟକାଇ ରଖିବା ପରିବର୍ତ୍ତେ ଅଧିକ ବାରମ୍ବାର fixes ପ୍ରଦାନ କରିବା ଦିଗରେ ଏକ ପଦକ୍ଷେପ ବର୍ଣ୍ଣନା କରାଯାଇଛି, ଯେତେବେଳେ ଏହା ଉପରେ ଗୁରୁତ୍ୱ ଦିଆଯାଇଛି ଯେ ଅନେକ AI-generated reports କୌଣସି ବାସ୍ତବବାଦୀ security impact ଦେଖାନ୍ତି ନାହିଁ ଏବଂ ମାନବ ବିଶ୍ଳେଷଣ (human analysis) ଏବେ ମଧ୍ୟ ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ।

ଆମ ମଧ୍ୟରୁ ଅଧିକାଂଶଙ୍କ ପାଇଁ, ବ୍ୟବହାରିକ ଫଳାଫଳ ସରଳ। Critical fixes ବର୍ତ୍ତମାନ ଆପଣଙ୍କ ସାଧାରଣ maintenance window ବାହାରେ ମଧ୍ୟ ଆସିପାରେ। Vendor ଙ୍କ ଘୋଷଣାଗୁଡ଼ିକୁ ସିଧାସଳଖ ଅନୁସରଣ କରନ୍ତୁ, ଏବଂ ଜରୁରୀକାଳୀନ ପରିବର୍ତ୍ତନ କରିବାକୁ କାହାକୁ ଅନୁମତି ଅଛି ତାହା ପୂର୍ବରୁ ସ୍ଥିର କରନ୍ତୁ।

ଏହି ବିନ୍ଦୁଗୁଡ଼ିକ exposure ଏବଂ ଉଚିତ ପ୍ରତିକ୍ରିୟା ବର୍ଣ୍ଣନା କରନ୍ତି। ସେଗୁଡ଼ିକ ଏକ ନିଶ୍ଚିତ attack campaign ର ପ୍ରମାଣ ନୁହେଁ।

ପ୍ରକୃତ ଶିକ୍ଷା: ତିନୋଟି ବାକ୍ୟାଂଶ ଯାହା ସମାନ ନୁହେଁ

"SSH keys ବ୍ୟବହାର କରେ", "କୌଣସି password set ହୋଇନାହିଁ" ଏବଂ "password ସହିତ authenticate କରିପାରିବ ନାହିଁ" ଶୁଣିବାକୁ ଏକାଭଳି ଲାଗେ, କିନ୍ତୁ ସେଗୁଡ଼ିକ ଭିନ୍ନ ଜିନିଷ ବର୍ଣ୍ଣନା କରେ। ପ୍ରଥମଟି ଏକ ଅଭ୍ୟାସ। ଦ୍ୱିତୀୟଟି data ର ଏକ ସ୍ଥିତି। କେବଳ ତୃତୀୟଟି ହେଉଛି ଏକ enforced control, ଏବଂ ଆପଣ ଚାଲୁଥିବା server କୁ ପରୀକ୍ଷା କରି ହିଁ ଏହା ଜାଣିପାରିବେ।

ଉପସଂହାର

ଏହା ଏକ ତୀକ୍ଷ୍ଣ ଧାର ବିଶିଷ୍ଟ ସଂକୀର୍ଣ୍ଣ bug। ଅଧିକାଂଶ Linux systems ଏହାର ବାହାରେ ଅଛନ୍ତି, କିନ୍ତୁ ସମସ୍ତ ଚାରୋଟି ସର୍ତ୍ତ ପୂରଣ କରୁଥିବା ଏକ musl-ଆଧାରିତ server ଏପରି ଏକ account ପାଇଁ login ଗ୍ରହଣ କରିପାରେ ଯାହାର କୌଣସି password ରହିବା ଉଦ୍ଦିଷ୍ଟ ନଥିଲା। Update କରନ୍ତୁ, restart କରନ୍ତୁ, set କରନ୍ତୁ PasswordAuthentication no, ବାହାରୁ verify କରନ୍ତୁ, ଆପଣଙ୍କ logs ପଢ଼ନ୍ତୁ ଏବଂ ଆପଣଙ୍କ templates ଠିକ୍ କରନ୍ତୁ। ତା'ପରେ ଆପଣଙ୍କ ସଂସ୍ଥାରେ "key-only" ର ଅର୍ଥ କ'ଣ ତାହା ଲେଖନ୍ତୁ, ଏବଂ ଏହାକୁ ପରୀକ୍ଷା କରନ୍ତୁ।

ସୁବିଧାଗୁଡ଼ିକ

• Exposure ନିର୍ଦ୍ଦିଷ୍ଟ ଅଟେ, ତେଣୁ ଟିମ୍‌ଗୁଡ଼ିକ ଅଧିକାଂଶ systems କୁ ଶୀଘ୍ର ବାଦ୍ ଦେଇପାରିବେ।
• Fixed Alpine releases ଏବଂ ଏକ ସରଳ ଅସ୍ଥାୟୀ mitigation ପୂର୍ବରୁ ଉପଲବ୍ଧ ଅଛି।
• ଏହି ଯାଞ୍ଚଗୁଡ଼ିକ standard tools ବ୍ୟବହାର କରେ ଏବଂ ପ୍ରତି ସର୍ଭର ପାଇଁ କେବଳ କିଛି ମିନିଟ୍ ସମୟ ନିଏ।
• Logins ଏବଂ account data ସମୀକ୍ଷା କରିବା ଦ୍ୱାରା କେବଳ ଏହି ଗୋଟିଏ bug ନୁହେଁ, ବରଂ ସୁରକ୍ଷାରେ ଯଥେଷ୍ଟ ଉନ୍ନତି ଆସେ।

ଅସୁବିଧାଗୁଡ଼ିକ

• କେବଳ "OpenSSH installed" ଦର୍ଶାଉଥିବା Asset lists ଏହି ପ୍ରଶ୍ନର ଉତ୍ତର ଦେଇପାରିବ ନାହିଁ।
• ଏକ password user ଯୋଡ଼ିବା ଭଳି ଏକ ନିୟମିତ ପରିବର୍ତ୍ତନ, ଏକ ସୁରକ୍ଷିତ ମେସିନକୁ exposed କରିପାରେ।
• SSH settings ରେ ଭୁଲ୍ ହେଲେ administrators lock out ହୋଇପାରନ୍ତି।
• Patching ପୂର୍ବର କୌଣସି unauthorised access କୁ ପ୍ରକାଶ କରେ ନାହିଁ କିମ୍ବା undo କରେ ନାହିଁ।

ସତର୍କତା

ଏହି ଆର୍ଟିକିଲ୍ ଶିକ୍ଷଣୀୟ ଉଦ୍ଦେଶ୍ୟରେ ଲେଖାଯାଇଛି ଏବଂ ଲେଖିବା ସମୟରେ ଉପଲବ୍ଧ ପ୍ରକାଶିତ advisories ତଥା reporting ଉପରେ ଆଧାରିତ। Acme, Rohit, deploy, backup-admin, ହୋଷ୍ଟନାମ ଏବଂ IP ଠିକଣା କାଳ୍ପନିକ ପ୍ଲେସହୋଲ୍ଡର ଅଟେ, ତେଣୁ ସେଗୁଡ଼ିକୁ ଆପଣଙ୍କ ନିଜସ୍ୱ ମୂଲ୍ୟ ସହିତ ବଦଳାନ୍ତୁ। SSH ସେଟିଂସ ପରିବର୍ତ୍ତନ କରିବା ସମୟରେ ଏକ ସକ୍ରିୟ ସେସନ୍ ଖୋଲା ରଖନ୍ତୁ, କେବଳ ସେହି ସିଷ୍ଟମଗୁଡ଼ିକୁ ପରୀକ୍ଷା କରନ୍ତୁ ଯାହା ପାଇଁ ଆପଣ ଅନୁମୋଦିତ, ଏବଂ ସେଗୁଡ଼ିକ ଉପରେ ନିର୍ଭର କରିବା ପୂର୍ବରୁ ସାମ୍ପ୍ରତିକ OpenSSH ଏବଂ Alpine ପରାମର୍ଶାବଳୀ କିମ୍ବା ଆପଣଙ୍କ ନିଜ ଭେଣ୍ଡରଙ୍କ ମାର୍ଗଦର୍ଶନ ସହିତ ବିବରଣୀ ଯାଞ୍ଚ କରନ୍ତୁ।

ବାରମ୍ବାର ପଚରାଯାଉଥିବା ପ୍ରଶ୍ନଗୁଡ଼ିକ

• OpenSSH 10.6p2 କ’ଣ? — ଏହା 5 ନଭେମ୍ବର 2026 ର ଏକ ଜରୁରୀକାଳୀନ Portable OpenSSH ରିଲିଜ୍, ଯେଉଁଥିରେ କେତେକ musl-ଆଧାରିତ Linux ସିଷ୍ଟମକୁ ପ୍ରଭାବିତ କରୁଥିବା ଏକ ଲଗଇନ୍ ବାଇପାସ୍ ପାଇଁ ସମାଧାନ ରହିଛି।
• ପ୍ରତ୍ୟେକ Alpine Linux ସିଷ୍ଟମ୍ କ’ଣ ଅସୁରକ୍ଷିତ? — ନା। ଏକ ସିଷ୍ଟମରେ PAM ବିନା ପାସୱାର୍ଡ ଯାଞ୍ଚ କରୁଥିବା ଏକ ଚାଲୁଥିବା SSH ସର୍ଭର, ପାସୱାର୍ଡ ପ୍ରମାଣୀକରଣ ସକ୍ଷମ, ଏବଂ ଏପରି ଏକ ଟାର୍ଗେଟ୍ ଆକାଉଣ୍ଟ ଆବଶ୍ୟକ ଯେଉଁଥିରେ ଏକ * ପାସୱାର୍ଡ ଫିଲ୍ଡ ଥିବ, ଏବଂ ଅନ୍ୟ ଏକ ଲୋକାଲ୍ ଆକାଉଣ୍ଟ ଯେଉଁଥିରେ ଏକ $5$ କିମ୍ବା $6$ ହ୍ୟାଶ୍ ଥିବ।
• Ubuntu, Debian ଏବଂ ଅନ୍ୟ glibc ସିଷ୍ଟମଗୁଡ଼ିକ କ’ଣ ପ୍ରଭାବିତ? — glibc ବ୍ୟବହାର କରୁଥିବା Linux ସିଷ୍ଟମଗୁଡ଼ିକ ଉଲ୍ଲିଖିତ ପରିସର ବାହାରେ ଅଟେ, ଏବଂ ସେହିପରି ଅଣ-Linux ପ୍ଲାଟଫର୍ମ ତଥା PAM ମାଧ୍ୟମରେ ପାସୱାର୍ଡ ଯାଞ୍ଚ କରୁଥିବା Linux ସିଷ୍ଟମଗୁଡ଼ିକ ମଧ୍ୟ ଏହାର ବାହାରେ।
• Alpine Docker କଣ୍ଟେନରଗୁଡ଼ିକ କ’ଣ ବିପଦରେ ରହିଛି? — କୌଣସି ଚାଲୁଥିବା SSH ସର୍ଭର ନଥିବା କଣ୍ଟେନରଗୁଡ଼ିକ ଏହି ଆକ୍ରମଣ ପଥର ବାହାରେ, ତେଣୁ ପ୍ରଶ୍ନ ହେଉଛି ଏକ କଣ୍ଟେନର ପ୍ରକୃତରେ sshd ଚଲାଉଛି କି ନାହିଁ।
• PermitRootLogin prohibit-password କ’ଣ ମୋତେ ସୁରକ୍ଷା ଦିଏ? — ଏହା root ପାଇଁ ସିଧାସଳଖ ପାସୱାର୍ଡ ଲଗଇନକୁ ବ୍ଲକ୍ କରେ, କିନ୍ତୁ ଏହା କୌଣସି ଆକ୍ରମଣକାରୀଙ୍କୁ ଅନ୍ୟ ଏକ ଆକାଉଣ୍ଟ ମାଧ୍ୟମରେ ପ୍ରବେଶ କରି ପ୍ରିଭିଲେଜ୍ ବଢ଼ାଇବାରୁ ରୋକି ନଥାଏ, ଯେପରିକି tiny-cloud alpine ଆକାଉଣ୍ଟ ପରିସ୍ଥିତିରେ।
• ପ୍ୟାକେଜ୍ ଅପଡେଟ୍ କରିବା କ’ଣ ଯଥେଷ୍ଟ? — ନା। ଆପଣଙ୍କୁ SSH ସର୍ଭିସ୍ ମଧ୍ୟ ରିଷ୍ଟାର୍ଟ କରିବାକୁ ପଡ଼ିବ, କାରଣ ଆପଣ ତାହା ନକରିବା ପର୍ଯ୍ୟନ୍ତ ପୁରୁଣା ସର୍ଭର ମେମୋରୀରେ ଚାଲୁ ରହିଥାଏ।
• ଯଦି ମୁଁ ଆଜି ଅପଡେଟ୍ କରିପାରିବି ନାହିଁ, ତେବେ ମୋତେ କ’ଣ କରିବା ଉଚିତ୍? — ସେଟ୍ କରନ୍ତୁ PasswordAuthentication no, ଏହା ସହିତ ପ୍ରଭାବୀ ସେଟିଂ ନିଶ୍ଚିତ କରନ୍ତୁ sshd -T, ଏବଂ ଏକ ବିଦ୍ୟମାନ ସେସନ୍ ଖୋଲା ରଖି କୀ ଆକ୍ସେସ୍ ପରୀକ୍ଷା କରନ୍ତୁ।
• କେହି ଏହାକୁ ପୂର୍ବରୁ ବ୍ୟବହାର କରିଛନ୍ତି କି ନାହିଁ ତାହା ମୁଁ କିପରି ଯାଞ୍ଚ କରିବି? — ଖୋଜନ୍ତୁ /var/log/messages ରେ Accepted password for ଏଣ୍ଟ୍ରିଗୁଡ଼ିକ, ସେହି ଆକାଉଣ୍ଟଗୁଡ଼ିକରେ ଯେଉଁଗୁଡ଼ିକ ପାସୱାର୍ଡ ବ୍ୟବହାର କରିବା ଉଚିତ୍ ନୁହେଁ, ଏବଂ ଯଦି ଅନଧିକୃତ ଲଗଇନ୍ ଏଡ଼ାଇ ଦିଆଯାଇପାରିବ ନାହିଁ ତେବେ ହୋଷ୍ଟକୁ କମ୍ପ୍ରୋମାଇଜ୍ ବୋଲି ବିବେଚନା କରନ୍ତୁ।

ଟ୍ୟାଗ୍‌ଗୁଡ଼ିକ

#OpenSSH #AlpineLinux #LinuxSecurity #SSH #AuthenticationBypass #Musl #DevSecOps #CloudSecurity #PatchManagement #IncidentResponse