ਇਹ ਲੇਖ "ਤੁਹਾਡੇ ਨੈੱਟਵਰਕ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦਾ ਨਿਯੰਤਰਣ ਕਿਵੇਂ ਲੈਣਾ ਹੈ" ਦੀ ਲੜੀ ਵਿੱਚ ਚੌਥਾ ਹੈ। ਲੜੀ ਦੇ ਸਾਰੇ ਲੇਖਾਂ ਦੀ ਸਮੱਗਰੀ ਅਤੇ ਲਿੰਕ ਲੱਭੇ ਜਾ ਸਕਦੇ ਹਨ ਇੱਥੇ.

В ਪਹਿਲਾ ਭਾਗ ਇਸ ਚੈਪਟਰ ਵਿੱਚ, ਅਸੀਂ ਡਾਟਾ ਸੈਂਟਰ ਖੰਡ ਵਿੱਚ ਨੈੱਟਵਰਕ ਸੁਰੱਖਿਆ ਦੇ ਕੁਝ ਪਹਿਲੂਆਂ ਨੂੰ ਦੇਖਿਆ। ਇਹ ਹਿੱਸਾ "ਇੰਟਰਨੈੱਟ ਐਕਸੈਸ" ਹਿੱਸੇ ਨੂੰ ਸਮਰਪਿਤ ਕੀਤਾ ਜਾਵੇਗਾ।

ਇੰਟਰਨੈੱਟ ਪਹੁੰਚ

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

ਇਸ ਹਿੱਸੇ ਦਾ ਆਡਿਟ ਕਰਦੇ ਸਮੇਂ, ਹੇਠਾਂ ਦਿੱਤੇ ਪਹਿਲੂਆਂ ਵੱਲ ਧਿਆਨ ਦਿਓ:

• ਡਿਜ਼ਾਇਨ
• BGP ਸੈਟਿੰਗਾਂ
• DOS/DDOS ਸੁਰੱਖਿਆ
• ਫਾਇਰਵਾਲ 'ਤੇ ਟ੍ਰੈਫਿਕ ਫਿਲਟਰਿੰਗ

ਡਿਜ਼ਾਈਨ

ਇੱਕ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਨੈਟਵਰਕ ਲਈ ਇਸ ਹਿੱਸੇ ਦੇ ਡਿਜ਼ਾਈਨ ਦੀ ਇੱਕ ਉਦਾਹਰਣ ਵਜੋਂ, ਮੈਂ ਸਿਫਾਰਸ਼ ਕਰਾਂਗਾ ਅਗਵਾਈ ਅੰਦਰ ਸਿਸਕੋ ਤੋਂ ਸੁਰੱਖਿਅਤ ਮਾਡਲ.

ਬੇਸ਼ੱਕ, ਸ਼ਾਇਦ ਦੂਜੇ ਵਿਕਰੇਤਾਵਾਂ ਦਾ ਹੱਲ ਤੁਹਾਡੇ ਲਈ ਵਧੇਰੇ ਆਕਰਸ਼ਕ ਲੱਗੇਗਾ (ਵੇਖੋ. ਗਾਰਟਨਰ ਕਵਾਡਰੈਂਟ 2018), ਪਰ ਤੁਹਾਨੂੰ ਇਸ ਡਿਜ਼ਾਈਨ ਦੀ ਵਿਸਥਾਰ ਨਾਲ ਪਾਲਣਾ ਕਰਨ ਲਈ ਉਤਸ਼ਾਹਿਤ ਕੀਤੇ ਬਿਨਾਂ, ਮੈਨੂੰ ਅਜੇ ਵੀ ਇਸਦੇ ਪਿੱਛੇ ਸਿਧਾਂਤਾਂ ਅਤੇ ਵਿਚਾਰਾਂ ਨੂੰ ਸਮਝਣਾ ਲਾਭਦਾਇਕ ਲੱਗਦਾ ਹੈ।

ਨੋਟ

SAFE ਵਿੱਚ, "ਰਿਮੋਟ ਐਕਸੈਸ" ਖੰਡ "ਇੰਟਰਨੈਟ ਐਕਸੈਸ" ਹਿੱਸੇ ਦਾ ਹਿੱਸਾ ਹੈ। ਪਰ ਲੇਖਾਂ ਦੀ ਇਸ ਲੜੀ ਵਿੱਚ ਅਸੀਂ ਇਸ ਬਾਰੇ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਵਿਚਾਰ ਕਰਾਂਗੇ।

ਇੱਕ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਨੈਟਵਰਕ ਲਈ ਇਸ ਹਿੱਸੇ ਵਿੱਚ ਸਾਜ਼-ਸਾਮਾਨ ਦਾ ਮਿਆਰੀ ਸੈੱਟ ਹੈ

• ਬਾਰਡਰ ਰਾਊਟਰ
• ਫਾਇਰਵਾਲ

ਟਿੱਪਣੀ 1

ਲੇਖਾਂ ਦੀ ਇਸ ਲੜੀ ਵਿੱਚ, ਜਦੋਂ ਮੈਂ ਫਾਇਰਵਾਲਾਂ ਬਾਰੇ ਗੱਲ ਕਰਦਾ ਹਾਂ, ਮੇਰਾ ਮਤਲਬ ਹੈ NGFW.

ਟਿੱਪਣੀ 2

