सत्यापन-योग्य दावे।

पासवर्ड की ज़रूरत केवल पहला SSH कनेक्शन खोलने और एक सर्विस यूज़र इंस्टॉल करने के लिए होती है। इसे हमारे कनेक्शन के लिए SSH प्रमाणीकरण के रूप में पास किया जाता है — किसी स्क्रिप्ट आर्ग्युमेंट या एनवायरनमेंट वेरिएबल के रूप में नहीं। हमारे डेटाबेस में इसके लिए कोई फ़ील्ड नहीं है; यह स्क्रिप्ट-रन एनवायरनमेंट में नहीं जाता और लॉग में नहीं लिखा जाता (कनेक्शन एरर में केवल पता और पोर्ट होते हैं, पासवर्ड कभी नहीं)। इस्तेमाल के बाद इसे मेमोरी में (best-effort) मिटा दिया जाता है — यह बहु-परत सुरक्षा (defense in depth) है, कोई गारंटी नहीं: Go, garbage collection होने तक इस वैल्यू की प्रतियाँ heap पर रख सकता है।

ईमानदार चेतावनी: यह आपके सर्वर पर root पासवर्ड ही बना रहता है। इंस्टॉलेशन के बाद हम SSH पर पासवर्ड और root लॉगिन बंद कर देते हैं, लेकिन पासवर्ड को स्वयं नहीं बदलते — चाहें तो इसे आप खुद बदलें। 'हम इसे संग्रहीत नहीं करते' सच है; 'यह अब गुप्त नहीं रहा' सच नहीं है।

PasswordAuthentication no, PermitRootLogin no, SSH को एक ग़ैर-मानक पोर्ट पर ले जाया गया (डिफ़ॉल्ट रूप से 12011), fail2ban सक्षम (5 विफलताओं के बाद एक घंटे का बैन), केवल key से लॉगिन। सार्वजनिक key को इस्तेमाल से पहले कड़ाई से मान्य किया जाता है: नई-पंक्तियाँ (authorized_keys में अतिरिक्त keys घुसाने से सुरक्षा) और सिंटैक्स की दृष्टि से अमान्य keys अस्वीकार कर दी जाती हैं।

एंटी-लॉकआउट: पोर्ट 22 तब तक बंद नहीं किया जाता जब तक kernel (ss के ज़रिए) यह पुष्टि न कर दे कि नया SSH पोर्ट वाकई सुन रहा है; कॉन्फ़िग की जाँच sshd -t से और sudo नियम की जाँच visudo -cf से की जाती है, एरर होने पर दोनों वापस पलट (roll back) दिए जाते हैं।

पैनल आपके पासवर्ड से नहीं, बल्कि एक अलग key (ed25519) से काम करता है जिसे वह खुद जनरेट करता है। निजी हिस्सा डेटाबेस में AES-256-GCM से एन्क्रिप्टेड रहता है। एन्क्रिप्शन key (KEK) डेटाबेस से अलग संग्रहीत होती है — एक सर्वर एनवायरनमेंट वेरिएबल में — और प्रोडक्शन में यह अनिवार्य है (कोई असुरक्षित डिफ़ॉल्ट नहीं है: KEK के बिना क्रिप्टो सबसिस्टम बस चालू ही नहीं होगा)। यही एन्क्रिप्शन डेटाबेस के भारी सीक्रेट्स की रक्षा करता है — Marzban एडमिन पासवर्ड/token/JWT, Reality keys, पेमेंट-प्रोवाइडर keys, प्रॉक्सी-क्रेडेंशियल cache, बैकअप कॉन्फ़िग।

एन्क्रिप्शन डेटा को केवल छिपाता नहीं बल्कि उसे प्रमाणित भी करता है (GCM auth tag): किसी एन्क्रिप्टेड फ़ील्ड से छेड़छाड़ डिक्रिप्शन के समय पकड़ी जाती है और अस्वीकार कर दी जाती है। हर फ़ील्ड को एक नए यादृच्छिक nonce के साथ एन्क्रिप्ट किया जाता है; KEK की वैल्यू कभी लॉग तक नहीं पहुँचती — केवल उसका छोटा id पहुँचता है।

