Sophos Firewall v23: सुधार, सीमाएँ और खुले सवाल

मैं करीब दो सप्ताह से अपने होमलैब में Sophos Firewall v23 का परीक्षण कर रहा हूँ। पहली प्रतिक्रिया मिली-जुली है। नया नियम दृश्य मुझे पसंद है और REST API सही दिशा में कदम लगता है। लेकिन इंटरफ़ेस अब भी ऐसा लगता है जिसके अलग-अलग हिस्से अलग समय में बने हों। एक नई तालिका पूरे प्रशासन अनुभव को आधुनिक नहीं बना देती।

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

Sophos Firewall v23 अभी Early Access Program (EAP) में है। पिछले वर्षों के क्रम के आधार पर मुझे अंतिम संस्करण दिसंबर 2026 में आने की उम्मीद है। मैंने फ़र्मवेयर करीब दो सप्ताह अपने होमलैब में इस्तेमाल किया है, उत्पादन वातावरण में नहीं। उपयोगिता पर टिप्पणियाँ मेरे अपने अनुभव हैं; HA और WAF के प्रदर्शन आँकड़े Sophos के हैं।

नियम प्रबंधन: बेहतर फ़िल्टर हर समूह दृश्य की जगह नहीं लेता

नया नियम दृश्य उन बदलावों में है जो मुझे लैब में पसंद आए। लगातार तालिका, बदलने और स्थिर रखने योग्य कॉलम, खोज और फ़िल्टर उपयोगी हैं। गंतव्य, सेवाएँ और सुरक्षा प्रोफ़ाइल साथ दिखना, तुलना के लिए बार-बार नियम खोलने से बेहतर है। उपकरण की पहचान और HA स्थिति का लगातार दिखना भी काम का संदर्भ बनाए रखता है।

फिर भी समूहों पर आलोचना समझ में आती है। शुरुआती प्रतिक्रिया में पुराने संकुचित किए जा सकने वाले समूह नए दृश्य में नहीं मिलने की शिकायत है। बड़े नियम सेट में फ़िल्टर के बावजूद लंबी तालिका समझना मुश्किल हो सकता है। यह केवल पसंद का नहीं, सुरक्षित प्रशासन का मुद्दा है।

Sophos की नियम प्रबंधन पर अलग व्याख्या के अनुसार मौजूदा समूह और नियम क्रम बने रहते हैं। सदस्यता एक कॉलम में दिखती है और अभी दोनों दृश्य चुने जा सकते हैं। समूह हटाए नहीं गए हैं। प्रस्तुति बदली है। चर्चा में टैग आधारित संगठन भविष्य की संभावना है, वर्तमान बिल्ड का वादा नहीं।

मुझे नया दृश्य पसंद है, लेकिन बहुत बड़े सेट संभालने वालों की ज़रूरत भी समझता हूँ। हजारों नियमों में फ़िल्टर और प्रस्तुति से वास्तविक प्रभावी क्रम स्पष्ट रहना चाहिए। समूह वैश्विक क्रम से अलग स्वतंत्र सुरक्षा सीमा नहीं है।

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

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

WebAdmin में HTTP/2 स्वागत योग्य है, पर इन समस्याओं का समाधान नहीं। यह विशेषकर अधिक विलंब वाले कनेक्शन पर पेज संसाधनों का संचार बेहतर कर सकता है। इससे संचालन का तर्क नहीं बदलता और कॉन्फ़िगरेशन बदलने का समय अपने आप नहीं घटता। यहाँ नियंत्रित पहले-बाद का मापन नहीं है।

REST API: प्रगति का अर्थ सत्यापित किया जा सकने वाला कार्यप्रवाह

REST API मुझे v23 की उपयोगी दिशाओं में से एक लगती है। हर दोहराव वाले प्रशासन कार्य के लिए हाथ से क्लिक जरूरी नहीं। API keys, OpenAPI 3.0 और अंतर्निहित गाइड अपने उपकरणों का आधार देते हैं। कुंजी, समाप्ति और अनुमत IP होस्ट Administration > API access में संभाले जाते हैं।

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

API होना विश्वसनीय स्वचालन की गारंटी नहीं। अप्राप्य साइट विफल दिखनी चाहिए। पुनः प्रयास डुप्लिकेट ऑब्जेक्ट न बनाए और आंशिक विफलता दर्ज हो। मैं एकीकरण को इन मानकों पर जाँचूँगा।

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

पूर्ण कार्यक्षमता कवरेज अभी सवाल है। मौजूदा XML स्वचालन तभी बदलें जब उस बिल्ड की OpenAPI परिभाषा आवश्यक सभी संचालन बताती हो। Sophos WAF बदलावों के लिए अब भी XML API स्पष्ट करता है। दिशा सही है, लेकिन व्यवहारिक महत्व कवरेज, त्रुटि प्रबंधन और अनुमतियों में है।

