Sophos Firewall v22 MR2: अपडेट या नया जोखिम?

Sophos Firewall v22 MR2 आ गया है। Build 546 को 14 जुलाई 2026 को जारी किया गया। इसमें सुरक्षा सुविधाओं, authentication बदलावों, certificate समायोजनों और 50 से अधिक bug fixes का सीमित, पर उपयोगी मिश्रण है।

कागज़ पर यह सामान्य Maintenance Release है। व्यवहार में इसमें ठीक वही संयोजन है जिसे देखकर अब मैं Sophos के मामले में दो बार जाँचता हूँ: IPS में नई detection logic, user mapping का बदला व्यवहार, नई certificate chains और साथ ही kernel crashes, HA समस्याओं, failsafe स्थितियों, VPN त्रुटियों और reporting failures की लंबी सूची।

यह केवल अच्छी खबर नहीं है। 50 से अधिक bugs ठीक होना बताता है कि Sophos सफाई कर रहा है, पर यह भी कि GA और MR1 में कितनी गंभीर समस्याएँ बची थीं। इसी firmware quality की आलोचना मैं पहले Sophos Firewall: कोई CVE नहीं, फिर भी bugs (v21.5 से v22) में कर चुका हूँ।

मैं MR2 को तुरंत अपनी एक Sophos Firewall पर स्थापित करूँगा—release के पहले दिन उस पर आँख मूँदकर भरोसा करने के लिए नहीं, बल्कि यह देखने के लिए कि Build 546 आखिर v22 श्रृंखला को स्थिर करता है या फिर ठीक किए गए bugs से अधिक नए bugs पैदा होते हैं। मेरी विशेष रुचि HA, logging, IPsec, WebAdmin response time, STAS और pattern updates के बाद की स्थिरता में है।

इसी release में Sophos एक अजीब विरोधाभास भी बनाता है। आधिकारिक firewall updates में अब Config Studio 2.6 को काफी जगह मिलती है। बाहरी browser tool को template merges, बेहतर search, multi-file diffs, migration analysis और hardware compatibility data मिलते हैं। मगर वास्तविक firewall interface की रोज़मर्रा की usability में फिर लगभग कुछ दिखाई नहीं देता।

इसलिए MR2 मुझे तकनीकी रूप से महत्वपूर्ण, लेकिन रणनीतिक रूप से निराशाजनक लगता है। Security engine को नई सुविधाएँ मिलती हैं, जबकि आधुनिक admin workflows फिर Config Studio में भेजे जा रहे हैं।

संक्षेप में सबसे महत्वपूर्ण बातें

SFOS 22.0 MR2 का build number 546 है और यह MR1 Build 490 के बाद आता है। Sophos release में मुख्यतः सात क्षेत्र बताता है:

• Post-Quantum Cryptography की पहचान और नियंत्रण
• generative AI applications का बेहतर categorization
• Manifest V3 वाली नई Chromebook User ID extension
• STAS का बदला default behavior
• SFOS 23.0 के लिए Novell eDirectory की अग्रिम end-of-life सूचना
• नई Let’s Encrypt trust chains और बेहतर email notifications
• कई नई analysis, migration और comparison सुविधाओं वाला Config Studio 2.6

इसके अतिरिक्त 50 से अधिक समस्याएँ ठीक की गई हैं। संचालन की दृष्टि से ये fixes कई नई सुविधाओं से अधिक महत्वपूर्ण हैं, क्योंकि इनमें kernel crashes, HA समस्याएँ, failsafe स्थितियाँ, VPN errors और reporting performance की समस्याएँ शामिल हैं।

मेरा संक्षिप्त आकलन:

• जो पहले से v22 GA या MR1 पर हैं और सूचीबद्ध समस्या से प्रभावित हैं, उनके पास MR2 का ठोस कारण है।
• स्थिर 21.5 installation चलाने वालों को केवल PQC या Config Studio के कारण जल्दबाज़ी नहीं करनी चाहिए।
• PQC signatures को पहले observation-only mode में रखें, तुरंत Drop पर नहीं।
• STAS environments को upgrade के बाद जाँचना होगा कि Identity Probe के दौरान unauthenticated traffic कैसे संभाला जाता है।
• HA, IPsec, WAF, mail और reporting installations को हरे status indicator देखने के बजाय वास्तविक functional tests चाहिए।
• Config Studio 2.6 उपयोगी है, पर आधुनिक SFOS WebAdmin interface का प्रमाण नहीं—बल्कि उलटा संकेत है।

Hardware सीमा महत्वपूर्ण है: SFOS 22.0 अब XG और SG hardware appliances को support नहीं करता। यह release XGS, virtual, software और supported cloud installations के लिए है। XG hardware चलाने वाले MR2 को सामान्य अगला firmware step नहीं मान सकते।

Post-Quantum Cryptography को पहचानना और नियंत्रित करना

तकनीकी रूप से सबसे रोचक सुविधा Post-Quantum Cryptography, यानी PQC, का नियंत्रण है। इसका अर्थ यह नहीं कि Sophos Firewall अचानक quantum computers से रक्षा करती है। यह आधुनिक cryptographic key-exchange methods से संबंधित है, जिन्हें भविष्य के शक्तिशाली quantum-computer attacks के विरुद्ध अधिक मजबूत बनाया गया है।

MR2 का केंद्र ML-KEM है। इसे 2024 में FIPS 203 के रूप में standardize किया गया और यह Module-Learning-with-Errors समस्या की अनुमानित कठिनाई पर आधारित है। NIST तीन parameter levels परिभाषित करता है:

• ML-KEM-512: सबसे छोटे keys और data volume के साथ,
• ML-KEM-768: मध्यम और आज विशेष रूप से प्रचलित variant,
• ML-KEM-1024: उच्च security level, पर अधिक computation और transmission overhead।

Sophos MR2 दस्तावेज़ों में केवल pure और hybrid ML-KEM आधारित key-exchange algorithms की सामान्य बात करता है। कौन-से parameter levels, TLS groups या signature IDs cover होते हैं, यह नहीं बताया गया। इसलिए यह मानना गलत होगा कि हर संभव ML-KEM variant पहचाना जाता है।

