फ़ायरवॉल के लिए Threat Feed: प्रभाव, सीमाएँ और प्रदाताओं की तुलना

इंटरनेट पर बहुत-से सिस्टम सार्वजनिक IP पते लगातार स्कैन करते हैं। वे खुले पोर्ट, लॉगिन पेज, VPN पोर्टल, जाने-पहचाने वेब ऐप्लिकेशन और कमज़ोर सेवाएँ खोजते हैं। इनमें सुरक्षा शोधकर्ताओं और इंटरनेट-सर्च सेवाओं के सिस्टम भी हैं, और बॉट व हमलावर भी।

WAF या DNAT के ज़रिए कोई सेवा उपलब्ध कराएँ, या मेल गेटवे तथा सार्वजनिक लॉगिन चलाएँ, तो वह कभी न कभी इन स्कैन में दिखाई देगी। सार्वजनिक IP होना अपने-आप में सेंध लगने का प्रमाण नहीं है। लेकिन सेवा के जवाब देते ही यह पृष्ठभूमि शोर फ़ायरवॉल, IPS, WAF, सर्वर, ऐप्लिकेशन और लॉगिंग सिस्टम के लिए वास्तविक काम बन जाता है।

सिक्योरिटी इंजीनियर के रूप में यह मेरे रोज़मर्रा के काम का हिस्सा है। आम तौर पर कोई एक नाटकीय हमला नहीं होता, बल्कि पोर्ट स्कैन, लॉगिन प्रयास, क्रॉलर और एक्सप्लॉइट-जाँच का लगातार मिश्रण होता है। हाल में मैं एक ऐसे मामले के विश्लेषण में शामिल था जिसका पैमाना हमारी टीम के लिए भी उल्लेखनीय था। 10 Gbit/s अपलिंक और पर्याप्त क्षमता वाले डेटा सेंटर के फ़ायरवॉल पर सीमा के करीब लोड दिख रहा था। लिंक उपयोग अधिक था, प्रबंधन इंटरफ़ेस धीमा लग रहा था और सार्वजनिक सेवाएँ लगातार नए इवेंट पैदा कर रही थीं।

हमने ट्रैफ़िक की दिशा, गंतव्य, पोर्ट, समय और बार-बार आने वाले स्रोत IP देखे। स्वचालित अनुरोध उन्हीं वेब, मेल और लॉगिन सेवाओं को बार-बार निशाना बना रहे थे। प्रोसेसिंग का खर्च केवल डेटा की मात्रा से तय नहीं होता: पैकेट गिराना, TLS हैंडशेक करना और ऐप्लिकेशन पर जटिल अनुरोध चलाना अलग-अलग काम हैं।

हमने ग्राहक को बताया कि गतिविधि का बड़ा हिस्सा बॉट और स्कैन ट्रैफ़िक है। समझाया कि इस बिंदु पर Threat Feed क्या कर सकता है, क्या नहीं कर सकता, और उचित लाइसेंस की कीमत लगभग 350 अमेरिकी डॉलर सालाना है। मंज़ूरी मिलते ही कुछ क्लिक और कुछ मिनटों में सूची फ़ायरवॉल पर लगा दी।

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

नतीजे, आँकड़ों में

माप उत्पादन वातावरण के फ़ायरवॉल से लिए गए। IP Feed 1 सितंबर 2026 को 10:01:05 बजे प्रभावी हुआ और पहला हिट कुछ सेकंड बाद आया। 2 सितंबर को 20:30 CEST तक 516,959 ब्लॉक इवेंट दर्ज हुए।

पूरी अवधि में औसत 249.9 इवेंट प्रति मिनट या 4.17 प्रति सेकंड था: हर 0.24 सेकंड में एक ब्लॉक। सबसे व्यस्त मिनट में 775 इवेंट आए। चरम दर 107 इवेंट प्रति सेकंड थी, लगातार दो सेकंड तक।

मैं जानबूझकर इन्हें ब्लॉक इवेंट, हिट या कनेक्शन प्रयास कहता हूँ। 516,959 इवेंट का मतलब 516,959 स्वतंत्र, इंसानों द्वारा निर्देशित हमले नहीं है। एक स्कैनर बार-बार उसी सेवा तक पहुँच सकता है और बॉट तेज़ी से कई पोर्ट जाँच सकता है।

कौन आ रहा था?

