ਉਹ ਕਮਜ਼ੋਰੀ ਖੋਜ ਕਿਸ VPN ਪ੍ਰਕਿਰਿਆ ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ?

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

ਕ੍ਰਮ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਪਹਿਲਾਂ ਭਾਗ, ਦੂਜੀ ਸਲਾਹ, ਤੀਜਾ ਇਲਾਜ।

ਰਿਪੋਰਟ ਪੋਰਟ ਦਾ ਨਾਮ ਦੱਸਦੀ ਹੈ, ਪ੍ਰੋਗਰਾਮ ਦਾ ਨਹੀਂ

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

ਨਤੀਜੇ ਨਾਲ ਮੰਜ਼ਿਲ, ਢੋਆ-ਢੁਆਈ, ਪੋਰਟ ਅਤੇ ਸੇਵਾ ਦਾ ਨਾਮ ਦਰਜ ਕਰੋ, ਤਾਂ ਜੋ ਦਾਇਰਾ ਖੋਜ ਨਾਲ ਚੱਲੇ।

ਚੱਲ ਰਿਹਾ ਬਿਲਡ ਅਸਲ ਵਿੱਚ ਕੀ ਹੈ

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

systemctl status openvpn-server@server --no-pager
ps -o pid,lstart,args -C openvpn
ss -lntup | grep -E '1194|443'
dpkg -l | grep -i -E 'openvpn|libssl'
ldd "$(command -v openvpn)" | grep -i ssl

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

ਬਿਲਡ ਨੂੰ ਸਲਾਹ ਦੇ ਦਾਇਰੇ ਨਾਲ ਮਿਲਾਉਣਾ

ਸਲਾਹਾਂ ਉਤਪਾਦ, ਸੰਸਕਰਣ ਅਤੇ ਕਦੇ-ਕਦੇ ਲੋੜੀਂਦੀਆਂ ਸ਼ਰਤਾਂ ਦੱਸਦੀਆਂ ਹਨ, ਅਤੇ ਉਹ ਤਿੰਨ ਖੇਤਰ ਹਮੇਸ਼ਾ ਪੈਕੇਜ ਸੰਸਕਰਣ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ। OpenVPN ਦੀ ਅਪ੍ਰੈਲ 2014 ਦੀ Heartbleed ਸਲਾਹ ਇੱਕ ਲਾਭਦਾਇਕ ਇਤਿਹਾਸਕ ਉਦਾਹਰਣ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਪ੍ਰਭਾਵਿਤ Access Server ਰਿਲੀਜ਼ਾਂ ਨੂੰ ਵੱਖਰੇ ਐਕਸਪੋਜ਼ਰ ਵਾਲੀਆਂ ਵੈੱਬ ਸੇਵਾਵਾਂ ਅਤੇ VPN ਡੈਮਨਾਂ ਤੋਂ ਵੱਖ ਕਰਦੀ ਹੈ। ਸਬਕ ਇਹ ਹੈ ਕਿ OpenSSL ਸ਼ਬਦ ਨੂੰ ਪੈਟਰਨ ਨਾਲ ਮਿਲਾਉਣ ਦੀ ਬਜਾਏ ਪੜ੍ਹੋ ਕਿ ਲਿਖਤ ਕਿਸ ਭਾਗ ਨੂੰ ਕਵਰ ਕਰਦੀ ਹੈ।

ਉਹ ਸਲਾਹ ਵੀ ਪੁਰਾਣੀ ਹੈ। ਉਸਦੇ ਪੈਚ ਕੀਤੇ ਰਿਲੀਜ਼ ਨੰਬਰ ਹੁਣ ਸਥਾਪਨਾ ਸਲਾਹ ਨਹੀਂ ਹਨ, ਅਤੇ 2014 ਵਿੱਚ ਠੀਕ ਕੀਤੀ ਗਈ ਖਾਮੀ ਅੱਜ ਤੁਸੀਂ ਚਲਾ ਰਹੀ ਸ਼ਾਖਾ ਦੀਆਂ ਬਾਅਦ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦੀ।

ਮਤਭੇਦ ਸੁਲਝਾਉਣਾ, ਫਿਰ ਐਕਸਪੋਜ਼ਰ ਬੰਦ ਕਰਨਾ

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

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

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