VPN ਸਰਵਰ 'ਤੇ ਆਉਣ ਵਾਲੀ ਚੇਤਾਵਨੀ: ਨਿਰੀਖਣ ਬਿੰਦੂ ਪੜ੍ਹੋ

VPN ਪਿੱਛੇ ਬੈਠਾ ਸਰਵਰ ਆਪਣੀਆਂ ਜਨਤਕ ਸੇਵਾ-ਇੰਦਰਾਜਾਂ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਲੋਕ ਉਹਨਾਂ ਨੂੰ ਲਗਾਤਾਰ ਲੱਭਦੇ ਰਹਿੰਦੇ ਹਨ। ਚੇਤਾਵਨੀ ਕਤਾਰ ਵਿੱਚ ਜੋ ਆਉਂਦਾ ਹੈ ਉਹ ਇੱਕ ਖੋਜ ਨਹੀਂ ਸਗੋਂ ਤਿੰਨ ਸੰਭਾਵੀ ਖੋਜਾਂ ਹਨ, ਅਤੇ ਉਹਨਾਂ ਦਾ ਅਰਥ ਵੱਖਰਾ ਹੈ। ਪਹਿਲਾ ਕੰਮ ਖੁੱਲ੍ਹੀ ਸੇਵਾ ਨੂੰ ਖੁੱਲ੍ਹੇ ਲੌਗਇਨ ਵੇਰਵਿਆਂ ਤੋਂ ਵੱਖ ਕਰਨਾ ਹੈ।

ਨਿਰੀਖਣ ਬਿੰਦੂਆਂ ਨੂੰ ਕ੍ਰਮ ਨਾਲ ਵੇਖੋ। ਜਦੋਂ ਸਬੂਤ ਆਪਣੀ ਸ਼੍ਰੇਣੀ ਬਦਲੇ ਤਾਂ ਰੁਕੋ, ਕਿਉਂਕਿ ਅਗਲਾ ਪੜਾਅ ਵੱਖਰੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ।

ਪਹਿਲਾ ਪੜਾਅ: ਕੈਪਚਰ ਨੇ ਅਸਲ ਵਿੱਚ ਕੀ ਵੇਖਿਆ

ਪੈਕਟ ਕੈਪਚਰ ਉਹ ਦਰਜ ਕਰਦਾ ਹੈ ਜੋ ਰਾਹ ਉੱਤੇ ਆਪਣੇ ਹੀ ਬਿੰਦੂ 'ਤੇ ਦਿਖਾਈ ਦਿੱਤਾ। ਉਹ ਬਿੰਦੂ ਬਾਅਦ ਦੇ ਫਿਲਟਰਿੰਗ ਫੈਸਲੇ ਤੋਂ ਪਹਿਲਾਂ ਹੋ ਸਕਦਾ ਹੈ। ਫੜਿਆ ਪੈਕਟ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਟ੍ਰੈਫਿਕ ਉੱਥੇ ਪਹੁੰਚਿਆ। ਇਹ ਬਾਅਦ ਵਿੱਚ ਕੀ ਹੋਇਆ, ਇਸ ਬਾਰੇ ਕੁਝ ਵੀ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ।

ਇੰਟਰਫੇਸ ਵੀ ਨੋਟ ਕਰੋ। ਜਨਤਕ ਅਡੈਪਟਰ 'ਤੇ ਕੈਪਚਰ ਅਤੇ ਟਨਲ ਦੇ ਅੰਦਰ ਕੈਪਚਰ ਵੱਖਰੇ ਆਗਮਨ ਬਿੰਦੂ ਦਰਸਾਉਂਦੇ ਹਨ, ਅਤੇ ਗਲਤ ਬਿੰਦੂ ਦਾ ਹਵਾਲਾ ਦੇਣ ਵਾਲੀ ਚੇਤਾਵਨੀ ਗਲਤ ਸਿੱਟੇ ਵੱਲ ਲੈ ਜਾਂਦੀ ਹੈ।

Windows ਸਟੈਕ ਦੀਆਂ ਕਈ ਪਰਤਾਂ 'ਤੇ ਫਿਲਟਰ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਇਹ ਸਾਫ਼ ਮਾਡਲ ਕਿ ਕੈਪਚਰ ਸਾਧਨ ਦੂਜੀ ਪਰਤ 'ਤੇ ਅਤੇ ਫਾਇਰਵਾਲ ਤੀਜੀ ਪਰਤ 'ਤੇ ਬੈਠਦਾ ਹੈ, ਅਸਲ ਉਤਪਾਦ ਨਾਲ ਟਕਰਾਉਣ 'ਤੇ ਟਿਕਦਾ ਨਹੀਂ। Windows Filtering Platform ਦਾ ਸੰਖੇਪ ਸਟੈਕ ਪਰਤਾਂ ਵਿੱਚ ਫਿਲਟਰਿੰਗ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਨਿਰੀਖਣ ਦਾ ਕ੍ਰਮ ਮੰਨਣਾ ਨਹੀਂ, ਸਥਾਪਿਤ ਕਰਨਾ ਪੈਂਦਾ ਹੈ।