पूरी 34 घंटे 29 मिनट की अवधि में 516,727 इवेंट आने वाले ट्रैफ़िक के थे। केवल 232 रोके गए बाहर जाने वाले कनेक्शन से संबंधित थे। इसलिए इस वातावरण में Feed की 99.955% गतिविधि इंटरनेट स्रोतों से जुड़ी थी।

सूची में मौजूद 10,518 अलग IP दिखाई दिए। उस समय Feed में 220,000 IPv4 संकेतक थे; लगभग 34 घंटों में इस एक फ़ायरवॉल पर सूची के करीब 4.8% IP प्रासंगिक हुए। सबसे सक्रिय IP ने 4,141 इवेंट दिए, शीर्ष दस ने मिलकर लगभग 31,500, जबकि 767 IP केवल एक बार दिखे। 4.8% सूची के आकार से तुलना है, पहचान-दर नहीं। सूची बदलती रहती है और अज्ञात हमलावर इस गिनती में नहीं आते।

पोर्ट विश्लेषण लगभग 369,000 विस्तृत इवेंट वाले चलते हुए 24-घंटे के समयखंड पर आधारित है:

लगभग 56% इवेंट वेब पोर्ट और 40% मेल पोर्ट की ओर थे, जो इस साइट की सेवाओं से मेल खाता है। विस्तृत समयखंड में 27 आंतरिक गंतव्य सिस्टम थे। सेवा के नाम गंतव्य पोर्ट से अनुमानित हैं, सफल प्रोटोकॉल विश्लेषण से सिद्ध नहीं। यह चलता हुआ समयखंड सक्रिय होने के पहले 24 घंटों से भी अलग है, इसलिए कुल संख्याओं की सीधी तुलना सही नहीं होगी।

बाहर जाने वाले 232 हिट कम थे, लेकिन उनकी जाँच ज़रूरी है: दस आंतरिक सिस्टम ने सूचीबद्ध 17 गंतव्य IP से संपर्क करने की कोशिश की। हिट अपने-आप में संक्रमण साबित नहीं करता। कारण मैलवेयर, तृतीय-पक्ष सामग्री, पुरानी प्रविष्टि या पुनः आवंटित IP पर वैध सेवा भी हो सकती है।

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

इस मामले में स्वचालित अनुरोध पहले वास्तव में वेब और ऐप सर्वर तक पहुँच रहे थे। उन्हें अनुरोध संभालना पड़ता था, उदाहरण के लिए अस्तित्वहीन पथ पर त्रुटि जवाब देना। जल्दी IP ब्लॉक करने से संबंधित अनुरोधों पर वह अगला काम बच गया। सूची में मिलान करने की अपनी लागत भी है; लाभ आगे की प्रोसेसिंग बचने से आता है। WAF ट्रैफ़िक और फ़ायरवॉल पर होस्ट की गई सेवाओं में लागू होने का क्रम प्लेटफ़ॉर्म व कॉन्फ़िगरेशन पर निर्भर है। पहला पैकेट फिर भी WAN इंटरफ़ेस तक आता है; स्थानीय ब्लॉक बड़े DDoS के लिए अपस्ट्रीम सुरक्षा का विकल्प नहीं है।

Threat Feed वास्तव में कैसे काम करता है

साधारण फ़ायरवॉल Feed HTTPS पर मिलने वाली टेक्स्ट फ़ाइल भी हो सकती है। कई प्रदाता IP के साथ डोमेन और URL भी देते हैं। हमारे अधिकतर फ़ायरवॉल मामलों में हम मुख्यतः IP इस्तेमाल करते हैं, क्योंकि जल्दी ब्लॉक करने में यही सबसे उपयोगी और प्रभावशाली जानकारी है। फ़ायरवॉल निर्धारित अंतराल पर संकेतक अपडेट करता है और सेटिंग के अनुसार मिलते ट्रैफ़िक को लॉग या ब्लॉक करता है।

विश्वसनीयता प्रदाता के सत्यापन और रखरखाव पर निर्भर है:

• व्यवहार दुर्भावनापूर्ण था या केवल असामान्य?
• अवलोकन कितना नया है?
• क्या स्वतंत्र स्रोत पुष्टि करते हैं?
• पुराना संकेतक कब हटाया जाएगा?