KEM तकनीकी रूप से क्या करता है

ML-KEM पूरे data stream को सीधे encrypt नहीं करता। एक Key Encapsulation Mechanism में सरल रूप से तीन operations होते हैं:

1. KeyGen एक Encapsulation Key और संबंधित Decapsulation Key बनाता है।
2. Encaps public Encapsulation Key से ciphertext object और shared secret बनाता है।
3. Decaps दूसरी ओर private Decapsulation Key से वही secret पुनः प्राप्त करता है।

Protocol इस shared secret से symmetric session keys बनाता है। वास्तविक payload को अभी भी AES या ChaCha20 जैसे तेज symmetric algorithms सुरक्षित रखते हैं। ML-KEM केवल खतरे में पड़े asymmetric key negotiation भाग को बदलता है, पूरी TLS data encryption को नहीं।

व्यावहारिक पृष्ठभूमि Harvest now, decrypt later है: attacker आज encrypted traffic record करके आशा कर सकता है कि वर्षों बाद cryptographically relevant quantum computer से उसे decrypt कर सके। अल्पकालिक data के लिए जोखिम कम है; health data, सरकारी communication, intellectual property या लंबे समय तक गोपनीय corporate data की protection period नई attack class आने के समय से अधिक हो सकती है।

Pure और hybrid एक जैसे नहीं हैं

Pure PQC key exchange में negotiation की security केवल नए post-quantum method पर निर्भर होती है। Hybrid exchange classical mechanism को ML-KEM से जोड़ता है। व्यावहारिक उदाहरण X25519MLKEM768 है: classical X25519 और ML-KEM-768 दोनों परिणामी secret में योगदान करते हैं।

अभी hybrid तरीका उचित है। ML-KEM में implementation error या mathematical weakness निकले तो classical component बचा रहता है। शक्तिशाली quantum computer classical elliptic curve तोड़ दे तो ML-KEM हिस्सा बचता है। Hybrid एक migration bridge है, अनावश्यक double encryption नहीं।

ध्यान रहे: X25519MLKEM768 वर्तमान TLS implementations का वास्तविक उदाहरण है। Sophos यह नहीं कहता कि MR2 केवल या मुख्यतः इसी group को पहचानता है।

IPS इसमें क्या करता है

Intrusion Prevention System को नई signatures मिलती हैं, जो pure और hybrid ML-KEM key exchange पहचान सकती हैं। Admins इनके लिए अपनी IPS rules बनाकर Allow, Drop या Reset action लगा सकते हैं।

तकनीकी रूप से firewall TLS handshake में प्रस्तावित और चुने key exchange को पहचान सकती है: client ClientHello में supported groups और key shares देता है तथा server ServerHello में चयन बताता है। यह encrypted application stream शुरू होने से पहले होता है, इसलिए बाद की HTTPS सामग्री पढ़े बिना पहचान संभव है।

Sophos यह दस्तावेज़ नहीं करता कि Snort या SFOS IPS pipeline कहाँ इन characteristics का मूल्यांकन करती है, कौन-से TLS versions cover हैं और proxy, DPI तथा unencrypted FastPath traffic में पहचान कैसे बदलती है। Release Notes capability की पुष्टि करते हैं, internal data-path implementation की नहीं। Production policy के लिए firewall और IPS logs के साथ अपना test जरूरी है।

Actions का असर अलग है:

• Allow connection जारी रखता है और logging के साथ inventory बनाने के लिए उपयुक्त है।
• Drop matching packets को चुपचाप त्यागता है; client को आम तौर पर timeout या टूटा handshake दिखता है।
• Reset TCP connection सक्रिय रूप से बंद करता है; error जल्दी दिखता है, पर application logs में silent drop से अलग हो सकता है।

नई signatures default रूप से disabled हैं—यह सही निर्णय है। PQC अब केवल lab technology नहीं है। बड़े browsers, cloud services और web platforms hybrid methods का परीक्षण या उपयोग कर रहे हैं। इन्हें blanket-block करने से वैध websites और applications रुक सकती हैं।

उचित rollout:

1. Signatures enable करें, traffic allow करें और log करें।
2. दिनों या हफ्तों तक देखें कि कौन-सी applications और destinations ML-KEM इस्तेमाल करती हैं।
3. जाँचें कि internal cryptography policy कुछ methods रोकती या अनिवार्य करती है।
4. उसके बाद ही targeted Drop या Reset लागू करें।

पहली Community चर्चा में एक admin को upgrade के तुरंत बाद PQC, KEM या quantum खोजने पर signatures नहीं मिलीं। कारण pending pattern update या naming हो सकता है। Release के कुछ घंटों बाद इसे product bug कहना जल्दबाज़ी होगी, लेकिन यह documentation problem दिखाता है: feature तभी administrable है जब signature name, SID, category और log characteristics मिलें।

Policy change से पहले जाँचें:

• क्या IPS active है और Network Protection subscription valid है?
• कौन-सा IPS pattern version installed है?
• नई signatures किस name और SID से आती हैं?
• क्या hits IPS log और central reporting में आते हैं?
• DPI exceptions, TLS inspection और FastPath में detection समान रहती है?
• कौन-से browsers, operating systems, cloud services और internal apps hits पैदा करते हैं?

Web Protection क्या करता है

Sophos के अनुसार Web Protection web sessions को unsupported PQC algorithms negotiate करने से रोकता है। यह IPS signature से अलग काम है। IPS patterns पहचानकर action लेता है; Web Protection नियंत्रित TLS/web workflow में हस्तक्षेप करके ऐसा method रोकता है जिसे firewall process नहीं कर सकती या policy स्वीकार नहीं करती।

TLS inspection में यह खास तौर पर relevant है। Decrypted connection में firewall client की TLS session terminate करके destination server तक दूसरी TLS session बनाती है। यानी दो अलग handshakes और session-key sets होते हैं। Browser और server PQC support कर सकते हैं, जबकि बीच की inspection component proposed group सही तरह process न कर पाए।

