ਅਸੀਂ XDP 'ਤੇ DDoS ਹਮਲਿਆਂ ਤੋਂ ਸੁਰੱਖਿਆ ਲਿਖਦੇ ਹਾਂ। ਪ੍ਰਮਾਣੂ ਹਿੱਸਾ

ਐਕਸਪ੍ਰੈਸ ਡੇਟਾ ਪਾਥ (XDP) ਤਕਨਾਲੋਜੀ ਲੀਨਕਸ ਇੰਟਰਫੇਸ ਉੱਤੇ ਪੈਕੇਟ ਕਰਨਲ ਨੈਟਵਰਕ ਸਟੈਕ ਵਿੱਚ ਦਾਖਲ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਟ੍ਰੈਫਿਕ ਦੀ ਮਨਮਾਨੀ ਪ੍ਰਕਿਰਿਆ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ। XDP ਐਪਲੀਕੇਸ਼ਨ - DDoS ਹਮਲਿਆਂ (CloudFlare), ਗੁੰਝਲਦਾਰ ਫਿਲਟਰ, ਅੰਕੜੇ ਸੰਗ੍ਰਹਿ (Netflix) ਤੋਂ ਸੁਰੱਖਿਆ। XDP ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ eBPF ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਦੁਆਰਾ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ, ਇਸਲਈ ਫਿਲਟਰ ਦੀ ਕਿਸਮ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋਏ, ਉਹਨਾਂ ਦੇ ਕੋਡ ਅਤੇ ਉਪਲਬਧ ਕਰਨਲ ਫੰਕਸ਼ਨਾਂ ਦੋਵਾਂ 'ਤੇ ਪਾਬੰਦੀਆਂ ਹਨ।

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

ਇਸ ਹਿੱਸੇ ਵਿੱਚ, ਅਸੀਂ ਵਿਸਥਾਰ ਵਿੱਚ ਸਮਝਾਂਗੇ ਕਿ XDP ਫਿਲਟਰ ਨੂੰ ਕਿਵੇਂ ਅਸੈਂਬਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਕਿਵੇਂ ਟੈਸਟ ਕਰਨਾ ਹੈ, ਫਿਰ ਅਸੀਂ ਪੈਕੇਟ ਪ੍ਰੋਸੈਸਿੰਗ ਪੱਧਰ 'ਤੇ ਜਾਣੇ-ਪਛਾਣੇ SYN ਕੂਕੀਜ਼ ਵਿਧੀ ਦਾ ਇੱਕ ਸਧਾਰਨ ਸੰਸਕਰਣ ਲਿਖਾਂਗੇ। ਜਦੋਂ ਤੱਕ ਅਸੀਂ "ਵਾਈਟ ਲਿਸਟ" ਨਹੀਂ ਬਣਾਉਂਦੇ
ਪ੍ਰਮਾਣਿਤ ਗਾਹਕ, ਕਾਊਂਟਰ ਰੱਖੋ ਅਤੇ ਫਿਲਟਰ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰੋ - ਕਾਫ਼ੀ ਲੌਗ।

ਅਸੀਂ C ਵਿੱਚ ਲਿਖਾਂਗੇ - ਇਹ ਫੈਸ਼ਨੇਬਲ ਨਹੀਂ ਹੈ, ਪਰ ਵਿਹਾਰਕ ਹੈ. ਸਾਰੇ ਕੋਡ ਅੰਤ ਵਿੱਚ ਲਿੰਕ 'ਤੇ GitHub 'ਤੇ ਉਪਲਬਧ ਹਨ ਅਤੇ ਲੇਖ ਵਿੱਚ ਦੱਸੇ ਗਏ ਕਦਮਾਂ ਦੇ ਅਨੁਸਾਰ ਕਮਿਟਾਂ ਵਿੱਚ ਵੰਡਿਆ ਗਿਆ ਹੈ।

ਬੇਦਾਅਵਾ ਲੇਖ ਦੇ ਕੋਰਸ ਵਿੱਚ, DDoS ਹਮਲਿਆਂ ਨੂੰ ਦੂਰ ਕਰਨ ਲਈ ਇੱਕ ਮਿੰਨੀ-ਹੱਲ ਵਿਕਸਿਤ ਕੀਤਾ ਜਾਵੇਗਾ, ਕਿਉਂਕਿ ਇਹ XDP ਅਤੇ ਮੇਰੇ ਖੇਤਰ ਲਈ ਇੱਕ ਯਥਾਰਥਵਾਦੀ ਕੰਮ ਹੈ। ਹਾਲਾਂਕਿ, ਮੁੱਖ ਟੀਚਾ ਤਕਨਾਲੋਜੀ ਨੂੰ ਸਮਝਣਾ ਹੈ, ਇਹ ਰੈਡੀਮੇਡ ਸੁਰੱਖਿਆ ਬਣਾਉਣ ਲਈ ਇੱਕ ਗਾਈਡ ਨਹੀਂ ਹੈ. ਟਿਊਟੋਰਿਅਲ ਕੋਡ ਨੂੰ ਅਨੁਕੂਲਿਤ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਕੁਝ ਸੂਖਮਤਾਵਾਂ ਨੂੰ ਛੱਡ ਦਿੱਤਾ ਗਿਆ ਹੈ।

XDP ਦੀ ਇੱਕ ਸੰਖੇਪ ਜਾਣਕਾਰੀ

ਮੈਂ ਸਿਰਫ਼ ਮੁੱਖ ਨੁਕਤੇ ਦੱਸਾਂਗਾ ਤਾਂ ਕਿ ਦਸਤਾਵੇਜ਼ਾਂ ਅਤੇ ਮੌਜੂਦਾ ਲੇਖਾਂ ਦੀ ਨਕਲ ਨਾ ਕੀਤੀ ਜਾ ਸਕੇ।

ਇਸ ਲਈ, ਫਿਲਟਰ ਕੋਡ ਕਰਨਲ ਵਿੱਚ ਲੋਡ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਫਿਲਟਰ ਆਉਣ ਵਾਲੇ ਪੈਕੇਟਾਂ ਨੂੰ ਪਾਸ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਨਤੀਜੇ ਵਜੋਂ, ਫਿਲਟਰ ਨੂੰ ਇੱਕ ਫੈਸਲਾ ਲੈਣਾ ਚਾਹੀਦਾ ਹੈ: ਪੈਕੇਟ ਨੂੰ ਕਰਨਲ ਵਿੱਚ ਭੇਜਣ ਲਈ (XDP_PASS), ਡਰਾਪ ਪੈਕੇਟ (XDP_DROP) ਜਾਂ ਇਸਨੂੰ ਵਾਪਸ ਭੇਜੋ (XDP_TX). ਫਿਲਟਰ ਪੈਕੇਜ ਨੂੰ ਬਦਲ ਸਕਦਾ ਹੈ, ਇਹ ਇਸ ਲਈ ਖਾਸ ਤੌਰ 'ਤੇ ਸੱਚ ਹੈ XDP_TX. ਤੁਸੀਂ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਵੀ ਕਰੈਸ਼ ਕਰ ਸਕਦੇ ਹੋ (XDP_ABORTED) ਅਤੇ ਪੈਕੇਜ ਛੱਡੋ, ਪਰ ਇਹ ਸਮਾਨ ਹੈ assert(0) - ਡੀਬੱਗਿੰਗ ਲਈ।

eBPF (ਐਕਸਟੈਂਡਡ ਬਰਕਲੇ ਪੈਕੇਟ ਫਿਲਟਰ) ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਨੂੰ ਜਾਣਬੁੱਝ ਕੇ ਸਰਲ ਬਣਾਇਆ ਗਿਆ ਹੈ ਤਾਂ ਕਿ ਕਰਨਲ ਇਹ ਜਾਂਚ ਕਰ ਸਕੇ ਕਿ ਕੋਡ ਲੂਪ ਨਹੀਂ ਹੈ ਅਤੇ ਦੂਜੇ ਲੋਕਾਂ ਦੀ ਯਾਦਦਾਸ਼ਤ ਨੂੰ ਨੁਕਸਾਨ ਨਹੀਂ ਪਹੁੰਚਾਉਂਦਾ ਹੈ। ਸੰਚਤ ਪਾਬੰਦੀਆਂ ਅਤੇ ਜਾਂਚਾਂ:

• ਲੂਪਸ (ਵਾਪਸ ਛਾਲ) ਦੀ ਮਨਾਹੀ ਹੈ।
• ਡੇਟਾ ਲਈ ਇੱਕ ਸਟੈਕ ਹੈ, ਪਰ ਕੋਈ ਫੰਕਸ਼ਨ ਨਹੀਂ (ਸਾਰੇ C ਫੰਕਸ਼ਨ ਇਨਲਾਈਨ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ)।
• ਸਟੈਕ ਅਤੇ ਪੈਕੇਟ ਬਫਰ ਤੋਂ ਬਾਹਰ ਮੈਮੋਰੀ ਤੱਕ ਪਹੁੰਚ ਦੀ ਮਨਾਹੀ ਹੈ।
• ਕੋਡ ਦਾ ਆਕਾਰ ਸੀਮਤ ਹੈ, ਪਰ ਅਭਿਆਸ ਵਿੱਚ ਇਹ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਹੈ.
• ਸਿਰਫ਼ ਵਿਸ਼ੇਸ਼ ਕਰਨਲ ਫੰਕਸ਼ਨਾਂ (eBPF ਸਹਾਇਕ) ਦੀ ਇਜਾਜ਼ਤ ਹੈ।

ਇੱਕ ਫਿਲਟਰ ਦਾ ਵਿਕਾਸ ਅਤੇ ਸਥਾਪਨਾ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ:

1. ਸਰੋਤ ਕੋਡ (ਉਦਾਹਰਨ ਲਈ. kernel.c) ਵਸਤੂ ਨੂੰ ਕੰਪਾਇਲ ਕਰਦਾ ਹੈ (kernel.o) eBPF ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਆਰਕੀਟੈਕਚਰ ਲਈ। ਅਕਤੂਬਰ 2019 ਤੱਕ, eBPF ਨੂੰ ਕੰਪਾਇਲ ਕਰਨਾ Clang ਦੁਆਰਾ ਸਮਰਥਿਤ ਹੈ ਅਤੇ GCC 10.1 ਵਿੱਚ ਵਾਅਦਾ ਕੀਤਾ ਗਿਆ ਹੈ।
2. ਜੇਕਰ ਇਸ ਆਬਜੈਕਟ ਕੋਡ ਵਿੱਚ ਕਰਨਲ ਢਾਂਚੇ (ਉਦਾਹਰਣ ਵਜੋਂ, ਟੇਬਲ ਅਤੇ ਕਾਊਂਟਰਾਂ ਲਈ) ਕਾਲਾਂ ਹਨ, ਤਾਂ ਉਹਨਾਂ ਦੀ ID ਦੀ ਬਜਾਏ ਜ਼ੀਰੋ ਹਨ, ਯਾਨੀ, ਅਜਿਹੇ ਕੋਡ ਨੂੰ ਚਲਾਇਆ ਨਹੀਂ ਜਾ ਸਕਦਾ ਹੈ। ਕਰਨਲ ਵਿੱਚ ਲੋਡ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਇਹਨਾਂ ਜ਼ੀਰੋ ਨੂੰ ਕਰਨਲ ਕਾਲਾਂ (ਕੋਡ ਨੂੰ ਲਿੰਕ ਕਰੋ) ਦੁਆਰਾ ਬਣਾਏ ਗਏ ਖਾਸ ਆਬਜੈਕਟ ਦੇ ID ਨਾਲ ਬਦਲਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਤੁਸੀਂ ਇਹ ਬਾਹਰੀ ਉਪਯੋਗਤਾਵਾਂ ਨਾਲ ਕਰ ਸਕਦੇ ਹੋ, ਜਾਂ ਤੁਸੀਂ ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਲਿਖ ਸਕਦੇ ਹੋ ਜੋ ਇੱਕ ਖਾਸ ਫਿਲਟਰ ਨੂੰ ਲਿੰਕ ਅਤੇ ਲੋਡ ਕਰੇਗਾ।
3. ਕਰਨਲ ਪ੍ਰੋਗਰਾਮ ਲੋਡ ਹੋਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ। ਇਹ ਚੱਕਰਾਂ ਦੀ ਅਣਹੋਂਦ ਅਤੇ ਪੈਕੇਜ ਅਤੇ ਸਟੈਕ ਸੀਮਾਵਾਂ ਤੋਂ ਬਾਹਰ ਨਾ ਨਿਕਲਣ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਤਸਦੀਕਕਰਤਾ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ ਕਿ ਕੋਡ ਸਹੀ ਹੈ, ਤਾਂ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਅਸਵੀਕਾਰ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ - ਇੱਕ ਨੂੰ ਉਸਨੂੰ ਖੁਸ਼ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
4. ਸਫਲ ਤਸਦੀਕ ਤੋਂ ਬਾਅਦ, ਕਰਨਲ eBPF ਆਰਕੀਟੈਕਚਰ ਆਬਜੈਕਟ ਕੋਡ ਨੂੰ ਸਿਸਟਮ ਆਰਕੀਟੈਕਚਰ ਮਸ਼ੀਨ ਕੋਡ (ਸਿਰਫ਼ ਸਮੇਂ ਵਿੱਚ) ਵਿੱਚ ਕੰਪਾਇਲ ਕਰਦਾ ਹੈ।
5. ਪ੍ਰੋਗਰਾਮ ਇੰਟਰਫੇਸ ਨਾਲ ਜੁੜਿਆ ਹੋਇਆ ਹੈ ਅਤੇ ਪੈਕੇਟਾਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ।

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

ਵਾਤਾਵਰਣ ਦੀ ਤਿਆਰੀ

ਅਸੈਂਬਲੀ

Clang eBPF ਆਰਕੀਟੈਕਚਰ ਲਈ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਆਬਜੈਕਟ ਕੋਡ ਜਾਰੀ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ, ਇਸਲਈ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਦੋ ਕਦਮ ਹਨ:

1. ਸੀ ਕੋਡ ਨੂੰ LLVM ਬਾਈਟਕੋਡ ਵਿੱਚ ਕੰਪਾਇਲ ਕਰੋ (clang -emit-llvm).
2. ਬਾਈਟਕੋਡ ਨੂੰ eBPF ਆਬਜੈਕਟ ਕੋਡ ਵਿੱਚ ਬਦਲੋ (llc -march=bpf -filetype=obj).

ਫਿਲਟਰ ਲਿਖਣ ਵੇਲੇ, ਸਹਾਇਕ ਫੰਕਸ਼ਨਾਂ ਅਤੇ ਮੈਕਰੋ ਵਾਲੀਆਂ ਕੁਝ ਫਾਈਲਾਂ ਕੰਮ ਆਉਣਗੀਆਂ ਕਰਨਲ ਟੈਸਟਾਂ ਤੋਂ. ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਉਹ ਕਰਨਲ ਸੰਸਕਰਣ (KVER). ਉਹਨਾਂ ਨੂੰ ਡਾਉਨਲੋਡ ਕਰੋ helpers/:

export KVER=v5.3.7
export BASE=https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/plain/tools/testing/selftests/bpf
wget -P helpers --content-disposition "${BASE}/bpf_helpers.h?h=${KVER}" "${BASE}/bpf_endian.h?h=${KVER}"
unset KVER BASE

ਆਰਕ ਲੀਨਕਸ ਲਈ ਮੇਕਫਾਈਲ (ਕਰਨਲ 5.3.7):

CLANG ?= clang
LLC ?= llc

KDIR ?= /lib/modules/$(shell uname -r)/build
ARCH ?= $(subst x86_64,x86,$(shell uname -m))

CFLAGS = 
    -Ihelpers 
    
    -I$(KDIR)/include 
    -I$(KDIR)/include/uapi 
    -I$(KDIR)/include/generated/uapi 
    -I$(KDIR)/arch/$(ARCH)/include 
    -I$(KDIR)/arch/$(ARCH)/include/generated 
    -I$(KDIR)/arch/$(ARCH)/include/uapi 
    -I$(KDIR)/arch/$(ARCH)/include/generated/uapi 
    -D__KERNEL__ 
    
    -fno-stack-protector -O2 -g

xdp_%.o: xdp_%.c Makefile
    $(CLANG) -c -emit-llvm $(CFLAGS) $< -o - | 
    $(LLC) -march=bpf -filetype=obj -o $@

.PHONY: all clean

all: xdp_filter.o