क्षमता-token (capability tokens) के बारे में: /sub सब्सक्रिप्शन token एक bearer सीक्रेट है। लुकअप के लिए हम केवल उसका SHA-256 संग्रहीत करते हैं, जबकि पहले से जारी किए गए लिंक को दोबारा दिखाने के लिए ज़रूरी प्रति को AES-GCM ciphertext के रूप में रखा जाता है। पुराने plaintext रिकॉर्ड HTTP सर्वर शुरू होने से पहले, fail-closed तरीके से, नए फ़ॉर्मैट में माइग्रेट कर दिए जाते हैं। पेमेंट-webhook URL पहचानकर्ता को सादे रूप में संग्रहीत किया जाता है लेकिन वह अपने आप किसी इवेंट को प्रमाणित नहीं करता: प्रामाणिकता की पुष्टि अलग से एक HMAC हस्ताक्षर द्वारा की जाती है।

key को केवल सर्वर पर, मेमोरी में डिक्रिप्ट किया जाता है; सामान्य API इसे कभी वापस नहीं देते। इसे पाने का एकमात्र तरीका एक जानबूझकर बनाया गया एक्सपोर्ट फ़ंक्शन है ('अपनी key ले जाएँ'), जो साइन-इन के साथ-साथ एक एक-बार वाले email कोड से सुरक्षित है (कोड केवल एक HMAC हैश के रूप में संग्रहीत होता है, स्थिर समय (constant time) में तुलना की जाती है, 10-मिनट का TTL, 5 प्रयास)। यानी key को जानबूझकर निकाला जा सकता है, लेकिन किसी सामान्य अनुरोध के ज़रिए इसे 'लीक' नहीं किया जा सकता।

सर्वर की स्थिति बदलने से पहले और किसी भी बैकग्राउंड नेटवर्क ऑपरेशन से पहले, प्रबंधन key रखने वाले फ़ील्ड सिंक्रोनस रूप से शून्य (zero) कर दिए जाते हैं। यदि डेटाबेस साफ़ किए जाने की पुष्टि नहीं करता, तो ऑपरेशन एक एरर लौटाता है और उसे दोबारा आज़माया जा सकता है। हटाना 'soft' ही रहता है: पंक्ति और ग़ैर-गुप्त सर्विस डेटा सुरक्षित रखे जाते हैं। इसका मतलब पहले से बनाए गए बैकअप का भौतिक मिटाया जाना नहीं है — उनका जीवनचक्र बैकअप रिटेंशन नीति द्वारा नियंत्रित होता है।

ऑडिट किए गए पार्टनर रूट partner_id के आधार पर प्राधिकरण करते हैं, जिसे सर्वर हस्ताक्षरित लॉगिन token से प्राप्त करता है — न कि उससे जो क्लाइंट ने पथ (path) या body में भेजा। कुछ भी लौटाने या बदलने से पहले, सिस्टम दोबारा जाँचता है कि अनुरोधित सर्वर, क्लस्टर, inbound, रूट, VPN यूज़र या पेमेंट आपके अकाउंट का है; संबंधित डेटाबेस क्वेरी आपके partner_id तक सीमित होती हैं, और स्कीमा (कंपोज़िट यूनीक keys के साथ कंपोज़िट फ़ॉरेन keys) अमान्य क्रॉस-पार्टनर लिंक अस्वीकार कर देती है। आइसोलेशन बहुस्तरीय है: एप्लिकेशन, usecase पुनः-जाँच, एक partner_id फ़िल्टर, और स्कीमा।

