Phala / Intel TDX · उच्च-आश्वासन परिनियोजन

टीजीविटनेस / दस्तावेज़ीकरण · तैनाती और पुनर्प्राप्ति

उच्च-आश्वासन परिनियोजन संग्रह वातावरण के स्वतंत्र सत्यापन को अभिलेखागार सत्यापन में जोड़ता है। समीक्षक क्लाउड प्रदाता और Cloudflare के पास रखे गए परिनियोजन और पहुँच रिकॉर्ड की पूछताछ करता है, और एक Intel TDX परिनियोजन संग्रहकर्ता के वातावरण की हार्डवेयर प्रमाणीकरण जोड़ता है।

साधारण स्थानीय और Docker उपयोग अपरिवर्तित है। यहाँ कुछ भी तब तक नहीं चलता जब तक आप के साथ डिप्लॉय नहीं करते। python -m tgwitness.cloud, और कलेक्टर अपने होस्ट को केवल तब पढ़ता है जब डिप्लॉयमेंट सेट करता है TGWITNESS_ASSURANCE.

चित्र को पाठ के रूप में

1. ऑपरेटर → सर्वर, बिना इनबाउंड नियमों वाला फ़ायरवॉल (प्रदाता एपीआई)
2. ऑपरेटर → टनल और DNS (क्लाउडफ्लेयर एपीआई)
3. सर्वर, बिना इनबाउंड नियमों वाला फ़ायरवॉल → टनल और DNS (केवल आउटबाउंड)
4. सर्वर, बिना इनबाउंड नियमों वाला फ़ायरवॉल → सर्वर पर बनाई गई हस्ताक्षर कुंजी
5. प्रमाणीकरणकर्ता, केवल-पठन टोकन → प्रदाता लॉग और फ़ायरवॉल
6. प्रमाणीकरणकर्ता, केवल-पठन टोकन → टनल कनेक्टर का पता और प्रवेश
7. प्रमाणीकरणकर्ता, केवल-पठन टोकन → हस्ताक्षरित /api/assurance statement
8. प्रमाणीकरणकर्ता, केवल-पठन टोकन → साक्ष्य ज़िप

इस पृष्ठ पर

• एक सत्यापक क्या जाँच सकता है
• प्रदायक
• फला क्लाउड पर गोपनीय वीएम (इंटेल टीडीएक्स)
• शुरू करने से पहले
• पैनल से
• डोमेन के बिना त्वरित सुरंग
• तैनात करें
• डिबग डिप्लॉयमेंट और लॉक
• एक डिप्लॉयमेंट हटाएँ
• कोई भी सर्वर (स्व-प्रमाणित)
• सत्यापित करें
• साक्ष्य हस्तांतरण के लिए रिपोर्ट
• एक बाहरी गवाह के रूप में Cloudflare
• परिनियोजन परिणाम पढ़ना

एक सत्यापक क्या जाँच सकता है#

कलेक्टर हस्ताक्षरित process-start और host.state रिकॉर्ड में SSH स्थिति, सत्र, लॉगिन इतिहास और बूट जानकारी रिकॉर्ड करता है। एक सामान्य वीएम पर ये स्थानीय इन्वेंटरी रिकॉर्ड होते हैं, जिनकी समीक्षक प्रदाता के स्वतंत्र रिकॉर्ड से तुलना करता है। नीचे दी गई Intel TDX तैनाती अतिरिक्त रूप से हार्डवेयर-समर्थित मापों का सत्यापन करती है।

प्रदायक#

प्रत्येक मामले के लिए एक समर्पित प्रोजेक्ट, टीम, खाता या उप-खाता का उपयोग करें: सत्यापनकर्ता की केवल-पठन (read-only) पहुँच तब केवल इस तैनाती को दिखाती है। प्रमाण-पत्र (Credentials) से पढ़े जाते हैं --provider-token-file या उपरोक्त चर, कमांड लाइन से कभी नहीं। AWS के लिए फ़ाइल में ACCESS_KEY_ID SECRET_ACCESS_KEY [SESSION_TOKEN]; क्षेत्र है --location.

प्रत्येक प्रदाता के रिकॉर्ड में जो दिखाया नहीं जा सकता, वह हर रिपोर्ट में मुद्रित होता है। संक्षेप में: Hetzner कंसोल अनुरोधों को लॉग करता है; DigitalOcean का रिकवरी कंसोल, Linode का Lish/Glish और Vultr का वेब कंसोल इस तरह से लॉग नहीं होते हैं, इसलिए पहले बूट पर रूट लॉक हो जाता है और कंसोल लॉगिन के लिए पासवर्ड रीसेट या बूट परिवर्तन की आवश्यकता होगी, जिन्हें लॉग किया जाता है। Vultr कंसोल पता उस किसी भी कुंजी को लौटाता है जो इंस्टेंस को पढ़ सकती है; न तो रिकॉर्ड और न ही रिपोर्ट इसे संग्रहीत करती है।