clean:
    rm -f ./*.o

KDIR ਕਰਨਲ ਸਿਰਲੇਖਾਂ ਦਾ ਮਾਰਗ ਰੱਖਦਾ ਹੈ, ARCH - ਸਿਸਟਮ ਆਰਕੀਟੈਕਚਰ. ਪਾਥ ਅਤੇ ਟੂਲ ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਦੇ ਵਿਚਕਾਰ ਥੋੜ੍ਹਾ ਵੱਖ-ਵੱਖ ਹੋ ਸਕਦੇ ਹਨ।

ਡੇਬੀਅਨ 10 (ਕਰਨਲ 4.19.67) ਲਈ ਅੰਤਰ ਉਦਾਹਰਨ

# другая команда
CLANG ?= clang
LLC ?= llc-7

# другой каталог
KDIR ?= /usr/src/linux-headers-$(shell uname -r)
ARCH ?= $(subst x86_64,x86,$(shell uname -m))

# два дополнительных каталога -I
CFLAGS = 
    -Ihelpers 
    
    -I/usr/src/linux-headers-4.19.0-6-common/include 
    -I/usr/src/linux-headers-4.19.0-6-common/arch/$(ARCH)/include 
    # далее без изменений

CFLAGS ਸਹਾਇਕ ਹੈਡਰਾਂ ਵਾਲੀ ਇੱਕ ਡਾਇਰੈਕਟਰੀ ਅਤੇ ਕਰਨਲ ਹੈਡਰਾਂ ਨਾਲ ਕਈ ਡਾਇਰੈਕਟਰੀਆਂ ਸ਼ਾਮਲ ਕਰੋ। ਚਿੰਨ੍ਹ __KERNEL__ ਮਤਲਬ ਕਿ UAPI (userspace API) ਸਿਰਲੇਖ ਕਰਨਲ ਕੋਡ ਲਈ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤੇ ਗਏ ਹਨ, ਕਿਉਂਕਿ ਫਿਲਟਰ ਕਰਨਲ ਵਿੱਚ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ।

ਸਟੈਕ ਸੁਰੱਖਿਆ ਨੂੰ ਅਯੋਗ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ (-fno-stack-protector) ਕਿਉਂਕਿ eBPF ਕੋਡ ਵੈਰੀਫਾਇਰ ਕਿਸੇ ਵੀ ਤਰ੍ਹਾਂ ਸਟੈਕ ਸੀਮਾਵਾਂ ਤੋਂ ਬਾਹਰ ਨਾ ਹੋਣ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਤੁਰੰਤ ਅਨੁਕੂਲਤਾ ਨੂੰ ਸਮਰੱਥ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ eBPF ਬਾਈਟਕੋਡ ਦਾ ਆਕਾਰ ਸੀਮਤ ਹੈ।

ਆਉ ਇੱਕ ਫਿਲਟਰ ਨਾਲ ਸ਼ੁਰੂ ਕਰੀਏ ਜੋ ਸਾਰੇ ਪੈਕੇਟਾਂ ਨੂੰ ਪਾਸ ਕਰਦਾ ਹੈ ਅਤੇ ਕੁਝ ਨਹੀਂ ਕਰਦਾ:

#include <uapi/linux/bpf.h>

#include <bpf_helpers.h>

SEC("prog")
int xdp_main(struct xdp_md* ctx) {
    return XDP_PASS;
}

char _license[] SEC("license") = "GPL";

ਦੀ ਟੀਮ make ਇਕੱਠਾ ਕਰਦਾ ਹੈ xdp_filter.o. ਤੁਸੀਂ ਹੁਣ ਇਸਨੂੰ ਕਿੱਥੇ ਟੈਸਟ ਕਰ ਸਕਦੇ ਹੋ?

ਟੈਸਟ ਸਟੈਂਡ

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

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

ip link add xdp-remote type veth peer name xdp-local

ਇਹ ਇਸ ਲਈ ਹੈ xdp-remote и xdp-local — ਜੰਤਰ ਦੇ ਨਾਮ. 'ਤੇ xdp-local (192.0.2.1/24) ਨਾਲ ਇੱਕ ਫਿਲਟਰ ਨੱਥੀ ਕੀਤਾ ਜਾਵੇਗਾ xdp-remote (192.0.2.2/24) ਆਉਣ ਵਾਲੀ ਟਰੈਫਿਕ ਭੇਜੀ ਜਾਵੇਗੀ। ਹਾਲਾਂਕਿ, ਇੱਕ ਸਮੱਸਿਆ ਹੈ: ਇੰਟਰਫੇਸ ਇੱਕੋ ਮਸ਼ੀਨ 'ਤੇ ਹਨ, ਅਤੇ ਲੀਨਕਸ ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਦੂਜੇ ਰਾਹੀਂ ਟਰੈਫਿਕ ਨਹੀਂ ਭੇਜੇਗਾ। ਤੁਸੀਂ ਇਸ ਨੂੰ ਗੁੰਝਲਦਾਰ ਨਿਯਮਾਂ ਨਾਲ ਹੱਲ ਕਰ ਸਕਦੇ ਹੋ iptables, ਪਰ ਉਹਨਾਂ ਨੂੰ ਪੈਕੇਜ ਬਦਲਣੇ ਪੈਣਗੇ, ਜੋ ਡੀਬੱਗ ਕਰਨ ਵੇਲੇ ਅਸੁਵਿਧਾਜਨਕ ਹੈ। ਨੈੱਟਵਰਕ ਨੇਮਸਪੇਸ (ਨੈੱਟਵਰਕ ਨੇਮਸਪੇਸ, ਹੋਰ ਨੈੱਟਨਸ) ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਬਿਹਤਰ ਹੈ।

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

ਚਲੋ ਇੱਕ ਨਵਾਂ ਨੇਮਸਪੇਸ ਬਣਾਈਏ xdp-test ਅਤੇ ਉੱਥੇ ਚਲੇ ਜਾਓ xdp-remote.

ip netns add xdp-test
ip link set dev xdp-remote netns xdp-test

ਫਿਰ ਪ੍ਰਕਿਰਿਆ ਚੱਲ ਰਹੀ ਹੈ xdp-test, "ਵੇਖੋ" ਨਹੀਂ ਹੋਵੇਗਾ xdp-local (ਇਹ ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ netns ਵਿੱਚ ਰਹੇਗਾ) ਅਤੇ ਜਦੋਂ ਇੱਕ ਪੈਕੇਟ 192.0.2.1 ਨੂੰ ਭੇਜਦੇ ਹੋ ਤਾਂ ਇਸ ਵਿੱਚੋਂ ਲੰਘ ਜਾਵੇਗਾ xdp-remote, ਕਿਉਂਕਿ ਇਸ ਪ੍ਰਕਿਰਿਆ ਲਈ 192.0.2.0/24 'ਤੇ ਸਿਰਫ਼ ਇਹ ਹੀ ਇੰਟਰਫੇਸ ਉਪਲਬਧ ਹੈ। ਇਹ ਉਲਟਾ ਵੀ ਕੰਮ ਕਰਦਾ ਹੈ।

netns ਦੇ ਵਿਚਕਾਰ ਜਾਣ ਵੇਲੇ, ਇੰਟਰਫੇਸ ਹੇਠਾਂ ਚਲਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਪਤਾ ਗੁਆ ਦਿੰਦਾ ਹੈ। netns ਵਿੱਚ ਇੱਕ ਇੰਟਰਫੇਸ ਸਥਾਪਤ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਚਲਾਉਣ ਦੀ ਲੋੜ ਹੈ ip ... ਇਸ ਕਮਾਂਡ ਨੇਮਸਪੇਸ ਵਿੱਚ ip netns exec:

ip netns exec xdp-test 
    ip address add 192.0.2.2/24 dev xdp-remote
ip netns exec xdp-test 
    ip link set xdp-remote up

ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ, ਇਹ ਸੈਟਿੰਗ ਤੋਂ ਵੱਖਰਾ ਨਹੀਂ ਹੈ xdp-local ਡਿਫੌਲਟ ਨੇਮਸਪੇਸ ਵਿੱਚ:

    ip address add 192.0.2.1/24 dev xdp-local
    ip link set xdp-local up

ਜੇਕਰ ਚਲਾਇਆ ਜਾਵੇ tcpdump -tnevi xdp-local, ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਇਸ ਤੋਂ ਭੇਜੇ ਗਏ ਪੈਕੇਟ xdp-test, ਇਸ ਇੰਟਰਫੇਸ ਨੂੰ ਡਿਲੀਵਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ:

ip netns exec xdp-test   ping 192.0.2.1

ਅੰਦਰ ਸ਼ੈੱਲ ਚਲਾਉਣਾ ਸੁਵਿਧਾਜਨਕ ਹੈ xdp-test. ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਇੱਕ ਸਕ੍ਰਿਪਟ ਹੈ ਜੋ ਸਟੈਂਡ ਦੇ ਨਾਲ ਕੰਮ ਨੂੰ ਸਵੈਚਾਲਤ ਕਰਦੀ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਤੁਸੀਂ ਕਮਾਂਡ ਨਾਲ ਸਟੈਂਡ ਨੂੰ ਸੈਟ ਅਪ ਕਰ ਸਕਦੇ ਹੋ sudo ./stand up ਅਤੇ ਇਸ ਨੂੰ ਹਟਾਓ sudo ./stand down.

ਟਰੇਸਿੰਗ

ਫਿਲਟਰ ਡਿਵਾਈਸ ਨਾਲ ਇਸ ਤਰ੍ਹਾਂ ਜੁੜਿਆ ਹੋਇਆ ਹੈ:

ip -force link set dev xdp-local xdp object xdp_filter.o verbose

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

Verifier analysis:

0: (b7) r0 = 2
1: (95) exit

ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਇੰਟਰਫੇਸ ਤੋਂ ਵੱਖ ਕਰੋ:

ip link set dev xdp-local xdp off

ਸਕ੍ਰਿਪਟ ਵਿੱਚ, ਇਹ ਹੁਕਮ ਹਨ sudo ./stand attach и sudo ./stand detach.

ਫਿਲਟਰ ਨੂੰ ਬੰਨ੍ਹ ਕੇ, ਤੁਸੀਂ ਇਹ ਯਕੀਨੀ ਬਣਾ ਸਕਦੇ ਹੋ ping ਕੰਮ ਕਰਨਾ ਜਾਰੀ ਰੱਖਦਾ ਹੈ, ਪਰ ਕੀ ਪ੍ਰੋਗਰਾਮ ਕੰਮ ਕਰਦਾ ਹੈ? ਆਓ ਲੋਗੋ ਜੋੜੀਏ। ਫੰਕਸ਼ਨ bpf_trace_printk() ਦੇ ਵਰਗਾ printf(), ਪਰ ਪੈਟਰਨ ਤੋਂ ਇਲਾਵਾ ਸਿਰਫ਼ ਤਿੰਨ ਆਰਗੂਮੈਂਟਾਂ ਅਤੇ ਨਿਰਧਾਰਕਾਂ ਦੀ ਇੱਕ ਸੀਮਤ ਸੂਚੀ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਮੈਕਰੋ bpf_printk() ਕਾਲ ਨੂੰ ਸਰਲ ਬਣਾਉਂਦਾ ਹੈ।

   SEC("prog")
   int xdp_main(struct xdp_md* ctx) {
+      bpf_printk("got packet: %pn", ctx);
       return XDP_PASS;
   }

ਆਉਟਪੁੱਟ ਕਰਨਲ ਟਰੇਸ ਚੈਨਲ 'ਤੇ ਜਾਂਦੀ ਹੈ, ਜਿਸ ਨੂੰ ਯੋਗ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ:

echo -n 1 | sudo tee /sys/kernel/debug/tracing/options/trace_printk

ਸੁਨੇਹਾ ਪ੍ਰਵਾਹ ਦੇਖੋ:

cat /sys/kernel/debug/tracing/trace_pipe

ਇਹ ਦੋਵੇਂ ਟੀਮਾਂ ਇੱਕ ਕਾਲ ਕਰਦੀਆਂ ਹਨ sudo ./stand log.

ਪਿੰਗ ਨੂੰ ਹੁਣ ਇਸ ਵਿੱਚ ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਸੰਦੇਸ਼ ਪੈਦਾ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ:

<...>-110930 [004] ..s1 78803.244967: 0: got packet: 00000000ac510377

ਜੇਕਰ ਤੁਸੀਂ ਵੈਰੀਫਾਇਰ ਦੇ ਆਉਟਪੁੱਟ ਨੂੰ ਨੇੜਿਓਂ ਦੇਖਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਅਜੀਬ ਗਣਨਾਵਾਂ ਦੇਖ ਸਕਦੇ ਹੋ:

0: (bf) r3 = r1
1: (18) r1 = 0xa7025203a7465
3: (7b) *(u64 *)(r10 -8) = r1
4: (18) r1 = 0x6b63617020746f67
6: (7b) *(u64 *)(r10 -16) = r1
7: (bf) r1 = r10
8: (07) r1 += -16
9: (b7) r2 = 16
10: (85) call bpf_trace_printk#6
<...>

ਤੱਥ ਇਹ ਹੈ ਕਿ eBPF ਪ੍ਰੋਗਰਾਮਾਂ ਵਿੱਚ ਡੇਟਾ ਸੈਕਸ਼ਨ ਨਹੀਂ ਹੁੰਦਾ ਹੈ, ਇਸਲਈ ਫਾਰਮੈਟ ਸਤਰ ਨੂੰ ਏਨਕੋਡ ਕਰਨ ਦਾ ਇੱਕੋ ਇੱਕ ਤਰੀਕਾ ਹੈ VM ਕਮਾਂਡਾਂ ਦੇ ਤੁਰੰਤ ਆਰਗੂਮੈਂਟਸ:

$ python -c "import binascii; print(bytes(reversed(binascii.unhexlify('0a7025203a74656b63617020746f67'))))"
b'got packet: %pn'

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

XDP ਪੈਕੇਟ ਭੇਜੇ ਜਾ ਰਹੇ ਹਨ

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

       bpf_printk("got packet: %pn", ctx);
-      return XDP_PASS;
+      return XDP_TX;
   }

ਲਾਂਚ ਕਰੋ tcpdump 'ਤੇ xdp-remote. ਇਸ ਨੂੰ ਸਮਾਨ ਆਊਟਗੋਇੰਗ ਅਤੇ ਇਨਕਮਿੰਗ ICMP ਈਕੋ ਬੇਨਤੀ ਦਿਖਾਉਣੀ ਚਾਹੀਦੀ ਹੈ ਅਤੇ ICMP ਈਕੋ ਜਵਾਬ ਦਿਖਾਉਣਾ ਬੰਦ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਪਰ ਇਹ ਨਹੀਂ ਦਿਖਾਉਂਦਾ. ਕੰਮ ਕਰਨ ਲਈ ਨਿਕਲਦਾ ਹੈ XDP_TX ਲਈ ਪ੍ਰੋਗਰਾਮ ਵਿੱਚ xdp-local ਜ਼ਰੂਰੀ ਹੈਇੰਟਰਫੇਸ ਜੋੜਾ ਕਰਨ ਲਈ xdp-remote ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਵੀ ਨਿਰਧਾਰਤ ਕੀਤਾ ਗਿਆ ਸੀ, ਭਾਵੇਂ ਇਹ ਖਾਲੀ ਸੀ, ਅਤੇ ਇਸਨੂੰ ਉਭਾਰਿਆ ਗਿਆ ਸੀ।

ਮੈਨੂੰ ਕਿਵੇਂ ਪਤਾ ਲੱਗਾ?

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

ਤੁਹਾਨੂੰ ਬੁਰਾਈ ਵਿੱਚੋਂ ਚੰਗਾ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਇਸ ਨੂੰ ਬਣਾਉਣ ਲਈ ਹੋਰ ਕੁਝ ਨਹੀਂ ਹੈ।

$ sudo perf trace --call-graph dwarf -e 'xdp:*'
   0.000 ping/123455 xdp:xdp_bulk_tx:ifindex=19 action=TX sent=0 drops=1 err=-6
                                     veth_xdp_flush_bq ([veth])
                                     veth_xdp_flush_bq ([veth])
                                     veth_poll ([veth])
                                     <...>

ਕੋਡ 6 ਕੀ ਹੈ?

$ errno 6
ENXIO 6 No such device or address

ਫੰਕਸ਼ਨ veth_xdp_flush_bq() ਤੋਂ ਗਲਤੀ ਕੋਡ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ veth_xdp_xmit(), ਜਿੱਥੇ ਕੇ ਖੋਜ ENXIO ਅਤੇ ਇੱਕ ਟਿੱਪਣੀ ਲੱਭੋ.

ਘੱਟੋ-ਘੱਟ ਫਿਲਟਰ ਰੀਸਟੋਰ ਕਰੋ (XDP_PASS) ਫਾਈਲ ਵਿੱਚ xdp_dummy.c, ਇਸਨੂੰ ਮੇਕਫਾਈਲ ਵਿੱਚ ਜੋੜੋ, ਨਾਲ ਬੰਨ੍ਹੋ xdp-remote:

ip netns exec remote 
    ip link set dev int xdp object dummy.o

ਹੁਣ tcpdump ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਕੀ ਉਮੀਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ:

62:57:8e:70:44:64 > 26:0e:25:37:8f:96, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 13762, offset 0, flags [DF], proto ICMP (1), length 84)
    192.0.2.2 > 192.0.2.1: ICMP echo request, id 46966, seq 1, length 64
62:57:8e:70:44:64 > 26:0e:25:37:8f:96, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 13762, offset 0, flags [DF], proto ICMP (1), length 84)
    192.0.2.2 > 192.0.2.1: ICMP echo request, id 46966, seq 1, length 64

ਜੇਕਰ ਇਸਦੀ ਬਜਾਏ ਸਿਰਫ਼ ARP ਦਿਖਾਇਆ ਗਿਆ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਫਿਲਟਰਾਂ ਨੂੰ ਹਟਾਉਣ ਦੀ ਲੋੜ ਹੈ (ਇਸ ਨਾਲ sudo ./stand detach), ਚਲੋ ping, ਫਿਰ ਫਿਲਟਰ ਸਥਾਪਿਤ ਕਰੋ ਅਤੇ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰੋ। ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਫਿਲਟਰ XDP_TX ARP ਨੂੰ ਵੀ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਜੇਕਰ ਸਟੈਕ
ਨਾਮ-ਸਥਾਨਾਂ xdp-test MAC ਐਡਰੈੱਸ 192.0.2.1 ਨੂੰ "ਭੁੱਲਣ" ਵਿੱਚ ਪਰਬੰਧਿਤ, ਉਹ ਇਸ IP ਨੂੰ ਹੱਲ ਕਰਨ ਦੇ ਯੋਗ ਨਹੀਂ ਹੋਵੇਗਾ।

ਸਮੱਸਿਆ ਦਾ ਗਠਨ

ਚਲੋ ਦੱਸੇ ਗਏ ਕੰਮ ਵੱਲ ਵਧੀਏ: XDP ਉੱਤੇ ਇੱਕ SYN ਕੂਕੀ ਵਿਧੀ ਲਿਖਣ ਲਈ।

ਹੁਣ ਤੱਕ, SYN ਹੜ੍ਹ ਇੱਕ ਪ੍ਰਸਿੱਧ DDoS ਹਮਲਾ ਬਣਿਆ ਹੋਇਆ ਹੈ, ਜਿਸਦਾ ਸਾਰ ਹੇਠ ਲਿਖੇ ਅਨੁਸਾਰ ਹੈ। ਜਦੋਂ ਇੱਕ ਕਨੈਕਸ਼ਨ ਸਥਾਪਤ ਹੁੰਦਾ ਹੈ (TCP ਹੈਂਡਸ਼ੇਕ), ਸਰਵਰ ਇੱਕ SYN ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, ਭਵਿੱਖ ਦੇ ਕਨੈਕਸ਼ਨ ਲਈ ਸਰੋਤ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ, ਇੱਕ SYNACK ਪੈਕੇਟ ਨਾਲ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਇੱਕ ACK ਦੀ ਉਡੀਕ ਕਰਦਾ ਹੈ। ਹਮਲਾਵਰ ਇੱਕ ਬਹੁ-ਹਜ਼ਾਰ ਬੋਟਨੈੱਟ ਵਿੱਚ ਹਰੇਕ ਹੋਸਟ ਤੋਂ ਹਜ਼ਾਰਾਂ ਪ੍ਰਤੀ ਸਕਿੰਟ ਦੀ ਮਾਤਰਾ ਵਿੱਚ ਜਾਅਲੀ ਪਤਿਆਂ ਤੋਂ SYN ਪੈਕੇਟ ਭੇਜਦਾ ਹੈ। ਸਰਵਰ ਨੂੰ ਪੈਕੇਟ ਦੇ ਆਉਣ 'ਤੇ ਤੁਰੰਤ ਸਰੋਤ ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਪਰ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਬਾਅਦ ਇਸਨੂੰ ਜਾਰੀ ਕਰਦਾ ਹੈ, ਨਤੀਜੇ ਵਜੋਂ, ਮੈਮੋਰੀ ਜਾਂ ਸੀਮਾਵਾਂ ਖਤਮ ਹੋ ਜਾਂਦੀਆਂ ਹਨ, ਨਵੇਂ ਕਨੈਕਸ਼ਨ ਸਵੀਕਾਰ ਨਹੀਂ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਸੇਵਾ ਉਪਲਬਧ ਨਹੀਂ ਹੈ।

ਜੇਕਰ ਤੁਸੀਂ SYN ਪੈਕੇਟ 'ਤੇ ਸਰੋਤ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕਰਦੇ, ਪਰ ਸਿਰਫ ਇੱਕ SYNACK ਪੈਕੇਟ ਨਾਲ ਜਵਾਬ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਸਰਵਰ ਕਿਵੇਂ ਸਮਝ ਸਕਦਾ ਹੈ ਕਿ ਬਾਅਦ ਵਿੱਚ ਆਇਆ ACK ਪੈਕੇਟ SYN ਪੈਕੇਟ ਨਾਲ ਸਬੰਧਤ ਹੈ ਜੋ ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ? ਆਖਰਕਾਰ, ਇੱਕ ਹਮਲਾਵਰ ਜਾਅਲੀ ACKs ਵੀ ਤਿਆਰ ਕਰ ਸਕਦਾ ਹੈ। SYN ਕੂਕੀ ਦਾ ਸਾਰ ਇਨਕੋਡ ਕਰਨਾ ਹੈ seqnum ਕਨੈਕਸ਼ਨ ਪੈਰਾਮੀਟਰ ਪਤਿਆਂ, ਪੋਰਟਾਂ ਅਤੇ ਬਦਲਦੇ ਨਮਕ ਦੇ ਹੈਸ਼ ਵਜੋਂ। ਜੇਕਰ ACK ਲੂਣ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਪਹੁੰਚਣ ਵਿੱਚ ਕਾਮਯਾਬ ਹੋ ਗਿਆ, ਤਾਂ ਤੁਸੀਂ ਦੁਬਾਰਾ ਹੈਸ਼ ਦੀ ਗਣਨਾ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਇਸ ਨਾਲ ਤੁਲਨਾ ਕਰ ਸਕਦੇ ਹੋ acknum. ਨਕਲੀ acknum ਹਮਲਾਵਰ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਕਿਉਂਕਿ ਲੂਣ ਵਿੱਚ ਰਾਜ਼ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਸੀਮਤ ਚੈਨਲ ਦੇ ਕਾਰਨ ਇਸ ਨੂੰ ਛਾਂਟਣ ਲਈ ਸਮਾਂ ਨਹੀਂ ਹੁੰਦਾ।

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

TCP ਹੈਂਡਸ਼ੇਕ 'ਤੇ ਵਿਦਿਅਕ ਪ੍ਰੋਗਰਾਮ

TCP ਬਾਈਟਾਂ ਦੀ ਇੱਕ ਸਟ੍ਰੀਮ ਦੇ ਤੌਰ ਤੇ ਡੇਟਾ ਦਾ ਤਬਾਦਲਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ, HTTP ਬੇਨਤੀਆਂ TCP ਦੁਆਰਾ ਪ੍ਰਸਾਰਿਤ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਸਟਰੀਮ ਨੂੰ ਪੈਕੇਟਾਂ ਵਿੱਚ ਟੁਕੜੇ-ਟੁਕੜੇ ਵਿੱਚ ਪ੍ਰਸਾਰਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਸਾਰੇ TCP ਪੈਕੇਟਾਂ ਵਿੱਚ ਲਾਜ਼ੀਕਲ ਫਲੈਗ ਅਤੇ 32-ਬਿੱਟ ਕ੍ਰਮ ਨੰਬਰ ਹੁੰਦੇ ਹਨ:

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

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

• ਰਸੀਦ ਨੰਬਰ (ਐਕੰਨਮ) - ਸੀਕਨਮ ਦੇ ਸਮਾਨ ਆਫਸੈੱਟ, ਪਰ ਇਹ ਪ੍ਰਸਾਰਿਤ ਬਾਈਟ ਦੀ ਸੰਖਿਆ ਨੂੰ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕਰਦਾ, ਪਰ ਪ੍ਰਾਪਤਕਰਤਾ ਤੋਂ ਪਹਿਲੇ ਬਾਈਟ ਦੀ ਸੰਖਿਆ, ਜੋ ਭੇਜਣ ਵਾਲੇ ਨੇ ਨਹੀਂ ਦੇਖਿਆ ਸੀ।

ਕੁਨੈਕਸ਼ਨ ਦੀ ਸ਼ੁਰੂਆਤ 'ਤੇ, ਪਾਰਟੀਆਂ ਨੂੰ ਸਹਿਮਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ seqnum и acknum. ਕਲਾਇੰਟ ਇਸਦੇ ਨਾਲ ਇੱਕ SYN ਪੈਕੇਟ ਭੇਜਦਾ ਹੈ seqnum = X. ਸਰਵਰ ਇੱਕ SYNACK ਪੈਕੇਟ ਨਾਲ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਜਿੱਥੇ ਇਹ ਆਪਣਾ ਲਿਖਦਾ ਹੈ seqnum = Y ਅਤੇ ਪ੍ਰਗਟ ਕਰਦਾ ਹੈ acknum = X + 1. ਕਲਾਇੰਟ ਇੱਕ ACK ਪੈਕੇਟ ਨਾਲ SYNACK ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਜਿੱਥੇ seqnum = X + 1, acknum = Y + 1. ਉਸ ਤੋਂ ਬਾਅਦ, ਅਸਲ ਡਾਟਾ ਟ੍ਰਾਂਸਫਰ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ.

ਜੇਕਰ ਵਾਰਤਾਕਾਰ ਪੈਕੇਟ ਦੀ ਰਸੀਦ ਨੂੰ ਸਵੀਕਾਰ ਨਹੀਂ ਕਰਦਾ ਹੈ, ਤਾਂ TCP ਇਸਨੂੰ ਟਾਈਮਆਊਟ ਦੁਆਰਾ ਦੁਬਾਰਾ ਭੇਜਦਾ ਹੈ।

SYN ਕੂਕੀਜ਼ ਦੀ ਵਰਤੋਂ ਹਮੇਸ਼ਾ ਕਿਉਂ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ?

ਪਹਿਲਾਂ, ਜੇਕਰ ਕੋਈ SYNACK ਜਾਂ ACK ਗੁੰਮ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਦੁਬਾਰਾ ਭੇਜਣ ਲਈ ਉਡੀਕ ਕਰਨੀ ਪਵੇਗੀ - ਕੁਨੈਕਸ਼ਨ ਸਥਾਪਨਾ ਹੌਲੀ ਹੋ ਜਾਂਦੀ ਹੈ। ਦੂਜਾ, SYN ਪੈਕੇਟ ਵਿੱਚ - ਅਤੇ ਸਿਰਫ ਇਸ ਵਿੱਚ! - ਕਈ ਵਿਕਲਪ ਪ੍ਰਸਾਰਿਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਜੋ ਕਨੈਕਸ਼ਨ ਦੇ ਅਗਲੇ ਕੰਮ ਨੂੰ ਪ੍ਰਭਾਵਤ ਕਰਦੇ ਹਨ। ਆਉਣ ਵਾਲੇ SYN ਪੈਕੇਟਾਂ ਨੂੰ ਯਾਦ ਨਾ ਕਰਦੇ ਹੋਏ, ਸਰਵਰ ਇਸ ਤਰ੍ਹਾਂ ਇਹਨਾਂ ਵਿਕਲਪਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦਾ ਹੈ, ਹੇਠਾਂ ਦਿੱਤੇ ਪੈਕੇਟਾਂ ਵਿੱਚ ਕਲਾਇੰਟ ਹੁਣ ਉਹਨਾਂ ਨੂੰ ਨਹੀਂ ਭੇਜੇਗਾ। TCP ਇਸ ਕੇਸ ਵਿੱਚ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਘੱਟੋ ਘੱਟ ਸ਼ੁਰੂਆਤੀ ਪੜਾਅ 'ਤੇ, ਕੁਨੈਕਸ਼ਨ ਦੀ ਗੁਣਵੱਤਾ ਘੱਟ ਜਾਵੇਗੀ.

ਪੈਕੇਜਾਂ ਦੇ ਰੂਪ ਵਿੱਚ, ਇੱਕ XDP ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਇਹ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ:

• ਕੂਕੀ ਦੇ ਨਾਲ SYNACK ਨਾਲ SYN ਦਾ ਜਵਾਬ;
• ACK ਦਾ RST ਨਾਲ ਜਵਾਬ ਦਿਓ (ਕੁਨੈਕਸ਼ਨ ਤੋੜੋ);
• ਹੋਰ ਪੈਕੇਟ ਸੁੱਟੋ.

ਪੈਕੇਟ ਪਾਰਸਿੰਗ ਦੇ ਨਾਲ ਐਲਗੋਰਿਦਮ ਦਾ ਸੂਡੋ-ਕੋਡ:

Если это не Ethernet,
    пропустить пакет.
Если это не IPv4,
    пропустить пакет.
Если адрес в таблице проверенных,               (*)
        уменьшить счетчик оставшихся проверок,
        пропустить пакет.
Если это не TCP,
    сбросить пакет.     (**)
Если это SYN,
    ответить SYN-ACK с cookie.
Если это ACK,
    если в acknum лежит не cookie,
        сбросить пакет.
    Занести в таблицу адрес с N оставшихся проверок.    (*)
    Ответить RST.   (**)
В остальных случаях сбросить пакет.

ਇੱਕ (*) ਉਹ ਬਿੰਦੂ ਜਿੱਥੇ ਤੁਹਾਨੂੰ ਸਿਸਟਮ ਦੀ ਸਥਿਤੀ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਉਹਨਾਂ ਨੂੰ ਚਿੰਨ੍ਹਿਤ ਕੀਤਾ ਗਿਆ ਹੈ - ਪਹਿਲੇ ਪੜਾਅ 'ਤੇ, ਤੁਸੀਂ ਇੱਕ ਸੀਕਨਮ ਵਜੋਂ ਇੱਕ SYN ਕੂਕੀ ਬਣਾਉਣ ਦੇ ਨਾਲ ਇੱਕ TCP ਹੈਂਡਸ਼ੇਕ ਲਾਗੂ ਕਰਕੇ ਉਹਨਾਂ ਤੋਂ ਬਿਨਾਂ ਕਰ ਸਕਦੇ ਹੋ।

ਸਾਈਟ ਤੇ (**), ਜਦੋਂ ਕਿ ਸਾਡੇ ਕੋਲ ਟੇਬਲ ਨਹੀਂ ਹੈ, ਅਸੀਂ ਪੈਕੇਟ ਨੂੰ ਛੱਡ ਦੇਵਾਂਗੇ।

TCP ਹੈਂਡਸ਼ੇਕ ਲਾਗੂ ਕਰਨਾ

ਪੈਕੇਜ ਪਾਰਸਿੰਗ ਅਤੇ ਕੋਡ ਵੈਰੀਫਿਕੇਸ਼ਨ

ਸਾਨੂੰ ਨੈੱਟਵਰਕ ਸਿਰਲੇਖ ਢਾਂਚੇ ਦੀ ਲੋੜ ਹੈ: ਈਥਰਨੈੱਟ (uapi/linux/if_ether.h), IPv4 (uapi/linux/ip.h) ਅਤੇ TCP (uapi/linux/tcp.h). ਪਿਛਲੇ ਇੱਕ ਨਾਲ ਸੰਬੰਧਿਤ ਗਲਤੀਆਂ ਕਾਰਨ ਮੈਂ ਕਨੈਕਟ ਨਹੀਂ ਕਰ ਸਕਿਆ atomic64_t, ਮੈਨੂੰ ਕੋਡ ਵਿੱਚ ਲੋੜੀਂਦੀਆਂ ਪਰਿਭਾਸ਼ਾਵਾਂ ਦੀ ਨਕਲ ਕਰਨੀ ਪਈ।

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

#define INTERNAL static __attribute__((always_inline))

ਮੈਕਰੋ LOG() ਰੀਲੀਜ਼ ਬਿਲਡ ਵਿੱਚ ਪ੍ਰਿੰਟਿੰਗ ਨੂੰ ਅਯੋਗ ਕਰਦਾ ਹੈ।

ਪ੍ਰੋਗਰਾਮ ਫੰਕਸ਼ਨਾਂ ਦੀ ਇੱਕ ਪਾਈਪਲਾਈਨ ਹੈ। ਹਰੇਕ ਨੂੰ ਇੱਕ ਪੈਕੇਟ ਪ੍ਰਾਪਤ ਹੁੰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਸੰਬੰਧਿਤ ਪੱਧਰ ਦਾ ਸਿਰਲੇਖ ਉਜਾਗਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ, process_ether() ਭਰਨ ਦੀ ਉਡੀਕ ਕਰ ਰਿਹਾ ਹੈ ether. ਫੀਲਡ ਵਿਸ਼ਲੇਸ਼ਣ ਦੇ ਨਤੀਜਿਆਂ ਦੇ ਆਧਾਰ 'ਤੇ, ਫੰਕਸ਼ਨ ਪੈਕੇਟ ਨੂੰ ਉੱਚ ਪੱਧਰ 'ਤੇ ਟ੍ਰਾਂਸਫਰ ਕਰ ਸਕਦਾ ਹੈ। ਫੰਕਸ਼ਨ ਦਾ ਨਤੀਜਾ ਇੱਕ XDP ਐਕਸ਼ਨ ਹੈ। ਜਦੋਂ ਕਿ SYN ਅਤੇ ACK ਹੈਂਡਲਰ ਸਾਰੇ ਪੈਕੇਟਾਂ ਨੂੰ ਲੰਘਣ ਦਿੰਦੇ ਹਨ।

struct Packet {
    struct xdp_md* ctx;

    struct ethhdr* ether;
    struct iphdr* ip;
    struct tcphdr* tcp;
};

INTERNAL int process_tcp_syn(struct Packet* packet) { return XDP_PASS; }
INTERNAL int process_tcp_ack(struct Packet* packet) { return XDP_PASS; }
INTERNAL int process_tcp(struct Packet* packet) { ... }
INTERNAL int process_ip(struct Packet* packet) { ... }

INTERNAL int
process_ether(struct Packet* packet) {
    struct ethhdr* ether = packet->ether;

    LOG("Ether(proto=0x%x)", bpf_ntohs(ether->h_proto));

    if (ether->h_proto != bpf_ntohs(ETH_P_IP)) {
        return XDP_PASS;
    }

    // B
    struct iphdr* ip = (struct iphdr*)(ether + 1);
    if ((void*)(ip + 1) > (void*)packet->ctx->data_end) {
        return XDP_DROP; /* malformed packet */
    }

    packet->ip = ip;
    return process_ip(packet);
}

