ಟಿಎಲ್; ಡಿಆರ್. ಈ ಲೇಖನದಲ್ಲಿ, ಐದು ಜನಪ್ರಿಯ ಲಿನಕ್ಸ್ ವಿತರಣೆಗಳಲ್ಲಿ ಬಾಕ್ಸ್‌ನ ಹೊರಗೆ ಕೆಲಸ ಮಾಡುವ ಗಟ್ಟಿಯಾಗಿಸುವ ಯೋಜನೆಗಳನ್ನು ನಾವು ಅನ್ವೇಷಿಸುತ್ತೇವೆ. ಪ್ರತಿಯೊಂದಕ್ಕೂ, ನಾವು ಡೀಫಾಲ್ಟ್ ಕರ್ನಲ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ತೆಗೆದುಕೊಂಡಿದ್ದೇವೆ, ಎಲ್ಲಾ ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ಲೋಡ್ ಮಾಡಿದ್ದೇವೆ ಮತ್ತು ಲಗತ್ತಿಸಲಾದ ಬೈನರಿಗಳಲ್ಲಿನ ಭದ್ರತಾ ಯೋಜನೆಗಳನ್ನು ವಿಶ್ಲೇಷಿಸಿದ್ದೇವೆ. ಪರಿಗಣಿಸಲಾದ ವಿತರಣೆಗಳು OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 ಮತ್ತು 7, ಹಾಗೆಯೇ ಉಬುಂಟು 14.04, 12.04 ಮತ್ತು 18.04 LTS.

ಸ್ಟ್ಯಾಕಿಂಗ್ ಕ್ಯಾನರಿಗಳು ಮತ್ತು ಸ್ಥಾನ-ಸ್ವತಂತ್ರ ಕೋಡ್‌ನಂತಹ ಮೂಲಭೂತ ಯೋಜನೆಗಳನ್ನು ಸಹ ಎಲ್ಲರೂ ಇನ್ನೂ ಅಳವಡಿಸಿಕೊಂಡಿಲ್ಲ ಎಂದು ಫಲಿತಾಂಶಗಳು ಖಚಿತಪಡಿಸುತ್ತವೆ. ಸ್ಟಾಕ್ ಕ್ಲಾಷ್‌ನಂತಹ ದುರ್ಬಲತೆಗಳ ವಿರುದ್ಧ ರಕ್ಷಿಸಲು ಬಂದಾಗ ಕಂಪೈಲರ್‌ಗಳಿಗೆ ಪರಿಸ್ಥಿತಿ ಇನ್ನೂ ಕೆಟ್ಟದಾಗಿದೆ, ಇದು ಪ್ರಕಟಣೆಯ ನಂತರ ಜನವರಿಯಲ್ಲಿ ಗಮನಕ್ಕೆ ಬಂದಿತು systemd ದುರ್ಬಲತೆಗಳ ಬಗ್ಗೆ ಮಾಹಿತಿ. ಆದರೆ ಎಲ್ಲವೂ ತುಂಬಾ ಹತಾಶವಾಗಿಲ್ಲ. ಗಮನಾರ್ಹ ಸಂಖ್ಯೆಯ ಬೈನರಿಗಳು ಮೂಲಭೂತ ರಕ್ಷಣೆ ವಿಧಾನಗಳನ್ನು ಅಳವಡಿಸುತ್ತವೆ ಮತ್ತು ಅವುಗಳ ಸಂಖ್ಯೆಯು ಆವೃತ್ತಿಯಿಂದ ಆವೃತ್ತಿಗೆ ಬೆಳೆಯುತ್ತದೆ.

OS ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಮಟ್ಟಗಳಲ್ಲಿ ಉಬುಂಟು 18.04 ನಲ್ಲಿ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ರಕ್ಷಣೆ ವಿಧಾನಗಳನ್ನು ಅಳವಡಿಸಲಾಗಿದೆ ಎಂದು ವಿಮರ್ಶೆಯು ತೋರಿಸಿದೆ, ನಂತರ Debian 9. ಮತ್ತೊಂದೆಡೆ, OpenSUSE 12.4, CentOS 7 ಮತ್ತು RHEL 7 ಸಹ ಮೂಲಭೂತ ರಕ್ಷಣೆ ಯೋಜನೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತವೆ ಮತ್ತು ಘರ್ಷಣೆ ರಕ್ಷಣೆಯನ್ನು ಜೋಡಿಸುತ್ತವೆ. ಹೆಚ್ಚು ದಟ್ಟವಾದ ಡೀಫಾಲ್ಟ್ ಪ್ಯಾಕೇಜುಗಳೊಂದಿಗೆ ಹೆಚ್ಚು ವ್ಯಾಪಕವಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ.

ಪರಿಚಯ

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

ಪ್ರೋಗ್ರಾಂಗಳನ್ನು ರಕ್ಷಿಸುವ ಅಥವಾ ಗಟ್ಟಿಯಾಗಿಸುವ ವಿಧಾನಗಳು ಇಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ನಾವು ಕೆಲವು ರೀತಿಯ ದೋಷಗಳನ್ನು ತಡೆಯಲು ಸಾಧ್ಯವಿಲ್ಲ, ಆದರೆ ನಾವು ಆಕ್ರಮಣಕಾರರ ಜೀವನವನ್ನು ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಗಿಸಬಹುದು ಮತ್ತು ತಡೆಗಟ್ಟುವ ಅಥವಾ ತಡೆಗಟ್ಟುವ ಮೂಲಕ ಸಮಸ್ಯೆಯನ್ನು ಭಾಗಶಃ ಪರಿಹರಿಸಬಹುದು ಶೋಷಣೆ ಈ ದೋಷಗಳು. ಅಂತಹ ರಕ್ಷಣೆಯನ್ನು ಎಲ್ಲಾ ಆಧುನಿಕ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂಗಳಲ್ಲಿ ಬಳಸಲಾಗುತ್ತದೆ, ಆದರೆ ವಿಧಾನಗಳು ಸಂಕೀರ್ಣತೆ, ದಕ್ಷತೆ ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆಯಲ್ಲಿ ಹೆಚ್ಚು ಭಿನ್ನವಾಗಿರುತ್ತವೆ: ಸ್ಟಾಕ್ ಕ್ಯಾನರಿಗಳಿಂದ ಮತ್ತು ASLR ಸಂಪೂರ್ಣ ರಕ್ಷಣೆಗೆ ಸಿಎಫ್ಐ и ಆರ್ಒಪಿ. ಈ ಲೇಖನದಲ್ಲಿ, ಡೀಫಾಲ್ಟ್ ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ ಹೆಚ್ಚು ಜನಪ್ರಿಯವಾದ ಲಿನಕ್ಸ್ ವಿತರಣೆಗಳಲ್ಲಿ ಯಾವ ರಕ್ಷಣೆ ವಿಧಾನಗಳನ್ನು ಬಳಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ನಾವು ನೋಡುತ್ತೇವೆ ಮತ್ತು ಪ್ರತಿ ವಿತರಣೆಯ ಪ್ಯಾಕೇಜ್ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಗಳ ಮೂಲಕ ವಿತರಿಸಲಾದ ಬೈನರಿಗಳ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಸಹ ಪರಿಶೀಲಿಸುತ್ತೇವೆ.

CVE ಮತ್ತು ಭದ್ರತೆ

ನಾವೆಲ್ಲರೂ "ವರ್ಷದ ಅತ್ಯಂತ ದುರ್ಬಲ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು" ಅಥವಾ "ಅತ್ಯಂತ ದುರ್ಬಲ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳು" ನಂತಹ ಶೀರ್ಷಿಕೆಗಳೊಂದಿಗೆ ಲೇಖನಗಳನ್ನು ನೋಡಿದ್ದೇವೆ. ಸಾಮಾನ್ಯವಾಗಿ ಅವರು ದುರ್ಬಲತೆಗಳ ಬಗ್ಗೆ ಒಟ್ಟು ಸಂಖ್ಯೆಯ ದಾಖಲೆಗಳ ಅಂಕಿಅಂಶಗಳನ್ನು ಒದಗಿಸುತ್ತಾರೆ CVE (ಸಾಮಾನ್ಯ ದುರ್ಬಲತೆ ಮತ್ತು ಮಾನ್ಯತೆಗಳು), ನಿಂದ ಪಡೆಯಲಾಗಿದೆ ರಾಷ್ಟ್ರೀಯ ದುರ್ಬಲತೆ ಡೇಟಾಬೇಸ್ (NVD) ರಿಂದ ಎನ್ಐಎಸ್ಟಿ ಮತ್ತು ಇತರ ಮೂಲಗಳು. ತರುವಾಯ, ಈ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಅಥವಾ OS ಅನ್ನು CVE ಗಳ ಸಂಖ್ಯೆಯಿಂದ ಶ್ರೇಣೀಕರಿಸಲಾಗುತ್ತದೆ. ದುರದೃಷ್ಟವಶಾತ್, ಸಮಸ್ಯೆಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಮತ್ತು ಮಾರಾಟಗಾರರು ಮತ್ತು ಬಳಕೆದಾರರಿಗೆ ತಿಳಿಸಲು CVE ಗಳು ತುಂಬಾ ಉಪಯುಕ್ತವಾಗಿದ್ದರೂ, ಅವರು ಸಾಫ್ಟ್‌ವೇರ್‌ನ ನಿಜವಾದ ಭದ್ರತೆಯ ಬಗ್ಗೆ ಸ್ವಲ್ಪವೇ ಹೇಳುತ್ತಾರೆ.