फला क्लाउड पर गोपनीय वीएम (इंटेल टीडीएक्स)#

के साथ --provider phala कलेक्टर dstack द्वारा प्रबंधित Phala Cloud पर एक Intel TDX कॉन्फिडेंशियल वर्चुअल मशीन में चलता है। होस्ट और Phala का स्टाफ इसकी मेमोरी नहीं पढ़ सकता है, और प्रोसेसर इस बात की एक पुष्टि पर हस्ताक्षर करता है कि मशीन ने क्या बूट किया है। वेरिफायर Phala की बात पर भरोसा नहीं करता है: tgwitness.tdx हर प्रमाणीकरण को स्वयं, पिन किए गए Intel SGX रूट CA तक, Intel की रद्दीकरण सूचियों और Intel के हस्ताक्षरित प्लेटफ़ॉर्म डेटा के विरुद्ध जाँचता है, और उन मशीनों को अस्वीकार कर देता है जिन्हें डीबग या माइग्रेट किया जा सकता है।

The OS image (about 180 MB, of which 21 MB are kept) is downloaded once from Dstack-TEE/meta-dstack into dstack-images beside the record; --tdx-image FOLDER uses another folder or an unpacked image, --tdx-image none skips the comparison. The measurement follows dstack-mr and the qemu-acpi crate of Dstack-TEE/dstack. Private measurement regressions compare QEMU's own ACPI output and a retained Phala Cloud quote; live qualification also needs the published image. --tdx-measurements still compares MRTD and RTMR0-2 given as JSON instead.

जर्नल में दर्ज कलेक्टर की हर शुरुआत के साथ ऐसी एक प्रमाणीकरण होती है, इसलिए verify --evidence हर शुरुआत और उस OS इमेज की जांच करता है जिससे यह बूट हुआ था। Phala के एप्लिकेशन संशोधन और CVM के संचालन प्रदाता लॉग के रूप में काम करते हैं: एक Docker Compose कॉन्फ़िगरेशन जो डिप्लॉयमेंट के बाद बदला गया था, वह रिपोर्ट में विफल हो जाता है और समीक्षा के लिए पुनरारंभ सूचीबद्ध किए जाते हैं।

पैनल में Extras → Server 24/7 के अंतर्गत Confidential virtual machine · Phala Cloud चुनें और Phala Cloud API कुंजी पेस्ट करें; क्विक टनल Hetzner पर वैसे ही काम करता है। कमांड लाइन से:

python -m tgwitness.cloud deploy --provider phala --name case-1 --server-type tdx.small \
    --ref v0.8.0 --repository https://github.com/phishdestroy/TgWitness --quick-tunnel \
    --provider-token-file phala-key.txt
python -m tgwitness.cloud verify --record deployments/case-1/deployment.json \
    --provider-token-file phala-key.txt --cloud-init deployments/case-1/docker-compose.yaml \
    --source CHECKOUT_OF_COMMIT --fingerprint COLLECTOR_FINGERPRINT --report certificate.md
python -m tgwitness.cloud check-report --report certificate.pdf --verifier-fingerprint VERIFIER_KEY

--tdx-collateral इंटेल के प्रमाणपत्रों और रद्दीकरण सूचियों को इंटेल से डाउनलोड करने के बजाय एक फ़ाइल से पढ़ता है। गेटवे DNS यहां उपलब्ध नहीं है: फला के पास आउटगोइंग ट्रैफ़िक के लिए कोई प्रदाता फ़ायरवॉल नहीं है।

प्रमाणपत्र#

Phala deployment verify --report certificate.md प्रमाणपत्र भी लिखता है: एक स्वयं-निहित certificate.html और एक A4 certificate.pdf जिसमें निष्कर्ष, Intel की रूट से कलेक्टर कुंजी तक की विश्वास श्रृंखला, साधारण और उच्च-आश्वासन सर्वरों के साथ तुलना, प्रकाशित इमेज से गणना किए गए मानों के बगल में माप, प्रत्येक भाग के लिए कौन ज़मानत देता है, Intel प्रमाणपत्र श्रृंखला, हर जाँच, प्रदाता लॉग, और सत्यापन को दोहराने का तरीका शामिल है। JSON रिपोर्ट प्रामाणिक रिकॉर्ड बनी रहती है; पेज इसे प्रदर्शित करते हैं।