लंबी ब्लॉकलिस्ट अपने-आप अच्छी Threat Intelligence नहीं बनती। ताज़गी, सटीकता और नियमित सफ़ाई अहम हैं। क्लाउड, होस्टिंग और ISP के बदलते IP फिर वैध उपयोग में आ सकते हैं। दूसरी ओर बहुत छोटी सूची दैनिक स्कैन ट्रैफ़िक को कम पकड़ सकती है।

फ़ायरवॉल के लिए Threat Feed

मैं जवाब अंत तक छिपाना नहीं चाहता: आज मेरे कई सहकर्मी और मैं Cybora प्रदाता का Feed इस्तेमाल करते हैं। अपने क्लाउड सर्वरों पर सार्वजनिक सेवाओं की सुरक्षा के लिए भी मैं इसे निजी तौर पर लगाता हूँ। यह फैसला वास्तविक वातावरण में तुलना पर आधारित है, उत्पाद प्रदर्शन पर नहीं।

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

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

दोहराए इवेंट साथ देखकर विश्लेषण करने चाहिए, ताकि एक सक्रिय स्कैनर परिणाम पर हावी न हो। Feed द्वारा रुकने वाले वैध कनेक्शन भी उतने ही महत्वपूर्ण हैं। सही रूप से ख़तरनाक माने गए IP से भी संचालन में गलत ब्लॉक हो सकता है।

यह दैनिक उत्पादन उपयोग की तुलना है, स्वतंत्र रूप से दोहराया जा सकने वाला प्रयोगशाला बेंचमार्क नहीं। मूल्यांकन का क्रम, सूची में ओवरलैप और दूसरे सक्रिय सुरक्षा नियंत्रण Monitor लॉग बदल सकते हैं। लॉग में किसी IP का न दिखना अकेले पहचान की कमी नहीं साबित करता। स्वतंत्र बेंचमार्क के लिए समयांकित सूची-स्नैपशॉट, सेटिंग और पुष्टि किए सकारात्मक व नकारात्मक उदाहरण चाहिए; पूरा तुलनात्मक डेटा यहाँ प्रकाशित नहीं है।

ये ग्यारह विकल्प संपादकीय चयन हैं, लोकप्रियता की डेटा-समर्थित रैंकिंग नहीं। AbuseIPDB और IPsum दस्तावेज़ों के आधार पर शामिल हैं; इनके प्रत्यक्ष परीक्षण नतीजे दावा नहीं किए जाते। Cybora हमारी अनुभूति के कारण पहले है, बाकी क्रम मापी हुई रैंकिंग नहीं। अन्य उत्पादों की जानकारी 8 सितंबर 2026 और Q-Feeds की 28 सितंबर को जाँची गई थी।

Cybora ने हमारे वातावरण में कवरेज, ताज़गी, उपयोगी हिट, कम गलत-ब्लॉक काम, एकीकरण, सहयोग और कीमत का सबसे अच्छा संतुलन दिया। प्रवेश योजनाएँ किफ़ायती हैं और Ultimate का 15-मिनट अपडेट बड़े, खुले ढाँचे में काम आता है। प्रकाशन अंतराल से पूर्व की पहचान व मूल्यांकन का समय नहीं पता चलता; फ़ायरवॉल का डाउनलोड और आयात भी समय लेते हैं। केस डेटा में दो HTTP 429 जवाब दर्ज हैं। स्थानीय सूची चालू रही और अगला डाउनलोड सफल हुआ। इसलिए सूची की उम्र और असफल अपडेट की निगरानी ज़रूरी है।

CrowdSec Blocklists मुक्त स्रोत Security Engine, समुदाय संकेत और फ़ायरवॉल तक पहुँचाई जा सकने वाली चयनित सूचियाँ मिलाते हैं। उत्पादन वातावरण की टेलीमेट्री और विशेष सूचियाँ ताकत हैं; किसी CMS, प्रॉक्सी या खास CVE की सूची अपने-आप सार्वभौमिक परिधि Feed नहीं होती।

GreyNoise फ़ायरवॉल के लिए क्वेरी-आधारित IP ब्लॉकलिस्ट भी देता है। GNQL हाल में सक्रिय दुर्भावनापूर्ण स्रोत या CVE-संबंधी गतिविधि चुन सकता है। चयन-मापदंड नियंत्रित करने वाली टीमों के लिए अच्छा विकल्प है, लेकिन क्वेरी डिज़ाइन, डेटा मॉड्यूल की अनुमति और परिणामों की समीक्षा चाहिए। इसे केवल लॉग समृद्ध करने का साधन कहना अधूरा है।

