OpenSSH ತುರ್ತು ಪರಿಹಾರ: Alpine Linux ಲಾಗಿನ್ ಬೈಪಾಸ್ ವಿವರಣೆ, ಒಂದು ಪ್ರಾಯೋಗಿಕ ಉದಾಹರಣೆಯೊಂದಿಗೆ

ಯಾವುದೇ ಪಾಸ್‌ವರ್ಡ್ ಇಲ್ಲದ ಸರ್ವರ್ ಖಾತೆಯೊಂದನ್ನು ಊಹಿಸಿಕೊಳ್ಳಿ. ಈಗ ಪಾಸ್‌ವರ್ಡ್ ಪರಿಶೀಲನೆಯೊಂದು ದೋಷ ಸಂದೇಶವನ್ನು ಸರಿಯಾದ ಉತ್ತರವೆಂದು ತಪ್ಪಾಗಿ ಗ್ರಹಿಸಿದ್ದರಿಂದ, ದಾಳಿಕೋರನೊಬ್ಬ ಹೇಗಾದರೂ ಅದಕ್ಕೆ ಲಾಗಿನ್ ಆಗಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ ಎಂದು ಊಹಿಸಿಕೊಳ್ಳಿ. ಈ ವಾರದ OpenSSH ತುರ್ತು ಬಿಡುಗಡೆಯ ಕೇಂದ್ರಬಿಂದುವಾಗಿರುವ ದೋಷ (bug) ಇದೇ ಆಗಿದೆ.

ಇಂದು ನವೆಂಬರ್ 6, 2026, ಮತ್ತು ಇದು ಇದೀಗ ಅತ್ಯಂತ ಮುಖ್ಯವಾಗಿದೆ ಏಕೆಂದರೆ Portable OpenSSH 10.6p2 ಕೇವಲ ನಿನ್ನೆ, ನವೆಂಬರ್ 5 ರಂದು ಪ್ರಾಜೆಕ್ಟ್‌ನ ತುರ್ತು ವಿನಂತಿಯೊಂದಿಗೆ ಬಿಡುಗಡೆಯಾಗಿದೆ. ನೀವು ಪಾಸ್‌ವರ್ಡ್ ದೃಢೀಕರಣವನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿದ musl-ಆಧಾರಿತ Linux ಸರ್ವರ್‌ಗಳನ್ನು ಚಲಾಯಿಸುತ್ತಿದ್ದರೆ, ನೀವು ಸೂಕ್ತ ಕ್ರಮ ಕೈಗೊಳ್ಳುವವರೆಗೆ ಪಾಸ್‌ವರ್ಡ್ ಲಾಗಿನ್‌ಗಳನ್ನು ಅಥವಾ SSH ಅನ್ನು ತಕ್ಷಣವೇ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲು ಡೆವಲಪರ್‌ಗಳು ಕೋರಿದ್ದಾರೆ.

ಹಲವು ತಂಡಗಳು ಆ ಮುಖ್ಯಾಂಶವನ್ನು ಓದಿ ಗಾಬರಿಗೊಳ್ಳಬಹುದು ಅಥವಾ ನಿರ್ಲಕ್ಷಿಸಬಹುದು. ಎರಡೂ ತಪ್ಪು. ಹೆಚ್ಚಿನ Linux ಸರ್ವರ್‌ಗಳು ಇದರಿಂದ ಪ್ರಭಾವಿತವಾಗಿಲ್ಲ, ಆದರೆ ಪ್ರಭಾವಿತವಾಗಿರುವ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ನೀವು ಯಾವಾಗಲೂ "key-only" ಎಂದು ಕರೆಯುತ್ತಿದ್ದ ಸರ್ವರ್‌ಗಳೂ ಒಳಗೊಂಡಿರಬಹುದು. ಈ ಮಾರ್ಗದರ್ಶಿಯು ದೋಷವನ್ನು ಸರಳ ಭಾಷೆಯಲ್ಲಿ ವಿವರಿಸುತ್ತದೆ, ಸರ್ವರ್ ಅನ್ನು ಹೇಗೆ ಪರಿಶೀಲಿಸಬೇಕೆಂದು ನಿಖರವಾಗಿ ತೋರಿಸುತ್ತದೆ ಮತ್ತು ಪತ್ತೆಹಚ್ಚುವಿಕೆಯಿಂದ ಹಿಡಿದು ದೃಢೀಕೃತ ಪರಿಹಾರದವರೆಗಿನ ಸಂಪೂರ್ಣ ಉದಾಹರಣೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ.

ಸರಳ ಮಾತುಗಳಲ್ಲಿ ಏನು ಸಂಭವಿಸಿತು

ಸರ್ವರ್‌ಗಳಿಗೆ ರಿಮೋಟ್ ಆಗಿ ಲಾಗಿನ್ ಆಗಲು ನಿರ್ವಾಹಕರು ಬಳಸುವ ಸಾಧನವೇ SSH. OpenSSH ಇದರ ಅತ್ಯಂತ ವ್ಯಾಪಕವಾಗಿ ಬಳಸಲಾಗುವ ಆವೃತ್ತಿಯಾಗಿದೆ.

ಪ್ರತಿಯೊಂದು Linux ಪ್ರೋಗ್ರಾಂ ಮೂಲಭೂತ ಫಂಕ್ಷನ್‌ಗಳ ಹಂಚಿಕೆಯ ಸಂಗ್ರಹವಾದ C ಲೈಬ್ರರಿಯನ್ನು ಅವಲಂಬಿಸಿದೆ. ಹೆಚ್ಚಿನ Linux ಸಿಸ್ಟಮ್‌ಗಳು glibc ಎಂಬ ಲೈಬ್ರರಿಯನ್ನು ಬಳಸುತ್ತವೆ. Alpine Linux, musl ಎಂಬ ಸಣ್ಣ ಲೈಬ್ರರಿಯನ್ನು ಬಳಸುತ್ತದೆ; ಕಂಟೈನರ್‌ಗಳು ಮತ್ತು ಸಣ್ಣ ಕ್ಲೌಡ್ ಸರ್ವರ್‌ಗಳಿಗೆ Alpine ಇಷ್ಟೊಂದು ಜನಪ್ರಿಯವಾಗಲು ಇದು ಪ್ರಮುಖ ಕಾರಣವಾಗಿದೆ.

ಆ ಎರಡು ಸಾಫ್ಟ್‌ವೇರ್‌ಗಳು ಸಂಧಿಸುವ ಸ್ಥಳದಲ್ಲೇ ಈ ದೋಷ ಅಡಗಿದೆ. OpenSSH ನ ಡೆವಲಪರ್‌ಗಳು ಇದರ ಮೂಲ ಕಾರಣವು OpenSSH ನ ಹೊರಗಿದೆ ಎಂದು ಪರಿಗಣಿಸುತ್ತಾರೆ, ಆದರೆ SSH ಸರ್ವರ್ ಇದನ್ನು ದುರುಪಯೋಗಪಡಿಸಿಕೊಳ್ಳಲು (exploit) ಮಾರ್ಗವನ್ನು ಒದಗಿಸುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ತಡೆಯಲು ಪ್ರಾಯೋಗಿಕ ಸ್ಥಳವಾಗಿದೆ ಎಂಬುದನ್ನು ಸಹ ಅವರು ಗುರುತಿಸುತ್ತಾರೆ. ಆದ್ದರಿಂದ 10.6p2 ಒಂದು ಪರಿಹಾರೋಪಾಯವನ್ನು (workaround) ಸೇರಿಸುತ್ತದೆ. ಈ ದೋಷವನ್ನು Wakefield ನ Özgün Kültekin ಪತ್ತೆಹಚ್ಚಿದ್ದಾರೆ.

