किसी उपकरण के लॉग को दूरस्थ संग्राहक तक सुरक्षित रूप से कैसे भेजें

उपकरण लॉग उत्सर्जित कर सकता है, संग्राहक इंटरनेट के दूसरी ओर बैठता है, और हर कोई पहला सवाल यही पूछता है कि कौन-सा टनल बनाया जाए। यह ढाँचा गलत जगह से शुरू होता है। परिवहन तय करते हैं उपकरण जो प्रारूप बना सकता है, संग्राहक जो प्रमाणीकरण स्वीकार करेगा, और लिंक टूटने पर “पहुँचा दिया गया” का क्या अर्थ होना चाहिए। उन तीनों उत्तरों को लिख लें, और परिवहन आम तौर पर स्वयं को चुन लेता है।

जो उपकरण उत्सर्जित कर सकता है उसी से शुरू करें

व्यवहार में केवल तीन आकार हैं। 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 में यह कहें और हर पड़ाव को एक स्वामी दें।