SEC("prog")
int xdp_main(struct xdp_md* ctx) {
    struct Packet packet;
    packet.ctx = ctx;

    // A
    struct ethhdr* ether = (struct ethhdr*)(void*)ctx->data;
    if ((void*)(ether + 1) > (void*)ctx->data_end) {
        return XDP_PASS;
    }

    packet.ether = ether;
    return process_ether(&packet);
}

ਮੈਂ A ਅਤੇ B ਮਾਰਕ ਕੀਤੇ ਚੈਕਾਂ ਵੱਲ ਧਿਆਨ ਖਿੱਚਦਾ ਹਾਂ। ਜੇਕਰ ਤੁਸੀਂ A ਦੀ ਟਿੱਪਣੀ ਕਰਦੇ ਹੋ, ਤਾਂ ਪ੍ਰੋਗਰਾਮ ਬਣ ਜਾਵੇਗਾ, ਪਰ ਲੋਡ ਕਰਨ ਵੇਲੇ ਇੱਕ ਪੁਸ਼ਟੀਕਰਨ ਗਲਤੀ ਹੋਵੇਗੀ:

Verifier analysis:

<...>
11: (7b) *(u64 *)(r10 -48) = r1
12: (71) r3 = *(u8 *)(r7 +13)
invalid access to packet, off=13 size=1, R7(id=0,off=0,r=0)
R7 offset is outside of the packet
processed 11 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0