WAF अधिक उपयोगी है, लेकिन क्षमता सीमित है

Web Application Firewall में साइट के पाथ प्रविष्टि स्तर पर क्रियाएँ मिलती हैं। एप्लिकेशन प्रकाशित करने में उपयोगी है और SG/UTM9 से कुछ अंतर कम होता है। चार क्रियाओं के सुरक्षा अर्थ अलग हैं:

Redirect क्लाइंट का गंतव्य बदलता है, भीतर बैकएंड नहीं। WebSocket अपवाद अतिरिक्त सुरक्षा भी नहीं है। सुरक्षित पोर्टल और WebSocket चैनल साथ हों तो तय करना चाहिए कहाँ क्या निरीक्षण हो। काम करता कनेक्शन निरीक्षण का प्रमाण नहीं है।

एक पाथ रूटिंग प्रविष्टि में अधिकतम 128 पाथ जोड़ सकते हैं। WAF नियम सीमा डिफ़ॉल्ट 100 है, जिसे 200 तक बढ़ा सकते हैं। गाइड के अनुसार पुराने नियम Protect डिफ़ॉल्ट क्रिया के साथ स्थानांतरित होते हैं। इंटरफ़ेस और XML API स्पष्ट रूप से समर्थित हैं; इसका अर्थ नए REST API में सभी WAF कार्यप्रवाह होना नहीं है।

Apache Event MPM भी बदलाव है। Sophos बेहतर worker उपयोग और समवर्ती अनुरोधों की सहनशीलता बताता है। घोषणा के करीब 800 समानांतर अनुरोध पुराने ढाँचे के संतृप्त हो सकने की परिस्थिति हैं, न सार्वभौमिक पुरानी सीमा, न नए throughput की गारंटी।

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

WebAdmin के HTTP/2 को WAF समर्थन न समझें। जुड़े Reddit संवाद में WAF HTTP/2 भविष्य की माँग है। उत्तर रुचि दिखाता है, वादा नहीं। मैं इसे v23 फ़ीचर या HTTP/3 की गारंटी नहीं लिखूँगा।

HA: 300 मिलीसेकंड का अर्थ निर्बाध एप्लिकेशन नहीं

HA बदलाव मुझे विशेष रूप से रुचिकर लगते हैं। Sophos peer विफलता पहचान अवधि चार सेकंड से 300 मिलीसेकंड बताता है, लगभग 13 गुना तेज पहचान।

आँकड़ा विफलता पहचान का है। यह कॉल, VPN या एप्लिकेशन के 300 मिलीसेकंड में ठीक होने की गारंटी नहीं। शेष नोड का संभालना, पड़ोसी उपकरणों का ट्रैफ़िक भेजना और पुराने सत्रों का व्यवहार भी असर डालते हैं। एक ping पर्याप्त तस्वीर नहीं देता।

निगरानी में SSD जैसे हार्डवेयर शामिल हैं। नोड HA लिंक का उत्तर देता रहे, फिर भी स्टोरेज समस्या हो सकती है। हार्डवेयर स्थिति को failover का आधार बनाना उचित है। स्वस्थ नोड पर संचालन जारी होना कारण जाँच और खराब भाग बदलने का विकल्प नहीं।

HA heartbeat को सामान्य डेटा से अलग मार्ग पर प्राथमिकता देना भी महत्वपूर्ण है। Sophos के अनुसार प्राथमिकता भार के साथ समायोजित होती है, ताकि देर से आए heartbeat को गलत विफलता न समझा जाए। गाइड छूटे heartbeat और अनचाहे failover में उल्लेखनीय कमी कहती है, पूर्ण प्रतिरक्षा नहीं।

वास्तुकला में बदलाव उचित हैं। भारी भार पर बेवजह बदलता क्लस्टर हो तो तेज पहचान पर्याप्त नहीं। उत्पादन स्वीकृति में दोनों पहलू जाँचने होंगे। मेरे लैब अनुभव न मापा HA अवरोध हैं, न उत्पादन भार में स्थिरता का प्रमाण।

DNS और पैच स्थिति: दो अलग भरोसे

DNS over HTTPS चुने resolver तक संचार एन्क्रिप्ट करता है। DNSSEC हस्ताक्षरित DNS डेटा की हस्ताक्षर श्रृंखला सत्यापित करता है। दोनों पूरक हैं। DoH अपने आप उत्तर की प्रामाणिकता नहीं बताता और DNSSEC प्रश्न छिपाता नहीं। Resolver प्रश्न जानता है और सभी ज़ोन हस्ताक्षरित नहीं होते।

