ಆ ದುರ್ಬಲತೆಯ ಸಂಶೋಧನೆ ಯಾವ VPN ಪ್ರಕ್ರಿಯೆಗೆ ಸಂಬಂಧಿಸಿದೆ?

ಸ್ಕ್ಯಾನರ್ ಫಲಿತಾಂಶವು ಒಂದು ವಿಳಾಸ, ಒಂದು ಪೋರ್ಟ್ ಮತ್ತು ಅಲ್ಲಿ ಮಾತುಕತೆ ನಡೆದ ಯಾವುದನ್ನೋ ಹೆಸರಿಸುತ್ತದೆ. ಅದು ಆ ಸಾಕೆಟ್‌ನ ಹಿಂದಿನ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಹೆಸರಿಸುವುದಿಲ್ಲ, ಮತ್ತು VPN ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಹಲವು ಪ್ರಕ್ರಿಯೆಗಳು ಯಂತ್ರವನ್ನು ಹಂಚಿಕೊಳ್ಳಬಹುದು ಆದರೆ ಅವುಗಳಲ್ಲಿ ಒಂದೇ ಸುರಂಗವಾಗಿರುತ್ತದೆ. ಪಾರ್ಶ್ವ ಸಾಧನದಿಂದ ಆವೃತ್ತಿ ಸ್ಟ್ರಿಂಗ್ ಓದುವುದು ಅಥವಾ ಡಿಸ್ಕ್‌ನಲ್ಲಿ ಲೈಬ್ರರಿ ಫೈಲ್ ಕಂಡುಹಿಡಿಯುವುದು ಹೋಸ್ಟ್ ಬಗ್ಗೆ ಸಾಕ್ಷ್ಯ ಸೇರಿಸುತ್ತದೆ, ಆಲಿಸುವವರ ಬಗ್ಗೆ ಅಲ್ಲ. ಸಂಶೋಧನೆಯು ಒಂದು ಚಾಲನೆಯಲ್ಲಿರುವ ಘಟಕಕ್ಕೆ ಜೋಡಿಸಲ್ಪಟ್ಟು ನಂತರ ಸಲಹೆಯು ನಿಜವಾಗಿ ಹೇಳುವ ವ್ಯಾಪ್ತಿಗೆ ಹೊಂದಿಸಿದಾಗ ಮಾತ್ರ ಕ್ರಿಯಾಶೀಲವಾಗುತ್ತದೆ.

ಕ್ರಮ ಮುಖ್ಯ: ಮೊದಲು ಘಟಕ, ಎರಡನೆಯದು ಸಲಹೆ, ಮೂರನೆಯದು ಪರಿಹಾರ.

ವರದಿ ಪೋರ್ಟ್ ಹೆಸರಿಸುತ್ತದೆ, ಪ್ರೋಗ್ರಾಂ ಅಲ್ಲ

ನಿಜವಾಗಿ ಮೌಲ್ಯಮಾಪನ ಮಾಡಿದ ಅಂತ್ಯಬಿಂದುವಿನಿಂದ ಪ್ರಾರಂಭಿಸಿ. HTTPS ಆಡಳಿತ ಪೋರ್ಟ್ ವಿರುದ್ಧದ ಪರೀಕ್ಷೆ ವೆಬ್ ಸೇವೆ, ಅದರ TLS ಸ್ಟ್ಯಾಕ್ ಮತ್ತು ಅದರ ಮುಂದೆ ಇರುವ ಯಾವುದೇ ಪ್ರಾಕ್ಸಿಯನ್ನು ಅಳೆಯಿತು; ಬೇರೆ ಪೋರ್ಟ್‌ನಲ್ಲಿರುವ OpenVPN ಅಥವಾ WireGuard ಆಲಿಸುವವರ ಬಗ್ಗೆ ಅದು ಏನನ್ನೂ ಕಲಿಯಲಿಲ್ಲ. ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿಗಳು ಮತ್ತು ನಿರ್ವಹಣಾ ಏಜೆಂಟ್‌ಗಳು ಇದನ್ನು ಇನ್ನಷ್ಟು ಕೆಡಿಸುತ್ತವೆ, ಏಕೆಂದರೆ ಪ್ರಮಾಣಪತ್ರ ಮತ್ತು ಬ್ಯಾನರ್ ಮುಂಭಾಗಕ್ಕೆ ಸೇರಿರಬಹುದು ಆದರೆ ದುರ್ಬಲ ಲೈಬ್ರರಿ ಅದರ ಹಿಂದೆ ಹಿನ್ನೆಲೆ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಇರುತ್ತದೆ.

