PAM ದೃಢೀಕರಣವು ಕೈಯಿಂದ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಆದರೆ OpenVPN ಸೇವೆಯಾಗಿ ವಿಫಲವಾಗುತ್ತದೆ

PAM ಮೂಲಕ ದೃಢೀಕರಣವು ನೀವು ಕ್ಲೈಂಟ್ ಅನ್ನು ಕೈಯಿಂದ ಚಲಾಯಿಸಿದಾಗ ಯಶಸ್ವಿಯಾಗಬಹುದು ಮತ್ತು systemd ಅದೇ ಪ್ರೊಫೈಲ್ ಪ್ರಾರಂಭಿಸಿದಾಗ AUTH_FAILED ನೊಂದಿಗೆ ವಿಫಲವಾಗಬಹುದು. ಆ ಚಲಾವಣೆಗಳ ನಡುವೆ ಪಾಸ್‌ವರ್ಡ್ ಬದಲಾಗುವುದಿಲ್ಲ; ಬದಲಾಗುವುದು PAM ಗೆ ಪ್ರಶ್ನೆ ಹಾಕುವ ಪ್ರಕ್ರಿಯೆಯ ಸುತ್ತಲಿನ ನಿರ್ಬಂಧಗಳ ಗುಂಪು. PAM ತನ್ನದೇ ರುಜುವಾತುಗಳನ್ನು ಬದಲಿಸುವ ಸಾಮರ್ಥ್ಯವಿರುವ ಸಹಾಯಕದ ಮೂಲಕ ಉತ್ತರಿಸುತ್ತದೆ, ಮತ್ತು ಕಠಿಣಗೊಳಿಸಿದ unit ನಿಖರವಾಗಿ ಅದನ್ನೇ ತೆಗೆದುಹಾಕುತ್ತದೆ. ಸಾಮರ್ಥ್ಯಗಳ ಪಟ್ಟಿಯನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ಆ ಸಹಾಯಕ ಮತ್ತು ಅದಕ್ಕೆ ಬೇಕಾದ ಗಡಿಯನ್ನು ಹುಡುಕಿ.

unix_chkpwd ಎಂಬುದು PAM ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುವ ಬೈನರಿ

ಸ್ಥಳೀಯ ಪಾಸ್‌ವರ್ಡ್ ದೃಢೀಕರಣದೊಂದಿಗೆ, pam_unix ಸ್ವತಃ hash ಫೈಲ್ ಅನ್ನು ವಿರಳವಾಗಿ ಓದುತ್ತದೆ. ಅದು unix_chkpwd ಅನ್ನು ಚಲಾಯಿಸುತ್ತದೆ, ಅದನ್ನು ವಿತರಣೆಗಳು setuid root ಅಥವಾ setgid shadow ಆಗಿ ಸ್ಥಾಪಿಸುತ್ತವೆ, ಇದರಿಂದ /etc/shadow ಓದುವ ಕೆಲಸವಿಲ್ಲದ ಪ್ರಕ್ರಿಯೆಯ ಪರವಾಗಿ ಒಂದು ಪಾಸ್‌ವರ್ಡ್ ಪರಿಶೀಲಿಸಬಹುದು. ಆ ಗುರುತನ್ನು ಪಡೆಯುವ ಸಾಮರ್ಥ್ಯವನ್ನು ತೆಗೆದುಹಾಕಿ, ಸಹಾಯಕ ಪರಿಶೀಲನೆಯನ್ನು ಪೂರ್ಣಗೊಳಿಸಲಾರದು, ಆದ್ದರಿಂದ ಮಾಡ್ಯೂಲ್ ಸರಳ ದೃಢೀಕರಣ ವೈಫಲ್ಯವನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ.

ನಂತರ ವೈಫಲ್ಯವು ಕ್ಲೈಂಟ್ ನೋಡಬಹುದಾದ ಪ್ರತಿ ಲಾಗ್‌ನಲ್ಲಿ ರುಜುವಾತು ಸಮಸ್ಯೆಯಂತೆ ಕಾಣುತ್ತದೆ. ಅದೇ ಬಲೆ: ಕ್ಲೈಂಟ್ PAM ಅದಕ್ಕೆ ಏನು ಹೇಳಿತು ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು PAM ಸ್ಟಾಕ್ ಇಲ್ಲ ಎಂದಿತು ಎಂದು ಮಾತ್ರ ವರದಿ ಮಾಡುತ್ತದೆ. root ಆಗಿ ಸಹಾಯಕವನ್ನು ಕೈಯಿಂದ ಚಲಾಯಿಸುವುದೂ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಅದು ಸೇವೆ ಎಂದಿಗೂ ಬಳಸದ ಸವಲತ್ತು ಮಾರ್ಗವನ್ನು ಅಭ್ಯಾಸ ಮಾಡುತ್ತದೆ. systemd ನಿಜವಾಗಿ ಲೋಡ್ ಮಾಡಿದ unit ಅನ್ನು ಓದಿ, ನಂತರ ಮಾಡಿದ ಪ್ರಯತ್ನಕ್ಕಾಗಿ ಸಿಸ್ಟಮ್ ಲಾಗ್ ಓದಿ. ಆ ಎರಡು ದೃಷ್ಟಿಕೋನಗಳು ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಸಮಸ್ಯೆಯನ್ನು ತಪ್ಪು ಪಾಸ್‌ವರ್ಡ್ ಸಮಸ್ಯೆಯಿಂದ ಬೇರ್ಪಡಿಸುತ್ತವೆ.

