sudo ਨਾਲ ਚਲਾਉਣ ਵੇਲੇ ਪੋਰਟ ਸਕੈਨ ਕਿਉਂ ਬਦਲਦਾ ਹੈ

Nmap ਹਮੇਸ਼ਾ ਉਹ ਪੈਕੇਟ ਨਹੀਂ ਭੇਜਦਾ ਜੋ ਤੁਸੀਂ ਸਮਝਦੇ ਹੋ ਕਿ ਤੁਸੀਂ ਮੰਗਿਆ ਸੀ। ਜਦੋਂ raw ਸਾਕਟ ਉਪਲਬਧ ਨਹੀਂ ਹੁੰਦੇ, ਇਹ ਡਿਫ਼ਾਲਟ SYN ਸਕੈਨ ਦੀ ਥਾਂ TCP connect ਸਕੈਨ ਲਗਾ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਤੁਹਾਡੇ ਆਮ ਵਰਤੋਂਕਾਰ ਵਜੋਂ ਚਲਾਉਣਾ ਅਤੇ sudo ਹੇਠ ਚਲਾਉਣਾ ਇੱਕੋ ਪੋਰਟ ਬਾਰੇ ਵੱਖਰੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇ ਸਕਦੇ ਹਨ। ਨਤੀਜੇ ਇਜਾਜ਼ਤ-ਸਮੱਸਿਆ ਵਰਗੇ ਲੱਗਦੇ ਹਨ, ਪਰ ਆਮ ਤੌਰ ’ਤੇ ਇਹ ਤਰੀਕੇ ਦੀ ਤਬਦੀਲੀ ਹੁੰਦੇ ਹਨ। ਤਰੀਕਾ ਸਪਸ਼ਟ ਕਰਨਾ ਹੀ ਦੋਵੇਂ ਰਨ ਦੀ ਤੁਲਨਾ ਕਰਨ ਦਾ ਇੱਕੋ ਇੱਕ ਢੰਗ ਹੈ।

ਦੋ ਪ੍ਰੋਬ, ਇੱਕ ਪੋਰਟ, ਵੱਖਰੇ ਕੋਡ-ਰਾਹ

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

raw ਰਾਹ ਲਈ CAP_NET_RAW ਲੋੜੀਂਦਾ ਹੈ, ਇਸ ਲਈ ਉਹ ਸਮਰੱਥਾ ਨਾ ਹੋਣ ’ਤੇ ਡਿਫ਼ਾਲਟ ਸਕੈਨ ਚੁੱਪਚਾਪ ਕਮਜ਼ੋਰ ਪੈਂਦਾ ਹੈ। Nmap ਦਾ ਆਪਣਾ ਸਕੈਨ-ਤਕਨੀਕ ਸੰਦਰਭ ਇਸ ਬਦਲੀ ਦਾ ਦਸਤਾਵੇਜ਼ ਹੈ: connect ਸਕੈਨ ਬਦਲ ਹੈ ਕਿਉਂਕਿ ਇਸਨੂੰ ਕੋਈ ਖ਼ਾਸ ਇਜਾਜ਼ਤ ਲੋੜੀਂਦੀ ਹੀ ਨਹੀਂ। ਬਹੁਤੇ ਰਨਾਂ ਵਿੱਚ ਇਹ ਅਦਲਾ-ਬਦਲੀ ਬਿਨਾਂ ਚੇਤਾਵਨੀ ਦੇ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਇਹੀ ਇਸਨੂੰ ਗਲਤ ਪੜ੍ਹਨਾ ਇੰਨਾ ਸੌਖਾ ਬਣਾਉਂਦਾ ਹੈ। ਇੱਕ ਵਾਰ ਪਤਾ ਲੱਗੇ ਕਿ ਬਦਲ ਮੌਜੂਦ ਹੈ, “root ਵਜੋਂ ਖੁੱਲ੍ਹਾ, ਵਰਤੋਂਕਾਰ ਵਜੋਂ ਬੰਦ” ਇਜਾਜ਼ਤ-ਬੱਗ ਵਰਗਾ ਸੁਣਨਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ ਅਤੇ ਦੋ ਵੱਖਰੇ ਮਾਪਾਂ ਵਰਗਾ ਸੁਣਨ ਲੱਗਦਾ ਹੈ।