ਮੈਂ L2/L1 ਕਨੈਕਟੀਵਿਟੀ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਲੋੜੀਂਦੇ L2 ਹੱਲਾਂ 'ਤੇ L3/L1 ਦੀਆਂ ਵੱਖ-ਵੱਖ ਕਿਸਮਾਂ ਜਾਂ ਓਵਰਲੇ L2 ਦੇ ਵਿਚਾਰ ਨੂੰ ਛੱਡਦਾ ਹਾਂ ਅਤੇ ਆਪਣੇ ਆਪ ਨੂੰ ਸਿਰਫ਼ L3 ਪੱਧਰ ਅਤੇ ਇਸ ਤੋਂ ਉੱਪਰ ਦੇ ਮੁੱਦਿਆਂ ਤੱਕ ਸੀਮਤ ਕਰਦਾ ਹਾਂ। ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ, ਅਧਿਆਇ ਵਿੱਚ L1/L2 ਮੁੱਦਿਆਂ 'ਤੇ ਚਰਚਾ ਕੀਤੀ ਗਈ ਸੀ।ਸਫਾਈ ਅਤੇ ਦਸਤਾਵੇਜ਼".

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

ਦੇ ਵਿੱਚ ਵਾਂਗ ਹੀ ਕਰੀਏ ਪਿਛਲੇ ਭਾਗਆਉ ਇਸ ਸਵਾਲ ਨਾਲ ਸ਼ੁਰੂ ਕਰੀਏ: ਕੀ ਤੁਹਾਡੇ ਕੇਸ ਵਿੱਚ ਇਸ ਹਿੱਸੇ ਵਿੱਚ ਫਾਇਰਵਾਲ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ?

ਮੈਂ ਕਹਿ ਸਕਦਾ ਹਾਂ ਕਿ ਇਹ ਫਾਇਰਵਾਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਅਤੇ ਗੁੰਝਲਦਾਰ ਟ੍ਰੈਫਿਕ ਫਿਲਟਰਿੰਗ ਐਲਗੋਰਿਦਮ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਸਭ ਤੋਂ ਜਾਇਜ਼ ਸਥਾਨ ਜਾਪਦਾ ਹੈ. IN ਭਾਗ 1 ਅਸੀਂ 4 ਕਾਰਕਾਂ ਦਾ ਜ਼ਿਕਰ ਕੀਤਾ ਹੈ ਜੋ ਡਾਟਾ ਸੈਂਟਰ ਖੰਡ ਵਿੱਚ ਫਾਇਰਵਾਲ ਦੀ ਵਰਤੋਂ ਵਿੱਚ ਦਖਲ ਦੇ ਸਕਦੇ ਹਨ। ਪਰ ਇੱਥੇ ਉਹ ਹੁਣ ਇੰਨੇ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਹਨ.

1 ਉਦਾਹਰਨ. ਦੇਰੀ

ਜਿੱਥੋਂ ਤੱਕ ਇੰਟਰਨੈਟ ਦਾ ਸਬੰਧ ਹੈ, ਲਗਭਗ 1 ਮਿਲੀਸਕਿੰਟ ਦੀ ਦੇਰੀ ਬਾਰੇ ਗੱਲ ਕਰਨ ਦਾ ਕੋਈ ਮਤਲਬ ਨਹੀਂ ਹੈ। ਇਸ ਲਈ, ਇਸ ਹਿੱਸੇ ਵਿੱਚ ਦੇਰੀ ਫਾਇਰਵਾਲ ਦੀ ਵਰਤੋਂ ਨੂੰ ਸੀਮਿਤ ਕਰਨ ਵਾਲਾ ਕਾਰਕ ਨਹੀਂ ਹੋ ਸਕਦੀ।

2 ਉਦਾਹਰਨ. ਉਤਪਾਦਕਤਾ

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

3 ਉਦਾਹਰਨ. ਭਰੋਸੇਯੋਗਤਾ

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

ਇਸ ਲਈ, ਮੰਨ ਲਓ ਕਿ ਤੁਹਾਡੀ ਸੇਵਾ http/https (ਛੋਟੇ ਸੈਸ਼ਨਾਂ ਦੇ ਨਾਲ) ਦੇ ਸਿਖਰ 'ਤੇ ਰਹਿੰਦੀ ਹੈ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਤੁਸੀਂ ਦੋ ਸੁਤੰਤਰ ਬਕਸੇ (ਐਚਏ ਤੋਂ ਬਿਨਾਂ) ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਜੇਕਰ ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨਾਲ ਰੂਟਿੰਗ ਦੀ ਸਮੱਸਿਆ ਹੈ, ਤਾਂ ਸਾਰੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਦੂਜੇ ਵਿੱਚ ਟ੍ਰਾਂਸਫਰ ਕਰੋ।

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

ਇਸ ਲਈ, ਸਭ ਤੋਂ ਵੱਧ ਸੰਭਾਵਨਾ ਸਿਰਫ ਕੀਮਤ ਉਹ ਕਾਰਕ ਹੋ ਸਕਦਾ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਇਸ ਹਿੱਸੇ ਵਿੱਚ ਫਾਇਰਵਾਲਾਂ ਦੀ ਵਰਤੋਂ ਨੂੰ ਛੱਡਣ ਲਈ ਮਜ਼ਬੂਰ ਕਰੇਗਾ।

ਮਹੱਤਵਪੂਰਨ!

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

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

ਉਦਾਹਰਨ:

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

BGP ਲਈ ਜ਼ਰੂਰੀ ਨਹੀਂ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਸਮਰਪਿਤ ਰਾਊਟਰ ਹੋਣ, ਤੁਸੀਂ ਓਪਨ-ਸੋਰਸ ਟੂਲਸ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ ਜਿਵੇਂ ਕਿ ਕਵਾਗਾ. ਇਸ ਲਈ ਸ਼ਾਇਦ ਤੁਹਾਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਸਰਵਰ ਜਾਂ ਕਈ ਸਰਵਰਾਂ, ਇੱਕ ਸਵਿੱਚ ਅਤੇ BGP ਦੀ ਲੋੜ ਹੈ।

ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਤੁਹਾਡਾ ਸਰਵਰ ਜਾਂ ਕਈ ਸਰਵਰ ਨਾ ਸਿਰਫ ਇੱਕ CDN ਸਰਵਰ, ਬਲਕਿ ਇੱਕ ਰਾਊਟਰ ਦੀ ਭੂਮਿਕਾ ਨਿਭਾ ਸਕਦੇ ਹਨ। ਬੇਸ਼ੱਕ, ਅਜੇ ਵੀ ਬਹੁਤ ਸਾਰੇ ਵੇਰਵੇ ਹਨ (ਜਿਵੇਂ ਕਿ ਸੰਤੁਲਨ ਨੂੰ ਕਿਵੇਂ ਯਕੀਨੀ ਬਣਾਉਣਾ ਹੈ), ਪਰ ਇਹ ਸੰਭਵ ਹੈ, ਅਤੇ ਇਹ ਇੱਕ ਪਹੁੰਚ ਹੈ ਜੋ ਅਸੀਂ ਆਪਣੇ ਇੱਕ ਭਾਈਵਾਲ ਲਈ ਸਫਲਤਾਪੂਰਵਕ ਵਰਤੀ ਹੈ।

