ಹಂಚಿಕೊಂಡ VPN ನಿರ್ಗಮನವು ನೀವು ಉಂಟುಮಾಡದ ಲಾಗಿನ್ ಎಚ್ಚರಿಕೆಗಳನ್ನು ಏಕೆ ಪ್ರಚೋದಿಸುತ್ತದೆ
ಲಾಗಿನ್ ಬ್ಲಾಕ್ ಸಾಮಾನ್ಯವಾಗಿ ಅಪಾಯದ ಸ್ಕೋರ್, ನಿಮ್ಮ ಟನೆಲ್ ಬಗ್ಗೆ ತೀರ್ಪಲ್ಲ. ಹಂಚಿಕೊಂಡ ನಿರ್ಗಮನಗಳು ಆ ಸ್ಕೋರ್ನಲ್ಲಿ ಇನ್ನಾರು ಸೇರಿದ್ದಾರೆ ಮತ್ತು ಅದು ಅವರಿಗೆ ಎಷ್ಟು ವೆಚ್ಚವಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಾಯಿಸುತ್ತವೆ.
VPN ಮೂಲಕ ಪರಿಚಿತ ಸೈಟ್ ತೆರೆಯಿರಿ ಮತ್ತು ಹೆಚ್ಚುವರಿ ಸವಾಲು ಪಡೆಯಿರಿ, ಮತ್ತು ಆಮಿಷದ ವಿವರಣೆ ಎಂದರೆ ಟನೆಲ್ ಪತ್ತೆಯಾಗಿದೆ. ಏನೋ ಪತ್ತೆಯಾಗಿದೆ, ಆದರೆ ಅದು ನೀವಲ್ಲ. ಸೈಟ್ ಹಲವು ಸಂಕೇತಗಳಿಗೆ ಸ್ಕೋರ್ ನೀಡಿತು, ಅವುಗಳಲ್ಲಿ ಒಂದು ಮೂಲ ವಿಳಾಸ, ಮತ್ತು ಆ ವಿಳಾಸವು ಒಂದು ನಿಮಿಷದ ಹಿಂದೆ ವಿಫಲ ಲಾಗಿನ್ಗಳನ್ನು ಉಂಟುಮಾಡಿರಬಹುದಾದ ಅಪರಿಚಿತರೊಂದಿಗೆ ಹಂಚಿಕೊಳ್ಳಲ್ಪಟ್ಟಿದೆ. ನಿರ್ಧಾರವನ್ನು ನಿಮ್ಮ ಸಂಪರ್ಕದ ಬಗ್ಗೆ ತೀರ್ಪಾಗಿ ಓದುವುದು ಸ್ಕೋರ್ ಯಾವುದಕ್ಕಾಗಿ ಎಂಬುದನ್ನು ತಪ್ಪಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು.
ಮೂಲ ವಿಳಾಸ ಏನನ್ನು ನಿರ್ಣಯಿಸಬಹುದು ಮತ್ತು ಏನನ್ನು ಸಾಧ್ಯವಿಲ್ಲ
IP ವಿಳಾಸವು ನಿರ್ದಿಷ್ಟ ಕ್ಷಣದಲ್ಲಿ ಜಾಲದ ಮೂಲಕ ಹಾದುಹೋಗುವ ಮಾರ್ಗವನ್ನು ವಿವರಿಸುತ್ತದೆ. ಅದು ವ್ಯಕ್ತಿ, ಸಾಧನ ಅಥವಾ ಒಂದೇ ಖಾತೆಯನ್ನೂ ಗುರುತಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಕ್ಯಾರಿಯರ್-ಗ್ರೇಡ್ NAT ಅಥವಾ ನಿರಬಿಡುವ VPN ಪೂಲ್ನೊಂದಿಗೆ ಅದು ಏಕಕಾಲದಲ್ಲಿ ಸಾವಿರಾರು ಸಂಬಂಧವಿಲ್ಲದ ಅಧಿವೇಶನಗಳನ್ನು ಪ್ರತಿನಿಧಿಸಬಹುದು. ವಿಳಾಸವನ್ನು ಗುರುತಾಗಿ ಪರಿಗಣಿಸುವ ಸೈಟ್ ವಾಸ್ತವವಾಗಿ ಅದನ್ನು ಖ್ಯಾತಿಯಾಗಿ ಪರಿಗಣಿಸುತ್ತದೆ, ಅದು ಸಾಂಖ್ಯಿಕ ಹೇಳಿಕೆ, ಸತ್ಯವಲ್ಲ.
ಇಬ್ಬರು ಒಂದೇ ನಿರ್ಗಮನವನ್ನು ಹಂಚಿಕೊಂಡು ವಿರುದ್ಧ ಸಾಕ್ಷ್ಯ ನೀಡಬಹುದು: ಒಬ್ಬರು ಎರಡನೇ ಅಂಶದೊಂದಿಗೆ ಯಶಸ್ವಿಯಾಗಿ ಸೈನ್ ಇನ್ ಮಾಡುತ್ತಾರೆ, ಇನ್ನೊಬ್ಬರು ನಲವತ್ತು ಪಾಸ್ವರ್ಡ್ಗಳನ್ನು ಪ್ರಯತ್ನಿಸುತ್ತಾರೆ. ವಿಳಾಸ ಒಂದೇ ಆಗಿರುವುದರಿಂದ, ಕೇವಲ ವಿಳಾಸವನ್ನು ಆಧರಿಸಿದ ಯಾವುದೇ ನಿಯಮ ಅವರನ್ನು ಪ್ರತ್ಯೇಕಿಸಲಾಗದು, ಮತ್ತು ಪ್ರಚೋದಿಸುವ ಯಾವುದೇ ಪ್ರತಿಕ್ರಿಯೆ ಇಬ್ಬರಿಗೂ ಅನ್ವಯಿಸುತ್ತದೆ.
ಇದು ವಿಳಾಸಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸುವ ವಾದವಲ್ಲ. ಸಂಕೇತ ಏನನ್ನು ಅಳೆಯುತ್ತದೆ ಎಂಬುದನ್ನು ನೆನಪಿಟ್ಟುಕೊಳ್ಳುವ ವಾದ ಇದು, ಏಕೆಂದರೆ VPN ಲಾಗಿನ್ಗಳ ಸುತ್ತಲಿನ ಹೆಚ್ಚಿನ ಆಶ್ಚರ್ಯಕರ ವರ್ತನೆ ತಪ್ಪಾದ ಅವಲೋಕನದಿಂದಲ್ಲ, ತಪ್ಪಾದ ಮಟ್ಟದಲ್ಲಿ ನಿಯಂತ್ರಣ ಅನ್ವಯಿಸುವುದರಿಂದ ಬರುತ್ತದೆ.
ನಿರ್ಗಮನವನ್ನು ಬ್ಲಾಕ್ ಮಾಡುವುದು ಅಪರಿಚಿತರನ್ನು ಏಕೆ ಶಿಕ್ಷಿಸುತ್ತದೆ
ವಿಳಾಸ ಮಟ್ಟದ ಬ್ಲಾಕ್ ಜಾರಿಗೊಳಿಸಲು ಅಗ್ಗ, ಗುರಿಯಾಗಿಸಲು ದುಬಾರಿ. ಅದರ ಪ್ರಭಾವದ ತ್ರಿಜ್ಯ ಆ ವಿಳಾಸದ ಹಿಂದಿನ ಪ್ರತಿ ಅಧಿವೇಶನವೂ ಆಗಿದೆ, ಆದ್ದರಿಂದ ಹಂಚಿಕೊಂಡ ವಿಳಾಸಗಳು ಮತ್ತು NAT ವರ್ತನೆಗೆ ಕಾರ್ಯಾಚರಣಾ ದಾಖಲೆಗಳಲ್ಲಿ ತಮ್ಮದೇ ಇತಿಹಾಸವಿದೆ: ಅದೇ ತರ್ಕ IETF ಯ ಹಂಚಿಕೊಂಡ ಮೂಲ ವಿಳಾಸಗಳು ಮತ್ತು ವಿಳಾಸ ಆಧಾರಿತ ಫಿಲ್ಟರಿಂಗ್ನ ಅಡ್ಡಪರಿಣಾಮಗಳ ಕೆಲಸದಲ್ಲಿ ಕಾಣುತ್ತದೆ.
| Signal | What it provides evidence about | What it cannot settle |
|---|---|---|
| Source address and its reputation | The network path, and how that path behaved recently for others | Which account or person is behind the request |
| Authenticator result | Whether the account claim was proved at the required strength | Whether the account's owner initiated it |
| Request timing and volume | Whether the pattern looks automated or burst-like | Whether the intent was malicious or a shared client |
| Application event history | What this account has done while signed in | Anything about requests that never authenticated |
ಬ್ಲಾಕ್ ಸೃಷ್ಟಿಸುವ ಎರಡು ವೈಫಲ್ಯಗಳನ್ನು ಪರಿಗಣಿಸಿ. ಅದೇ ನಿರ್ಗಮನದ ಹಿಂದಿರುವ ಕಾನೂನುಬದ್ಧ ಗ್ರಾಹಕನಿಗೆ ಸೇವೆ ನಿರಾಕರಿಸಲ್ಪಡುತ್ತದೆ ಮತ್ತು ದುರುಪಯೋಗಕ್ಕಿಂತ ಹೆಚ್ಚು ವೆಚ್ಚವಾಗುವ ಬೆಂಬಲ ಟಿಕೆಟ್ ತೆರೆಯುತ್ತಾರೆ. ನಿಜವಾದ ಆಕ್ರಮಣಕಾರರು ಸಾವಿರಾರು ಪೂಲ್ನಲ್ಲಿ ಮುಂದಿನ ನಿರ್ಗಮನಕ್ಕೆ ತೆರಳಿ, ಮತ್ತೆ ಸಂಪರ್ಕಿಸುವುದನ್ನು ಬಿಟ್ಟು ಏನನ್ನೂ ಖರ್ಚು ಮಾಡದೆ ಮುಂದುವರಿಯುತ್ತಾರೆ.
ಅನುಪಾತವು ಕಾಣೆಯಾದ ಹೆಜ್ಜೆ. ಪುನರಾವರ್ತಿತ ವಿಫಲ ಸೈನ್-ಇನ್ಗಳು, ಸ್ವಯಂಚಾಲಿತ ವಿನಂತಿಗಳ ಅಲೆ ಮತ್ತು ದೃಢೀಕೃತ ಅನುಮತಿ ಉಲ್ಲಂಘನೆ ಮೂರು ವಿಭಿನ್ನ ಘಟನೆಗಳು, ಮತ್ತು ಎರಡನೆಯದು ಮಾತ್ರ ವಿಳಾಸ-ಆಕಾರದ ಸಮಸ್ಯೆ ಎನಿಸುತ್ತದೆ. ಅದೇ ಸೈಟ್-ವ್ಯಾಪಿ ಜಾಲ ನಿಷೇಧವನ್ನು ಮೂರಕ್ಕೂ ಅನ್ವಯಿಸುವುದು ಭದ್ರತಾ ನಿಯಂತ್ರಣವು ಬೆಂಬಲ ಸರದಿಯಾಗುವ ರೀತಿ.
ಸಾಕ್ಷ್ಯ ಇರುವಲ್ಲಿ ನಿರ್ಧಾರವನ್ನು ಇರಿಸಿ
ಖಾತೆ ಮಟ್ಟದ ನಿಯಂತ್ರಣಗಳು ವಿಳಾಸಗಳಾದ್ಯಂತ ಖಾತೆಯನ್ನು ಅನುಸರಿಸುತ್ತವೆ, ಇದು ನಿಮಗೆ ನಿಜವಾಗಿ ಮುಖ್ಯವಾದ ಘಟಕಕ್ಕೆ ಹೊಂದುತ್ತದೆ. ದರ ಮಿತಿ, ಪುನರಾವರ್ತಿತ ವೈಫಲ್ಯಗಳ ನಂತರದ ಕಾಯುವ ಅವಧಿಗಳು ಮತ್ತು ಸೂಕ್ಷ್ಮ ಕ್ರಿಯೆಗಳಿಗೆ ಹಂತಹಂತದ ದೃಢೀಕರಣ ಎಲ್ಲವೂ ಜಾಲ ಮಾರ್ಗದ ಮೇಲಲ್ಲ, ಖಾತೆ ಅಥವಾ ಕ್ರಿಯೆಯ ಮೇಲೆ ಕೆಲಸ ಮಾಡುತ್ತವೆ. ಇದು ನೀವು ನಿಜವಾಗಿ ರಕ್ಷಿಸುತ್ತಿರುವ ಘಟಕಕ್ಕೆ ಉತ್ತಮವಾಗಿ ಹೊಂದುತ್ತದೆ. ಇದು ಆಕ್ರಮಣಕಾರರಿಗೆ ಹೊಸ ನಿರ್ಗಮನ ವಿಳಾಸವನ್ನು ಹುಡುಕುವ ಪ್ರೇರಣೆಯನ್ನೂ ತೆಗೆದುಹಾಕುತ್ತದೆ.
NIST ನ ದೃಢೀಕರಣ ಮಾರ್ಗಸೂಚಿಗಳು ಇವುಗಳನ್ನು ಅಪಾಯ ಮೌಲ್ಯಮಾಪನದ ಇನ್ಪುಟ್ಗಳಾಗಿ ಪರಿಗಣಿಸುತ್ತವೆ ಮತ್ತು ಸಂಕೇತಗಳಲ್ಲಿ ವಿಳಾಸ, ಭೌಗೋಳಿಕ ಸ್ಥಳ ಮತ್ತು ವಿನಂತಿಯ ಸಮಯವನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತವೆ, ಅದು ಎರವಲು ಪಡೆಯಬೇಕಾದ ಚೌಕಟ್ಟು: ಸಂಕೇತವು ನಿರ್ಧಾರಕ್ಕೆ ಮಾಹಿತಿ ನೀಡುತ್ತದೆ, ಅದು ದೃಢೀಕರಣಕಾರನನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ. ಆ ಪಟ್ಟಿಯನ್ನು ನಿಷೇಧಿಸಬೇಕಾದ ವಸ್ತುಗಳ ಮೆನುವಾಗಿ ಅಲ್ಲ, ಇನ್ಪುಟ್ಗಳಾಗಿ ಓದಿ. ದೃಢೀಕರಣಕಾರನೇ ಸಾಕ್ಷ್ಯವನ್ನು ನೀಡುತ್ತಾನೆ, ಮತ್ತು ಇತರ ಸಂಕೇತಗಳು ಅದರ ಸುತ್ತ ಎಷ್ಟು ಘರ್ಷಣೆ ಇಡಬೇಕೆಂದು ಮಾತ್ರ ನಿರ್ಧರಿಸುತ್ತವೆ.
ಎರಡು ವಿನ್ಯಾಸ ನಿರ್ಬಂಧಗಳು ಖಾತೆ ಮಟ್ಟದ ವಿಧಾನವು ತನ್ನದೇ ಅಡಚಣೆಯಾಗುವುದನ್ನು ತಡೆಯುತ್ತವೆ. ದರ ಮಿತಿಗಳಿಗೆ ಸುರಕ್ಷಿತ ಪರಿಶೀಲನಾ ಮಾರ್ಗ ಬೇಕು, ಇದರಿಂದ ಬಳಕೆದಾರರು ರುಜುವಾತುಗಳನ್ನು ಪ್ರಕಟಿಸದೆ ತಪ್ಪು ವರ್ಗೀಕರಣವನ್ನು ವರದಿ ಮಾಡಬಹುದು, ಮತ್ತು ಹಂತಹಂತದ ಸವಾಲುಗಳಿಗೆ ಪರಿಶೀಲಿಸದ ಬೆಂಬಲ ಸಂಪರ್ಕಕ್ಕೆ ನೀಡಿದ ಪಾಸ್ವರ್ಡ್ ಅಥವಾ ಒಂದು-ಬಾರಿ ಕೋಡ್ನಿಂದ ಉತ್ತರಿಸಲಾಗದು.
ನ್ಯಾಯಯುತ ನೀತಿ ಹೊರಗಿನಿಂದ ಹೇಗೆ ಕಾಣುತ್ತದೆ
ಪ್ರತಿ ನಿಯಂತ್ರಣವು ಯಾವ ನಿರ್ಧಾರವನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಬರೆಯಿರಿ, ನಂತರ ನಿಯಂತ್ರಣದ ಸೂಕ್ಷ್ಮತೆ ಹೊಂದುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. ವಿಳಾಸ ನಿಯಂತ್ರಣಗಳು ಜಾಲದಿಂದ ಬರುವ ಸಂಚಾರದ ಬಗ್ಗೆ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತವೆ; ಖಾತೆ ನಿಯಂತ್ರಣಗಳು ಖಾತೆಯ ಬಗ್ಗೆ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತವೆ; ಅಪ್ಲಿಕೇಶನ್ ಘಟನೆಗಳು ದೃಢೀಕರಣದ ನಂತರದ ವರ್ತನೆಯ ಬಗ್ಗೆ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತವೆ. ಮೂರನ್ನೂ ಹೆಸರಿಸುವ ನೀತಿ ಲೆಕ್ಕಪರಿಶೋಧನೀಯ, ಮತ್ತು ಕೇವಲ VPN ಸಂಚಾರ ಎಂದು ಹೆಸರಿಸುವ ನೀತಿ ಹಾಗಲ್ಲ.
ನಂತರ ನಿಯಮಗಳ ಸಂಖ್ಯೆಯಲ್ಲ, ಫಲಿತಾಂಶವನ್ನು ಅಳೆಯಿರಿ. ಅನಧಿಕೃತ ಪ್ರಯತ್ನಗಳು ಕಡಿಮೆಯಾಗಬೇಕು, ಕಾನೂನುಬದ್ಧ ಬಳಕೆದಾರರು ಬೆಂಬಲಿತ ಮಾರ್ಗವನ್ನು ಉಳಿಸಿಕೊಳ್ಳಬೇಕು, ಮತ್ತು ಪ್ರತಿ ಸಾವಿರ ಲಾಗಿನ್ಗಳಿಗೆ ಬೆಂಬಲ ಸಂಪರ್ಕಗಳ ಸಂಖ್ಯೆ ಹೆಚ್ಚಾಗಬಾರದು. ಮೊದಲ ಸಂಖ್ಯೆಯನ್ನು ಸುಧಾರಿಸಿ ಉಳಿದ ಎರಡನ್ನು ಹಾಳುಮಾಡುವ ಬ್ಲಾಕ್ ಸಮಸ್ಯೆಯನ್ನು ಸರಿಸಿದೆ, ಪರಿಹರಿಸಿಲ್ಲ.
VPN ಸಂಪರ್ಕಗಳನ್ನು ಸ್ವೀಕರಿಸುವುದು ಮತ್ತು ದುರುಪಯೋಗ ನಿಯಂತ್ರಣಗಳನ್ನು ಜಾರಿಗೊಳಿಸುವುದು ಹೊಂದಿಕೊಳ್ಳುವ ಗುರಿಗಳು. ಕೆಲಸ ಮಾಡುವ ಆವೃತ್ತಿ ಮೂಲ ವಿಳಾಸವನ್ನು ಹಲವು ಇನ್ಪುಟ್ಗಳಲ್ಲಿ ಒಂದಾಗಿ ಪರಿಗಣಿಸುತ್ತದೆ, ಸಾಕ್ಷ್ಯಕ್ಕೆ ಹೊಂದುವ ಸಂಕುಚಿತ ನಿಯಂತ್ರಣವನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ, ಮತ್ತು ತಪ್ಪಾಗಿ ವರ್ಗೀಕರಿಸಲ್ಪಟ್ಟ ವ್ಯಕ್ತಿಗೆ ಪ್ರಾಮಾಣಿಕ ಮಾರ್ಗವನ್ನು ಬಿಡುತ್ತದೆ. ವಿಫಲವಾಗುವ ಆವೃತ್ತಿ ವಿಳಾಸವನ್ನು ಶಂಕಿತನಾಗಿ ಪರಿಗಣಿಸಿ ಅದನ್ನು ನೀತಿ ಎಂದು ಕರೆಯುತ್ತದೆ.