ਸਕੈਨ ਵਿੱਚ sudo ਅਸਲ ਵਿੱਚ ਕੀ ਬਦਲਦਾ ਹੈ

ਇਜਾਜ਼ਤਾਂ ਵਧਾਉਣ ਨਾਲ raw ਸਾਕਟ ਦਾ ਰਾਹ ਵਾਪਸ ਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇਹ ਫ਼ੈਸਲੇ ਤੋਂ ਵੱਧ ਬਦਲਦਾ ਹੈ। ਸਰੋਤ ਪੋਰਟ ਦੀ ਚੋਣ, ਪੈਕੇਟ ਦਾ ਸਮਾਂ, ਦੁਬਾਰਾ ਭੇਜਣ ਦਾ ਵਿਵਹਾਰ ਅਤੇ ਫਿਲਟਰ ਕੀਤੇ ਜਵਾਬ ਦੀ ਸ਼੍ਰੇਣੀ—ਸਭ ਵੱਖਰੇ ਕੋਡ ਤੋਂ ਆਉਂਦੇ ਹਨ। SYN ਦੀ ਦਰ ਸੀਮਤ ਕਰਨ ਵਾਲਾ ਵਿਚਕਾਰਲਾ ਯੰਤਰ ਮੰਤਵ ਹੋਸਟ ਇੱਕੋ ਹੋਣ ’ਤੇ ਵੀ ਦੋਵੇਂ ਰਨਾਂ ਨਾਲ ਅਸਮਾਨ ਵਿਵਹਾਰ ਕਰਦਾ ਹੈ।

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

ਦੋਵੇਂ ਰਨਾਂ ਵਿੱਚ ਤਰੀਕਾ ਸਥਿਰ ਰੱਖੋ

ਦੋਵੇਂ ਕਾਲਾਂ ਵਿੱਚ ਉਹੀ ਤਕਨੀਕ ਜ਼ਬਰਦਸਤੀ ਵਰਤੋ ਅਤੇ ਤੁਲਨਾ ਦਾ ਕੋਈ ਅਰਥ ਬਣਨ ਲੱਗਦਾ ਹੈ। -sT ਫ਼ਲੈਗ connect ਸਕੈਨ ਸਪਸ਼ਟ ਮੰਗਦਾ ਹੈ, -Pn ਹੋਸਟ ਖੋਜ ਹਟਾਉਂਦਾ ਹੈ, -n ਨਾਮ-ਹੱਲ ਹਟਾਉਂਦਾ ਹੈ, ਅਤੇ ਇੱਕ -p ਪੋਰਟ-ਸੂਚੀ ਦੇ ਫ਼ਰਕ ਹਟਾਉਂਦਾ ਹੈ।

nmap -sT -Pn -n -p 8443 198.51.100.77
sudo nmap -sT -Pn -n -p 8443 198.51.100.77

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

ਖਾਤਾ-ਸੰਦਰਭ ਸਿਰਫ਼ ਇਜਾਜ਼ਤ-ਫ਼ਲੈਗ ਨਹੀਂ

VPN ਤੈਨਾਤੀ ਪੈਕੇਟਾਂ ਨੂੰ UID ਨਾਲ, cgroup ਨਾਲ, ਜਾਂ ਸਾਕਟ ਖੋਲ੍ਹਣ ਵਾਲੀ ਪ੍ਰਕਿਰਿਆ ਨਾਲ ਜੁੜੇ ਨਿਯਮ ਨਾਲ ਸ਼੍ਰੇਣੀਬੱਧ ਕਰ ਸਕਦੀ ਹੈ। ਫਿਰ root ਟ੍ਰੈਫ਼ਿਕ ਅਤੇ ਵਰਤੋਂਕਾਰ ਟ੍ਰੈਫ਼ਿਕ ਵੱਖਰੀਆਂ ਰਾਊਟਿੰਗ ਸਾਰਣੀਆਂ ਰਾਹੀਂ ਨਿਕਲਦੇ ਹਨ ਜਾਂ ਵੱਖਰੇ ਨਿਯਮ-ਸਮੂਹਾਂ ਨਾਲ ਟਕਰਾਉਂਦੇ ਹਨ, ਅਤੇ ਸਕੈਨ-ਤਰੀਕੇ ਦਾ ਕੋਈ ਅਨੁਸ਼ਾਸਨ ਉਨ੍ਹਾਂ ਨੂੰ ਨਹੀਂ ਮਿਲਾ ਸਕਦਾ।