Q-Feeds के अनुसार वह 2,500 से अधिक वाणिज्यिक, खुले और सरकारी स्रोत मिलाकर IP, डोमेन और URL Feed देता है तथा गुणवत्ता और गलत-सकारात्मक जाँच करता है। हमारा ब्लॉकिंग अनुभव कम अच्छा रहा: पहले घंटे में ही कई वैध कनेक्शन रुक गए। प्रभावित ट्रैफ़िक की जाँच कर हमने जाँचे गए मामलों को गलत ब्लॉक पाया। सपोर्ट ने रिपोर्ट की गई प्रविष्टियाँ काफ़ी जल्दी हटाईं, पर जाँच और रिपोर्ट का बोझ इतना रहा कि बाद में हमने हर अगला मामला व्यवस्थित रूप से भेजना बंद कर दिया। स्रोतों की संख्या अकेले कारण नहीं बताती। हर IP की उत्पत्ति, शामिल करने का कारण और पुनर्मूल्यांकन जाने बिना मूल कारण विश्वसनीय रूप से तय नहीं किया जा सकता। हमारे ग्राहकों के फ़ायरवॉल पर व्यापक ब्लॉकिंग के लिए अपवाद और सपोर्ट का बोझ अधिक था; मॉनिटरिंग या जाँच में Feed फिर भी उपयोगी हो सकता है।

Spamhaus DROP विशेष रूप से ख़तरनाक नेटवर्क की संयमित सूची है, किनारे पर फ़िल्टरिंग या रूटिंग फैसलों के लिए। ऊँची प्रवेश-सीमा इसे भरोसेमंद बनाती है, पर यह हर अल्पकालिक स्कैनर को पकड़ने का प्रयास नहीं करती।

ThreatFox, abuse.ch और Spamhaus का स्रोत, मैलवेयर-संबंधी संकेतकों और कमांड-एंड-कंट्रोल पर केंद्रित है। मैलवेयर पहचान व Threat Hunting में अच्छा है, पर स्कैनर और ब्रूट फ़ोर्स वाले सामान्य Feed से अधिक संकीर्ण है।

URLhaus, abuse.ch की सेवा, मैलवेयर पहुँचाने वाले URL जमा करती है। DNS फ़िल्टर, प्रॉक्सी, सुरक्षित वेब गेटवे और विश्लेषण में अधिक उपयोगी; केवल IP ब्लॉकिंग में विशेष घटक है। API के लिए Auth-Key चाहिए, और सामुदायिक पहुँच का मतलब बिना सीमा के मुफ़्त व्यावसायिक उपयोग नहीं। उचित-उपयोग की शर्तें जाँचें।

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

FireHOL IP Lists कई सार्वजनिक सूचियाँ इकट्ठा कर आकार, अपडेट, उम्र और ओवरलैप की तुलना में मदद करता है। एग्रीगेटर अपने स्रोतों की कमज़ोरियाँ भी लेता है, और बार-बार प्रकाशित पुरानी प्रविष्टियाँ ज़रूरत से ज़्यादा टिक सकती हैं।

AbuseIPDB रिपोर्ट-आधारित IP प्रतिष्ठा और बदलने योग्य भरोसा-सीमा वाली टेक्स्ट ब्लैकलिस्ट देता है। ऊँचा स्कोर यह साबित नहीं करता कि IP से हर मौजूदा कनेक्शन दुर्भावनापूर्ण है। रिपोर्ट की उम्र, साझा पते और योजना के अनुरोध-सीमा मायने रखते हैं।

IPsum प्रतिदिन 30 से अधिक सार्वजनिक सूचियाँ जोड़ता है और स्रोत-सूची सहमति के आधार पर स्तर देता है। यह पारदर्शी है, लेकिन तीन सूचियाँ एक-दूसरे का डेटा दोहरा सकती हैं; वह तीन स्वतंत्र अवलोकन नहीं होंगे। दैनिक अपडेट प्रतिक्रिया सीमित करता है; इसकी अपनी स्वतंत्र टेलीमेट्री नहीं है।

