ACK ਪੈਕੇਟ 'ਤੇ conntrack NEW: ਇਹ ਕੀ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ

ਫਾਇਰਵਾਲ ਲੌਗ ਵਿੱਚ ਇੱਕ ਲਾਈਨ ਹੈ ਜਿਸ ਦੀ ਤੁਸੀਂ ਉਮੀਦ ਨਹੀਂ ਸੀ ਕੀਤੀ: ਇੱਕ ACK ਪੈਕੇਟ, conntrack ਸਥਿਤੀ NEW, ਤੁਹਾਡਾ ਨਾ ਹੋਣ ਵਾਲਾ ਸਰੋਤ ਪਤਾ, ਟਿਕਾਣਾ ਪੋਰਟ ਖੁੱਲ੍ਹਾ। ਇਸ ਨੂੰ ਕਿਸੇ ਨਾ ਮਨਜ਼ੂਰ ਕੀਤੇ ਨਵੇਂ ਆਉਂਦੇ ਕਨੈਕਸ਼ਨ ਵਜੋਂ ਪੜ੍ਹਨ ਦਾ ਲਾਲਚ ਹੁੰਦਾ ਹੈ। ਲਾਈਨ ਅਸਲ ਵਿੱਚ ਜੋ ਕਹਿੰਦੀ ਹੈ ਉਹ ਵਧੇਰੇ ਤੰਗ ਹੈ: ਜਦੋਂ ਉਹ ਪੈਕੇਟ ਇਸ hook 'ਤੇ ਪਹੁੰਚਿਆ, ਟਰੈਕਰ ਕੋਲ ਮੇਲ ਖਾਂਦੀ ਕੋਈ ਸਥਿਤੀ ਨਹੀਂ ਸੀ, ਅਤੇ ਪੈਕੇਟ ACK ਲੈ ਕੇ ਆਇਆ ਸੀ। ਇਹ ਦੋ ਵੱਖਰੀਆਂ ਚੀਜ਼ਾਂ ਬਾਰੇ ਦੋ ਤੱਥ ਹਨ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਪੂਰੀ ਹੈਂਡਸ਼ੇਕ ਰਿਕਾਰਡ ਨਹੀਂ ਹੈ। ਸਿੱਟਾ ਕੱਢਣ ਤੋਂ ਪਹਿਲਾਂ ਮੈਂ ਜੋ ਕ੍ਰਮ ਅਪਣਾਉਂਦਾ ਹਾਂ ਉਹ ਇਹ ਹੈ।

ਫੈਸਲੇ ਤੋਂ ਨਹੀਂ, ਪੈਕੇਟ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ

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

ਇਹਨਾਂ ਤਿੰਨਾਂ ਨੂੰ ਮਿਲਾਉਣਾ ਹੀ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ACK “ਪ੍ਰੋਵਾਈਡਰ ਨੇ ਕਿਸੇ ਨੂੰ ਅੰਦਰ ਆਉਣ ਦਿੱਤਾ” ਬਣ ਜਾਂਦਾ ਹੈ।

hook 'ਤੇ NEW ਦਾ ਅਸਲ ਅਰਥ ਕੀ ਹੈ

iptables conntrack ਮਿਲਾਨ NEW ਨੂੰ ਅਜਿਹੇ ਪੈਕੇਟ ਵਜੋਂ ਦਰਜ ਕਰਦਾ ਹੈ ਜੋ ਕਨੈਕਸ਼ਨ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਜਾਂ ਅਜਿਹੇ ਕਨੈਕਸ਼ਨ ਨਾਲ ਜੁੜਿਆ ਪੈਕੇਟ ਜਿਸ ਨੇ ਅਜੇ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਟ੍ਰੈਫਿਕ ਨਹੀਂ ਵੇਖਿਆ। ESTABLISHED ਦਾ ਮਤਲਬ ਹੈ ਟਰੈਕਰ ਨੇ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਪੈਕੇਟ ਵੇਖੇ ਹਨ। ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਪਰਿਭਾਸ਼ਾ ਇਹ ਨਹੀਂ ਕਹਿੰਦੀ ਕਿ ਪੈਕੇਟ SYN ਸੀ, ਜਾਂ ਇਹ ਕਿ ਇਹ ਇਤਿਹਾਸ ਤੋਂ ਬਿਨਾਂ ਆਇਆ।

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