ਇਜਾਜ਼ਤ ਨਹੀਂ, ਨੀਤੀ ਵੇਖੋ। Linux ਵਿੱਚ nftables ਇਸਨੂੰ meta skuid ਨਾਲ ਪ੍ਰਗਟ ਕਰਦਾ ਹੈ ਅਤੇ iptables ਮਾਲਕ-ਮੇਲ ਨਾਲ, ਅਤੇ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਇੱਕ UID ਨੂੰ ਸੁਰੰਗ ਵਿੱਚ ਭੇਜ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਦੂਜਾ ਭੌਤਿਕ ਡਿਫ਼ਾਲਟ ਰਾਹ ਵਰਤਦਾ ਰਹਿੰਦਾ ਹੈ।

sudo nft list ruleset | grep -n skuid
sudo iptables-save | grep -n uid-owner
ip rule show
ip route get 198.51.100.77

ਨਤੀਜਿਆਂ ਦੀ ਤੁਲਨਾ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰੋਬ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

ਸਿੱਟੇ ਕੱਢਣ ਤੋਂ ਪਹਿਲਾਂ ਸਾਬਤ ਕਰੋ ਕਿ ਕਿਹੜਾ ਪ੍ਰੋਬ ਚੱਲਿਆ। Nmap ਆਪਣੇ ਆਊਟਪੁੱਟ ਵਿੱਚ ਤਕਨੀਕ ਦਾ ਨਾਮ ਦੱਸਦਾ ਹੈ, ਅਤੇ --reason ਹਰ ਹਾਲਤ ਪਿੱਛੇ ਸਬੂਤ ਜੋੜਦਾ ਹੈ, ਅਤੇ ਉਹੀ ਹਿੱਸਾ ਦੱਸਦਾ ਹੈ ਕਿ ਹੈਂਡਸ਼ੇਕ ਸੱਚਮੁੱਚ ਪੂਰਾ ਹੋਇਆ ਜਾਂ ਨਹੀਂ।

nmap --reason -sT -Pn -n -p 8443 198.51.100.77
sudo nmap --reason -sS -Pn -n -p 8443 198.51.100.77
getcap "$(command -v nmap)"
capsh --print | grep -i net_raw

ਵੱਖਰੇ ਕਾਰਨਾਂ ਨਾਲ ਇੱਕੋ ਹਾਲਤ ਦੱਸਣ ਵਾਲੇ ਦੋ ਰਨ ਵਿਰੋਧਾਭਾਸ ਨਹੀਂ ਹਨ, ਅਤੇ ਇੱਕੋ ਕਾਰਨ ਨਾਲ ਵੱਖਰੀਆਂ ਹਾਲਤਾਂ ਦੱਸਣ ਵਾਲੇ ਦੋ ਰਨ ਸਕੈਨ ਵੱਲ ਨਹੀਂ, ਰਾਊਟਿੰਗ ਜਾਂ ਨੀਤੀ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ। ਮੰਤਵ, ਪੋਰਟ, ਨਾਮ-ਥਾਂ ਅਤੇ ਸਮਾਂ ਇੱਕੋ ਜਿਹੇ ਰੱਖੋ, ਫਿਰ ਇੱਕ ਵਾਰ ਵਿੱਚ ਇੱਕ ਚਰ ਬਦਲੋ। ਸੇਵਾ ਨੂੰ root ਵਜੋਂ ਚਲਾਉਣਾ ਨੀਤੀ-ਅਸੰਗਤੀ ਦਾ ਇਲਾਜ ਨਹੀਂ; ਇਲਾਜ ਇਹ ਹੈ ਕਿ ਇੱਛਤ ਨੀਤੀ ਸੇਵਾ ਦੇ ਮਾਲਕ ਰਾਹੀਂ ਪ੍ਰਗਟ ਕੀਤੀ ਜਾਵੇ।