फ़ायरवॉल के लिए 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-घंटे का समयखंड सक्रिय होने के पहले 24 घंटों से अलग है, इसलिए कुल संख्याएँ सीधे तुलनीय नहीं हैं।

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

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

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

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

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

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

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

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

फ़ायरवॉल के लिए Threat Feed की तुलना

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

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

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

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

ये ग्यारह विकल्प लोकप्रियता रैंकिंग नहीं हैं। हमारे अनुभव के आधार पर Cybora पहले है।

Cybora

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

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

CrowdSec Blocklists

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

GreyNoise

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

Q-Feeds

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

स्रोतों की संख्या अकेले इन हिट का कारण नहीं बताती। हर IP का स्रोत और मूल्यांकन जाने बिना कारण निश्चित नहीं हो सका। ग्राहकों पर व्यापक ब्लॉकिंग के लिए अनुमानित अपवाद व सपोर्ट का काम हमें ज़्यादा लगा। निगरानी या जाँच में Q-Feeds फिर भी उपयोगी हो सकता है।

Spamhaus DROP

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

ThreatFox

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

URLhaus

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

DShield

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

FireHOL IP Lists

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

AbuseIPDB

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

IPsum

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 नियम उसी पते पर अलग साइट नहीं पहचानता। हम ऐसे मामले अपवाद प्रबंधन में गिनते हैं: अनुमति संभव हो तो आवश्यक सेवा और उपयोगकर्ताओं तक सीमित रखें, फिर दोबारा जाँचें। अहम बात केवल प्रविष्टि का सही होना नहीं, बल्कि सीमित परिचालन बोझ के साथ सुरक्षित ब्लॉकिंग है।

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

हमारा माप IPv4 का है। IPv6 से भी उपलब्ध सेवाओं को अलग सुरक्षा चाहिए; IPv4 सूची उनके कनेक्शन फ़िल्टर नहीं करती।

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

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