ಉದಾಹರಣೆಯಾಗಿ, Linux ಕರ್ನಲ್‌ಗಾಗಿ ಕಳೆದ ನಾಲ್ಕು ವರ್ಷಗಳಲ್ಲಿ CVEಗಳ ಒಟ್ಟು ಸಂಖ್ಯೆಯನ್ನು ಪರಿಗಣಿಸಿ ಮತ್ತು ಐದು ಅತ್ಯಂತ ಜನಪ್ರಿಯ ಸರ್ವರ್ ವಿತರಣೆಗಳಾದ Ubuntu, Debian, Red Hat Enterprise Linux ಮತ್ತು OpenSUSE.

ಅಂಜೂರ. 1

ಈ ಗ್ರಾಫ್ ನಮಗೆ ಏನು ಹೇಳುತ್ತದೆ? ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ CVE ಗಳು ಒಂದು ವಿತರಣೆಯು ಇನ್ನೊಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ದುರ್ಬಲವಾಗಿದೆ ಎಂದು ಅರ್ಥವೇ? ಉತ್ತರ ಇಲ್ಲ. ಉದಾಹರಣೆಗೆ, OpenSUSE ಅಥವಾ RedHat Linux ಗೆ ಹೋಲಿಸಿದರೆ ಡೆಬಿಯನ್ ಬಲವಾದ ಭದ್ರತಾ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಹೊಂದಿದೆ ಎಂದು ಈ ಲೇಖನದಲ್ಲಿ ನೀವು ನೋಡುತ್ತೀರಿ ಮತ್ತು ಇನ್ನೂ ಡೆಬಿಯನ್ ಹೆಚ್ಚು CVE ಗಳನ್ನು ಹೊಂದಿದೆ. ಆದಾಗ್ಯೂ, ಅವುಗಳು ದುರ್ಬಲವಾದ ಭದ್ರತೆಯನ್ನು ಅರ್ಥೈಸುವುದಿಲ್ಲ: CVE ಯ ಉಪಸ್ಥಿತಿಯು ಸಹ ದುರ್ಬಲತೆಯನ್ನು ಸೂಚಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಸೂಚಿಸುವುದಿಲ್ಲ. ಶೋಷಣೆ ಮಾಡಲಾಗಿದೆ. ತೀವ್ರತೆಯ ಅಂಕಗಳು ಹೇಗೆ ಎಂಬುದರ ಸೂಚನೆಯನ್ನು ನೀಡುತ್ತವೆ ಬಹುಶಃ ದುರ್ಬಲತೆಯ ಶೋಷಣೆ, ಆದರೆ ಅಂತಿಮವಾಗಿ ಶೋಷಣೆಯು ಪೀಡಿತ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಇರುವ ರಕ್ಷಣೆಗಳು ಮತ್ತು ಆಕ್ರಮಣಕಾರರ ಸಂಪನ್ಮೂಲಗಳು ಮತ್ತು ಸಾಮರ್ಥ್ಯಗಳ ಮೇಲೆ ಹೆಚ್ಚು ಅವಲಂಬಿತವಾಗಿದೆ. ಇದಲ್ಲದೆ, CVE ವರದಿಗಳ ಅನುಪಸ್ಥಿತಿಯು ಇತರರ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ ನೋಂದಾಯಿಸದ ಅಥವಾ ತಿಳಿದಿಲ್ಲ ದುರ್ಬಲತೆಗಳು. CVE ಯಲ್ಲಿನ ವ್ಯತ್ಯಾಸವು ಸಾಫ್ಟ್‌ವೇರ್ ಗುಣಮಟ್ಟವನ್ನು ಹೊರತುಪಡಿಸಿ ಇತರ ಅಂಶಗಳ ಕಾರಣದಿಂದಾಗಿರಬಹುದು, ಪರೀಕ್ಷೆಗೆ ನಿಯೋಜಿಸಲಾದ ಸಂಪನ್ಮೂಲಗಳು ಅಥವಾ ಬಳಕೆದಾರರ ಬೇಸ್‌ನ ಗಾತ್ರವೂ ಸೇರಿದೆ. ನಮ್ಮ ಉದಾಹರಣೆಯಲ್ಲಿ, ಡೆಬಿಯನ್‌ನ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ CVE ಗಳು ಡೆಬಿಯನ್ ಹೆಚ್ಚು ಸಾಫ್ಟ್‌ವೇರ್ ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ರವಾನಿಸುತ್ತದೆ ಎಂದು ಸರಳವಾಗಿ ಸೂಚಿಸಬಹುದು.

ಸಹಜವಾಗಿ, CVE ವ್ಯವಸ್ಥೆಯು ನಿಮಗೆ ಸೂಕ್ತವಾದ ರಕ್ಷಣೆಗಳನ್ನು ರಚಿಸಲು ಅನುಮತಿಸುವ ಉಪಯುಕ್ತ ಮಾಹಿತಿಯನ್ನು ಒದಗಿಸುತ್ತದೆ. ಪ್ರೋಗ್ರಾಂ ವೈಫಲ್ಯದ ಕಾರಣಗಳನ್ನು ನಾವು ಉತ್ತಮವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತೇವೆ, ಶೋಷಣೆಯ ಸಂಭವನೀಯ ವಿಧಾನಗಳನ್ನು ಗುರುತಿಸುವುದು ಮತ್ತು ಸೂಕ್ತವಾದ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವುದು ಸುಲಭವಾಗಿದೆ ಪತ್ತೆ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆ. ಅಂಜೂರದಲ್ಲಿ. 2 ಕಳೆದ ನಾಲ್ಕು ವರ್ಷಗಳಲ್ಲಿ ಎಲ್ಲಾ ವಿತರಣೆಗಳಿಗೆ ದುರ್ಬಲತೆಗಳ ವರ್ಗಗಳನ್ನು ತೋರಿಸುತ್ತದೆ (ಮೂಲ) ಹೆಚ್ಚಿನ CVE ಗಳು ಈ ಕೆಳಗಿನ ವರ್ಗಗಳಿಗೆ ಸೇರುತ್ತವೆ ಎಂಬುದು ತಕ್ಷಣವೇ ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ: ಸೇವೆಯ ನಿರಾಕರಣೆ (DoS), ಕೋಡ್ ಎಕ್ಸಿಕ್ಯೂಶನ್, ಓವರ್‌ಫ್ಲೋ, ಮೆಮೊರಿ ಭ್ರಷ್ಟಾಚಾರ, ಮಾಹಿತಿ ಸೋರಿಕೆ (ಹೊರಹಾಕುವಿಕೆ) ಮತ್ತು ಸವಲತ್ತು ಹೆಚ್ಚಳ. ಅನೇಕ CVE ಗಳನ್ನು ವಿವಿಧ ವರ್ಗಗಳಲ್ಲಿ ಹಲವಾರು ಬಾರಿ ಎಣಿಸಲಾಗುತ್ತದೆಯಾದರೂ, ಸಾಮಾನ್ಯವಾಗಿ ಅದೇ ಸಮಸ್ಯೆಗಳು ವರ್ಷದಿಂದ ವರ್ಷಕ್ಕೆ ಮುಂದುವರಿಯುತ್ತವೆ. ಲೇಖನದ ಮುಂದಿನ ಭಾಗದಲ್ಲಿ, ಈ ದುರ್ಬಲತೆಗಳ ಶೋಷಣೆಯನ್ನು ತಡೆಗಟ್ಟಲು ವಿವಿಧ ರಕ್ಷಣಾ ಯೋಜನೆಗಳ ಬಳಕೆಯನ್ನು ನಾವು ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತೇವೆ.

ಅಂಜೂರ. 2

ಕಾರ್ಯಗಳನ್ನು

ಈ ಲೇಖನದಲ್ಲಿ ನಾವು ಈ ಕೆಳಗಿನ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸಲು ಉದ್ದೇಶಿಸಿದ್ದೇವೆ:

• ವಿವಿಧ ಲಿನಕ್ಸ್ ವಿತರಣೆಗಳ ಭದ್ರತೆ ಏನು? ಕರ್ನಲ್ ಮತ್ತು ಯೂಸರ್ ಸ್ಪೇಸ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ ಯಾವ ರಕ್ಷಣಾ ಕಾರ್ಯವಿಧಾನಗಳು ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ?
• ವಿತರಣೆಗಳಾದ್ಯಂತ ಕಾಲಾನಂತರದಲ್ಲಿ ಭದ್ರತಾ ಕಾರ್ಯವಿಧಾನಗಳ ಅಳವಡಿಕೆಯು ಹೇಗೆ ಬದಲಾಗಿದೆ?
• ಪ್ರತಿ ವಿತರಣೆಗೆ ಪ್ಯಾಕೇಜ್‌ಗಳು ಮತ್ತು ಲೈಬ್ರರಿಗಳ ಸರಾಸರಿ ಅವಲಂಬನೆಗಳು ಯಾವುವು?
• ಪ್ರತಿ ಬೈನರಿಗೆ ಯಾವ ರಕ್ಷಣೆಗಳನ್ನು ಅಳವಡಿಸಲಾಗಿದೆ?