ದೋಷವೊಂದು ಯಶಸ್ವಿ ಲಾಗಿನ್ ಆಗಿ ಹೇಗೆ ಬದಲಾಗುತ್ತದೆ

ಯಾವುದೇ ಎಕ್ಸ್‌ಪ್ಲಾಯ್ಟ್ ವಿವರಗಳಿಲ್ಲದೆ, ಹಂತ-ಹಂತವಾಗಿ ತರ್ಕ ಇಲ್ಲಿದೆ.

ಸರ್ವರ್ ಒಂದು PAM (Pluggable Authentication Modules, ಲಾಗಿನ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಸಾಮಾನ್ಯ ವ್ಯವಸ್ಥೆ) ಇಲ್ಲದೆ ಪಾಸ್‌ವರ್ಡ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿದಾಗ, ಅದು ಸರಳವಾದದ್ದನ್ನು ಮಾಡುತ್ತದೆ. ಸಂದರ್ಶಕರು ಟೈಪ್ ಮಾಡಿದ ಪಾಸ್‌ವರ್ಡ್ ಅನ್ನು ಹ್ಯಾಶ್ ಮಾಡುತ್ತದೆ, ನಂತರ ಆ ಫಲಿತಾಂಶವನ್ನು ಆ ಖಾತೆಗಾಗಿ ಸಂಗ್ರಹಿಸಲಾದ ಮೌಲ್ಯದೊಂದಿಗೆ ಹೋಲಿಸುತ್ತದೆ.

ಹ್ಯಾಶ್‌ಗೆ ಸಾಲ್ಟ್ (salt) ನ ಅಗತ್ಯವಿರುತ್ತದೆ, ಇದು ಸಣ್ಣ ಯಾದೃಚ್ಛಿಕ ಮೌಲ್ಯವಾಗಿದ್ದು, ಒಂದೇ ರೀತಿಯ ಪಾಸ್‌ವರ್ಡ್‌ಗಳು ವಿಭಿನ್ನ ಫಲಿತಾಂಶಗಳನ್ನು ನೀಡುವಂತೆ ಮಾಡಲು ಅದನ್ನು ಬೆರೆಸಲಾಗುತ್ತದೆ. ಒಂದು ಖಾತೆಗೆ ಸಂಗ್ರಹಿಸಲಾದ ಮೌಲ್ಯವು ಸಾಲ್ಟ್ ಒದಗಿಸಲು ತುಂಬಾ ಕಡಿಮೆಯಿದ್ದರೆ, OpenSSH ಅದೇ ಮೆಷಿನ್‌ನಲ್ಲಿರುವ ಮತ್ತೊಂದು ಖಾತೆಯಿಂದ ಒಂದನ್ನು ಎರವಲು ಪಡೆಯಬಹುದು. ಇದು ಇದನ್ನು ಉತ್ತಮ ಕಾರಣಕ್ಕಾಗಿ ಮಾಡುತ್ತದೆ: CVE-2016-6210 ದೋಷಕ್ಕೆ ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿ, ಯಾವ ಬಳಕೆದಾರರ ಹೆಸರುಗಳು ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ ಎಂದು ದಾಳಿಕೋರರು ಊಹಿಸುವುದನ್ನು ತಡೆಯಲು 2016 ರಿಂದ ಇದು ಪ್ರಯತ್ನಿಸುತ್ತಿದೆ.

ಈಗ ಘರ್ಷಣೆ (collision). musl ನ crypt() ಫಂಕ್ಷನ್‌ಗೆ ನಿರ್ದಿಷ್ಟ ಹ್ಯಾಶ್ ಪ್ರಕಾರಗಳಿಗೆ ಅತಿ ಉದ್ದವಾದ ಪಾಸ್‌ವರ್ಡ್ ನೀಡಿದಾಗ, ಅದು ನಿರಾಕರಿಸುತ್ತದೆ ಮತ್ತು ಒಂದೇ ಅಕ್ಷರವಾದ * ಅನ್ನು ದೋಷದ ಸಂಕೇತವಾಗಿ ಹಿಂತಿರುಗಿಸುತ್ತದೆ.

ಆದರೆ * ಎಂಬುದು ಪಾಸ್‌ವರ್ಡ್ ಹೊಂದಿರಬಾರದೆಂದಿರುವ ಖಾತೆಯ ಪಾಸ್‌ವರ್ಡ್ ಫೀಲ್ಡ್‌ನಲ್ಲಿ ಹಲವು ಸಿಸ್ಟಮ್‌ಗಳು ಸಂಗ್ರಹಿಸಿಡುವ ಮೌಲ್ಯವೂ ಆಗಿದೆ.

ಹಾಗಾಗಿ ಸರ್ವರ್ ಎರಡು ಮೌಲ್ಯಗಳನ್ನು ಹೋಲಿಸುತ್ತದೆ:

• ಅದು ಲೆಕ್ಕಾಚಾರ ಮಾಡಿದ್ದು: *, ಇದರ ನಿಜವಾದ ಅರ್ಥ "error".
• ಅದು ಸಂಗ್ರಹಿಸಿಟ್ಟುಕೊಂಡಿರುವುದು: *, ಇದರ ನಿಜವಾದ ಅರ್ಥ "no usable password".

ಅವು ಹೊಂದಾಣಿಕೆಯಾಗುತ್ತವೆ. ಲಾಗಿನ್ ಯಶಸ್ವಿಯಾಗುತ್ತದೆ.

ಪಟ್ಟಿಯೊಂದನ್ನು ನೋಡಿ ಹೆಸರುಗಳನ್ನು ಪರಿಶೀಲಿಸುವ ಬೌನ್ಸರ್ ಒಬ್ಬನನ್ನು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ಸ್ಕ್ಯಾನರ್ ಕೆಟ್ಟುಹೋಗಿ "ERROR" ಎಂದು ಪ್ರಿಂಟ್ ಮಾಡುತ್ತದೆ. ಸಿಬ್ಬಂದಿಗಾಗಿ ಟಿಪ್ಪಣಿಯಾಗಿ ಸೇರಿಸಲಾದ ಪಟ್ಟಿಯ ಒಂದು ನಮೂದೂ ಸಹ "ERROR" ಎಂದಿರುತ್ತದೆ. ಬೌನ್ಸರ್ ಎರಡು ಒಂದೇ ರೀತಿಯ ಪದಗಳನ್ನು ಕಂಡು ಆ ವ್ಯಕ್ತಿಗೆ ಒಳಗೆ ಹೋಗಲು ಸನ್ನೆ ಮಾಡುತ್ತಾನೆ. ಯಾರೂ ಸುಳ್ಳು ಹೇಳಲಿಲ್ಲ, ಮತ್ತು ಪ್ರತಿಯೊಂದು ಭಾಗವೂ ತನ್ನ ಕೆಲಸವನ್ನು ಮಾಡಿದೆ. ಆದರೆ ಒಂದೇ ಮೌಲ್ಯವು ಎರಡು ವಿಭಿನ್ನ ಅರ್ಥಗಳನ್ನು ನೀಡಿದ್ದರಿಂದ ಈ ಅಪಾಯ ಉಂಟಾಗಿದೆ.