ಫಲಿತಾಂಶದೊಂದಿಗೆ ಗಮ್ಯಸ್ಥಾನ, ಸಾಗಣೆ, ಪೋರ್ಟ್ ಮತ್ತು ಸೇವೆಯ ಹೆಸರನ್ನು ದಾಖಲಿಸಿ, ಇದರಿಂದ ವ್ಯಾಪ್ತಿಯು ಸಂಶೋಧನೆಯೊಂದಿಗೆ ಚಲಿಸುತ್ತದೆ.

ಚಾಲನೆಯಲ್ಲಿರುವ ಬಿಲ್ಡ್ ವಾಸ್ತವವಾಗಿ ಏನು

ಸಾಮಾನ್ಯ ಉದ್ದೇಶದ ಹೋಸ್ಟ್‌ನಲ್ಲಿ, ಸ್ಥಾಪಿತ ಪ್ಯಾಕೇಜ್ ಮತ್ತು ಲೋಡ್ ಆದ ಲೈಬ್ರರಿ ಬೇರೆ ಬೇರೆ ಪ್ರಶ್ನೆಗಳು. ಪ್ಯಾಕೇಜ್ ಡೇಟಾಬೇಸ್ ಪ್ಯಾಚ್ ಮಾಡಿದ ಆವೃತ್ತಿಯನ್ನು ಪಟ್ಟಿ ಮಾಡಬಹುದು ಆದರೆ ದೀರ್ಘಕಾಲ ಚಾಲನೆಯಲ್ಲಿರುವ ಡೀಮನ್ ಇನ್ನೂ ಹಳೆಯ ಹಂಚಿಕೆಯ ವಸ್ತುವನ್ನು ಮೆಮೊರಿಯಲ್ಲಿ ಇಟ್ಟುಕೊಂಡಿರುತ್ತದೆ, ಮತ್ತು ಬಂಡಲ್ ಮಾಡಿದ ಸಾಧನ ಇಮೇಜ್ ತನ್ನದೇ ಲೈಬ್ರರಿಗಳನ್ನು ಹೊಂದಿರಬಹುದು, ಅವನ್ನು ಯಾವುದೇ ಪ್ಯಾಕೇಜ್ ನಿರ್ವಾಹಕ ವರದಿ ಮಾಡುವುದಿಲ್ಲ. ಸೇವಾ ನಿರ್ವಾಹಕರನ್ನು ಏನು ಚಾಲನೆಯಲ್ಲಿದೆ ಎಂದು ಕೇಳಿ, ನಂತರ ಪ್ರಕ್ರಿಯೆ ಮತ್ತು ಅದರ ಸಂಪರ್ಕಗಳನ್ನು ಪರಿಶೀಲಿಸಿ.

systemctl status openvpn-server@server --no-pager
ps -o pid,lstart,args -C openvpn
ss -lntup | grep -E '1194|443'
dpkg -l | grep -i -E 'openvpn|libssl'
ldd "$(command -v openvpn)" | grep -i ssl

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

ಬಿಲ್ಡ್ ಅನ್ನು ಸಲಹೆಯ ವ್ಯಾಪ್ತಿಗೆ ಹೊಂದಿಸುವುದು

ಸಲಹೆಗಳು ಉತ್ಪನ್ನಗಳು, ಆವೃತ್ತಿಗಳು ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ಅಗತ್ಯವಿರುವ ಷರತ್ತುಗಳನ್ನು ವಿವರಿಸುತ್ತವೆ, ಮತ್ತು ಆ ಮೂರು ಕ್ಷೇತ್ರಗಳು ಯಾವಾಗಲೂ ಪ್ಯಾಕೇಜ್ ಆವೃತ್ತಿಗೆ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ. OpenVPNನ ಏಪ್ರಿಲ್ 2014ರ Heartbleed ಸಲಹೆ ಉಪಯುಕ್ತ ಐತಿಹಾಸಿಕ ಉದಾಹರಣೆ, ಏಕೆಂದರೆ ಅದು ಪರಿಣಾಮಿತ Access Server ಬಿಡುಗಡೆಗಳನ್ನು ಬೇರೆ ಒಡ್ಡಿಕೆ ಹೊಂದಿದ್ದ ವೆಬ್ ಸೇವೆಗಳು ಮತ್ತು VPN ಡೀಮನ್‌ಗಳಿಂದ ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ. ಪಾಠವೆಂದರೆ OpenSSL ಪದವನ್ನು ಮಾದರಿ-ಹೊಂದಿಸುವ ಬದಲು ಪಠ್ಯ ಯಾವ ಘಟಕವನ್ನು ಆವರಿಸುತ್ತದೆ ಎಂದು ಓದುವುದು.