ವಿತರಣೆಗಳ ಆಯ್ಕೆ

ವಿತರಣಾ ಅನುಸ್ಥಾಪನೆಗಳಲ್ಲಿ ನಿಖರವಾದ ಅಂಕಿಅಂಶಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಕಷ್ಟ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ, ಏಕೆಂದರೆ ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ ಡೌನ್‌ಲೋಡ್‌ಗಳ ಸಂಖ್ಯೆಯು ನಿಜವಾದ ಸ್ಥಾಪನೆಗಳ ಸಂಖ್ಯೆಯನ್ನು ಸೂಚಿಸುವುದಿಲ್ಲ. ಆದಾಗ್ಯೂ, Unix ರೂಪಾಂತರಗಳು ಬಹುಪಾಲು ಸರ್ವರ್ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ರೂಪಿಸುತ್ತವೆ (ವೆಬ್ ಸರ್ವರ್‌ಗಳಲ್ಲಿ 69,2%, ಮೂಲಕ ಅಂಕಿಅಂಶಗಳು W3techs ಮತ್ತು ಇತರ ಮೂಲಗಳು), ಮತ್ತು ಅವರ ಪಾಲು ನಿರಂತರವಾಗಿ ಬೆಳೆಯುತ್ತಿದೆ. ಹೀಗಾಗಿ, ನಮ್ಮ ಸಂಶೋಧನೆಗಾಗಿ ನಾವು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿ ಬಾಕ್ಸ್‌ನ ಹೊರಗೆ ಲಭ್ಯವಿರುವ ವಿತರಣೆಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸಿದ್ದೇವೆ Google ಮೇಘ. ನಿರ್ದಿಷ್ಟವಾಗಿ, ನಾವು ಈ ಕೆಳಗಿನ OS ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಿದ್ದೇವೆ:

ವಿತರಣೆ/ಆವೃತ್ತಿ
ನ್ಯೂಕ್ಲಿಯಸ್
ನಿರ್ಮಿಸಲು

OpenSUSE 12.4
4.12.14-95.3-ಡೀಫಾಲ್ಟ್
#1 SMP ಬುಧ ಡಿಸೆಂಬರ್ 5 06:00:48 UTC 2018 (63a8d29)

ಡೆಬಿಯನ್ 9 (ಹಿಗ್ಗಿಸುವಿಕೆ)
4.9.0-8-amd64
#1 SMP ಡೆಬಿಯನ್ 4.9.130-2 (2018-10-27)

ಸೆಂಟಿಒಎಸ್ ಕ್ಯುಮ್ಎಕ್ಸ್ಎಕ್ಸ್
2.6.32-754.10.1.el6.x86_64
#1 SMP ಮಂಗಳವಾರ ಜನವರಿ 15 17:07:28 UTC 2019

ಸೆಂಟಿಒಎಸ್ ಕ್ಯುಮ್ಎಕ್ಸ್ಎಕ್ಸ್
3.10.0-957.5.1.el7.x86_64
#1 SMP ಶುಕ್ರ ಫೆಬ್ರವರಿ 1 14:54:57 UTC 2019

Red Hat Enterprise Linux ಸರ್ವರ್ 6.10 (Santiago)
2.6.32-754.9.1.el6.x86_64
#1 SMP ಬುಧವಾರ ನವೆಂಬರ್ 21 15:08:21 EST 2018

Red Hat Enterprise Linux ಸರ್ವರ್ 7.6 (Maipo)
3.10.0-957.1.3.el7.x86_64
#1 SMP ಗುರು ನವೆಂಬರ್ 15 17:36:42 UTC 2018

ಉಬುಂಟು 14.04 (ಟ್ರಸ್ಟಿ ತಹ್ರ್)
4.4.0–140-ಜೆನೆರಿಕ್

#166~14.04.1-ಉಬುಂಟು SMP ಶನಿ ನವೆಂಬರ್ 17 01:52:43 UTC 20…

ಉಬುಂಟು 16.04 (Xenial Xerus)
4.15.0–1026-gcp
#27~16.04.1-ಉಬುಂಟು SMP ಶುಕ್ರ ಡಿಸೆಂಬರ್ 7 09:59:47 UTC 2018

ಉಬುಂಟು 18.04 (ಬಯೋನಿಕ್ ಬೀವರ್)
4.15.0–1026-gcp
#27-ಉಬುಂಟು SMP ಗುರು ಡಿಸೆಂಬರ್ 6 18:27:01 UTC 2018

ಟೇಬಲ್ 1

ಅನಾಲಿಜ

ಡೀಫಾಲ್ಟ್ ಕರ್ನಲ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಅಧ್ಯಯನ ಮಾಡೋಣ, ಹಾಗೆಯೇ ಬಾಕ್ಸ್‌ನ ಹೊರಗೆ ಪ್ರತಿ ವಿತರಣೆಯ ಪ್ಯಾಕೇಜ್ ಮ್ಯಾನೇಜರ್ ಮೂಲಕ ಲಭ್ಯವಿರುವ ಪ್ಯಾಕೇಜ್‌ಗಳ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಅಧ್ಯಯನ ಮಾಡೋಣ. ಹೀಗಾಗಿ, ನಾವು ಪ್ರತಿ ವಿತರಣೆಯ ಡೀಫಾಲ್ಟ್ ಮಿರರ್‌ಗಳಿಂದ ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ಮಾತ್ರ ಪರಿಗಣಿಸುತ್ತೇವೆ, ಅಸ್ಥಿರ ರೆಪೊಸಿಟರಿಗಳಿಂದ ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತೇವೆ (ಉದಾಹರಣೆಗೆ ಡೆಬಿಯನ್ 'ಟೆಸ್ಟಿಂಗ್' ಮಿರರ್‌ಗಳು) ಮತ್ತು ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಪ್ಯಾಕೇಜ್‌ಗಳು (ಉದಾಹರಣೆಗೆ ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಮಿರರ್‌ಗಳಿಂದ ಎನ್ವಿಡಿಯಾ ಪ್ಯಾಕೇಜುಗಳು). ಹೆಚ್ಚುವರಿಯಾಗಿ, ನಾವು ಕಸ್ಟಮ್ ಕರ್ನಲ್ ಸಂಕಲನಗಳು ಅಥವಾ ಭದ್ರತೆ-ಗಟ್ಟಿಯಾದ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳನ್ನು ಪರಿಗಣಿಸುವುದಿಲ್ಲ.

ಕರ್ನಲ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅನಾಲಿಸಿಸ್

ನಾವು ಆಧರಿಸಿ ವಿಶ್ಲೇಷಣೆ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಅನ್ವಯಿಸಿದ್ದೇವೆ ಉಚಿತ kconfig ಪರೀಕ್ಷಕ. ಹೆಸರಿಸಲಾದ ವಿತರಣೆಗಳ ಬಾಕ್ಸ್‌ನ ಹೊರಗಿನ ರಕ್ಷಣೆಯ ನಿಯತಾಂಕಗಳನ್ನು ನೋಡೋಣ ಮತ್ತು ಅವುಗಳನ್ನು ಪಟ್ಟಿಯೊಂದಿಗೆ ಹೋಲಿಸಿ ನೋಡೋಣ ಕೋರ್ ಸೆಲ್ಫ್ ಡಿಫೆನ್ಸ್ ಪ್ರಾಜೆಕ್ಟ್ (ಕೆಎಸ್ಪಿಪಿ). ಪ್ರತಿ ಕಾನ್ಫಿಗರೇಶನ್ ಆಯ್ಕೆಗೆ, ಟೇಬಲ್ 2 ಬಯಸಿದ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ವಿವರಿಸುತ್ತದೆ: ಚೆಕ್‌ಬಾಕ್ಸ್ KSSP ಶಿಫಾರಸುಗಳನ್ನು ಅನುಸರಿಸುವ ವಿತರಣೆಗಳಿಗಾಗಿ ಆಗಿದೆ (ನಿಯಮಗಳ ವಿವರಣೆಗಾಗಿ ಕೆಳಗಿನದನ್ನು ನೋಡಿ). ಇಲ್ಲಿ; ಮುಂದಿನ ಲೇಖನಗಳಲ್ಲಿ ಈ ಭದ್ರತಾ ವಿಧಾನಗಳು ಎಷ್ಟು ಅಸ್ತಿತ್ವಕ್ಕೆ ಬಂದವು ಮತ್ತು ಅವುಗಳ ಅನುಪಸ್ಥಿತಿಯಲ್ಲಿ ಸಿಸ್ಟಮ್ ಅನ್ನು ಹೇಗೆ ಹ್ಯಾಕ್ ಮಾಡುವುದು ಎಂಬುದನ್ನು ನಾವು ವಿವರಿಸುತ್ತೇವೆ).