नियंत्रण न हो तो अस्पष्ट errors बनते हैं: client नया group देता है, firewall handshake relay नहीं कर पाती, server unexpected variant चुनता है या fallback गलत व्यवहार करता है। MR2 unsupported PQC negotiation रोकने का दावा करता है।

Sophos यह नहीं बताता कि Web Protection के लिए PQC policy matrix क्या है, supported groups कौन-से हैं, या unsupported offer हटाया, reject किया अथवा classical fallback से बदला जाता है। इसे configurable IPS action के समान नहीं मानना चाहिए।

Feature उपयोगी है, पर crypto strategy का विकल्प नहीं। संगठनों को अभी भी जानना होगा कि कौन-से TLS connections decrypt होते हैं, exceptions कहाँ हैं और PQC केवल observe करना है या enforce भी।

Generative AI applications की बेहतर visibility

दूसरी नई security सुविधा generative AI applications की Synchronized Application Control के जरिए बेहतर categorization है।

मूल सिद्धांत नया नहीं: Sophos Endpoint जानता है कि कौन-सा local process connection बनाता है और Security Heartbeat से application context firewall को देता है। इस तरह firewall session को program से जोड़ सकती है, जब port, destination IP और encrypted traffic पर्याप्त पहचान न दें।

सरल data path:

1. Protected endpoint की application network connection खोलती है।
2. Sophos Endpoint process name, path और local context जानता है।
3. Security Heartbeat endpoint और firewall views जोड़ता है।
4. SFOS unknown या broadly identified session को application से map करता है।
5. Application Synchronized Application Control में आती और categorize होती है।
6. Application Filter policy संबंधित traffic को allow, block या shape करती है।

Connection List में Resolve application info अज्ञात connections के लिए endpoint से जानकारी माँग सकता है। Application list name, path, category या endpoints से searchable है। Sophos अधिकतम 15,000 managed applications बताता है। Memory बचाने के लिए प्रति application और endpoint केवल पाँच नवीनतम occurrences रखे जाते हैं।

MR2 खासकर generative AI application mapping सुधारता है। Sophos Endpoint इन्हें अधिक सटीक पहचानकर firewall को देता है। Generative AI category SFOS application list में है और Application Filters तथा reports में उपयोग हो सकती है।

Admins के लिए तीन मुख्य लाभ:

• Visibility: reporting में कौन-सी generative AI apps उपयोग हो रही हैं, अधिक स्पष्ट दिखेगा।
• Rules: identified apps को targeted allow, restrict या block किया जा सकता है।
• Inventory: security और privacy teams approved तथा unapproved AI services अलग कर सकती हैं।

लेकिन “generative AI detection” को बढ़ा-चढ़ाकर नहीं समझना चाहिए। Synchronized Application Control मुख्यतः पूछता है: connection किस application ने बनाया? यह अपने-आप नहीं बताता:

• user ने कौन-सा prompt लिखा,
• कौन-सी file upload हुई,
• personal या confidential data था या नहीं,
• browser session personal थी या business,
• approved service में embedded AI function उपयोग हुआ या नहीं।

Distinct process path वाला desktop client पहचानना आसान है; एक ही browser process में दस AI websites अलग करना कठिन। URL categorization, TLS inspection और cloud-app detection अतिरिक्त जानकारी दे सकते हैं, पर वे अलग detection layers हैं।

लाभ Sophos Endpoint, active Security Heartbeat और enabled Synchronized Application Control पर निर्भर है। पहली activation Sophos Central से होती है। केवल SFOS चलाने वाले या Heartbeat path से बाहर endpoints को वही depth नहीं मिलेगी।

सही अपेक्षा: MR2 app mapping और policy basis सुधारता है, पर कौन-सी AI service allowed हो और वहाँ कौन-सा data process हो, यह governance प्रश्न अकेले हल नहीं करता।

Upgrade के बाद पूरी Generative AI category तुरंत block नहीं करनी चाहिए। पहले reporting में देखें कि hits endpoint context, firewall signature या web categorization से आए। वरना Microsoft 365, development tools, browsers या support platforms की productive सुविधाएँ बिना वास्तविक usage समझे रुक सकती हैं।

Authentication और user mapping में बदलाव

MR2 में तीन स्वतंत्र authentication विषय हैं। दो के लिए ठोस तैयारी चाहिए, तीसरा अग्रिम migration warning है।

Manifest V3 वाली Chromebook User ID

Sophos Chromebook User ID Extension को Manifest V3 पर बदला गया है—यह Chrome का वर्तमान extension platform है और पुरानी technical base को replace करता है।

महत्वपूर्ण बात: पुरानी extension uninstall करके नई install करनी होगी; silent update पर्याप्त नहीं। Centrally managed Chromebooks वाले school और enterprise Google Admin policies से बदलाव तैयार करें, test group में जाँचें और फिर व्यापक rollout करें।

Extension SSO path का केवल एक भाग है। Chromebook SSO के लिए Sophos को चाहिए:

• firewall पर AD, LDAP या Google Secure LDAP server,
• SFOS-protected network में Chromebooks,
• registered Google Workspace domain के user addresses,
• encrypted communication certificate,
• certificate से matching CN,
• default Sophos communication port 65123,
• SFOS से exported और Google Workspace में stored JSON configuration,
• accounts.google.com, Google API hosts और Chrome Web Store तक access।

Google Workspace में नई extension Devices > Chrome > Apps and extensions > Users and browsers से deploy होती है। Production में Force install उचित है ताकि user identity mapping वाली extension हटा न सके। Sophos User ID App को API Controls में trusted करना होगा, अन्यथा OAuth fail हो सकता है।

सिर्फ installation नहीं, पूरी chain जाँचें:

1. User Chromebook में login करे।
2. Extension intended network और certificate से firewall तक पहुँचे।
3. User Live users में दिखे।
4. User-based rule सच में user या group पर match हो।
5. Logout या device change के बाद mapping सही हटे।

