ਬਚਾਅ ਲਈ DDoS: ਅਸੀਂ ਤਣਾਅ ਅਤੇ ਲੋਡ ਟੈਸਟ ਕਿਵੇਂ ਕਰਦੇ ਹਾਂ

Variti ਬੋਟਸ ਅਤੇ DDoS ਹਮਲਿਆਂ ਤੋਂ ਸੁਰੱਖਿਆ ਵਿਕਸਿਤ ਕਰਦੀ ਹੈ, ਅਤੇ ਤਣਾਅ ਅਤੇ ਲੋਡ ਟੈਸਟਿੰਗ ਵੀ ਕਰਦੀ ਹੈ। ਹਾਈਲੋਡ++ 2018 ਕਾਨਫਰੰਸ ਵਿੱਚ ਅਸੀਂ ਵੱਖ-ਵੱਖ ਕਿਸਮਾਂ ਦੇ ਹਮਲਿਆਂ ਤੋਂ ਸਰੋਤਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਨ ਬਾਰੇ ਗੱਲ ਕੀਤੀ। ਸੰਖੇਪ ਵਿੱਚ: ਸਿਸਟਮ ਦੇ ਹਿੱਸਿਆਂ ਨੂੰ ਅਲੱਗ ਕਰੋ, ਕਲਾਉਡ ਸੇਵਾਵਾਂ ਅਤੇ ਸੀਡੀਐਨ ਦੀ ਵਰਤੋਂ ਕਰੋ, ਅਤੇ ਨਿਯਮਿਤ ਤੌਰ 'ਤੇ ਅਪਡੇਟ ਕਰੋ। ਪਰ ਤੁਸੀਂ ਅਜੇ ਵੀ ਵਿਸ਼ੇਸ਼ ਕੰਪਨੀਆਂ ਤੋਂ ਬਿਨਾਂ ਸੁਰੱਖਿਆ ਨੂੰ ਸੰਭਾਲਣ ਦੇ ਯੋਗ ਨਹੀਂ ਹੋਵੋਗੇ :)

ਪਾਠ ਨੂੰ ਪੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ, ਤੁਸੀਂ ਛੋਟੇ ਐਬਸਟਰੈਕਟ ਪੜ੍ਹ ਸਕਦੇ ਹੋ ਕਾਨਫਰੰਸ ਦੀ ਵੈੱਬਸਾਈਟ 'ਤੇ.
ਅਤੇ ਜੇਕਰ ਤੁਸੀਂ ਪੜ੍ਹਨਾ ਪਸੰਦ ਨਹੀਂ ਕਰਦੇ ਹੋ ਜਾਂ ਸਿਰਫ਼ ਵੀਡੀਓ ਦੇਖਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਸਾਡੀ ਰਿਪੋਰਟ ਦੀ ਰਿਕਾਰਡਿੰਗ ਹੇਠਾਂ ਵਿਗਾੜਨ ਵਾਲੀ ਹੈ।

ਰਿਪੋਰਟ ਦੀ ਵੀਡੀਓ ਰਿਕਾਰਡਿੰਗ

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

ਅਸੀਂ ਕਿਵੇਂ ਕੰਮ ਕਰ ਰਹੇ ਹਾਂ

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

ਆਸਣ ਕਰਦਾ ਹੈ

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

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

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

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

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

L7 ਹਮਲਿਆਂ ਦੀਆਂ ਵਿਲੱਖਣ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ

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

HTTP ਹੜ੍ਹ

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

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

ਕੀ ਖੋਜ ਕਰਨਾ ਹੈ

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

ਕਿੱਥੇ ਦੇਖਣਾ ਹੈ

