ਵਰਡ ਪ੍ਰੈਸ XML-RPC ਬੰਦ ਕਰਨਾ: ਬਰੂਟ ਫੋਰਸ ਹਮਲਿਆਂ ਤੋਂ ਬਚਣ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ

ਵਰਡ ਪ੍ਰੈਸ XML-RPC ਬੰਦ ਕਰਨਾ, ਤੁਹਾਡੇ ਸਾਈਟ ਦੇ xmlrpc.php ਫਾਈਲ ਨੂੰ ਦੂਰ ਤੋਂ ਆ ਰਹੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਰੋਕ ਕੇ ਬਰੂਟ ਫੋਰਸ ਕੋਸ਼ਿਸ਼ਾਂ, ਪਿੰਗਬੈਕ ਦੁਰਵਿਵਹਾਰ ਅਤੇ ਬੇਮਤਲਬ ਬੌਟ ਟ੍ਰੈਫਿਕ ਨੂੰ ਜਲਦੀ ਘਟਾਉਣ ਦੀ ਕਾਰਵਾਈ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਜੇਟਪੈਕ, ਵਰਡ ਪ੍ਰੈਸ ਮੋਬਾਈਲ ਐਪ, ਪੁਰਾਣੇ ਦੂਰ ਦੇ ਪ੍ਰਕਾਸ਼ਨ ਟੂਲ ਜਾਂ XML-RPC ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਕਿਸੇ ਵਿਸ਼ੇਸ਼ ਇੰਟਿਗਰੇਸ਼ਨ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰ ਰਹੇ, ਤਾਂ XML-RPC ਨੂੰ ਬੰਦ ਕਰਨਾ ਬਹੁਤ ਸਾਰੇ ਵਰਡ ਪ੍ਰੈਸ ਸਾਈਟਾਂ ਲਈ ਸੁਰੱਖਿਅਤ ਅਤੇ ਪ੍ਰਯੋਗਸ਼ੀਲ ਸਖਤੀ ਦਾ ਇੱਕ ਕਦਮ ਹੈ। ਸਭ ਤੋਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਤਰੀਕਾ, ਬੇਨਤੀ ਨੂੰ ਵਰਡ ਪ੍ਰੈਸ ਚਲਦੇ ਹੋਏ ਸੱਤ ਸਥਰ 'ਤੇ ਰੋਕਣਾ ਹੈ; ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ Apache, LiteSpeed, Nginx ਜਾਂ WAF ਨਿਯਮ ਨਾਲ xmlrpc.php ਦੀ ਪਹੁੰਚ ਨੂੰ ਰੋਕਣਾ, ਪਲੱਗਇਨ ਨਾਲ ਬੰਦ ਕਰਨ ਦੀ ਤੁਲਨਾ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਵੱਧ ਪ੍ਰਦਰਸ਼ਨਸ਼ੀਲ ਹੁੰਦਾ ਹੈ।

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

XML-RPC ਕੀ ਹੈ ਅਤੇ ਵਰਡ ਪ੍ਰੈਸ ਵਿੱਚ ਇਹ ਕੀ ਕੰਮ ਕਰਦਾ ਹੈ?

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

ਆਧੁਨਿਕ ਵਰਡ ਪ੍ਰੈਸ ਇਕੋਸਿਸਟਮ ਵਿੱਚ REST API ਕਾਫੀ ਪ੍ਰਸਿੱਧ ਹੋ ਗਿਆ ਹੈ ਇਸ ਲਈ XML-RPC ਦੀ ਮਹੱਤਤਾ ਘੱਟ ਹੋ ਗਈ ਹੈ। ਪਰੰਤੂ ਫਾਈਲ ਅਜੇ ਵੀ ਕਈ ਸਥਾਪਨਾਵਾਂ ਵਿੱਚ ਪਹੁੰਚਯੋਗ ਹੈ। ਇਹ ਹਮਲਾਵਰਾਂ ਲਈ ਆਸਾਨੀ ਨਾਲ ਖੋਜਿਆ ਜਾਣ ਵਾਲਾ, ਸਟੈਂਡਰਡ ਰਸਤਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਅਤੇ ਆਟੋਮੇਸ਼ਨ ਨਾਲ ਟਾਰਗੇਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਰੈਂਡਮ IP ਰੇਂਜਾਂ ਨੂੰ ਸਕੈਨ ਕਰਨ ਵਾਲੇ ਬੌਟ, ਤੁਹਾਡਾ ਡੋਮੇਨ ਨਾਂ ਨਵੇਂ ਹੋਣ ਦੇ ਬਾਵਜੂਦ xmlrpc.php ਪਤੇ ਨੂੰ ਕੁਝ ਮਿੰਟਾਂ ਵਿੱਚ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦੇ ਹਨ। ਇਸ ਲਈ, ਡੋਮੇਨ ਪੁੱਛਤਾਛ ਨਾਲ ਨਵਾਂ ਖਰੀਦਿਆ ਗਿਆ ਡੋਮੇਨ ਪੇਸ਼ ਕਰਨ ਸਮੇਂ ਸੁਰੱਖਿਆ ਦੀ ਬੁਨਿਆਦ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਸੋਚਣਾ ਜਰੂਰੀ ਹੈ।

XML-RPC ਕਿਸ ਹਾਲਤਾਂ ਵਿੱਚ ਲੋੜੀਂਦ ਹੈ?

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

