ਖਾਤਾ ਲਾਕਆਉਟ ਬਨਾਮ ਪਤਾ ਬੈਨ: OpenVPN ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਗਿਣਤੀ ਕਰਦਾ ਹੈ

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

ਉਸ VPN ਲਈ ਜੋ ਪ੍ਰਮਾਣਿਕਤਾ PAM ਨੂੰ ਸੌਂਪਦਾ ਹੈ, ਕਾਊਂਟਰ ਉਹ ਹੁੰਦਾ ਹੈ ਜਿਸ ਤੱਕ PAM ਸਟੈਕ ਪਹੁੰਚਦਾ ਹੈ, ਨਾ ਕਿ ਉਹ ਜੋ ਲਿਸਨਰ ਨੇ ਲੌਗ ਕੀਤਾ। ਇਹਨਾਂ ਦੋਹਾਂ ਨੂੰ ਵੱਖ ਕਰਨਾ ਪਹਿਲਾ ਲਾਭਦਾਇਕ ਕਦਮ ਹੈ।

ਦੋ ਕਾਊਂਟਰ, ਦੋ ਵੱਖ-ਵੱਖ ਸ਼ਿਕਾਰ

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

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

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

ਉਹ ਸਟੋਰ ਲੱਭੋ ਜੋ ਪਹਿਲਾਂ ਹੀ ਗਿਣਤੀ ਦਾ ਮਾਲਕ ਹੈ

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

grep -rnE 'faillock|pam_tally|pam_unix' /etc/pam.d/
ls -l /etc/pam.d/ | head -20

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

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

pam_faillock ਦੀਆਂ ਤਿੰਨ ਕਾਲ ਸਥਿਤੀਆਂ ਹਨ, ਇੱਕ ਨਹੀਂ

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

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

faillock --user alice
faillock --user alice --reset

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

ਸਮਰਪਿਤ ਸੇਵਾ ਨਾਮ ਅਲੱਗ-ਥਲੱਗਤਾ ਨਹੀਂ ਹੈ

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

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

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

ਕ੍ਰਮ ਨੂੰ ਸਵੀਕਾਰ ਕਰੋ, ਇੱਕੋ ਅਸਵੀਕਾਰ ਨੂੰ ਨਹੀਂ

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

faillock --user test-vpn-01
journalctl -u openvpn-server@lab -n 30 --no-pager | grep -i 'auth\|pam'

ਸਫਲਤਾ ਦੇ ਵਿਵਹਾਰ ਨੂੰ ਓਨੀ ਹੀ ਧਿਆਨ ਨਾਲ ਜਾਂਚੋ ਜਿੰਨਾ ਅਸਫਲਤਾ ਦੇ ਵਿਵਹਾਰ ਨੂੰ। ਜੇ ਸਫਲ ਲੌਗਇਨ ਇਤਿਹਾਸ ਨੂੰ ਸਾਫ਼ ਨਹੀਂ ਕਰਦਾ, ਤਾਂ ਆਮ ਗਲਤੀਆਂ ਦੇ ਹੌਲੀ-ਹੌਲੀ ਇਕੱਠੇ ਹੋਣ ਤੋਂ ਬਾਅਦ ਖਾਤਾ ਲਾਕ ਹੋ ਜਾਵੇਗਾ। ਜੇ ਇਹ ਹਰ ਸੇਵਾ ਤੋਂ ਸਭ ਕੁਝ ਸਾਫ਼ ਕਰ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਕਾਊਂਟਰ ਨੀਤੀ ਦੇ ਦਾਅਵੇ ਨਾਲੋਂ ਕਮਜ਼ੋਰ ਹੈ।

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