DNS और ARP ट्रैफ़िक ट्राइएज लैब

Arch Linux वर्कस्टेशन पर पूर्ण किया गया एक शैक्षिक पैकेट-विश्लेषण और रिज़ॉल्वर-सख्तीकरण अभ्यास।

दायरा: यह रिपॉजिटरी एक सीखने की परियोजना है। शामिल कैप्चर DNS और ARP निरीक्षण का अभ्यास करने के लिए उपयोगी है, लेकिन यह अपने आप में किसी जीवित कैश-पॉइज़निंग हमले, दुर्भावनापूर्ण हार्डवेयर, किसी विशिष्ट CVE के शोषण, या NetworkManager रूटिंग मीट्रिक से कारणात्मक संबंध को सिद्ध नहीं करता है।

मैंने इस परियोजना को क्यों संशोधित किया

मेरे पहले लेखन ने कई अवलोकनों को पुष्ट कारणों के रूप में माना। यह बहुत अधिक दृढ़ था। DNS फ्रेम का 839 बाइट्स होना स्वतः गलत-संरचित या दुर्भावनापूर्ण नहीं है, और DNS-over-TLS कॉन्फ़िगर किए गए अपस्ट्रीम रिज़ॉल्वर तक DNS ट्रैफ़िक की सुरक्षा करता है—यह ARP स्पूफिंग या हर Layer 2/3 हमले को नहीं रोकता है।

संशोधित संस्करण लैब के उपयोगी हिस्सों को रखता है जबकि निम्न को अलग करता है:

1. प्रदान किया गया डेटा क्या दर्शाता है;
2. मुझे शुरू में क्या संदेह था;
3. किसके लिए अधिक साक्ष्य की आवश्यकता होगी;
4. रिज़ॉल्वर कॉन्फ़िगरेशन वास्तव में क्या बदलता है।

यह अंतर अच्छे इंसिडेंट कार्य का हिस्सा है। साक्ष्य जितना समर्थन करता है उससे अधिक दावा करने की तुलना में निष्कर्ष को सीमित करना बेहतर है।

लैब लक्ष्य

• Wireshark और tshark के साथ DNS और ARP ट्रैफ़िक का निरीक्षण करें।
• सादा-पाठ DNS को एन्क्रिप्टेड के रूप में गलत लेबल किए बिना स्थानीय रिज़ॉल्वर परिणामों की तुलना किसी ज्ञात सार्वजनिक रिज़ॉल्वर से करें।
• प्रमाणित TLS के ऊपर अपस्ट्रीम DNS क्वेरी को अग्रेषित करने के लिए Unbound को कॉन्फ़िगर करें।
• सीमाओं और वैकल्पिक स्पष्टीकरणों का दस्तावेजीकरण करें।
• ऐसे चरण तैयार करें जिन्हें कोई अन्य व्यक्ति दोहरा सके।

वातावरण

• Arch Linux वर्कस्टेशन
• Wireshark / tshark
• BIND dig
• Unbound स्थानीय रिज़ॉल्वर
• TCP/853 के ऊपर Cloudflare और Quad9 अपस्ट्रीम रिज़ॉल्वर

लैब दोबारा चलाए जाने पर सटीक पैकेज संस्करण दर्ज किए जाने चाहिए। वर्तमान रिपॉजिटरी में ट्रैफ़िक को किसी उत्पाद भेद्यता से जोड़ने के लिए पर्याप्त संस्करण मेटाडेटा नहीं है।

प्रदान किए गए साक्ष्य

समीक्षा को दोहराएं

1. फ़ाइल अखंडता रिकॉर्ड करें

sha256sum evidence/incident_triage_snippet.pcap
capinfos evidence/incident_triage_snippet.pcap

हैश और कैप्चर मेटाडेटा को अपने नोट्स के साथ सहेजें। कैप्चर को “पूर्ण इंसिडेंट साक्ष्य” न कहें; यह एक स्निपेट है।

2. ARP ट्रैफ़िक की समीक्षा करें

tshark -r evidence/incident_triage_snippet.pcap -Y arp \
  -T fields -e frame.number -e frame.time_relative \
  -e arp.opcode -e arp.src.proto_ipv4 -e arp.src.hw_mac \
  -e arp.dst.proto_ipv4 -e arp.dst.hw_mac

