लगभग 1 मिलियन IP पतों को ब्लैकलिस्ट करने के लिए IPtables या अशक्त मार्ग का उपयोग करें?

Question

मैं ऐसी स्थिति में आया हूं, जहां एक ग्राहक को केवल 1 मिलियन व्यक्तिगत आईपी पते (कोई सबनेट) के तहत एक सेट को ब्लैकलिस्ट करने की आवश्यकता है, और नेटवर्क प्रदर्शन एक चिंता का विषय है। जबकि मैं अनुमान लगाता हूं कि IPTables नियमों में मार्गों की तुलना में प्रदर्शन प्रभाव कम होगा, यह केवल अनुमान है।

क्या किसी के पास IPTables या शून्य रूटिंग के पक्ष में कोई ठोस सबूत या अन्य औचित्य है जो IP पतों की लंबी सूचियों को ब्लैकलिस्ट करने के लिए समाधान के रूप में है? इस मामले में सब कुछ स्वचालित है, इसलिए आसानी से उपयोग वास्तव में एक चिंता का विषय नहीं है।

EDIT 26-Nov-11

कुछ परीक्षण और विकास के बाद, ऐसा प्रतीत होता है कि इनमें से कोई भी विकल्प व्यावहारिक नहीं है। ऐसा प्रतीत होता है कि दोनों रूट लुकअप और आईपीटेबल्स नियम के माध्यम से रैखिक खोज करते हैं, और इस कई नियमों को संसाधित करने के लिए बस बहुत लंबा समय लेते हैं। आधुनिक हार्डवेयर पर, एक iptables ब्लैकलिस्ट में 1M आइटम डालने से सर्वर लगभग 2 दर्जन पैकेट प्रति सेकंड धीमा हो जाता है। इसलिए IPTables और अशक्त मार्ग बाहर हैं।

ipset, जैसा कि जिमी हेडमैन द्वारा सिफारिश की गई, यह बहुत अच्छा होगा, सिवाय इसके कि यह आपको एक सेट में 65536 से अधिक पतों को ट्रैक करने की अनुमति नहीं देता है, इसलिए मैं तब तक इसका उपयोग करने की कोशिश नहीं कर सकता जब तक कि किसी के पास कोई विचार न हो।

जाहिरा तौर पर यह कई आईपी को अवरुद्ध करने का एकमात्र समाधान अनुप्रयोग परत में अनुक्रमित खोज कर रहा है। क्या ऐसा नहीं है?

---

अधिक जानकारी:

इस उदाहरण में उपयोग मामला वेब सर्वर पर स्थिर सामग्री तक पहुंचने से आईपी पते की "ज्ञात अपराधियों" सूची को अवरुद्ध कर रहा है। एफडब्ल्यूआईडब्ल्यू, अपाचे के माध्यम से अवरुद्ध Deny fromकरना समान रूप से धीमा है (यदि ऐसा नहीं है) तो यह एक रैखिक स्कैन भी करता है।

---

FYI करें: अंतिम कार्य समाधान ब्लैकलिस्ट के खिलाफ लुकअप करने के लिए एक बर्कले DB मानचित्र के साथ संयोजन में अपाचे के mod_rewrite का उपयोग करना था। बर्कले DBs की अनुक्रमित प्रकृति ने सूची को O (लॉग एन) प्रदर्शन के साथ स्केल करने की अनुमति दी।

Comments

इस प्रकार की समस्या को संभालने के लिए ipset ( ipset.netfilter.org ) को कम डिज़ाइन नहीं किया गया है?

— जिमी हेडमैन

@ जिमीहेडमैन: आपको इसका जवाब देना चाहिए। और फिर सभी 3 तरीकों से करने के लिए एक सुझाव जोड़ें :)

— मिकीबी

अगर आप हल करने की कोशिश कर रहे हैं तो आप किस समस्या के बारे में थोड़ी और जानकारी दे सकते हैं, मैं उत्सुक हूं? शायद 1 एम आईपी पते को अवरुद्ध करना समस्या को ठीक करने का तरीका नहीं है?

— SpacemanSpiff

यह जानने में बहुत मदद मिलेगी कि आप इस कई पतों को ब्लॉक क्यों करना चाहते हैं, और आप जो INPUT या FORWARD ट्रैफ़िक फ़िल्टर करना चाहते हैं, उसे मिटाना चाहते हैं।

— जुलियानो

