ਡਿਵਾਈਸ ਦੇ ਲੌਗ ਦੂਰ ਦੇ ਸੰਗ੍ਰਾਹਕ ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਕਿਵੇਂ ਭੇਜਣੇ ਹਨ

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

ਡਿਵਾਈਸ ਜੋ ਭੇਜ ਸਕਦਾ ਹੈ ਉਸ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ

ਵਿਵਹਾਰ ਵਿੱਚ ਸਿਰਫ਼ ਤਿੰਨ ਰੂਪ ਹਨ। UDP ਜਾਂ TCP ’ਤੇ ਵਿਅਕਤੀਗਤ syslog ਘਟਨਾਵਾਂ, ਉਤਪਾਦ ਵਿੱਚ ਬਣਿਆ ਪ੍ਰਮਾਣਿਤ HTTPS ਅੱਪਲੋਡ, ਜਾਂ ਡਿਸਕ ’ਤੇ ਲਿਖੀਆਂ ਅਤੇ ਹਿਲਾਉਣ ਵਾਲੀਆਂ ਪੂਰੀਆਂ ਫਾਈਲਾਂ। ਸਿਰਫ਼ UDP syslog ਭੇਜ ਸਕਣ ਵਾਲਾ ਫਾਇਰਵਾਲ ਟਨਲ ਜੋੜਨ ਨਾਲ TLS ਭੇਜਣ ਵਾਲਾ ਨਹੀਂ ਬਣੇਗਾ; ਇਹ ਅਜੇ ਵੀ ਬਿਨਾਂ ਪੁਸ਼ਟੀ ਵਾਲੇ ਡੇਟਾਗ੍ਰਾਮ ਭੇਜੇਗਾ, ਹੁਣ ਇਨਕ੍ਰਿਪਟਿਡ ਲਿਫਾਫੇ ਵਿੱਚ।

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

TLS syslog: ਸਭ ਤੋਂ ਛੋਟਾ ਰਾਹ ਜਦੋਂ ਦੋਵੇਂ ਸਿਰੇ ਬੋਲਦੇ ਹਨ

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

rsyslog ਵਿੱਚ ਸਿਰਫ਼ ਟ੍ਰਾਂਸਪੋਰਟ ਮੌਡਿਊਲ ਦਾ ਨਾਮ ਦੱਸਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿਹੜੇ ਯੁੱਗ ਵਿੱਚ ਹੋ: lmnsd_gtls GnuTLS ਨੂੰ ਲਪੇਟਦਾ ਹੈ, ਜਦੋਂ ਕਿ lmnsd_ossl OpenSSL ਨੂੰ ਲਪੇਟਦਾ ਹੈ ਅਤੇ ਮੌਜੂਦਾ 8.x ਪੈਕੇਜ ਉਹੀ ਦਿੰਦੇ ਹਨ। ਸਰਟੀਫਿਕੇਟ ਜਾਂਚ ਨਾਲ ਫਾਰਵਰਡ ਕਾਰਵਾਈ ਲਗਭਗ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਦੀ ਹੈ, ਅਤੇ ਸਹੀ ਪੈਰਾਮੀਟਰ ਨਾਮ ਤੁਹਾਡੇ ਸਥਾਪਿਤ ਸੰਸਕਰਣ ਨਾਲ ਜਾਂਚਣ ਯੋਗ ਹਨ:

action(type="omfwd" target="collector.example" port="6514" protocol="tcp"
       StreamDriver.Name="ossl" StreamDriver.Mode="1" StreamDriver.AuthMode="x509/name"
       StreamDriver.CAFile="/etc/pki/ca.pem"
       queue.type="LinkedList" queue.filename="fwdq" queue.maxDiskSpace="1g"
       queue.saveOnShutdown="on" action.resumeRetryCount="-1")