ಸಾಮಾನ್ಯವಾಗಿ, ಹೊಸ ಕರ್ನಲ್‌ಗಳು ಬಾಕ್ಸ್‌ನ ಹೊರಗೆ ಕಟ್ಟುನಿಟ್ಟಾದ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಹೊಂದಿವೆ. ಉದಾಹರಣೆಗೆ, 6.10 ಕರ್ನಲ್‌ನಲ್ಲಿರುವ CentOS 6.10 ಮತ್ತು RHEL 2.6.32 ಹೊಸ ಕರ್ನಲ್‌ಗಳಲ್ಲಿ ಅಳವಡಿಸಲಾದ ಹೆಚ್ಚಿನ ನಿರ್ಣಾಯಕ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ. SMAP, ಕಟ್ಟುನಿಟ್ಟಾದ RWX ಅನುಮತಿಗಳು, ವಿಳಾಸ ಯಾದೃಚ್ಛಿಕಗೊಳಿಸುವಿಕೆ ಅಥವಾ copy2usr ರಕ್ಷಣೆ. ಟೇಬಲ್‌ನಲ್ಲಿನ ಹಲವು ಕಾನ್ಫಿಗರೇಶನ್ ಆಯ್ಕೆಗಳು ಕರ್ನಲ್‌ನ ಹಳೆಯ ಆವೃತ್ತಿಗಳಲ್ಲಿ ಲಭ್ಯವಿಲ್ಲ ಮತ್ತು ವಾಸ್ತವದಲ್ಲಿ ಅನ್ವಯಿಸುವುದಿಲ್ಲ ಎಂದು ಗಮನಿಸಬೇಕು - ಇದು ಸರಿಯಾದ ರಕ್ಷಣೆಯ ಕೊರತೆ ಎಂದು ಟೇಬಲ್‌ನಲ್ಲಿ ಇನ್ನೂ ಸೂಚಿಸಲಾಗುತ್ತದೆ. ಅಂತೆಯೇ, ನೀಡಿರುವ ಆವೃತ್ತಿಯಲ್ಲಿ ಕಾನ್ಫಿಗರೇಶನ್ ಆಯ್ಕೆಯು ಇಲ್ಲದಿದ್ದರೆ ಮತ್ತು ಭದ್ರತೆಗೆ ಆ ಆಯ್ಕೆಯನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬೇಕಾದರೆ, ಇದನ್ನು ಸಮಂಜಸವಾದ ಕಾನ್ಫಿಗರೇಶನ್ ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ.

ಫಲಿತಾಂಶಗಳನ್ನು ಅರ್ಥೈಸುವಾಗ ಪರಿಗಣಿಸಬೇಕಾದ ಇನ್ನೊಂದು ಅಂಶವೆಂದರೆ: ದಾಳಿಯ ಮೇಲ್ಮೈಯನ್ನು ಹೆಚ್ಚಿಸುವ ಕೆಲವು ಕರ್ನಲ್ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳನ್ನು ಭದ್ರತೆಗಾಗಿ ಸಹ ಬಳಸಬಹುದು. ಇಂತಹ ಉದಾಹರಣೆಗಳಲ್ಲಿ uprobes ಮತ್ತು kprobes, ಕರ್ನಲ್ ಮಾಡ್ಯೂಲ್‌ಗಳು ಮತ್ತು BPF/eBPF ಸೇರಿವೆ. ಮೇಲಿನ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ನೈಜ ರಕ್ಷಣೆಯನ್ನು ಒದಗಿಸಲು ಬಳಸುವುದು ನಮ್ಮ ಶಿಫಾರಸು, ಏಕೆಂದರೆ ಅವುಗಳು ಬಳಸಲು ಕ್ಷುಲ್ಲಕವಲ್ಲ ಮತ್ತು ದುರುದ್ದೇಶಪೂರಿತ ನಟರು ಈಗಾಗಲೇ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ನೆಲೆಯನ್ನು ಸ್ಥಾಪಿಸಿದ್ದಾರೆ ಎಂದು ಅವರ ಶೋಷಣೆ ಊಹಿಸುತ್ತದೆ. ಆದರೆ ಈ ಆಯ್ಕೆಗಳನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿದರೆ, ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರು ನಿಂದನೆಗಾಗಿ ಸಕ್ರಿಯವಾಗಿ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕು.

ಕೋಷ್ಟಕ 2 ರಲ್ಲಿನ ನಮೂದುಗಳನ್ನು ಮತ್ತಷ್ಟು ನೋಡಿದಾಗ, ಆಧುನಿಕ ಕರ್ನಲ್‌ಗಳು ಮಾಹಿತಿ ಸೋರಿಕೆ ಮತ್ತು ಸ್ಟಾಕ್/ಹೀಪ್ ಓವರ್‌ಫ್ಲೋಗಳಂತಹ ದುರ್ಬಲತೆಗಳ ಶೋಷಣೆಯಿಂದ ರಕ್ಷಿಸಲು ಹಲವಾರು ಆಯ್ಕೆಗಳನ್ನು ಒದಗಿಸುತ್ತವೆ ಎಂದು ನಾವು ನೋಡುತ್ತೇವೆ. ಆದಾಗ್ಯೂ, ಇತ್ತೀಚಿನ ಜನಪ್ರಿಯ ವಿತರಣೆಗಳು ಸಹ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾದ ರಕ್ಷಣೆಯನ್ನು ಇನ್ನೂ ಅಳವಡಿಸಿಲ್ಲ ಎಂದು ನಾವು ಗಮನಿಸುತ್ತೇವೆ (ಉದಾಹರಣೆಗೆ, ಪ್ಯಾಚ್‌ಗಳೊಂದಿಗೆ ಭದ್ರತೆ) ಅಥವಾ ಕೋಡ್ ಮರುಬಳಕೆಯ ದಾಳಿಗಳ ವಿರುದ್ಧ ಆಧುನಿಕ ರಕ್ಷಣೆ (ಉದಾ. ಕೋಡ್‌ಗಾಗಿ R^X ನಂತಹ ಸ್ಕೀಮ್‌ಗಳೊಂದಿಗೆ ಯಾದೃಚ್ಛಿಕತೆಯ ಸಂಯೋಜನೆ) ವಿಷಯಗಳನ್ನು ಇನ್ನಷ್ಟು ಹದಗೆಡಿಸಲು, ಈ ಹೆಚ್ಚು ಸುಧಾರಿತ ರಕ್ಷಣೆಗಳು ಸಹ ಸಂಪೂರ್ಣ ಶ್ರೇಣಿಯ ದಾಳಿಯಿಂದ ರಕ್ಷಿಸುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ, ರನ್‌ಟೈಮ್ ಶೋಷಣೆ ಪತ್ತೆ ಮತ್ತು ತಡೆಗಟ್ಟುವಿಕೆಯನ್ನು ಒದಗಿಸುವ ಪರಿಹಾರಗಳೊಂದಿಗೆ ಸ್ಮಾರ್ಟ್ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳನ್ನು ಪೂರೈಸಲು ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರಿಗೆ ಇದು ನಿರ್ಣಾಯಕವಾಗಿದೆ.

ಅಪ್ಲಿಕೇಶನ್ ವಿಶ್ಲೇಷಣೆ

ವಿಭಿನ್ನ ವಿತರಣೆಗಳು ವಿಭಿನ್ನ ಪ್ಯಾಕೇಜ್ ಗುಣಲಕ್ಷಣಗಳು, ಸಂಕಲನ ಆಯ್ಕೆಗಳು, ಲೈಬ್ರರಿ ಅವಲಂಬನೆಗಳು ಇತ್ಯಾದಿಗಳನ್ನು ಹೊಂದಿವೆ. ಸಂಬಂಧಿಸಿದ ಕಡಿಮೆ ಸಂಖ್ಯೆಯ ಅವಲಂಬನೆಗಳೊಂದಿಗೆ ವಿತರಣೆಗಳು ಮತ್ತು ಪ್ಯಾಕೇಜುಗಳು (ಉದಾಹರಣೆಗೆ, ಉಬುಂಟು ಅಥವಾ ಡೆಬಿಯನ್‌ನಲ್ಲಿನ ಕೋರೆಟಿಲ್ಸ್). ವ್ಯತ್ಯಾಸಗಳನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಲು, ನಾವು ಲಭ್ಯವಿರುವ ಎಲ್ಲಾ ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಿದ್ದೇವೆ, ಅವುಗಳ ವಿಷಯಗಳನ್ನು ಹೊರತೆಗೆಯುತ್ತೇವೆ ಮತ್ತು ಬೈನರಿಗಳು ಮತ್ತು ಅವಲಂಬನೆಗಳನ್ನು ವಿಶ್ಲೇಷಿಸಿದ್ದೇವೆ. ಪ್ರತಿ ಪ್ಯಾಕೇಜಿಗೆ, ಅದು ಅವಲಂಬಿಸಿರುವ ಇತರ ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ನಾವು ಟ್ರ್ಯಾಕ್ ಮಾಡಿದ್ದೇವೆ ಮತ್ತು ಪ್ರತಿ ಬೈನರಿಗಾಗಿ ನಾವು ಅದರ ಅವಲಂಬನೆಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಿದ್ದೇವೆ. ಈ ವಿಭಾಗದಲ್ಲಿ ನಾವು ಸಂಕ್ಷಿಪ್ತವಾಗಿ ತೀರ್ಮಾನಗಳನ್ನು ಸಾರಾಂಶ ಮಾಡುತ್ತೇವೆ.