ಸಂಶೋಧಕರು ಈ ಪರಸ್ಪರ ಕ್ರಿಯೆಯ ಮೂಲವನ್ನು 2012 ರ musl ಬದಲಾವಣೆಗಳು ಮತ್ತು ಆ 2016 ರ OpenSSH ಬದಲಾವಣೆಗೆ ಗುರುತಿಸುತ್ತಾರೆ. AI ಏಜೆಂಟ್‌ಗಳ ಸಹಾಯದೊಂದಿಗೆ, ವಿವಿಧ ಬಿಲ್ಡ್ ಮತ್ತು ಲಾಗಿನ್ ಸಂಯೋಜನೆಗಳಲ್ಲಿ ಸುಮಾರು 17,600 ಪರೀಕ್ಷಾ ಲಾಗಿನ್‌ಗಳ ಮೂಲಕ ಇದನ್ನು ಕಂಡುಕೊಂಡಿರುವುದಾಗಿ ಅವರು ವರದಿ ಮಾಡಿದ್ದಾರೆ.

ನೀವು ಇದರಿಂದ ಪ್ರಭಾವಿತರಾಗಿದ್ದೀರಾ? ನಾಲ್ಕು ಷರತ್ತುಗಳು

Alpine ಸಲಹೆಯು ನಾಲ್ಕು ಷರತ್ತುಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಅವೆಲ್ಲವೂ ಮುಖ್ಯವಾಗಿವೆ:

1. OpenSSH ಪಾಸ್‌ವರ್ಡ್‌ಗಳನ್ನು PAM ಇಲ್ಲದೆ ಪರಿಶೀಲಿಸುತ್ತದೆ.
2. PasswordAuthentication ಸಕ್ರಿಯವಾಗಿದೆ (enabled).
3. ಟಾರ್ಗೆಟ್ ಖಾತೆಯ ಪಾಸ್‌ವರ್ಡ್ ಫೀಲ್ಡ್ ಒಳಗೊಂಡಿರುವುದು *.
4. ಮತ್ತೊಂದು ಸ್ಥಳೀಯ ಖಾತೆಯು ಇದರೊಂದಿಗೆ ಪ್ರಾರಂಭವಾಗುವ ಪಾಸ್‌ವರ್ಡ್ ಹ್ಯಾಶ್ ಹೊಂದಿದೆ: $5$ ಅಥವಾ $6$.

Alpine ನ ಪ್ರಮಾಣಿತ openssh-server ಪ್ಯಾಕೇಜ್ PAM ಅನ್ನು ಬಳಸುವುದಿಲ್ಲ. ಇನ್‌ಸ್ಟಾಲ್ ಮಾಡಲಾದ openssh-server-pam ಕೂಡ ಇದನ್ನು ಪರಿಹರಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಒಂದು ವೇಳೆ UsePAM no ಸೆಟ್ ಆಗಿದ್ದರೆ ನೀವು ಇನ್ನೂ ಅಪಾಯದಲ್ಲಿದ್ದೀರಿ.

ಇವುಗಳು ಹೇಳಲಾದ ವ್ಯಾಪ್ತಿಯಿಂದ ಹೊರಗಿವೆ:

• Linux ಅಲ್ಲದ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳು.
• glibc ಬಳಸುವ Linux ಸಿಸ್ಟಮ್‌ಗಳು.
• PAM ಮೂಲಕ ಪಾಸ್‌ವರ್ಡ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸುವ Linux ಸಿಸ್ಟಮ್‌ಗಳು.
• ಯಾವುದೇ ಚಾಲನೆಯಲ್ಲಿರುವ SSH ಸರ್ವರ್ ಹೊಂದಿರದ ಕಂಟೈನರ್‌ಗಳು.
• ಪಾಸ್‌ವರ್ಡ್ ದೃಢೀಕರಣವನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲಾದ ಸಿಸ್ಟಮ್‌ಗಳು.
• ಖಾತೆಗಳನ್ನು ಇದರೊಂದಿಗೆ ಲಾಕ್ ಮಾಡಿದ್ದರೆ: ! , ಇದರ ಬದಲಿಗೆ: *.

ಆ ಕೊನೆಯ ಗುಂಪೇ "ನಾವು Alpine ಬಳಸುತ್ತೇವೆ" ಎಂಬುದು "ನಾವು ಅಪಾಯದಲ್ಲಿದ್ದೇವೆ" ಎಂಬುದಕ್ಕೆ ಸಮಾನವಲ್ಲದಿರಲು ಕಾರಣವಾಗಿದೆ. ಹೆಚ್ಚಿನ Alpine ಕಂಟೈನರ್‌ಗಳು ಯಾವುದೇ SSH ಸರ್ವರ್ ಅನ್ನು ಚಲಾಯಿಸುವುದೇ ಇಲ್ಲ. ಅದೇ ರೀತಿ, "OpenSSH ಇನ್‌ಸ್ಟಾಲ್ ಆಗಿದೆ" ಎಂಬುದು ನಿಮಗೆ ಬಹಳ ಕಡಿಮೆ ಮಾಹಿತಿಯನ್ನು ನೀಡುತ್ತದೆ. ನೀವು C ಲೈಬ್ರರಿ, ಪ್ಯಾಕೇಜ್, ಚಾಲನೆಯಲ್ಲಿರುವ ಕಾನ್ಫಿಗರೇಶನ್ ಮತ್ತು ಖಾತೆಯ ಡೇಟಾವನ್ನು ತಿಳಿದುಕೊಳ್ಳಬೇಕಾಗುತ್ತದೆ.

ಅಪಾಯಕಾರಿ ಸನ್ನಿವೇಶ: ಅಧಿಕೃತ ಕ್ಲೌಡ್ ಇಮೇಜ್‌ಗಳು

Alpine ನಿರ್ದಿಷ್ಟವಾಗಿ ಒಂದು ಸನ್ನಿವೇಶವನ್ನು ಪ್ರಸ್ತಾಪಿಸುತ್ತದೆ. ಆವೃತ್ತಿ 3.18.11 ರಿಂದ 3.24.3 ರವರೆಗಿನ ಅದರ ಅಧಿಕೃತ tiny-cloud ಇಮೇಜ್‌ಗಳು ಇಂತಹ ಒಂದು alpine ಖಾತೆಯನ್ನು ಒಳಗೊಂಡಿವೆ, ಇದು * ಪಾಸ್‌ವರ್ಡ್ ಫೀಲ್ಡ್ ಮತ್ತು ಪಾಸ್‌ವರ್ಡ್ ಇಲ್ಲದ doas ಹಕ್ಕುಗಳನ್ನು (rights) ಹೊಂದಿದೆ. doas ಎಂಬುದು ಒಂದು ಸಣ್ಣ ಸಾಧನವಾಗಿದ್ದು, ಇದು sudoಗೆ ಹೋಲುತ್ತದೆ ಮತ್ತು ಬಳಕೆದಾರರಿಗೆ root ಆಗಿ ಕಮಾಂಡ್‌ಗಳನ್ನು ಚಲಾಯಿಸಲು ಅನುಮತಿಸುತ್ತದೆ.