ਢਿੱਲੀ ਟਰੈਕਿੰਗ ਬਹੁਤੇ ACK ਹੈਰਾਨੀਆਂ ਦੀ ਵਿਆਖਿਆ ਕਰਦੀ ਹੈ

ਕਰਨਲ ਦਰਜ ਕਰਦਾ ਹੈ nf_conntrack_tcp_loose, ਜੋ ਟਰੈਕਰ ਨੂੰ ਅਜਿਹੇ TCP ਕਨੈਕਸ਼ਨ ਚੁੱਕਣ ਦਿੰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦੀ ਸ਼ੁਰੂਆਤ ਉਸ ਨੇ ਨਹੀਂ ਵੇਖੀ। ਸੈਟਿੰਗ ਆਪਣੇ ਡਿਫ਼ਾਲਟ ਮੁੱਲ 'ਤੇ ਹੋਣ 'ਤੇ, ਪ੍ਰਵਾਹ ਦੇ ਵਿਚਕਾਰੋਂ ਆਇਆ ACK ਸਥਾਪਿਤ ਪ੍ਰਵਾਹ ਵਜੋਂ ਸਵੀਕਾਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਇਸ ਨੂੰ ਬੰਦ ਕਰੋ, ਅਤੇ ਉਹੀ ਪੈਕੇਟ NEW ਦੀ ਬਜਾਏ INVALID ਵਜੋਂ ਸ਼੍ਰੇਣੀਬੱਧ ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਵੱਧ ਹੈ। ਦੋਵੇਂ ਨਤੀਜੇ ਟਰੈਕਰ ਦੇ ਨਿਯਮ ਦੱਸਦੇ ਹਨ, ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਇਤਿਹਾਸ ਨਹੀਂ।

ਇਸ ਲਈ ਲੇਬਲ 'ਤੇ ਸਿਧਾਂਤ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਸੈਟਿੰਗ ਜਾਂਚੋ।

ਉਬਾਉਣ ਵਾਲੇ ਕਾਰਨ ਇਸ ਕ੍ਰਮ ਵਿੱਚ ਬਾਹਰ ਰੱਖੋ

ਮੈਂ ਪਿੱਛਾ ਕੀਤੇ NEW-on-ACK ਸਮਾਗਮਾਂ ਵਿੱਚੋਂ ਬਹੁਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ 'ਤੇ ਖ਼ਤਮ ਹੋਏ, ਅਤੇ ਸਭ ਨੂੰ ਜਾਂਚਣਾ ਸਸਤਾ ਹੈ:

• conntrack ਸਾਰਣੀ ਫਲਸ਼ ਹੋਈ, ਜਾਂ ਟਰੈਕਰ ਮੁੜ ਸ਼ੁਰੂ ਹੋਇਆ।
• ਹੋਸਟ ਰੀਬੂਟ ਹੋਇਆ, ਜਾਂ ਪ੍ਰਵਾਹ ਕਿਸੇ ਹੋਰ namespace ਜਾਂ ਡਿਵਾਈਸ 'ਤੇ ਚਲਾ ਗਿਆ।
• ਅਸਮਮਿਤ ਰੂਟਿੰਗ ਨੇ SYN ਨੂੰ ਉਸ ਮਾਰਗ ਰਾਹੀਂ ਭੇਜਿਆ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਕੈਪਚਰ ਨਹੀਂ ਕਰ ਰਹੇ।
• NAT ਨੇ tuple ਮੁੜ ਲਿਖਿਆ, ਇਸ ਲਈ ਐਂਟਰੀ ਹੁਣ ਤੁਹਾਡੇ ਪੜ੍ਹੇ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੀ।
• ਕੈਪਚਰ ਦੇਰ ਨਾਲ ਸ਼ੁਰੂ ਹੋਇਆ ਅਤੇ ਸ਼ੁਰੂਆਤ ਕਦੇ ਨਹੀਂ ਵੇਖੀ।

ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਪਹਿਲਾਂ ਦੇ ਪੈਕੇਟਾਂ ਨੂੰ ਟਰੈਕਰ ਦੀ ਨਜ਼ਰ ਤੋਂ ਹਟਾ ਦਿੰਦਾ ਹੈ ਅਤੇ ਬਾਅਦ ਵਾਲਿਆਂ ਨੂੰ ਅਛੂਤ ਰਹਿਣ ਦਿੰਦਾ ਹੈ। ਰੀਬੂਟ ਜਾਂ ਸਾਰਣੀ ਫਲਸ਼ uptime ਅਤੇ ਲੌਗਾਂ ਤੋਂ ਪੁਸ਼ਟੀ ਕਰਨਾ ਸਭ ਤੋਂ ਸੌਖਾ ਹੈ। ਅਸਮਮਿਤ ਰੂਟਿੰਗ ਇੱਕ-ਦਿਸ਼ਾ ਕੈਪਚਰ ਵਜੋਂ ਦਿਸਦੀ ਹੈ। NAT ਚਲਾਕ ਹੈ, ਕਿਉਂਕਿ ਟਰੈਕਰ ਨੇ ਸੰਭਾਲਿਆ tuple ਲੌਗ ਵਿੱਚ ਛਾਪਿਆ tuple ਨਹੀਂ ਹੈ।