यहां आप देख सकते हैं कि कैसे ipset नियमित रूप से iptables नियमों की तुलना में 11x तेज के बारे में iptables नियम बनाते हैं। daemonkeeper.net/781/mass-blocking-ip-addresses-with-ipset यह मदद करें।

— एलियन टॉरेस

Answer 1

लुकअप की संख्या को कम करने के लिए iptables और मल्टी-लेवल ट्री के निर्माण का प्रयास करें।

iptables -N rules_0_0_0_0_2
iptables -N rules_64_0_0_0_2
iptables -N rules_128_0_0_0_2
iptables -N rules_192_0_0_0_2
iptables -N rules_0_0_0_0_4
iptables -N rules_16_0_0_0_4

iptables -A INPUT -p tcp --dport 80 -s 0.0.0.0/2 -j rules_0_0_0_0_2
iptables -A INPUT -p tcp --dport 80 -s 64.0.0.0/2 -j rules_64_0_0_0_2
iptables -A INPUT -p tcp --dport 80 -s 128.0.0.0/4 -j rules_128_0_0_0_2
iptables -A INPUT -p tcp --dport 80 -s 192.0.0.0/4 -j rules_192_0_0_0_2

iptables -A rules_0_0_0_0_2 -s 0.0.0.0/4 -j rules_0_0_0_0_4
iptables -A rules_0_0_0_0_2 -s 16.0.0.0/4 -j rules_16_0_0_0_4

और इसी तरह - घोंसले के शिकार के स्तर को जोड़ना; स्पष्ट रूप से आपको नियमों के निर्माण के लिए एक स्वचालित तरीके की आवश्यकता होगी और आपके पास उन नेटवर्कों के लिए जंजीर होनी चाहिए जहां आपके पास एक या एक से अधिक अपराधी हैं - इस तरह से आप उन लुकअप की संख्या को कम कर सकते हैं जो काफी महत्वपूर्ण रूप से किए जाने हैं और मुझे लगता है कि यह हो सकता है वास्तव में काम करते हैं।

Comments

यह ध्वनि करता है जैसे कि यह काम कर सकता है, प्रभावी ढंग से ओ (एन) से ओ (लॉग एन) से फ़ायरवॉल नियम लुकअप की समय जटिलता को कम कर सकता है, प्रभावी रूप से आईपीटबल्स में एक खोज ट्री का निर्माण कर सकता है।

— प्रति वॉन ज़्वीबर्गबर्ग

यदि आप इस मार्ग पर जाने का निर्णय लेते हैं, तो संभवतः आईपी पतों की सूची से संतुलित बाइनरी सर्च ट्री बनाने के लिए कुछ एल्गोरिदम का उपयोग करना उपयोगी होगा, और फिर उस खोज ट्री की संरचना को IPtables नियमों के एक सेट के रूप में डंप करना होगा।

— प्रति वॉन ज़्वीबर्गबर्ग

@Per वॉन Zweigbergk - वास्तव में ... या बस पेड़ को जल्दी से छाँट दें जहाँ गहरी नज़र रखने की ज़रूरत नहीं है। हालाँकि, नियमों की उस अनलोड राशि को लोड करने में बहुत समय लगेगा।

— pQd

यह एक बहुत अच्छा दृष्टिकोण है। जाहिर है कि इसे बनाए रखने के लिए थोड़ी प्रसंस्करण की आवश्यकता है, लेकिन यह सही विचार है, मुझे लगता है।

— tylerl

@ IPQables एट अल के साथ पिछली विफलताओं के बाद @PQd, मैंने बर्कले डेटाबेस के साथ एक रिवेट्रिप का उपयोग करके अपाचे में एक समाधान लागू किया । लेकिन लूप में iptables का उपयोग करने वाला मेरा सबसे तेज़ तंत्र प्रति सेकंड लगभग 100 नियमों को लोड करता है, जबकि iptables-restore ने पूरे सेट को लगभग 4 सेकंड में पूरा किया। यह एक टॉप-ऑफ-द-लाइन डेस्कटॉप कंप्यूटर पर है। रिवाइटरपाइप तंत्र का प्रदर्शन पर एक कम प्रभाव पड़ता है।

— टायलरल

Answer 2

यह वास्तव में ipsetऐसा ही है।

इसकी वेबसाइट http://ipset.netfilter.org/ से :

यदि आप चाहते हैं