ईमानदार चेतावनी: यह अनुरोध-पथ के आर-पार एक कोड ऑडिट द्वारा सत्यापित है, किसी सार्वजनिक पेनिट्रेशन टेस्ट द्वारा नहीं — इसलिए SR-16, बाकी सबकी तरह, bug bounty में खंडन के लिए खुला है।

सब कुछ स्वचालित रूप से कॉन्फ़िगर करने के लिए (Xray+Reality इंस्टॉल करना, कॉन्फ़िग लागू करना, मेट्रिक्स पढ़ना) पैनल के पास सर्वर पर पूर्ण प्रशासनिक एक्सेस होता है (root-समकक्ष, बिना-पासवर्ड sudo वाले एक सर्विस यूज़र के ज़रिए)। यह प्रबंधन के लिए आवश्यक है, और हम इसे 'सीमित' नहीं कहते।

जोखिम को क्या कम करता है: सीक्रेट्स सर्वर को केवल प्रोसेस के stdin के ज़रिए भेजे जाते हैं (कमांड आर्ग्युमेंट के रूप में नहीं — वे प्रोसेस सूची में नहीं दिखते); शुरुआती इंस्टॉल के बाद, हर प्रबंधन कनेक्शन सर्वर की पिन-की-गई host key सत्यापित करता है — 'बीच में' किया गया सर्वर-स्वैप अस्वीकार कर दिया जाता है। आप क्या नियंत्रित करते हैं: एक्सेस एक ऐसी key पर टिका है जिसे आप किसी भी समय रद्द कर सकते हैं — सर्वर हटाकर (key शून्य कर दी जाती है) या बस अपने होस्ट पर VPS हटाकर (तब सब कुछ ग़ायब हो जाता है)।

VPN अकाउंट स्वयं (VLESS/Reality) आपके मास्टर सर्वर पर Marzban में बनाए जाते हैं और वहीं रहते हैं। केंद्रीय रूप से हम केवल वही संग्रहीत करते हैं जो एक सब्सक्रिप्शन लिंक जारी करने के लिए आवश्यक है: एक यादृच्छिक सब्सक्रिप्शन token और प्रॉक्सी क्रेडेंशियल का एक एन्क्रिप्टेड snapshot (एक cache; सत्य का स्रोत आपका Marzban है)। हमारे पास कोई ट्रैफ़िक, IP, या यूज़र विज़िट इतिहास नहीं है।

यहाँ एक ईमानदार सूची है कि किन-किन जगहों पर अंतिम उपयोगकर्ता का ईमेल वास्तव में हमारे केंद्रीय डेटाबेस से होकर गुज़रता है: साइन-इन कोड वाला ईमेल हम भेजते हैं, इसलिए पता हमारी भेजने की कतार से गुज़रता है (स्टोरफ्रंट में किसी भी साइन-इन के लिए, मुफ़्त सहित); भुगतान के समय खरीदार का ईमेल भुगतान webhook में आता है और भुगतान लॉग में दर्ज हो जाता है; Telegram जोड़ते समय ईमेल प्रोफ़ाइल में सहेजा जाता है। ये ही एकमात्र संपर्क-बिंदु हैं — सेवागत और आवश्यकतावश; इनमें से कोई भी ट्रैफ़िक या उपयोगकर्ता व्यवहार को नहीं छूता।

इन सेवा-संबंधी डेटा को हम केवल आवश्यक समय तक रखते हैं और स्वतः साफ़ कर देते हैं: ईमेल भेजने के तुरंत बाद भेजने की कतार से हटा दिया जाता है, भुगतान इवेंट का बॉडी संसाधन के बाद, और पुनः प्रयास की प्रतीक्षा कर रहे इवेंट 90 दिनों की अवधि के भीतर। आप सहायता से संपर्क करके अपना अकाउंट, उससे जुड़े डेटा सहित, हटा सकते हैं (विवरण के लिए जोखिम 7 देखें)। हम इसे अस्पष्ट शब्दों के पीछे छिपाने के बजाय खुलकर बताते हैं।