ಆ ಇಮೇಜ್‌ಗಳು ಆರಂಭದಲ್ಲಿ ಸುರಕ್ಷಿತವಾಗಿರುತ್ತವೆ, ಏಕೆಂದರೆ ನಾಲ್ಕನೇ ಷರತ್ತು ಅಲ್ಲಿರುವುದಿಲ್ಲ. ಮೆಷಿನ್‌ನಲ್ಲಿ ಅಂತಹ ಯಾವುದೇ ಅರ್ಹ ಪಾಸ್‌ವರ್ಡ್ ಹ್ಯಾಶ್ ಇರುವುದಿಲ್ಲ.

ನಂತರ ಯಾರಾದರೂ ಬಹುಶಃ ಕನ್ಸೋಲ್ ಪ್ರವೇಶಕ್ಕಾಗಿ ಸಾಮಾನ್ಯ ಪಾಸ್‌ವರ್ಡ್ ಹೊಂದಿರುವ ಬಳಕೆದಾರರನ್ನು ಸೇರಿಸುತ್ತಾರೆ. ಆ ಒಂದು ವಾಡಿಕೆಯ ಬದಲಾವಣೆಯು ಈ ಷರತ್ತುಗಳ ಗುಂಪನ್ನು ಪೂರ್ಣಗೊಳಿಸಬಹುದು. ದಾಳಿಕೋರನು alpine ಆಗಿ ಪ್ರವೇಶಿಸಿ root ಆಗಿ ಬದಲಾಗಬಹುದು.

ಡೀಫಾಲ್ಟ್ ಆದ PermitRootLogin prohibit-password ಸೆಟ್ಟಿಂಗ್ ಇಲ್ಲಿ ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ. ಇದು root ಗೆ ನೇರ ಪಾಸ್‌ವರ್ಡ್ ಲಾಗಿನ್‌ಗಳನ್ನು ತಡೆಯುತ್ತದೆ, ಆದರೆ ಈ ಮಾರ್ಗವು ಪರೋಕ್ಷವಾಗಿ root ಅನ್ನು ತಲುಪುತ್ತದೆ.

ಒಂದು ಪ್ರಾಯೋಗಿಕ ಉದಾಹರಣೆ: Acme ನ ಜಂಪ್ ಹೋಸ್ಟ್

ನಾವು ಒಂದು ಕಾಲ್ಪನಿಕ ಕಂಪನಿಯನ್ನು ಗಮನಿಸೋಣ. Acme ಒಂದು ಸಣ್ಣ Alpine ಸರ್ವರ್ ಆದ bastion.example.comಅನ್ನು ನಡೆಸುತ್ತದೆ, ಆಂತರಿಕ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ತಲುಪಲು ಸಿಬ್ಬಂದಿ ಇದರ ಮೂಲಕ ಸಂಪರ್ಕ ಸಾಧಿಸುತ್ತಾರೆ. ಪ್ರತಿಯೊಬ್ಬರೂ ಇದು key-only ಎಂದು ಹೇಳುತ್ತಾರೆ. ಹೊಸ ಇಂಜಿನಿಯರ್ ಆದ Rohit ಗೆ ಅದನ್ನು ಸಾಬೀತುಪಡಿಸಲು ಕೇಳಲಾಗಿದೆ.

ಹಂತ 1: ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಅನ್ನು ದೃಢೀಕರಿಸಿ

Rohit ಲಾಗಿನ್ ಆಗಿ ಸಿಸ್ಟಮ್ ಅನ್ನು ಪರಿಶೀಲಿಸುತ್ತಾನೆ:

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

ಮೊದಲ ಕಮಾಂಡ್ Alpine ಆವೃತ್ತಿಯನ್ನು ತೋರಿಸುತ್ತದೆ. ಎರಡನೆಯದು musl ಅನ್ನು ಹೆಸರಿಸುತ್ತದೆ. ಮೂರನೆಯದು ಆ ಎರಡು ಪ್ಯಾಕೇಜ್‌ಗಳಲ್ಲಿ ಯಾವುದು ಇನ್‌ಸ್ಟಾಲ್ ಆಗಿದೆ ಎಂದು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ. Acme ನ ಸರ್ವರ್‌ನಲ್ಲಿ ಕೇವಲ openssh-server ಮಾತ್ರ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಆದ್ದರಿಂದ ಅಲ್ಲಿ ಯಾವುದೇ PAM ಇರುವುದಿಲ್ಲ.

ಒಂದು ವೇಳೆ ldd --version ಇದರ ಬದಲಾಗಿ glibc ಅನ್ನು ಹೆಸರಿಸಿದರೆ, ಅಥವಾ ಆ ಮೆಷಿನ್ ಯಾವುದೇ SSH ಸರ್ವರ್ ಚಲಾಯಿಸದಿದ್ದರೆ, ಅವರು ಅಲ್ಲಿಗೇ ನಿಲ್ಲಿಸಿ ಮುಂದಿನ ಸಿಸ್ಟಮ್‌ಗೆ ಮುಂದುವರಿಯಬಹುದು.

ಹಂತ 2: sshd ವಾಸ್ತವವಾಗಿ ಏನನ್ನು ಜಾರಿಗೊಳಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸಿ

ತಂಡಗಳು ಕೈಬಿಡುವ ಹಂತ ಇದೇ ಆಗಿದೆ. ಕಾನ್ಫಿಗ್ ಫೈಲ್ ಅನ್ನು ಓದಿ ಊಹಿಸಿಕೊಳ್ಳಬೇಡಿ. ಸರ್ವರ್‌ನಿಂದಲೇ ಅದರ ಪರಿಣಾಮಕಾರಿ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಕೇಳಿ ಪಡೆದುಕೊಳ್ಳಿ:

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

Rohit ಗೆ ಇದು ಕಾಣಿಸುತ್ತದೆ:

permitrootlogin prohibit-password
passwordauthentication yes
authenticationmethods any

ಇಲ್ಲಿದೆ ಆಶ್ಚರ್ಯ. ಪಾಸ್‌ವರ್ಡ್ ಲಾಗಿನ್‌ಗಳು ಆನ್ ಆಗಿವೆ. ಸಿಬ್ಬಂದಿ ಯಾವಾಗಲೂ ಕೀಗಳನ್ನು ಬಳಸುತ್ತಿದ್ದರು, ಆದ್ದರಿಂದ ಯಾರೂ ಇದನ್ನು ಗಮನಿಸಿರಲಿಲ್ಲ. PAM ಇಲ್ಲದ ಬಿಲ್ಡ್ usepam ಅನ್ನು ಪ್ರಿಂಟ್ ಮಾಡದೇ ಇರಬಹುದು, ಅದಕ್ಕಾಗಿಯೇ ಈ ಔಟ್‌ಪುಟ್‌ನಲ್ಲಿ ಅಂತಹ ಯಾವುದೇ ಸಾಲು ಇಲ್ಲ.

ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಪ್ರತಿ ಸಂಪರ್ಕಕ್ಕೂ Match ನಿಯಮಗಳ ಮೂಲಕ ಬದಲಾಗಬಹುದು, ಆದ್ದರಿಂದ ಅವರು ನಿರ್ದಿಷ್ಟ ಬಳಕೆದಾರ ಮತ್ತು ವಿಳಾಸಕ್ಕಾಗಿ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಪರೀಕ್ಷಿಸುತ್ತಾರೆ:

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

