ACK पैकेट पर conntrack NEW: यह क्या साबित नहीं करता

फ़ायरवॉल लॉग में एक पंक्ति है जिसकी आपको अपेक्षा नहीं थी: एक ACK पैकेट, conntrack स्थिति NEW, ऐसा स्रोत पता जो आपका नहीं है, गंतव्य पोर्ट खुला। ललच यह है कि इसे किसी के द्वारा अनुमोदित न किए गए नए इनबाउंड कनेक्शन के रूप में पढ़ा जाए। पंक्ति वास्तव में जो कहती है वह अधिक संकीर्ण है: जब वह पैकेट इस hook तक पहुँचा, तब ट्रैकर के पास कोई मेल खाती स्थिति नहीं थी, और पैकेट में ACK था। ये दो अलग चीज़ों के बारे में दो तथ्य हैं, और इनमें से कोई भी पूरा हैंडशेक रिकॉर्ड नहीं है। निष्कर्ष निकालने से पहले मैं यह क्रम अपनाता हूँ।

फैसले से नहीं, पैकेट से शुरू करें

व्याख्या से पहले अवलोकनों को अलग करें। TCP फ़्लैग इस पैकेट का वर्णन करते हैं, ट्रैकर की स्थिति बताती है कि उस hook पर उसे क्या पता था, और आपका कैप्चर केवल उस विंडो का वर्णन करता है जो आपने रिकॉर्ड की।

इन तीनों को मिलाना ही वह तरीका है जिससे एक ACK “प्रोवाइडर ने किसी को अंदर आने दिया” बन जाता है।

hook पर NEW का वास्तव में क्या अर्थ है

iptables conntrack मिलान NEW को ऐसे पैकेट के रूप में प्रलेखित करता है जो कनेक्शन शुरू करता है, या ऐसे कनेक्शन से जुड़ा पैकेट जिसने अभी तक दोनों दिशाओं में ट्रैफ़िक नहीं देखा। ESTABLISHED का अर्थ है कि ट्रैकर ने दोनों दिशाओं में पैकेट देखे हैं। दोनों में से कोई परिभाषा यह नहीं कहती कि पैकेट SYN था, और न यह कि वह इतिहास के बिना आया।

जो ट्रैकर किसी प्रवाह को बीच से देखना शुरू करता है, वह अगले पैकेट को अपनी जानकारी के अनुसार वर्गीकृत करता है, और वह कुछ भी न हो सकता है। यह ट्रैकर की स्मृति के बारे में कथन है, दूर के होस्ट के इरादे के बारे में नहीं।

ढीला ट्रैकिंग अधिकांश ACK आश्चर्य समझाती है

कर्नेल प्रलेखित करता है nf_conntrack_tcp_loose, जो ट्रैकर को ऐसे TCP कनेक्शन उठाने देता है जिनकी शुरुआत उसने नहीं देखी। सेटिंग के डिफ़ॉल्ट मान पर, प्रवाह के मध्य से आया ACK स्थापित प्रवाह के रूप में स्वीकार किया जा सकता है। इसे बंद करें और वही पैकेट NEW के बजाय INVALID के रूप में वर्गीकृत होने की अधिक संभावना रखता है। दोनों परिणाम ट्रैकर के नियम बताते हैं, एप्लिकेशन का इतिहास नहीं।

इसलिए लेबल पर सिद्धांत बनाने से पहले वह सेटिंग जाँचें।

नीरस कारणों को इस क्रम में बाहर करें

मैंने जिन NEW-ऑन-ACK घटनाओं का पीछा किया, उनमें से अधिकांश इनमें से किसी एक पर समाप्त हुईं, और सभी को जाँचना सस्ता है:

• conntrack तालिका फ़्लश हुई, या ट्रैकर पुनः आरंभ हुआ।
• होस्ट रीबूट हुआ, या प्रवाह दूसरे namespace या डिवाइस पर चला गया।
• असममित राउटिंग ने SYN को ऐसे पथ से भेज दिया जिसे आप कैप्चर नहीं कर रहे।
• NAT ने tuple फिर से लिखा, इसलिए प्रविष्टि अब आपके पढ़े हुए से मेल नहीं खाती।
• कैप्चर देर से शुरू हुआ और शुरुआत कभी नहीं देखी।

इनमें से हर एक पुराने पैकेट को ट्रैकर की दृष्टि से हटा देता है और बाद वाले पैकेट अक्षत रहने देता है। रीबूट या तालिका फ़्लश uptime और लॉग से पुष्टि करना सबसे आसान है। असममित राउटिंग एकदिशीय कैप्चर के रूप में दिखती है। NAT चालाक है, क्योंकि ट्रैकर ने जो tuple सहेजा वह लॉग में छपा tuple नहीं है।

आगे बढ़ने से पहले लिखें कि इनमें से किन्हें आपने बाहर किया, और कैसे।

tuple, इंटरफ़ेस और hook पढ़ें

conntrack प्रविष्टि पते, पोर्ट और प्रोटोकॉल पर कुंजीबद्ध होती है, इसलिए कोई भी अनुवाद बदल देता है कि कौन-सी प्रविष्टि मेल खाती है। इंटरफ़ेस और hook भी दर्ज करें, क्योंकि ग़लत इंटरफ़ेस पर या किसी दूसरी श्रृंखला के बाद दिखा पैकेट बताता है कि पथ वह नहीं है जो आरेख में है। जब घटना में VPN शामिल हो, तय करें कि आप भीतरी पैकेट देख रहे हैं या बाहरी वाहक। फिर गेटवे ने उसी पाँच-भाग वाले tuple के लिए जो दर्ज किया उससे तुलना करें।

एक ही प्रवाह के दो परस्पर विरोधी दृश्य अकेले किसी एक से अधिक जानकारी देते हैं।

कब एस्केलेट करना उचित है

तब एस्केलेट करें जब आप ऐसी सेवा दिखा सकें जो पहुँच में है और नहीं होनी चाहिए, साथ में प्रवाह, उसे अनुमति देने वाली नीति और दोनों सिरों के साक्ष्य। केवल एक स्थिति लेबल या एक आंशिक कैप्चर के आधार पर प्रोवाइडर दोष की रिपोर्ट न करें, क्योंकि वह रिपोर्ट उसी व्याख्या के साथ बंद कर दी जाएगी जो आपने अभी पढ़ी। यदि सेवा वास्तव में उजागर है, तो उस सीमा का स्वामी ही उसे ठीक करने वाला सही व्यक्ति है, और बग की तुलना में प्रत्यायोजित पोर्ट मैपिंग या अनजाने में बना श्रोता अधिक संभावित कारण है।

फिर उस दृश्यता अंतराल को बंद करें जिसने एक पैकेट को पूरा सत्र दिखाया।