ਜਦੋਂ ਅਸੀਂ ਟੈਸਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕਿਸੇ ਸਰੋਤ ਨੂੰ ਸਕੈਨ ਕਰਦੇ ਹਾਂ, ਅਸੀਂ ਪਹਿਲਾਂ, ਬੇਸ਼ਕ, ਸਾਈਟ 'ਤੇ ਹੀ ਦੇਖਦੇ ਹਾਂ। ਅਸੀਂ ਹਰ ਕਿਸਮ ਦੇ ਇਨਪੁਟ ਖੇਤਰਾਂ, ਭਾਰੀ ਫਾਈਲਾਂ ਦੀ ਭਾਲ ਕਰ ਰਹੇ ਹਾਂ - ਆਮ ਤੌਰ 'ਤੇ, ਉਹ ਸਭ ਕੁਝ ਜੋ ਸਰੋਤ ਲਈ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਇਸਦੇ ਕੰਮ ਨੂੰ ਹੌਲੀ ਕਰ ਸਕਦਾ ਹੈ। ਗੂਗਲ ਕਰੋਮ ਅਤੇ ਫਾਇਰਫਾਕਸ ਵਿੱਚ ਬੇਨਲ ਡਿਵੈਲਪਮੈਂਟ ਟੂਲ ਇੱਥੇ ਮਦਦ ਕਰਦੇ ਹਨ, ਪੇਜ ਦੇ ਜਵਾਬ ਦਾ ਸਮਾਂ ਦਿਖਾਉਂਦੇ ਹੋਏ।
ਅਸੀਂ ਸਬਡੋਮੇਨਾਂ ਨੂੰ ਵੀ ਸਕੈਨ ਕਰਦੇ ਹਾਂ। ਉਦਾਹਰਨ ਲਈ, ਇੱਥੇ ਇੱਕ ਖਾਸ ਔਨਲਾਈਨ ਸਟੋਰ ਹੈ, abc.com, ਅਤੇ ਇਸਦਾ ਇੱਕ ਸਬਡੋਮੇਨ admin.abc.com ਹੈ। ਜ਼ਿਆਦਾਤਰ ਸੰਭਾਵਨਾ ਹੈ, ਇਹ ਪ੍ਰਮਾਣਿਕਤਾ ਵਾਲਾ ਇੱਕ ਐਡਮਿਨ ਪੈਨਲ ਹੈ, ਪਰ ਜੇ ਤੁਸੀਂ ਇਸ 'ਤੇ ਲੋਡ ਪਾਉਂਦੇ ਹੋ, ਤਾਂ ਇਹ ਮੁੱਖ ਸਰੋਤ ਲਈ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ।
ਸਾਈਟ ਦਾ ਇੱਕ ਸਬਡੋਮੇਨ api.abc.com ਹੋ ਸਕਦਾ ਹੈ। ਜ਼ਿਆਦਾਤਰ ਸੰਭਾਵਨਾ ਹੈ, ਇਹ ਮੋਬਾਈਲ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਇੱਕ ਸਰੋਤ ਹੈ. ਐਪਲੀਕੇਸ਼ਨ ਐਪ ਸਟੋਰ ਜਾਂ Google Play ਵਿੱਚ ਲੱਭੀ ਜਾ ਸਕਦੀ ਹੈ, ਇੱਕ ਵਿਸ਼ੇਸ਼ ਐਕਸੈਸ ਪੁਆਇੰਟ ਸਥਾਪਤ ਕਰੋ, API ਨੂੰ ਡਿਸਸੈਕਟ ਕਰੋ ਅਤੇ ਟੈਸਟ ਖਾਤੇ ਰਜਿਸਟਰ ਕਰੋ। ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਲੋਕ ਅਕਸਰ ਸੋਚਦੇ ਹਨ ਕਿ ਅਧਿਕਾਰ ਦੁਆਰਾ ਸੁਰੱਖਿਅਤ ਕੀਤੀ ਗਈ ਕੋਈ ਵੀ ਚੀਜ਼ ਸੇਵਾ ਦੇ ਹਮਲਿਆਂ ਤੋਂ ਇਨਕਾਰ ਕਰਨ ਤੋਂ ਮੁਕਤ ਹੈ। ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ, ਅਧਿਕਾਰ ਸਭ ਤੋਂ ਵਧੀਆ ਕੈਪਟਚਾ ਹੈ, ਪਰ ਅਜਿਹਾ ਨਹੀਂ ਹੈ। 10-20 ਟੈਸਟ ਖਾਤਿਆਂ ਨੂੰ ਬਣਾਉਣਾ ਆਸਾਨ ਹੈ, ਪਰ ਉਹਨਾਂ ਨੂੰ ਬਣਾ ਕੇ, ਅਸੀਂ ਗੁੰਝਲਦਾਰ ਅਤੇ ਨਿਰਵਿਘਨ ਕਾਰਜਸ਼ੀਲਤਾ ਤੱਕ ਪਹੁੰਚ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ।
ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ, ਅਸੀਂ ਇਤਿਹਾਸ ਨੂੰ ਦੇਖਦੇ ਹਾਂ, robots.txt ਅਤੇ WebArchive, ViewDNS 'ਤੇ, ਅਤੇ ਸਰੋਤ ਦੇ ਪੁਰਾਣੇ ਸੰਸਕਰਣਾਂ ਦੀ ਖੋਜ ਕਰਦੇ ਹਾਂ। ਕਈ ਵਾਰ ਅਜਿਹਾ ਹੁੰਦਾ ਹੈ ਕਿ ਡਿਵੈਲਪਰਾਂ ਨੇ mail2.yandex.net ਨੂੰ ਰੋਲਆਊਟ ਕਰ ਦਿੱਤਾ ਹੈ, ਪਰ ਪੁਰਾਣਾ ਸੰਸਕਰਣ, mail.yandex.net, ਰਹਿੰਦਾ ਹੈ। ਇਹ mail.yandex.net ਹੁਣ ਸਮਰਥਿਤ ਨਹੀਂ ਹੈ, ਵਿਕਾਸ ਸਰੋਤ ਇਸ ਨੂੰ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕੀਤੇ ਗਏ ਹਨ, ਪਰ ਇਹ ਡੇਟਾਬੇਸ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਜਾਰੀ ਰੱਖਦਾ ਹੈ। ਇਸ ਅਨੁਸਾਰ, ਪੁਰਾਣੇ ਸੰਸਕਰਣ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਤੁਸੀਂ ਬੈਕਐਂਡ ਦੇ ਸਰੋਤਾਂ ਅਤੇ ਲੇਆਉਟ ਦੇ ਪਿੱਛੇ ਮੌਜੂਦ ਹਰ ਚੀਜ਼ ਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਵਰਤ ਸਕਦੇ ਹੋ. ਬੇਸ਼ੱਕ, ਇਹ ਹਮੇਸ਼ਾ ਨਹੀਂ ਹੁੰਦਾ ਹੈ, ਪਰ ਅਸੀਂ ਅਜੇ ਵੀ ਅਕਸਰ ਇਸਦਾ ਸਾਹਮਣਾ ਕਰਦੇ ਹਾਂ.
ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ, ਅਸੀਂ ਸਾਰੇ ਬੇਨਤੀ ਮਾਪਦੰਡਾਂ ਅਤੇ ਕੂਕੀ ਢਾਂਚੇ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਦੇ ਹਾਂ। ਤੁਸੀਂ, ਕਹਿ ਸਕਦੇ ਹੋ, ਇੱਕ ਕੂਕੀ ਦੇ ਅੰਦਰ ਇੱਕ JSON ਐਰੇ ਵਿੱਚ ਕੁਝ ਮੁੱਲ ਡੰਪ ਕਰ ਸਕਦੇ ਹੋ, ਬਹੁਤ ਸਾਰੇ ਆਲ੍ਹਣੇ ਬਣਾ ਸਕਦੇ ਹੋ ਅਤੇ ਸਰੋਤ ਨੂੰ ਗੈਰ-ਵਾਜਬ ਲੰਬੇ ਸਮੇਂ ਲਈ ਕੰਮ ਕਰ ਸਕਦੇ ਹੋ।