नई extension न होने पर future updates रुक सकते हैं। Authentication design के अनुसार user mapping तथा user-based firewall/web rules प्रभावित हो सकती हैं। School में firewall, Internet और Chromebook “online” दिखने के बावजूद filtering fail हो सकती है।

STAS अब Identity Probe के दौरान default रूप से block नहीं करता

Sophos Transparent Authentication Suite में MR2 Restrict client traffic during identity probe का default No करता है।

STAS Windows Domain Controller पर पहचाने users को IP addresses से map करता है:

1. User Windows domain में login करता है।
2. Domain Controller Security Audit Event लिखता है, नए Windows में सामान्यतः Event ID 4768।
3. STAS Agent event से username और IP पढ़ता है।
4. Agent default TCP 5566 पर Collector को सूचना भेजता है।
5. Collector successful mappings UDP 6060 पर firewall को देता है।
6. Unknown IP का traffic देखकर SFOS Collector को port 6677 पर query कर सकता है।
7. Firewall configured AD server से group membership जोड़कर user-based rules लगाती है।

अपरिचित IP Learning Mode में आती है। पहले probe के दौरान traffic default रूप से hold या discard होता था; documented default duration 120 seconds है। Collector जवाब न दे तो IP एक घंटे तक unauthenticated रह सकती है और unauthenticated rules लागू होते हैं।

MR1 में यहीं वास्तविक समस्या थी। Sophos NC-181885 दस्तावेज़ करता है: Restrict client traffic during identity probe = Yes पर repeated probes intermittent interruptions पैदा कर सकती थीं या MR1 upgrade रोक सकती थीं। MR2 fix version है और default को No करता है।

No पर probe के दौरान client traffic चलता रहता है। इससे disruption कम होता है, पर trade-off बदलता है:

• user को कम interruptions,
• probe के दौरान firewall के पास confirmed identity शायद न हो,
• इस transition में user-based rules और logging की सावधानी से जाँच।

यह availability और strict identity enforcement का classic trade-off है। Yes पर broken Collector communication client block कर सकती है; No पर identity confirm होने से पहले traffic बह सकता है। वह general network rule, unauthenticated rule या बाद की user rule में कहाँ match करता है, अपने ruleset में test करें।

Release Notes केवल default value को No में बदलने की बात करते हैं; यह स्पष्ट नहीं कि जानबूझकर set existing configurations overwrite होंगी। Upgrade के बाद actual value जाँचें।

इसके अतिरिक्त:

• क्या UDP 6060 और 6677 firewall तथा Collector के बीच खुले हैं?
• STAS Service चल रही और सही NIC से bound है?
• Fault Tolerance के लिए multiple Collectors groups में हैं?
• Printers, IoT और non-domain devices के लिए Clientless User objects काम करते हैं?
• Sleep, roaming, DHCP change और logout के बाद users सही दिखते हैं?
• Learning Mode और unauthenticated state में rules security design के अनुसार match होते हैं?

यह उन environments में विशेष रूप से महत्वपूर्ण है जहाँ identity केवल reporting नहीं, वास्तविक access condition है।

SFOS 23.0 में Novell eDirectory समाप्त

MR2 पहली बार पहले से सूचित करता है कि SFOS 23.0 में Novell eDirectory authentication servers का support समाप्त होगा।

MR2 में eDirectory अभी काम करता है; यह warning है, तत्काल loss नहीं। Users को SFOS 23.0 से पहले supported authentication type पर migrate करना चाहिए।

Migration केवल server entry नहीं है। Groups, firewall rules, web policies, VPN access, user portals और reporting पुराने identity source पर निर्भर हो सकते हैं। अलग Distinguished Names, nested groups, search paths और username formats का मतलब है कि successful LDAP test भी working policy migration साबित नहीं करता।

पुरानी सीमा भी है: STAS eDirectory के लिए LDAP over SSL/TLS support नहीं करता। SFOS 23.0 में हटना पूरी तरह अप्रत्याशित नहीं, पर replacement architecture समय से तैयार होनी चाहिए—test accounts, parallel groups, documented rule references और rollback plan वाले अलग project की तरह।

Let’s Encrypt: नई chains और बेहतर mapping

Let’s Encrypt अपनी certificate infrastructure को धीरे-धीरे नए Root और Intermediate certificates पर ले जा रहा है। MR2 YE Root, YE1, YE2, YR Root, YR1 और YR2 support जोड़ता है।

Generation-Y hierarchy में अलग key types वाले दो नए Root CAs हैं:

• ISRG Root YE ECDSA P-384 उपयोग करता और पुरानी ECDSA hierarchy का successor path है।
• ISRG Root YR RSA 4096 वाला नया RSA root path है।
• YE1 और YE2 ECDSA-P-384 intermediates हैं।
• YR1 और YR2 RSA-2048 intermediates हैं।

Roots पुराने ISRG roots से cross-signed हैं। इससे नई chains पुराने widespread Trust Anchors तक लौट सकती हैं, जबकि browser/OS vendors नए roots trust stores में जोड़ते हैं। YE1, YE2, YR1 और YR2 intermediates 2026 में active issuance के लिए relevant हुए।

SFOS के लिए यह compatibility change है। Firewall को नए issuers/chains जानने होंगे ताकि automatic issuance, renewal, WAF usage और validation काम करें। Updated trust chain न हो तो domain, port 80 और HTTP-01 सही होने पर भी certificate operation fail हो सकता है।

ऐसा ACME error भ्रमित करता है: admin DNS, DNAT, port 80, WAF rule या Terms of Service में खोजता है, जबकि कारण नई CA chain होती है।

SFOS Let’s Encrypt requests के लिए अभी HTTP-01 इस्तेमाल करता है। Domain FQDN को selected public WAN address पर point करना चाहिए, port 80 firewall तक पहुँचना चाहिए और उसी address/port 80 पर competing DNAT validation रोक सकता है। MR2 यह सिद्धांत नहीं बदलता, केवल CA hierarchy बढ़ाता है।