CreateYourVPN प्लेटफ़ॉर्म यह जानकारी न प्राप्त करता है और न संग्रहीत करता है कि आप या आपके यूज़र कौन-सी साइटें देखते हैं। मेट्रिक्स-इनजेस्ट स्कीमा बंद है: इसमें IP, डोमेन, या विज़िट के लिए भौतिक रूप से कोई फ़ील्ड नहीं है — केवल समुच्चय (अद्वितीय ऑनलाइन गिनती, कुल bytes, CPU/RAM/लोड)। हर नोड अपने ही id से बंधे एक HMAC token से प्रमाणित होता है और केवल अपने लिए ही मेट्रिक्स लिख सकता है। नोड-पर मौजूद बैलेंसर (HAProxy) SNI के आधार पर एक TCP राउटर की तरह काम करता है और ट्रैफ़िक को डिक्रिप्ट नहीं करता। सर्वर पर स्वयं, सिस्टम जर्नल लगभग एक घंटे से अधिक नहीं रखे जाते और syslog को फ़ॉरवर्ड नहीं किए जाते।

प्लेटफ़ॉर्म स्तर से परे, सर्वर भी कोई विज़िट जर्नल नहीं रखते: हर कॉन्फ़िग पुश पर Xray की access logging ज़बरन बंद कर दी जाती है (प्लेटफ़ॉर्म log.access को none पर सेट करता है), इसलिए edge proxy यह रिकॉर्ड नहीं करता कि उपयोगकर्ता किन पतों से जुड़ते हैं। यह कोड में लागू किया गया है और पूरे fleet में तैनात किया गया है।

साइट और पैनल का उपयोग कैसे होता है यह समझने के लिए हम Google Analytics लगाते हैं (cookie बैनर cookie और आँकड़ों के संग्रह के बारे में चेतावनी देता है; विवरण गोपनीयता नीति में हैं)। कोई अन्य थर्ड-पार्टी ट्रैकर नहीं है: न Sentry, न PostHog, न Mixpanel, और न कोई विज्ञापन pixel (दोनों फ्रंटएंड में खोजकर सत्यापित)। बैकएंड में बिल्कुल भी कोई थर्ड-पार्टी टेलीमेट्री नहीं है। end-user स्टोरफ्रंट पर एनालिटिक्स बिल्कुल भी नहीं है — न GA, न कोई ट्रैकर (इसके स्रोतों से सत्यापन-योग्य)।

चेतावनी: GA आपका IP (Google की तरफ़) और देखे गए पैनल पेजों के पते प्राप्त करता है; पैनल के URL में केवल एक क्लस्टर पहचानकर्ता होता है, कोई email नहीं।

पेमेंट और सभी कार्ड डेटा प्रोवाइडर की तरफ़ (Tribute / Lemon Squeezy) संभाले जाते हैं। हमें केवल एक हस्ताक्षरित webhook मिलता है (HMAC-SHA256, स्थिर-समय तुलना, body को पार्स किए जाने से पहले और किसी भी डेटाबेस राइट से पहले सत्यापित: सीक्रेट जाने बिना, कोई इवेंट सत्यापन में विफल हो जाता है)। हमें पूरा कार्ड नंबर (PAN) या CVV नहीं मिलता। उसी webhook का दोबारा भेजा जाना (प्रोवाइडर द्वारा पुनः-प्रयास) दोहरा ग्रांट नहीं कराता — इवेंट डी-डुप्लिकेट कर दिए जाते हैं।