ਖੋਜ ਲੋਡ

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

ਜੇ ਕੋਈ ਖੋਜ ਨਹੀਂ ਹੈ?

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

ਰੈਸਟ ਏਪੀਆਈ

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

ਭਾਰੀ ਸਮੱਗਰੀ ਲੋਡ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ

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

ਸਰਵਰ ਸਥਾਪਤ ਕਰਨ ਬਾਰੇ ਨਾ ਭੁੱਲੋ। ਤੁਸੀਂ ਅਕਸਰ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਇੱਕ ਵਿਅਕਤੀ ਨੇ ਇੱਕ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਖਰੀਦੀ ਹੈ, ਉੱਥੇ ਅਪਾਚੇ ਸਥਾਪਤ ਕੀਤੀ ਹੈ, ਹਰ ਚੀਜ਼ ਨੂੰ ਮੂਲ ਰੂਪ ਵਿੱਚ ਕੌਂਫਿਗਰ ਕੀਤਾ ਹੈ, ਇੱਕ PHP ਐਪਲੀਕੇਸ਼ਨ ਸਥਾਪਤ ਕੀਤੀ ਹੈ, ਅਤੇ ਹੇਠਾਂ ਤੁਸੀਂ ਨਤੀਜਾ ਦੇਖ ਸਕਦੇ ਹੋ।

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