ਪ੍ਰਯੋਗਸ਼ੀਲ ਜਾਂਚ ਇਹ ਹੈ: ਜੇ ਤੁਸੀਂ ਆਪਣੇ ਸਾਈਟ ਤੇ ਸਮੱਗਰੀ ਸਿਰਫ wp-admin ਪੈਨਲ ਤੋਂ ਸ਼ਾਮਲ ਕਰਦੇ ਹੋ, ਜੇ ਤੁਸੀਂ ਜੇਟਪੈਕ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦੇ, ਜੇ ਤੁਸੀਂ ਮੋਬਾਈਲ ਐਪ ਤੋਂ ਪ੍ਰਕਾਸ਼ਨ ਨਹੀਂ ਕਰਦੇ, ਅਤੇ ਜੇ ਤੁਹਾਡੇ ਵਿਕਾਸਕ ਨੇ ਵਿਸ਼ੇਸ਼ XML-RPC ਇੰਟਿਗਰੇਸ਼ਨ ਸੈਟ ਨਹੀਂ ਕੀਤਾ ਹੈ, ਤਾਂ ਬਹੁਤ ਸੰਭਾਵਨਾ ਹੈ ਕਿ ਤੁਹਾਨੂੰ XML-RPC ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਕਾਰਪੋਰੇਟ ਸਾਈਟਾਂ, ਬਲੌਗ, ਕੈਟਾਲੌਗ ਸਾਈਟਾਂ, ਛੋਟੇ ਕਾਰੋਬਾਰ ਦੀਆਂ ਵੈਬਸਾਈਟਾਂ ਅਤੇ WooCommerce ਸਟੋਰਾਂ ਦਾ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਹਿੱਸਾ XML-RPC ਬੰਦ ਹੋਣ 'ਤੇ ਬਿਨਾਂ ਕਿਸੇ ਸਮੱਸਿਆ ਦੇ ਕੰਮ ਕਰਦਾ ਹੈ। ਫਿਰ ਵੀ ਜੇ ਤੁਹਾਡੇ ਕੋਲ WooCommerce, ਭੁਗਤਾਨ ਢਾਂਚਾ ਅਤੇ ਸ਼ਿਪਿੰਗ ਇੰਟਿਗਰੇਸ਼ਨ ਵਰਗੇ ਮਹੱਤਵਪੂਰਨ ਪ੍ਰਕਿਰਿਆਵਾਂ ਹਨ, ਤਾਂ ਇਹ ਤਬਦੀਲੀ ਨੂੰ ਘੱਟ ਰੂਪਾਂ ਵਿੱਚ ਪਰਖਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

ਵਰਡ ਪ੍ਰੈਸ XML-RPC ਬਰੂਟ ਫੋਰਸ ਲਈ ਕਿਉਂ ਖਤਰਾ ਹੈ?

ਬਰੂਟ ਫੋਰਸ ਹਮਲਾ ਇਕ ਹਮਲਾਵਰ ਦੁਆਰਾ ਵਰਤੋਂਕਾਰ ਨਾਮ ਅਤੇ ਪਾਸਵਰਡ ਦੇ ਜੋੜਿਆਂ ਨੂੰ ਆਟੋਮੈਟਿਕ ਸਾਧਨਾਂ ਦੁਆਰਾ ਮੁੜ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦਾ ਕਾਰਜ ਹੈ। ਵਰਡ ਪ੍ਰੈਸ ਵਿੱਚ ਇਹ ਕੋਸ਼ਿਸ਼ਾਂ ਆਮ ਤੌਰ 'ਤੇ wp-login.php ਰਾਹੀਂ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ; ਪਰ XML-RPC, ਹਮਲਾਵਰ ਨੂੰ ਵਧੀਆ ਰਸਤਾ ਪ੍ਰਦਾਨ ਕਰ ਸਕਦਾ ਹੈ। ਕਿਉਂਕਿ ਕੁਝ XML-RPC ਵਿਧੀਆਂ ਇੱਕ ਹੀ HTTP ਬੇਨਤੀ ਵਿੱਚ ਬਹੁਤ ਸਾਰੀਆਂ ਲਾਗਇਨ ਕੋਸ਼ਿਸ਼ਾਂ ਦੀ ਆਗਿਆ ਦਿੰਦੀਆਂ ਹਨ। ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ system.multicall ਫੀਚਰ, ਕਮਜ਼ੋਰ ਸੰਰਚਿਤ ਸਿਸਟਮਾਂ ਵਿੱਚ ਸੈਂਕੜੇ ਕੋਸ਼ਿਸ਼ਾਂ ਨੂੰ ਘੱਟ ਦਿਖਾਈ ਦੇਣ ਵਾਲੀਆਂ ਬੇਨਤੀਆਂ ਨਾਲ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ।

ਉਦਾਹਰਨ ਲਈ, wp-login.php ਰਾਹੀਂ 500 ਪਾਸਵਰਡ ਕੋਸ਼ਿਸ਼ਾਂ ਕਰਨਾ 500 ਵੱਖਰੀਆਂ ਬੇਨਤੀਆਂ ਵਾਂਗ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ, ਜਦ ਕਿ XML-RPC ਰਾਹੀਂ ਉਸੇ ਕੋਸ਼ਿਸ਼ਾਂ ਨੂੰ ਘੱਟ ਮਾਤਰਾ ਵਿੱਚ ਪੈਕੇਜ ਕੀਤੀ ਬੇਨਤੀਆਂ ਨਾਲ ਭੇਜਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਇਹ ਸੁਰੱਖਿਆ ਪਲੱਗਇਨਾਂ ਅਤੇ ਸਧਾਰਨ ਲੌਗ ਟ੍ਰੈਕਿੰਗ ਨੂੰ ਹਮਲੇ ਨੂੰ ਦੇਰ ਨਾਲ ਪਛਾਣਨ ਦਾ ਕਾਰਨ ਬਣਾਉਂਦੀ ਹੈ। ਨਤੀਜੇ ਵਜੋਂ CPU ਦੀ ਵਰਤੋਂ ਵਧਦੀ ਹੈ, PHP ਵਰਕਰਾਂ ਵਿੱਚ ਰੁਕਾਵਟ ਆਉਂਦੀ ਹੈ, ਡੇਟਾਬੇਸ ਬੇਮਤਲਬ ਪੁੱਛਗਿੱਛਾਂ ਨਾਲ ਥੱਕ ਜਾਂਦਾ ਹੈ ਅਤੇ ਅਸਲੀ ਦੌਰਾਖੇ ਜਲਦੀ ਜਵਾਬ ਨਹੀਂ ਮਿਲਦਾ। ਸਾਂਝੇ ਹੋਸਟਿੰਗ ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ ਇਹ ਸਿਰਫ ਸੁਰੱਖਿਆ ਦਾ ਖਤਰਾ ਨਹੀਂ, ਸਗੋਂ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਸਾਧਨ ਦੀ ਵਰਤੋਂ ਦਾ ਸਮੱਸਿਆ ਹੈ।

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

