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-on-ACK घटनाहरूमध्ये धेरैजसो यीमध्ये एकमा टुंगिए, र सबै जाँच्न सस्तो छ:

• conntrack तालिका फ्लस भयो, वा ट्र्याकर पुनः सुरु भयो।
• होस्ट रिबुट भयो, वा प्रवाह अर्को namespace वा यन्त्रमा सर्यो।
• असममित राउटिङले SYN लाई तपाईंले क्याप्चर नगरेको बाटोबाट पठायो।
• NAT ले tuple पुनः लेख्यो, त्यसैले प्रविष्टि अब तपाईंले पढेकोसँग मिल्दैन।
• क्याप्चर ढिलो सुरु भयो र सुरुवात कहिल्यै देखेन।

यीमध्ये प्रत्येकले अघिल्ला प्याकेटहरूलाई ट्र्याकरको दृष्टिबाट हटाउँछ र पछिल्लाहरूलाई अक्षत राख्छ। रिबुट वा तालिका फ्लस uptime र लगबाट पुष्टि गर्न सबैभन्दा सजिलो छ। असममित राउटिङ एकदिश क्याप्चरका रूपमा देखिन्छ। NAT चलाख छ, किनभने ट्र्याकरले सञ्चित गरेको tuple लगमा छापिएको tuple होइन।

अगाडि बढ्नुअघि यीमध्ये कुन बाहिर राख्नुभयो र कसरी, लेख्नुहोस्।

tuple, इन्टरफेस र hook पढ्नुहोस्

conntrack प्रविष्टि ठेगाना, पोर्ट र प्रोटोकलमा कुञ्जीबद्ध हुन्छ, त्यसैले कुनै पनि अनुवादले कुन प्रविष्टि मिल्छ भन्ने बदल्छ। इन्टरफेस र hook पनि अभिलेख गर्नुहोस्, किनभने गलत इन्टरफेसमा वा अर्को चेनपछि देखिएको प्याकेटले बाटो रेखाचित्रमा देखाइएको जस्तो छैन भन्ने बताउँछ। घटना VPN सँग सम्बन्धित भएमा, तपाईं भित्री प्याकेट हेर्दै हुनुहुन्छ कि बाहिरी वाहक भनेर निर्णय गर्नुहोस्। त्यसपछि गेटवेले त्यही पाँच-भाग tuple का लागि अभिलेख गरेकोसँग तुलना गर्नुहोस्।

एउटै प्रवाहका दुई विरोधाभासी दृश्यले कुनै एकभन्दा बढी जानकारी दिन्छन्।

कहिले एस्केलेट गर्नु उपयुक्त हुन्छ

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

त्यसपछि एउटा प्याकेटलाई पूरै सत्रजस्तो देखाउन दिएको दृश्यता अन्तराल बन्द गर्नुहोस्।