ನಮ್ಮ ಗ್ರಾಹಕರ ಕೆಲಸದಲ್ಲಿ "ಮೂರನೇ ವ್ಯಕ್ತಿಗಳು" ಹೇಗೆ ಹಸ್ತಕ್ಷೇಪ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿದರು ಮತ್ತು ಈ ಸಮಸ್ಯೆಯನ್ನು ಹೇಗೆ ಪರಿಹರಿಸಲಾಯಿತು ಎಂಬುದರ ಕುರಿತು ತಂಪಾದ ಕಥೆಯನ್ನು ನಿಮಗೆ ಹೇಳೋಣ.
ಅದು ಹೇಗೆ ಪ್ರಾರಂಭವಾಯಿತು
ಇದು ಎಲ್ಲಾ ಅಕ್ಟೋಬರ್ 31 ರ ಬೆಳಿಗ್ಗೆ ಪ್ರಾರಂಭವಾಯಿತು, ತಿಂಗಳ ಕೊನೆಯ ದಿನ, ಅನೇಕರು ತುರ್ತು ಮತ್ತು ಪ್ರಮುಖ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ಸಮಯಾವಕಾಶವನ್ನು ಪಡೆಯಬೇಕಾಗಿದೆ.
ನಮ್ಮ ಕ್ಲೌಡ್‌ನಲ್ಲಿ ಸೇವೆ ಸಲ್ಲಿಸುವ ಕ್ಲೈಂಟ್‌ಗಳ ಹಲವಾರು ವರ್ಚುವಲ್ ಯಂತ್ರಗಳನ್ನು ಇರಿಸುವ ಪಾಲುದಾರರಲ್ಲಿ ಒಬ್ಬರು, 9:10 ರಿಂದ 9:20 ರವರೆಗೆ ನಮ್ಮ ಉಕ್ರೇನಿಯನ್ ಸೈಟ್‌ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಹಲವಾರು ವಿಂಡೋಸ್ ಸರ್ವರ್‌ಗಳು ರಿಮೋಟ್ ಪ್ರವೇಶ ಸೇವೆಗೆ ಸಂಪರ್ಕಗಳನ್ನು ಸ್ವೀಕರಿಸುವುದಿಲ್ಲ ಎಂದು ವರದಿ ಮಾಡಿದ್ದಾರೆ , ಬಳಕೆದಾರರಿಗೆ ಸಾಧ್ಯವಾಗಲಿಲ್ಲ ಅವರ ಡೆಸ್ಕ್‌ಟಾಪ್‌ಗಳಿಗೆ ಲಾಗ್ ಇನ್ ಮಾಡಲು, ಆದರೆ ಕೆಲವು ನಿಮಿಷಗಳ ನಂತರ ಸಮಸ್ಯೆಯು ಸ್ವತಃ ಪರಿಹರಿಸಲ್ಪಟ್ಟಂತೆ ತೋರುತ್ತಿದೆ.
ಸಂವಹನ ಚಾನೆಲ್‌ಗಳ ಕಾರ್ಯಾಚರಣೆಯ ಕುರಿತು ನಾವು ಅಂಕಿಅಂಶಗಳನ್ನು ಸಂಗ್ರಹಿಸಿದ್ದೇವೆ, ಆದರೆ ಯಾವುದೇ ಟ್ರಾಫಿಕ್ ಉಲ್ಬಣಗಳು ಅಥವಾ ವೈಫಲ್ಯಗಳು ಕಂಡುಬಂದಿಲ್ಲ. ಕಂಪ್ಯೂಟಿಂಗ್ ಸಂಪನ್ಮೂಲಗಳ ಮೇಲಿನ ಹೊರೆಯ ಅಂಕಿಅಂಶಗಳನ್ನು ನಾವು ನೋಡಿದ್ದೇವೆ - ಯಾವುದೇ ವೈಪರೀತ್ಯಗಳಿಲ್ಲ. ಮತ್ತು ಅದು ಏನು?
ನಂತರ ನಮ್ಮ ಕ್ಲೌಡ್‌ನಲ್ಲಿ ಸುಮಾರು ನೂರು ಸರ್ವರ್‌ಗಳನ್ನು ಹೋಸ್ಟ್ ಮಾಡುವ ಇನ್ನೊಬ್ಬ ಪಾಲುದಾರರು, ಅವರ ಕೆಲವು ಕ್ಲೈಂಟ್‌ಗಳು ಗಮನಿಸಿದ ಅದೇ ಸಮಸ್ಯೆಗಳನ್ನು ವರದಿ ಮಾಡಿದ್ದಾರೆ ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಸರ್ವರ್‌ಗಳು ಪ್ರವೇಶಿಸಬಹುದು (ಪಿಂಗ್ ಪರೀಕ್ಷೆ ಮತ್ತು ಇತರ ವಿನಂತಿಗಳಿಗೆ ಸರಿಯಾಗಿ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ), ಆದರೆ ಈ ಸರ್ವರ್‌ಗಳಲ್ಲಿನ ಸೇವೆ ರಿಮೋಟ್ ಪ್ರವೇಶವು ಹೊಸ ಸಂಪರ್ಕಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಅಥವಾ ಅವುಗಳನ್ನು ತಿರಸ್ಕರಿಸುತ್ತದೆ ಮತ್ತು ನಾವು ವಿಭಿನ್ನ ಸೈಟ್‌ಗಳಲ್ಲಿನ ಸರ್ವರ್‌ಗಳ ಕುರಿತು ಮಾತನಾಡುತ್ತಿದ್ದೇವೆ, ವಿಭಿನ್ನ ಡೇಟಾ ಪ್ರಸರಣ ಚಾನಲ್‌ಗಳಿಂದ ಬರುವ ದಟ್ಟಣೆ.
ಈ ಸಂಚಾರವನ್ನು ನೋಡೋಣ. ಸಂಪರ್ಕ ವಿನಂತಿಯೊಂದಿಗೆ ಪ್ಯಾಕೆಟ್ ಸರ್ವರ್‌ಗೆ ಆಗಮಿಸುತ್ತದೆ:
xx:xx:xx.xxxxxx IP xxx.xxx.xxx.xxx.58355 > 192.168.xxx.xxx.3389: Flags [S], seq 467744439, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
ಸರ್ವರ್ ಈ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಆದರೆ ಸಂಪರ್ಕವನ್ನು ತಿರಸ್ಕರಿಸುತ್ತದೆ:
xx:xx:xx.xxxxxx IP 192.168.xxx.xxx.3389 > xxx.xxx.xxx.xxx.58355: Flags [R.], seq 0, ack 467744440, win 0, length 0
ಇದರರ್ಥ ಸಮಸ್ಯೆಯು ಮೂಲಭೂತ ಸೌಕರ್ಯಗಳ ಕಾರ್ಯಾಚರಣೆಯಲ್ಲಿನ ಯಾವುದೇ ಸಮಸ್ಯೆಗಳಿಂದ ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ, ಆದರೆ ಬೇರೆ ಯಾವುದೋ ಕಾರಣದಿಂದ ಉಂಟಾಗುತ್ತದೆ. ಬಹುಶಃ ಎಲ್ಲಾ ಬಳಕೆದಾರರು ರಿಮೋಟ್ ಡೆಸ್ಕ್‌ಟಾಪ್ ಪರವಾನಗಿಯೊಂದಿಗೆ ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸುತ್ತಿದ್ದಾರೆಯೇ? ಬಹುಶಃ ಕೆಲವು ರೀತಿಯ ಮಾಲ್‌ವೇರ್ ಅವರ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ಭೇದಿಸುವಲ್ಲಿ ಯಶಸ್ವಿಯಾಗಿರಬಹುದು ಮತ್ತು ಇಂದು ಅದನ್ನು ಒಂದೆರಡು ವರ್ಷಗಳ ಹಿಂದೆ ಸಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ XData и ಪೆಟ್ಯಾ?
ನಾವು ಅದನ್ನು ವಿಂಗಡಿಸುತ್ತಿರುವಾಗ, ಇನ್ನೂ ಹಲವಾರು ಕ್ಲೈಂಟ್‌ಗಳು ಮತ್ತು ಪಾಲುದಾರರಿಂದ ನಾವು ಇದೇ ರೀತಿಯ ವಿನಂತಿಗಳನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇವೆ.
ಈ ಯಂತ್ರಗಳಲ್ಲಿ ನಿಜವಾಗಿ ಏನಾಗುತ್ತದೆ?
ಈವೆಂಟ್ ಲಾಗ್‌ಗಳು ಪಾಸ್‌ವರ್ಡ್ ಅನ್ನು ಊಹಿಸುವ ಪ್ರಯತ್ನಗಳ ಕುರಿತು ಸಂದೇಶಗಳಿಂದ ತುಂಬಿವೆ:
ವಿಶಿಷ್ಟವಾಗಿ, ರಿಮೋಟ್ ಪ್ರವೇಶ ಸೇವೆಗಾಗಿ ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಪೋರ್ಟ್ (3389) ಅನ್ನು ಬಳಸುವ ಎಲ್ಲಾ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಅಂತಹ ಪ್ರಯತ್ನಗಳನ್ನು ನೋಂದಾಯಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಎಲ್ಲೆಡೆಯಿಂದ ಪ್ರವೇಶವನ್ನು ಅನುಮತಿಸಲಾಗುತ್ತದೆ. ಲಭ್ಯವಿರುವ ಎಲ್ಲಾ ಸಂಪರ್ಕ ಬಿಂದುಗಳನ್ನು ನಿರಂತರವಾಗಿ ಸ್ಕ್ಯಾನ್ ಮಾಡುವ ಮತ್ತು ಪಾಸ್‌ವರ್ಡ್ ಅನ್ನು ಊಹಿಸಲು ಪ್ರಯತ್ನಿಸುವ ಬಾಟ್‌ಗಳಿಂದ ಇಂಟರ್ನೆಟ್ ತುಂಬಿದೆ (ಇದಕ್ಕಾಗಿಯೇ "123" ಬದಲಿಗೆ ಸಂಕೀರ್ಣ ಪಾಸ್‌ವರ್ಡ್‌ಗಳನ್ನು ಬಳಸಲು ನಾವು ಬಲವಾಗಿ ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ). ಆದಾಗ್ಯೂ, ಆ ದಿನ ಈ ಪ್ರಯತ್ನಗಳ ತೀವ್ರತೆ ತುಂಬಾ ಹೆಚ್ಚಿತ್ತು.
ನಾನು ಏನು ಮಾಡಬೇಕು?
ಗ್ರಾಹಕರು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಅಂತಿಮ ಬಳಕೆದಾರರಿಗೆ ವಿಭಿನ್ನ ಪೋರ್ಟ್‌ಗೆ ಬದಲಾಯಿಸಲು ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಬದಲಾಯಿಸಲು ಸಾಕಷ್ಟು ಸಮಯವನ್ನು ಕಳೆಯುತ್ತಾರೆ ಎಂದು ಶಿಫಾರಸು ಮಾಡುವುದೇ? ಒಳ್ಳೆಯದು ಅಲ್ಲ, ಗ್ರಾಹಕರು ಸಂತೋಷವಾಗಿರುವುದಿಲ್ಲ. VPN ಮೂಲಕ ಮಾತ್ರ ಪ್ರವೇಶವನ್ನು ಅನುಮತಿಸಲು ಶಿಫಾರಸು ಮಾಡುವುದೇ? ತರಾತುರಿಯಲ್ಲಿ ಮತ್ತು ಭಯಭೀತರಾಗಿ, ಐಪಿಎಸ್‌ಸೆಕ್ ಸಂಪರ್ಕಗಳನ್ನು ಹೆಚ್ಚಿಸದವರಿಗೆ ಅವುಗಳನ್ನು ಹೆಚ್ಚಿಸುವುದು - ಬಹುಶಃ ಅಂತಹ ಸಂತೋಷವು ಗ್ರಾಹಕರ ಮೇಲೆ ಕಿರುನಗೆ ಬೀರುವುದಿಲ್ಲ. ಆದಾಗ್ಯೂ, ನಾನು ಹೇಳಲೇಬೇಕು, ಇದು ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ ದೈವಿಕ ವಿಷಯವಾಗಿದೆ, ಸರ್ವರ್ ಅನ್ನು ಖಾಸಗಿ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಮರೆಮಾಡಲು ನಾವು ಯಾವಾಗಲೂ ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಸೆಟ್ಟಿಂಗ್‌ಗಳಿಗೆ ಸಹಾಯ ಮಾಡಲು ಸಿದ್ಧರಿದ್ದೇವೆ ಮತ್ತು ಅದನ್ನು ಸ್ವಂತವಾಗಿ ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ಇಷ್ಟಪಡುವವರಿಗೆ, ನಾವು ಸೂಚನೆಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತೇವೆ ಸೈಟ್-ಟು-ಸೈಟ್ ಅಥವಾ ರೋಡ್ ಮೋಡ್-ವಾರಿಯರ್‌ನಲ್ಲಿ ನಮ್ಮ ಕ್ಲೌಡ್‌ನಲ್ಲಿ IPSec/L2TP ಹೊಂದಿಸಲು ಮತ್ತು ಯಾರಾದರೂ ತಮ್ಮ ಸ್ವಂತ ವಿಂಡೋಸ್ ಸರ್ವರ್‌ನಲ್ಲಿ VPN ಸೇವೆಯನ್ನು ಹೊಂದಿಸಲು ಬಯಸಿದರೆ, ಅವರು ಯಾವಾಗಲೂ ಹೇಗೆ ಹೊಂದಿಸುವುದು ಎಂಬುದರ ಕುರಿತು ಸಲಹೆಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ಸಿದ್ಧರಾಗಿದ್ದಾರೆ ಪ್ರಮಾಣಿತ RAS ಅಥವಾ OpenVPN. ಆದರೆ, ನಾವು ಎಷ್ಟೇ ತಂಪಾಗಿದ್ದರೂ, ಗ್ರಾಹಕರಲ್ಲಿ ಶೈಕ್ಷಣಿಕ ಕೆಲಸವನ್ನು ನಡೆಸಲು ಇದು ಉತ್ತಮ ಸಮಯವಲ್ಲ, ಏಕೆಂದರೆ ಬಳಕೆದಾರರಿಗೆ ಕನಿಷ್ಠ ಒತ್ತಡದೊಂದಿಗೆ ನಾವು ಸಮಸ್ಯೆಯನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಸರಿಪಡಿಸಬೇಕಾಗಿದೆ.
ನಾವು ಜಾರಿಗೆ ತಂದ ಪರಿಹಾರವು ಈ ಕೆಳಗಿನಂತಿತ್ತು. ಪೋರ್ಟ್ 3389 ಗೆ TCP ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸುವ ಎಲ್ಲಾ ಪ್ರಯತ್ನಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಮತ್ತು 150 ಸೆಕೆಂಡುಗಳಲ್ಲಿ, ನಮ್ಮ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ 16 ಕ್ಕೂ ಹೆಚ್ಚು ವಿಭಿನ್ನ ಸರ್ವರ್‌ಗಳೊಂದಿಗೆ ಸಂಪರ್ಕಗಳನ್ನು ಸ್ಥಾಪಿಸಲು ಪ್ರಯತ್ನಿಸುವ ವಿಳಾಸಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ರೀತಿಯಲ್ಲಿ ನಾವು ಹಾದುಹೋಗುವ ದಟ್ಟಣೆಯ ವಿಶ್ಲೇಷಣೆಯನ್ನು ಹೊಂದಿಸಿದ್ದೇವೆ. - ಇವು ದಾಳಿಯ ಮೂಲಗಳಾಗಿವೆ ( ಸಹಜವಾಗಿ, ಗ್ರಾಹಕರು ಅಥವಾ ಪಾಲುದಾರರಲ್ಲಿ ಒಬ್ಬರು ಒಂದೇ ಮೂಲದಿಂದ ಹಲವಾರು ಸರ್ವರ್‌ಗಳೊಂದಿಗೆ ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸುವ ನಿಜವಾದ ಅಗತ್ಯವನ್ನು ಹೊಂದಿದ್ದರೆ, ನೀವು ಯಾವಾಗಲೂ ಅಂತಹ ಮೂಲಗಳನ್ನು "ಬಿಳಿ ಪಟ್ಟಿಗೆ" ಸೇರಿಸಬಹುದು. ಈ 150 ಸೆಕೆಂಡುಗಳ ಕಾಲ ಒಂದು ವರ್ಗ C ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ, 32 ಕ್ಕೂ ಹೆಚ್ಚು ವಿಳಾಸಗಳನ್ನು ಗುರುತಿಸಿದರೆ, ಸಂಪೂರ್ಣ ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ನಿರ್ಬಂಧಿಸಲು ಇದು ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ. ನಿರ್ಬಂಧಿಸುವಿಕೆಯನ್ನು 3 ದಿನಗಳವರೆಗೆ ಹೊಂದಿಸಲಾಗಿದೆ ಮತ್ತು ಈ ಸಮಯದಲ್ಲಿ ನೀಡಿದ ಮೂಲದಿಂದ ಯಾವುದೇ ದಾಳಿಯನ್ನು ನಡೆಸದಿದ್ದರೆ, ಈ ಮೂಲವನ್ನು "ಕಪ್ಪು ಪಟ್ಟಿಯಿಂದ" ಸ್ವಯಂಚಾಲಿತವಾಗಿ ತೆಗೆದುಹಾಕಲಾಗುತ್ತದೆ. ನಿರ್ಬಂಧಿಸಲಾದ ಮೂಲಗಳ ಪಟ್ಟಿಯನ್ನು ಪ್ರತಿ 300 ಸೆಕೆಂಡುಗಳಿಗೆ ನವೀಕರಿಸಲಾಗುತ್ತದೆ.
ಈ ಪಟ್ಟಿಯು ಈ ವಿಳಾಸದಲ್ಲಿ ಲಭ್ಯವಿದೆ: , ನೀವು ಅದರ ಆಧಾರದ ಮೇಲೆ ನಿಮ್ಮ ACL ಗಳನ್ನು ನಿರ್ಮಿಸಬಹುದು.
ಅಂತಹ ಸಿಸ್ಟಮ್ನ ಮೂಲ ಕೋಡ್ ಅನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ನಾವು ಸಿದ್ಧರಿದ್ದೇವೆ; ಅದರಲ್ಲಿ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾದ ಏನೂ ಇಲ್ಲ (ಇವುಗಳು ಮೊಣಕಾಲಿನ ಮೇಲೆ ಅಕ್ಷರಶಃ ಒಂದೆರಡು ಗಂಟೆಗಳಲ್ಲಿ ಸಂಕಲಿಸಲಾದ ಹಲವಾರು ಸರಳ ಸ್ಕ್ರಿಪ್ಟ್ಗಳು), ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ಅದನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳಬಹುದು ಮತ್ತು ಬಳಸಲಾಗುವುದಿಲ್ಲ ಅಂತಹ ದಾಳಿಯಿಂದ ರಕ್ಷಿಸಲು ಮಾತ್ರ, ಆದರೆ ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡುವ ಯಾವುದೇ ಪ್ರಯತ್ನಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಮತ್ತು ನಿರ್ಬಂಧಿಸಲು:
ಹೆಚ್ಚುವರಿಯಾಗಿ, ನಾವು ಮಾನಿಟರಿಂಗ್ ಸಿಸ್ಟಮ್ನ ಸೆಟ್ಟಿಂಗ್‌ಗಳಿಗೆ ಕೆಲವು ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಿದ್ದೇವೆ, ಇದು ಈಗ ನಮ್ಮ ಕ್ಲೌಡ್‌ನಲ್ಲಿನ ವರ್ಚುವಲ್ ಸರ್ವರ್‌ಗಳ ನಿಯಂತ್ರಣ ಗುಂಪಿನ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು RDP ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸುವ ಪ್ರಯತ್ನಕ್ಕೆ ಹೆಚ್ಚು ನಿಕಟವಾಗಿ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತದೆ: ಪ್ರತಿಕ್ರಿಯೆಯು ಒಂದು ಒಳಗೆ ಅನುಸರಿಸದಿದ್ದರೆ ಎರಡನೆಯದಾಗಿ, ಇದು ಗಮನ ಕೊಡಲು ಒಂದು ಕಾರಣವಾಗಿದೆ.
ಪರಿಹಾರವು ಸಾಕಷ್ಟು ಪರಿಣಾಮಕಾರಿಯಾಗಿದೆ: ಗ್ರಾಹಕರು ಮತ್ತು ಪಾಲುದಾರರಿಂದ ಮತ್ತು ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯಿಂದ ಹೆಚ್ಚಿನ ದೂರುಗಳಿಲ್ಲ. ಹೊಸ ವಿಳಾಸಗಳು ಮತ್ತು ಸಂಪೂರ್ಣ ನೆಟ್‌ವರ್ಕ್‌ಗಳನ್ನು ನಿಯಮಿತವಾಗಿ ಕಪ್ಪುಪಟ್ಟಿಗೆ ಸೇರಿಸಲಾಗುತ್ತದೆ, ಇದು ದಾಳಿಯು ಮುಂದುವರಿಯುತ್ತದೆ ಎಂದು ಸೂಚಿಸುತ್ತದೆ, ಆದರೆ ಇನ್ನು ಮುಂದೆ ನಮ್ಮ ಗ್ರಾಹಕರ ಕೆಲಸದ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ.
ಸಂಖ್ಯೆಯಲ್ಲಿ ಸುರಕ್ಷತೆ ಇದೆ
ಇತರ ನಿರ್ವಾಹಕರು ಇದೇ ರೀತಿಯ ಸಮಸ್ಯೆಯನ್ನು ಎದುರಿಸಿದ್ದಾರೆ ಎಂದು ಇಂದು ನಾವು ಕಲಿತಿದ್ದೇವೆ. ಮೈಕ್ರೋಸಾಫ್ಟ್ ರಿಮೋಟ್ ಆಕ್ಸೆಸ್ ಸೇವೆಯ ಕೋಡ್‌ಗೆ ಕೆಲವು ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಿದೆ ಎಂದು ಯಾರಾದರೂ ಇನ್ನೂ ನಂಬುತ್ತಾರೆ (ನಿಮಗೆ ನೆನಪಿದ್ದರೆ, ನಾವು ಮೊದಲ ದಿನದಲ್ಲಿ ಅದೇ ವಿಷಯವನ್ನು ಅನುಮಾನಿಸಿದ್ದೇವೆ, ಆದರೆ ನಾವು ಈ ಆವೃತ್ತಿಯನ್ನು ತ್ವರಿತವಾಗಿ ತಿರಸ್ಕರಿಸಿದ್ದೇವೆ) ಮತ್ತು ಪರಿಹಾರವನ್ನು ತ್ವರಿತವಾಗಿ ಕಂಡುಹಿಡಿಯಲು ಸಾಧ್ಯವಿರುವ ಎಲ್ಲವನ್ನೂ ಮಾಡುವುದಾಗಿ ಭರವಸೆ ನೀಡುತ್ತದೆ . ಕೆಲವು ಜನರು ಸಮಸ್ಯೆಯನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತಾರೆ ಮತ್ತು ಗ್ರಾಹಕರು ತಮ್ಮನ್ನು ತಾವು ರಕ್ಷಿಸಿಕೊಳ್ಳಲು ಸಲಹೆ ನೀಡುತ್ತಾರೆ (ಸಂಪರ್ಕ ಪೋರ್ಟ್ ಅನ್ನು ಬದಲಾಯಿಸಿ, ಖಾಸಗಿ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಸರ್ವರ್ ಅನ್ನು ಮರೆಮಾಡಿ ಮತ್ತು ಹೀಗೆ). ಮತ್ತು ಮೊದಲ ದಿನದಲ್ಲಿ, ನಾವು ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲಿಲ್ಲ, ಆದರೆ ನಾವು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಯೋಜಿಸಿರುವ ಹೆಚ್ಚು ಜಾಗತಿಕ ಬೆದರಿಕೆ ಪತ್ತೆ ವ್ಯವಸ್ಥೆಗಾಗಿ ಕೆಲವು ಅಡಿಪಾಯವನ್ನು ಸಹ ರಚಿಸಿದ್ದೇವೆ.
ಒಂದು ದಿನ ಶತ್ರುವಿನ ಶವವು ಅದರ ಉದ್ದಕ್ಕೂ ತೇಲುತ್ತದೆ ಎಂದು ನದಿಯ ದಡದಲ್ಲಿ ಕಾಯದೆ ಮೌನವಾಗಿ ಉಳಿಯದ ಗ್ರಾಹಕರು ಮತ್ತು ಪಾಲುದಾರರಿಗೆ ವಿಶೇಷ ಧನ್ಯವಾದಗಳು, ಆದರೆ ತಕ್ಷಣವೇ ನಮ್ಮ ಗಮನವನ್ನು ಸಮಸ್ಯೆಯತ್ತ ಸೆಳೆಯಿತು, ಅದು ನಮಗೆ ತೊಡೆದುಹಾಕಲು ಅವಕಾಶವನ್ನು ನೀಡಿತು. ಅದೇ ದಿನ.
ಮೂಲ: www.habr.com