ಹಂತ 3: ಖಾತೆಯ ಡೇಟಾವನ್ನು ಪರಿಶೀಲಿಸಿ

root ಆಗಿ ಚಲಾಯಿಸಿದಾಗ, ಈ ಎರಡು ಕಮಾಂಡ್‌ಗಳು ಕೇವಲ ಖಾತೆಯ ಹೆಸರುಗಳನ್ನು ಮಾತ್ರ ಪ್ರಿಂಟ್ ಮಾಡುತ್ತವೆ, ಹ್ಯಾಶ್‌ಗಳನ್ನಲ್ಲ:

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" ಖಾತೆಯು * ಫೀಲ್ಡ್ ಅನ್ನು ಹೊಂದಿದೆ. ಮತ್ತು backup-admin, ಎಂಬ ಕನ್ಸೋಲ್ ಪ್ರವೇಶಕ್ಕಾಗಿ ಕಳೆದ ವರ್ಷ ರಚಿಸಲಾದ ಖಾತೆಯು ಅರ್ಹವಾದ ಹ್ಯಾಶ್ ಅನ್ನು ಹೊಂದಿದೆ. ಎಲ್ಲಾ ನಾಲ್ಕು ಷರತ್ತುಗಳು ಪೂರೈಕೆಯಾಗಿವೆ. ಈ ಸರ್ವರ್ ಅಪಾಯದಲ್ಲಿದೆ.

ಹಂತ 4: ಮೊದಲು ಬಾಗಿಲನ್ನು ಮುಚ್ಚಿ, ನಂತರ ಪ್ಯಾಚ್ ಮಾಡಿ

Rohit ತನ್ನ ಪ್ರಸ್ತುತ ಸೆಶನ್ ಅನ್ನು ತೆರೆದಿಡುತ್ತಾನೆ ಮತ್ತು ಎರಡನೇ ಟರ್ಮಿನಲ್‌ನಿಂದ ತನ್ನ ಕೀ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುತ್ತಾನೆ. ಇಲ್ಲಿ ಮಾಡುವ ಸಣ್ಣ ತಪ್ಪೂ ಎಲ್ಲರ ಪ್ರವೇಶವನ್ನು ನಿರ್ಬಂಧಿಸಬಹುದು, ಮತ್ತು ತೆರೆದಿರುವ ಸೆಶನ್ ಅವನ ಸುರಕ್ಷತಾ ಹಗ್ಗವಾಗಿದೆ.

ಅವರು ಈ ಕೆಳಗಿನ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಸೇರಿಸುತ್ತಾರೆ: /etc/ssh/sshd_config:

PasswordAuthentication no

ಒಂದು ಅಪಾಯದ ಅಂಶ: OpenSSH ಹೆಚ್ಚಿನ ಸೆಟ್ಟಿಂಗ್‌ಗಳಿಗೆ ತಾನು ಓದುವ ಮೊದಲ ಮೌಲ್ಯವನ್ನು ಬಳಸುತ್ತದೆ. ಫೈಲ್‌ನ ಮೇಲ್ಭಾಗದಲ್ಲಿ Include ಸಾಲಿದ್ದರೆ, ಅಥವಾ ಕೆಳಭಾಗದಲ್ಲಿ Match ಬ್ಲಾಕ್ ಇದ್ದರೆ, ಹೊಸ ಸಾಲು ಅನ್ವಯವಾಗದೇ ಇರಬಹುದು. ಅದಕ್ಕಾಗಿಯೇ ಎಡಿಟ್ ಮಾಡಿದ ತಕ್ಷಣವೇ ಪರಿಶೀಲನೆ ನಡೆಸಲಾಗುತ್ತದೆ:

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

sshd -t ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿನ ದೋಷಗಳನ್ನು ಪರೀಕ್ಷಿಸುತ್ತದೆ. ಇದು ಯಶಸ್ವಿಯಾದರೆ, ಅವರು ಪ್ರಕಟಿಸಲಾದ Alpine ಪರಿಹಾರವನ್ನು ಅನ್ವಯಿಸುತ್ತಾರೆ. Alpine ಸಂಸ್ಥೆಯು 3.21.10, 3.22.8, 3.23.8 ಮತ್ತು 3.24.4 ಆವೃತ್ತಿಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿದೆ, ಮತ್ತು OpenRC ಸಿಸ್ಟಮ್‌ಗಳಲ್ಲಿನ ಪರಿಹಾರ ಹೀಗಿದೆ:

apk upgrade -U -a
rc-service sshd restart

ರೀಸ್ಟಾರ್ಟ್ ಮಾಡುವುದು ಐಚ್ಛಿಕವಲ್ಲ. ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಇನ್‌ಸ್ಟಾಲ್ ಮಾಡುವುದರಿಂದ ಮೆಮೊರಿಯಲ್ಲಿ ಈಗಾಗಲೇ ಚಾಲನೆಯಲ್ಲಿರುವ SSH ಸರ್ವರ್ ಬದಲಾಗುವುದಿಲ್ಲ.

ಹಂತ 5: ಹೊರಗಿನಿಂದ ಅದನ್ನು ಸಾಬೀತುಪಡಿಸಿ

ಈಗ Rohit ಹೊರಗಿನವರು ಮಾಡುವಂತೆಯೇ, ಮತ್ತೊಂದು ಮೆಷಿನ್‌ನಿಂದ ತನ್ನ ಸ್ವಂತ ಸರ್ವರ್ ಅನ್ನು ಪರೀಕ್ಷಿಸುತ್ತಾನೆ:

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

ಅವರು ನಿರೀಕ್ಷಿಸುವ ಉತ್ತರವು ಇಂತಹ ತಿರಸ್ಕಾರವಾಗಿರುತ್ತದೆ: Permission denied (publickey). ಇದರರ್ಥ ಸರ್ವರ್ ಇನ್ನು ಮುಂದೆ ಯಾವುದೇ ಪಾಸ್‌ವರ್ಡ್‌ಗಳನ್ನು ಒದಗಿಸುವುದಿಲ್ಲ. ಸಿಬ್ಬಂದಿ ಇನ್ನೂ ಪ್ರವೇಶಿಸಬಹುದು ಎಂಬುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಅವರು ಹೊಸ ಟರ್ಮಿನಲ್‌ನಲ್ಲಿ ಸಾಮಾನ್ಯ ಕೀ-ಆಧಾರಿತ ಸೆಶನ್ ಅನ್ನು ತೆರೆಯುತ್ತಾರೆ.

ಹಂತ 6: ಈ ಹಿಂದಿನ ದುರುಪಯೋಗವನ್ನು ಪರಿಶೀಲಿಸಿ