ವಿತರಣೆಗಳು

ಒಟ್ಟಾರೆಯಾಗಿ, ನಾವು ಎಲ್ಲಾ ವಿತರಣೆಗಳಿಗಾಗಿ 361 ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಿದ್ದೇವೆ, ಡೀಫಾಲ್ಟ್ ಕನ್ನಡಿಗಳಿಂದ ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ಮಾತ್ರ ಹೊರತೆಗೆಯುತ್ತೇವೆ. ಮೂಲಗಳು, ಫಾಂಟ್‌ಗಳು ಇತ್ಯಾದಿಗಳಂತಹ ELF ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ನಾವು ನಿರ್ಲಕ್ಷಿಸಿದ್ದೇವೆ. ಫಿಲ್ಟರ್ ಮಾಡಿದ ನಂತರ, 556 ಪ್ಯಾಕೇಜ್‌ಗಳು ಉಳಿದಿವೆ, ಒಟ್ಟು 129 ಬೈನರಿಗಳನ್ನು ಒಳಗೊಂಡಿದೆ. ವಿತರಣೆಗಳಾದ್ಯಂತ ಪ್ಯಾಕೇಜುಗಳು ಮತ್ತು ಫೈಲ್‌ಗಳ ವಿತರಣೆಯನ್ನು ಅಂಜೂರದಲ್ಲಿ ತೋರಿಸಲಾಗಿದೆ. 569.

ಅಂಜೂರ. 3

ವಿತರಣೆಯು ಹೆಚ್ಚು ಆಧುನಿಕವಾಗಿದೆ ಎಂದು ನೀವು ಗಮನಿಸಬಹುದು, ಅದು ಹೆಚ್ಚು ಪ್ಯಾಕೇಜುಗಳು ಮತ್ತು ಬೈನರಿಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ, ಇದು ತಾರ್ಕಿಕವಾಗಿದೆ. ಆದಾಗ್ಯೂ, ಉಬುಂಟು ಮತ್ತು ಡೆಬಿಯನ್ ಪ್ಯಾಕೇಜುಗಳು CentOS, SUSE ಮತ್ತು RHEL ಗಿಂತ ಹೆಚ್ಚಿನ ಬೈನರಿಗಳನ್ನು (ಎರಡೂ ಕಾರ್ಯಗತಗೊಳಿಸಬಲ್ಲವುಗಳು ಮತ್ತು ಡೈನಾಮಿಕ್ ಮಾಡ್ಯೂಲ್‌ಗಳು ಮತ್ತು ಲೈಬ್ರರಿಗಳು) ಒಳಗೊಂಡಿವೆ, ಇದು ಉಬುಂಟು ಮತ್ತು ಡೆಬಿಯನ್‌ನ ಆಕ್ರಮಣದ ಮೇಲ್ಮೈಯನ್ನು ಸಮರ್ಥವಾಗಿ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ (ಸಂಖ್ಯೆಗಳು ಎಲ್ಲಾ ಆವೃತ್ತಿಗಳ ಎಲ್ಲಾ ಬೈನರಿಗಳನ್ನು ಪ್ರತಿಬಿಂಬಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ಗಮನಿಸಬೇಕು. ಪ್ಯಾಕೇಜ್, ಅಂದರೆ, ಕೆಲವು ಫೈಲ್‌ಗಳನ್ನು ಹಲವಾರು ಬಾರಿ ವಿಶ್ಲೇಷಿಸಲಾಗುತ್ತದೆ). ಪ್ಯಾಕೇಜುಗಳ ನಡುವಿನ ಅವಲಂಬನೆಗಳನ್ನು ನೀವು ಪರಿಗಣಿಸಿದಾಗ ಇದು ಮುಖ್ಯವಾಗಿದೆ. ಹೀಗಾಗಿ, ಒಂದೇ ಪ್ಯಾಕೇಜ್ ಬೈನರಿಯಲ್ಲಿನ ದುರ್ಬಲತೆಯು ಪರಿಸರ ವ್ಯವಸ್ಥೆಯ ಅನೇಕ ಭಾಗಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರಬಹುದು, ದುರ್ಬಲ ಗ್ರಂಥಾಲಯವು ಅದನ್ನು ಆಮದು ಮಾಡಿಕೊಳ್ಳುವ ಎಲ್ಲಾ ಬೈನರಿಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರಬಹುದು. ಆರಂಭಿಕ ಹಂತವಾಗಿ, ವಿಭಿನ್ನ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳಲ್ಲಿನ ಪ್ಯಾಕೇಜುಗಳ ನಡುವೆ ಅವಲಂಬನೆಗಳ ಸಂಖ್ಯೆಯ ವಿತರಣೆಯನ್ನು ನೋಡೋಣ:

ಅಂಜೂರ. 4

ಬಹುತೇಕ ಎಲ್ಲಾ ವಿತರಣೆಗಳಲ್ಲಿ, 60% ಪ್ಯಾಕೇಜ್‌ಗಳು ಕನಿಷ್ಠ 10 ಅವಲಂಬನೆಗಳನ್ನು ಹೊಂದಿವೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಕೆಲವು ಪ್ಯಾಕೇಜುಗಳು ಗಣನೀಯವಾಗಿ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಅವಲಂಬನೆಗಳನ್ನು ಹೊಂದಿವೆ (100 ಕ್ಕಿಂತ ಹೆಚ್ಚು). ರಿವರ್ಸ್ ಪ್ಯಾಕೇಜ್ ಅವಲಂಬನೆಗಳಿಗೆ ಇದು ಅನ್ವಯಿಸುತ್ತದೆ: ನಿರೀಕ್ಷೆಯಂತೆ, ಕೆಲವು ಪ್ಯಾಕೇಜುಗಳನ್ನು ವಿತರಣೆಯಲ್ಲಿ ಅನೇಕ ಇತರ ಪ್ಯಾಕೇಜ್‌ಗಳು ಬಳಸುತ್ತವೆ, ಆದ್ದರಿಂದ ಆಯ್ದ ಕೆಲವರಲ್ಲಿ ದುರ್ಬಲತೆಗಳು ಹೆಚ್ಚಿನ ಅಪಾಯವನ್ನು ಹೊಂದಿರುತ್ತವೆ. ಉದಾಹರಣೆಯಾಗಿ, ಕೆಳಗಿನ ಕೋಷ್ಟಕವು SLES, Centos 20, Debian 7 ಮತ್ತು Ubuntu 9 ನಲ್ಲಿ ಗರಿಷ್ಠ ಸಂಖ್ಯೆಯ ರಿವರ್ಸ್ ಅವಲಂಬನೆಗಳೊಂದಿಗೆ 18.04 ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ (ಪ್ರತಿ ಕೋಶವು ಪ್ಯಾಕೇಜ್ ಮತ್ತು ರಿವರ್ಸ್ ಅವಲಂಬನೆಗಳ ಸಂಖ್ಯೆಯನ್ನು ಸೂಚಿಸುತ್ತದೆ).

ಟೇಬಲ್ 3

ಆಸಕ್ತಿದಾಯಕ ವಾಸ್ತವ. ವಿಶ್ಲೇಷಿಸಲಾದ ಎಲ್ಲಾ OS ಗಳನ್ನು x86_64 ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಾಗಿ ನಿರ್ಮಿಸಲಾಗಿದೆ, ಮತ್ತು ಹೆಚ್ಚಿನ ಪ್ಯಾಕೇಜುಗಳು x86_64 ಮತ್ತು x86 ಎಂದು ವ್ಯಾಖ್ಯಾನಿಸಲಾದ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಹೊಂದಿದ್ದರೂ, ಪ್ಯಾಕೇಜುಗಳು ಚಿತ್ರ 5 ರಲ್ಲಿ ತೋರಿಸಿರುವಂತೆ ಇತರ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳಿಗೆ ಬೈನರಿಗಳನ್ನು ಹೊಂದಿರುತ್ತವೆ. XNUMX.

ಅಂಜೂರ. 5

ಮುಂದಿನ ವಿಭಾಗದಲ್ಲಿ, ನಾವು ವಿಶ್ಲೇಷಿಸಿದ ಬೈನರಿಗಳ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತೇವೆ.

ಬೈನರಿ ಫೈಲ್ ರಕ್ಷಣೆ ಅಂಕಿಅಂಶಗಳು