बार-बार या विरोधाभासी IP-से-MAC दावों की तलाश करें। विरोध जाँच करने का संकेत है, किसी हमलावर का स्वतः प्रमाण नहीं। जाँच करें कि क्या पते सिंथेटिक लैब मान हैं, क्या कोई डिवाइस वैध रूप से बदला है, और क्या समय-निर्धारण परिकल्पना का समर्थन करता है।

3. DNS ट्रैफ़िक की समीक्षा करें

tshark -r evidence/incident_triage_snippet.pcap -Y dns \
  -T fields -e frame.number -e frame.time_relative \
  -e ip.src -e ip.dst -e udp.srcport -e udp.dstport \
  -e dns.id -e dns.flags.response -e dns.qry.name \
  -e dns.count.answers -e frame.len

उपयोगी अनुवर्ती फ़िल्टर:

dns && frame.len == 839
dns.flags.response == 1
dns.qry.name == "."
arp.duplicate-address-detected || arp.duplicate-address-frame

अकेले पैकेट आकार कोई निर्णय नहीं है। DNS प्रतिक्रिया आकार रिकॉर्ड गणना, EDNS, DNSSEC और परिवहन व्यवहार के कारण भिन्न हो सकते हैं। डिकोड किए गए रिकॉर्ड का निरीक्षण करें और उनकी तुलना किसी ज्ञात-अच्छे आधाररेखा से करें।

4. रिज़ॉल्वरों की तुलना करें

chmod +x scripts/checkdns.sh
./scripts/checkdns.sh example.com

स्क्रिप्ट सीधे dig @1.1.1.1 क्वेरी को पोर्ट 53 पर सादा-पाठ DNS के रूप में सही ढंग से लेबल करती है। जब kdig उपलब्ध होता है, तो यह एक अलग TLS परीक्षण भी करती है।

5. Unbound अग्रेषण को मान्य करें

configs/unbound.conf की समीक्षा करें, स्थानीय सिस्टम के लिए प्रमाणपत्र पथ अनुकूलित करें, और उपयोग से पहले मान्य करें:

sudo unbound-checkconf configs/unbound.conf
sudo ss -tnp | grep ':853'
dig @127.0.0.1 example.com

एक सफल क्वेरी के साथ TCP/853 से स्थापित कनेक्शन, संकीर्ण निष्कर्ष का समर्थन करता है कि Unbound TLS के ऊपर कॉन्फ़िगर किए गए अपस्ट्रीम को अग्रेषित कर रहा है। यह सिद्ध नहीं करता कि कोई असंबंधित ARP या रूटिंग समस्या समाप्त कर दी गई थी।

निष्कर्ष और सीमाएं

• कैप्चर का उपयोग DNS और ARP फ्रेम्स की पहचान करने और संरचित समीक्षा का अभ्यास करने के लिए किया जा सकता है।
• 839-बाइट DNS फ्रेम एक अवलोकन है, अपने आप में समझौते का संकेतक नहीं।
• वर्तमान साक्ष्य किसी भेद्य BIND 9 रिज़ॉल्वर या प्रभावित संस्करण की पहचान नहीं करते, इसलिए CVE-2025-40778 एक इंसिडेंट आरोपण के बजाय पृष्ठभूमि शोध है।
• प्रमाणित DNS-over-TLS इस रिज़ॉल्वर और इसके अपस्ट्रीम के बीच गोपनीयता और अखंडता में सुधार करता है। यह पूरे स्थानीय नेटवर्क को सुरक्षित नहीं करता है।
• मजबूत आरोपण के लिए पूर्ण कैप्चर उत्पत्ति, डिवाइस सूची, रिज़ॉल्वर/संस्करण साक्ष्य, पैकेट-संख्या संदर्भ, टाइमस्टैम्प और दोहराने योग्य पहले/बाद परीक्षण की आवश्यकता होगी।

संदर्भ

• RFC 7858 — DNS over TLS
• RFC 8310 — DNS Privacy Usage Profiles
• ISC advisory for CVE-2025-40778
• Wireshark display-filter reference

कानूनी और गोपनीयता टिप्पणी

पैकेट-कैप्चर और नेटवर्क-परीक्षण उपकरणों का उपयोग केवल उन सिस्टम और नेटवर्क पर करें जिनके आप स्वामी हैं या जिनके परीक्षण के लिए आप अधिकृत हैं। प्रकाशित करने से पहले कैप्चर में निजी पते, होस्टनाम, टोकन, क्रेडेंशियल और व्यक्तिगत जानकारी की जाँच करें।