ਜ਼ਿਮਬਰਾ ਅਤੇ ਮੇਲ ਬੰਬਾਰੀ ਸੁਰੱਖਿਆ

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

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

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

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

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

ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ ਤੋਂ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਲੋੜੀਂਦੀ ਹੈ cbpolicyd ਮੋਡੀਊਲ ਨੂੰ ਸਰਗਰਮ ਕਰਨਾ, ਜੋ ਕਿ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ MTA ਸਰਵਰ 'ਤੇ Zimbra Collaboration Suite OSE ਵਿੱਚ ਪਹਿਲਾਂ ਤੋਂ ਸਥਾਪਤ ਹੈ। ਇਹ zmprov ms `zmhostname` +zimbraServiceEnabled cbpolicyd ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਸ ਤੋਂ ਬਾਅਦ, ਤੁਹਾਨੂੰ ਆਰਾਮ ਨਾਲ cbpolicyd ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣ ਲਈ ਵੈੱਬ ਇੰਟਰਫੇਸ ਨੂੰ ਸਰਗਰਮ ਕਰਨ ਦੀ ਲੋੜ ਹੋਵੇਗੀ। ਅਜਿਹਾ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਵੈੱਬ ਪੋਰਟ ਨੰਬਰ 7780 'ਤੇ ਕਨੈਕਸ਼ਨਾਂ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣ ਦੀ ਲੋੜ ਹੈ, ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਪ੍ਰਤੀਕ ਲਿੰਕ ਬਣਾਓ ln -s /opt/zimbra/common/share/webui /opt/zimbra/data/httpd/htdocs/webui, ਅਤੇ ਫਿਰ ਨੈਨੋ ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸੈਟਿੰਗਜ਼ ਫਾਈਲ ਨੂੰ ਸੰਪਾਦਿਤ ਕਰੋ /opt/zimbra/data/httpd/htdocs/webui/includes/config.php, ਜਿੱਥੇ ਤੁਹਾਨੂੰ ਹੇਠ ਲਿਖੀਆਂ ਲਾਈਨਾਂ ਲਿਖਣ ਦੀ ਲੋੜ ਹੈ:

$DB_DSN="sqlite:/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb";
$DB_USER="root";
$DB_TABLE_PREFIX="";

ਇਸ ਤੋਂ ਬਾਅਦ, ਜੋ ਬਾਕੀ ਰਹਿੰਦਾ ਹੈ ਉਹ zmcontrol ਰੀਸਟਾਰਟ ਅਤੇ zmapachectl ਰੀਸਟਾਰਟ ਕਮਾਂਡਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਜ਼ਿਮਬਰਾ ਅਤੇ ਜ਼ਿਮਬਰਾ ਅਪਾਚੇ ਸੇਵਾਵਾਂ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰਨਾ ਹੈ। ਇਸ ਤੋਂ ਬਾਅਦ, ਤੁਹਾਡੇ ਕੋਲ ਵੈੱਬ ਇੰਟਰਫੇਸ ਤੱਕ ਪਹੁੰਚ ਹੋਵੇਗੀ example.com:7780/webui/index.php. ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਇਸ ਵੈੱਬ ਇੰਟਰਫੇਸ ਦਾ ਪ੍ਰਵੇਸ਼ ਦੁਆਰ ਅਜੇ ਕਿਸੇ ਵੀ ਤਰੀਕੇ ਨਾਲ ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਹੈ ਅਤੇ ਅਣਅਧਿਕਾਰਤ ਵਿਅਕਤੀਆਂ ਨੂੰ ਇਸ ਵਿੱਚ ਆਉਣ ਤੋਂ ਰੋਕਣ ਲਈ, ਵੈੱਬ ਇੰਟਰਫੇਸ ਦੇ ਹਰੇਕ ਪ੍ਰਵੇਸ਼ ਦੁਆਰ ਤੋਂ ਬਾਅਦ ਤੁਸੀਂ ਪੋਰਟ 7780 'ਤੇ ਕੁਨੈਕਸ਼ਨ ਬੰਦ ਕਰ ਸਕਦੇ ਹੋ।

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

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

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

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

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

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

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

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

ਇਸ ਤੋਂ ਇਲਾਵਾ, SPF, DMARC, ਅਤੇ DKIM ਜਾਂਚਾਂ ਨੂੰ ਜੋੜਨਾ ਈਮੇਲ ਬੰਬਾਰੀ ਤੋਂ ਬਚਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ। ਅਕਸਰ ਚਿੱਠੀਆਂ ਜੋ ਮੇਲ ਬੰਬਾਰੀ ਦੀ ਪ੍ਰਕਿਰਿਆ ਰਾਹੀਂ ਪਹੁੰਚਦੀਆਂ ਹਨ, ਅਜਿਹੀਆਂ ਜਾਂਚਾਂ ਨੂੰ ਪਾਸ ਨਹੀਂ ਕਰਦੀਆਂ। ਇਹ ਕਿਵੇਂ ਕਰਨਾ ਹੈ ਬਾਰੇ ਚਰਚਾ ਕੀਤੀ ਗਈ ਸੀ ਸਾਡੇ ਪਿਛਲੇ ਲੇਖਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵਿੱਚ.

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

ਸਰੋਤ: www.habr.com