XML-RPC ਬੰਦ ਕਰਨ ਦਾ ਫੈਸਲਾ: ਜਲਦੀ ਤੁਲਨਾ ਟੇਬਲ

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

ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂਚ ਸੂਚੀ

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

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

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

ਤਰੀਕਾ 1: Apache ਜਾਂ LiteSpeed 'ਤੇ .htaccess ਨਾਲ XML-RPC ਬੰਦ ਕਰਨਾ

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

ਕਦਮ-ਦਰ-ਕਦਮ ਲਾਗੂ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ

• ਹੋਸਟਿੰਗ ਕੰਟਰੋਲ ਪੈਨਲ ਤੋਂ ਫਾਈਲ ਮੈਨੇਜਰ ਨੂੰ ਖੋਲ੍ਹੋ ਜਾਂ FTP ਨਾਲ public_html ਡਾਇਰੈਕਟਰੀ ਨਾਲ ਜੁੜੋ।
• .htaccess ਫਾਈਲ ਲੱਭੋ ਅਤੇ ਇਸਨੂੰ ਆਪਣੇ ਕੰਪਿਊਟਰ 'ਤੇ ਬੈਕਅਪ ਕਰੋ। ਜੇ ਫਾਈਲ ਦਿਖਾਈ ਨਹੀਂ ਦੇ ਰਹੀ ਤਾਂ ਲੁਕਾਈ ਫਾਈਲਾਂ ਨੂੰ ਦਿਖਾਉਣ ਦਾ ਵਿਕਲਪ ਚਾਲੂ ਕਰੋ।
• ਵਰਡ ਪ੍ਰੈਸ ਦੁਆਰਾ ਬਣਾਏ ਗਏ ਨਿਯਮਾਂ ਨੂੰ ਹਟਾਉਣ ਤੋਂ ਬਿਨਾਂ, ਫਾਈਲ ਦੇ ਉੱਪਰਲੇ ਹਿੱਸੇ ਵਿੱਚ XML-RPC ਰੋਕਣ ਵਾਲਾ ਨਿਯਮ ਸ਼ਾਮਲ ਕਰੋ।
• ਨਿਯਮ ਦਾ ਤਰਕ ਇਹ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ: xmlrpc.php ਫਾਈਲ ਲਈ ਆਉਣ ਵਾਲੀਆਂ ਸਾਰੀਆਂ ਪਹੁੰਚਾਂ ਨੂੰ ਰੋਕੋ।
• ਸੰਭਾਲੋ ਅਤੇ ਬ੍ਰਾਉਜ਼ਰ ਵਿੱਚ ਆਪਣੇ ਡੋਮੇਨ ਦੇ ਪਤੇ ਨੂੰ ਚੈੱਕ ਕਰੋ: ਤੁਹਾਡਾ-ਡੋਮੇਨ-ਨਾਮ.com/xmlrpc.php।

Apache 2.4 ਅਤੇ LiteSpeed ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ ਵਰਤਣ ਵਾਲਾ ਤਰਕ ਇਹ ਹੈ: xmlrpc.php ਫਾਈਲ ਲਈ Require all denied ਤਰਕ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਪੁਰਾਣੇ Apache 2.2 ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ Deny from all ਪਹੁੰਚ ਵੀ ਵੇਖੀ ਜਾ ਸਕਦੀ ਹੈ; ਪਰ 2026 ਮਿਆਰ ਵਿੱਚ ਨਵੀਨਤਮ ਸਰਵਰ ਸਾਫਟਵੇਅਰ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਸਿਫਾਰਿਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਅਜੇ ਵੀ ਪੁਰਾਣੇ Apache ਵਰਜਨ ਨਾਲ ਕੰਮ ਕਰ ਰਹੇ ਹੋ ਤਾਂ ਇਹ ਸਿਰਫ XML-RPC ਨਹੀਂ, ਸਗੋਂ ਆਮ ਸੁਰੱਖਿਆ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਸੁਧਾਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਸਫਲਤਾ ਨਾਲ ਰੋਕਣ 'ਤੇ xmlrpc.php ਪਤਾ 403 Forbidden, 404 Not Found ਜਾਂ ਤੁਹਾਡੇ ਸਰਵਰ ਦੇ ਸੰਰਚਨਾ ਦੇ ਅਨੁਸਾਰ ਸਮਾਨ ਪਹੁੰਚ ਰੱਦ ਕਰਨ ਵਾਲੀ ਜਵਾਬ ਦੇ ਸਕਦੀ ਹੈ। ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਪੰਨਾ XML-RPC server accepts POST requests ਵਰਗਾ ਕੋਈ ਜਵਾਬ ਨਾ ਦੇ। ਜੇ ਇਹ ਵੇਖਿਆ ਜਾ ਰਿਹਾ ਹੈ ਤਾਂ ਫਾਈਲ ਅਜੇ ਵੀ ਪਹੁੰਚਯੋਗ ਹੈ।

ਤਰੀਕਾ 2: Nginx 'ਤੇ XML-RPC ਦੀ ਪਹੁੰਚ ਨੂੰ ਰੋਕਣਾ

