Linux ನಲ್ಲಿ AnyConnect ನ ಅಮಾನ್ಯ TLS ಆವೃತ್ತಿ: ಮೊದಲು ಸರಿಪಡಿಸುವಿಕೆಯ ವ್ಯಾಪ್ತಿಯನ್ನು ನಿರ್ಧರಿಸಿ
ಇಡೀ ಹೋಸ್ಟ್ಗೆ LEGACY ನೀತಿ, ಪ್ರತಿ ಪ್ರಕ್ರಿಯೆಗೆ OpenSSL ಸಂರಚನೆ ಮತ್ತು ಒಂದು ಬಾರಿ ಬಳಸುವ VM ಹೋಲಿಸಲಾಗಿದೆ, ಜೊತೆಗೆ ದೋಷವನ್ನು ಶಾಶ್ವತವಾಗಿ ತೆಗೆದುಹಾಕುವ ಗೇಟ್ವೇ ಬದಲಾವಣೆ.
ಈ ದೋಷವು ಪಾಸ್ವರ್ಡ್ ಕೇಳುವ ಮೊದಲೇ ಬರುತ್ತದೆ, ಮತ್ತು ಅದೇ ಉಪಯುಕ್ತ ಭಾಗ: ಇನ್ನೂ ಯಾವುದೂ ದೃಢೀಕರಣಗೊಂಡಿಲ್ಲ, ಆದ್ದರಿಂದ ರುಜುವಾತುಗಳೇ ಸಮಸ್ಯೆ ಅಲ್ಲ. Linux ನಲ್ಲಿ ಅದೇ AnyConnect ಸಂವಾದವು ಹಳೆಯ ಪ್ರೋಟೋಕಾಲ್ ಆವೃತ್ತಿ, 1024-ಬಿಟ್ ಕೀ ವಿನಿಮಯ ಗುಂಪು, ಅಥವಾ ಸಿಸ್ಟಮ್ನ ಕ್ರಿಪ್ಟೋ ನೀತಿ ನಿರಾಕರಿಸುವ ಸೈಫರ್ ಸೆಟ್ನಿಂದ ಬರಬಹುದು. ನಾನು ಮೂರು ಯಂತ್ರಗಳಲ್ಲಿ ಮೂರು ಬೇರೆ ವಿಧಾನಗಳಿಂದ ಇದನ್ನು ತೆಗೆದುಹಾಕಿದ್ದೇನೆ, ಮತ್ತು ಆ ಪರಿಹಾರಗಳನ್ನು ಬೇರ್ಪಡಿಸುವುದು ಚಾತುರ್ಯವಲ್ಲ, ಪರಿಣಾಮದ ವ್ಯಾಪ್ತಿ. ಪ್ರತಿಯೊಂದೂ ಸರಿಯಾದ ಸ್ಥಳದಲ್ಲಿ ಸಮರ್ಥನೀಯ ಮತ್ತು ಉಳಿದೆಡೆ ಕೆಟ್ಟ ಡೀಫಾಲ್ಟ್.
ನೀತಿಯನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ಸಂದೇಶವನ್ನು ಓದಿ
ಸಂವಾದದಿಂದ ನಿಖರವಾದ ಸ್ಟ್ರಿಂಗ್ ಉಳಿಸಿಕೊಳ್ಳಿ. ಆವೃತ್ತಿಯ ದೂರು ಪ್ರೋಟೋಕಾಲ್ ಪದರವನ್ನು ಸೂಚಿಸುತ್ತದೆ, ಪ್ರಮಾಣಪತ್ರದ ದೂರು ನಂಬಿಕೆ ಅಥವಾ ನಾಮಕರಣವನ್ನು, ಮತ್ತು ವಿಫಲ ಲಾಗಿನ್ ರುಜುವಾತುಗಳನ್ನು ಸೂಚಿಸುತ್ತದೆ. TLS 1.0, 1024-ಬಿಟ್ DHE ಗುಂಪು, AES-256-CBC ಮತ್ತು SHA-1 ಸಹಿ ನೀಡುವ ಗೇಟ್ವೇ ಸಂಪೂರ್ಣ ಮಾನ್ಯ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಹೊಂದಿದ್ದರೂ ನಿಮ್ಮ ರುಜುವಾತುಗಳು ಕಳುಹಿಸುವ ಮೊದಲೇ ಆಧುನಿಕ ನೀತಿಯಿಂದ ತಿರಸ್ಕರಿಸಬಹುದು.
ಸಿಸ್ಟಮ್ನ OpenSSL ನಿಂದ ಎಂಡ್ಪಾಯಿಂಟ್ ಪರಿಶೀಲಿಸಿ, ನಿಜವಾದ ಹೋಸ್ಟ್ಹೆಸರು ಮತ್ತು ಕ್ಲಯಂಟ್ ಬಳಸುವ ಪೋರ್ಟ್ ಬಳಸಿ.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com ವಿಫಲವಾಗಿ -tls1 -cipher DEFAULT@SECLEVEL=0 ಯಶಸ್ವಿಯಾದರೆ, ಮಿತಿ ಆವೃತ್ತಿ ಮತ್ತು ಕೀ ಗಾತ್ರ ಎರಡೂ ಎಂದರ್ಥ. ಮೊದಲ ಆಜ್ಞೆ ಪ್ರೋಟೋಕಾಲ್ ಎಚ್ಚರಿಕೆಯ ಬದಲು ಚಿಕ್ಕ DH ಕೀಯನ್ನು ವರದಿ ಮಾಡಿದರೆ, ಆವೃತ್ತಿ ಸರಿಯಾಗಿದೆ ಮತ್ತು ಗುಂಪಿಗೆ ಮಾತ್ರ ಗಮನ ಬೇಕು. ಪರಿಶೀಲನೆಯಲ್ಲಿ ಎಂದಿಗೂ ಖಾಸಗಿ ಕೀ ಅಥವಾ ಪಾಸ್ವರ್ಡ್ ಹಾಕಬೇಡಿ.
ಆಯ್ಕೆ 1: ಕ್ರಿಪ್ಟೋ ನೀತಿಯಿಂದ ಇಡೀ ಹೋಸ್ಟ್ ಸಡಿಲಗೊಳಿಸಿ
Fedora ಮತ್ತು RHEL 8 ಮತ್ತು 9 ನಲ್ಲಿ, update-crypto-policies --set LEGACY OpenSSL ನ ಸಿಸ್ಟಮ್ ನೀತಿಯನ್ನು ಇಳಿಸುತ್ತದೆ, ಮತ್ತು update-crypto-policies --show ಯಾವುದು ಸಕ್ರಿಯವಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ. ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಸುರಂಗವನ್ನು ಮರುಸ್ಥಾಪಿಸುತ್ತದೆ, ಆದರೆ ಪ್ರಕ್ರಿಯೆ ಪ್ರಾರಂಭವಾದಾಗ ನೀತಿ ಓದಲ್ಪಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಮತ್ತೆ ಪರೀಕ್ಷಿಸುವ ಮೊದಲು ಕ್ಲಯಂಟ್ ಮತ್ತು ಅದು ರಚಿಸಿದ ಯಾವುದೇ ಸಹಾಯಕ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿ. ಇದು ಯಂತ್ರದ ಪ್ರತಿ TLS ಕ್ಲಯಂಟ್ಗೆ ಹಳೆಯ ಪ್ರೋಟೋಕಾಲ್ಗಳು ಮತ್ತು ದುರ್ಬಲ ಗುಂಪುಗಳನ್ನು ಸಹ ಅನುಮತಿಸುತ್ತದೆ, ಪಕ್ಕದ ಕಿಟಕಿಯ ಬ್ರೌಸರ್ನಿಂದ ಕರ್ನಲ್ ನವೀಕರಿಸುವ ಪ್ಯಾಕೇಜ್ ನಿರ್ವಾಹಕದವರೆಗೆ.
ಆ ವಿಸ್ತಾರವೇ ಪೂರ್ತಿ ಉದ್ದೇಶ ಮತ್ತು ಪೂರ್ತಿ ಸಮಸ್ಯೆ. LEGACY ಇಡೀ ಹೋಸ್ಟ್ಗೆ ಅನ್ವಯಿಸುತ್ತದೆ, ಶಾಶ್ವತ ಮತ್ತು ಮರೆಯುವುದು ಸುಲಭ, ಆದ್ದರಿಂದ ಅದು ರೋಗನಿರ್ಣಯದ ಹಂತ ಅಥವಾ ನಿರ್ವಹಿತ ಬಿಲ್ಡ್ನಲ್ಲಿ ದಾಖಲಾದ ವಿನಾಯಿತಿಯಾಗಿರಬೇಕು, ಎಂದಿಗೂ ವರ್ಕ್ಸ್ಟೇಷನ್ನ ವಿಶ್ರಾಂತ ಸ್ಥಿತಿಯಾಗಿರಬಾರದು. ಒಂದು ಆಂತರಿಕ ಪೋರ್ಟಲ್ಗೆ ಅದು ಬೇಕಿದ್ದ ಕಾರಣ ಎರಡು ವರ್ಷ LEGACY ನಲ್ಲಿ ಉಳಿದ ಒಂದನ್ನು ನೋಡಿದ್ದೇನೆ, ಮತ್ತು ಅದು ಯಾವಾಗ ಪ್ರಾರಂಭವಾಯಿತು ಎಂದು ಯಾರೂ ಹೇಳಲಾಗಲಿಲ್ಲ.
Debian ಮತ್ತು Ubuntu ಗೆ ಇದಕ್ಕೆ ಒಂದೇ ಸ್ವಿಚ್ ಇಲ್ಲ. ಸಮಾನವಾದುದು ಸಿಸ್ಟಮ್ ಡೀಫಾಲ್ಟ್ ವಿಭಾಗದಲ್ಲಿ ಕಡಿಮೆ MinProtocol ಮತ್ತು CipherString = DEFAULT@SECLEVEL=0 ಸೆಟ್ ಮಾಡುವ /etc/ssl/openssl.cnf ಸಂಪಾದನೆ. ಅದೇ ವ್ಯಾಪ್ತಿ, ಬೇರೆ ಫೈಲ್, ಬಿಡುಗಡೆ ಅಪ್ಗ್ರೇಡ್ ಸಮಯದಲ್ಲಿ ಕಣ್ಣಿನಿಂದ ಮರೆಯಾಗಲು ಸ್ವಲ್ಪ ಸುಲಭ.
ಆಯ್ಕೆ 2: ಒಂದು ಕ್ಲಯಂಟ್ಗೆ ಒಂದು ಕಾನ್ಫಿಗ್ ಫೈಲ್
ಪ್ರತಿ ಪ್ರಕ್ರಿಯೆಗೆ OpenSSL ಸಂರಚನೆ ಬದಲಾವಣೆಯನ್ನು ಒಂದೇ ಪ್ರಕ್ರಿಯೆ ಮರದೊಳಗೆ ಇಡುತ್ತದೆ, ಆದರೆ ಫೈಲ್ ಗ್ರಂಥಾಲಯ ನಿರೀಕ್ಷಿಸುವ ರೀತಿಯಲ್ಲಿ ಜೋಡಿಸಲ್ಪಟ್ಟಿದ್ದರೆ ಮಾತ್ರ. ssl_conf ವಿಭಾಗಕ್ಕೆ ಹೆಸರಿಡುವುದು ಸಾಕಾಗುವುದಿಲ್ಲ: OpenSSL ಮೇಲ್ಮಟ್ಟದ openssl_conf ಕೀಯನ್ನು ಓದುತ್ತದೆ, ಅದನ್ನು ಇನಿಟ್ ವಿಭಾಗಕ್ಕೆ ಅನುಸರಿಸುತ್ತದೆ, ಮತ್ತು ಆ ನಂತರವೇ SSL ಡೀಫಾಲ್ಟ್ಗಳನ್ನು ತಲುಪುತ್ತದೆ.
openssl_conf = openssl_init
[openssl_init]
ssl_conf = ssl_sect
[ssl_sect]
system_default = system_default_sect
[system_default_sect]
MinProtocol = TLSv1.0
CipherString = DEFAULT@SECLEVEL=0OPENSSL_CONF ಅನ್ನು ಆ ಫೈಲ್ಗೆ ತೋರಿಸಿ ಮತ್ತು ಅದನ್ನು ಎಕ್ಸ್ಪೋರ್ಟ್ ಮಾಡುವ ರ್ಯಾಪರ್ ಮೂಲಕ VPN ಕ್ಲಯಂಟ್ ಪ್ರಾರಂಭಿಸಿ. ಹೋಸ್ಟ್ನಲ್ಲಿ ಉಳಿದ ಎಲ್ಲವೂ ಡೀಫಾಲ್ಟ್ ನೀತಿಯನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಅನುಸರಣೆಯ ಪ್ರಶ್ನೆ ಬಂದಾಗ ಮುಖ್ಯವಾದುದು ಆ ಗುಣಲಕ್ಷಣವೇ. ಗೇಟ್ವೇಗೆ ದೋಷ ಹೇರುವ ಮೊದಲು ಫೈಲ್ ನಿಜವಾಗಿ ಜಾರಿಯಲ್ಲಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ: OPENSSL_CONF=/path/to/file openssl ciphers -s -tls1 TLS 1.0 ಸೈಫರ್ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಬೇಕು, ಮತ್ತು ಖಾಲಿ ಫಲಿತಾಂಶ ಎಂದರೆ ಸರಪಳಿ ಮುರಿದಿದೆ ಮತ್ತು ಕ್ಲಯಂಟ್ ಸದ್ದಿಲ್ಲದೆ ಸಿಸ್ಟಮ್ ಡೀಫಾಲ್ಟ್ಗಳನ್ನು ಉಳಿಸಿಕೊಂಡಿದೆ.
ಫೈಲ್ ಆವೃತ್ತಿಗೆ ಸೂಕ್ಷ್ಮವಾಗಿದೆ. OpenSSL 1.1.1 ಮತ್ತು 3.x ಅದೇ ವಿಭಾಗ ಹೆಸರುಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತವೆ, ಆದರೆ ಪೂರೈಕೆದಾರರ ಸುತ್ತಲಿನ ಸೂಚನೆಗಳ ನಿರ್ವಹಣೆ 3.x ನಲ್ಲಿ ಬದಲಾಯಿತು, ಆದ್ದರಿಂದ ಫೈಲ್ ಓದಲ್ಪಟ್ಟಿದೆ ಎಂದು ಊಹಿಸುವ ಬದಲು ಕ್ಲಯಂಟ್ನ ಸ್ವಂತ ಲಾಗ್ ಮತ್ತು ಪರೀಕ್ಷಾ ಹ್ಯಾಂಡ್ಶೇಕ್ನಿಂದ ಪರಿಶೀಲಿಸಿ. ವಿಭಾಗ ಹೆಸರಿನಲ್ಲಿ ಮುದ್ರಣ ದೋಷ ತೆರೆದೇ ವಿಫಲವಾಗುತ್ತದೆ, ಮತ್ತು ಕ್ಲಯಂಟ್ ಸದ್ದಿಲ್ಲದೆ ಸಿಸ್ಟಮ್ ಡೀಫಾಲ್ಟ್ಗಳನ್ನು ಬಳಸುತ್ತದೆ.
ಮಿತಿ ಕವರೇಜ್. GnuTLS ಅಥವಾ NSS ಗೆ ಲಿಂಕ್ ಆಗಿರುವ ಯಾವುದೂ OPENSSL_CONF ಅನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ, ಮತ್ತು ಪರಿಸರವನ್ನು ಆನುವಂಶಿಕವಾಗಿ ಪಡೆಯದೆ ಕ್ಲಯಂಟ್ ಪ್ರಾರಂಭಿಸುವ ಯಾವುದೇ ಸಹಾಯಕ ಪ್ರಕ್ರಿಯೆಯೂ ಹಾಗೆಯೇ. ರ್ಯಾಪರ್ ನಿರ್ಮಿಸುವ ಮೊದಲು ldd ನಿಂದ ಬೈನರಿ ನಿಜವಾಗಿ ಯಾವ TLS ಗ್ರಂಥಾಲಯಕ್ಕೆ ಲಿಂಕ್ ಆಗಿದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಉತ್ತರವೇ ಈ ಆಯ್ಕೆ ಇದೆಯೇ ಇಲ್ಲವೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ.
ಆಯ್ಕೆ 3: ಒಂದು ಬಾರಿ ಬಳಸುವ VM ಅಥವಾ ಕಂಟೇನರ್
ಎರಡು ವಾರಗಳ ಕಾಲ ಒಂದು ಹಳೆಯ ಗೇಟ್ವೇ ಮೇಲೆ ದಾಳಿ ಮಾಡುವ ಗುತ್ತಿಗೆದಾರನಿಗೆ, ಸಡಿಲಗೊಳಿಸಿದ ನೀತಿಯ ಮೀಸಲಾದ VM ವರ್ಕ್ಸ್ಟೇಷನ್ಗಿಂತ ಸ್ವಚ್ಛವಾದ ಗಡಿ. ಹಳೆಯ ಮೇಲ್ಮೈ ಮತ್ತು ದೈನಂದಿನ ಬ್ರೌಸರ್ ಪ್ರೊಫೈಲ್ ಇನ್ನು ಕರ್ನಲ್ ನೀತಿಯನ್ನು ಹಂಚಿಕೊಳ್ಳುವುದಿಲ್ಲ, ಮತ್ತು ವಿಲೇವಾರಿ ಎಂದರೆ ಆಡಿಟ್ ಕಂಡುಹಿಡಿಯುವಿಕೆ ಅಲ್ಲ, ಅಳಿಸುವಿಕೆ.
ಇದು ಇನ್ನೂ ಜಾಲಬಂಧದ ಯಂತ್ರ, ಆದ್ದರಿಂದ ಅದರ ಪ್ರವೇಶವನ್ನು ಸೀಮಿತಗೊಳಿಸಿ ಮತ್ತು ಸಾಮಾನ್ಯ ಬ್ರೌಸಿಂಗ್ನಿಂದ ದೂರವಿರಿಸಿ. ನಿರ್ವಹಣಾ ವೆಚ್ಚ ಎಂದರೆ ಪ್ಯಾಚ್ ಮಾಡಬೇಕಾದ ಇನ್ನೊಂದು ಇಮೇಜ್, ಅದು ನಿಜವಾದರೂ ಸೀಮಿತ ಮತ್ತು ಗೋಚರ, ಲ್ಯಾಪ್ಟಾಪ್ನಲ್ಲಿ ಮರೆತ LEGACY ಧ್ವಜದಂತೆ ಅಲ್ಲ.
ಹೋಲಿಕೆ ನಿಮಗೆ ಏನು ಬಿಡುತ್ತದೆ
ಮೂರು ಪ್ರಶ್ನೆಗಳ ಮೇಲೆ ಆಯ್ಕೆ ಮಾಡಿ: ಹಳೆಯ ಪ್ರೋಟೋಕಾಲ್ ಯಾರಿಗೆ ಬೇಕು, ಎಷ್ಟು ಕಾಲ, ಮತ್ತು ವಿನಾಯಿತಿ ತನ್ನ ಕಾರಣವನ್ನು ಮೀರಿ ಬದುಕಿದರೆ ಯಾರು ಗಮನಿಸುತ್ತಾರೆ. ಒಂದು ಆ್ಯಪ್, ಒಬ್ಬ ವ್ಯಕ್ತಿ, ಕೆಲವು ದಿನಗಳು ಪ್ರತಿ ಪ್ರಕ್ರಿಯೆ ಸಂರಚನೆಯನ್ನು ಸೂಚಿಸುತ್ತವೆ. ಒಂದು ಸಾಧನದ ಹಿಂದಿನ ಇಡೀ ತಂಡ ಗೇಟ್ವೇಯನ್ನೇ ಸೂಚಿಸುತ್ತದೆ. ಹೋಸ್ಟ್ನಲ್ಲಿ ಶಾಶ್ವತ LEGACY ನೀತಿ ಬೇಕಾಗುವ ಯಾವುದೂ ತಾಂತ್ರಿಕ ಉಡುಪಿನಲ್ಲಿರುವ ಖರೀದಿ ನಿರ್ಧಾರ.
ಬಾಳಿಕೆ ಬರುವ ಪರಿಹಾರ ಸಾಧನದ್ದು: TLS 1.2 ಅಥವಾ ಹೊಸದು, ಕನಿಷ್ಠ 2048 ಬಿಟ್ ಗುಂಪು, AEAD ಸೈಫರ್, ಮತ್ತು ಆಧುನಿಕ ಸಹಿಯ ಪ್ರಮಾಣಪತ್ರ. ಆ ಬದಲಾವಣೆಯನ್ನು ಸಾಧನದ ಮಾಲೀಕರನ್ನು ಕೇಳಿ, ನಂತರ ಕ್ಲಯಂಟ್ ಲಾಗ್ನಲ್ಲಿ ಸಮಾಲೋಚಿಸಿದ ಆವೃತ್ತಿ ಮತ್ತು ಸೈಫರ್ ಖಚಿತಪಡಿಸಿ. ವಿನಾಯಿತಿಯನ್ನು ಹೋಸ್ಟ್, ಗೇಟ್ವೇ, ಸಮಾಲೋಚಿಸಿದ ಪ್ರೋಟೋಕಾಲ್, ಅನುಮೋದಿಸಿದವರು ಮತ್ತು ಮುಕ್ತಾಯ ದಿನಾಂಕದೊಂದಿಗೆ ಬರೆಯಿರಿ, ಏಕೆಂದರೆ ತಾತ್ಕಾಲಿಕ ಪರಿಹಾರ ಡೀಫಾಲ್ಟ್ ಆಗುವುದನ್ನು ತಡೆಯುವುದು ಆ ಟಿಪ್ಪಣಿಯೇ.