मुफ़्त होना ख़राब होने का प्रमाण नहीं, और वाणिज्यिक होना अच्छा होने का नहीं। बहुत-से सार्वजनिक Feed अपने विशेष क्षेत्र में उत्कृष्ट हैं। परिधि पर व्यापक ब्लॉकिंग के लिए हमारे अनुभव में वे लगातार सँभाले जा रहे सामान्य Feed का पूरा विकल्प नहीं, बल्कि विशेष उपयोग के हिस्से हैं।

हमारी तुलना में Cybora पहले क्यों आया

पारदर्शिता के लिए: यह मेरा निजी ब्लॉग है और मुझे व्यक्तिगत कमीशन नहीं मिलता। मगर मेरी कंपनी Cybora की पुनर्विक्रेता है; वह रियायती लाइसेंस खरीदकर मार्जिन पर बेचती है। मेरी सिफ़ारिश समझते समय यह वाणिज्यिक रिश्ता जानना ज़रूरी है। हमारा चुनाव बताए गए परीक्षण अनुभव से निकला, पुनर्विक्रेता शर्तों से नहीं।

डेटा सेंटर में वास्तव में Cybora Feed था। हमने सालाना 349 डॉलर के Premium और प्रति घंटे अपडेट से शुरुआत की। सार्वजनिक उत्पाद-विवरण के अनुसार Cybora OSINT, वाणिज्यिक स्रोत, हनीपॉट, सेंसर और वास्तविक फ़ायरवॉल टेलीमेट्री मिलाता है। संकेतकों को नवीनता, विश्वास और स्रोत-सहमति के आधार पर आँका, दोहराव हटाया, अनुमति तथा अपवाद नियमों से जाँचा और HTTPS सूची के रूप में प्रकाशित किया जाता है। परीक्षण के समय Premium में 220,000 IPv4, 45,000 डोमेन और 25,000 URL संकेतक थे। मापे गए फ़ायरवॉल पर IPv4 Block तथा डोमेन शुरू में Monitor पर थे।

एक सप्ताह बाद ग्राहक Ultimate पर गया। उस समय उसमें 300,000 से अधिक IPv4 और 100,000 से अधिक डोमेन तथा 100,000 से अधिक URL थे, हर 15 मिनट अपडेट के साथ। ग्राहक ने आगे भी प्रदर्शन सुधार बताया, लेकिन ऊपर की माप-खिड़की इस बदलाव से पहले समाप्त होती है, इसलिए Ultimate का अतिरिक्त लाभ साबित नहीं करती। इस विशिष्ट मामले में ऊँची योजना भी बड़े फ़ायरवॉल हार्डवेयर और उसके लाइसेंस से काफ़ी सस्ती थी। यह हर छोटे कार्यालय के लिए डिफ़ॉल्ट सलाह नहीं; अनेक सार्वजनिक सेवाओं वाले इस डेटा सेंटर में अतिरिक्त कवरेज उचित था।

वास्तविक उत्पादन नेटवर्क, कृत्रिम सेंसर से अलग सेवाएँ और ट्रैफ़िक दिखाते हैं। इससे अपने-आप श्रेष्ठता सिद्ध नहीं होती; दूसरे प्रदाता भी उत्पादन टेलीमेट्री लेते हैं। हमें कई बार ऐसे IP मिले जो जाँच के क्षण Cybora में थे, लेकिन जाँची गई दूसरी सूचियों में नहीं। उपलब्ध फ़ायरवॉल व ऐप लॉग में असामान्य अनुरोध क्रम, URL पथ और स्वचालित लॉगिन या फ़ॉर्म प्रयास दिखे। शुरुआती IP ड्रॉप स्वयं HTTP पथ नहीं दिखा सकता; उसका प्रमाण Monitor अवधि या मिलान योग्य दूसरे लॉग से आता है। बहुत अनुरोध होना अकेले हमला सिद्ध नहीं करता।

एक सपोर्ट मामला IP ब्लॉकिंग की सीमा दिखाता है। ग्राहक की आवश्यक वेबसाइट ऐसे साझा होस्टिंग IP पर थी जो सूची में था। जाँच से होस्टिंग ढाँचे का संक्रमित होना पुष्ट हुआ। IP को चिन्हित करना उचित था, मगर वैध साइट भी रुक गई: परिचालन गलत ब्लॉक। IP नियम एक ही पते पर वेबसाइटें अलग नहीं कर सकता। संभव हो तो अपवाद आवश्यक सेवा और उपयोगकर्ताओं तक सीमित रखें और बाद में पुनः जाँचें। पूरा IP अनुमति देने से अन्य सामग्री भी खुल जाएगी। सपोर्ट से एक संपर्क उसकी सामान्य प्रतिक्रिया गति नहीं बताता।