Error fetching program/map!

ਕੁੰਜੀ ਸਤਰ invalid access to packet, off=13 size=1, R7(id=0,off=0,r=0): ਇੱਥੇ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਮਾਰਗ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਬਫਰ ਦੀ ਸ਼ੁਰੂਆਤ ਤੋਂ ਤੇਰ੍ਹਵਾਂ ਬਾਈਟ ਪੈਕੇਟ ਦੇ ਬਾਹਰ ਹੁੰਦਾ ਹੈ। ਸੂਚੀ ਤੋਂ ਇਹ ਦੱਸਣਾ ਔਖਾ ਹੈ ਕਿ ਅਸੀਂ ਕਿਸ ਲਾਈਨ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ, ਪਰ ਇੱਥੇ ਇੱਕ ਹਦਾਇਤ ਨੰਬਰ (12) ਅਤੇ ਇੱਕ ਡਿਸਸੈਂਬਲਰ ਹੈ ਜੋ ਸਰੋਤ ਕੋਡ ਦੀਆਂ ਲਾਈਨਾਂ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ:

llvm-objdump -S xdp_filter.o | less

ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਇਹ ਲਾਈਨ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ

LOG("Ether(proto=0x%x)", bpf_ntohs(ether->h_proto));

ਜੋ ਇਹ ਸਪੱਸ਼ਟ ਕਰਦਾ ਹੈ ਕਿ ਸਮੱਸਿਆ ਹੈ ether. ਇਹ ਹਮੇਸ਼ਾ ਅਜਿਹਾ ਹੀ ਹੋਵੇਗਾ।