ਵੇਵ ਆਧਾਰਿਤ

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

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

ਇਕੱਲੇ HTTP ਨਹੀਂ

L7 'ਤੇ HTTP ਤੋਂ ਇਲਾਵਾ, ਅਸੀਂ ਹੋਰ ਪ੍ਰੋਟੋਕੋਲ ਦਾ ਸ਼ੋਸ਼ਣ ਕਰਨਾ ਪਸੰਦ ਕਰਦੇ ਹਾਂ। ਇੱਕ ਨਿਯਮ ਦੇ ਤੌਰ ਤੇ, ਇੱਕ ਨਿਯਮਤ ਵੈਬਸਾਈਟ, ਖਾਸ ਤੌਰ 'ਤੇ ਇੱਕ ਨਿਯਮਤ ਹੋਸਟਿੰਗ, ਵਿੱਚ ਮੇਲ ਪ੍ਰੋਟੋਕੋਲ ਅਤੇ MySQL ਸਟਿੱਕਿੰਗ ਹੁੰਦੇ ਹਨ। ਮੇਲ ਪ੍ਰੋਟੋਕੋਲ ਡੇਟਾਬੇਸ ਨਾਲੋਂ ਘੱਟ ਲੋਡ ਦੇ ਅਧੀਨ ਹਨ, ਪਰ ਉਹਨਾਂ ਨੂੰ ਕਾਫ਼ੀ ਕੁਸ਼ਲਤਾ ਨਾਲ ਲੋਡ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ ਸਰਵਰ 'ਤੇ ਇੱਕ ਓਵਰਲੋਡ CPU ਨਾਲ ਖਤਮ ਹੋ ਸਕਦਾ ਹੈ।
ਸਾਨੂੰ 2016 SSH ਕਮਜ਼ੋਰੀ ਦੇ ਨਾਲ ਅਸਲ ਵਿੱਚ ਸਫਲਤਾ ਮਿਲੀ ਹੈ। ਹੁਣ ਇਹ ਕਮਜ਼ੋਰੀ ਲਗਭਗ ਹਰ ਕਿਸੇ ਲਈ ਫਿਕਸ ਕੀਤੀ ਗਈ ਹੈ, ਪਰ ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਲੋਡ ਨੂੰ SSH ਨੂੰ ਜਮ੍ਹਾਂ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਸਕਦਾ ਹੈ। ਇੱਥੇ ਅਧਿਕਾਰਾਂ ਦਾ ਇੱਕ ਬਹੁਤ ਵੱਡਾ ਭਾਰ ਹੈ, SSH ਸਰਵਰ 'ਤੇ ਲਗਭਗ ਪੂਰੇ CPU ਨੂੰ ਖਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਵੈਬਸਾਈਟ ਪ੍ਰਤੀ ਸਕਿੰਟ ਇੱਕ ਜਾਂ ਦੋ ਬੇਨਤੀਆਂ ਤੋਂ ਡਿੱਗ ਜਾਂਦੀ ਹੈ। ਇਸ ਅਨੁਸਾਰ, ਲੌਗਸ ਦੇ ਅਧਾਰ ਤੇ ਇਹਨਾਂ ਇੱਕ ਜਾਂ ਦੋ ਬੇਨਤੀਆਂ ਨੂੰ ਇੱਕ ਜਾਇਜ਼ ਲੋਡ ਤੋਂ ਵੱਖ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਬਹੁਤ ਸਾਰੇ ਕਨੈਕਸ਼ਨ ਜੋ ਅਸੀਂ ਸਰਵਰਾਂ ਵਿੱਚ ਖੋਲ੍ਹਦੇ ਹਾਂ ਉਹ ਵੀ ਢੁਕਵੇਂ ਰਹਿੰਦੇ ਹਨ। ਪਹਿਲਾਂ, ਅਪਾਚੇ ਇਸ ਲਈ ਦੋਸ਼ੀ ਸੀ, ਹੁਣ nginx ਅਸਲ ਵਿੱਚ ਇਸ ਲਈ ਦੋਸ਼ੀ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਅਕਸਰ ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ ਸੰਰਚਿਤ ਹੁੰਦਾ ਹੈ। ਕੁਨੈਕਸ਼ਨਾਂ ਦੀ ਗਿਣਤੀ ਜੋ nginx ਖੁੱਲੇ ਰੱਖ ਸਕਦੀ ਹੈ ਸੀਮਤ ਹੈ, ਇਸਲਈ ਅਸੀਂ ਕੁਨੈਕਸ਼ਨਾਂ ਦੀ ਇਸ ਸੰਖਿਆ ਨੂੰ ਖੋਲ੍ਹਦੇ ਹਾਂ, nginx ਹੁਣ ਕੋਈ ਨਵਾਂ ਕਨੈਕਸ਼ਨ ਸਵੀਕਾਰ ਨਹੀਂ ਕਰਦਾ ਹੈ, ਅਤੇ ਨਤੀਜੇ ਵਜੋਂ ਸਾਈਟ ਕੰਮ ਨਹੀਂ ਕਰਦੀ ਹੈ।
ਸਾਡੇ ਟੈਸਟ ਕਲੱਸਟਰ ਕੋਲ SSL ਹੈਂਡਸ਼ੇਕ 'ਤੇ ਹਮਲਾ ਕਰਨ ਲਈ ਕਾਫ਼ੀ CPU ਹੈ। ਸਿਧਾਂਤਕ ਤੌਰ 'ਤੇ, ਜਿਵੇਂ ਕਿ ਅਭਿਆਸ ਦਿਖਾਉਂਦਾ ਹੈ, ਬੋਟਨੈੱਟ ਕਈ ਵਾਰ ਅਜਿਹਾ ਕਰਨਾ ਵੀ ਪਸੰਦ ਕਰਦੇ ਹਨ. ਇੱਕ ਪਾਸੇ, ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਤੁਸੀਂ SSL ਤੋਂ ਬਿਨਾਂ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਕਿਉਂਕਿ Google ਨਤੀਜੇ, ਦਰਜਾਬੰਦੀ, ਸੁਰੱਖਿਆ. ਦੂਜੇ ਪਾਸੇ, SSL ਵਿੱਚ ਬਦਕਿਸਮਤੀ ਨਾਲ ਇੱਕ CPU ਮੁੱਦਾ ਹੈ।