ಕನಿಷ್ಠ ಪಕ್ಷ, ನಿಮ್ಮ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಬೈನರಿಗಳಿಗಾಗಿ ನೀವು ಮೂಲಭೂತ ಭದ್ರತಾ ಆಯ್ಕೆಗಳನ್ನು ಅನ್ವೇಷಿಸುವ ಅಗತ್ಯವಿದೆ. ಹಲವಾರು ಲಿನಕ್ಸ್ ವಿತರಣೆಗಳು ಅಂತಹ ತಪಾಸಣೆಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳೊಂದಿಗೆ ಬರುತ್ತವೆ. ಉದಾಹರಣೆಗೆ, ಡೆಬಿಯನ್/ಉಬುಂಟು ಅಂತಹ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಹೊಂದಿದೆ. ಅವರ ಕೆಲಸದ ಉದಾಹರಣೆ ಇಲ್ಲಿದೆ:

$ hardening-check $(which docker)
/usr/bin/docker:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: no, only unprotected functions found!
 Read-only relocations: yes
 Immediate binding: yes

ಸ್ಕ್ರಿಪ್ಟ್ ಐದು ಪರಿಶೀಲಿಸುತ್ತದೆ ರಕ್ಷಣೆ ಕಾರ್ಯಗಳು:

• ಸ್ವತಂತ್ರ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ಸ್ಥಾನ (PIE): ಕರ್ನಲ್‌ನಲ್ಲಿ ASLR ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿದರೆ ಯಾದೃಚ್ಛಿಕತೆಯನ್ನು ಸಾಧಿಸಲು ಪ್ರೋಗ್ರಾಂನ ಪಠ್ಯ ವಿಭಾಗವನ್ನು ಮೆಮೊರಿಯಲ್ಲಿ ಚಲಿಸಬಹುದೇ ಎಂದು ಸೂಚಿಸುತ್ತದೆ.
• ಸ್ಟಾಕ್ ರಕ್ಷಿಸಲಾಗಿದೆ: ಸ್ಟಾಕ್ ಘರ್ಷಣೆ ದಾಳಿಯಿಂದ ರಕ್ಷಿಸಲು ಸ್ಟಾಕ್ ಕ್ಯಾನರಿಗಳನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆಯೇ.
• ಮೂಲವನ್ನು ಬಲಪಡಿಸಿ: ಅಸುರಕ್ಷಿತ ಕಾರ್ಯಗಳನ್ನು (ಉದಾಹರಣೆಗೆ, strcpy) ಅವುಗಳ ಹೆಚ್ಚು ಸುರಕ್ಷಿತ ಕೌಂಟರ್‌ಪಾರ್ಟ್‌ಗಳೊಂದಿಗೆ ಬದಲಾಯಿಸಲಾಗಿದೆಯೇ ಮತ್ತು ರನ್‌ಟೈಮ್‌ನಲ್ಲಿ ಪರಿಶೀಲಿಸಲಾದ ಕರೆಗಳನ್ನು ಅವುಗಳ ಪರಿಶೀಲಿಸದ ಕೌಂಟರ್‌ಪಾರ್ಟ್‌ಗಳೊಂದಿಗೆ ಬದಲಾಯಿಸಲಾಗುತ್ತದೆ (ಉದಾಹರಣೆಗೆ, __memcpy_chk ಬದಲಿಗೆ memcpy).
• ಓದಲು-ಮಾತ್ರ ಸ್ಥಳಾಂತರಗಳು (RELRO): ಮರುಸ್ಥಾಪನೆ ಟೇಬಲ್ ನಮೂದುಗಳನ್ನು ಎಕ್ಸಿಕ್ಯೂಶನ್ ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲು ಪ್ರಚೋದಿಸಿದರೆ ಓದಲು ಮಾತ್ರ ಎಂದು ಗುರುತಿಸಲಾಗಿದೆಯೇ.
• ತಕ್ಷಣದ ಬೈಂಡಿಂಗ್: ಪ್ರೋಗ್ರಾಂ ಎಕ್ಸಿಕ್ಯೂಶನ್ ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲು ರನ್‌ಟೈಮ್ ಲಿಂಕರ್ ಎಲ್ಲಾ ಚಲನೆಗಳನ್ನು ಅನುಮತಿಸುತ್ತದೆಯೇ (ಇದು ಪೂರ್ಣ RELRO ಗೆ ಸಮನಾಗಿರುತ್ತದೆ).

ಮೇಲಿನ ಕಾರ್ಯವಿಧಾನಗಳು ಸಾಕಷ್ಟಿವೆಯೇ? ದುರದೃಷ್ಟವಶಾತ್ ಇಲ್ಲ. ಮೇಲಿನ ಎಲ್ಲಾ ರಕ್ಷಣೆಗಳನ್ನು ಬೈಪಾಸ್ ಮಾಡಲು ತಿಳಿದಿರುವ ಮಾರ್ಗಗಳಿವೆ, ಆದರೆ ಕಠಿಣವಾದ ರಕ್ಷಣೆ, ಆಕ್ರಮಣಕಾರರಿಗೆ ಹೆಚ್ಚಿನ ಬಾರ್. ಉದಾಹರಣೆಗೆ, RELRO ಬೈಪಾಸ್ ವಿಧಾನಗಳು PIE ಮತ್ತು ತಕ್ಷಣದ ಬೈಂಡಿಂಗ್ ಜಾರಿಯಲ್ಲಿದ್ದರೆ ಅನ್ವಯಿಸಲು ಹೆಚ್ಚು ಕಷ್ಟ. ಅಂತೆಯೇ, ಪೂರ್ಣ ASLR ಗೆ ಕೆಲಸದ ಶೋಷಣೆಯನ್ನು ರಚಿಸಲು ಹೆಚ್ಚುವರಿ ಕೆಲಸದ ಅಗತ್ಯವಿದೆ. ಆದಾಗ್ಯೂ, ಅತ್ಯಾಧುನಿಕ ದಾಳಿಕೋರರು ಅಂತಹ ರಕ್ಷಣೆಗಳನ್ನು ಪೂರೈಸಲು ಈಗಾಗಲೇ ಸಿದ್ಧರಾಗಿದ್ದಾರೆ: ಅವರ ಅನುಪಸ್ಥಿತಿಯು ಮೂಲಭೂತವಾಗಿ ಹ್ಯಾಕ್ ಅನ್ನು ವೇಗಗೊಳಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ ಈ ಕ್ರಮಗಳನ್ನು ಅಗತ್ಯವೆಂದು ಪರಿಗಣಿಸುವುದು ಅತ್ಯಗತ್ಯ ಕನಿಷ್ಠ.

ಪ್ರಶ್ನೆಯಲ್ಲಿರುವ ವಿತರಣೆಗಳಲ್ಲಿ ಎಷ್ಟು ಬೈನರಿ ಫೈಲ್‌ಗಳನ್ನು ಈ ಮತ್ತು ಇತರ ಮೂರು ವಿಧಾನಗಳಿಂದ ರಕ್ಷಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ನಾವು ಅಧ್ಯಯನ ಮಾಡಲು ಬಯಸಿದ್ದೇವೆ:

• ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗದ ಬಿಟ್ (NX) ಸ್ಟಾಕ್ ಹೀಪ್ ಇತ್ಯಾದಿಗಳಂತಹ ಕಾರ್ಯಗತಗೊಳಿಸದ ಯಾವುದೇ ಪ್ರದೇಶದಲ್ಲಿ ಮರಣದಂಡನೆಯನ್ನು ತಡೆಯುತ್ತದೆ.
• RPATH/RUNPATH ಹೊಂದಾಣಿಕೆಯ ಲೈಬ್ರರಿಗಳನ್ನು ಹುಡುಕಲು ಡೈನಾಮಿಕ್ ಲೋಡರ್ ಬಳಸುವ ಎಕ್ಸಿಕ್ಯೂಶನ್ ಪಥವನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಮೊದಲನೆಯದು ಕಡ್ಡಾಯ ಯಾವುದೇ ಆಧುನಿಕ ವ್ಯವಸ್ಥೆಗೆ: ಅದರ ಅನುಪಸ್ಥಿತಿಯು ಆಕ್ರಮಣಕಾರರಿಗೆ ಅನಿಯಂತ್ರಿತವಾಗಿ ಪೇಲೋಡ್ ಅನ್ನು ಮೆಮೊರಿಗೆ ಬರೆಯಲು ಮತ್ತು ಅದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಅನುಮತಿಸುತ್ತದೆ. ಎರಡನೆಯದಾಗಿ, ಹಲವಾರು ಸಮಸ್ಯೆಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದಾದ ವಿಶ್ವಾಸಾರ್ಹವಲ್ಲದ ಕೋಡ್ ಅನ್ನು ಪರಿಚಯಿಸುವಲ್ಲಿ ತಪ್ಪಾದ ಎಕ್ಸಿಕ್ಯೂಶನ್ ಪಾಥ್ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳು ಸಹಾಯ ಮಾಡುತ್ತವೆ (ಉದಾ. ಸವಲತ್ತು ಹೆಚ್ಚಳಮತ್ತು ಇತರ ಸಮಸ್ಯೆಗಳು).
• ಸ್ಟಾಕ್ ಘರ್ಷಣೆ ರಕ್ಷಣೆಯು ದಾಳಿಯ ವಿರುದ್ಧ ರಕ್ಷಣೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ, ಅದು ಸ್ಟಾಕ್ ಅನ್ನು ಮೆಮೊರಿಯ ಇತರ ಪ್ರದೇಶಗಳನ್ನು ಅತಿಕ್ರಮಿಸಲು ಕಾರಣವಾಗುತ್ತದೆ (ಉದಾಹರಣೆಗೆ ರಾಶಿ). ಇತ್ತೀಚಿನ ದುರ್ಬಳಕೆಗಳನ್ನು ನೀಡಲಾಗಿದೆ systemd ರಾಶಿ ಘರ್ಷಣೆ ದುರ್ಬಲತೆಗಳು, ನಮ್ಮ ಡೇಟಾಸೆಟ್‌ನಲ್ಲಿ ಈ ಕಾರ್ಯವಿಧಾನವನ್ನು ಸೇರಿಸುವುದು ಸೂಕ್ತವೆಂದು ನಾವು ಭಾವಿಸಿದ್ದೇವೆ.