ಪ್ಯಾಚ್ ಮಾಡುವುದು ಬಾಗಿಲನ್ನು ಮುಚ್ಚುತ್ತದೆ, ಆದರೆ ಈಗಾಗಲೇ ಅದರ ಮೂಲಕ ಯಾರು ಒಳಬಂದಿದ್ದಾರೆ ಎಂಬುದರ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. Alpine ಈ ನಿರ್ದಿಷ್ಟ ನಮೂದಿಗಾಗಿ ಲಾಗ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಲು ಶಿಫಾರಸು ಮಾಡುತ್ತದೆ:

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

ಸಿಬ್ಬಂದಿ ಕೇವಲ ಕೀಗಳನ್ನು ಮಾತ್ರ ಬಳಸುವ ಸರ್ವರ್‌ನಲ್ಲಿ, ಯಶಸ್ವಿ ಪಾಸ್‌ವರ್ಡ್ ಲಾಗಿನ್ ಎಂಬುದು ತನಿಖೆ ನಡೆಸಬೇಕಾದ ಸಂಕೇತವಾಗಿದೆ. ಪುನರಾವರ್ತಿತ ವೈಫಲ್ಯಗಳನ್ನು ಗಮನಿಸುವ ಮಾನಿಟರಿಂಗ್ ವ್ಯವಸ್ಥೆಯು ಇದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಕಳೆದುಕೊಳ್ಳಬಹುದು, ಏಕೆಂದರೆ ಇಲ್ಲಿ ದಾಳಿಕೋರನ ಪ್ರಯತ್ನವು ಯಶಸ್ಸಿನಂತೆ ಕಾಣುತ್ತದೆ.

Rohit ಗೆ ಅಂತಹದ್ದೇನೂ ಕಂಡುಬರುವುದಿಲ್ಲ. ಒಂದು ವೇಳೆ deployಗಾಗಿ ಅಂತಹ ನಮೂದು ಕಂಡುಬಂದಿದ್ದರೆ, ಕೆಲಸವು ಪ್ಯಾಚಿಂಗ್‌ನಿಂದ ಇನ್ಸಿಡೆಂಟ್ ರೆಸ್ಪಾನ್ಸ್‌ಗೆ ಬದಲಾಗುತ್ತಿತ್ತು. ಸವಲತ್ತುಗಳ ಹೆಚ್ಚಳ (privilege escalation), ಹೊಸ ಬಳಕೆದಾರರು, ಹೊಸ ಫೈಲ್‌ಗಳು ಮತ್ತು ಬದಲಾದ ಅಧಿಕೃತ ಕೀಗಳನ್ನು ಪರಿಶೀಲಿಸಲು Alpine ಸಲಹೆ ನೀಡುತ್ತದೆ, ಮತ್ತು ಅನಧಿಕೃತ ಲಾಗಿನ್ ಅನ್ನು ತಳ್ಳಿಹಾಕಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ ಆ ಹೋಸ್ಟ್ ರಾಜಿಗೊಳಗಾಗಿದೆ ಎಂದು ಪರಿಗಣಿಸಲು ತಿಳಿಸುತ್ತದೆ. ಸಂಗ್ರಹಿಸಲಾದ ರುಜುವಾತುಗಳು (credentials) ಮತ್ತು ನಿಯೋಜನೆ ರಹಸ್ಯಗಳು (deployment secrets) ಸೇರಿದಂತೆ ಆ ಖಾತೆಯು ತಲುಪಬಹುದಾದ ಎಲ್ಲವನ್ನೂ ಪರಿಶೀಲಿಸುವುದು ಮತ್ತು ಬದಲಾಯಿಸುವುದು ಅಗತ್ಯವಾಗಿರುತ್ತದೆ.

ಯಾವುದೇ ಅನುಮಾನಾಸ್ಪದ ಲಾಗಿನ್ ನಡೆದ ಸಮಯದಲ್ಲಿ ಖಾತೆಯು ಹೇಗೆ ಕಾಣುತ್ತಿತ್ತು ಎಂಬುದನ್ನೂ ಸಹ ಪರಿಶೀಲಿಸಿ. ಅದರ ಪ್ರಸ್ತುತ ಸ್ಥಿತಿಯು ನಂತರದ ಬದಲಾವಣೆಯನ್ನು ಪ್ರತಿಬಿಂಬಿಸಬಹುದು.

ಹಂತ 7: ಕೇವಲ ಉತ್ಪನ್ನವನ್ನಷ್ಟೇ ಅಲ್ಲ, ಕಾರ್ಖಾನೆಯನ್ನೂ ಸರಿಪಡಿಸಿ

Acme ಉಳಿಸಲಾದ ಇಮೇಜ್‌ನಿಂದ ಸರ್ವರ್‌ಗಳನ್ನು ನಿರ್ಮಿಸುತ್ತದೆ. Rohit ಹಂತ 6 ರಲ್ಲೇ ನಿಲ್ಲಿಸಿದ್ದರೆ, ಮುಂದಿನ ಮರುನಿರ್ಮಾಣ ಅಥವಾ ಆಟೋಸ್ಕೇಲಿಂಗ್ ಹಳೆಯ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ನೇರವಾಗಿ ಮರಳಿ ತರಬಹುದಿತ್ತು. ಅವರು ಟೆಂಪ್ಲೇಟ್ ಅನ್ನು ಅಪ್‌ಡೇಟ್ ಮಾಡುತ್ತಾರೆ, ಅಲ್ಲಿ PasswordAuthentication no ಅನ್ನು ಸೆಟ್ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಅಸಲಿಗೆ backup-admin ಗೆ ಪಾಸ್‌ವರ್ಡ್ ಏಕೆ ಬೇಕು ಎಂದು ಪ್ರಶ್ನಿಸುತ್ತಾರೆ.

ಸ್ಕ್ಯಾನರ್ ಫಲಿತಾಂಶಗಳನ್ನು ಹೇಗೆ ಅರ್ಥೈಸಿಕೊಳ್ಳುವುದು

ಈ ವಾರ ಗೊಂದಲಮಯ ವರದಿಗಳನ್ನು ನಿರೀಕ್ಷಿಸಿ. ಎರಡು ವಿಚಾರಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿಡಿ.

ಅಪ್‌ಸ್ಟ್ರೀಮ್ ಆವೃತ್ತಿಯ ಸ್ಟ್ರಿಂಗ್ ಮತ್ತು ಡಿಸ್ಟ್ರಿಬ್ಯೂಷನ್‌ನ ಪ್ಯಾಚ್ ಸ್ಥಿತಿಯು ವಿಭಿನ್ನ ಪುರಾವೆಗಳಾಗಿವೆ. ವೆಂಡರ್ ಒಬ್ಬರು ಮುಖ್ಯ ಆವೃತ್ತಿಯನ್ನು ಬದಲಾಯಿಸದೆಯೇ ಪರಿಹಾರವನ್ನು ಬ್ಯಾಕ್‌ಪೋರ್ಟ್ ಮಾಡಿರಬಹುದು, ಆದ್ದರಿಂದ ನಿಮ್ಮ ಡಿಸ್ಟ್ರಿಬ್ಯೂಷನ್‌ನ ಪ್ಯಾಕೇಜ್ ಮಾರ್ಗದರ್ಶನವನ್ನು ಅನುಸರಿಸಿ. ನೀವು OpenSSH ಅನ್ನು ಸ್ವತಃ ಕಂಪೈಲ್ ಮಾಡುತ್ತಿದ್ದರೆ, 10.6p2 ಬಿಡುಗಡೆ ಟಿಪ್ಪಣಿಗಳನ್ನು ಬಳಸಿ.