L3&4

ਜਦੋਂ ਅਸੀਂ L3 ਅਤੇ 4 ਪੱਧਰਾਂ 'ਤੇ ਹਮਲੇ ਬਾਰੇ ਗੱਲ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਲਿੰਕ ਪੱਧਰ 'ਤੇ ਹਮਲੇ ਬਾਰੇ ਗੱਲ ਕਰਦੇ ਹਾਂ। ਅਜਿਹਾ ਲੋਡ ਲਗਭਗ ਹਮੇਸ਼ਾ ਇੱਕ ਜਾਇਜ਼ ਤੋਂ ਵੱਖਰਾ ਹੁੰਦਾ ਹੈ, ਜਦੋਂ ਤੱਕ ਇਹ SYN- ਹੜ੍ਹ ਦਾ ਹਮਲਾ ਨਾ ਹੋਵੇ। ਸੁਰੱਖਿਆ ਸਾਧਨਾਂ ਲਈ SYN- ਹੜ੍ਹ ਹਮਲਿਆਂ ਦੀ ਸਮੱਸਿਆ ਉਹਨਾਂ ਦੀ ਵੱਡੀ ਮਾਤਰਾ ਹੈ। ਅਧਿਕਤਮ L3 ਅਤੇ 4 ਮੁੱਲ 1,5-2 Tbit/s ਸੀ। ਓਰੇਕਲ ਅਤੇ ਗੂਗਲ ਸਮੇਤ ਵੱਡੀਆਂ ਕੰਪਨੀਆਂ ਲਈ ਵੀ ਇਸ ਕਿਸਮ ਦੀ ਆਵਾਜਾਈ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਨਾ ਬਹੁਤ ਮੁਸ਼ਕਲ ਹੈ।
SYN ਅਤੇ SYN-ACK ਪੈਕੇਟ ਹਨ ਜੋ ਕੁਨੈਕਸ਼ਨ ਸਥਾਪਤ ਕਰਨ ਵੇਲੇ ਵਰਤੇ ਜਾਂਦੇ ਹਨ। ਇਸ ਲਈ, SYN- ਹੜ੍ਹ ਨੂੰ ਇੱਕ ਜਾਇਜ਼ ਲੋਡ ਤੋਂ ਵੱਖ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੈ: ਇਹ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹੈ ਕਿ ਕੀ ਇਹ ਇੱਕ SYN ਹੈ ਜੋ ਇੱਕ ਕੁਨੈਕਸ਼ਨ ਸਥਾਪਤ ਕਰਨ ਲਈ ਆਇਆ ਹੈ, ਜਾਂ ਇੱਕ ਹੜ੍ਹ ਦਾ ਹਿੱਸਾ ਹੈ।

