उपकरणाचे लॉग दूरच्या संग्राहकाकडे सुरक्षितपणे कसे पाठवायचे

उपकरण लॉग उत्सर्जित करू शकते, संग्राहक इंटरनेटच्या दुसऱ्या बाजूला बसतो, आणि प्रत्येकजण विचारतो तो पहिला प्रश्न म्हणजे कोणता बोगदा बांधायचा। ही चौकट चुकीच्या ठिकाणाहून सुरू होते। वाहतूक ठरवते ते उपकरण जे स्वरूप तयार करू शकते, संग्राहक जे प्रमाणीकरण स्वीकारेल, आणि दुवा तुटल्यावर “वितरित” चा अर्थ काय असावा। ती तीन उत्तरे लिहून ठेवा, आणि वाहतूक सहसा स्वतःच निवडली जाते।

उपकरण जे उत्सर्जित करू शकते त्यापासून सुरुवात करा

प्रत्यक्षात फक्त तीन आकार आहेत। 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 मध्ये तसे सांगा आणि प्रत्येक झेपेला मालक द्या।