तकनीकी परिणाम बहुत सरल है: HTTPS पता और सूची, जिसे समर्थित प्लेटफ़ॉर्म पर मिनटों में लगाया जा सकता है। जिम्मेदारी से ब्लॉकिंग लागू करने के लिए अपने ट्रैफ़िक पर सत्यापन फिर भी ज़रूरी है।

STIX और TAXII ब्लॉकलिस्ट नहीं हैं

STIX (Structured Threat Information Expression) संरचित डेटा मॉडल है। यह IP के अलावा मैलवेयर, अभियान, हमलावर, तकनीक, अवलोकन, समय, विश्वास स्तर और संबंध बता सकता है। इससे संकेतक क्यों महत्वपूर्ण है, यह संदर्भ मिलता है।

TAXII (Trusted Automated Exchange of Intelligence Information) HTTPS पर साइबर-ख़तरे की जानकारी बाँटने का प्रोटोकॉल है। सरल शब्दों में STIX सामग्री और TAXII उसका परिवहन या API बताता है।

यह संदर्भ Threat Intelligence प्लेटफ़ॉर्म, SIEM और SOC के लिए उपयोगी है। तेज़ IP मिलान के लिए फ़ायरवॉल को अक्सर उससे निकाले गए पतों का सेट चाहिए। वह संकेतक समय-समय पर डाउनलोड करके स्थानीय सेट से ट्रैफ़िक मिलाता है; हर पैकेट पर STIX/TAXII दोबारा नहीं पढ़ता। TXT सूची कम जानकारी रखती है, मगर परिधि पर लागू करना सरल है।

Threat Feed क्या नहीं कर सकता

यह माप और IP कवरेज IPv4 का है; इससे IPv6 सुरक्षा पर कोई निष्कर्ष नहीं निकलता। IPv6 पर भी सेवा प्रकाशित है तो उसकी फ़िल्टरिंग अलग से जाँचें।

Feed ज्ञात संकेतक ब्लॉक करता है। यह साफ़ IP से आए नए हमलावर, वैध क्लाउड पर दुर्भावनापूर्ण ग्राहक, CDN के पीछे छिपा हमला या आपके ऐप की कमजोरी अपने-आप नहीं पहचानता। IP बदलते हैं, डोमेन बनते हैं और संक्रमित सिस्टम साफ़ या पुनः आवंटित हो सकते हैं।

इसलिए यह पैचिंग, MFA, IPS, WAF, EDR, सही फ़ायरवॉल नीति और काम के लॉग का विकल्प नहीं। यह शुरुआती निर्णय की अतिरिक्त परत है जो DNAT, WAF, VPN और मेल के सामने ज्ञात शोर कम कर सकती है। नया Feed पहले निगरानी मोड में चलाएँ, अपवाद तैयार करें, फ़ायरवॉल की अपडेट तथा क्षमता-सीमाएँ जाँचें और गलत ब्लॉक के लिए प्रक्रिया तय करें।

मेरा निष्कर्ष

ये आँकड़े नहीं दिखाते कि Feed लाइसेंस जादुई रूप से 10 Gbit/s लिंक या बड़े फ़ायरवॉल की जगह ले सकता है। ये दिखाते हैं कि एक फ़ायरवॉल ने लगभग 34 घंटे में ज्ञात अवांछित स्रोतों से आधे मिलियन से अधिक कनेक्शन इवेंट जल्दी रोक दिए।

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

हमारी बारह-महीने की तुलना में इस उपयोग के लिए Cybora सबसे संतुलित सामान्य Feed था। CrowdSec, GreyNoise, Spamhaus, abuse.ch और दूसरे स्रोत भी मूल्यवान हैं, अक्सर अपने विशेषज्ञ क्षेत्र में बेहतर। सही प्रश्न “किसकी सूची सबसे लंबी है?” नहीं, बल्कि “मेरी सार्वजनिक सेवाओं के लिए कौन-सा डेटा नया, सटीक और सुरक्षित रूप से लागू करने योग्य है?” है।

फिर मिलेंगे,
Joe

अक्सर पूछे जाने वाले प्रश्न