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 साठी गेटवेने नोंदविलेल्याशी तुलना करा.

एकाच प्रवाहाची दोन परस्परविरोधी दृश्ये प्रत्येकापेक्षा जास्त माहिती देतात.

कधी एस्कलेट करणे योग्य आहे

पोहोचण्यायोग्य पण नसावी अशी सेवा प्रवाह, तिला अनुमती देणारे धोरण आणि दोन्ही टोकांचे पुरावे यांसह दाखवता आल्यास एस्कलेट करा. फक्त एका स्थिती लेबलावर किंवा एका आंशिक कॅप्चरवर प्रदात्याच्या दोषाची तक्रार करू नका, कारण ती तक्रार तुम्ही नुकतीच वाचलेल्या स्पष्टीकरणाने बंद केली जाईल. सेवा खरोखर उघडी असल्यास, त्या सीमेचा मालक ती दुरुस्त करण्याचा योग्य व्यक्ती आहे, आणि बगपेक्षा प्रत्यायोजित पोर्ट मॅपिंग किंवा अनावधानाने तयार झालेला श्रोता हे अधिक संभाव्य कारण आहे.

नंतर एका पॅकेटला संपूर्ण सत्रासारखे दिसू देणारी दृश्यता त्रुटी बंद करा.