SYN ਨੂੰ ਜਵਾਬ ਦਿਓ

ਇਸ ਪੜਾਅ 'ਤੇ ਟੀਚਾ ਇੱਕ ਸਥਿਰ ਦੇ ਨਾਲ ਇੱਕ ਸਹੀ SYNACK ਪੈਕੇਟ ਤਿਆਰ ਕਰਨਾ ਹੈ seqnum, ਜੋ ਭਵਿੱਖ ਵਿੱਚ SYN ਕੂਕੀ ਦੁਆਰਾ ਬਦਲਿਆ ਜਾਵੇਗਾ। ਵਿੱਚ ਸਾਰੀਆਂ ਤਬਦੀਲੀਆਂ ਹੁੰਦੀਆਂ ਹਨ process_tcp_syn() ਅਤੇ ਆਲੇ ਦੁਆਲੇ.

ਪੈਕੇਜ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ

ਅਜੀਬ ਤੌਰ 'ਤੇ, ਇੱਥੇ ਸਭ ਤੋਂ ਕਮਾਲ ਦੀ ਲਾਈਨ ਹੈ, ਜਾਂ ਇਸ ਦੀ ਬਜਾਏ, ਇਸ ਲਈ ਇੱਕ ਟਿੱਪਣੀ:

/* Required to verify checksum calculation */
const void* data_end = (const void*)ctx->data_end;