ಪಾಸ್‌ವರ್ಡ್ ಲಾಗ್ ಓದುವ ಮೊದಲು unit ಓದಿ

ಪ್ಯಾಕೇಜ್ ಮಾಡಿದ unit ನೀವು ಬರೆಯದ drop-in ಅನ್ನು ಹೊಂದಿರಬಹುದು, ಮತ್ತು ಪರಿಣಾಮಕಾರಿ ಸಂರಚನೆ ವಿಲೀನವಾದ ಫಲಿತಾಂಶ. systemd ನೋಡುವಂತೆ unit ಅನ್ನು ಮುದ್ರಿಸಿ, ಸಹಾಯಕ ತನ್ನನ್ನು ಎತ್ತರಿಸಿಕೊಳ್ಳಬಹುದೇ ಎಂದು ನಿರ್ಧರಿಸುವ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳೊಂದಿಗೆ. ಈ ಹಂತದಲ್ಲಿ ಓದಲು-ಮಾತ್ರ ಪರಿಶೀಲನೆ ಸಾಕು.

systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p CapabilityBoundingSet -p AmbientCapabilities -p NoNewPrivileges
journalctl -u [email protected] -b

ಮೊದಲ ಆಜ್ಞೆ unit ಮತ್ತು ಅದರ drop-in ಗಳು ಎಲ್ಲಿಂದ ಬರುತ್ತವೆ ಎಂದು ತೋರಿಸುತ್ತದೆ, ಇದು ಮುಖ್ಯ ಏಕೆಂದರೆ ತಿಂಗಳ ಹಿಂದೆ ಸೇರಿಸಿದ ಮೇಲ್ಬರಹವು ಅದು ಏಕೆ ಇದೆ ಎಂಬ ನೆನಪಿಗಿಂತ ಹೆಚ್ಚು ಕಾಲ ಬದುಕುತ್ತದೆ. ಎರಡನೆಯದು ಮುಂದಿನ ಎರಡು ವಿಭಾಗಗಳು ಅವಲಂಬಿಸಿರುವ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಮೌಲ್ಯಗಳನ್ನು ಮುದ್ರಿಸುತ್ತದೆ.

ನೀವು ನೋಡುವುದನ್ನು ಅದೇ ವಿತರಣೆ ಮತ್ತು ಆವೃತ್ತಿಯ ಕಾರ್ಯನಿರ್ವಹಣಾ ಹೋಸ್ಟ್‌ನೊಂದಿಗೆ ಹೋಲಿಸಿ. User, CapabilityBoundingSet ಅಥವಾ NoNewPrivileges ನಲ್ಲಿನ ವ್ಯತ್ಯಾಸ ನಿರ್ದಿಷ್ಟ ಸುಳಿವು; ಗದ್ಯ ಟಿಪ್ಪಣಿಗಳಲ್ಲಿನ ವ್ಯತ್ಯಾಸವಲ್ಲ. ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ಮೌಲ್ಯಗಳನ್ನು ಬರೆದಿಡಿ, ಏಕೆಂದರೆ ಚಲಿಸುವ ಗುರಿಯೊಂದಿಗೆ ನಂತರದ ಹೋಲಿಕೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಸೇವೆಯು ಖಾಲಿ bounding ಗುಂಪಿನೊಂದಿಗೆ ಸವಲತ್ತಿಲ್ಲದ ಖಾತೆಯಾಗಿ ಚಲಿಸಿದರೆ, ಸಹಾಯಕಕ್ಕೆ ಕೆಲಸ ಮಾಡಲು ಬಹುತೇಕ ಏನೂ ಇರುವುದಿಲ್ಲ.

ರುಜುವಾತು ರೂಪಾಂತರ, ಫೈಲ್ ಪ್ರವೇಶ ಮತ್ತು ನೀತಿ ಮೂರು ಗಡಿಗಳು