ਭੇਜਣ ਵਾਲੇ ਨੂੰ ਡੀਬੱਗ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਅੰਤ ਬਿੰਦੂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। openssl s_client -connect collector.example:6514 -servername collector.example -CAfile /etc/pki/ca.pem -verify_return_error ਜਾਂ ਤਾਂ ਵੈਧ ਚੇਨ ਨਾਲ ਹੈਂਡਸ਼ੇਕ ਪੂਰਾ ਕਰਦਾ ਹੈ ਜਾਂ ਠੀਕ-ਠੀਕ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਹੜੀ ਜਾਂਚ ਫੇਲ ਹੋਈ। ਡਿਵਾਈਸ ਤੋਂ ਹੀ ਜਾਂਚੋ, ਆਪਣੇ ਲੈਪਟਾਪ ਤੋਂ ਨਹੀਂ, ਕਿਉਂਕਿ ਡਿਵਾਈਸ ਦਾ ਟਰੱਸਟ ਸਟੋਰ ਹੀ ਮਹੱਤਵਪੂਰਨ ਹੈ।

SFTP: ਫਾਈਲਾਂ ਲਈ ਚੰਗਾ, ਪ੍ਰਵਾਹਾਂ ਲਈ ਗਲਤ

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

ਹੋਸਟ ਪੁਸ਼ਟੀ ਚਾਲੂ ਰੱਖੋ। ਪ੍ਰਾਂਪਟ ਤੋਂ ਬਚਣ ਲਈ ਇਸਨੂੰ ਬੰਦ ਕਰਨ ਵਾਲੀ ਬੈਚ ਕਾਲ ਟ੍ਰਾਂਸਪੋਰਟ ਦੀ ਇੱਕੋ-ਇੱਕ ਪ੍ਰਮਾਣਿਕਤਾ ਨਸ਼ਟ ਕਰ ਦਿੰਦੀ ਹੈ:

sftp -b /etc/logship/batch -o BatchMode=yes -o StrictHostKeyChecking=yes      -o IdentitiesOnly=yes -i /etc/logship/id_ed25519 [email protected]

ਤਿਆਰੀ ਦੌਰਾਨ ਖਾਤੇ ਦੇ known_hosts ਵਿੱਚ ਹੋਸਟ ਕੁੰਜੀ ਪਿੰਨ ਕਰੋ, ਖਾਤੇ ਨੂੰ ਟਾਰਗੇਟ ਡਾਇਰੈਕਟਰੀ ਤੱਕ ਸੀਮਿਤ ਕਰੋ, ਅਤੇ chroot ਨਾਲ internal-sftp ਉਪ-ਸਿਸਟਮ ਨੂੰ ਤਰਜੀਹ ਦਿਓ। ਮੁੜ ਭੇਜਣ ਦੀ ਕਹਾਣੀ ਵੀ ਯੋਜਨਾ ਬਣਾਓ: ਜੇ ਅੰਸ਼ਿਕ ਅਸਫਲਤਾ ਤੋਂ ਬਾਅਦ ਫਾਈਲ ਦੁਬਾਰਾ ਭੇਜੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਸੰਗ੍ਰਾਹਕ ਨੂੰ ਨਕਲ ਨੂੰ ਨਵੀਂ ਫਾਈਲ ਤੋਂ ਵੱਖਰਾ ਪਛਾਣਨਾ ਚਾਹੀਦਾ ਹੈ, ਆਮ ਤੌਰ ’ਤੇ ਨਾਮ ਅਤੇ ਚੈੱਕਸਮ ਨਾਲ, ਆਉਣ ਦੇ ਸਮੇਂ ਨਾਲ ਨਹੀਂ।

ਜਦੋਂ ਸਥਾਨਕ ਗੇਟਵੇ ਜਾਂ ਟਨਲ ਹੀ ਇਮਾਨਦਾਰ ਜਵਾਬ ਹੋਵੇ

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

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

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

ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਡਿਲੀਵਰੀ ਸਮਝੌਤਾ ਲਿਖੋ

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

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

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