ਕੋਡ ਦੇ ਪਹਿਲੇ ਸੰਸਕਰਣ ਨੂੰ ਲਿਖਣ ਵੇਲੇ, 5.1 ਕਰਨਲ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਗਈ ਸੀ, ਜਿਸ ਦੇ ਤਸਦੀਕ ਕਰਨ ਵਾਲੇ ਵਿੱਚ ਇੱਕ ਅੰਤਰ ਸੀ data_end и (const void*)ctx->data_end. ਲਿਖਣ ਦੇ ਸਮੇਂ, 5.3.1 ਕਰਨਲ ਵਿੱਚ ਇਹ ਸਮੱਸਿਆ ਨਹੀਂ ਸੀ। ਸ਼ਾਇਦ ਕੰਪਾਈਲਰ ਇੱਕ ਖੇਤਰ ਨਾਲੋਂ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਇੱਕ ਸਥਾਨਕ ਵੇਰੀਏਬਲ ਤੱਕ ਪਹੁੰਚ ਕਰ ਰਿਹਾ ਸੀ। ਨੈਤਿਕ - ਇੱਕ ਵੱਡੇ ਆਲ੍ਹਣੇ 'ਤੇ, ਕੋਡ ਨੂੰ ਸਰਲ ਬਣਾਉਣਾ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ.

ਤਸਦੀਕ ਕਰਨ ਵਾਲੇ ਦੀ ਮਹਿਮਾ ਲਈ ਲੰਬਾਈ ਦੀ ਹੋਰ ਰੁਟੀਨ ਜਾਂਚ; ਓ MAX_CSUM_BYTES ਹੇਠਾਂ.

const u32 ip_len = ip->ihl * 4;
if ((void*)ip + ip_len > data_end) {
    return XDP_DROP; /* malformed packet */
}
if (ip_len > MAX_CSUM_BYTES) {
    return XDP_ABORTED; /* implementation limitation */
}

const u32 tcp_len = tcp->doff * 4;
if ((void*)tcp + tcp_len > (void*)ctx->data_end) {
    return XDP_DROP; /* malformed packet */
}
if (tcp_len > MAX_CSUM_BYTES) {
    return XDP_ABORTED; /* implementation limitation */
}

ਪੈਕੇਜ ਫੈਲਾਓ

ਅਸੀਂ ਭਰਦੇ ਹਾਂ seqnum и acknum, ACK ਸੈੱਟ ਕਰੋ (SYN ਪਹਿਲਾਂ ਹੀ ਸੈੱਟ ਹੈ):

const u32 cookie = 42;
tcp->ack_seq = bpf_htonl(bpf_ntohl(tcp->seq) + 1);
tcp->seq = bpf_htonl(cookie);
tcp->ack = 1;

TCP ਪੋਰਟਾਂ, IP ਅਤੇ MAC ਐਡਰੈੱਸ ਨੂੰ ਸਵੈਪ ਕਰੋ। ਸਟੈਂਡਰਡ ਲਾਇਬ੍ਰੇਰੀ XDP ਪ੍ਰੋਗਰਾਮ ਤੋਂ ਉਪਲਬਧ ਨਹੀਂ ਹੈ, ਇਸ ਲਈ memcpy() - ਇੱਕ ਮੈਕਰੋ ਜੋ ਕਲੈਂਗ ਅੰਦਰੂਨੀ ਨੂੰ ਲੁਕਾਉਂਦਾ ਹੈ।

const u16 temp_port = tcp->source;
tcp->source = tcp->dest;
tcp->dest = temp_port;

const u32 temp_ip = ip->saddr;
ip->saddr = ip->daddr;
ip->daddr = temp_ip;