चेतावनी: प्रोवाइडर webhook body में कार्ड मेटाडेटा (ब्रांड और अंतिम 4 अंक) और भुगतानकर्ता का नाम व email शामिल कर सकता है। प्रोसेसिंग पूरी होने तक worker को मूल body की ज़रूरत होती है; सफल प्रोसेसिंग के बाद इसे email संकेत सहित हटा दिया जाता है। पुनः-प्रयास या मैन्युअल समीक्षा की प्रतीक्षा कर रहे इवेंट मूल body को केवल रिटेंशन विंडो के अंत तक (बिना गतिविधि के 90 दिन) रखते हैं, जिसके बाद कार्ड मेटाडेटा और भुगतानकर्ता का email स्वतः मिटा दिया जाता है। 'कोई पूरा कार्ड नंबर नहीं है' सच है, लेकिन यह प्रोवाइडरों का गुण है (हम स्वयं body को फ़िल्टर नहीं करते); 'हम कार्ड के बारे में बिल्कुल कुछ नहीं देखते' सच नहीं है।

Email (साइन-इन के लिए ज़रूरी), आख़िरी साइन-इन का समय, इंटरफ़ेस मोड; बिलिंग के लिए — बैलेंस और Telegram (टॉप-अप के लिए)। पार्टनर का IP डेटाबेस में संग्रहीत नहीं होता, और हम पैनल में कोई क्लिक या क्रिया इतिहास नहीं रखते (एरर पर एक छोटे access लॉग के अलावा)।

फ़ायरवॉल डिफ़ॉल्ट रूप से आने वाले कनेक्शन अस्वीकार करता है। बाहर की ओर खुले: 443 (VPN, Xray+Reality), एक ग़ैर-मानक पोर्ट पर SSH (डिफ़ॉल्ट रूप से 12011), और — मास्टर सर्वर पर — Marzban एडमिन पैनल पोर्ट, केवल control-plane IP के लिए। पोर्ट 80 केवल Let's Encrypt मोड में HTTP-01 के लिए अलग से खोला जाता है। SSH स्थानांतरित होने के बाद पोर्ट 22 बंद कर दिया जाता है।

नोड के प्रबंधन पोर्ट केवल मास्टर सर्वर के IP के लिए खुले होते हैं, बाहर की ओर नहीं (इस binding की विफलता इंस्टॉल को रोक देती है)। यदि फ़ायरवॉल सक्रिय नहीं होता, तो इंस्टॉलेशन विफल हो जाता है। ICMP echo केवल IPv4 के लिए सीमित है; हम यह वादा नहीं करते कि सर्वर 'अदृश्य' है, और IPv6 के सही ढंग से काम करने के लिए IPv6 ICMP संरक्षित रखा जाता है।

Unattended upgrades सुरक्षा पैकेज अपडेट स्वचालित रूप से इंस्टॉल करता है। चेतावनी: स्वचालित reboot जानबूझकर बंद रखा गया है (ताकि कोई असत्यापित kernel अपने आप reboot न हो जाए) — इसका मतलब है कि reboot माँगने वाले फ़िक्स (kernel, कभी-कभी OpenSSH) केवल किसी मैन्युअल या निर्धारित reboot के बाद ही लागू होते हैं। 'ऑटो-पैचिंग' userland के लिए सच है, उसके लिए नहीं जिसे reboot चाहिए।

हम यह दावा नहीं करते कि सर्वर 'अदृश्य' है या 'स्कैन नहीं किया जा सकता'। पोर्ट 443 खुला है और किसी भी वेब सर्वर की तरह एक TCP कनेक्शन का जवाब देता है। यह गुण कि 'ग़लत कनेक्शन पर यह एक साधारण असंबंधित वेबसाइट जैसा दिखता है' — Xray के भीतर Reality प्रोटोकॉल द्वारा प्रदान किया जाता है — एक अलग घटक जिसे हम निरपेक्ष रूप में नहीं बदलते।