रिपोर्ट को certificate.seal.json और इसके बगल में रखी .tsq/.tsr फ़ाइलों में हस्ताक्षरों और समय-मुद्रणों के साथ डिजिटल रूप से सील किया गया है:

--timestamp URL (दोहराने योग्य) अन्य प्राधिकरणों को चुनता है, --timestamp none कोई नहीं, --sign-with none सील को बिना हस्ताक्षर के छोड़ देता है। check-report रिपोर्ट के हैश, सत्यापनकर्ता के हस्ताक्षर, प्रत्येक टाइमस्टैम्प को एक विश्वसनीय रूट और उसकी योग्य स्थिति से, और PDF के हस्ताक्षर की जाँच करता है। यूरोपीय संघ के बाहर एक योग्य टाइमस्टैम्प, और पूरी रिपोर्ट का कानूनी भार, इसे प्राप्त करने वाली अदालत या प्राधिकरण पर निर्भर करता है; सील यह दर्शाती है कि रिपोर्ट कब मौजूद थी और यह कि उसमें कोई बदलाव नहीं हुआ है।

एक प्रमाणीकरण Intel के TDX मॉड्यूल या माइक्रोकोड में किसी खामी, या मेमोरी बस तक भौतिक पहुँच को खारिज नहीं कर सकता। Phala के खाते में एप्लिकेशन को जो भी नियंत्रित करता है, वह एक और कंपोज़ तैनात कर सकता है; यह एक नए कंपोज़ हैश के साथ एक नए संस्करण के रूप में दिखाई देता है। होस्ट मशीन के समय स्रोत और नेटवर्क को नियंत्रित करता है।

डिप्लॉय, --evidence से सत्यापित करें, पुनरारंभ, OS इमेज की तुलना, डिजिटल रूप से सील किए गए हस्ताक्षरों और टाइमस्टैम्प वाले प्रमाणपत्र और नष्ट करें Phala Cloud पर ही चले हैं; देखें , 4 नवंबर 2026 का रन ।

शुरू करने से पहले#

1. एक Cloudflare ज़ोन, उसका अकाउंट आईडी, और एक API टोकन जिसमें Cloudflare Tunnel Edit, Zone Read और DNS Edit शामिल हैं, दिया गया --cloudflare-token-file या CLOUDFLARE_API_TOKENसत्यापनकर्ता के लिए: Cloudflare Tunnel Read, DNS Read और, ऑडिट लॉग के लिए, Account Settings Read। डोमेन के बिना, एक त्वरित टनल को इनमें से किसी की भी आवश्यकता नहीं होती है।
2. प्रदाता क्रेडेंशियल्स जिनकी लिखने की अनुमति एक समर्पित प्रोजेक्ट तक हो; lock इसी का उपयोग करता है:
   • Hetzner: रीड और राइट अनुमति वाला API टोकन;
   • DigitalOcean: लिखने की अनुमति वाला व्यक्तिगत एक्सेस टोकन;
   • Linode: व्यक्तिगत एक्सेस टोकन के साथ linodes, firewall और events रीड/राइट स्कोप्स के साथ;
   • Vultr: एक समर्पित खाते या उप-खाते की API कुंजी;
   • AWS: IAM क्रेडेंशियल्स की अनुमति ec2:DescribeVpcs, ec2:DescribeImages, ec2:CreateSecurityGroup, ec2:AuthorizeSecurityGroupIngress, ec2:RunInstances, ec2:CreateTags, ec2:DescribeInstances, ec2:DescribeSecurityGroupRules और ec2:RevokeSecurityGroupIngress.
3. चलाने के लिए commit। एक release tag एक बार अपने commit के साथ resolved होता है git ls-remote; सर्वर को केवल 40-अक्षर वाला कमिट ही प्राप्त होता है।

पैनल से#

अपने कंप्यूटर पर, Extras → Server 24/7 वही चलाता है deploy तीन चरणों में Hetzner के लिए: यूरोप या संयुक्त राज्य अमेरिका चुनें, एक Hetzner टोकन (पढ़ें और लिखें) पेस्ट करें, फिर सर्वर का प्रकार, मासिक मूल्य, पता और संस्करण की समीक्षा करें जो पैनल ने उस टोकन के साथ पाया। आप पुष्टि करने से पहले कुछ भी नहीं बनाया जाता है। पैनल प्रत्येक चरण को इस प्रकार दिखाता है deploy यह रिपोर्ट करता है, फिर पता, पैनल टोकन और साइनिंग की फिंगरप्रिंट। डोमेन के बिना सर्वर को एक त्वरित टनल मिलता है; आपके सर्वर → वर्तमान पता खोजें पुनरारंभ के बाद फिर से इसे देखता है। अपने स्वयं के डोमेन के तहत एक स्थिर पते के लिए, वैकल्पिक · अपना स्वयं का डोमेन खोलें और एक Cloudflare टोकन जोड़ें (तैयार लिंक ज़ोन पढ़ें, DNS संपादन और Cloudflare टनल संपादन का चयन करता है)।

