ਆਉ ਤੁਹਾਨੂੰ ਇੱਕ ਵਧੀਆ ਕਹਾਣੀ ਦੱਸੀਏ ਕਿ ਕਿਵੇਂ "ਤੀਜੀ ਧਿਰਾਂ" ਨੇ ਸਾਡੇ ਗਾਹਕਾਂ ਦੇ ਕੰਮ ਵਿੱਚ ਦਖਲ ਦੇਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ, ਅਤੇ ਇਹ ਸਮੱਸਿਆ ਕਿਵੇਂ ਹੱਲ ਕੀਤੀ ਗਈ ਸੀ।
ਇਹ ਸਭ ਕਿਵੇਂ ਸ਼ੁਰੂ ਹੋਇਆ
ਇਹ ਸਭ 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 ਕੁਨੈਕਸ਼ਨਾਂ ਨੂੰ ਵਧਾਉਣਾ ਜਿਨ੍ਹਾਂ ਨੇ ਉਹਨਾਂ ਨੂੰ ਨਹੀਂ ਉਠਾਇਆ - ਸ਼ਾਇਦ ਅਜਿਹੀ ਖੁਸ਼ੀ ਗਾਹਕਾਂ 'ਤੇ ਵੀ ਮੁਸਕਰਾ ਨਹੀਂ ਪਾਉਂਦੀ ਹੈ. ਹਾਲਾਂਕਿ, ਮੈਨੂੰ ਜ਼ਰੂਰ ਕਹਿਣਾ ਚਾਹੀਦਾ ਹੈ, ਇਹ ਕਿਸੇ ਵੀ ਸਥਿਤੀ ਵਿੱਚ ਇੱਕ ਧਰਮੀ ਚੀਜ਼ ਹੈ, ਅਸੀਂ ਹਮੇਸ਼ਾਂ ਇੱਕ ਨਿੱਜੀ ਨੈਟਵਰਕ ਵਿੱਚ ਸਰਵਰ ਨੂੰ ਲੁਕਾਉਣ ਦੀ ਸਿਫਾਰਸ਼ ਕਰਦੇ ਹਾਂ ਅਤੇ ਸੈਟਿੰਗਾਂ ਵਿੱਚ ਮਦਦ ਕਰਨ ਲਈ ਤਿਆਰ ਹਾਂ, ਅਤੇ ਉਹਨਾਂ ਲਈ ਜੋ ਆਪਣੇ ਆਪ ਇਸਦਾ ਪਤਾ ਲਗਾਉਣਾ ਚਾਹੁੰਦੇ ਹਨ, ਅਸੀਂ ਨਿਰਦੇਸ਼ ਸਾਂਝੇ ਕਰਦੇ ਹਾਂ ਸਾਈਟ-ਟੂ-ਸਾਈਟ ਜਾਂ ਰੋਡ ਮੋਡ ਵਿੱਚ ਸਾਡੇ ਕਲਾਉਡ ਵਿੱਚ IPSec/L2TP ਸੈਟ ਅਪ ਕਰਨ ਲਈ, ਅਤੇ ਜੇਕਰ ਕੋਈ ਆਪਣੇ ਵਿੰਡੋਜ਼ ਸਰਵਰ 'ਤੇ ਇੱਕ VPN ਸੇਵਾ ਸੈਟ ਅਪ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ, ਤਾਂ ਉਹ ਇੱਕ ਸੈਟ ਅਪ ਕਰਨ ਬਾਰੇ ਸੁਝਾਅ ਸਾਂਝੇ ਕਰਨ ਲਈ ਹਮੇਸ਼ਾ ਤਿਆਰ ਹਨ ਮਿਆਰੀ RAS ਜਾਂ OpenVPN। ਪਰ, ਭਾਵੇਂ ਅਸੀਂ ਕਿੰਨੇ ਵੀ ਠੰਡੇ ਸੀ, ਇਹ ਗਾਹਕਾਂ ਵਿੱਚ ਵਿਦਿਅਕ ਕੰਮ ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਵਧੀਆ ਸਮਾਂ ਨਹੀਂ ਸੀ, ਕਿਉਂਕਿ ਸਾਨੂੰ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਘੱਟ ਤੋਂ ਘੱਟ ਤਣਾਅ ਦੇ ਨਾਲ ਸਮੱਸਿਆ ਨੂੰ ਜਲਦੀ ਤੋਂ ਜਲਦੀ ਹੱਲ ਕਰਨ ਦੀ ਲੋੜ ਸੀ।
ਅਸੀਂ ਜੋ ਹੱਲ ਲਾਗੂ ਕੀਤਾ ਹੈ ਉਹ ਹੇਠ ਲਿਖੇ ਅਨੁਸਾਰ ਸੀ। ਅਸੀਂ ਪੋਰਟ 3389 'ਤੇ ਇੱਕ TCP ਕਨੈਕਸ਼ਨ ਸਥਾਪਤ ਕਰਨ ਦੀਆਂ ਸਾਰੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਲਈ ਇਸ ਤਰੀਕੇ ਨਾਲ ਟਰੈਫਿਕ ਨੂੰ ਪਾਸ ਕਰਨ ਦਾ ਇੱਕ ਵਿਸ਼ਲੇਸ਼ਣ ਸਥਾਪਤ ਕੀਤਾ ਹੈ ਅਤੇ ਇਸ ਵਿੱਚੋਂ ਪਤਾ ਚੁਣਿਆ ਹੈ ਕਿ, 150 ਸਕਿੰਟਾਂ ਦੇ ਅੰਦਰ, ਸਾਡੇ ਨੈੱਟਵਰਕ 'ਤੇ 16 ਤੋਂ ਵੱਧ ਵੱਖ-ਵੱਖ ਸਰਵਰਾਂ ਨਾਲ ਕਨੈਕਸ਼ਨ ਸਥਾਪਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ। - ਇਹ ਹਮਲੇ ਦੇ ਸਰੋਤ ਹਨ ( ਬੇਸ਼ੱਕ, ਜੇਕਰ ਕਿਸੇ ਇੱਕ ਗਾਹਕ ਜਾਂ ਭਾਈਵਾਲ ਨੂੰ ਇੱਕੋ ਸਰੋਤ ਤੋਂ ਬਹੁਤ ਸਾਰੇ ਸਰਵਰਾਂ ਨਾਲ ਕਨੈਕਸ਼ਨ ਸਥਾਪਤ ਕਰਨ ਦੀ ਅਸਲ ਲੋੜ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਹਮੇਸ਼ਾ ਅਜਿਹੇ ਸਰੋਤਾਂ ਨੂੰ "ਵਾਈਟ ਲਿਸਟ" ਵਿੱਚ ਸ਼ਾਮਲ ਕਰ ਸਕਦੇ ਹੋ। ਜੇਕਰ ਇਹਨਾਂ 150 ਸਕਿੰਟਾਂ ਲਈ ਇੱਕ ਕਲਾਸ C ਨੈੱਟਵਰਕ ਵਿੱਚ, 32 ਤੋਂ ਵੱਧ ਪਤਿਆਂ ਦੀ ਪਛਾਣ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਇਹ ਪੂਰੇ ਨੈੱਟਵਰਕ ਨੂੰ ਬਲੌਕ ਕਰਨ ਦਾ ਮਤਲਬ ਸਮਝਦਾ ਹੈ। ਬਲਾਕਿੰਗ 3 ਦਿਨਾਂ ਲਈ ਸੈੱਟ ਕੀਤੀ ਗਈ ਹੈ, ਅਤੇ ਜੇਕਰ ਇਸ ਸਮੇਂ ਦੌਰਾਨ ਕਿਸੇ ਦਿੱਤੇ ਸਰੋਤ ਤੋਂ ਕੋਈ ਹਮਲਾ ਨਹੀਂ ਕੀਤਾ ਗਿਆ, ਇਹ ਸਰੋਤ ਆਪਣੇ ਆਪ "ਕਾਲੀ ਸੂਚੀ" ਵਿੱਚੋਂ ਹਟਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਬਲੌਕ ਕੀਤੇ ਸਰੋਤਾਂ ਦੀ ਸੂਚੀ ਹਰ 300 ਸਕਿੰਟਾਂ ਵਿੱਚ ਅੱਪਡੇਟ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।
ਇਹ ਸੂਚੀ ਇਸ ਪਤੇ 'ਤੇ ਉਪਲਬਧ ਹੈ: , ਤੁਸੀਂ ਇਸਦੇ ਆਧਾਰ 'ਤੇ ਆਪਣੇ ACLs ਬਣਾ ਸਕਦੇ ਹੋ।
ਅਸੀਂ ਅਜਿਹੀ ਪ੍ਰਣਾਲੀ ਦੇ ਸਰੋਤ ਕੋਡ ਨੂੰ ਸਾਂਝਾ ਕਰਨ ਲਈ ਤਿਆਰ ਹਾਂ; ਇਸ ਵਿੱਚ ਕੁਝ ਵੀ ਬਹੁਤ ਜ਼ਿਆਦਾ ਗੁੰਝਲਦਾਰ ਨਹੀਂ ਹੈ (ਇਹ ਕਈ ਸਧਾਰਨ ਸਕ੍ਰਿਪਟਾਂ ਹਨ ਜੋ ਸ਼ਾਬਦਿਕ ਤੌਰ 'ਤੇ ਗੋਡੇ 'ਤੇ ਕੁਝ ਘੰਟਿਆਂ ਵਿੱਚ ਕੰਪਾਇਲ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ), ਅਤੇ ਉਸੇ ਸਮੇਂ ਇਸ ਨੂੰ ਅਨੁਕੂਲਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ ਵਰਤਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ. ਸਿਰਫ ਅਜਿਹੇ ਹਮਲੇ ਤੋਂ ਬਚਾਉਣ ਲਈ, ਪਰ ਨੈਟਵਰਕ ਨੂੰ ਸਕੈਨ ਕਰਨ ਦੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ ਨੂੰ ਖੋਜਣ ਅਤੇ ਰੋਕਣ ਲਈ ਵੀ:
ਇਸ ਤੋਂ ਇਲਾਵਾ, ਅਸੀਂ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਦੀਆਂ ਸੈਟਿੰਗਾਂ ਵਿੱਚ ਕੁਝ ਬਦਲਾਅ ਕੀਤੇ ਹਨ, ਜੋ ਹੁਣ ਸਾਡੇ ਕਲਾਉਡ ਵਿੱਚ ਇੱਕ ਆਰਡੀਪੀ ਕਨੈਕਸ਼ਨ ਸਥਾਪਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਲਈ ਵਰਚੁਅਲ ਸਰਵਰਾਂ ਦੇ ਇੱਕ ਨਿਯੰਤਰਣ ਸਮੂਹ ਦੀ ਪ੍ਰਤੀਕ੍ਰਿਆ ਦੀ ਵਧੇਰੇ ਧਿਆਨ ਨਾਲ ਨਿਗਰਾਨੀ ਕਰਦਾ ਹੈ: ਜੇਕਰ ਪ੍ਰਤੀਕ੍ਰਿਆ ਇੱਕ ਦੇ ਅੰਦਰ ਨਹੀਂ ਚੱਲਦੀ ਹੈ ਦੂਜਾ, ਇਹ ਧਿਆਨ ਦੇਣ ਦਾ ਇੱਕ ਕਾਰਨ ਹੈ।
ਹੱਲ ਕਾਫ਼ੀ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਸਾਬਤ ਹੋਇਆ: ਗ੍ਰਾਹਕਾਂ ਅਤੇ ਭਾਈਵਾਲਾਂ ਅਤੇ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਦੋਵਾਂ ਤੋਂ ਕੋਈ ਹੋਰ ਸ਼ਿਕਾਇਤਾਂ ਨਹੀਂ ਹਨ. ਨਵੇਂ ਪਤੇ ਅਤੇ ਪੂਰੇ ਨੈੱਟਵਰਕਾਂ ਨੂੰ ਬਲੈਕਲਿਸਟ ਵਿੱਚ ਨਿਯਮਿਤ ਤੌਰ 'ਤੇ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜੋ ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਹਮਲਾ ਜਾਰੀ ਹੈ, ਪਰ ਹੁਣ ਸਾਡੇ ਗਾਹਕਾਂ ਦੇ ਕੰਮ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਕਰੇਗਾ।
ਗਿਣਤੀ ਵਿੱਚ ਸੁਰੱਖਿਆ ਹੈ
ਅੱਜ ਅਸੀਂ ਸਿੱਖਿਆ ਹੈ ਕਿ ਹੋਰ ਓਪਰੇਟਰਾਂ ਨੂੰ ਵੀ ਅਜਿਹੀ ਸਮੱਸਿਆ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ ਹੈ। ਕੋਈ ਅਜੇ ਵੀ ਵਿਸ਼ਵਾਸ ਕਰਦਾ ਹੈ ਕਿ ਮਾਈਕ੍ਰੋਸਾੱਫਟ ਨੇ ਰਿਮੋਟ ਐਕਸੈਸ ਸੇਵਾ ਦੇ ਕੋਡ ਵਿੱਚ ਕੁਝ ਬਦਲਾਅ ਕੀਤੇ ਹਨ (ਜੇ ਤੁਹਾਨੂੰ ਯਾਦ ਹੈ, ਸਾਨੂੰ ਪਹਿਲੇ ਦਿਨ ਇਹੀ ਸ਼ੱਕ ਸੀ, ਪਰ ਅਸੀਂ ਇਸ ਸੰਸਕਰਣ ਨੂੰ ਬਹੁਤ ਜਲਦੀ ਰੱਦ ਕਰ ਦਿੱਤਾ) ਅਤੇ ਜਲਦੀ ਹੱਲ ਲੱਭਣ ਲਈ ਹਰ ਸੰਭਵ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦਾ ਵਾਅਦਾ ਕੀਤਾ। . ਕੁਝ ਲੋਕ ਸਿਰਫ਼ ਸਮੱਸਿਆ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੇ ਹਨ ਅਤੇ ਗਾਹਕਾਂ ਨੂੰ ਸਲਾਹ ਦਿੰਦੇ ਹਨ ਕਿ ਉਹ ਆਪਣੇ ਆਪ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਨ (ਕੁਨੈਕਸ਼ਨ ਪੋਰਟ ਬਦਲੋ, ਸਰਵਰ ਨੂੰ ਇੱਕ ਪ੍ਰਾਈਵੇਟ ਨੈਟਵਰਕ ਵਿੱਚ ਲੁਕਾਓ, ਅਤੇ ਹੋਰ)। ਅਤੇ ਪਹਿਲੇ ਹੀ ਦਿਨ, ਅਸੀਂ ਨਾ ਸਿਰਫ਼ ਇਸ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਕੀਤਾ, ਸਗੋਂ ਇੱਕ ਹੋਰ ਵਿਸ਼ਵਵਿਆਪੀ ਖਤਰੇ ਦਾ ਪਤਾ ਲਗਾਉਣ ਵਾਲੀ ਪ੍ਰਣਾਲੀ ਲਈ ਕੁਝ ਆਧਾਰ ਬਣਾਇਆ ਹੈ ਜਿਸ ਨੂੰ ਅਸੀਂ ਵਿਕਸਤ ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾ ਰਹੇ ਹਾਂ।
ਗਾਹਕਾਂ ਅਤੇ ਭਾਈਵਾਲਾਂ ਦਾ ਵਿਸ਼ੇਸ਼ ਧੰਨਵਾਦ ਜੋ ਚੁੱਪ ਨਹੀਂ ਰਹੇ ਅਤੇ ਦਰਿਆ ਦੇ ਕੰਢੇ 'ਤੇ ਇਕ ਦਿਨ ਦੁਸ਼ਮਣ ਦੀ ਲਾਸ਼ ਦੀ ਉਡੀਕ ਕਰਨ ਲਈ ਨਹੀਂ ਬੈਠੇ, ਪਰ ਤੁਰੰਤ ਇਸ ਸਮੱਸਿਆ ਵੱਲ ਸਾਡਾ ਧਿਆਨ ਖਿੱਚਿਆ, ਜਿਸ ਨਾਲ ਸਾਨੂੰ ਇਸ ਨੂੰ ਖਤਮ ਕਰਨ ਦਾ ਮੌਕਾ ਮਿਲਿਆ। ਇਸ ਨੂੰ ਉਸੇ ਦਿਨ 'ਤੇ.
ਸਰੋਤ: www.habr.com