ਤੁਹਾਡੇ ਕੋਲ ਪੂਰੀ ਸੁਰੱਖਿਆ (ਫਾਇਰਵਾਲ, ਤੁਹਾਡੇ ਇੰਟਰਨੈਟ ਪ੍ਰਦਾਤਾਵਾਂ ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੀਆਂ ਗਈਆਂ DDOS ਸੁਰੱਖਿਆ ਸੇਵਾਵਾਂ) ਅਤੇ ਸਿਰਫ਼ L2 ਸਵਿੱਚਾਂ ਅਤੇ ਸਰਵਰਾਂ ਦੇ ਨਾਲ ਦਰਜਨਾਂ ਜਾਂ ਸੈਂਕੜੇ "ਸਰਲ" ਪੁਆਇੰਟ ਮੌਜੂਦ ਹੋ ਸਕਦੇ ਹਨ।

ਪਰ ਇਸ ਮਾਮਲੇ ਵਿੱਚ ਸੁਰੱਖਿਆ ਬਾਰੇ ਕੀ?

ਆਓ ਦੇਖੀਏ, ਉਦਾਹਰਨ ਲਈ, ਹਾਲ ਹੀ ਵਿੱਚ ਪ੍ਰਸਿੱਧ DNS ਐਂਪਲੀਫਿਕੇਸ਼ਨ DDOS ਹਮਲਾ. ਇਸਦਾ ਖ਼ਤਰਾ ਇਸ ਤੱਥ ਵਿੱਚ ਹੈ ਕਿ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਟ੍ਰੈਫਿਕ ਪੈਦਾ ਹੁੰਦਾ ਹੈ, ਜੋ ਤੁਹਾਡੇ ਸਾਰੇ ਅਪਲਿੰਕਸ ਦੇ 100% ਨੂੰ ਸਿਰਫ਼ "ਬੰਦ" ਕਰਦਾ ਹੈ।

ਸਾਡੇ ਡਿਜ਼ਾਈਨ ਦੇ ਮਾਮਲੇ ਵਿਚ ਸਾਡੇ ਕੋਲ ਕੀ ਹੈ.