ಆದ್ದರಿಂದ, ಮತ್ತಷ್ಟು ಸಡಗರವಿಲ್ಲದೆ, ಸಂಖ್ಯೆಗಳಿಗೆ ಇಳಿಯೋಣ. ಕೋಷ್ಟಕಗಳು 4 ಮತ್ತು 5 ಅನುಕ್ರಮವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ಫೈಲ್‌ಗಳು ಮತ್ತು ವಿವಿಧ ವಿತರಣೆಗಳ ಲೈಬ್ರರಿಗಳ ವಿಶ್ಲೇಷಣೆಯ ಸಾರಾಂಶವನ್ನು ಹೊಂದಿರುತ್ತವೆ.

• ನೀವು ನೋಡುವಂತೆ, ಅಪರೂಪದ ವಿನಾಯಿತಿಗಳೊಂದಿಗೆ NX ರಕ್ಷಣೆಯನ್ನು ಎಲ್ಲೆಡೆ ಅಳವಡಿಸಲಾಗಿದೆ. ನಿರ್ದಿಷ್ಟವಾಗಿ ಹೇಳುವುದಾದರೆ, CentOS, RHEL ಮತ್ತು OpenSUSE ಗೆ ಹೋಲಿಸಿದರೆ ಉಬುಂಟು ಮತ್ತು ಡೆಬಿಯನ್ ವಿತರಣೆಗಳಲ್ಲಿ ಅದರ ಸ್ವಲ್ಪ ಕಡಿಮೆ ಬಳಕೆಯನ್ನು ಗಮನಿಸಬಹುದು.
• ಸ್ಟಾಕ್ ಕ್ಯಾನರಿಗಳು ಅನೇಕ ಸ್ಥಳಗಳಲ್ಲಿ ಕಾಣೆಯಾಗಿವೆ, ವಿಶೇಷವಾಗಿ ಹಳೆಯ ಕರ್ನಲ್‌ಗಳೊಂದಿಗೆ ವಿತರಣೆಗಳಲ್ಲಿ. Centos, RHEL, Debian ಮತ್ತು Ubuntu ನ ಇತ್ತೀಚಿನ ವಿತರಣೆಗಳಲ್ಲಿ ಕೆಲವು ಪ್ರಗತಿ ಕಂಡುಬರುತ್ತಿದೆ.
• ಡೆಬಿಯನ್ ಮತ್ತು ಉಬುಂಟು 18.04 ಹೊರತುಪಡಿಸಿ, ಹೆಚ್ಚಿನ ವಿತರಣೆಗಳು ಕಳಪೆ PIE ಬೆಂಬಲವನ್ನು ಹೊಂದಿವೆ.
• ಸ್ಟಾಕ್ ಘರ್ಷಣೆ ರಕ್ಷಣೆ OpenSUSE, Centos 7 ಮತ್ತು RHEL 7 ನಲ್ಲಿ ದುರ್ಬಲವಾಗಿದೆ ಮತ್ತು ಇತರರಲ್ಲಿ ವಾಸ್ತವಿಕವಾಗಿ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ.
• ಆಧುನಿಕ ಕರ್ನಲ್‌ಗಳೊಂದಿಗಿನ ಎಲ್ಲಾ ವಿತರಣೆಗಳು RELRO ಗೆ ಕೆಲವು ಬೆಂಬಲವನ್ನು ಹೊಂದಿವೆ, ಉಬುಂಟು 18.04 ದಾರಿಯನ್ನು ಮುನ್ನಡೆಸುತ್ತದೆ ಮತ್ತು ಡೆಬಿಯನ್ ಎರಡನೇ ಸ್ಥಾನದಲ್ಲಿದೆ.

ಈಗಾಗಲೇ ಹೇಳಿದಂತೆ, ಈ ಕೋಷ್ಟಕದಲ್ಲಿನ ಮೆಟ್ರಿಕ್‌ಗಳು ಬೈನರಿ ಫೈಲ್‌ನ ಎಲ್ಲಾ ಆವೃತ್ತಿಗಳಿಗೆ ಸರಾಸರಿ. ನೀವು ಫೈಲ್‌ಗಳ ಇತ್ತೀಚಿನ ಆವೃತ್ತಿಗಳನ್ನು ಮಾತ್ರ ನೋಡಿದರೆ, ಸಂಖ್ಯೆಗಳು ವಿಭಿನ್ನವಾಗಿರುತ್ತದೆ (ಉದಾಹರಣೆಗೆ, ನೋಡಿ PIE ಅನುಷ್ಠಾನದೊಂದಿಗೆ ಡೆಬಿಯನ್ ಪ್ರಗತಿ) ಇದಲ್ಲದೆ, ಹೆಚ್ಚಿನ ವಿತರಣೆಗಳು ಅಂಕಿಅಂಶಗಳನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುವಾಗ ಬೈನರಿಯಲ್ಲಿ ಕೆಲವು ಕಾರ್ಯಗಳ ಸುರಕ್ಷತೆಯನ್ನು ಮಾತ್ರ ಪರೀಕ್ಷಿಸುತ್ತವೆ, ಆದರೆ ನಮ್ಮ ವಿಶ್ಲೇಷಣೆಯು ಗಟ್ಟಿಯಾದ ಕಾರ್ಯಗಳ ನಿಜವಾದ ಶೇಕಡಾವಾರು ಪ್ರಮಾಣವನ್ನು ತೋರಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ, ಬೈನರಿಯಲ್ಲಿ 5 ಕಾರ್ಯಗಳಲ್ಲಿ 50 ಅನ್ನು ರಕ್ಷಿಸಿದರೆ, ನಾವು ಅದಕ್ಕೆ 0,1 ಸ್ಕೋರ್ ನೀಡುತ್ತೇವೆ, ಇದು 10% ರಷ್ಟು ಬಲಪಡಿಸುವ ಕಾರ್ಯಗಳಿಗೆ ಅನುರೂಪವಾಗಿದೆ.

ಕೋಷ್ಟಕ 4. ಅಂಜೂರದಲ್ಲಿ ತೋರಿಸಿರುವ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ಫೈಲ್‌ಗಳಿಗೆ ಭದ್ರತಾ ಗುಣಲಕ್ಷಣಗಳು. 3 (ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ಫೈಲ್‌ಗಳ ಒಟ್ಟು ಸಂಖ್ಯೆಯ ಶೇಕಡಾವಾರು ಪ್ರಮಾಣದಲ್ಲಿ ಸಂಬಂಧಿತ ಕಾರ್ಯಗಳ ಅನುಷ್ಠಾನ)

ಕೋಷ್ಟಕ 5. ಅಂಜೂರದಲ್ಲಿ ತೋರಿಸಿರುವ ಗ್ರಂಥಾಲಯಗಳಿಗೆ ಭದ್ರತಾ ಗುಣಲಕ್ಷಣಗಳು. 3 (ಸಂಬಂಧಿತ ಕಾರ್ಯಗಳ ಅನುಷ್ಠಾನ ಗ್ರಂಥಾಲಯಗಳ ಒಟ್ಟು ಸಂಖ್ಯೆಯ ಶೇಕಡಾವಾರು)

ಹಾಗಾದರೆ ಪ್ರಗತಿ ಇದೆಯೇ? ಖಂಡಿತವಾಗಿಯೂ ಇದೆ: ವೈಯಕ್ತಿಕ ವಿತರಣೆಗಳ ಅಂಕಿಅಂಶಗಳಿಂದ ಇದನ್ನು ನೋಡಬಹುದು (ಉದಾಹರಣೆಗೆ, ಡೆಬಿಯನ್), ಹಾಗೆಯೇ ಮೇಲಿನ ಕೋಷ್ಟಕಗಳಿಂದ. ಅಂಜೂರದಲ್ಲಿ ಉದಾಹರಣೆಯಾಗಿ. ಚಿತ್ರ 6 ಉಬುಂಟು LTS 5 ರ ಮೂರು ಸತತ ವಿತರಣೆಗಳಲ್ಲಿ ರಕ್ಷಣೆ ಕಾರ್ಯವಿಧಾನಗಳ ಅನುಷ್ಠಾನವನ್ನು ತೋರಿಸುತ್ತದೆ (ನಾವು ಸ್ಟಾಕ್ ಘರ್ಷಣೆ ರಕ್ಷಣೆಯ ಅಂಕಿಅಂಶಗಳನ್ನು ಬಿಟ್ಟುಬಿಟ್ಟಿದ್ದೇವೆ). ಆವೃತ್ತಿಯಿಂದ ಆವೃತ್ತಿಗೆ ಹೆಚ್ಚು ಹೆಚ್ಚು ಫೈಲ್‌ಗಳು ಸ್ಟಾಕ್ ಕ್ಯಾನರಿಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತವೆ ಮತ್ತು ಹೆಚ್ಚು ಹೆಚ್ಚು ಬೈನರಿಗಳನ್ನು ಪೂರ್ಣ RELRO ರಕ್ಷಣೆಯೊಂದಿಗೆ ರವಾನಿಸಲಾಗುತ್ತದೆ ಎಂದು ನಾವು ಗಮನಿಸುತ್ತೇವೆ.