टोकन ब्राउज़र टैब से उसी कंप्यूटर पर TgWitness तक प्रत्येक अनुरोध के साथ चलते हैं और कहीं भी लिखे नहीं जाते; डिप्लॉयमेंट रिकॉर्ड, संशोधित क्लाउड-इनिट, पैनल टोकन और, एक त्वरित टनल के लिए, एड्रेस की को में रखा जाता है deployments/NAME डेटा निर्देशिका के अंदर। पैनल यह केवल मुख्य प्रशासक को एक सीधे लूपबैक कनेक्शन पर प्रदान करता है (127.0.0.1, कोई प्रॉक्सी या टनल हेडर नहीं); एक पैनल जो नेटवर्क के माध्यम से पहुँचा जाता है, उसके बजाय कमांड दिखाता है। संस्करण डिफ़ॉल्ट रूप से चल रहे पैनल के रिलीज़ टैग पर होता है, जिसे GitHub API के माध्यम से हल किया जाता है। स्थान, सर्वर का प्रकार और कीमत Hetzner की API से आते हैं: cpx22 जहाँ यह पेश किया जाता है, अन्यथा कम से कम 2 GB मेमोरी के साथ सबसे सस्ता x86 प्रकार।

डोमेन के बिना त्वरित टनल#

--quick-tunnel replaces --zone, --cloudflare-account और --panel-host; कोई Cloudflare खाता या टोकन शामिल नहीं है:

python -m tgwitness.cloud deploy --provider hetzner --name case-2026-11 --server-type cpx22 \
    --ref 0123456789abcdef0123456789abcdef01234567 --quick-tunnel --provider-token-file hetzner.token

सर्वर पर, cloudflared पैनल के लिए एक त्वरित सुरंग खोलता है: एक यादृच्छिक https://….trycloudflare.com पता बदलता है जब भी cloudflared या सर्वर रीस्टार्ट होता है। सर्वर पर एक छोटी सेवा प्रत्येक पता को एक यादृच्छिक ntfy.sh विषय पर पोस्ट करती है, जिसे केवल डिप्लॉयमेंट डायरेक्टरी में मौजूद कुंजी से (HMAC-SHA256) हस्ताक्षरित किया गया है (address-key.txt), और इसे हर तीन घंटे में दोहराता है क्योंकि ntfy.sh पोस्ट को 12 के लिए रखता है। deploy और मौजूदा पता खोजें केवल हस्ताक्षरित पोस्ट स्वीकार करते हैं, इसलिए एक जाली पोस्ट आपको, और आपके पैनल टोकन को, किसी और के पते पर नहीं भेज सकती। टॉपिक रिकॉर्ड में है और प्रकाशित cloud-init में भी: जिसके पास भी ये हैं, वह वर्तमान पता पढ़ सकता है, जो अभी भी पैनल टोकन मांगता है। सर्वर किसी भी तरह से कोई इनबाउंड पोर्ट नहीं रखता।

एक वेरिफायर के पास एड्रेस की नहीं होती है, और कोई भी जो टॉपिक पढ़ता है, उसमें पोस्ट कर सकता है। इसलिए कलेक्टर भी एड्रेस को स्वयं पोस्ट करता है, जिसे अपनी ही Ed25519 की से साइन किया गया है, और verify डिप्लॉयमेंट रिकॉर्ड में कलेक्टर की से साइन की गई सबसे नई पोस्ट को लेता है; पोस्ट्स को उस समय के अनुसार क्रमबद्ध किया जाता है जब ntfy.sh ने उन्हें प्राप्त किया था, न कि उस समय के अनुसार जिसका वे दावा करती हैं। इस बदलाव से पहले का एक कलेक्टर कुछ भी साइन नहीं करता है, और फिर verify सबसे नई पोस्ट लेता है और statement चेक में ऐसा कहता है; एक जाली पोस्ट केवल उस चेक को विफल कर सकती है, क्योंकि एड्रेस को अभी भी कलेक्टर की कुंजी से जवाब देना होगा।

