phillipmartin/gopassivednsनेटवर्क-आधारित निष्क्रिय DNS लॉगर जो लाइव ट्रैफिक या pcap फ़ाइलों से DNS क्वेरी कैप्चर और लॉग करता है, SIEM और खतरा खुफिया प्लेटफ़ॉर्म के साथ एकीकरण के लिए JSON आउटपुट करता है।
गो में नेटवर्क-आधारित DNS लॉगिंग
एक नेटवर्क-कैप्चर आधारित DNS लॉगर, जो https://github.com/gamelinux/passivedns से प्रेरित है। यह libpcap और पैकेट प्रोसेसिंग से निपटने के लिए gopacket का उपयोग करता है। यह JSON लॉग आउटपुट करता है। यह उन वातावरणों में उच्च मात्रा में क्वेरी कैप्चर से निपटने के लिए है जहाँ एक से लेकर सैकड़ों DNS रिज़ॉल्वर हों।
यह एक अच्छा विकल्प है। मैंने इसे इसलिए बनाया क्योंकि मेरा मानना है कि बड़ी मात्रा में अविश्वसनीय डेटा को कई खराब दस्तावेजित किनारे के मामलों (edge cases) के साथ संसाधित करने जैसे कार्यों को मेमोरी भ्रष्टाचार-शैली के हमलों को रोकने के लिए एक प्रबंधित रनटाइम द्वारा नियंत्रित किया जाना चाहिए। मैंने कई संगठनों में PassiveDNS तैनात किया है, और मैंने gopassivedns को कुछ विशिष्ट कठिनाइयों को हल करने के लिए बनाया जो मैंने देखीं: मुझे बहुत सारे स्थानों को इंस्ट्रूमेंट करने की आवश्यकता थी, मुझे बहुत सारे लुकअप को संभालने के लिए स्टोरेज लेयर को स्केल करने की आवश्यकता थी, और मैं DNS के सभी किनारे के मामलों के आसपास अच्छी कवरेज वाला एक परीक्षण सूट चाहता था।
यह भी एक अच्छा विकल्प है। Bro जैसी प्रणालियाँ आमतौर पर नेटवर्क एग्रेस (network egresses) पर तैनात की जाती हैं, जिसका परिणाम यह होता है कि लुकअप का वास्तविक स्रोत आपके रिकर्सिव रिज़ॉल्वर के पीछे छिप जाता है। इसका मतलब है कि आपको आमतौर पर Bro को तैनात करना होता है और रिज़ॉल्वर क्वेरी लॉगिंग (यदि संभव हो) करनी होती है, और दोनों के लॉग को एक केंद्रीय लॉगिंग सिस्टम में एकीकृत करना होता है ताकि किसी लुकअप को क्लाइंट तक ट्रैक किया जा सके। gopassivedns को आपके रिज़ॉल्वर पर बिना किसी रिज़ॉल्वर कॉन्फ़िगरेशन परिवर्तन के और/या आपके नेटवर्क एग्रेस पर तैनात करने, एक विश्वसनीय प्रोटोकॉल के माध्यम से केंद्रीय रूप से लॉग करने और किसी भी लॉग सिस्टम में आसानी से पार्स करने के लिए डिज़ाइन किया गया था।
क्वेरी लॉगिंग के लिए रिज़ॉल्वर का समर्थन, जिसमें प्रश्न और उत्तर दोनों शामिल हैं, सबसे अच्छे रूप में खराब है। सबसे अधिक तैनात DNS सर्वरों में से एक, BIND, इसका बिल्कुल समर्थन नहीं करता है। अन्य, जैसे Windows DNS, में वास्तव में भयानक लॉग प्रारूप हैं। इसके अतिरिक्त, नेटवर्क-आधारित लॉगिंग आपके क्लाइंट से सीधे दूरस्थ सर्वर (जैसे Google DNS) को भेजे गए क्वेरी को पकड़ लेगी।
कॉन्फ़िगरेशन विकल्पों को पर्यावरण चर (environment variables), एक .env फ़ाइल में या कमांड लाइन पर निर्दिष्ट किया जा सकता है। प्राथमिकता कमांड लाइन फ़्लैग्स, .env फ़ाइल और अंत में पर्यावरण में पहले से परिभाषित चर है। कॉन्फ़िगरेशन विकल्प नीचे दिए गए हैं
आपको -dev या -pcap में से किसी एक की आपूर्ति करनी होगी।
goroutines और मानक daemonize प्रक्रिया (https://github.com/golang/go/issues/227) के साथ ज्ञात समस्याएँ हैं, इसलिए मैं दृढ़ता से अनुशंसा करता हूँ कि आप इस प्रक्रिया को सिस्टम टूल्स का उपयोग करके डेमॉन के रूप में चलाने के लिए यहाँ वर्णित विधियों में से एक का उपयोग करें: http://stackoverflow.com/questions/10067295/how-to-start-a-go-program-as-a-daemon-in-ubuntu
यदि आप syslog लॉगिंग का उपयोग करना चुनते हैं, तो हम golang के "log/syslog" का उपयोग करते हैं, जिसके लिए syslog के साथ संचार करने के लिए उपयोग किए जाने वाले यूनिक्स सॉकेट को /dev/log, /var/run/log या /var/run/syslog में से किसी एक पर होना आवश्यक है।
आपके पास 3 विकल्प हैं: इसे अपने रिज़ॉल्वर पर तैनात करें या अपने गेटवे पर या दोनों पर। अपने रिज़ॉल्वर पर तैनात करना अच्छा है क्योंकि आपको उस क्लाइंट का IP पता मिलेगा जिसने मूल अनुरोध भेजा था। आप अनुरोध के अपस्ट्रीम चरण (रिज़ॉल्वर से श्रृंखला में अगले रिज़ॉल्वर तक) भी देख सकते हैं, जब तक आप उस चरण को अनदेखा करने के लिए अपने BPF फ़िल्टर को ट्यून नहीं करते। अपने गेटवे पर तैनात करने का मतलब है कि आप क्लाइंट -> आंतरिक रिज़ॉल्वर चरण नहीं देखते हैं, इसलिए किसी अनुरोध को किसी विशिष्ट क्लाइंट से जोड़ना कठिन हो सकता है। दूसरी ओर, आप उन अनुरोधों को देखेंगे जो आपके आंतरिक रिज़ॉल्वर को बायपास करते हैं। बेशक, आप रिज़ॉल्वर से उसके द्वारा उपयोग किए जाने वाले किसी भी अपस्ट्रीम रिज़ॉल्वर को भेजे गए क्वेरी भी देखेंगे। एक आदर्श दुनिया में, मैं इस उपकरण को अपने प्रत्येक आंतरिक रिज़ॉल्वर पर और अपने गेटवे पर एक टैप (tap) पर तैनात करूँगा। आंतरिक रिज़ॉल्वर में एक BPF फ़िल्टर होगा जो क्वेरी के अपस्ट्रीम चरण को अनदेखा करता है, और गेटवे कुछ भी अनदेखा नहीं करेगा।
अभी, मैं लॉग को elasticsearch क्लस्टर में भेजने के लिए logstash का उपयोग करने की सलाह दूँगा। सभी लॉग JSON हैं, इसलिए यह काफी आसान होना चाहिए। मैं दीर्घकालिक भंडारण और सामूहिक विश्लेषण के लिए HDFS जैसी किसी चीज़ का उपयोग करने का भी सुझाव दूँगा। DNS क्वेरी आंतरिक डेटा का एक अद्भुत स्रोत हैं!