UDP-ਹੜ੍ਹ

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

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

ਮੁਸ਼ਕਲ SYN- ਹੜ੍ਹ

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

ਸੰਦ

L7 ਵਰਕਲੋਡ ਲਈ ਸਾਡੇ ਦੁਆਰਾ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਮੁੱਖ ਸਾਧਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਯਾਂਡੇਕਸ-ਟੈਂਕ ਹੈ। ਖਾਸ ਤੌਰ 'ਤੇ, ਇੱਕ ਫੈਂਟਮ ਨੂੰ ਬੰਦੂਕ ਵਜੋਂ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਨਾਲ ਹੀ ਕਾਰਤੂਸ ਬਣਾਉਣ ਅਤੇ ਨਤੀਜਿਆਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਲਈ ਕਈ ਸਕ੍ਰਿਪਟਾਂ ਹਨ।
Tcpdump ਦੀ ਵਰਤੋਂ ਨੈੱਟਵਰਕ ਟ੍ਰੈਫਿਕ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ Nmap ਦੀ ਵਰਤੋਂ ਸਰਵਰ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। L3 ਅਤੇ 4 ਪੱਧਰ 'ਤੇ ਲੋਡ ਬਣਾਉਣ ਲਈ, OpenSSL ਅਤੇ DPDK ਲਾਇਬ੍ਰੇਰੀ ਦੇ ਨਾਲ ਸਾਡੇ ਆਪਣੇ ਜਾਦੂ ਦੀ ਇੱਕ ਛੋਟੀ ਜਿਹੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। DPDK Intel ਦੀ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਲੀਨਕਸ ਸਟੈਕ ਨੂੰ ਬਾਈਪਾਸ ਕਰਕੇ ਨੈੱਟਵਰਕ ਇੰਟਰਫੇਸ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਕੁਸ਼ਲਤਾ ਵਧਦੀ ਹੈ। ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ, ਅਸੀਂ ਨਾ ਸਿਰਫ਼ L3 ਅਤੇ 4 ਪੱਧਰ 'ਤੇ, ਸਗੋਂ L7 ਪੱਧਰ 'ਤੇ ਵੀ DPDK ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ, ਕਿਉਂਕਿ ਇਹ ਸਾਨੂੰ ਇੱਕ ਮਸ਼ੀਨ ਤੋਂ ਪ੍ਰਤੀ ਸਕਿੰਟ ਕਈ ਮਿਲੀਅਨ ਬੇਨਤੀਆਂ ਦੀ ਸੀਮਾ ਦੇ ਅੰਦਰ, ਇੱਕ ਬਹੁਤ ਉੱਚ ਲੋਡ ਪ੍ਰਵਾਹ ਬਣਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।
ਅਸੀਂ ਕੁਝ ਟ੍ਰੈਫਿਕ ਜਨਰੇਟਰਾਂ ਅਤੇ ਵਿਸ਼ੇਸ਼ ਸਾਧਨਾਂ ਦੀ ਵੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ ਜੋ ਅਸੀਂ ਖਾਸ ਟੈਸਟਾਂ ਲਈ ਲਿਖਦੇ ਹਾਂ। ਜੇਕਰ ਅਸੀਂ SSH ਅਧੀਨ ਕਮਜ਼ੋਰੀ ਨੂੰ ਯਾਦ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਉਪਰੋਕਤ ਸੈੱਟ ਦਾ ਸ਼ੋਸ਼ਣ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਜੇ ਅਸੀਂ ਮੇਲ ਪ੍ਰੋਟੋਕੋਲ 'ਤੇ ਹਮਲਾ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਮੇਲ ਉਪਯੋਗਤਾਵਾਂ ਲੈਂਦੇ ਹਾਂ ਜਾਂ ਉਹਨਾਂ 'ਤੇ ਸਕ੍ਰਿਪਟਾਂ ਲਿਖਦੇ ਹਾਂ।