Let’s Encrypt email notifications में अब firewall hostname और serial number भी आते हैं। MSPs और बड़े environments में generic warning को सही device से जोड़ना आसान होगा। यह छोटी, पर उपयोगी quality-of-life सुधार है। हर centrally managed firewall message में कम से कम hostname, serial, model और firmware होना चाहिए; backup emails के बाद MR2 में Let’s Encrypt भी उसी दिशा में जाता है।

Config Studio 2.6: हर नई सुविधा की व्याख्या

Sophos Config Studio 2.6 को MR2 announcement का हिस्सा बताता है, हालाँकि यह अभी भी अलग browser tool है, SFOS में embedded नई UI नहीं। मूल workflow के लिए पुराना लेख Sophos Firewall Config Studio V2: सिर्फ Viewer से कहीं अधिक देखें, जिसमें export, Entities.xml, comparison और editor शामिल हैं।

तकनीकी और privacy context: Sophos के अनुसार parsing, analysis और report generation endpoint के browser में local होती है; uploaded configuration Sophos या दूसरे server को नहीं भेजी जाती। Full firewall config की Entities.xml में internal networks, objects, policies, VPN definitions, certificate references और organizational names हो सकते हैं, इसलिए यह महत्वपूर्ण है।

फिर भी local processing अपने-आप risk-free नहीं। Browser application Internet से load करता है। Highly sensitive environments में code version, browser cache, offline use, endpoint hardening और exports की secure storage के प्रश्न रहते हैं। Entities.xml को Downloads, tickets या सामान्य cloud sync में अनियंत्रित नहीं रखना चाहिए।

Config Studio 2.6 के पाँच areas हैं:

• Policy Test, analysis और global search वाला Configuration Report
• दो या अधिक configurations का comparison
• Bulk Editing और XML, API या curl output वाला visual editor
• Sophos UTM, SonicWall, FortiGate और Palo Alto Networks से migration
• Backup Restore, Flexi Port, transceiver और model compatibility

Version 2.6 इन्हें कई जगह बढ़ाता है।

Templates merge करना

Merge Templates से baseline configurations और industry-specific templates जोड़े जा सकते हैं। MSP logging, DNS, admin access और standard objects वाली technical baseline को clinics, schools या branches की template से मिला सकता है।

लाभ reuse है: हर firewall शून्य से नहीं बनानी। Baseline admin access, NTP, DNS, Syslog, standard services और logging conventions दे; दूसरी template industry rules/objects जोड़े।

पर conflict handling महत्वपूर्ण है:

• समान object names और अलग values पर क्या होगा?
• UUIDs, references और rule order consistent resolve होते हैं?
• कौन-से interface/zone references target model से नहीं मिलते?
• duplicate/overlapping rules बनते हैं?
• restrictive object broad template value से बदलता है?

Merge के बाद Duplicate Analysis, Shadow Rule Analysis, Usage References और full Policy Test अनिवार्य हैं। Technical success सुरक्षित resulting policy का प्रमाण नहीं।

बेहतर global search

Global search objects जल्दी खोजकर सीधे वहाँ navigate करती है। बड़े rulesets में host object Firewall, NAT, TLS, Web या VPN config में referenced हो सकता है; direct navigation बहुत manual work बचाती है।

Search केवल visible object name तक सीमित नहीं; data type के अनुसार values, paths और referenced elements भी relevant हैं। Generic names जैसे Server, LAN_Network या पुरानी host groups में यह उपयोगी है।

लेकिन Search और Usage Reference अलग हैं। Search पूछती है “object/value कहाँ है?” Usage Reference पूछती है “कौन-से अन्य elements इस पर निर्भर हैं?” Safe change में दोनों चाहिए। यही सुविधा सीधे firewall UI में भी जरूरी है।

अधिक सार्थक configuration reports

Firewall, NAT और TLS rule reports अब reference names के साथ objects के values/details भी दिखाते हैं। केवल Webserver-Gruppe के बजाय reviewer उसमें शामिल hosts/networks देख सकता है।

Audit, handover और four-eyes review में यह महत्वपूर्ण है। Source, destination, services और linked objects दिखे बिना rule आकलन योग्य नहीं। साफ object name के पीछे Any, बहुत broad network या भूली entries हो सकती हैं।

Report Policy Test और analysis भी देता है। Policy Test देखता है कि defined source/destination पर कौन-सी rule या route match करती है। Analysis shadowing और duplicates खोजता है। SFOS rules top-to-bottom evaluate करता और first match पर रुकता है, इसलिए ordering security logic है, केवल display नहीं।

Config Studio 2.6: Migration, comparison और export

Success rate वाली migration analysis

Config Studio migration/conversion information के साथ सफलतापूर्वक transferred हिस्सा दिखाता है। Percentage quick indicator है, acceptance report नहीं।

Third-party migrations में Sophos states:

• Supported: content change बिना automatic migration
• Partial: gaps के साथ migrated; missing parts जोड़ने होंगे
• Manual: Sophos Firewall पर manually recreate करना होगा
• Not supported: migrate नहीं होगा
• Action required: export से पहले decision जरूरी

95% conversion में missing 5% certificates, passwords, VPNs, NAT या special routing हो सकता है। असली मूल्य green percentage में नहीं, बल्कि unresolved, partial और automatically resolved elements की सूची में है।

Vendor logic differences वास्तविक हैं। FortiGate rules अधिक interface-based और SFOS zone-based हो सकता है; Palo Alto के object, zone और policy models अलग हैं। Config Studio syntax/structures convert कर सकता है, security model की semantic equivalence साबित नहीं।

Multi-File Configuration Diff

अब दो या अधिक configuration states upload करके समय के साथ compare किए जा सकते हैं। Config Studio files को modification date से order करता और field level पर added, removed, modified changes दिखाता है।

Side-by-Side, Unified और Semantic views उपलब्ध हैं। Semantic comparison महत्वपूर्ण है, क्योंकि XML text diff order, IDs या formatting से noisy होता है; Entity/Field-level diff actual config change पर केंद्रित होता है।

यह change reconstruction/troubleshooting में उपयोगी है। देर से दिखी समस्या में कई exports से पता चलता है कि rule, object या setting कब बदली।