ਅੱਗੇ ਵਧਣ ਤੋਂ ਪਹਿਲਾਂ ਲਿਖੋ ਕਿ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕਿਹੜੇ ਬਾਹਰ ਰੱਖੇ ਅਤੇ ਕਿਵੇਂ।

tuple, ਇੰਟਰਫ਼ੇਸ ਅਤੇ hook ਪੜ੍ਹੋ

conntrack ਐਂਟਰੀ ਪਤਿਆਂ, ਪੋਰਟਾਂ ਅਤੇ ਪ੍ਰੋਟੋਕੋਲ 'ਤੇ ਕੁੰਜੀਬੱਧ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਕੋਈ ਵੀ ਅਨੁਵਾਦ ਬਦਲ ਦਿੰਦਾ ਹੈ ਕਿ ਕਿਹੜੀ ਐਂਟਰੀ ਮੇਲ ਖਾਂਦੀ ਹੈ। ਇੰਟਰਫ਼ੇਸ ਅਤੇ hook ਵੀ ਦਰਜ ਕਰੋ, ਕਿਉਂਕਿ ਗ਼ਲਤ ਇੰਟਰਫ਼ੇਸ 'ਤੇ ਜਾਂ ਕਿਸੇ ਹੋਰ ਚੇਨ ਤੋਂ ਬਾਅਦ ਦਿਸਿਆ ਪੈਕੇਟ ਦੱਸਦਾ ਹੈ ਕਿ ਮਾਰਗ ਚਿੱਤਰ ਵਿੱਚ ਦਿੱਤੇ ਜਿਹਾ ਨਹੀਂ ਹੈ। ਜਦੋਂ ਸਮਾਗਮ VPN ਨਾਲ ਸੰਬੰਧਿਤ ਹੋਵੇ, ਤੈਅ ਕਰੋ ਕਿ ਤੁਸੀਂ ਅੰਦਰਲਾ ਪੈਕੇਟ ਵੇਖ ਰਹੇ ਹੋ ਜਾਂ ਬਾਹਰਲਾ ਵਾਹਕ। ਫਿਰ ਉਸੇ ਪੰਜ-ਭਾਗ tuple ਲਈ ਗੇਟਵੇ ਨੇ ਜੋ ਦਰਜ ਕੀਤਾ ਉਸ ਨਾਲ ਤੁਲਨਾ ਕਰੋ।

ਇੱਕੋ ਪ੍ਰਵਾਹ ਦੇ ਦੋ ਵਿਰੋਧਾਭਾਸੀ ਦ੍ਰਿਸ਼ ਕਿਸੇ ਇੱਕ ਨਾਲੋਂ ਵੱਧ ਜਾਣਕਾਰੀ ਦਿੰਦੇ ਹਨ।

ਕਦੋਂ ਐਸਕਲੇਟ ਕਰਨਾ ਯੋਗ ਹੈ

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

ਫਿਰ ਉਹ ਦਿੱਖ ਅੰਤਰਾਲ ਬੰਦ ਕਰੋ ਜਿਸ ਨੇ ਇੱਕ ਪੈਕੇਟ ਨੂੰ ਪੂਰਾ ਸੈਸ਼ਨ ਵਰਗਾ ਦਿਸਣ ਦਿੱਤਾ।