पार्टनर साइन-इन email पर भेजे गए एक-बार वाले 6-अंकीय कोड से होता है। कोई अकाउंट पासवर्ड नहीं है। यह प्रबंधित घटकों के आंतरिक क्रेडेंशियल पर लागू नहीं होता, जैसे जनरेट किया गया Marzban एडमिन पासवर्ड। कोड एक क्रिप्टोग्राफ़िक जनरेटर द्वारा बनाए जाते हैं; केवल उनका HMAC हैश संग्रहीत होता है, और तुलना स्थिर-समय में होती है। कोड एक-बार-उपयोग वाला है: सफल होने पर इसे तुरंत हटा दिया जाता है (कोई replay नहीं); 5 ग़लत प्रयासों के बाद इसे समय से पहले रद्द कर दिया जाता है। जारी करने की rate limit प्रति email गिनी जाती है, प्रति IP नहीं — पते बदलकर इसे बायपास नहीं किया जा सकता।

सेशन token एक HttpOnly और Secure cookie में रहता है (JS इसे नहीं पढ़ सकता), जिसकी पुष्टि बैकएंड पर होती है (केवल edge पर नहीं)। निष्क्रियता पर idle टाइमआउट और ऑटो-लॉगआउट क्लाइंट पर लागू किए गए हैं, सर्वर पर नहीं। token को HS256 से हस्ताक्षरित किया जाता है; सत्यापन पर हम किसी भी अन्य एल्गोरिदम ('none' सहित) को कड़ाई से अस्वीकार करते हैं — क्लासिक एल्गोरिदम-स्वैप हमला पास नहीं होता। स्टोरफ्रंट token और पार्टनर-पैनल token audience के आधार पर अलग किए गए हैं: एक end-user token तकनीकी रूप से पार्टनर API तक नहीं पहुँच सकता (और इसका उलटा भी)। एक हटाया गया पार्टनर जीवित token के साथ भी अस्वीकार कर दिया जाता है।

चेतावनी: निरस्तीकरण (revocation) हर अनुरोध पर यह जाँचकर लागू किया जाता है कि पार्टनर मौजूद है या नहीं, न कि token को स्वयं अमान्य करके; साइन-आउट cookie को हटा देता है, लेकिन जारी किया गया token समाप्ति तक क्रिप्टोग्राफ़िक रूप से मान्य रहता है (एक घंटे तक)। अभी तक कोई केंद्रीकृत निरस्तीकरण सूची नहीं है (एक सोचा-समझा MVP सरलीकरण)।

ब्राउज़र के local storage में कोई token नहीं होते (केवल UI सेटिंग्स); न कोई सीक्रेट और न API पता क्लाइंट बंडल में पहुँचता है। केवल सर्वर (Next.js) ही token को एक HttpOnly cookie में रखता है। ब्राउज़र core से केवल सर्वर के ज़रिए बात करता है (Server Actions): फ्रंटएंड ब्राउज़र से सीधे API को कॉल नहीं करता, और CORS दूसरे origin से API रिस्पॉन्स को ब्राउज़र में पढ़ने की अनुमति नहीं देता।

एक पूर्व निरपेक्ष कथन के बजाय एक स्पष्टीकरण: API डोमेन स्वयं एक सार्वजनिक होस्ट है — तकनीकी रूप से आप इसे ब्राउज़र से खोल सकते हैं, लेकिन सेशन के बिना यह कोई प्राधिकृत डेटा नहीं लौटाता।

CreateYourVPN के सार्वजनिक डोमेन HTTPS पर HSTS के साथ परोसे जाते हैं (max-age दो साल, includeSubDomains)। वेब फ्रंटएंड और API डोमेन दोनों सुरक्षा हेडर का एक सख़्त समूह भेजते हैं: एक प्रतिबंधात्मक Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options, और एक कसी हुई Referrer-Policy (API पर no-referrer; फ्रंटएंड पर strict-origin-when-cross-origin, जो एक प्रतिबंधात्मक Permissions-Policy भी भेजता है)।

यह दोनों डोमेन पर प्रोडक्शन में चालू है और स्वतंत्र रूप से जाँचा जा सकता है — किसी भी HTTP हेडर इंस्पेक्टर या SSL Labs जैसी सेवा से।