ಆ ಸಲಹೆಯೂ ಹಳೆಯದು. ಅದರ ಪ್ಯಾಚ್ ಮಾಡಿದ ಬಿಡುಗಡೆ ಸಂಖ್ಯೆಗಳು ಈಗ ಸ್ಥಾಪನೆ ಸಲಹೆಯಲ್ಲ, ಮತ್ತು 2014ರಲ್ಲಿ ಸರಿಪಡಿಸಿದ ದೋಷವು ಇಂದು ನೀವು ಚಲಾಯಿಸುವ ಶಾಖೆಯ ನಂತರದ ಸಮಸ್ಯೆಗಳ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.

ಭಿನ್ನಾಭಿಪ್ರಾಯ ಬಗೆಹರಿಸಿ, ನಂತರ ಒಡ್ಡಿಕೆ ಮುಚ್ಚಿ

ದಾಸ್ತಾನು ಮತ್ತು ಮೌಲ್ಯಮಾಪನ ಒಪ್ಪದಿದ್ದಾಗ, ಎರಡೂ ಒಂದೇ ಅಂತ್ಯಬಿಂದು ಮತ್ತು ಒಂದೇ ರನ್‌ಟೈಮ್ ವಿವರಿಸುತ್ತವೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ: ಬೇರೆ ವಿಳಾಸ, ಮುಂಭಾಗದ ಪ್ರಾಕ್ಸಿ, ಎರಡನೇ ಸೇವೆ, ಪೋರ್ಟ್‌ಗೆ ಇನ್ನೂ ಬದ್ಧವಾಗಿರುವ ಹಳೆಯ ಪ್ರಕ್ರಿಯೆ, ಅಥವಾ ಪ್ಯಾಕೇಜ್ ನಿರ್ವಾಹಕ ಎಂದೂ ನೋಡದ ಬಂಡಲ್ ಲೈಬ್ರರಿ. ವರದಿ ಮತ್ತೆ ಬರೆಯುವ ಮೊದಲು ಗಡಿಯಲ್ಲಿ ಅದನ್ನು ಬಗೆಹರಿಸಿ.

ಬೆಂಬಲಿತ ತಿದ್ದುಪಡಿಯನ್ನು ಅನ್ವಯಿಸಿ, ಪರಿಣಾಮಿತ ಸೇವೆಯನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿ ಮತ್ತು ಹೊಸ ಬಿಲ್ಡ್ ಈಗ ಚಾಲನೆಯಲ್ಲಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. ಡಿಸ್ಕ್‌ನಲ್ಲಿ ಪ್ಯಾಚ್ ಮಾಡಿದ ಫೈಲ್ ಇದ್ದು ಹಳೆಯ ಪ್ರಕ್ರಿಯೆ ಇನ್ನೂ ಸಂಚಾರ ಸೇವೆ ಮಾಡುತ್ತಿದ್ದರೆ ಅದು ಪರಿಹಾರವಲ್ಲ.

ನಂತರ ಒಡ್ಡಿಕೆ ಅವಧಿಯಲ್ಲಿ ಘಟಕವು ಹೊಂದಿರಬಹುದಾದದ್ದನ್ನು ನಿಭಾಯಿಸಿ. ಪ್ಯಾಚಿಂಗ್ ಮತ್ತು ರುಜುವಾತುಗಳ ಬದಲಾವಣೆ ಬೇರೆ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತವೆ, ಮತ್ತು ಪರಿಣಾಮಿತ ಹೋಸ್ಟ್‌ನ ಸಮೀಪ ಸಂಗ್ರಹಿಸಿದ ಪ್ರಮಾಣಪತ್ರವು ಸ್ವತಃ ಸೋರಿಕೆಯಾದದ್ದರ ಪಟ್ಟಿಯಲ್ಲ. ರದ್ದತಿ, ಅವಧಿಗಳ ತೆಗೆದುಹಾಕುವಿಕೆ ಮತ್ತು ಕ್ಲೈಂಟ್ ನವೀಕರಣಗಳಿಗಾಗಿ ಘಟನೆಯ ಮಾಲೀಕರ ಕಾರ್ಯವಿಧಾನವನ್ನು ಅನುಸರಿಸಿ, ಮತ್ತು ಯಾವ ಘಟಕ ಪರಿಣಾಮಿತವಾಯಿತು, ಸಾಕ್ಷ್ಯ ಏಕೆ ಅನ್ವಯಿಸಿತು ಮತ್ತು ಯಾವುದು ಅದನ್ನು ಮುಚ್ಚಿತು ಎಂದು ದಾಖಲಿಸಿ. ಆ ದಾಖಲೆಯನ್ನೇ ನಂತರದ ಪರಿಶೀಲನೆ ಓದುತ್ತದೆ.