ಸಾಧನದ ಲಾಗ್ಗಳನ್ನು ದೂರದ ಸಂಗ್ರಾಹಕಕ್ಕೆ ಸುರಕ್ಷಿತವಾಗಿ ಕಳುಹಿಸುವುದು ಹೇಗೆ

ಸಾಧನವು ಲಾಗ್ಗಳನ್ನು ಹೊರಡಿಸಬಲ್ಲದು, ಸಂಗ್ರಾಹಕವು ಇಂಟರ್ನೆಟ್ನ ಇನ್ನೊಂದು ಬದಿಯಲ್ಲಿ ಕುಳಿತಿದೆ, ಮತ್ತು ಎಲ್ಲರೂ ಕೇಳುವ ಮೊದಲ ಪ್ರಶ್ನೆ ಎಂದರೆ ಯಾವ ಸುರಂಗವನ್ನು ನಿರ್ಮಿಸಬೇಕು। ಈ ಚೌಕಟ್ಟು ತಪ್ಪು ಸ್ಥಳದಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ। ಸಾಗಣೆಯನ್ನು ನಿರ್ಧರಿಸುವುದು ಸಾಧನವು ಉತ್ಪಾದಿಸಬಹುದಾದ ಸ್ವರೂಪ, ಸಂಗ್ರಾಹಕವು ಸ್ವೀಕರಿಸುವ ದೃಢೀಕರಣ, ಮತ್ತು ಕೊಂಡಿ ಮುರಿದಾಗ “ವಿತರಿಸಲಾಗಿದೆ” ಎಂಬುದರ ಅರ್ಥ। ಆ ಮೂರು ಉತ್ತರಗಳನ್ನು ಬರೆದಿಡಿ, ಸಾಗಣೆ ಸಾಮಾನ್ಯವಾಗಿ ತಾನೇ ಆಯ್ಕೆಯಾಗುತ್ತದೆ।

ಸಾಧನವು ಹೊರಡಿಸಬಹುದಾದದ್ದರಿಂದ ಪ್ರಾರಂಭಿಸಿ

ಪ್ರಾಯೋಗಿಕವಾಗಿ ಮೂರು ರೂಪಗಳಿವೆ। 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ನಲ್ಲಿ ಹೇಳಿ ಮತ್ತು ಪ್ರತಿ ಹೆಜ್ಜೆಗೆ ಒಬ್ಬ ಮಾಲೀಕರನ್ನು ನೀಡಿ।