struct ethhdr temp_ether = *ether;
memcpy(ether->h_dest, temp_ether.h_source, ETH_ALEN);
memcpy(ether->h_source, temp_ether.h_dest, ETH_ALEN);

ਚੈਕਸਮ ਮੁੜ ਗਣਨਾ

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

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

ਚੈੱਕਸਮ ਗਣਨਾ ਫੰਕਸ਼ਨ:

#define MAX_CSUM_WORDS 32
#define MAX_CSUM_BYTES (MAX_CSUM_WORDS * 2)

INTERNAL u32
sum16(const void* data, u32 size, const void* data_end) {
    u32 s = 0;
#pragma unroll
    for (u32 i = 0; i < MAX_CSUM_WORDS; i++) {
        if (2*i >= size) {
            return s; /* normal exit */
        }
        if (data + 2*i + 1 + 1 > data_end) {
            return 0; /* should be unreachable */
        }
        s += ((const u16*)data)[i];
    }
    return s;
}

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

32-ਬਿੱਟ ਸ਼ਬਦਾਂ ਲਈ, ਇੱਕ ਸਰਲ ਸੰਸਕਰਣ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ:

INTERNAL u32
sum16_32(u32 v) {
    return (v >> 16) + (v & 0xffff);
}

ਅਸਲ ਵਿੱਚ ਚੈੱਕਸਮਾਂ ਦੀ ਮੁੜ ਗਣਨਾ ਕਰਨਾ ਅਤੇ ਪੈਕੇਟ ਨੂੰ ਵਾਪਸ ਭੇਜਣਾ:

ip->check = 0;
ip->check = carry(sum16(ip, ip_len, data_end));

u32 tcp_csum = 0;
tcp_csum += sum16_32(ip->saddr);
tcp_csum += sum16_32(ip->daddr);
tcp_csum += 0x0600;
tcp_csum += tcp_len << 8;
tcp->check = 0;
tcp_csum += sum16(tcp, tcp_len, data_end);
tcp->check = carry(tcp_csum);

return XDP_TX;

ਫੰਕਸ਼ਨ carry() RFC 32 ਦੇ ਅਨੁਸਾਰ, 16-ਬਿੱਟ ਸ਼ਬਦਾਂ ਦੇ 791-ਬਿੱਟ ਜੋੜ ਵਿੱਚੋਂ ਇੱਕ ਚੈੱਕਸਮ ਬਣਾਉਂਦਾ ਹੈ।

TCP ਹੈਂਡਸ਼ੇਕ ਚੈੱਕ

ਫਿਲਟਰ ਸਹੀ ਢੰਗ ਨਾਲ ਨਾਲ ਇੱਕ ਕੁਨੈਕਸ਼ਨ ਸਥਾਪਤ ਕਰਦਾ ਹੈ netcat, ਫਾਈਨਲ ACK ਨੂੰ ਛੱਡਣਾ, ਜਿਸ ਲਈ ਲੀਨਕਸ ਨੇ ਇੱਕ RST ਪੈਕੇਟ ਨਾਲ ਜਵਾਬ ਦਿੱਤਾ, ਕਿਉਂਕਿ ਨੈੱਟਵਰਕ ਸਟੈਕ ਨੂੰ ਇੱਕ SYN ਨਹੀਂ ਮਿਲਿਆ - ਇਸਨੂੰ SYNACK ਵਿੱਚ ਬਦਲਿਆ ਗਿਆ ਅਤੇ ਵਾਪਸ ਭੇਜਿਆ ਗਿਆ - ਅਤੇ OS ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਇੱਕ ਪੈਕੇਟ ਆਇਆ ਜੋ ਨਹੀਂ ਸੀ। ਖੁੱਲੇ ਕੁਨੈਕਸ਼ਨਾਂ ਨਾਲ ਸਬੰਧਤ.

$ sudo ip netns exec xdp-test   nc -nv 192.0.2.1 6666
192.0.2.1 6666: Connection reset by peer

ਪੂਰੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀ ਜਾਂਚ ਕਰਨਾ ਅਤੇ ਨਿਰੀਖਣ ਕਰਨਾ ਮਹੱਤਵਪੂਰਨ ਹੈ tcpdump 'ਤੇ xdp-remote ਕਿਉਂਕਿ, ਉਦਾਹਰਨ ਲਈ, hping3 ਗਲਤ ਚੈੱਕਸਮਾਂ ਦਾ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦਾ।

SYN ਕੂਕੀ

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

ਬਾਹਰੀ ਪਰਸਪਰ ਪ੍ਰਭਾਵ ਨਾਲ ਸਬੰਧਤ ਨਵੇਂ TODOs ਲਈ ਪ੍ਰਗਟ ਹੋਇਆ:

• XDP ਪ੍ਰੋਗਰਾਮ ਸਟੋਰ ਨਹੀਂ ਕਰ ਸਕਦਾ cookie_seed (ਲੂਣ ਦਾ ਗੁਪਤ ਹਿੱਸਾ) ਇੱਕ ਗਲੋਬਲ ਵੇਰੀਏਬਲ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਇੱਕ ਕਰਨਲ ਸਟੋਰ ਦੀ ਲੋੜ ਹੈ ਜਿਸਦਾ ਮੁੱਲ ਸਮੇਂ-ਸਮੇਂ ਤੇ ਇੱਕ ਭਰੋਸੇਯੋਗ ਜਨਰੇਟਰ ਤੋਂ ਅਪਡੇਟ ਕੀਤਾ ਜਾਵੇਗਾ।

• ਜੇਕਰ ACK ਪੈਕੇਟ ਵਿੱਚ SYN ਕੂਕੀ ਮੇਲ ਖਾਂਦੀ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਇੱਕ ਸੁਨੇਹਾ ਪ੍ਰਿੰਟ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਪਰ ਇਸ ਤੋਂ ਪੈਕੇਟ ਨੂੰ ਛੱਡਣ ਲਈ ਪ੍ਰਮਾਣਿਤ ਕਲਾਇੰਟ ਦਾ IP ਯਾਦ ਰੱਖੋ।

ਇੱਕ ਜਾਇਜ਼ ਗਾਹਕ ਦੁਆਰਾ ਪ੍ਰਮਾਣਿਕਤਾ:

$ sudoip netns exec xdp-test   nc -nv 192.0.2.1 6666
192.0.2.1 6666: Connection reset by peer

ਲਾਗਾਂ ਨੇ ਚੈੱਕ ਦੇ ਬੀਤਣ ਨੂੰ ਰਿਕਾਰਡ ਕੀਤਾ (flags=0x2 SYN ਹੈ flags=0x10 ACK ਹੈ):

Ether(proto=0x800)
  IP(src=0x20e6e11a dst=0x20e6e11e proto=6)
    TCP(sport=50836 dport=6666 flags=0x2)
Ether(proto=0x800)
  IP(src=0xfe2cb11a dst=0xfe2cb11e proto=6)
    TCP(sport=50836 dport=6666 flags=0x10)
      cookie matches for client 20200c0

ਜਦੋਂ ਤੱਕ ਪ੍ਰਮਾਣਿਤ IP ਦੀ ਕੋਈ ਸੂਚੀ ਨਹੀਂ ਹੈ, ਉਦੋਂ ਤੱਕ SYN ਹੜ੍ਹ ਦੇ ਵਿਰੁੱਧ ਕੋਈ ਸੁਰੱਖਿਆ ਨਹੀਂ ਹੋਵੇਗੀ, ਪਰ ਇੱਥੇ ਇਸ ਕਮਾਂਡ ਦੁਆਰਾ ਲਾਂਚ ਕੀਤੇ ਗਏ ACK ਹੜ੍ਹ ਦੀ ਪ੍ਰਤੀਕ੍ਰਿਆ ਹੈ:

sudo ip netns exec xdp-test   hping3 --flood -A -s 1111 -p 2222 192.0.2.1

ਲੌਗ ਐਂਟਰੀਆਂ:

Ether(proto=0x800)
  IP(src=0x15bd11a dst=0x15bd11e proto=6)
    TCP(sport=3236 dport=2222 flags=0x10)
      cookie mismatch

ਸਿੱਟਾ

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

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

ਲਿੰਕ:

• GitHub 'ਤੇ ਪੂਰਾ ਕੋਡ
• bpftrace ਚੀਟ ਸ਼ੀਟ
• BPF ਅਤੇ XDP ਸੰਦਰਭ ਗਾਈਡ
• XDP ਟਿਊਟੋਰਿਅਲ
• PoC: Rust ਤੋਂ eBPF ਨੂੰ ਕੰਪਾਇਲ ਕਰਨਾ

ਸਰੋਤ: www.habr.com