Sophos अपने या सामान्य प्रदाता के साथ DoH तथा DNS Protection आसानी से सक्रिय करना बताता है। सभी क्लाइंट स्वतः उस मार्ग से नहीं जाते। ब्राउज़र का निजी DoH, आंतरिक resolver और निजी नामस्थान भी योजना माँगते हैं। मुझे अंदर और बाहर के नाम सही हल होने तथा फ़िल्टर और DNSSEC निर्णय समझने योग्य होने चाहिए।

Hotfix दृश्य कम आकर्षक, लेकिन उपयोगी है। Backup and Firmware में लागू सुरक्षा अपडेट के CVE, विवरण, दिनांक, गंभीरता और advisory लिंक दिखते हैं। गाइड Log Viewer, ईमेल और Central Firewall Reporting भी बताती है।

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

Sophos Fusion के आवर्ती फ़र्मवेयर कार्यक्रम में चरणबद्ध रोलआउट और उपकरणवार अपवाद हैं। प्रमुख संस्करण वैकल्पिक हैं। मैं परीक्षण समूह से शुरू करूँगा, जरूरी काम जाँचूँगा, फिर अगला समूह। स्वचालन मेहनत घटाता है, पुनर्प्राप्ति योजना नहीं बदलता।

DHCP, mDNS और रूटिंग की अपनी स्वीकृति जाँच चाहिए

DHCP नए Control Plane में जाता है। Sophos बेहतर leases, अधिक reservations, सेवा से पहले flood जाँच और ज्यादा स्क्रीन सेटिंग बताता है। यह सिर्फ सजावट नहीं। Lease, renewal, reservation और विशेष विकल्प महत्वपूर्ण हैं। वेबसाइट खुलना PXE या शायद ही restart होने वाले उपकरण की सही कॉन्फ़िगरेशन नहीं साबित करता।

mDNS reflector चुने VLAN या subnet के बीच सेवा खोज देता है, IPv4 और IPv6 के साथ। इंटरफ़ेस और सेवा चुन सकते हैं। यह आगे का डेटा कनेक्शन अपने आप अनुमति नहीं देता। प्रिंटर दिख सकता है, पर नियम न होने से छपाई नहीं। आसानी के लिए सब reflect करके अतिथि नेटवर्क को अंदर के सभी उपकरण नहीं दिखाने चाहिए। निषिद्ध व्यवहार भी जाँचना होगा।

FRR अपडेट और एकीकृत console मिलता है। BGP और static routes के BFD को standalone में प्रयोगात्मक बताया गया है। वह forwarding पाथ की विफलता पहचानता है, HA heartbeat नहीं। अभी मैं इसे उत्पादन निर्भरता नहीं बनाऊँगा।

IPv6 IPoE, IPIP/DS-Lite वाले 4in6 tunnels और VNE-सचेत DDNS कनेक्टिविटी बढ़ाते हैं, जापान के Xpass सहित। Endpoint तथा MTU/MSS बदलाव उस पद्धति वाले प्रदाता में उपयोगी हैं, सारे IPv6 मुद्दों का समाधान नहीं। IONOS Cloud में आधिकारिक image से Bring Your Own Image है, Marketplace प्रविष्टि नहीं और lifecycle हाथ से संभालना है।

पहचान: अपडेट सभी पूर्वशर्तें पूरी नहीं करता

Entra ID विस्तार Sophos Endpoint के साथ Synchronized User ID है, केवल पोर्टल लॉगिन का नया नाम नहीं। गाइड स्थानीय AD और Entra hybrid, UPN और sAMAccountName mapping तथा बताए Endpoint 2025.1 से Windows समर्थन कहती है। अकेला Entra पहचान नहीं देता। संस्करण, लाइसेंस और SSO सही होने चाहिए।

Google Workspace Captive Portal, VPN Portal, Sophos Connect और WebAdmin के लिए OpenID Connect IdP है, IdP द्वारा MFA सहित। दिए सेवा समूह के लिए एक IdP की सीमा है। Authentication और authorization अलग जाँचें हैं। वैध Google खाता गलती से प्रशासन अधिकार न पाए।

MFA enrollment QR ईमेल से भेज सकते हैं। नए इंस्टॉल में डिफ़ॉल्ट, पुराने और स्थानांतरित में portal तरीका बना रहता है। इस्तेमाल न हुआ कोड 24 घंटे बाद समाप्त होता है। उसमें authenticator secret है, इसलिए mailbox और फिर enrollment सुरक्षित रखें। केवल ईमेल भेजना सुरक्षित पहचान जाँच नहीं है।

साझा सर्वर पर SATC और XDR Sensor मौजूदा Endpoint या AV के साथ चल सकते हैं, एक IP वाले कई sessions पर उपयोगकर्ता नियम के लिए। पहले OS, लाइसेंस और खास third-party संयोजन जाँचें।

Chromebook extension Manifest V3 पर है और सभी समर्थित SFOS के लिए है। यह सिर्फ v23 अपडेट की वजह नहीं। साझा उपकरण पर logout या उपयोगकर्ता बदलने से mapping विश्वसनीय रूप से समाप्त होनी चाहिए।

