उपकरणका लगहरू टाढाको सङ्कलकमा सुरक्षित रूपमा कसरी पठाउने

उपकरणले लगहरू निकाल्न सक्छ, सङ्कलक इन्टरनेटको अर्को छेउमा बस्छ, र सबैले सोध्ने पहिलो प्रश्न कुन सुरुङ बनाउने हो। यो ढाँचा गलत ठाउँबाट सुरु हुन्छ। ढुवानी तय गर्ने कुरा उपकरणले उत्पादन गर्न सक्ने ढाँचा, सङ्कलकले स्वीकार गर्ने प्रमाणीकरण, र लिङ्क टुट्दा “पुर्याइयो” को अर्थ के हुनुपर्छ भन्ने हो। ती तीन उत्तर लेख्नुहोस्, र ढुवानी सामान्यतया आफैं छानिन्छ।

उपकरणले निकाल्न सक्ने कुराबाट सुरु गर्नुहोस्

व्यवहारमा तीनवटा मात्र ढाँचा छन्। 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 मा भन्नुहोस् र प्रत्येक फड्कोलाई एक मालिक दिनुहोस्।