ਥੋੜ੍ਹੇ ਚਿਰ ਲਈ IP ਆਗਿਆ-ਸੂਚੀ ਦੇ ਲਿੰਕ: ਆਗਿਆ ਅਸਲ ਵਿੱਚ ਕੀ ਮੰਨਦੀ ਹੈ

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

ਤੈਅ ਕਰੋ ਕਿ ਆਗਿਆ ਕਿਹੜੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ

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

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

ਸਰਵਰ 'ਤੇ ਬੇਨਤੀ ਸੀਮਤ ਕਰੋ

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

ਫਿਰ ਜਾਂਚੋ ਕਿ ਪੋਰਟਲ ਅਤੇ ਸੇਵਾ ਇੱਕੋ ਸਰੋਤ ਦੇਖਦੇ ਹਨ। ਵੰਡਿਆ ਟਨਲਿੰਗ, ਇੱਕ ਪ੍ਰੌਕਸੀ ਹੌਪ ਅਤੇ IPv4 ਬਨਾਮ IPv6 ਦੋ ਮੰਜ਼ਿਲਾਂ ਨੂੰ ਦੋ ਵੱਖਰੇ ਪਤੇ ਦੇ ਸਕਦੇ ਹਨ, ਇਸ ਲਈ ਇੱਕ ਰਾਹ ਤੋਂ ਸਰਗਰਮ ਕੀਤੀ ਆਗਿਆ ਅਗਲੀ ਬੇਨਤੀ ਨੂੰ ਨਹੀਂ ਢੱਕ ਸਕਦੀ।

ਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਆਗਿਆ ਦਿਖਾਓ

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

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

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

ਆਗਿਆ ਜੀਵਤ ਹੋਣ 'ਤੇ ਵੀ ਪਤਾ ਸਾਂਝਾ ਹੁੰਦਾ ਹੈ

ਦਫ਼ਤਰ NAT, ਕੈਰੀਅਰ NAT ਅਤੇ ਸਾਂਝਾ VPN ਨਿਕਾਸ ਹਰ ਇੱਕ ਕਈ ਲੋਕਾਂ ਨੂੰ ਇੱਕ ਪਤੇ ਪਿੱਛੇ ਰੱਖਦਾ ਹੈ। ਉਸ ਪਤੇ ਨੂੰ ਮੰਨਣਾ ਉਸ ਪਿੱਛੇ ਹਰ ਕਿਸੇ ਨੂੰ ਮੰਨਣਾ ਹੈ — ਸੇਵਾ ਦੀ ਅਗਲੀ ਹੱਦ ਤੱਕ —, ਜਦੋਂ ਕਿ ਸੇਵਾ ਜਿਸ ਖਾਤੇ ਦੀ ਆਸ ਰੱਖਦੀ ਹੈ ਉਹ ਕਿਸ ਕੋਲ ਹੈ ਇਸ ਦਾ ਕੋਈ ਸਬੂਤ ਨਹੀਂ ਦਿੰਦਾ।

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

ਚਾਰ ਹਾਲਾਤ ਅਤੇ ਦੋਨੋਂ ਪਤਾ-ਪਰਿਵਾਰ ਜਾਂਚੋ

ਆਗਿਆ ਓਨੀ ਹੀ ਚੰਗੀ ਹੈ ਜਿੰਨੇ ਚਾਰ ਹਾਲਾਤ ਇਹ ਝੱਲਦੀ ਹੈ: ਨਵੀਂ ਮਨਜ਼ੂਰ ਬੇਨਤੀ, ਨਾ-ਮਨਜ਼ੂਰ ਬੇਨਤੀਕਰਤਾ, ਉਸੇ ਲਿੰਕ ਦਾ ਦੁਹਰਾਓ, ਅਤੇ ਸਮਾਪਤੀ ਤੋਂ ਬਾਅਦ ਉਹੀ ਬੇਨਤੀ।

ਫਿਰ ਹਰ ਪਰਿਵਾਰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਸੇਵਾ ਜੋ ਸਰੋਤ-ਪਤਾ ਦੇਖਦੀ ਹੈ ਉਹ ਉਨ੍ਹਾਂ ਵਿਚਕਾਰ ਵੱਖਰਾ ਹੋ ਸਕਦਾ ਹੈ।

dig +short A service.example.com
dig +short AAAA service.example.com
curl -4 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com
curl -6 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com

ਲਾਭਕਾਰੀ ਨਤੀਜਾ ਆਮ ਵਰਤੋਂਕਾਰ-ਆਗਿਆ ਹੇਠਲਾ ਥੋੜ੍ਹੇ ਚਿਰ ਦਾ, ਆਡਿਟਯੋਗ ਸਵੀਕ੍ਰਿਤੀ ਫ਼ੈਸਲਾ ਹੈ, ਪਹਿਲਾਂ ਕਲਿੱਕ ਕਰਨ ਵਾਲੇ ਦਾ ਨਾਂ ਲੈ ਕੇ ਚੱਲਣ ਵਾਲਾ ਪੱਕਾ ਦਰਵਾਜ਼ਾ ਨਹੀਂ।