ਸਿੱਟਾ

ਸਿੱਟੇ ਵਜੋਂ ਮੈਂ ਇਹ ਕਹਿਣਾ ਚਾਹਾਂਗਾ:

• ਕਲਾਸਿਕ ਲੋਡ ਟੈਸਟਿੰਗ ਤੋਂ ਇਲਾਵਾ, ਤਣਾਅ ਦੀ ਜਾਂਚ ਕਰਵਾਉਣੀ ਜ਼ਰੂਰੀ ਹੈ. ਸਾਡੇ ਕੋਲ ਇੱਕ ਅਸਲ ਉਦਾਹਰਣ ਹੈ ਜਿੱਥੇ ਇੱਕ ਸਾਥੀ ਦੇ ਉਪ-ਠੇਕੇਦਾਰ ਨੇ ਸਿਰਫ ਲੋਡ ਟੈਸਟਿੰਗ ਕੀਤੀ ਹੈ। ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਸਰੋਤ ਆਮ ਲੋਡ ਦਾ ਸਾਮ੍ਹਣਾ ਕਰ ਸਕਦਾ ਹੈ. ਪਰ ਫਿਰ ਇੱਕ ਅਸਧਾਰਨ ਲੋਡ ਪ੍ਰਗਟ ਹੋਇਆ, ਸਾਈਟ ਵਿਜ਼ਟਰਾਂ ਨੇ ਸਰੋਤ ਨੂੰ ਥੋੜਾ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਵਰਤਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ, ਅਤੇ ਨਤੀਜੇ ਵਜੋਂ ਉਪ-ਠੇਕੇਦਾਰ ਹੇਠਾਂ ਲੇਟ ਗਿਆ। ਇਸ ਤਰ੍ਹਾਂ, ਕਮਜ਼ੋਰੀਆਂ ਦੀ ਭਾਲ ਕਰਨਾ ਮਹੱਤਵਪੂਰਣ ਹੈ ਭਾਵੇਂ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ DDoS ਹਮਲਿਆਂ ਤੋਂ ਸੁਰੱਖਿਅਤ ਹੋ।
• ਸਿਸਟਮ ਦੇ ਕੁਝ ਹਿੱਸਿਆਂ ਨੂੰ ਦੂਜਿਆਂ ਤੋਂ ਅਲੱਗ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ। ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਖੋਜ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਇਸਨੂੰ ਵੱਖਰੀਆਂ ਮਸ਼ੀਨਾਂ ਵਿੱਚ ਭੇਜਣ ਦੀ ਲੋੜ ਹੈ, ਯਾਨੀ ਡੌਕਰ ਤੱਕ ਵੀ ਨਹੀਂ। ਕਿਉਂਕਿ ਜੇਕਰ ਖੋਜ ਜਾਂ ਪ੍ਰਮਾਣਿਕਤਾ ਅਸਫਲ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਘੱਟੋ ਘੱਟ ਕੁਝ ਕੰਮ ਕਰਨਾ ਜਾਰੀ ਰੱਖੇਗਾ. ਇੱਕ ਔਨਲਾਈਨ ਸਟੋਰ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਉਪਭੋਗਤਾ ਕੈਟਾਲਾਗ ਵਿੱਚ ਉਤਪਾਦਾਂ ਨੂੰ ਲੱਭਣਾ ਜਾਰੀ ਰੱਖਣਗੇ, ਐਗਰੀਗੇਟਰ ਤੋਂ ਜਾਓ, ਖਰੀਦੋ ਜੇ ਉਹ ਪਹਿਲਾਂ ਹੀ ਅਧਿਕਾਰਤ ਹਨ, ਜਾਂ OAuth2 ਦੁਆਰਾ ਅਧਿਕਾਰਤ ਹਨ।
• ਹਰ ਕਿਸਮ ਦੀਆਂ ਕਲਾਉਡ ਸੇਵਾਵਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਨਾ ਕਰੋ।
• CDN ਦੀ ਵਰਤੋਂ ਨਾ ਸਿਰਫ਼ ਨੈੱਟਵਰਕ ਦੇਰੀ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣ ਲਈ ਕਰੋ, ਸਗੋਂ ਚੈਨਲ ਥਕਾਵਟ 'ਤੇ ਹਮਲਿਆਂ ਤੋਂ ਸੁਰੱਖਿਆ ਦੇ ਸਾਧਨ ਵਜੋਂ ਅਤੇ ਸਿਰਫ਼ ਸਥਿਰ ਟ੍ਰੈਫਿਕ ਵਿੱਚ ਹੜ੍ਹ ਆਉਣ ਦੇ ਰੂਪ ਵਿੱਚ ਵੀ ਕਰੋ।
• ਵਿਸ਼ੇਸ਼ ਸੁਰੱਖਿਆ ਸੇਵਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ। ਤੁਸੀਂ ਆਪਣੇ ਆਪ ਨੂੰ ਚੈਨਲ ਪੱਧਰ 'ਤੇ L3 ਅਤੇ 4 ਹਮਲਿਆਂ ਤੋਂ ਬਚਾ ਨਹੀਂ ਸਕਦੇ ਹੋ, ਕਿਉਂਕਿ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਲੋੜੀਂਦਾ ਚੈਨਲ ਨਹੀਂ ਹੈ। ਤੁਸੀਂ L7 ਹਮਲਿਆਂ ਦਾ ਮੁਕਾਬਲਾ ਕਰਨ ਦੀ ਵੀ ਸੰਭਾਵਨਾ ਨਹੀਂ ਰੱਖਦੇ, ਕਿਉਂਕਿ ਇਹ ਬਹੁਤ ਵੱਡੇ ਹੋ ਸਕਦੇ ਹਨ। ਨਾਲ ਹੀ, ਛੋਟੇ ਹਮਲਿਆਂ ਦੀ ਖੋਜ ਅਜੇ ਵੀ ਵਿਸ਼ੇਸ਼ ਸੇਵਾਵਾਂ, ਵਿਸ਼ੇਸ਼ ਐਲਗੋਰਿਦਮ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ.
• ਨਿਯਮਿਤ ਤੌਰ 'ਤੇ ਅਪਡੇਟ ਕਰੋ। ਇਹ ਸਿਰਫ਼ ਕਰਨਲ 'ਤੇ ਹੀ ਨਹੀਂ, ਸਗੋਂ SSH ਡੈਮਨ 'ਤੇ ਵੀ ਲਾਗੂ ਹੁੰਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ ਜੇ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਬਾਹਰੋਂ ਖੁੱਲ੍ਹਾ ਰੱਖਿਆ ਹੈ। ਸਿਧਾਂਤ ਵਿੱਚ, ਹਰ ਚੀਜ਼ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਕਿਉਂਕਿ ਤੁਸੀਂ ਆਪਣੇ ਆਪ ਕੁਝ ਕਮਜ਼ੋਰੀਆਂ ਨੂੰ ਟਰੈਕ ਕਰਨ ਦੇ ਯੋਗ ਨਹੀਂ ਹੋ ਸਕਦੇ ਹੋ।

ਸਰੋਤ: www.habr.com