ಪ್ರತಿ ಸರ್ವರ್‌ಗೆ ನಾಲ್ಕು ಪ್ರತ್ಯೇಕ ಅಂಶಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಿ: ದುರ್ಬಲ ಪ್ಯಾಕೇಜ್ ಗುರುತಿಸಲಾಗಿದೆ, ಪರ್ಯಾಯ ಪ್ಯಾಕೇಜ್ ಇನ್‌ಸ್ಟಾಲ್ ಮಾಡಲಾಗಿದೆ, ಸೇವೆಯನ್ನು ರೀಸ್ಟಾರ್ಟ್ ಮಾಡಲಾಗಿದೆ, ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಪರಿಶೀಲಿಸಲಾಗಿದೆ. ಟಿಕೆಟ್‌ನಲ್ಲಿ "Patched" ಎಂದು ಬರೆದಿರುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಎರಡನೆಯ ಅಂಶವನ್ನು ಮಾತ್ರ ಸೂಚಿಸುತ್ತದೆ.

ಪರಿಹಾರವು ಇಷ್ಟು ಬೇಗ ಏಕೆ ಬಂದಿತು

ಪರಿಹಾರೋಪಾಯವನ್ನು (workaround) ಬಿಡುಗಡೆ ಮಾಡುವ ಹಿಂದಿನ ದಿನವಷ್ಟೇ ಈ ಸಮಸ್ಯೆಯ ಬಗ್ಗೆ OpenSSH ತಂಡಕ್ಕೆ ತಿಳಿಯಿತು ಎಂದು Damien Miller ಹೇಳಿದ್ದಾರೆ. ಕೆಲವೇ ಗಂಟೆಗಳಲ್ಲಿ AI ಏಜೆಂಟ್‌ಗಳು ಸ್ವತಂತ್ರವಾಗಿ ದೋಷಗಳನ್ನು ಮರುಶೋಧಿಸಿದ ಇತ್ತೀಚಿನ ಪ್ರಕರಣಗಳನ್ನು ಅವರು ಉಲ್ಲೇಖಿಸಿದ್ದು, ದೀರ್ಘಾವಧಿಯ ನಿರ್ಬಂಧಗಳು ದಾಳಿಕೋರರಿಗೆ ಅನುಕೂಲವಾಗಬಹುದು ಎಂದು ವಾದಿಸಿದ್ದಾರೆ.

ನಿಗದಿತ ಬಿಡುಗಡೆಗಳಿಗಾಗಿ ಬದಲಾವಣೆಗಳನ್ನು ಕಾಯ್ದಿರಿಸುವ ಬದಲು ಹೆಚ್ಚು ಆಗಾಗ್ಗೆ ಪರಿಹಾರಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡುವ ನಿಟ್ಟಿನಲ್ಲಿ ಕ್ರಮ ಕೈಗೊಳ್ಳುವುದನ್ನು ಈ ಬಿಡುಗಡೆ ಟಿಪ್ಪಣಿಗಳು ವಿವರಿಸುತ್ತವೆ; ಜೊತೆಗೆ ಹಲವು AI-ರಚಿತ ವರದಿಗಳು ಯಾವುದೇ ನೈಜ ಭದ್ರತಾ ಪರಿಣಾಮವನ್ನು ತೋರಿಸುವುದಿಲ್ಲ ಮತ್ತು ಮಾನವ ವಿಶ್ಲೇಷಣೆ ಇನ್ನೂ ಮುಖ್ಯವಾಗಿದೆ ಎಂಬುದನ್ನು ಒತ್ತಿಹೇಳುತ್ತವೆ.

ನಮ್ಮಲ್ಲಿ ಹೆಚ್ಚಿನವರಿಗೆ ಪ್ರಾಯೋಗಿಕ ಫಲಿತಾಂಶ ಸರಳವಾಗಿದೆ. ನಿರ್ಣಾಯಕ ಪರಿಹಾರಗಳು ಈಗ ನಿಮ್ಮ ಸಾಮಾನ್ಯ ನಿರ್ವಹಣಾ ಅವಧಿಯ (maintenance window) ಹೊರತಾಗಿಯೂ ಬರಬಹುದು. ವೆಂಡರ್ ಪ್ರಕಟಣೆಗಳನ್ನು ನೇರವಾಗಿ ಅನುಸರಿಸಿ, ಮತ್ತು ತುರ್ತು ಬದಲಾವಣೆಯನ್ನು ಮಾಡಲು ಯಾರಿಗೆ ಅಧಿಕಾರವಿದೆ ಎಂಬುದನ್ನು ಮುಂಚಿತವಾಗಿಯೇ ನಿರ್ಧರಿಸಿ.

ಈ ಅಂಶಗಳು ಅಪಾಯದ ಪ್ರಮಾಣವನ್ನು ಮತ್ತು ಸಮಂಜಸವಾದ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ವಿವರಿಸುತ್ತವೆ. ಇವು ದೃಢೀಕೃತ ದಾಳಿ ಅಭಿಯಾನದ ಪುರಾವೆಗಳಲ್ಲ.

ನಿಜವಾದ ಪಾಠ: ಒಂದೇ ಅರ್ಥವನ್ನು ನೀಡದ ಮೂರು ವಾಕ್ಯಗಳು

"Uses SSH keys", "has no password set" ಮತ್ತು "cannot authenticate with a password" ಒಂದೇ ರೀತಿ ಧ್ವನಿಸುತ್ತವೆ, ಆದರೆ ಅವು ವಿಭಿನ್ನ ವಿಷಯಗಳನ್ನು ವಿವರಿಸುತ್ತವೆ. ಮೊದಲನೆಯದು ರೂಢಿ. ಎರಡನೆಯದು ಡೇಟಾದ ಸ್ಥಿತಿ. ಮೂರನೆಯದು ಮಾತ್ರ ಕಡ್ಡಾಯವಾಗಿ ಜಾರಿಗೊಳಿಸಲಾದ ನಿಯಂತ್ರಣವಾಗಿದೆ, ಮತ್ತು ಚಾಲನೆಯಲ್ಲಿರುವ ಸರ್ವರ್ ಅನ್ನು ಪರೀಕ್ಷಿಸುವ ಮೂಲಕ ಮಾತ್ರ ನೀವು ಅದನ್ನು ತಿಳಿದುಕೊಳ್ಳಬಹುದು.

ಉಪಸಂಹಾರ