• ਜੇਕਰ ਤੁਸੀਂ AnyCast ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ, ਤਾਂ ਟ੍ਰੈਫਿਕ ਤੁਹਾਡੀ ਮੌਜੂਦਗੀ ਦੇ ਬਿੰਦੂਆਂ ਵਿਚਕਾਰ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ। ਜੇ ਤੁਹਾਡੀ ਕੁੱਲ ਬੈਂਡਵਿਡਥ ਟੈਰਾਬਿਟ ਹੈ, ਤਾਂ ਇਹ ਅਸਲ ਵਿੱਚ ਆਪਣੇ ਆਪ ਵਿੱਚ (ਹਾਲਾਂਕਿ, ਹਾਲ ਹੀ ਵਿੱਚ ਟੈਰਾਬਿਟ ਦੇ ਕ੍ਰਮ 'ਤੇ ਖਤਰਨਾਕ ਟ੍ਰੈਫਿਕ ਦੇ ਨਾਲ ਕਈ ਹਮਲੇ ਹੋਏ ਹਨ) ਤੁਹਾਨੂੰ "ਓਵਰਫਲੋਇੰਗ" ਅੱਪਲਿੰਕਸ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।
• ਜੇਕਰ, ਹਾਲਾਂਕਿ, ਕੁਝ ਅੱਪਲਿੰਕਸ ਬੰਦ ਹੋ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਇਸ ਸਾਈਟ ਨੂੰ ਸੇਵਾ ਤੋਂ ਹਟਾ ਦਿੰਦੇ ਹੋ (ਅਗੇਤਰ ਵਿਗਿਆਪਨ ਬੰਦ ਕਰੋ)
• ਤੁਸੀਂ ਆਪਣੇ "ਪੂਰੇ" (ਅਤੇ, ਇਸ ਅਨੁਸਾਰ, ਸੁਰੱਖਿਅਤ) ਡੇਟਾ ਸੈਂਟਰਾਂ ਤੋਂ ਭੇਜੇ ਗਏ ਟ੍ਰੈਫਿਕ ਦੇ ਹਿੱਸੇ ਨੂੰ ਵੀ ਵਧਾ ਸਕਦੇ ਹੋ, ਇਸ ਤਰ੍ਹਾਂ ਮੌਜੂਦਗੀ ਦੇ ਅਸੁਰੱਖਿਅਤ ਬਿੰਦੂਆਂ ਤੋਂ ਖਤਰਨਾਕ ਟ੍ਰੈਫਿਕ ਦੇ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਹਿੱਸੇ ਨੂੰ ਹਟਾ ਸਕਦੇ ਹੋ।

ਅਤੇ ਇਸ ਉਦਾਹਰਨ ਲਈ ਇੱਕ ਹੋਰ ਛੋਟਾ ਨੋਟ. ਜੇਕਰ ਤੁਸੀਂ IXs ਰਾਹੀਂ ਕਾਫੀ ਟ੍ਰੈਫਿਕ ਭੇਜਦੇ ਹੋ, ਤਾਂ ਇਹ ਅਜਿਹੇ ਹਮਲਿਆਂ ਪ੍ਰਤੀ ਤੁਹਾਡੀ ਕਮਜ਼ੋਰੀ ਨੂੰ ਵੀ ਘਟਾਉਂਦਾ ਹੈ

BGP ਦੀ ਸਥਾਪਨਾ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ

ਇੱਥੇ ਦੋ ਵਿਸ਼ੇ ਹਨ।

• ਕਨੈਕਟੀਵਿਟੀ
• BGP ਦੀ ਸਥਾਪਨਾ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ

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

ਮਿਸਾਲ 1

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

ਮਿਸਾਲ 2

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

ਮਿਸਾਲ 3

ਤੁਹਾਨੂੰ ਇਹ ਵੀ ਸਮਝਣ ਦੀ ਲੋੜ ਹੈ ਕਿ, TCP ਪ੍ਰੋਟੋਕੋਲ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਕਾਰਨ, ਇੱਕ TCP ਸੈਸ਼ਨ ਦੇ ਅੰਦਰ ਡਾਟਾ ਟ੍ਰਾਂਸਫਰ ਦਰ ਵੀ RTT (ਰਾਊਂਡ ਟ੍ਰਿਪ ਟਾਈਮ) 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। ਸਮੱਗਰੀ ਵੰਡ ਸਰਵਰਾਂ ਨੂੰ ਇਸ ਸਮਗਰੀ ਦੇ ਖਪਤਕਾਰਾਂ ਦੇ ਨੇੜੇ ਲਿਜਾ ਕੇ ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ CDN ਨੈਟਵਰਕ ਵੀ ਬਣਾਏ ਜਾ ਰਹੇ ਹਨ।

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

ਉਪਯੋਗੀ ਸਰੋਤ:

ripe.net
bgp.he.net

ਉਦਾਹਰਨ:

ਮੈਂ ਸਿਰਫ਼ ਇੱਕ ਛੋਟੀ ਜਿਹੀ ਉਦਾਹਰਣ ਦੇਵਾਂਗਾ।

ਮੰਨ ਲਓ ਕਿ ਤੁਹਾਡਾ ਡੇਟਾ ਸੈਂਟਰ ਮਾਸਕੋ ਵਿੱਚ ਸਥਿਤ ਹੈ, ਅਤੇ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਸਿੰਗਲ ਅਪਲਿੰਕ ਹੈ - ਰੋਸਟੇਲੀਕਾਮ (AS12389). ਇਸ ਸਥਿਤੀ ਵਿੱਚ (ਸਿੰਗਲ ਹੋਮਡ) ਤੁਹਾਨੂੰ BGP ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਜਨਤਕ ਪਤਿਆਂ ਦੇ ਤੌਰ 'ਤੇ Rostelecom ਤੋਂ ਐਡਰੈੱਸ ਪੂਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ।

ਮੰਨ ਲਓ ਕਿ ਤੁਸੀਂ ਇੱਕ ਖਾਸ ਸੇਵਾ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹੋ, ਅਤੇ ਤੁਹਾਡੇ ਕੋਲ ਯੂਕਰੇਨ ਤੋਂ ਕਾਫ਼ੀ ਗਿਣਤੀ ਵਿੱਚ ਗਾਹਕ ਹਨ, ਅਤੇ ਉਹ ਲੰਬੇ ਦੇਰੀ ਬਾਰੇ ਸ਼ਿਕਾਇਤ ਕਰਦੇ ਹਨ। ਤੁਹਾਡੀ ਖੋਜ ਦੌਰਾਨ, ਤੁਹਾਨੂੰ ਪਤਾ ਲੱਗਾ ਹੈ ਕਿ ਉਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਦੇ IP ਐਡਰੈੱਸ 37.52.0.0/21 ਗਰਿੱਡ ਵਿੱਚ ਹਨ।

ਇੱਕ ਟਰੇਸਰੂਟ ਚਲਾ ਕੇ, ਤੁਸੀਂ ਦੇਖਿਆ ਕਿ ਟ੍ਰੈਫਿਕ AS1299 (Telia) ਰਾਹੀਂ ਜਾ ਰਿਹਾ ਸੀ, ਅਤੇ ਇੱਕ ਪਿੰਗ ਚਲਾ ਕੇ, ਤੁਸੀਂ 70 - 80 ਮਿਲੀਸਕਿੰਟ ਦੀ ਔਸਤ RTT ਪ੍ਰਾਪਤ ਕੀਤੀ। ਤੁਸੀਂ ਇਸ 'ਤੇ ਵੀ ਦੇਖ ਸਕਦੇ ਹੋ ਦਿੱਖ ਗਲਾਸ Rostelecom.

whois ਉਪਯੋਗਤਾ (ripe.net ਜਾਂ ਇੱਕ ਸਥਾਨਕ ਉਪਯੋਗਤਾ 'ਤੇ) ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਤੁਸੀਂ ਆਸਾਨੀ ਨਾਲ ਨਿਰਧਾਰਤ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਬਲਾਕ 37.52.0.0/21 AS6849 (Ukrtelecom) ਨਾਲ ਸਬੰਧਤ ਹੈ।

ਅੱਗੇ, ਜਾ ਕੇ bgp.he.net ਤੁਸੀਂ ਦੇਖਦੇ ਹੋ ਕਿ AS6849 ਦਾ AS12389 ਨਾਲ ਕੋਈ ਰਿਸ਼ਤਾ ਨਹੀਂ ਹੈ (ਉਹ ਨਾ ਤਾਂ ਗਾਹਕ ਹਨ ਅਤੇ ਨਾ ਹੀ ਇੱਕ ਦੂਜੇ ਨਾਲ ਅੱਪਲਿੰਕ ਹਨ, ਨਾ ਹੀ ਉਹਨਾਂ ਕੋਲ ਪੀਅਰਿੰਗ ਹੈ)। ਪਰ ਜੇ ਤੁਸੀਂ ਦੇਖਦੇ ਹੋ ਸਾਥੀਆਂ ਦੀ ਸੂਚੀ AS6849 ਲਈ, ਤੁਸੀਂ ਦੇਖੋਗੇ, ਉਦਾਹਰਨ ਲਈ, AS29226 (Mastertel) ਅਤੇ AS31133 (Megafon)।

ਇੱਕ ਵਾਰ ਜਦੋਂ ਤੁਸੀਂ ਇਹਨਾਂ ਪ੍ਰਦਾਤਾਵਾਂ ਦੇ ਦਿੱਖ ਵਾਲੇ ਸ਼ੀਸ਼ੇ ਨੂੰ ਲੱਭ ਲੈਂਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਮਾਰਗ ਅਤੇ RTT ਦੀ ਤੁਲਨਾ ਕਰ ਸਕਦੇ ਹੋ। ਉਦਾਹਰਨ ਲਈ, Mastertel RTT ਲਈ ਲਗਭਗ 30 ਮਿਲੀਸਕਿੰਟ ਹੋਵੇਗੀ।

ਇਸ ਲਈ, ਜੇਕਰ ਤੁਹਾਡੀ ਸੇਵਾ ਲਈ 80 ਅਤੇ 30 ਮਿਲੀਸਕਿੰਟ ਵਿਚਕਾਰ ਅੰਤਰ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਤਾਂ ਸ਼ਾਇਦ ਤੁਹਾਨੂੰ ਕਨੈਕਟੀਵਿਟੀ ਬਾਰੇ ਸੋਚਣ, ਆਪਣਾ AS ਨੰਬਰ, RIPE ਤੋਂ ਆਪਣਾ ਪਤਾ ਪੂਲ ਪ੍ਰਾਪਤ ਕਰਨ ਅਤੇ ਵਾਧੂ ਅਪਲਿੰਕਸ ਨੂੰ ਜੋੜਨ ਅਤੇ/ਜਾਂ IXs 'ਤੇ ਮੌਜੂਦਗੀ ਦੇ ਪੁਆਇੰਟ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ।

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

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

DOS/DDOS ਸੁਰੱਖਿਆ

ਹੁਣ DOS/DDOS ਹਮਲੇ ਬਹੁਤ ਸਾਰੀਆਂ ਕੰਪਨੀਆਂ ਲਈ ਰੋਜ਼ਾਨਾ ਦੀ ਹਕੀਕਤ ਬਣ ਗਏ ਹਨ। ਅਸਲ ਵਿੱਚ, ਤੁਹਾਡੇ 'ਤੇ ਅਕਸਰ ਕਿਸੇ ਨਾ ਕਿਸੇ ਰੂਪ ਵਿੱਚ ਹਮਲਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਸ ਤੱਥ ਦਾ ਕਿ ਤੁਸੀਂ ਅਜੇ ਤੱਕ ਇਸ ਵੱਲ ਧਿਆਨ ਨਹੀਂ ਦਿੱਤਾ ਹੈ, ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਤੁਹਾਡੇ ਵਿਰੁੱਧ ਅਜੇ ਤੱਕ ਇੱਕ ਨਿਸ਼ਾਨਾ ਹਮਲਾ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ, ਅਤੇ ਇਹ ਕਿ ਸੁਰੱਖਿਆ ਸਾਧਨ ਜੋ ਤੁਸੀਂ ਵਰਤਦੇ ਹੋ, ਸ਼ਾਇਦ ਇਹ ਜਾਣੇ ਬਿਨਾਂ (ਓਪਰੇਟਿੰਗ ਸਿਸਟਮਾਂ ਦੀਆਂ ਵੱਖ-ਵੱਖ ਬਿਲਟ-ਇਨ ਸੁਰੱਖਿਆ), ਲਈ ਕਾਫ਼ੀ ਹਨ। ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਹਾਡੇ ਅਤੇ ਤੁਹਾਡੇ ਗਾਹਕਾਂ ਲਈ ਪ੍ਰਦਾਨ ਕੀਤੀ ਗਈ ਸੇਵਾ ਦੀ ਗਿਰਾਵਟ ਨੂੰ ਘੱਟ ਕੀਤਾ ਗਿਆ ਹੈ।

ਇੱਥੇ ਇੰਟਰਨੈਟ ਸਰੋਤ ਹਨ ਜੋ ਸਾਜ਼-ਸਾਮਾਨ ਦੇ ਲੌਗਸ ਦੇ ਅਧਾਰ ਤੇ, ਅਸਲ ਸਮੇਂ ਵਿੱਚ ਸੁੰਦਰ ਹਮਲੇ ਦੇ ਨਕਸ਼ੇ ਬਣਾਉਂਦੇ ਹਨ।

ਇਹ ਇਸ ਲਈ ਹੈ ਤੁਸੀਂ ਉਹਨਾਂ ਲਈ ਲਿੰਕ ਲੱਭ ਸਕਦੇ ਹੋ।

ਮੇਰਾ ਮਨਪਸੰਦ карта ਚੈੱਕਪੁਆਇੰਟ ਤੋਂ.

DDOS/DOS ਦੇ ਵਿਰੁੱਧ ਸੁਰੱਖਿਆ ਆਮ ਤੌਰ 'ਤੇ ਲੇਅਰਡ ਹੁੰਦੀ ਹੈ। ਇਹ ਸਮਝਣ ਲਈ ਕਿ ਕਿਉਂ, ਤੁਹਾਨੂੰ ਇਹ ਸਮਝਣ ਦੀ ਲੋੜ ਹੈ ਕਿ ਕਿਸ ਕਿਸਮ ਦੇ DOS/DDOS ਹਮਲੇ ਮੌਜੂਦ ਹਨ (ਦੇਖੋ, ਉਦਾਹਰਨ ਲਈ, ਇੱਥੇ ਜ ਇੱਥੇ)

ਭਾਵ, ਸਾਡੇ ਕੋਲ ਤਿੰਨ ਤਰ੍ਹਾਂ ਦੇ ਹਮਲੇ ਹਨ:

• ਵੌਲਯੂਮੈਟ੍ਰਿਕ ਹਮਲੇ
• ਪ੍ਰੋਟੋਕੋਲ ਹਮਲੇ
• ਐਪਲੀਕੇਸ਼ਨ ਹਮਲੇ

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

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

ਉਦਾਹਰਨ:

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

ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਹਮਲੇ ਦੇ ਦੌਰਾਨ ਕੁਨੈਕਟੀਵਿਟੀ ਨੂੰ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਕੁਰਬਾਨ ਕਰਨਾ ਪਏਗਾ. ਪਰ

• ਇਹ ਸਿਰਫ ਹਮਲੇ ਦੀ ਮਿਆਦ ਲਈ ਹੈ। ਹਮਲੇ ਦੀ ਸਥਿਤੀ ਵਿੱਚ, ਤੁਸੀਂ ਹੱਥੀਂ ਜਾਂ ਆਟੋਮੈਟਿਕਲੀ BGP ਨੂੰ ਮੁੜ ਸੰਰਚਿਤ ਕਰ ਸਕਦੇ ਹੋ ਤਾਂ ਜੋ ਟਰੈਫਿਕ ਕੇਵਲ ਉਸ ਪ੍ਰਦਾਤਾ ਦੁਆਰਾ ਜਾਂਦਾ ਹੈ ਜੋ ਤੁਹਾਨੂੰ "ਛਤਰੀ" ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਹਮਲਾ ਖਤਮ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਤੁਸੀਂ ਰੂਟਿੰਗ ਨੂੰ ਇਸਦੀ ਪਿਛਲੀ ਸਥਿਤੀ ਵਿੱਚ ਵਾਪਸ ਕਰ ਸਕਦੇ ਹੋ
• ਇਹ ਸਾਰੇ ਆਵਾਜਾਈ ਨੂੰ ਤਬਦੀਲ ਕਰਨ ਲਈ ਜ਼ਰੂਰੀ ਨਹੀ ਹੈ. ਜੇ, ਉਦਾਹਰਨ ਲਈ, ਤੁਸੀਂ ਦੇਖਦੇ ਹੋ ਕਿ ਕੁਝ ਅਪਲਿੰਕਸ ਜਾਂ ਪੀਅਰਿੰਗਜ਼ ਦੁਆਰਾ ਕੋਈ ਹਮਲੇ ਨਹੀਂ ਹੁੰਦੇ ਹਨ (ਜਾਂ ਟ੍ਰੈਫਿਕ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਹੈ), ਤੁਸੀਂ ਇਹਨਾਂ BGP ਗੁਆਂਢੀਆਂ ਲਈ ਪ੍ਰਤੀਯੋਗੀ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਾਲੇ ਅਗੇਤਰਾਂ ਦਾ ਇਸ਼ਤਿਹਾਰ ਦੇਣਾ ਜਾਰੀ ਰੱਖ ਸਕਦੇ ਹੋ।

ਤੁਸੀਂ ਆਪਣੇ ਭਾਈਵਾਲਾਂ ਨੂੰ "ਪ੍ਰੋਟੋਕੋਲ ਹਮਲੇ" ਅਤੇ "ਐਪਲੀਕੇਸ਼ਨ ਹਮਲਿਆਂ" ਤੋਂ ਸੁਰੱਖਿਆ ਵੀ ਸੌਂਪ ਸਕਦੇ ਹੋ।
ਇੱਥੇ ਇੱਥੇ ਤੁਸੀਂ ਇੱਕ ਚੰਗਾ ਅਧਿਐਨ ਪੜ੍ਹ ਸਕਦੇ ਹੋ (ਅਨੁਵਾਦ). ਇਹ ਸੱਚ ਹੈ ਕਿ ਲੇਖ ਦੋ ਸਾਲ ਪੁਰਾਣਾ ਹੈ, ਪਰ ਇਹ ਤੁਹਾਨੂੰ DDOS ਹਮਲਿਆਂ ਤੋਂ ਆਪਣੇ ਆਪ ਨੂੰ ਕਿਵੇਂ ਬਚਾ ਸਕਦੇ ਹਨ ਇਸ ਬਾਰੇ ਪਹੁੰਚ ਬਾਰੇ ਇੱਕ ਵਿਚਾਰ ਦੇਵੇਗਾ।

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

ਇਸ ਲਈ, ਆਓ ਦੇਖੀਏ ਕਿ ਬਚਾਅ ਦੀਆਂ ਦੂਜੀਆਂ ਅਤੇ ਤੀਜੀਆਂ ਲਾਈਨਾਂ ਨੂੰ ਕਿਵੇਂ ਸੰਗਠਿਤ ਕਰਨਾ ਹੈ (ਪ੍ਰਦਾਤਾ ਤੋਂ ਸੁਰੱਖਿਆ ਦੇ ਜੋੜ ਵਜੋਂ).

ਇਸ ਲਈ, ਬਚਾਅ ਦੀ ਦੂਜੀ ਲਾਈਨ ਤੁਹਾਡੇ ਨੈਟਵਰਕ ਦੇ ਪ੍ਰਵੇਸ਼ ਦੁਆਰ 'ਤੇ ਫਿਲਟਰਿੰਗ ਅਤੇ ਟ੍ਰੈਫਿਕ ਲਿਮਿਟਰ (ਪੁਲੀਸਰ) ਹੈ।

ਮਿਸਾਲ 1

ਚਲੋ ਇਹ ਮੰਨ ਲਓ ਕਿ ਤੁਸੀਂ ਪ੍ਰਦਾਤਾਵਾਂ ਵਿੱਚੋਂ ਇੱਕ ਦੀ ਮਦਦ ਨਾਲ ਆਪਣੇ ਆਪ ਨੂੰ ਡੀਡੀਓਐਸ ਦੇ ਵਿਰੁੱਧ ਇੱਕ ਛਤਰੀ ਨਾਲ ਕਵਰ ਕੀਤਾ ਹੈ. ਚਲੋ ਇਹ ਮੰਨ ਲਓ ਕਿ ਇਹ ਪ੍ਰਦਾਤਾ ਆਪਣੇ ਨੈਟਵਰਕ ਦੇ ਕਿਨਾਰੇ 'ਤੇ ਟ੍ਰੈਫਿਕ ਅਤੇ ਫਿਲਟਰਾਂ ਨੂੰ ਫਿਲਟਰ ਕਰਨ ਲਈ ਆਰਬਰ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ.

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

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

ਮਿਸਾਲ 2

ਇੱਕ ਅਸਧਾਰਨ ਤੌਰ 'ਤੇ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ SYN ਪੈਕੇਟ ਨਾ ਸਿਰਫ਼ SYN ਹੜ੍ਹ ਦੇ ਹਮਲੇ ਦਾ ਨਤੀਜਾ ਹੋ ਸਕਦੇ ਹਨ। ਚਲੋ ਮੰਨ ਲਓ ਕਿ ਤੁਸੀਂ ਇੱਕ ਸੇਵਾ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹੋ ਜਿਸ ਵਿੱਚ ਤੁਸੀਂ ਇੱਕੋ ਸਮੇਂ ਲਗਭਗ 100 ਹਜ਼ਾਰ TCP ਕਨੈਕਸ਼ਨ (ਇੱਕ ਡੇਟਾ ਸੈਂਟਰ ਲਈ) ਰੱਖ ਸਕਦੇ ਹੋ।

ਮੰਨ ਲਓ ਕਿ ਤੁਹਾਡੇ ਮੁੱਖ ਪ੍ਰਦਾਤਾਵਾਂ ਵਿੱਚੋਂ ਇੱਕ ਦੇ ਨਾਲ ਇੱਕ ਛੋਟੀ ਮਿਆਦ ਦੀ ਸਮੱਸਿਆ ਦੇ ਨਤੀਜੇ ਵਜੋਂ, ਤੁਹਾਡੇ ਅੱਧੇ ਸੈਸ਼ਨਾਂ ਨੂੰ ਕਿੱਕ ਕੀਤਾ ਗਿਆ ਹੈ। ਜੇਕਰ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਡਿਜ਼ਾਇਨ ਕੀਤਾ ਗਿਆ ਹੈ ਕਿ, ਬਿਨਾਂ ਦੋ ਵਾਰ ਸੋਚੇ, ਇਹ ਤੁਰੰਤ (ਜਾਂ ਕੁਝ ਸਮੇਂ ਦੇ ਅੰਤਰਾਲ ਤੋਂ ਬਾਅਦ ਜੋ ਸਾਰੇ ਸੈਸ਼ਨਾਂ ਲਈ ਇੱਕੋ ਜਿਹਾ ਹੈ) ਕੁਨੈਕਸ਼ਨ ਨੂੰ ਮੁੜ ਸਥਾਪਿਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਘੱਟੋ-ਘੱਟ 50 ਹਜ਼ਾਰ SYN ਪੈਕੇਟ ਪ੍ਰਾਪਤ ਹੋਣਗੇ। ਨਾਲ ਹੀ.

ਜੇ, ਉਦਾਹਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਇਹਨਾਂ ਸੈਸ਼ਨਾਂ ਦੇ ਸਿਖਰ 'ਤੇ ssl/tls ਹੈਂਡਸ਼ੇਕ ਚਲਾਉਣਾ ਪੈਂਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਸਰਟੀਫਿਕੇਟਾਂ ਦਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਕਰਨਾ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਲੋਡ ਬੈਲੈਂਸਰ ਲਈ ਸਰੋਤਾਂ ਨੂੰ ਖਤਮ ਕਰਨ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਇਹ ਇੱਕ ਸਧਾਰਨ ਨਾਲੋਂ ਬਹੁਤ ਮਜ਼ਬੂਤ ​​"DDOS" ਹੋਵੇਗਾ। SYN ਹੜ੍ਹ। ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਸੰਤੁਲਨ ਰੱਖਣ ਵਾਲਿਆਂ ਨੂੰ ਅਜਿਹੀਆਂ ਘਟਨਾਵਾਂ ਨੂੰ ਸੰਭਾਲਣਾ ਚਾਹੀਦਾ ਹੈ, ਪਰ ... ਬਦਕਿਸਮਤੀ ਨਾਲ, ਸਾਨੂੰ ਅਜਿਹੀ ਸਮੱਸਿਆ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈ ਰਿਹਾ ਹੈ।

ਅਤੇ, ਬੇਸ਼ੱਕ, ਕਿਨਾਰੇ ਰਾਊਟਰ 'ਤੇ ਇੱਕ ਪੁਲਿਸਰ ਇਸ ਕੇਸ ਵਿੱਚ ਵੀ ਤੁਹਾਡੇ ਸਾਜ਼-ਸਾਮਾਨ ਨੂੰ ਬਚਾਏਗਾ.

DDOS/DOS ਦੇ ਵਿਰੁੱਧ ਸੁਰੱਖਿਆ ਦਾ ਤੀਜਾ ਪੱਧਰ ਤੁਹਾਡੀ ਫਾਇਰਵਾਲ ਸੈਟਿੰਗ ਹੈ।

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

ਟਿਪ

ਫਾਇਰਵਾਲ ਨੂੰ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਘੱਟ ਕੰਮ ਦੇਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ, ਬਚਾਅ ਦੀਆਂ ਪਹਿਲੀਆਂ ਦੋ ਲਾਈਨਾਂ 'ਤੇ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਫਿਲਟਰ ਕਰੋ। ਅਤੇ ਇਸੇ ਲਈ.

ਕੀ ਤੁਹਾਡੇ ਨਾਲ ਕਦੇ ਅਜਿਹਾ ਹੋਇਆ ਹੈ ਕਿ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ, ਜਾਂਚ ਕਰਨ ਲਈ ਟ੍ਰੈਫਿਕ ਪੈਦਾ ਕਰਦੇ ਸਮੇਂ, ਉਦਾਹਰਨ ਲਈ, ਤੁਹਾਡੇ ਸਰਵਰਾਂ ਦਾ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ DDOS ਹਮਲਿਆਂ ਲਈ ਕਿੰਨਾ ਰੋਧਕ ਹੈ, ਤੁਸੀਂ ਆਪਣੀ ਫਾਇਰਵਾਲ ਨੂੰ "ਮਾਰਿਆ", ਇਸਨੂੰ 100 ਪ੍ਰਤੀਸ਼ਤ ਤੱਕ ਲੋਡ ਕੀਤਾ, ਆਮ ਤੀਬਰਤਾ ਨਾਲ ਟ੍ਰੈਫਿਕ ? ਜੇ ਨਹੀਂ, ਤਾਂ ਸ਼ਾਇਦ ਇਹ ਸਿਰਫ਼ ਇਸ ਲਈ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕੀਤੀ ਹੈ?

ਆਮ ਤੌਰ 'ਤੇ, ਇੱਕ ਫਾਇਰਵਾਲ, ਜਿਵੇਂ ਕਿ ਮੈਂ ਕਿਹਾ, ਇੱਕ ਗੁੰਝਲਦਾਰ ਚੀਜ਼ ਹੈ, ਅਤੇ ਇਹ ਜਾਣੀਆਂ-ਪਛਾਣੀਆਂ ਕਮਜ਼ੋਰੀਆਂ ਅਤੇ ਟੈਸਟ ਕੀਤੇ ਹੱਲਾਂ ਦੇ ਨਾਲ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੀ ਹੈ, ਪਰ ਜੇ ਤੁਸੀਂ ਕੁਝ ਅਸਾਧਾਰਨ, ਸਿਰਫ਼ ਕੁਝ ਕੂੜਾ ਜਾਂ ਗਲਤ ਸਿਰਲੇਖਾਂ ਦੇ ਨਾਲ ਪੈਕੇਟ ਭੇਜਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਕੁਝ ਦੇ ਨਾਲ ਹੋ, ਨਾ ਕਿ ਨਾਲ. ਇੰਨੀ ਛੋਟੀ ਸੰਭਾਵਨਾ (ਮੇਰੇ ਤਜਰਬੇ ਦੇ ਅਧਾਰ ਤੇ), ਤੁਸੀਂ ਚੋਟੀ ਦੇ ਅੰਤ ਵਾਲੇ ਉਪਕਰਣਾਂ ਨੂੰ ਵੀ ਬੇਚੈਨ ਕਰ ਸਕਦੇ ਹੋ. ਇਸ ਲਈ, ਪੜਾਅ 2 'ਤੇ, ਨਿਯਮਤ ACLs (L3/L4 ਪੱਧਰ 'ਤੇ) ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਸਿਰਫ ਤੁਹਾਡੇ ਨੈਟਵਰਕ ਵਿੱਚ ਟ੍ਰੈਫਿਕ ਦੀ ਆਗਿਆ ਦਿਓ ਜੋ ਉੱਥੇ ਦਾਖਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਫਾਇਰਵਾਲ 'ਤੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਫਿਲਟਰ ਕਰਨਾ

ਆਉ ਫਾਇਰਵਾਲ ਬਾਰੇ ਗੱਲਬਾਤ ਜਾਰੀ ਰੱਖੀਏ। ਤੁਹਾਨੂੰ ਇਹ ਸਮਝਣ ਦੀ ਲੋੜ ਹੈ ਕਿ DOS/DDOS ਹਮਲੇ ਸਿਰਫ਼ ਇੱਕ ਕਿਸਮ ਦੇ ਸਾਈਬਰ ਹਮਲੇ ਹਨ।

DOS/DDOS ਸੁਰੱਖਿਆ ਤੋਂ ਇਲਾਵਾ, ਸਾਡੇ ਕੋਲ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਹੇਠ ਲਿਖੀ ਸੂਚੀ ਵਰਗਾ ਕੁਝ ਵੀ ਹੋ ਸਕਦਾ ਹੈ:

• ਐਪਲੀਕੇਸ਼ਨ ਫਾਇਰਵਾਲਿੰਗ
• ਖਤਰੇ ਦੀ ਰੋਕਥਾਮ (ਐਂਟੀਵਾਇਰਸ, ਐਂਟੀ-ਸਪਾਈਵੇਅਰ, ਅਤੇ ਕਮਜ਼ੋਰੀ)
• URL ਫਿਲਟਰਿੰਗ
• ਡਾਟਾ ਫਿਲਟਰਿੰਗ (ਸਮੱਗਰੀ ਫਿਲਟਰਿੰਗ)
• ਫਾਈਲ ਬਲਾਕਿੰਗ (ਫਾਇਲ ਕਿਸਮਾਂ ਨੂੰ ਬਲੌਕ ਕਰਨਾ)

ਇਹ ਤੁਹਾਡੇ ਉੱਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਇਸ ਸੂਚੀ ਵਿੱਚੋਂ ਕੀ ਚਾਹੀਦਾ ਹੈ।

ਨੂੰ ਜਾਰੀ ਰੱਖਿਆ ਜਾਵੇਗਾ

ਸਰੋਤ: www.habr.com