పరికర లాగ్లను దూర సేకరణకర్తకు సురక్షితంగా ఎలా పంపాలి

పరికరం లాగ్లను విడుదల చేయగలదు, సేకరణకర్త ఇంటర్నెట్కు అవతల వైపు కూర్చొని ఉన్నాడు, మరియు అందరూ అడిగే మొదటి ప్రశ్న ఏ సొరంగం నిర్మించాలి అని। ఈ చట్రం తప్పు స్థలం నుండి మొదలవుతుంది। రవాణాను నిర్ణయించేది పరికరం ఉత్పత్తి చేయగల ఆకృతి, సేకరణకర్త అంగీకరించే ప్రామాణీకరణ, మరియు లింక్ తెగినప్పుడు “డెలివరీ అయింది” అనే దాని అర్థం। ఆ మూడు సమాధానాలు రాయండి, రవాణా సాధారణంగా తనను తానే ఎంచుకుంటుంది।

పరికరం విడుదల చేయగల దాని నుండి ప్రారంభించండి

ఆచరణలో మూడు ఆకృతులు మాత్రమే ఉన్నాయి। 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 లో చెప్పండి, ప్రతి దశకు ఒక యజమానిని ఇవ్వండి।