पर नियमित saved states, correct timestamps और sensitive exports का disciplined handling चाहिए। Downloaded/copied file का modification date firewall change time नहीं भी हो सकता। Reliable history में filename, export time, hostname, serial, firmware और change ticket साथ document करें।

Version discipline बिना diff history बना नहीं सकता। Central में immutable audit history के साथ यह manual upload से कहीं शक्तिशाली होता।

Backup Restore, Flexi Port और speed reference

Config Studio अलग Sophos models की Backup Restore compatibility और port layouts जाँचता है, साथ में Flexi Port modules तथा 25, 40, 100 Gbit/s तक supported speeds/standards दिखाता है।

Hardware migration से पहले अनुमान लगता है:

• backup restore हो सकता है या नहीं,
• physical ports कितने हैं,
• existing Flexi Port modules compatible हैं या नहीं,
• supported interface standards/speeds क्या हैं।

यह migration design का replacement नहीं। LAGs, VLANs, Bridges, HA, port names, zones और interface mapping plan तथा restore के बाद verify करनी होंगी।

Broader compatibility SFOS 20.0 MR2 या बाद के targets के लिए है। Source version/target platform के अनुसार Backup Restore Assistant interface mapping देता है। Physical ports remap हो सकते हैं; VLANs/Aliases parent interface follow करते और assigned ports से LAGs/Bridges फिर बनते हैं।

Flexi Port में केवल mechanical fit काफी नहीं। Model generation, form factor, transceiver, supported standard, speed, breakout behavior और SFOS version साथ जाँचें। Config Studio reference तेज करता है, migration के बाद link/failover test नहीं बदलता।

Dark Mode

Release Notes Dark Mode भी बताते हैं। यह छोटी usability improvement है, firewall feature नहीं। फिर भी प्रतीकात्मक है: Dark Mode भी पहले external Config Studio में आता है, जबकि local WebAdmin console वर्षों से बहुत धीरे आगे बढ़ती है।

Editor तकनीकी रूप से क्या output देता है

Editor configurations import/new बना सकता, Bulk Changes कर सकता और export से पहले Import XML, API Request या curl दिखा सकता है। XML/TAR download करके Backup & firmware > Import export से SFOS में import भी किया जा सकता है।

यह शक्तिशाली है, इसलिए admin responsibility बढ़ती है। Generated API request स्वतः idempotent नहीं। Successful import यह सिद्ध नहीं करता कि Rule Order, object usage, NAT, VPN और Security Policies सही काम करते हैं। Production से पहले output change ticket में, diff review में और firewall real data-path test में जाना चाहिए।

50 से अधिक fixes ही MR2 का असली कारण हैं

Sophos 50 से अधिक reliability, stability और security समस्याएँ ठीक करने का दावा करता है। हर fix हर installation को प्रभावित नहीं करता, पर कई operationally गंभीर हैं।

मेरी दृष्टि में खास groups:

HA और Failsafe मामूली विषय नहीं

कई fixes individual feature नहीं, appliance की operational availability को प्रभावित करते हैं:

• NC-181331: full configuration partition firewall को Failsafe Mode में डाल सकती थी।
• NC-180110: Primary पर Logging Daemon start न होने से HA device Failsafe में गया।
• NC-177441: v22 GA upgrade के बाद Postgres problem से original Primary Failsafe में जा सकता था।
• NC-178906: RED Server Service start न होकर Failsafe trigger कर सकती थी।
• NC-177467: बहुत बड़ी संख्या में parallel unauthenticated SSH attempts के कारण Auxiliary सही start नहीं हुआ।

कारण अलग, operational result समान: firewall services खोती, protection mode में जाती या HA partner उपलब्ध नहीं होता, जबकि cluster status पहले green था। इसलिए upgrade के बाद केवल HA status: Active-Passive देखना पर्याप्त नहीं। Synchronization, service status, failover और real traffic test करें।

IPsec fixes data path में गहरे हैं

VPN fixes cosmetic नहीं:

• NC-180433: VPN tunnel से multicast traffic repeated firewall crashes करा सकता था।
• NC-171719: SD-WAN स्थिति में ESP traffic गलत routing पर गया।
• NC-180520: IPsec Acceleration enabled होने पर upgrade के बाद XFRM gateway unavailable रहा, जब tunnel Alias IP से bound और ESP दूसरे WAN port से आया।
• NC-176855: route-based IPsec पर IPv6 throughput प्रभावित था।
• NC-178121: Drag-and-drop Site-to-Site IPsec connections को Failover Group में गलत positions पर ले जा सकता था।

इनमें tunnel status Active कुछ साबित नहीं करता। Route-based VPNs में XFRM interface, routing table, SD-WAN decision, ESP path, MTU, IPv4 और IPv6 अलग जाँचें। Failover Groups में order और failover documented priority के अनुसार हों।

Logging और Reporting स्वयं outages पैदा कर सकते थे

NC-155252 खास अप्रिय fix है: reporting में high disk-I/O load से CPU spikes और एक मिनट तक intermittent Internet outages हुए। यानी analysis subsystem ने production data path को प्रभावित किया।

NC-178745 Logging Framework में out-of-memory के कारण HA device auto-restart बताता है। NC-181520 Log Viewer performance सुधारता है। कुल मिलाकर logging को harmless side feature नहीं माना जा सकता; storage, database, Garner, Log Viewer और Central Reporting system से अधिक गहराई से जुड़े हैं, जितना UI दिखाती है।

MR2 के बाद केवल नई log lines नहीं, यह जाँचें:

• Firewall, IPS, WAF, Authentication और VPN events पूर्ण आते हैं?
• Timeline बिना gaps रहती है?
• External Syslog Collector को data मिलता है?
• Normal load में CPU, RAM और disk I/O stable हैं?
• Reports data path प्रभावित किए बिना बनते हैं?

Central fixes “Single Pane of Glass” की सीमा दिखाते हैं