Nginx ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ .htaccess ਕੰਮ ਨਹੀਂ ਕਰਦਾ; ਕਿਉਂਕਿ Nginx ਡਾਇਰੈਕਟਰੀ ਬੇਸਡ .htaccess ਨੂੰ ਨਹੀਂ ਪੜ੍ਹਦਾ। ਇਸ ਲਈ ਨਿਯਮ, ਸਾਈਟ ਦੇ ਸਰਵਰ ਬਲਾਕ ਸੰਰਚਨਾ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਪ੍ਰਬੰਧਿਤ ਹੋਸਟਿੰਗ ਵਰਤ ਰਹੇ ਹੋ ਤਾਂ ਇਹ ਖੇਤਰ ਤੁਹਾਡੇ ਲਈ ਸਿੱਧਾ ਖੁੱਲਾ ਨਹੀਂ ਹੋ ਸਕਦਾ; ਇਸ ਤਰ੍ਹਾਂ ਤੁਸੀਂ ਹੋਸਟਿੰਗ ਸਹਾਇਤਾ ਟੀਮ ਤੋਂ xmlrpc.php ਦੀ ਪਹੁੰਚ ਬੰਦ ਕਰਨ ਲਈ ਬੇਨਤੀ ਕਰ ਸਕਦੇ ਹੋ।

Nginx ਪਾਸੇ ਬੁਨਿਆਦੀ ਤਰੀਕਾ, location = /xmlrpc.php ਬਲੌਕ ਨਾਲ ਬੇਨਤੀ ਨੂੰ ਰੋਕਣਾ ਜਾਂ 404 ਵਾਪਸ ਕਰਨਾ ਹੈ। ਸੁਰੱਖਿਆ ਦੇ ਨਜ਼ਰੀਏ ਨਾਲ 403 ਨਾਲ ਸਾਫ਼ ਤੌਰ 'ਤੇ ਰੋਕਣਾ ਜਾਂ 404 ਨਾਲ ਫਾਈਲ ਨੂੰ ਮੌਜੂਦ ਨਾ ਹੋਣ ਵਾਂਗ ਦਿਖਾਉਣਾ ਵੀ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ। 404 ਦੇ ਤਰੀਕੇ ਨੂੰ ਪ੍ਰਬੰਧਕਾਂ ਦੁਆਰਾ ਵੱਧ ਜਾਣਕਾਰੀ ਨਹੀਂ ਦੇਣ ਦੀ ਇੱਛਾ ਰੱਖਣ ਵਾਲਿਆਂ ਦੁਆਰਾ ਚੁਣਿਆ ਜਾਂਦਾ ਹੈ। ਨਿਯਮ ਸ਼ਾਮਲ ਕਰਨ ਤੋਂ ਬਾਅਦ Nginx ਸੰਰਚਨਾ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ ਅਤੇ ਸੇਵਾ ਨੂੰ ਮੁੜ ਲੋਡ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਗਲਤ ਅੱਖਰ ਸਾਰੀ ਸਾਈਟ ਨੂੰ ਖੋਲ੍ਹਣ ਤੋਂ ਰੋਕ ਸਕਦਾ ਹੈ ਇਸ ਲਈ ਇਹ ਕਾਰਵਾਈ ਜਰੂਰੀ ਤੌਰ 'ਤੇ ਧਿਆਨ ਨਾਲ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ।

Nginx ਵਰਤਣ ਵਾਲੇ VPS ਜਾਂ ਡੇਡੀਕੇਟਡ ਸਰਵਰਾਂ ਵਿੱਚ ਤਬਦੀਲੀ ਤੋਂ ਬਾਅਦ ਐਕਸੈਸ ਲੌਗ ਨੂੰ ਨਿਗਰਾਨੀ ਕਰਨਾ ਲਾਭਦਾਇਕ ਹੁੰਦਾ ਹੈ। ਤੁਸੀਂ ਦੇਖਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ xmlrpc.php ਦੀਆਂ ਬੇਨਤੀਆਂ ਹੁਣ 403 ਜਾਂ 404 ਨਾਲ ਨਤੀਜਾ ਦੇ ਰਹੀਆਂ ਹਨ। ਜੇ ਉਹੀ IP ਪਤਾ ਤੋਂ ਬਹੁਤ ਸਾਰੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ ਜਾਰੀ ਹਨ, ਤਾਂ fail2ban, ਰੇਟ ਸੀਮਾ ਜਾਂ WAF ਨਿਯਮ ਨਾਲ ਦੂਜੀ ਪੱਧਰ ਦੀ ਸੁਰੱਖਿਆ ਜੋੜੀ ਜਾ ਸਕਦੀ ਹੈ। ਸਰਵਰ ਪ੍ਰਬੰਧਨ ਪਾਸੇ ਵਧੇਰੇ ਵਿਸਥਾਰਿਤ ਗਾਈਡਾਂ ਲਈ VPS ਸਰਵਰ ਦੀ ਸੁਰੱਖਿਆ ਦਾ ਲਿੰਕ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ।

ਤਰੀਕਾ 3: ਸੁਰੱਖਿਆ ਪਲੱਗਇਨ ਨਾਲ XML-RPC ਬੰਦ ਕਰਨਾ

ਤਕਨੀਕੀ ਫਾਈਲ ਸੋਧਣ ਦੀ ਇੱਛਾ ਨਾ ਰੱਖਣ ਵਾਲੇ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਸੁਰੱਖਿਆ ਪਲੱਗਇਨ ਪ੍ਰਯੋਗਸ਼ੀਲ ਹੱਲ ਹਨ। Wordfence, Solid Security, All-In-One Security ਵਰਗੇ ਪਲੱਗਇਨਾਂ ਵਿੱਚ XML-RPC ਨੂੰ ਅਸਮਰੱਥ ਕਰਨ, ਪਿੰਗਬੈਕ ਨੂੰ ਬੰਦ ਕਰਨ ਜਾਂ XML-RPC ਲਾਗਇਨ ਕੋਸ਼ਿਸ਼ਾਂ ਨੂੰ ਰੋਕਣ ਦੇ ਵਿਕਲਪ ਹੋ ਸਕਦੇ ਹਨ। ਇਹ ਤਰੀਕਾ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਛੋਟੇ ਬਲੌਗਾਂ ਅਤੇ ਮੁੱਢਲੀ ਕਾਰਪੋਰੇਟ ਸਾਈਟਾਂ ਲਈ ਤੇਜ਼ ਸ਼ੁਰੂਆਤ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

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

ਪਲੱਗਇਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਧਿਆਨ ਦੇਣ ਵਾਲੀਆਂ ਗੱਲਾਂ

• ਸੁਰੱਖਿਆ ਪਲੱਗਇਨ ਨੂੰ ਸਿਰਫ ਅਧਿਕਾਰੀ ਵਰਡ ਪ੍ਰੈਸ ਪਲੱਗਇਨ ਡਾਇਰੈਕਟਰੀ ਤੋਂ ਜਾਂ ਨਿਰਮਾਤਾ ਦੀ ਅਧਿਕਾਰੀ ਵੈਬਸਾਈਟ ਤੋਂ ਡਾਊਨਲੋਡ ਕਰੋ।
• ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਅੱਪਡੇਟ ਨਾ ਹੋਏ ਪਲੱਗਇਨਾਂ ਦੀ ਚੋਣ ਨਾ ਕਰੋ। 2026 ਵਿੱਚ ਸਰਗਰਮੀ ਦੇਖਭਾਲ ਅਤੇ ਅਨੁਕੂਲਤਾ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਸੁਰੱਖਿਆ ਸੂਚਕ ਹੈ।
• ਇੱਕੋ ਕੰਮ ਲਈ ਇੱਕ ਤੋਂ ਵੱਧ ਸੁਰੱਖਿਆ ਪਲੱਗਇਨਾਂ ਨੂੰ ਇਕੱਠੇ ਨਾ ਵਰਤੋਂ। ਟਕਰਾਅ ਲਾਗਇਨ, ਕੇਸ਼ ਅਤੇ ਫਾਈਲ ਪਹੁੰਚ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰ ਸਕਦੇ ਹਨ।
• XML-RPC ਸੈਟਿੰਗ ਕਰਨ ਤੋਂ ਬਾਅਦ ਸਾਈਟ ਸਿਹਤ ਦੀ ਸਕREEN, ਫਾਰਮਾਂ, ਮੈਂਬਰਸ਼ਿਪ ਲਾਗਇਨ ਅਤੇ ਭੁਗਤਾਨ ਦੇ ਕਾਰਵਾਈਆਂ ਦੀ ਜਾਂਚ ਕਰੋ।
• ਪਲੱਗਇਨ ਲੌਗ ਨੂੰ ਨਿਯਮਤ ਰੂਪ ਵਿੱਚ ਜਾਂਚੋ। ਜੇ ਹਮਲੇ ਜਾਰੀ ਹਨ ਤਾਂ IP ਆਧਾਰਿਤ ਰੋਕਣਾ ਜਾਂ WAF ਨਿਯਮ ਸ਼ਾਮਲ ਕਰੋ।

ਤਰੀਕਾ 4: WAF, CDN ਅਤੇ ਹੋਸਟਿੰਗ ਸੁਰੱਖਿਆ ਦੀਵਾਰ ਨਾਲ ਰੋਕਣਾ

ਵੈਬ ਐਪਲੀਕੇਸ਼ਨ ਫਾਇਰਵਾਲ, ਅਰਥਾਤ WAF, ਖਰਾਬ ਬੇਨਤੀਆਂ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਛਾਨਨਾ ਲਈ ਸਭ ਤੋਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਪੱਧਰਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ। Cloudflare ਵਰਗੇ CDN ਆਧਾਰਿਤ ਹੱਲ, ਸਰਵਰ ਦੇ ਅੱਗੇ xmlrpc.php ਦੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਰੋਕ ਸਕਦੇ ਹਨ। ਤੁਹਾਡੇ ਹੋਸਟਿੰਗ ਪ੍ਰਦਾਤਾ ਦੁਆਰਾ ਦਿੱਤੇ ਗਏ ModSecurity ਜਾਂ ਵਿਸ਼ੇਸ਼ WAF ਨਿਯਮ ਵੀ ਇੱਥੇ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ। ਇਹ ਪੱਧਰ, ਖਾਸ ਤੌਰ 'ਤੇ ਕਈ ਬੌਟ ਬੇਨਤੀਆਂ ਨੂੰ ਵਰਡ ਪ੍ਰੈਸ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਰੋਕਣ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ।

WAF ਨਿਯਮ ਵਿੱਚ ਨਿਸ਼ਾਨ ਸਾਫ਼ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ: ਜੇ URI ਰਾਹ xmlrpc.php ਦਾ ਸਮਾਵੇਸ਼ ਹੈ ਤਾਂ ਬੇਨਤੀ ਨੂੰ ਰੋਕੋ ਜਾਂ ਚੁਣੌਤੀ ਲਾਗੂ ਕਰੋ। ਜੇ ਤੁਹਾਨੂੰ XML-RPC ਦੀ ਪੂਰੀ ਲੋੜ ਨਹੀਂ ਹੈ ਤਾਂ ਬਲਾਕ ਹੋਰ ਸਾਫ਼ ਹੁੰਦਾ ਹੈ। ਜੇ ਕੁਝ ਲੋੜ ਹੈ ਤਾਂ ਸਿਰਫ਼ ਖਾਸ IP ਪਤੇ ਨੂੰ ਆਗਿਆ ਦੇਣ ਦਾ ਤਰੀਕਾ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ ਜੇ ਤੁਹਾਡੀ ਕਿਸੇ ਆਟੋਮੇਸ਼ਨ ਸੇਵਾ ਦਾ IP ਸਥਿਰ ਹੈ, ਤਾਂ ਇਸ IP ਨੂੰ ਸਫੇਦ ਸੂਚੀ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਹੋਰ ਸਾਰੀਆਂ xmlrpc.php ਬੇਨਤੀਆਂ ਨੂੰ ਰੋਕ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਤਰੀਕਾ, ਸੁਰੱਖਿਆ ਅਤੇ ਕਾਰੋਬਾਰੀ ਲਗਾਤਾਰਤਾ ਦੇ ਵਿਚਕਾਰ ਇੱਕ ਸੰਤੁਲਿਤ ਹੱਲ ਹੈ।