ਦੂਜਾ ਪੜਾਅ: ਡਰਾਪ ਰਿਕਾਰਡ ਕੀ ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ

ਡਰਾਪ ਰਿਕਾਰਡ ਕਹਿੰਦਾ ਹੈ ਕਿ ਨੀਤੀ ਦੀ ਸੀਮਾ ਨੇ ਉਹ ਪੈਕਟ ਰੱਦ ਕੀਤਾ। ਇਹ ਮਜ਼ਬੂਤ ਸਬੂਤ ਹੈ। ਇਹ ਸੰਕੁਚਿਤ ਵੀ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਇੱਕ ਸੀਮਾ 'ਤੇ ਇੱਕ ਫੈਸਲੇ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ। ਸਟੈਕ ਵਿੱਚ ਹੋਰ ਕੋਈ ਵੀ ਚੀਜ਼ ਇਸ ਨਾਲ ਬਿਆਨ ਨਹੀਂ ਹੁੰਦੀ।

ਟੁਪਲ ਅਤੇ ਸਮਾਂ-ਛਾਪ 'ਤੇ ਮਿਲਾਣ ਕਰੋ। ਉਹੀ ਸਰੋਤ, ਉਹੀ ਮੰਜ਼ਿਲ, ਉਹੀ ਪੋਰਟ, ਉਸੇ ਸਕਿੰਟ ਦੇ ਅੰਦਰ। ਅਜਿਹਾ ਮਿਲਾਣ ਨਾ ਹੋਵੇ ਤਾਂ ਦੂਜੇ ਲੌਗ ਵਿੱਚ ਮਿਲਦੀ-ਜੁਲਦੀ ਘਟਨਾ ਬੱਸ ਇੱਕ ਹੋਰ ਘਟਨਾ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਜੋੜਨ ਨਾਲ ਇੱਕ ਅਜਿਹੀ ਕਹਾਣੀ ਬਣਦੀ ਹੈ ਜਿਸਦਾ ਕੋਈ ਬਚਾਅ ਨਹੀਂ ਕਰ ਸਕਦਾ।

# what did the firewall actually drop, and when?
Get-NetFirewallProfile -PolicyStore ActiveStore | Select-Object Name, LogAllowed, LogBlocked
Get-Content "$env:systemroot\System32\LogFiles\Firewall\pfirewall.log" | Select-String 'DROP'

# correlate with a listening service on the same port
Get-NetTCPConnection -LocalPort 3389 -State Listen | Select-Object LocalAddress, OwningProcess

ਬੰਦ ਪੋਰਟ ਅਤੇ ਰੱਦ ਕੀਤਾ ਪੈਕਟ ਬਾਹਰੋਂ ਇੱਕੋ ਜਿਹੇ ਦਿਸਦੇ ਹਨ ਅਤੇ ਇਹਨਾਂ ਦੋ ਨਤੀਜਿਆਂ ਵਿੱਚ ਬਿਲਕੁਲ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ। ਸਥਾਨਕ ਰਿਕਾਰਡ ਪੜ੍ਹਨ ਦਾ ਪੂਰਾ ਕਾਰਨ ਉਹੀ ਅੰਤਰ ਹੈ।

ਤੀਜਾ ਪੜਾਅ: ਪ੍ਰਮਾਣਿਕਤਾ ਘਟਨਾ ਕੀ ਸਾਬਤ ਕਰਦੀ ਹੈ

ਪ੍ਰਮਾਣਿਕਤਾ ਘਟਨਾ ਕਹਿੰਦੀ ਹੈ ਕਿ ਕਿਸੇ ਕੰਪੋਨੈਂਟ ਨੇ ਬੇਨਤੀ ਨੂੰ ਨਤੀਜਾ ਦਰਜ ਕਰਨ ਲੱਗਿਆਂ ਤੱਕ ਪ੍ਰੋਸੈਸ ਕੀਤਾ। ਤਿੰਨ ਪੜਾਵਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇਹੀ ਪਛਾਣ ਬਾਰੇ ਬੋਲਦੀ ਹੈ, ਅਤੇ ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿੰਨੇ ਪੈਕਟ ਆਏ, ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦੀ।

ਘਟਨਾ ਦਾ ਅਸਲ ਸੰਦਰਭ ਪੜ੍ਹੋ। ਜਿਸ ਖਾਤੇ ਦਾ ਵਜੂਦ ਹੀ ਨਹੀਂ, ਉਸ ਲਈ ਅਸਫਲ ਲੌਗਇਨ ਸਕੈਨਿੰਗ ਦਾ ਸ਼ੋਰ ਹੈ। ਭਰੋਸੇਯੋਗ ਸਰੋਤ ਵਾਲੇ ਅਸਲ ਖਾਤੇ ਲਈ ਅਸਫਲ ਲੌਗਇਨ ਵੱਖਰੀ ਤਰਜੀਹ ਹੈ। ਸਫਲ ਸੈਸ਼ਨ ਬਿਲਕੁਲ ਵੱਖਰੀ ਘਟਨਾ-ਸ਼੍ਰੇਣੀ ਹੈ।