• एक से अधिक आईपी पते या पोर्ट नंबर स्टोर करें और एक स्वूप में iptables द्वारा संग्रह के खिलाफ मैच करें;
• आईपी ​​पते या बंदरगाहों के खिलाफ प्रदर्शन दंड के बिना गतिशील रूप से iptables नियम अपडेट करें;
• एक एकल iptables नियम के साथ जटिल आईपी पते और बंदरगाहों पर आधारित नियमों को व्यक्त करें और आईपी सेट की गति से लाभ उठाएं

तो आपके लिए ipset उचित उपकरण हो सकता है।

यह एक नेटफिल्टर कोर टीम के सदस्य जोसेफ कडलेसिक (जिन्होंने REJECT लक्ष्य भी लिखा है) द्वारा लिखा गया है, इसलिए यह सबसे अच्छा विकल्प है जिसके बारे में मैं सोच सकता हूं।

यह हाल की गुठली में भी शामिल है।

Comments

जहाँ तक मैंने देखा है, ipset 65k आईपी पते पर सबसे ऊपर है। क्या कोई सेट प्रकार है जो 1M प्रविष्टियों को संभाल सकता है?

— टायलरल

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

— मैथ्यू इफ

हालांकि इसके लायक यह है कि 1M पतों के साथ एक ipset का मेमोरी उपयोग बड़े होने लगता है। नेटफिल्टर मेलिंग लिस्ट के इस पोस्ट के अनुसार , ipset हैश आकार के लिए मौजूदा 2015 फॉर्मूला है, H * 40byte + (N/4 + N%4) * 4 * element sizeजो 1.5M स्लॉट हैश में 1M पते के लिए लगभग 64MB का आता है। Apache / berkdb समाधान का उपयोग करके डिस्क पर डेटा संग्रहीत किया जाता है और केवल सक्रिय पतों के पृष्ठों को लोड करता है।

— एम कॉनराड

Answer 3

मैंने खुद इसका परीक्षण नहीं किया है, लेकिन जब मैंने आपकी समस्या का वर्णन सुना तो मैंने तुरंत सोचा " pf" (जैसा कि ओपनबीएसडी से)।

pfपता तालिकाओं की अवधारणा है जो सिर्फ वही हो सकती है जो आप खोज रहे हैं।

मेरे द्वारा किए गए कुछ बहुत ही सरसरी शोध के अनुसार , ऐसा लगता है कि यह क्षमता से बेहतर पैमाने पर है ipset। रनटाइम विकल्पों पर पीएफ एफएक्यू के अध्याय के अनुसार , ट्यूनिंग के बिना बॉक्स के बाहर, पीएफ डिफ़ॉल्ट रूप से सभी तालिकाओं में कुल 200,000 प्रविष्टियों के साथ कुल 1,000 तालिकाओं का समर्थन करता है। (100,000 अगर सिस्टम में <100MB भौतिक मेमोरी है)। यह मुझे विश्वास दिलाता है कि कम से कम यह देखने की कोशिश करने पर विचार करने के लायक है कि क्या यह किसी भी तरह के उपयोगी स्तर पर काम करता है।

बेशक, मैं मान रहा हूँ कि आप लिनक्स पर अपने सर्वर चला रहे हैं, इसलिए आपके पास एक अलग फ़ायरवॉल बॉक्स होना चाहिए जो pf के साथ कुछ OS चला रहा हो (जैसे OpenBSD या FreeBSD)। आप किसी भी प्रकार के स्टेटफुल पैकेट फ़िल्टरिंग को पूरा करके थ्रूपुट को बेहतर बनाने में सक्षम हो सकते हैं।

Comments

ग्राहक के सर्वर आर्किटेक्चर को बीएसडी में बदलना वास्तव में एक विकल्प नहीं है। बॉक्स से बाहर कम से कम, हालांकि सोच।

— tylerl

आपको पूरे सर्वर आर्किटेक्चर को बीएसडी में नहीं बदलना होगा, असली सर्वर के सामने फायरवॉल बनाने के लिए पर्याप्त होगा। (एक वीएम में करने के लिए काफी आसान है।)

— प्रति वॉन ज़्वीबर्गबर्ग 5

Answer 4

क्या आपने FIB_HASH के बजाय FIB_TRIE का उपयोग करके जांच की है।