WAF ਪੱਧਰ, SSL ਦੇ ਨਾਲ ਮਿਲ ਕੇ ਵਧੇਰੇ ਅਰਥਪੂਰਨ ਹੁੰਦਾ ਹੈ। HTTPS ਦੀ ਵਰਤੋਂ ਨਾ ਕਰਨ ਵਾਲੀਆਂ ਸਾਈਟਾਂ ਵਿੱਚ ਲਾਗਇਨ ਜਾਣਕਾਰੀਆਂ ਅਤੇ ਸੈਸ਼ਨ ਦੀ ਸੁਰੱਖਿਆ ਵੱਖ-ਵੱਖ ਖਤਰੇ ਵਿੱਚ ਹੁੰਦੀ ਹੈ। ਇਸ ਲਈ XML-RPC ਬੰਦ ਕਰਨ ਦੇ ਨਾਲ ਨਾਲ ਪੂਰੀ ਸਾਈਟ ਨੂੰ HTTPS ਰਾਹੀਂ ਚਲਾਉਣਾ, HSTS ਵਰਗੇ ਹੈਡਰਾਂ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨਾ ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਦੀ ਮਿਆਦ ਦਾ ਧਿਆਨ ਰੱਖਣਾ ਜਰੂਰੀ ਹੈ। ਇਸ ਬਿੰਦੂ 'ਤੇ SSL ਸਰਟੀਫਿਕੇਟ ਅਤੇ ਮੁਫ਼ਤ SSL ਸੰਸਥਾਪਨ ਵਿਸ਼ੇ ਕੁਝ ਕੁਦਰਤੀ ਸਹਾਇਤਾ ਸਮੱਗਰੀ ਵਜੋਂ ਵਰਤੀ ਜਾ ਸਕਦੀ ਹੈ।

XML-RPC ਬੰਦ ਕਰਨ ਦੇ ਬਾਅਦ ਟੈਸਟ ਕਿਵੇਂ ਕੀਤਾ ਜਾਵੇ?

ਤਬਦੀਲੀ ਤੋਂ ਬਾਅਦ ਇੱਕ ਹੀ ਚੀਜ਼ ਜੋ ਦੇਖਣੀ ਹੈ ਉਹ ਸਾਈਟ ਦਾ ਖੁਲਣਾ ਨਹੀਂ ਹੈ। XML-RPC ਬੰਦ ਕੀਤਾ ਗਿਆ ਹੈ ਜਾਂ ਨਹੀਂ, ਲਾਗਇਨ ਸਿਸਟਮ ਸਮੱਸਿਆ ਰਹਿਤ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਸਲੀ ਉਪਭੋਗਤਾ ਪ੍ਰਕਿਰਿਆਵਾਂ ਪ੍ਰਭਾਵਿਤ ਹੋਈਆਂ ਹਨ ਜਾਂ ਨਹੀਂ, ਲੌਗ ਵਿੱਚ ਉਮੀਦ ਕੀਤੀ ਨਤੀਜਾ ਹੈ ਜਾਂ ਨਹੀਂ ਇਨ੍ਹਾਂ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। ਹੇਠਾਂ ਦਿੱਤਾ ਟੈਸਟ ਪ੍ਰਵਾਹ, ਪ੍ਰਯੋਗਸ਼ੀਲ ਅਤੇ ਯੋਗ ਇੱਕ ਪੁਸ਼ਟੀकरण ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

• ਬ੍ਰਾਉਜ਼ਰ ਤੋਂ ਆਪਣੇ ਡੋਮੇਨ ਦੇ ਪਤੇ ਨੂੰ ਖੋਲ੍ਹੋ: ਤੁਹਾਡਾ-ਡੋਮੇਨ-ਨਾਮ.com/xmlrpc.php। ਪਹੁੰਚ ਰੱਦ ਕਰਨ, 404 ਜਾਂ ਖਾਲੀ ਜਵਾਬ ਮਿਲਣ ਦੀ ਉਮੀਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। XML-RPC server accepts POST requests ਦਾ ਪਾਠ ਨਹੀਂ ਦਿਖਾਈ ਦੇਣਾ ਚਾਹੀਦਾ।
• ਵਰਡ ਪ੍ਰੈਸ ਪ੍ਰਬੰਧਨ ਪੈਨਲ ਵਿੱਚ ਆਮ ਵਰਤੋਂਕਾਰ ਜਾਣਕਾਰੀ ਨਾਲ ਲਾਗਇਨ ਕਰੋ। ਲਾਗਇਨ ਪੰਨਾ XML-RPC ਤੋਂ ਸੁਤੰਤਰਤਾਪੂਰਕ ਕੰਮ ਕਰਦਾ ਹੈ ਇਹ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।
• ਸੰਪਰਕ ਫਾਰਮ, ਟਿੱਪਣੀ ਫਾਰਮ, ਮੈਂਬਰਸ਼ਿਪ ਅਤੇ WooCommerce ਭੁਗਤਾਨ ਦੇ ਕਦਮਾਂ ਦੀ ਜਾਂਚ ਕਰੋ।
• ਸਰਵਰ ਐਕਸੈਸ ਲੌਗ ਵਿੱਚ xmlrpc.php ਬੇਨਤੀਆਂ ਕਿਸ ਸਥਿਤੀ ਕੋਡ ਨਾਲ ਵਾਪਸ ਆਈਆਂ ਇਹਦੀ ਜਾਂਚ ਕਰੋ। 403 ਜਾਂ 404 ਜਵਾਬ ਸਹੀ ਨਿਯਮ ਦੇ ਕੰਮ ਕਰਨ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ।
• ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਸੁਰੱਖਿਆ ਪਲੱਗਇਨ ਹੈ ਤਾਂ ਘਟਨਾ ਲੌਗ ਦੀ ਜਾਂਚ ਕਰੋ। ਪੁਰਾਣੀਆਂ ਬੌਟ ਕੋਸ਼ਿਸ਼ਾਂ ਘੱਟ ਹੋਣ ਜਾਂ ਰੋਕੀਆਂ ਜਾਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ।