ਪ੍ਰੋਟੋਕੋਲ ਦੇ ਨਾਮ ਵੀ ਵੇਖੋ। RPC ਅਤੇ RDP ਵੱਖਰੇ ਪੋਰਟਾਂ ਵਾਲੀਆਂ ਵੱਖਰੀਆਂ ਸੇਵਾਵਾਂ ਹਨ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ 'ਤੇ ਨਜ਼ਰ ਰੱਖਣ ਵਾਲਾ ਡਿਟੈਕਟਰ ਦੂਜੇ ਨੂੰ ਕਵਰ ਨਹੀਂ ਕਰਦਾ। ਨੈੱਟਵਰਕ ਗਤੀਵਿਧੀ ਦਾ ਸੰਖੇਪ ਦੇਣ ਵਾਲੇ ਸਾਧਨ ਹਮੇਸ਼ਾ ਨਹੀਂ ਦੱਸਦੇ ਕਿ ਘਟਨਾ ਇਹਨਾਂ ਦੋਹਾਂ ਵਿੱਚੋਂ ਕਿਸ ਨੇ ਪੈਦਾ ਕੀਤੀ।

ਇੱਕ ਮਿਲਾਇਆ ਨਮੂਨਾ ਡੈਸ਼ਬੋਰਡ ਨਾਲੋਂ ਬਿਹਤਰ

ਇੱਕ ਅਧਿਕਾਰਤ ਟੈਸਟ ਚੁਣੋ, ਉਹਨੂੰ ਜਾਣ-ਬੁੱਝ ਕੇ ਚਲਾਓ, ਅਤੇ ਸ਼ੁਰੂ ਤੋਂ ਅੰਤ ਤੱਕ ਪਿੱਛਾ ਕਰੋ: ਮੰਜ਼ਿਲ ਪਤਾ ਅਤੇ ਇੰਟਰਫੇਸ, ਅਸਲ ਸਰੋਤ ਪਤਾ, ਸੇਵਾ ਪੋਰਟ, ਪ੍ਰਭਾਵੀ ਫਾਇਰਵਾਲ ਪ੍ਰੋਫਾਈਲ ਅਤੇ ਨਿਯਮ, ਅਤੇ ਮਿਲਦਾ ਸੇਵਾ-ਨਤੀਜਾ। ਉਸ ਲੜੀ ਵਿੱਚ ਉੱਪਰਲਾ ਮੈਪਿੰਗ ਜਾਂ ਕਲਾਉਡ ਫਾਇਰਵਾਲ ਵੀ ਸ਼ਾਮਲ ਕਰੋ, ਕਿਉਂਕਿ ਉੱਥੋਂ ਦਾ ਆਗਿਆ ਦੇਣ ਵਾਲਾ ਨਿਯਮ ਸਾਫ਼ ਸਥਾਨਕ ਨਿਯਮ ਨੂੰ ਬੇਅਸਰ ਕਰ ਸਕਦਾ ਹੈ।

ਫਿਰ ਦੋ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਵੱਖ ਕਰੋ। ਜੇ ਪ੍ਰਸ਼ਾਸਨ ਸਿਰਫ਼ VPN ਰਾਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਇਹ ਜਨਤਕ ਅਤੇ ਟਨਲ ਦੋਹਾਂ ਰਾਹਾਂ 'ਤੇ ਲਾਗੂ ਕਰੋ ਅਤੇ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਰਿਕਵਰੀ ਰਾਹ ਰੱਖੋ। ਰੱਦ ਕੀਤੀ ਕੋਸ਼ਿਸ਼ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨਾ ਸਰਵਰ ਨੂੰ ਕੀ ਸਵੀਕਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਇਹ ਤੈਅ ਕਰਨ ਵਾਲਾ ਉਹੀ ਕੰਮ ਨਹੀਂ ਹੈ।

ਭੂਗੋਲਿਕ ਨਿਯਮ ਜਾਂ ਰੋਕਿਆ ਗਿਆ ਅਸੰਬੰਧਿਤ ਪ੍ਰੋਟੋਕੋਲ ਨਿਰੀਖਣ ਵਿੱਚ ਆਈ ਇੰਦਰਾਜ ਅਤੇ ਉਸ ਨੂੰ ਮਿਲੇ ਫੈਸਲੇ ਨੂੰ ਲੱਭਣ ਦਾ ਬਦਲ ਨਹੀਂ ਹੈ। VPN ਵੀ ਨਹੀਂ: ਬਾਹਰ ਜਾਂਦਾ ਟ੍ਰੈਫਿਕ ਟਨਲ ਰਾਹੀਂ ਭੇਜਣਾ ਅੰਦਰ ਆਉਣ ਵਾਲੀ ਅਧਿਕਾਰਤਾ ਬਾਰੇ ਕੁਝ ਵੀ ਦਰਜ ਨਹੀਂ ਕਰਦਾ।