exec ಸಮಯದಲ್ಲಿ ಏನಾಗುತ್ತದೆ ಎಂಬುದರಿಂದ ಪ್ರಾರಂಭಿಸಿ. setuid ಬೈನರಿ ಅಥವಾ ಫೈಲ್ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಹೊತ್ತ ಫೈಲ್ ರುಜುವಾತು ರೂಪಾಂತರವನ್ನು ಪ್ರಚೋದಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಉಂಟಾದ ಗುರುತು ಕರೆ ಮಾಡಿದವರ ಮುಂದುವರಿಕೆಯಲ್ಲ. bounding ಗುಂಪು ಅಂತಹ ಫೈಲ್ ಏನನ್ನು ಪಡೆಯಬಹುದು ಎಂಬುದನ್ನು ಮಿತಿಗೊಳಿಸುತ್ತದೆ, ಮತ್ತು NoNewPrivileges setuid, setgid ಮತ್ತು ಫೈಲ್-ಸಾಮರ್ಥ್ಯಗಳ ಸಂಪಾದನೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತಡೆಯುತ್ತದೆ. ಆ ಮೂರರಲ್ಲಿ ಯಾವುದಾದರೂ ಸಹಾಯಕವನ್ನು ನಿಲ್ಲಿಸಬಹುದು, ಆದರೆ ಸೇವೆಯ ಪ್ರತಿಯೊಂದು ಇತರ ಕಾರ್ಯವೂ ಅಚ್ಚುಕಟ್ಟಾಗಿರುತ್ತದೆ.

ಮುಂದೆ, ವಿಶಾಲ ವಿವೇಚನಾಧೀನ ಬೈಪಾಸ್ ಅನ್ನು ಸಂಕುಚಿತ ಓದು ಪ್ರವೇಶದಿಂದ ಬೇರ್ಪಡಿಸಿ. CAP_DAC_OVERRIDE ಬಹುತೇಕ ಎಲ್ಲೆಡೆ ವಿವೇಚನಾಧೀನ ಪರಿಶೀಲನೆಗಳನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತದೆ, ಆದರೆ CAP_DAC_READ_SEARCH ತನ್ನದೇ ಹೆಚ್ಚುವರಿ ಅಧಿಕಾರಗಳೊಂದಿಗೆ ಓದು ಮತ್ತು ಡೈರೆಕ್ಟರಿ ಸಂಚಾರವನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ. ಅವು ವಿಭಿನ್ನ ಪರಿಣಾಮ-ತ್ರಿಜ್ಯದ ವಿಭಿನ್ನ ಸಾಧನಗಳು, ಮತ್ತು ಯಾವುದೂ PAM shadow ಫೈಲ್ ಓದಲಿ ಎಂಬ ವಾಕ್ಯದ ಕಾಗುಣಿತವಲ್ಲ.

ಕೊನೆಯದಾಗಿ, ಕಡ್ಡಾಯ ನೀತಿ ಈ ಕ್ರಿಯೆಗೆ ಸರಿಸುಮಾರು ಅನುಮತಿ ನೀಡುತ್ತದೆಯೇ ಎಂದು ಕೇಳಿ. Linux ಸಾಮರ್ಥ್ಯವು SELinux ಅನ್ನು ರದ್ದುಗೊಳಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಒಂದನ್ನು ಹೊಂದಿರುವುದು type enforcement ನಿಯಮದ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಫೈಲ್-ಪ್ರವೇಶ ನಿರಾಕರಣೆ ಮತ್ತು ಸಾಮರ್ಥ್ಯ ನಿರಾಕರಣೆಯನ್ನು ವಿಭಿನ್ನ ಸಾಕ್ಷ್ಯಗಳಾಗಿ ಪರಿಗಣಿಸಿ, ಏಕೆಂದರೆ ಅವು ವಿಭಿನ್ನ ಸರಿಪಡಿಸುವಿಕೆಗಳನ್ನು ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ವಿಭಿನ್ನ ಮಾಲೀಕರನ್ನು ಹೆಸರಿಸುತ್ತವೆ. ದಾಖಲೆಯ ಪ್ರತಿ ಕ್ಷೇತ್ರವನ್ನು ಓದಿ, ಬರೀ denied ಪದವನ್ನಲ್ಲ. ಯಾವ ಕಾರ್ಯನಿರ್ವಾಹಕ ಕ್ರಿಯೆ ಮಾಡಿತು, ಯಾವ ಡೊಮೇನ್‌ನಲ್ಲಿ ಚಲಿಸಿತು, ಯಾವ ರೀತಿಯ ಗುರಿಯನ್ನು ಮುಟ್ಟಿತು, ಯಾವ ವಸ್ತು ವರ್ಗ ಒಳಗೊಂಡಿತ್ತು ಮತ್ತು ನೀತಿ ಯಾವ ಅನುಮತಿಯನ್ನು ನಿರಾಕರಿಸಿತು — ಪ್ರತಿಯೊಂದೂ ವಿಭಿನ್ನ ರೀತಿಯಲ್ಲಿ ಉತ್ತರವನ್ನು ಸಂಕುಚಿಸುತ್ತದೆ.