ಅಂಜೂರ. 6

ದುರದೃಷ್ಟವಶಾತ್, ವಿವಿಧ ವಿತರಣೆಗಳಲ್ಲಿನ ಹಲವಾರು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ಫೈಲ್‌ಗಳು ಇನ್ನೂ ಮೇಲಿನ ಯಾವುದೇ ರಕ್ಷಣೆಗಳನ್ನು ಹೊಂದಿಲ್ಲ. ಉದಾಹರಣೆಗೆ, Ubuntu 18.04 ಅನ್ನು ನೋಡಿದಾಗ, ನೀವು ngetty ಬೈನರಿ (ಗೆಟ್ಟಿ ಬದಲಿ), ಹಾಗೆಯೇ mksh ಮತ್ತು lksh ಶೆಲ್‌ಗಳು, picolisp ಇಂಟರ್ಪ್ರಿಟರ್, nvidia-cuda-toolkit ಪ್ಯಾಕೇಜುಗಳು (GPU- ವೇಗವರ್ಧಿತ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗಾಗಿ ಜನಪ್ರಿಯ ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಗಮನಿಸಬಹುದು. ಉದಾಹರಣೆಗೆ ಯಂತ್ರ ಕಲಿಕೆಯ ಚೌಕಟ್ಟುಗಳು), ಮತ್ತು klibc -utils. ಅಂತೆಯೇ, ಮ್ಯಾಂಡೋಸ್-ಕ್ಲೈಂಟ್ ಬೈನರಿ (ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಲಾದ ಫೈಲ್ ಸಿಸ್ಟಮ್‌ಗಳೊಂದಿಗೆ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಯಂತ್ರಗಳನ್ನು ರೀಬೂಟ್ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ಆಡಳಿತಾತ್ಮಕ ಸಾಧನ) ಹಾಗೆಯೇ rsh-redone-client (rsh ಮತ್ತು rlogin ನ ಮರುಪೂರಣ) NX ರಕ್ಷಣೆಯಿಲ್ಲದೆ, ಅವುಗಳು SUID ಹಕ್ಕುಗಳನ್ನು ಹೊಂದಿದ್ದರೂ: (. ಅಲ್ಲದೆ, ಹಲವಾರು suid ಬೈನರಿಗಳು ಸ್ಟಾಕ್ ಕ್ಯಾನರಿಗಳಂತಹ ಮೂಲಭೂತ ರಕ್ಷಣೆಯನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ (ಉದಾಹರಣೆಗೆ, Xorg ಪ್ಯಾಕೇಜ್‌ನಿಂದ Xorg.wrap ಬೈನರಿ).

ಸಾರಾಂಶ ಮತ್ತು ಮುಕ್ತಾಯದ ಟೀಕೆಗಳು

ಈ ಲೇಖನದಲ್ಲಿ, ಆಧುನಿಕ ಲಿನಕ್ಸ್ ವಿತರಣೆಗಳ ಹಲವಾರು ಭದ್ರತಾ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ನಾವು ಹೈಲೈಟ್ ಮಾಡಿದ್ದೇವೆ. ಇತ್ತೀಚಿನ ಉಬುಂಟು LTS ವಿತರಣೆಯು (18.04) ಉಬುಂಟು 14.04, 12.04 ಮತ್ತು Debian 9 ನಂತಹ ತುಲನಾತ್ಮಕವಾಗಿ ಹೊಸ ಕರ್ನಲ್‌ಗಳೊಂದಿಗೆ ವಿತರಣೆಗಳ ನಡುವೆ ಸರಾಸರಿ ಪ್ರಬಲ OS ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಮಟ್ಟದ ರಕ್ಷಣೆಯನ್ನು ಅಳವಡಿಸುತ್ತದೆ ಎಂದು ವಿಶ್ಲೇಷಣೆ ತೋರಿಸಿದೆ. ಆದಾಗ್ಯೂ, ಪರೀಕ್ಷಿಸಿದ ವಿತರಣೆಗಳು CentOS, RHEL ಮತ್ತು ನಮ್ಮ ಸೆಟ್‌ನಲ್ಲಿರುವ OpenSUSE ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಅವರು ದಟ್ಟವಾದ ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ಉತ್ಪಾದಿಸುತ್ತಾರೆ ಮತ್ತು ಇತ್ತೀಚಿನ ಆವೃತ್ತಿಗಳಲ್ಲಿ (CentOS ಮತ್ತು RHEL) ಡೆಬಿಯನ್-ಆಧಾರಿತ ಪ್ರತಿಸ್ಪರ್ಧಿಗಳಿಗೆ (ಡೆಬಿಯನ್ ಮತ್ತು ಉಬುಂಟು) ಹೋಲಿಸಿದರೆ ಅವರು ಹೆಚ್ಚಿನ ಶೇಕಡಾವಾರು ಸ್ಟಾಕ್ ಡಿಕ್ಕಿಯ ರಕ್ಷಣೆಯನ್ನು ಹೊಂದಿದ್ದಾರೆ. CentOS ಮತ್ತು RedHat ಆವೃತ್ತಿಗಳನ್ನು ಹೋಲಿಸಿದಾಗ, 6 ರಿಂದ 7 ಆವೃತ್ತಿಗಳ ಸ್ಟಾಕ್ ಕ್ಯಾನರಿಗಳು ಮತ್ತು RELRO ಗಳ ಅನುಷ್ಠಾನದಲ್ಲಿ ದೊಡ್ಡ ಸುಧಾರಣೆಗಳನ್ನು ನಾವು ಗಮನಿಸುತ್ತೇವೆ, ಆದರೆ ಸರಾಸರಿ CentOS RHEL ಗಿಂತ ಹೆಚ್ಚಿನ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಅಳವಡಿಸಲಾಗಿದೆ. ಸಾಮಾನ್ಯವಾಗಿ, ಎಲ್ಲಾ ವಿತರಣೆಗಳು PIE ರಕ್ಷಣೆಗೆ ವಿಶೇಷ ಗಮನವನ್ನು ನೀಡಬೇಕು, ಇದು Debian 9 ಮತ್ತು Ubuntu 18.04 ಅನ್ನು ಹೊರತುಪಡಿಸಿ, ನಮ್ಮ ಡೇಟಾಸೆಟ್‌ನಲ್ಲಿ 10% ಕ್ಕಿಂತ ಕಡಿಮೆ ಬೈನರಿಗಳಲ್ಲಿ ಅಳವಡಿಸಲಾಗಿದೆ.

ಅಂತಿಮವಾಗಿ, ನಾವು ಸಂಶೋಧನೆಯನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ನಡೆಸಿದ್ದರೂ, ಹಲವು ಭದ್ರತಾ ಪರಿಕರಗಳು ಲಭ್ಯವಿವೆ ಎಂಬುದನ್ನು ಗಮನಿಸಬೇಕು (ಉದಾ. ಲಿನಿಸ್, ಟೈಗರ್, ಹಬಲ್), ಇದು ವಿಶ್ಲೇಷಣೆಯನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಅಸುರಕ್ಷಿತ ಸಂರಚನೆಗಳನ್ನು ತಪ್ಪಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ದುರದೃಷ್ಟವಶಾತ್, ಸಮಂಜಸವಾದ ಸಂರಚನೆಗಳಲ್ಲಿ ಬಲವಾದ ರಕ್ಷಣೆ ಸಹ ಶೋಷಣೆಗಳ ಅನುಪಸ್ಥಿತಿಯನ್ನು ಖಾತರಿಪಡಿಸುವುದಿಲ್ಲ. ಅದಕ್ಕಾಗಿಯೇ ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು ಅತ್ಯಗತ್ಯ ಎಂದು ನಾವು ದೃಢವಾಗಿ ನಂಬುತ್ತೇವೆ ನೈಜ ಸಮಯದಲ್ಲಿ ದಾಳಿಗಳ ವಿಶ್ವಾಸಾರ್ಹ ಮೇಲ್ವಿಚಾರಣೆ ಮತ್ತು ತಡೆಗಟ್ಟುವಿಕೆ, ಶೋಷಣೆಯ ಮಾದರಿಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುವುದು ಮತ್ತು ಅವುಗಳನ್ನು ತಡೆಗಟ್ಟುವುದು.

ಮೂಲ: www.habr.com