NC-181175 में Sophos Central group policies Pending रह सकती थीं। NC-180513 MR1 upgrade के बाद Central View configuration import को प्रभावित करता था। NC-181904 Central से quarantine emails release नहीं होने देता था।

समानता यह है: central UI request accept/display कर सकती है, जबकि desired change firewall पर लागू न हुआ हो। Group Policy push के बाद target device पर object, rule, order और timestamp verify करें। Central में successfully closed dialog technical commit proof नहीं है।

Fix list यह भी दिखाती है कि Maintenance Release का मूल्य feature count से नहीं आँकना चाहिए। Logging, Postgres, SD-WAN या multicast से Failsafe/restart रोकना नई dashboard tile से अधिक मूल्यवान है।

पर fixes की संख्या स्वयं quality badge नहीं। वह बताती है कि problems ठीक हुईं और पुराने builds में कितनी गंभीर थीं। Critical HA, VPN या WAF environment न तो डर से पुराने build पर हमेशा रहे, न MR2 को पहले दिन बिना परीक्षण हर जगह deploy करे।

Upgrade से पहले admins क्या जाँचें

Sophos security, stability और performance fixes के कारण MR2 शीघ्र install करने को कहता है। Production में “शीघ्र” का अर्थ “बिना परीक्षण” नहीं।

Bridges पर legacy VLAN tagging MR2 रोकता है

MR2 में old CLI-based VLAN tagging on Bridge Interfaces पर hard upgrade block है। Configuration में legacy system vlan-tag हो तो SFOS 22.0 MR2 या बाद का upgrade नहीं होगा।

Upgrade से पहले इसे साफ या migrate करें। इस legacy config वाले backups SFOS 22.0 GA या बाद पर restore भी नहीं होते। यह लंबे समय से चली और कभी CLI से modified installations में विशेष महत्वपूर्ण है।

पुरानी v22 बाधाएँ भी लागू हैं

• MR1 या MR2 से पहले Legacy Remote Access IPsec हटाना/migrate करना होगा।
• SFOS 22 को अधिक disk space चाहिए; कुछ desktop, virtual या software appliances में पहले adjustment जरूरी है।
• GA से policy-based IPsec VPN behavior बदला है; relevant tunnels जाँचें।
• XG और SG hardware SFOS 22 support नहीं करते।
• पुराने RED 15, RED 15w और RED 50 v21.5 से unsupported हैं।

मेरा upgrade workflow

Production firewall पर कम से कम:

1. Current backup बनाकर external location में सुरक्षित करें।
2. Support/license status और approved upgrade path जाँचें।
3. Legacy Remote Access IPsec और CLI VLAN tagging on Bridges exclude करें।
4. Control Center में disk-space warnings देखें।
5. HA में दोनों nodes, synchronization और available firmware जाँचें।
6. Critical VPNs, WAF publications, mail flows, SD-WAN rules और authentication document करें।
7. MR2 पहले representative test या less-critical appliance पर install करें।
8. बाद में logs, pattern version, HA, routing, DNS, VPN, WebAdmin, reporting और central policy pushes test करें।

कई fixes वाले release में before/after test खास जरूरी है। वरना केवल firmware नया होना पता होगा, critical data paths पहले जैसे हैं या नहीं, नहीं।

SFOS 20 से automatic firmware rollback है, जब upgrade में configuration migration fail हो। इससे Factory Configuration के साथ boot होने का risk घटता है। लेकिन unsupported upgrade path या कुछ Setup Assistant flows जैसे हर scenario में यह नहीं चलता। Auto rollback के बाद migration.log और migrationhash.log analyze करें।

Automatic rollback external backup, Secure Storage Master Key और reachable console access का replacement नहीं। यह मुख्यतः failed configuration migration से बचाता है; successful technical upgrade के बाद WAF, VPN, HA या Reporting ठीक होने का प्रमाण नहीं।

मेरे direct MR2 test में upgrade से पहले और बाद में वही points measure/provoke होंगे:

• Restart और सभी services का पूरा startup
• WebAdmin login और बड़े rule lists का response time
• Local/external log flow
• IPsec traffic, Rekey और Failover
• Firewall पर verification सहित Central Policy Push
• IPS और Application Control pattern update
• STAS re-login और unknown client IP behavior
• Test system cluster हुआ तो HA synchronization और controlled role change

तभी कह सकता हूँ कि MR2 मेरे environment में बेहतर है। Successful installation और green Control Center page पर्याप्त नहीं।

शुरुआती Community feedback क्या बताता है

Feedback thread MR2 के दिन ही खुला और इस आकलन के समय कुछ घंटे पुराना है। इससे न stability सिद्ध होती है, न problems।

फिर भी दो चर्चाएँ उल्लेखनीय हैं:

• XGS 5500 Active-Passive HA operator test depth पूछता है, क्योंकि NC-177467 ने MR1 में महीनों परेशान किया। Sophos इसे MR2 में fixed बताता है। यह बहुत सारे simultaneous unauthenticated SSH attempts के कारण Auxiliary start failure था।
• PQC signatures पर Sophos employee बताता है कि ये जानबूझकर disabled हैं। Browser/applications में PQC TLS बढ़ने से immediate activation बहुत alerts ला सकती है। पहले Allow और logging, फिर आवश्यक हो तो blocking action उचित है।

नई release की early phase में concrete tests, Case IDs और reproducible feedback, blanket “चलता है” या “टूटा है” से बेहतर हैं। शुरुआती दिनों/हफ्तों में HA, IPsec, WAF, STAS और Reporting के लिए thread देखते रहना चाहिए।

Config Studio पुरानी UI का spare-parts warehouse बन रहा है

अब अप्रिय भाग।

Config Studio 2.6 अच्छा tool है। Template merge, object search, report references resolve, multi-state compare और hardware migration preparation वास्तविक admin functions हैं। आलोचना features की नहीं, उनके स्थान की है।

Sophos अब Config Studio को Firewall Release Notes और official MR2 announcement में सीधे बताता है। वह उन problems का strategic answer लगता है, जो WebAdmin या Sophos Central में हल होनी चाहिए।