ಇದು ತೀಕ್ಷ್ಣವಾದ ಪರಿಣಾಮ ಹೊಂದಿರುವ ಒಂದು ಸೀಮಿತ ವ್ಯಾಪ್ತಿಯ ದೋಷವಾಗಿದೆ. ಹೆಚ್ಚಿನ Linux ಸಿಸ್ಟಮ್‌ಗಳು ಇದರ ವ್ಯಾಪ್ತಿಯಿಂದ ಹೊರಗಿವೆ, ಆದರೆ ಎಲ್ಲಾ ನಾಲ್ಕು ಷರತ್ತುಗಳನ್ನು ಪೂರೈಸುವ musl-ಆಧಾರಿತ ಸರ್ವರ್, ಪಾಸ್‌ವರ್ಡ್ ಹೊಂದಿರಬಾರದೆಂದಿರುವ ಖಾತೆಗೂ ಲಾಗಿನ್ ಅನ್ನು ಸ್ವೀಕರಿಸಬಹುದು. ಅಪ್‌ಡೇಟ್ ಮಾಡಿ, ರೀಸ್ಟಾರ್ಟ್ ಮಾಡಿ, PasswordAuthentication noಸೆಟ್ ಮಾಡಿ, ಹೊರಗಿನಿಂದ ಪರಿಶೀಲಿಸಿ, ನಿಮ್ಮ ಲಾಗ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ ಮತ್ತು ನಿಮ್ಮ ಟೆಂಪ್ಲೇಟ್‌ಗಳನ್ನು ಸರಿಪಡಿಸಿ. ನಂತರ ನಿಮ್ಮ ಸಂಸ್ಥೆಯಲ್ಲಿ "key-only" ಎಂದರೆ ಏನು ಎಂಬುದನ್ನು ಬರೆದಿಟ್ಟುಕೊಳ್ಳಿ ಮತ್ತು ಅದನ್ನು ಪರೀಕ್ಷಿಸಿ.

ಅನುಕೂಲಗಳು

• ಅಪಾಯವು ನಿರ್ದಿಷ್ಟವಾಗಿದೆ, ಆದ್ದರಿಂದ ತಂಡಗಳು ಹೆಚ್ಚಿನ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ತ್ವರಿತವಾಗಿ ಹೊರಗಿಡಬಹುದು.
• ಪರಿಹರಿಸಲಾದ Alpine ಆವೃತ್ತಿಗಳು ಮತ್ತು ಸರಳವಾದ ತಾತ್ಕಾಲಿಕ ಪರಿಹಾರೋಪಾಯ ಈಗಾಗಲೇ ಲಭ್ಯವಿದೆ.
• ಪರಿಶೀಲನೆಗಳು ಪ್ರಮಾಣಿತ ಸಾಧನಗಳನ್ನು ಬಳಸುತ್ತವೆ ಮತ್ತು ಪ್ರತಿ ಸರ್ವರ್‌ಗೆ ಕೆಲವೇ ನಿಮಿಷಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತವೆ.
• ಲಾಗಿನ್‌ಗಳು ಮತ್ತು ಖಾತೆಯ ಡೇಟಾವನ್ನು ಪರಿಶೀಲಿಸುವುದು ಈ ಒಂದು ದೋಷವನ್ನು ಮೀರಿಯೂ ಭದ್ರತೆಯನ್ನು ಸುಧಾರಿಸುತ್ತದೆ.

ಅನನುಕೂಲಗಳು

• ಕೇವಲ "OpenSSH installed" ಎಂದು ಮಾತ್ರ ತೋರಿಸುವ ಅಸೆಟ್ ಪಟ್ಟಿಗಳು ಈ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.
• ಪಾಸ್‌ವರ್ಡ್ ಬಳಕೆದಾರರನ್ನು ಸೇರಿಸುವಂತಹ ವಾಡಿಕೆಯ ಬದಲಾವಣೆಯು ಸುರಕ್ಷಿತ ಮೆಷಿನ್ ಅನ್ನು ಅಪಾಯಕ್ಕೆ ಸಿಲುಕಿಸಬಹುದು.
• SSH ಸೆಟ್ಟಿಂಗ್‌ಗಳಲ್ಲಿನ ತಪ್ಪುಗಳು ನಿರ್ವಾಹಕರ ಪ್ರವೇಶವನ್ನು ನಿರ್ಬಂಧಿಸಬಹುದು.
• ಪ್ಯಾಚ್ ಮಾಡುವುದು ಯಾವುದೇ ಹಿಂದಿನ ಅನಧಿಕೃತ ಪ್ರವೇಶವನ್ನು ಬಹಿರಂಗಪಡಿಸುವುದಿಲ್ಲ ಅಥವಾ ರದ್ದುಗೊಳಿಸುವುದಿಲ್ಲ.

ಎಚ್ಚರಿಕೆ

ಈ ಲೇಖನವು ಶೈಕ್ಷಣಿಕ ಉದ್ದೇಶದ್ದಾಗಿದೆ ಮತ್ತು ಬರೆಯುವ ಸಮಯದಲ್ಲಿ ಲಭ್ಯವಿರುವ ಪ್ರಕಟಿತ ಸಲಹೆಗಳು ಹಾಗೂ ವರದಿಗಳನ್ನು ಆಧರಿಸಿದೆ. Acme, Rohit, deploy, backup-admin, ಹೋಸ್ಟ್‌ನೇಮ್ ಮತ್ತು IP ವಿಳಾಸವು ಕಾಲ್ಪನಿಕ ಪ್ಲೇಸ್‌ಹೋಲ್ಡರ್‌ಗಳಾಗಿವೆ, ಆದ್ದರಿಂದ ಅವುಗಳನ್ನು ನಿಮ್ಮ ಸ್ವಂತ ಮೌಲ್ಯಗಳೊಂದಿಗೆ ಬದಲಾಯಿಸಿ. SSH ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಬದಲಾಯಿಸುವಾಗ ಸಕ್ರಿಯ ಸೆಷನ್ ತೆರೆದಿಡಿ, ನೀವು ಪರೀಕ್ಷಿಸಲು ಅಧಿಕಾರ ಹೊಂದಿರುವ ಸಿಸ್ಟಂಗಳನ್ನು ಮಾತ್ರ ಪರೀಕ್ಷಿಸಿ, ಮತ್ತು ಅವುಗಳ ಮೇಲೆ ಅವಲಂಬಿತರಾಗುವ ಮೊದಲು ಪ್ರಸ್ತುತ OpenSSH ಮತ್ತು Alpine ಸಲಹೆಗಳು ಅಥವಾ ನಿಮ್ಮ ಸ್ವಂತ ವೆಂಡರ್ ಮಾರ್ಗದರ್ಶನದೊಂದಿಗೆ ವಿವರಗಳನ್ನು ಪರಿಶೀಲಿಸಿ.

ಪದೇ ಪದೇ ಕೇಳಲಾಗುವ ಪ್ರಶ್ನೆಗಳು

• OpenSSH 10.6p2 ಎಂದರೇನು? — ಇದು ನಿರ್ದಿಷ್ಟ musl-ಆಧಾರಿತ Linux ಸಿಸ್ಟಮ್‌ಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವ ಲಾಗಿನ್ ಬೈಪಾಸ್‌ಗೆ ಪರಿಹಾರದೊಂದಿಗೆ 5 ನವೆಂಬರ್ 2026 ರ ತುರ್ತು Portable OpenSSH ಬಿಡುಗಡೆಯಾಗಿದೆ.
• ಪ್ರತಿಯೊಂದು 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