ਇੱਕ ਹੋਰ ਤਕਨੀਕੀ ਟੈਸਟ ਲਈ ਟਰਮੀਨਲ ਤੋਂ POST ਬੇਨਤੀ ਭੇਜੀ ਜਾ ਸਕਦੀ ਹੈ; ਪਰ ਜ਼ਿਆਦਾਤਰ ਸਾਈਟ ਦੇ ਮਾਲਿਕਾਂ ਲਈ ਬ੍ਰਾਉਜ਼ਰ ਅਤੇ ਲੌਗ ਦੀ ਜਾਂਚ ਕਾਫੀ ਹੁੰਦੀ ਹੈ। ਜੇ ਤਬਦੀਲੀ ਤੋਂ ਬਾਅਦ ਜੇਟਪੈਕ ਦੇ ਨਾਲ ਸੰਕਟ ਹੁੰਦਾ ਹੈ, ਮੋਬਾਈਲ ਐਪ ਪ੍ਰਕਾਸ਼ਿਤ ਨਹੀਂ ਹੋ ਸਕਦੀ ਜਾਂ ਕਿਸੇ ਇੰਟਿਗਰੇਸ਼ਨ ਵਿੱਚ ਗਲਤੀ ਆਉਂਦੀ ਹੈ ਤਾਂ ਇਹ ਸਿੱਧਾ ਹੈ ਕਿ XML-RPC ਦੀ ਵਾਸਤਵ ਵਿੱਚ ਲੋੜ ਹੈ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬੰਦ ਕਰਨ ਦੇ ਬਜਾਏ IP ਆਧਾਰਿਤ ਆਗਿਆ ਦੇਣ ਜਾਂ ਰੇਟ ਸੀਮਾ ਦੀ ਰਣਨੀਤੀ ਬਾਰੇ ਸੋਚਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

XML-RPC ਨੂੰ ਬੰਦ ਕਰਨਾ ਕਾਫੀ ਹੈ? ਵਾਧੂ ਸੁਰੱਖਿਆ ਉਪਾਅ

XML-RPC ਬੰਦ ਕਰਨਾ, ਬਰੂਟ ਫੋਰਸ ਹਮਲਿਆਂ ਦੇ ਖਿਲਾਫ ਇੱਕ ਤੇਜ਼ ਅਤੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਕਦਮ ਹੈ; ਪਰ ਇਹ ਇਕੱਲੇ ਸੁਰੱਖਿਆ ਦੀ ਪੂਰੀ ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦਾ। ਹਮਲਾਵਰ wp-login.php, REST API, ਕਮਜ਼ੋਰ ਪਲੱਗਇਨ, ਪੁਰਾਣੀਆਂ ਥੀਮਾਂ ਜਾਂ ਲੀਕ ਹੋਏ ਪਾਸਵਰਡਾਂ ਰਾਹੀਂ ਵੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦੇ ਹਨ। ਇਸ ਲਈ XML-RPC ਨੂੰ ਬੰਦ ਕਰਨ ਦੇ ਬਾਅਦ ਵਰਡ ਪ੍ਰੈਸ ਸੁਰੱਖਿਆ ਨੂੰ ਪਦਰੂਪਕ ਤਰੀਕੇ ਨਾਲ ਸੋਚਣਾ ਚਾਹੀਦਾ ਹੈ।

ਇਹਨਾਂ ਦੇ ਅਮਲ ਕਰਨ ਵਾਲੇ ਮੁੱਖ ਉਪਾਅ