Local Firewall UI daily use में पुरानी और बड़े configurations में अक्सर धीमी रहती है। Bulk changes अपर्याप्त हैं। Object usage, true global search, clean diffs, NAT cloning, rule conflicts और modern change workflow वहीं नहीं हैं जहाँ admins रोज काम करते हैं। Central gap का केवल कुछ हिस्सा भरता है।

समस्या केवल design नहीं। Modern firewall UI को reliable change process चाहिए:

• immediate individual changes के बजाय Candidate Configuration
• commit से पहले full before/after diffs
• Objects, Rules, NAT, VPN और TLS पर dependency checks
• atomic commit या clear transaction status
• last known state पर validated rollback
• audit trail में सही user, time और source attribution
• preview/conflict checking वाली Bulk Operations
• reproducible changes के लिए consistent API output

Config Studio इनमें कुछ बाहर reproduce करता है। Export analyze करके XML/API requests और diffs देता है, पर offline view तथा active runtime state में gap रहता है। Sessions, dynamic routing, HA status, current patterns, certificate status और loaded config local Entities.xml के समान नहीं।

एक release announcement से यह fact निकालना अनुचित होगा कि Sophos SFOS interface कभी modernize नहीं करेगा—ऐसी पुष्टि नहीं। फिर भी संकेत खराब है: usability, search, comparison और configuration के सबसे visible improvements फिर management interfaces के बाहर हैं।

Workflow fragmented रहता है:

1. Firewall से configuration export करें।
2. Archive extract करके Entities.xml खोजें।
3. अलग browser tool में file load करें।
4. वहाँ analyze, compare या edit करें।
5. XML, API या curl से result वापस लाएँ।

Audit के लिए ठीक, आधुनिक, सुरक्षित, traceable administration के लिए detour। खास बात यह कि Config Studio केवल special case नहीं, बल्कि वर्षों से admins की माँगी low-hanging fruits पाता है।

यहाँ मेरी आलोचना और कड़ी है: यदि Config Studio सामान्य Firewall Release Notes का बड़ा विषय है, तो इसे छोटी helper utility नहीं कहा जा सकता। Sophos इसे admin strategy का visible हिस्सा बना रहा है। इसलिए बताना चाहिए कि कौन-सी functions WebAdmin/Central में आएँगी और कौन-सी browser tool में ही रहेंगी।

Roadmap बिना impression बनता है कि पुरानी, धीमी और बड़े configs में increasingly user-unfriendly UI बनी रहेगी और modern workflow के लिए admins Config Studio इस्तेमाल करें। यह confirmed Sophos plan नहीं, पर product की वर्तमान दिशा यही संकेत देती है।

इससे UniFi के लिए रास्ता आसान क्यों होता है

UniFi हर Sophos Firewall का पूर्ण replacement नहीं। Sophos license/architecture के अनुसार deeper security, IPS, Web Protection, WAF, endpoint integration, MDR/XDR और enterprise features देता है। निष्पक्ष तुलना इसे नहीं मिटा सकती।

लेकिन perceived product quality में usability रोज जीतती है।

Ubiquiti design, mobile apps, consistent navigation, topology, simple device onboarding और बिना वर्षों के product experience समझ आने वाली UI में visibly निवेश करता है। हर UniFi function technical depth में आगे नहीं, पर product आधुनिक लगता है और purchasing decisions प्रभावित करता है।

छोटी IT team केवल IPS datasheets नहीं देखती, बल्कि:

• Device, rule या client कितनी जल्दी मिलता है?
• Smartphone से environment meaningful ढंग से check हो सकती है?
• Warnings/dependencies specialist knowledge बिना समझ आते हैं?
• Routine change में कितने clicks लगते हैं?
• Product cohesive platform है या साथ रखे अलग tools?

यहाँ Sophos Ubiquiti जैसे vendors के लिए अनावश्यक रूप से आसान बनाता है। Sophos Firewall security में अधिक कर सकती और कई SMEs के लिए बेहतर choice रह सकती है। पर modern search, diffs, templates और mass changes के लिए अलग Config Studio चाहिए तथा core UI पुरानी/धीमी है, तो Sophos सबसे visible layer पर trust खोता है।

अच्छी security में मजबूत engine ही नहीं, ऐसी UI भी चाहिए जिसमें लोग rules समझें, errors पकड़ें और changes सुरक्षित करें। Usability cosmetic extra नहीं, operational security का भाग है।

निष्कर्ष: MR2 install करें, लेकिन product problem कायम है

SFOS 22.0 MR2 बड़ा feature release नहीं; उपयोगी additions वाला महत्वपूर्ण Maintenance Release है।

PQC control सही समय पर आता है, पर पहले observe होना चाहिए। Generative AI app detection visibility/policy सुधारती है, DLP या AI governance नहीं बदलती। Chromebook admins को Manifest V3 extension actively deploy करनी होगी। STAS कम disruptive होगा, लेकिन identity rules की conscious review चाहिए। Let’s Encrypt अगली certificate chains के लिए तैयार होता है। कई fixes ऐसी problems संबोधित करते हैं जो production outages पैदा कर सकती थीं।

मैं backup और preflight के तुरंत बाद MR2 install करके इन data paths को test करूँगा। Listed HA, VPN, Reporting, Central या Failsafe problems से प्रभावित environments के पास update के अच्छे कारण हैं। Build 546 सच में stable है या नई regressions लाता है, release day पर ईमानदारी से नहीं कहा जा सकता।

मेरी आलोचना स्पष्ट है: Config Studio 2.6 उपयोगी है, पर Firewall Release में उसकी प्रमुख भूमिका यह impression मजबूत करती है कि Sophos modern administration को side tool में भेज रहा है। यह नई SFOS UI की confirmed cancellation नहीं, पर strategic warning signal है।

Sophos की firewall foundation मजबूत है। Vendor को admins को उस technical base के अनुरूप management experience देना चाहिए। वरना modern platforms बेहतर security से नहीं, screen के सामने बैठे लोगों को अधिक गंभीरता से लेने के कारण जीतेंगे।

अगली बार तक,
आपका Joe

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