इसकी लागत: कोई क्लाउडफ्लेयर खाता एक त्वरित टनल का रिकॉर्ड नहीं रखता है, इसलिए verify टनल, कनेक्टर और DNS जांच को अनुपलब्ध के रूप में रिपोर्ट करता है और परिणाम सर्वोत्तम स्थिति में incomplete होता है (Phala पर क्लाउड में जाँच इसके बजाय पास हो जाती है: कनेक्टर मापे गए डॉकर कम्पोज कॉन्फ़िगरेशन के अंदर चलता है); प्रदाता रिकॉर्ड, फ़ायरवॉल, हस्ताक्षरित बयान, होस्ट माप और इंस्टॉलर की तुलना सामान्य रूप से जाँची जाती है। संदर्भ इंस्टॉलर के साथ बाइट तुलना के लिए एक तैनात कमिट की आवश्यकता होती है जो पहले से ही --quick-tunnel को जानता हो; एक 0.7.0 चेकआउट डोमेन इंस्टॉलर का निर्माण करता है और अंतर की रिपोर्ट करता है। क्लाउडफ्लेयर क्विक टनल्स को कोई अपटाइम गारंटी नहीं देता, एक साथ 200 अनुरोधों की अनुमति देता है और सर्वर-सेंट इवेंट्स को नहीं ले जाता है, इसलिए पैनल के लाइव अपडेट (0.7.0 के बाद के संस्करण) एक के माध्यम से नहीं आ सकते हैं और एक व्यू को फिर से लोड करने की आवश्यकता होती है; उस हिस्से को आजमाया नहीं गया है। एक ऐसे मामले के लिए जो कायम रहना है, अपना खुद का डोमेन उपयोग करें।

तैनात करें#

सबसे पहले वह सब देखें जो भेजा जाएगा। plan कोई प्रदाता या Cloudflare अनुरोध नहीं करता:

python -m tgwitness.cloud plan --provider hetzner --name case-2026-11 --server-type cpx22 \
    --ref 0123456789abcdef0123456789abcdef01234567 --zone example.org \
    --cloudflare-account CLOUDFLARE_ACCOUNT_ID --panel-host case.example.org

फिर उन्हीं विकल्पों और क्रेडेंशियल्स के साथ डिप्लॉय करें:

python -m tgwitness.cloud deploy --provider hetzner --name case-2026-11 --server-type cpx22 \
    --ref 0123456789abcdef0123456789abcdef01234567 --zone example.org \
    --cloudflare-account CLOUDFLARE_ACCOUNT_ID --panel-host case.example.org \
    --witness-host case-witness.example.org \
    --provider-token-file hetzner.token --cloudflare-token-file cloudflare.token

शुरू करने के लिए सर्वर प्रकार: cpx22 (Hetzner), s-1vcpu-2gb (DigitalOcean), g6-standard-1 (Linode), vc2-1c-2gb (Vultr), t3.small (AWS). --location और --image डिफ़ॉल्ट रूप से प्रत्येक प्रदाता का यूबंटू 24.04 यूरोपीय क्षेत्र में।