आपके उपसर्गों की संख्या के लिए FIB_TRIE को अधिक बेहतर पैमाने पर रखना चाहिए। ((32s null मार्ग अभी भी उपसर्ग हैं, बस बहुत विशिष्ट)

आपको इसका उपयोग करने के लिए अपने स्वयं के कर्नेल को संकलित करने की आवश्यकता हो सकती है, लेकिन यह मदद करता है।

FIB_TRIE नोट्स

Answer 5

पोस्टीरिटी के लिए: ipsetडॉक्स के अनुसार सेट का डिफ़ॉल्ट आकार 65536 है, इसे विकल्पों द्वारा बदला जा सकता है।

maxelem यह पैरामीटर सभी हैश प्रकार सेट के कमांड के लिए मान्य है। यह उन तत्वों की अधिकतम संख्या को परिभाषित करता है जिन्हें सेट में संग्रहीत किया जा सकता है, डिफ़ॉल्ट 65536। उदाहरण:ipset create test hash:ip maxelem 2048.

मैं इसे यहाँ डाल दिया क्योंकि मैं अभी तक टिप्पणी नहीं कर सकता।

Answer 6

भविष्य में इस समस्या से जूझने वाले किसी व्यक्ति के लिए कुछ उपयोगी नोट्स:

सबसे पहले, किसी भी ट्रैफ़िक का विश्लेषण न करें जिसकी आपको आवश्यकता नहीं है। यदि आप टीसीपी ट्रैफ़िक को रोक रहे हैं, उदाहरण के लिए, केवल SYN पैकेट को फ़िल्टर करें, इस तरह आप केवल कनेक्शन के अनुसार एक बार फ़िल्टर को हिट करते हैं। -m stateयदि आप चाहें तो उपयोग कर सकते हैं, लेकिन कनेक्शन ट्रैकिंग का अपना ओवरहेड है जिसे आप चाहते हैं कि प्रदर्शन एक समस्या हो।

दूसरा, iptables में एक लाख नियम डालने में लंबा समय लगता है: कई मिनट। यदि आपको कई संस्थाओं को ट्रैक करने की आवश्यकता है, तो आप शायद इसे नेटफ्लिटर से बाहर रखेंगे। नियमों के सरासर आकार में फर्क पड़ता है।

तीसरा, लक्ष्य रैखिक स्कैन से बचने के लिए है; लेकिन दुर्भाग्य से, iptables और iproute2 दोनों स्वाभाविक रूप से रैखिक हैं। आप अपने नियमों को बाइनरी-ट्री-स्टाइल को बड़ी संख्या में श्रृंखलाओं में विभाजित कर सकते हैं, जो आपके द्वारा परामर्श किए जाने वाले नियमों की संख्या को सीमित करता है, लेकिन फिर भी, इस आकार की समस्या के लिए iptables अच्छी तरह से अनुकूल नहीं है। यह काम करेगा , लेकिन यह मूल्यवान संसाधनों की बर्बादी है।

चौथा, और सबसे महत्वपूर्ण बात, अपने कार्यभार को उपयोगकर्ताओं के लिए धकेलना एक बुरा विचार नहीं है। यह आपको अपना खुद का तंग कोड लिखने या ऑफ-द-शेल्फ समाधान का उपयोग करने की अनुमति देता है जो आपकी समस्या सेट पर ट्यून किया गया है। इस समस्या का मेरा स्वयं का समाधान, जैसा कि उल्लेख किया गया है, Apache के mod_rewrite सिस्टम के माध्यम से ट्रिगर BDB लुकअप का उपयोग करना था। इसमें प्रति सत्र केवल एक लुकअप को ट्रिगर करने का अतिरिक्त लाभ था, और केवल एक वैध अनुरोध प्रस्तुत किए जाने के बाद। इस मामले में, प्रदर्शन बेहद तेज था और ब्लॉकलिस्ट की लागत लगभग नगण्य थी।

आप -j QUEUEके साथ संयोजन के रूप में लक्ष्य का उपयोग करके iptables के साथ इसी तरह के उपयोगकर्ताओं के हेरफेर कर सकते हैं libnetfilter_queue। यह उपकरण शक्तिशाली, सरल और खराब दस्तावेज है। मैं आपको अधिक से अधिक स्रोतों से पढ़ने की सलाह दूंगा जितना कि आप पा सकते हैं, क्योंकि वेब पर बहुत सारी दिलचस्प सामग्री बिखरी हुई है जो किसी भी आधिकारिक दस्तावेज का हिस्सा नहीं है।