netfilter / iptables: कच्ची मेज का उपयोग क्यों नहीं?

Question

लिनक्स के तहत, हम आम फिल्टर करने के लिए आमतौर पर "फ़िल्टर" तालिका का उपयोग करते हैं:

iptables --table filter --append INPUT --source 1.2.3.4 --jump DROP
iptables --table filter --append INPUT --in-interface lo --jump ACCEPT

नीचे दिए गए नेटफिल्टर फ्लो चार्ट के अनुसार, पैकेट पहले "कच्चे" तालिका के माध्यम से यात्रा करते हैं:

तो हम लिख सकते हैं:

iptables --table raw --append PREROUTING --source 1.2.3.4 --jump DROP
iptables --table raw --append PREROUTING --in-interface lo --jump ACCEPT

• पैकेट जल्दी से संभाले जाते हैं, बिना जाने की आवश्यकता के बावजूद, कंसीलर + मेंगल + नेट + राउटिंग। इतना हल्का सीपीयू / मेमोरी का उपयोग किया जाता है (और बदले में इस तथ्य से क्षतिपूर्ति की जाती है कि iptable_raw मॉड्यूल को लोड किया जाना है)
• केवल एक नियम के मामले में बॉक्स भी एक राउटर है (हर नियम के लिए ठीक नहीं होगा, जाहिर है) क्योंकि फिल्टर / फॉरवर्ड के लिए एक ही नियम जोड़ने की आवश्यकता नहीं है

मैंने केवल तेजी से परीक्षण किए, और यह पूरी तरह से अच्छी तरह से काम करता है।
मैंने पाया दस्तावेज़ हमेशा सख्त मामलों में उपयोग की जाने वाली कच्ची तालिका का वर्णन करते हैं। लेकिन कोई भी सबसे छोटा औचित्य नहीं देता है।

प्रश्न: क्या कोई कारण है कि कच्चे टेबल का उपयोग नहीं किया गया है, इसके अलावा हठधर्मी हैं?

Comments

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

— wurtel

अगर यह सिर्फ एक सिरदर्द की समस्या है, तो मुझे लगता है कि हमें कच्चे टेबल के बारे में बोलने वाले कुछ उदाहरण खोजने चाहिए। जैसा कि यह मामला नहीं है, सिरदर्द सिद्धांत शायद मुख्य कारक नहीं है।

— ग्रेगरी MOUSSAT

Ipset के लेखक ने ipset iptables नियमों के लिए कच्ची तालिका का उपयोग करने की सिफारिश की ipset.netfilter.org/tips.html

— स्टुअर्ट कार्डलैल

Answer 1

से आदमी iptables :

raw: This table is used mainly for configuring exemptions from connection
     tracking in combination with the NOTRACK target. It registers at the
     netfilter hooks with higher priority and is thus called before
     ip_conntrack, or any other IP tables.
     It  provides the following built-in chains:

     - PREROUTING (for packets arriving via any network interface)
     - OUTPUT (for packets generated by local processes)

विश्लेषण :

तो, RAW तालिका कॉनट्रैक से पहले है और इसे पैकेट पर NOTRACK मार्क सेट करने के लिए उपयोग किए जाने वाले उद्देश्य से डिज़ाइन किया गया था जिसे आप नेटफिल्टर में ट्रैक नहीं करना चाहते हैं।

-J लक्ष्य केवल NOTRACK तक ही सीमित नहीं हैं, इसलिए हां, आप कम सीपीयू / मेमोरी की खपत के लाभ के साथ कच्ची तालिका में फ़िल्टर पैकेट देते हैं।

सबसे अधिक बार, सर्वर को सभी कनेक्शनों का ट्रैक रखने की आवश्यकता नहीं होती है। यदि आपको पिछले स्थापित कनेक्शनों के आधार पर पैकेटों को फ़िल्टर करने की आवश्यकता है, तो आपको केवल ट्रैकिंग की आवश्यकता होगी। केवल 80 के पोर्ट (और शायद 21) खुले के साथ एक सरल उद्देश्य की सेवा करने वाले सर्वर पर, इसकी आवश्यकता नहीं है। उन उदाहरणों में, आप कनेक्शन ट्रैकिंग को अक्षम कर सकते हैं।

हालाँकि, यदि आप NAT राउटर चलाने की कोशिश कर रहे हैं, तो चीजें थोड़ी जटिल हो जाती हैं। NAT को कुछ करने के लिए, आपको उन कनेक्शनों पर नज़र रखने की ज़रूरत है ताकि आप बाहरी नेटवर्क से आंतरिक नेटवर्क पर पैकेट वितरित कर सकें।

यदि पूरा कनेक्शन NOTRACK के साथ सेट किया गया है, तो आप संबंधित कनेक्शनों को ट्रैक नहीं कर पाएंगे या नहीं, कॉनट्रैक और नेट हेल्पर्स केवल अनट्रैक किए गए कनेक्शन के लिए काम नहीं करेंगे और न ही संबंधित ICMP त्रुटियां करेंगे। आपको दूसरे शब्दों में इन्हें मैन्युअल रूप से खोलना होगा। जब एफ़टीपी और एससीटीपी और अन्य जैसे जटिल प्रोटोकॉल की बात आती है, तो इसे प्रबंधित करना बहुत कठिन हो सकता है।

मामलों का उपयोग करें :

एक उदाहरण यह होगा कि यदि आपके पास एक भारी ट्रैफ़िक राउटर है जिसे आप आने वाले और बाहर जाने वाले ट्रैफ़िक को फ़ायरवॉल करना चाहते हैं, लेकिन रूट ट्रैफ़िक नहीं। फिर, आप प्रसंस्करण शक्ति को बचाने के लिए अग्रेषित ट्रैफ़िक को अनदेखा करने के लिए NOTRACK चिह्न सेट कर सकते हैं।

एक अन्य उदाहरण जब NOTRACK का उपयोग किया जा सकता है यदि आपके पास अत्यधिक ट्रैफ़िक वाला वेब-सर्वर है, तो आप एक नियम सेट कर सकते हैं जो सभी स्थानीय स्वामित्व वाले आईपी पते पर पोर्ट 80 के लिए ट्रैकिंग की बारी है, या जो वास्तव में वेब ट्रैफ़िक की सेवा कर रहे हैं। फिर आप वेब ट्रैफिक को छोड़कर अन्य सभी सेवाओं पर स्टेटफुल ट्रैकिंग का आनंद ले सकते हैं, जो पहले से ही ओवरलोड सिस्टम पर कुछ प्रोसेसिंग पावर बचा सकते हैं।

उदाहरण -> रनिंग-ए-सेमी-स्टेटलेस-लाइनक्स-राउटर-फॉर-प्राइवेट-नेटवर्क

निष्कर्ष : कच्ची तालिका का उपयोग नहीं करने का एक मजबूत कारण नहीं है, लेकिन कच्चे तालिका में NOTRACK लक्ष्य का उपयोग करते समय देखभाल करने के लिए कुछ कारण हैं।