• ਮਜ਼ਬੂਤ ਪਾਸਵਰਡ ਅਤੇ ਵਿਲੱਖਣ ਵਰਤੋਂਕਾਰ ਨਾਮ ਦੀ ਵਰਤੋਂ ਕਰੋ। admin ਵਰਤੋਂਕਾਰ ਨਾਮ ਦੀ ਵਰਤੋਂ ਨਾ ਕਰਨ ਦੀ ਆਜੇ ਵੀ ਸਧਾਰਣ ਪਰੰਤੂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਵਿਧੀ ਹੈ।
• ਦੋ ਫੈਕਟਰ ਦੀ ਪਛਾਣ ਸ਼ਾਮਲ ਕਰੋ। ਪ੍ਰਬੰਧਕ ਖਾਤਿਆਂ ਵਿੱਚ 2FA, ਪਾਸਵਰਡ ਲੀਕ ਹੋਣ ਦੇ ਖਤਰੇ ਨੂੰ ਸਖਤ ਰੂਪ ਵਿੱਚ ਘਟਾਉਂਦਾ ਹੈ।
• ਲਾਗਇਨ ਕੋਸ਼ਿਸ਼ਾਂ ਦੀ ਸੀਮਾ ਲਗੂ ਕਰੋ। wp-login.php ਲਈ ਰੇਟ ਸੀਮਾ ਜਾਂ ਸੁਰੱਖਿਆ ਪਲੱਗਇਨ ਦੀ ਵਰਤੋਂ ਕਰੋ।
• ਵਰਡ ਪ੍ਰੈਸ ਕੋਰ, ਪਲੱਗਇਨਾਂ ਅਤੇ ਥੀਮਾਂ ਨੂੰ ਅਪਡੇਟ ਰੱਖੋ। ਪੁਰਾਣੇ ਪਲੱਗਇਨ ਵਾਸਤਵਿਕ ਦੁਨੀਆਂ ਵਿੱਚ ਉਲੰਘਣਾਂ ਦੇ ਸਭ ਤੋਂ ਆਮ ਕਾਰਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹਨ।
• ਜੋ ਪਲੱਗਇਨ ਅਤੇ ਥੀਮਾਂ ਤੁਸੀਂ ਵਰਤ ਨਹੀਂ ਰਹੇ ਉਹਨਾਂ ਨੂੰ ਹਟਾਉ। ਨਿਸ਼ਕ੍ਰਿਤ ਪਰੰਤੂ ਪੁਰਾਣੇ ਪਲੱਗਇਨ ਵੀ ਫਾਈਲ ਸਿਸਟਮ 'ਤੇ ਖਤਰਾ ਪੈਦਾ ਕਰ ਸਕਦੇ ਹਨ।
• ਫਾਈਲ ਦੀਆਂ ਆਗਿਆਆਂ ਦੀ ਜਾਂਚ ਕਰੋ। ਬੇਮਤਲਬ ਲਿਖਣ ਦੀਆਂ ਆਗਿਆਆਂ, ਮਲਵੇਅਰ ਫਾਈਲਾਂ ਲੋਡ ਕਰਨ ਦੇ ਖਤਰੇ ਨੂੰ ਵਧਾਉਂਦੀਆਂ ਹਨ।
• ਨਿਯਮਤ ਬੈਕਅਪ ਲਵੋ ਅਤੇ ਵਾਪਸੀ ਦੇ ਟੈਸਟ ਕਰੋ। ਬੈਕਅਪ, ਜਦ ਤਕ ਟੈਸਟ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ, ਇੱਕ ਧਾਰਨਾ ਹੈ।
• ਭਰੋਸੇਯੋਗ ਹੋਸਟਿੰਗ ਢਾਂਚਾ ਵਰਤੋਂ। ਆਇਸੋਲੇਸ਼ਨ, ਅਪਡੇਟ PHP, WAF ਅਤੇ ਬੈਕਅਪ ਦੇ ਸਹਿਯੋਗ ਨਾਲ ਹਮਲੇ ਦੇ ਪ੍ਰਭਾਵ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ।

ਉਦਾਹਰਨ ਲਈ, ਜੇ ਤੁਸੀਂ ਸਿਰਫ XML-RPC ਬੰਦ ਕਰਦੇ ਹੋ ਅਤੇ ਪ੍ਰਬੰਧਕ ਪਾਸਵਰਡ ਨੂੰ 123456 ਵਾਂਗ ਜ਼ਿਆਦਾ ਕਮਜ਼ੋਰ ਛੱਡਦੇ ਹੋ, ਤਾਂ ਸੁਰੱਖਿਆ ਚੇਨ ਦਾ ਸਭ ਤੋਂ ਕਮਜ਼ੋਰ ਹੜ੍ਹਾ ਅਜੇ ਵੀ ਖੁਲਾ ਹੈ। ਇਸ ਦੇ ਵਿਰੁੱਧ, ਮਜ਼ਬੂਤ ਪਾਸਵਰਡ, 2FA, ਅਪਡੇਟ ਸਾਫਟਵੇਅਰ, WAF ਅਤੇ ਸੁਰੱਖਿਅਤ ਹੋਸਟਿੰਗ ਇਕੱਠੇ ਵਰਤਣ 'ਤੇ ਆਮ ਬੌਟ ਹਮਲਿਆਂ ਦੇ ਮਹੱਤਵਪੂਰਨ ਹਿੱਸੇ ਨੂੰ ਅਸਰਸ਼ਾਲ਼ੀ ਬਣਾਉਂਦੇ ਹਨ। ਇਹ ਪਹੁੰਚ, 2026 SEO ਪੱਖ ਤੋਂ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ; ਕਿਉਂਕਿ ਸੁਰੱਖਿਆ ਵਿੱਚ ਕਮਜ਼ੋਰ ਸਾਈਟਾਂ ਨੂੰ ਖ਼ਰਾਬ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼, ਸਪੈਮ ਪੰਨਾ ਉਤਪਾਦਨ ਅਤੇ ਇੰਡੇਕਸ ਖਰਾਬ ਕਰਨ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈ ਸਕਦਾ ਹੈ।

ਕਾਰਗੁਜ਼ਾਰੀ ਅਤੇ SEO ਦੇ ਅਨੁਸਾਰ XML-RPC ਬੰਦ ਕਰਨ ਦਾ ਅਸਰ

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

ਇੱਕ ਉਦਾਹਰਨ ਦੇ ਤੌਰ 'ਤੇ ਸੋਚੀਏ: ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਡੀ ਮੁੱਖ ਪੰਨਾ 300 ਮਿਲੀਸਕਿੰਟਾਂ ਦੇ ਸਰਵਰ ਜਵਾਬ ਦੇਣ ਦੇ ਸਮੇਂ ਨਾਲ ਖੁਲਦੀ ਹੈ; ਪਰ ਜਦੋਂ xmlrpc.php ਨੂੰ ਪ੍ਰਤੀ ਮਿੰਟ 1000 ਬੇਨਤੀਆਂ ਮਿਲਦੀਆਂ ਹਨ ਤਾਂ PHP ਵਰਕਰ ਭਰ ਜਾਂਦੇ ਹਨ ਅਤੇ ਜਵਾਬ ਦਾ ਸਮਾਂ 2 ਸੈਕਡ ਤੋਂ ਵੱਧ ਹੋ ਜਾਂਦਾ ਹੈ।