--repository दूसरे https Git रिपॉजिटरी से कमिट लेता है, URL में क्रेडेंशियल्स के बिना (डिफ़ॉल्ट https://github.com/phishdestroy/TgWitness.git). deploy भी स्वीकार करता है --out किसी अन्य डिप्लॉयमेंट डायरेक्टरी के लिए (डिफ़ॉल्ट deployments/NAME; एक ऐसी निर्देशिका जिसमें पहले से ही एक डिप्लॉयमेंट मौजूद है, उसे अस्वीकार कर दिया जाता है) और --wait, कलेक्टर के हस्ताक्षरित बयान का इंतजार करने के लिए मिनट: 1 से 240, डिफ़ॉल्ट 20, या के लिए 60 generic.

कमांड:

1. एक Cloudflare टनल बनाता है जिसकी इनग्रेस पैनल होस्टनेम को पैनल पर फॉरवर्ड करती है और, यदि दिया गया हो, तो विटनेस होस्टनेम को /api/witness/head और /api/assurance केवल;
2. उन होस्टनामों के लिए प्रॉक्सी किए गए CNAME रिकॉर्ड बनाता है, और पहले से मौजूद नामों को अस्वीकार करता है;
3. इनबाउंड नियमों के बिना एक प्रदाता फ़ायरवॉल और इसके पीछे कोई SSH कुंजी, कोई बैकअप, कोई कंसोल एजेंट, और cloud-init जो SSH को मास्क करता है, रूट को लॉक करता है, इंस्टॉल करता है cloudflared, ठीक उसी कमिट को प्राप्त करता है, उसकी जाँच करता है और TgWitness को एक मजबूत systemd सेवा के रूप में शुरू करता है;
4. कलेक्टर के हस्ताक्षरित बयान का इंतजार करता है और जांचता है कि उसमें इस सर्वर और इस cloud-init का हैश नामित किया गया है।

deployments/case-2026-11/ फिर रखता है:

प्रदाता का रूट पासवर्ड, टनल टोकन और पैनल टोकन कभी भी लिखे नहीं जाते deployment.jsonअंत में प्रिंट किए गए कलेक्टर फिंगरप्रिंट को केवल आपके नियंत्रण वाले चैनल के माध्यम से प्रकाशित करें, उदाहरण के लिए एक विटनेस चैनल या प्राप्तकर्ता को संदेश के रूप में।

Telegram में साइन इन करें https://case.example.org पैनल टोकन के साथ, जैसा कि खाता गाइड में है। पैनल क्रियाएँ हस्ताक्षरित जर्नल में दर्ज की जाती हैं; वे SSH सत्र नहीं हैं। एक विटनेस पोल कर सकता है https://case-witness.example.org.

कोई SSH नहीं है: यदि बूटस्ट्रैप विफल हो जाता है, तो कलेक्टर कभी जवाब नहीं देता। सर्वर को हटा दें और फिर से डिप्लॉय करें, या कारण खोजने के लिए डिबग डिप्लॉयमेंट का उपयोग करें।

उपयोगकर्ता डेटा में छिपे रहस्य#

क्लाउड-इनिट दो सीक्रेट्स रखता है: पैनल टोकन और क्लाउडफ्लेयर टनल टोकन। साइनिंग की उनमें शामिल नहीं है; यह सर्वर पर बनाई जाती है। हेत्ज़नर, डिजिटलओशन और लिनोड अपनी API के माध्यम से उपयोगकर्ता डेटा वापस नहीं करते हैं। Vultr इसे किसी भी की को लौटाता है जो इंस्टेंस को पढ़ सकती है, और EC2 के माध्यम से DescribeInstanceAttribute. AWS के लिए वेरिफायर को केवल तालिका में तीन क्रियाएँ दें, कभी भी ec2:Describe*. Vultr के लिए, मान लें कि सत्यापनकर्ता की कुंजी दोनों टोकन पढ़ सकती है। एक टनल टोकन किसी को दूसरा कनेक्टर चलाने देता है: verify सर्वर पर नहीं होने वाले किसी भी कनेक्टर की रिपोर्ट करता है, और कलेक्टर के बयानों को इस तरह से जाली नहीं बनाया जा सकता क्योंकि प्रत्येक एक नए चुनौती पर हस्ताक्षर करता है। के साथ --quick-tunnel दूसरा रहस्य इसके बजाय एड्रेस की (address key) है: जो कोई भी इसे पढ़ता है, वह एक झूठा पता पोस्ट कर सकता है जिसे पैनल स्वीकार कर लेगा।

संग्रहकर्ता का सार्वजनिक बयान सर्वर का पता और लॉगिन के स्रोतों को छोड़ देता है; दोनों हस्ताक्षरित जर्नल में रहते हैं।

डिबग डिप्लॉयमेंट और लॉक#

--debug-ssh-key KEY --debug-ssh-from 198.51.100.4 एक पते या छोटे नेटवर्क से एक कुंजी के लिए SSH को सीमित करता है, IPv4 के लिए अधिकतम एक /24 या IPv6 के लिए एक /48। KEY पहले से ही प्रदाता के साथ पंजीकृत है: Hetzner प्रोजेक्ट में एक SSH कुंजी का नाम या ID, DigitalOcean टीम में एक SSH कुंजी की ID या फिंगरप्रिंट, एक Linode उपयोगकर्ता नाम जिसके प्रोफ़ाइल में SSH कुंजियाँ रूट में जोड़ी जाती हैं, Vultr खाते में एक SSH कुंजी की ID, या क्षेत्र में एक EC2 कुंजी जोड़ी का नाम। ये विकल्प पर लागू नहीं होते generic. ऐसी तैनाती को के रूप में दर्ज किया जाता है debug और कभी नहीं को high-assurance के रूप में रिपोर्ट किया जाता है। जब आप समाप्त कर लें, तो चलाएँ sudo tgwitness-lock के रूप में अंतिम SSH सत्र की अंतिम कमांड के रूप में चलाएँ, फिर:

python -m tgwitness.cloud lock --record deployments/case-2026-11/deployment.json --provider-token-file hetzner.token

फ़ायरवॉल हर इनबाउंड नियम खो देता है। रिपोर्टें फिर दिखाती हैं कि SSH कब अनुमत था और कब इसे बंद किया गया था; वह विंडो दिखाई देती रहती है।

एक डिप्लॉयमेंट हटाएँ#

destroy सर्वर और उसके फ़ायरवॉल को हटाता है, जिसे डिप्लॉयमेंट के लेबल से खोजा जाता है ताकि आधी राह में असफल हुई डिप्लॉयमेंट को भी हटाया जा सके, फिर उन DNS रिकॉर्ड्स को जो उसकी टनल की ओर इशारा करते हैं, और टनल को हटाया जाता है। सर्वर का जर्नल और साइनिंग की इसके साथ ही हटा दिए जाते हैं: पहले सबूत को एक्सपोर्ट करें। रिकॉर्ड बना रहता है, चिह्नित removed, हटाने के API कॉल्स के साथ।

python -m tgwitness.cloud destroy --record deployments/case-2026-11/deployment.json --confirm case-2026-11 \
    --provider-token-file hetzner.token --cloudflare-token-file cloudflare.token

Hetzner के लिए API के माध्यम से हटाने की सुविधा लागू की गई है। अन्य प्रदाताओं के लिए destroy कुछ भी हटाने से पहले रुकता है और प्रदाता के कंसोल में हटाए जाने वाले लेबल का नाम बताता है। एक हाथ से इंस्टॉल किया गया सर्वर (generic) केवल अपने टनल और DNS रिकॉर्ड खोता है। एक त्वरित टनल परिनियोजन को Cloudflare टोकन की कोई आवश्यकता नहीं होती: इसका टनल सर्वर के साथ समाप्त होता है, और इसकी पोस्ट्स ntfy.sh से 12 घंटों के भीतर समाप्त हो जाती हैं।

कोई भी सर्वर (स्व-प्रमाणित)#

--provider generic हाथ से खरीदे या इंस्टॉल किए गए सर्वर के लिए है। deploy टनल और DNS बनाता है, लिखता है install.sh (निजी) और install.redacted.sh (प्रकाशित करने के लिए), और प्रतीक्षा करता है। कॉपी करें install.sh ताज़ा इंस्टॉल किए गए Ubuntu 24.04 सर्वर पर कॉपी करें और इसे वहाँ चलाएँ:

sudo bash install.sh

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

सत्यापित करें#

सत्यापनकर्ता को आवश्यकता है deployment.json, प्रकाशित इंस्टॉलर, केवल-पठन योग्य क्रेडेंशियल और, आदर्श रूप से, कमिट का एक चेकआउट और एक सबूत ZIP:

git clone -c core.autocrlf=false https://github.com/phishdestroy/TgWitness.git checkout
git -C checkout checkout 0123456789abcdef0123456789abcdef01234567
python -m tgwitness.cloud verify --record deployment.json \
    --provider-token-file read-only.token --cloudflare-token-file cloudflare-read.token \
    --fingerprint COLLECTOR_FINGERPRINT --cloud-init cloud-init.redacted.yaml \
    --source checkout --evidence tgwitness-evidence.zip --report report.md

प्रत्येक प्रदाता और Cloudflare मान उस क्षण सत्यापनकर्ता द्वारा अनुरोध किया जाता है; रिकॉर्ड केवल पूछने के लिए आईडी प्रदान करता है। एक्जिट कोड PASS के लिए 0, FAIL के लिए 1 और REVIEW, INCOMPLETE या SELF-ATTESTED के लिए 2 है। --fingerprint एक स्वतंत्र चैनल से आना चाहिए; इसके बिना कुंजी की तुलना केवल ऑपरेटर के रिकॉर्ड से की जाती है। python verify.py फिर भी प्रमाण को स्वयंZIP द्वारा सत्यापित किया जाता है, जैसा कि Evidence में है।

प्रोवाइडर क्रियाओं को वर्गीकृत किया जाता है: निर्माण और निर्माण के 30 मिनट के भीतर शुरू होने वाली क्रियाएँ पास हो जाती हैं; कंसोल, रेस्क्यू, पासवर्ड रीसेट, रीबिल्ड, ISO, इमेज, स्नैपशॉट, बैकअप, सिस्टम्स मैनेजर, EC2 इंस्टेंस कनेक्ट और फ़ायरवॉल ओपनिंग विफल हो जाती हैं; पावर क्रियाएँ और कोई भी अप्रत्याशित क्रिया समीक्षा के लिए चिह्नित की जाती हैं। एक अज्ञात क्रिया कभी भी चुपचाप पास नहीं होती।

साक्ष्य हस्तांतरण के लिए रिपोर्ट#

--report report.md मार्कडाउन रिपोर्ट लिखता है और report.json इसके बगल में:

1. परिणाम, कलेक्टर कुंजी फिंगरप्रिंट, परिनियोजन, प्रदाता, कमिट, सर्वर, फ़ायरवॉल, टनल;
2. हर जाँच अपनी स्थिति और स्रोत (प्रदाता API, Cloudflare API, कलेक्टर स्टेटमेंट, सबूत जर्नल) के साथ;
3. प्रत्येक क्रिया के मूल्यांकन के साथ प्रदाता का लॉग और, जहाँ प्रदाता इसे रिकॉर्ड करता है, वहाँ कर्ता;
4. क्लाउडफ्लेयर एंडपॉइंट्स जो टनल के कनेक्शन, कॉन्फ़िगरेशन और ऑडिट लॉग को होल्ड करते हैं;
5. हस्ताक्षरित कलेक्टर वक्तव्य;
6. रिपोर्ट क्या स्थापित करती है और क्या नहीं;
7. इसे पुन: उत्पन्न करने के लिए कमांड, और इसे दी गई प्रत्येक फ़ाइल का SHA-256।

रिपोर्ट सौंपें, report.json, deployment.json, प्रकाशित इंस्टॉलर और साक्ष्य ZIP। रिपोर्ट जल्दी प्रस्तुत करें: प्रदाता लॉग सीमित समय के लिए रखे जाते हैं।

बाहरी गवाह के रूप में क्लाउडफ्लेयर#

यहाँ सब कुछ वैकल्पिक है। Cloudflare खाते के बिना भी सर्वर चलता रहता है, और इनमें से दो आज काम करते हैं:

Logpush, जो Cloudflare की अपनी प्रति R2 में रखता है, एक एंटरप्राइज़ फ़ीचर है: मुफ़्त प्लान पर Cloudflare जवाब देता है logpush is not enabled for this account. वहाँ इसका गेटवे लॉग 24 घंटे तक रहता है, इसलिए एविडेंस मोड इसे साइन किए गए जर्नल में कॉपी करता है (Cloudflare गेटवे का इस सर्वर की DNS क्वेरीज़ का लॉग, एक रीड-ओनली टोकन जिसके पास अकाउंट एनालिटिक्स रीड की अनुमति है)।

ज़ीरो ट्रस्ट योजना के बिना एक खाते का एक DNS स्थान होता है। जब Cloudflare किसी अन्य को अस्वीकार करता है, तो सर्वर मौजूदा वाले को साझा करता है और उसकी क्वेरीज़ को उसके पते से अलग बताया जाता है; उस फ़िल्टर को भी ज़ीरो ट्रस्ट PII रीड की आवश्यकता होती है, और destroy एक साझा स्थान छोड़ देता है। एक लॉग क्वेरी अधिकतम तीन घंटे तक फैली होती है, इसलिए कॉपी और verify दिन को तीन-तीन घंटे के अंतराल में पढ़ता है।

गेटवे DNS सिस्टम रिज़ॉल्वर को कवर करता है। पोर्ट 443 पर HTTPS पर दूसरे रिज़ॉल्वर को DNS, और किसी भी जगह न खोजे गए पते (जैसे टेलीग्राम के डेटा सेंटर) से कनेक्शन, इसके लॉग में नहीं होते हैं।

Cloudflare टेलीग्राम के एन्क्रिप्शन के अंदर, टेलीग्राम खाते पर अन्य डिवाइस (एविडेंस मोड की डिवाइस सूची उन्हें टेलीग्राम की ओर से रिकॉर्ड करती है) या प्रदाता के हाइपरवाइज़र को नहीं देख सकता।

परिनियोजन परिणाम पढ़ना#

एक सामान्य वीएम के लिए, प्रदाता होस्ट इंफ्रास्ट्रक्चर को नियंत्रित करता है, और प्रदाता रिकॉर्ड के साथ-साथ स्थानीय इन्वेंट्री की जाँच की जाती है। Intel TDX के लिए, सत्यापनकर्ता अतिरिक्त रूप से हार्डवेयर उद्धरण, कलेक्टर बाइंडिंग, कम्पोज़ और ओएस माप की जाँच करता है। यह देखने के लिए व्यक्तिगत परिणाम पढ़ें कि कौन सी जाँचें पास हुईं या अनुपलब्ध थीं।

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