AI और NDR: निर्णय दिखते रहने चाहिए

Sophos Fusion के Firewall Assistant का पहला चरण नियमों पर है: सेटिंग पढ़ना और सवालों का जवाब। स्पष्ट अपवाद नियम बनाना है, जो निष्क्रिय होकर सूची के अंत में जुड़ता है। समीक्षा और सक्रिय करना प्रशासक का काम है। गाइड कहती है उसकी डेटा पहुँच Fusion SSO से उस प्रशासक को दिखने वाली पहुँच जैसी है।

मुझे यह सीमा पसंद है। Draft में भी objects, services, users, सुरक्षा प्रोफ़ाइल और स्थान जाँचें। निष्क्रिय नियम भी सहेजी गई सेटिंग में बदलाव है। अच्छी भाषा सुरक्षा का प्रमाण नहीं।

Generative AI category और application filters Sophos AI Defense में अनुमत सेवा नियंत्रण का आधार हैं। Domain अनुमति से तय नहीं होता prompt में कौन सा डेटा जा सकता है। नेटवर्क नियंत्रण हर upload पूरा नहीं जाँचता और डेटा वर्गीकरण का विकल्प नहीं। अतिरिक्त सेवाएँ, लाइसेंस और क्षमताएँ अलग आँकें।

NDR Essentials और NDR Active Threat Intelligence में स्वतः isolation या लाल Heartbeat के बिना alerts हैं। दृश्यता तत्काल रोक से अलग होती है। इसका अर्थ सभी Active Threat Response क्रियाएँ बंद नहीं। बिना स्वचालित प्रतिक्रिया वाले alert के लिए जिम्मेदार और escalation मार्ग चाहिए।

छोटे बदलावों में ईमेल Content Control Lists को ID से संदर्भ और backend Web category परिभाषा की versioning है। अपडेट और restore में सुसंगति पर असर पड़ सकता है।

अपग्रेड से पहले migration

सबसे बाध्यकारी बदलाव AI नहीं: Sophos native eDirectory server प्रकार हटाता है। v23 authentication दस्तावेज़ के अनुसार पहले समर्थित प्रकार में migration और पुरानी setting हटानी होगी, नहीं तो upgrade विफल है।

यह वास्तविक migration परियोजना है। वैकल्पिक integration से login, automatic पहचान, group mapping और नियम सब सही होने का प्रमाण नहीं। Directory SSO में mapping अलग सत्यापित करें। मैं firmware से पहले पहचान बदलाव पूरा करूँगा ताकि बाद के दोष अलग किए जा सकें।

EAP1 भी सीमा है। समर्थन community forums से है। मेरे लिए recovery योजना वाला नियंत्रित परीक्षण उपयुक्त है। घोषणा मेरी महत्वपूर्ण infrastructure पर चलाने की मंजूरी नहीं।

शुरुआती प्रतिक्रियाएँ क्या बताती हैं

EAP1 feedback thread में नियम आलोचना के अलावा VMware report है। 22.0.1 से upgrade के बाद ping और SSH पहुँचते थे, लेकिन 30 मिनट बाद WebAdmin नहीं। Search index में बाद का उत्तर उसी उपयोगकर्ता से लगभग 40 मिनट बाद लौटने का बताता है।

यह अकेली रिपोर्ट है; मैंने कारण दोहराया नहीं। इसे सार्वभौमिक VMware दोष या सामान्य समय नहीं मानना चाहिए। यह management पहुँच, update window और recovery की याद दिलाती है। शुरुआती चर्चा बदलती है, आगे के उत्तर और विरोधी उदाहरण भी अहम हैं।

Reddit रिलीज़ चर्चा में WAF सवाल संचालकों की शेष अपेक्षाएँ बताते हैं। यह संदर्भ है, benchmark या पुष्टि हुए सारे दोषों की सूची नहीं।

करीब दो सप्ताह बाद मेरा पहला आकलन

v23 की दिशा अच्छी है, संपूर्ण अनुभव अभी सुसंगत नहीं। नया नियम दृश्य अच्छा कदम और REST API नियंत्रित स्वचालन की सही दिशा है। डिज़ाइन, काम और responsive व्यवहार में आधुनिक प्रशासन अपेक्षा से पीछे अंतर हैं।

HA, WAF और पैच पारदर्शिता AI नाम से तकनीकी रूप से ज्यादा महत्वपूर्ण हैं। घोषित सुधार देखने योग्य हैं, लेकिन शुरुआती परीक्षण भार तुलना या उत्पादन क्लस्टर अनुभव नहीं बदलता। निर्माता के आँकड़े और स्थानीय स्वीकृति अब भी जरूरी हैं।

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

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

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