ಆಡಿಟ್ ಲಾಗ್‌ನಿಂದ ನಿರಾಕರಣೆಯನ್ನು ಹೊರತೆಗೆಯಿರಿ

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

ausearch -m AVC,USER_AVC -ts recent

ಖಾಲಿ ಫಲಿತಾಂಶವು ನಿರಪರಾಧದ ಸಾಕ್ಷ್ಯವಲ್ಲ. ಅದರ ಅರ್ಥ ಆಡಿಟಿಂಗ್ ಸಂಗ್ರಹಿಸುತ್ತಿಲ್ಲ, ಅಥವಾ ನಿಮ್ಮ ವಿಂಡೋ ಪ್ರಯತ್ನವನ್ನು ತಪ್ಪಿಸಿತು, ಮತ್ತು ನೀತಿಯನ್ನು ಹೊರಗಿಡುವ ಮೊದಲು ಎರಡೂ ಸಾಧ್ಯತೆಗಳನ್ನು ಹೊರಗಿಡಬೇಕು.

Red Hat ನ SELinux ಸಮಸ್ಯೆ ಪರಿಹಾರ ಮಾರ್ಗದರ್ಶನ ಲೇಬಲ್ ಮತ್ತು ಸಂರಚನೆ ಪರಿಶೀಲನೆಗಳನ್ನು allow ನಿಯಮಗಳನ್ನು ರಚಿಸುವ ಮೊದಲು ಇಡುತ್ತದೆ, ಇದು ಈ ಸಮಸ್ಯೆಗೂ ಸರಿಯಾದ ಕ್ರಮ. ತಪ್ಪಾಗಿ ಲೇಬಲ್ ಮಾಡಿದ ಸಹಾಯಕ ಬೈನರಿ ಮತ್ತು ನೀತಿಯ ಕೊರತೆ ಸಮಾನ ನಿರಾಕರಣೆಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ ಆದರೆ ವಿಭಿನ್ನ ದುರಸ್ತಿಗಳನ್ನು ಬೇಡುತ್ತವೆ. ಲೇಬಲಿಂಗ್ ದೋಷಕ್ಕೆ allow ನಿಯಮವನ್ನು ರಚಿಸುವುದು ದೋಷವನ್ನು ಮರೆಮಾಡುತ್ತದೆ ಮತ್ತು ಮುಂದಿನ ಪ್ಯಾಕೇಜ್ ನವೀಕರಣ ಅದನ್ನು ಮತ್ತೆ ತರಲು ಬಿಡುತ್ತದೆ. ಯಾವುದೇ ನೀತಿ ಬರೆಯುವ ಮೊದಲು ಸ್ಥಾಪಿಸಿದ ಸಹಾಯಕದ ಲೇಬಲ್ ಅನ್ನು ದೃಢೀಕರಿಸಿ.

ಒಂದು ಸ್ವೀಕೃತ ಮತ್ತು ಒಂದು ನಿರಾಕರಿಸಿದ ಲಾಗಿನ್‌ನೊಂದಿಗೆ ಬದಲಾವಣೆಯನ್ನು ಸಾಬೀತುಪಡಿಸಿ

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

ನಿಜವಾದ ಸಂಪರ್ಕ ಪ್ರಯತ್ನ ಮಾಡಿ ಮತ್ತು ತಕ್ಷಣ ನಂತರ ಜರ್ನಲ್ ಓದಿ. ಸರಿಪಡಿಸುವಿಕೆಯನ್ನು ಸಾಬೀತುಪಡಿಸುವ ಸಾಲು ಆ ಪ್ರಯತ್ನದ pam_unix(openvpn:auth) ನಮೂದು: ಅದು ದೃಢೀಕರಣ ಯಶಸ್ವಿ ಎಂದು ಓದಬೇಕು, ಮತ್ತು ಯಾವುದೇ AVC ದಾಖಲೆ ಅದೇ ಸೆಕೆಂಡ್ ಹೊಂದಿರಬಾರದು.

journalctl -u [email protected] -n 30 --no-pager
ss -tnp | grep openvpn

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