तीन हॉप, एक होस्ट: खऱ्या गोपनीयता-अवलंबित्वांची गणना
हॉप-संख्या सामायिक होस्टिंग, एक अॅडमिन खाते आणि तोच नोंदणीकर्ता लपवते. अवलंबित्वांची नोंदवही तयार करा, प्रत्येक ओळीचे मूल्यांकन करा आणि सामायिक मूल्य काय जोडते ते पहा.
दुसरा हॉप वेळेवर वर आला आणि तुमचा आकृती अजूनही तीन वेगळे प्रदाते दाखवते। नंतर बिले येतात आणि त्यांपैकी दोन एकाच होस्टिंग कंपनीचे नाव घेतात, तोच नोंदणीकर्ता तिन्ही डोमेन ठेवतो, आणि प्रत्येक खाते तुमच्या मालकीच्या एकाच मेलबॉक्समध्ये पुनर्संचयित होते। टनेल कॉन्फिगरेशनमध्ये काहीही तुटलेले नाही। डिझाइनने हॉपच्या खाली असलेल्या अवलंबित्वांची कधीही गणना केली नाही, आणि हॉप-संख्या रहदारी जो मार्ग घेते ते वर्णन करते, त्यावर कार्य करू शकणाऱ्या पक्षांची संख्या नाही।
लक्षण बिलिंगमध्ये दिसते, लॉगमध्ये नाही
तुम्हाला हे टनेल लॉगमध्ये सापडणार नाही, कारण टनेल तुम्ही कॉन्फिगर केलेलेच करत आहे। पुरावा सार्वजनिक नोंदी आणि खाते सेटिंग्जमध्ये राहतो: whois संस्थांची नावे जी एंडपॉइंट्समध्ये जुळतात, एकसारखे नाव सर्व्हर, सामायिक नोंदणीकर्ता पत्ता, एक पेमेंट पद्धत, एक नियंत्रण पॅनेल। यांपैकी प्रत्येक सूचना आहे की स्वतंत्रपणे अयशस्वी व्हायला हवीत अशा दोन स्तर एकत्र अयशस्वी होऊ शकतात।
यांपैकी कोणतीही सूचना हे सिद्ध करत नाही की कोणताही एकच पक्ष तुमची रहदारी वाचू शकतो। त्या जे कमी करतात ते म्हणजे दोन संरक्षण स्तर एकाच घटनेने तडकाफडकी होण्यापूर्वी चुकीचे व्हायला हवीत अशा स्वतंत्र निर्णयांची संख्या।
तुम्हाला खरोखर दिसणाऱ्या नोंदींची तुलना करा आणि काय तुलना केले ते लिहा। प्रत्येक एंडपॉइंट पत्त्यावर संस्था शोधा, प्रत्येक डोमेनचे नाव सर्व्हर सूचीबद्ध करा, आणि साखळीतील प्रत्येक खात्याची पुनर्प्राप्ती सेटिंग्ज उघडा। जिथे दोन मूल्ये जुळतात, तिथे जुळणी मालकीबद्दल आहे, कामकाजाबद्दल आहे, की फक्त पुनर्विक्रेत्याच्या पुढील भागाबद्दल हे नोंदवा। हे वेगवेगळे निष्कर्ष आहेत, आणि त्यांना एक मानणे हेच अवलंबित्व-पुनरावलोकन अंदाजात बदलण्याचे मार्ग आहे।
तार्किक मार्ग काढा, नंतर अवलंबित्व नकाशा
दोन आकृत्या लागतात, आणि बहुतेक लोक फक्त पहिली काढतात। तार्किक मार्ग दाखवतो की प्रत्येक संरक्षण स्तर कुठे संपतो आणि त्या एंडपॉइंटला काय निरीक्षण करता येते। अवलंबित्व नकाशा दाखवतो की यापैकी प्रत्येक एंडपॉइंट कोण चालवतो आणि प्रशासित करतो, जो पूर्णपणे वेगळा नावांचा संच आहे।
| Layer to record | Evidence you can collect | What a shared value would mean |
|---|---|---|
| Endpoint operator | Published operator, contract, support contacts | The same party sees two traffic layers |
| Compute and hosting | Address ranges, hosting brands, platform status pages | One administrative action affects two machines |
| Network dependency | Endpoints and transit links near the observation point | Two paths share a segment that could be watched once |
| Management | Control panels, SSH keys, staff with access | One credential compromise crosses both layers |
| Account linkage | Registration records, payment method, recovery mail | Two services can be tied to one identity |
प्रत्येक ओळ भरण्याऐवजी मूल्यांकन करा। ज्ञात म्हणजे तुम्ही असे नोंद पाहिली जी ते सांगते, अनुमानित म्हणजे एक निरीक्षण त्याला न सोडवता आधार देते, आणि अज्ञात म्हणजे काहीही सापडले नाही। सामायिक होस्टिंग ब्रँड सामायिक पायाभूत सुविधांबद्दलचे अनुमान आहे, सामायिक ग्राहक डेटाबेसबद्दलचे विधान नाही। फक्त अपेक्षित निष्कर्षासाठी सोयीचे आहे म्हणून अनुमानाला गुपचूप ज्ञात तथ्यात उंचावू नका।
रिकामी ओळ स्वतःच एक निष्कर्ष आहे। कोणते तथ्य कळल्यास निर्णय बदलेल ते सांगते, आणि ते एका प्रगल्भ विरोधकाला काय करता येईल याबद्दलच्या अजून एका परिच्छेदापेक्षा उपयुक्त आहे।
AS क्रमांक फक्त राउटिंग प्रश्नाचे उत्तर देतो
स्वायत्त प्रणाली ही राउटिंग प्रशासनाची संकल्पना आहे, पत्त्यांचा एक संच जो इतर नेटवर्कला एक सुसंगत राउटिंग दृश्य म्हणून सादर केला जातो। म्हणून वेगवेगळे AS क्रमांक कॉर्पोरेट मालकी, वेगळे कर्मचारी किंवा स्वतंत्र कायदेशीर नियंत्रणाबद्दल काहीही निर्णायक सांगत नाहीत। उलटी चूकही तितकीच सामान्य आहे: एका AS मध्ये दोन एंडपॉइंट स्वयंचलितपणे एक पक्ष विशिष्ट वापरकर्त्याची ओळख करण्याची घटना नाही।
जर तुम्हाला आकडे हवे असतील, तर गृहीत धरण्याऐवजी ते सोडवा। खालील पत्ता प्लेसहोल्डर आहे, आणि फ्लॅग साधनाला प्रत्येक हॉपला तो जाहीर करणाऱ्या AS ने लेबल करण्यास सांगतो।
mtr --aslookup --report --report-cycles 5 203.0.113.9तो आउटपुट राउटिंगचे मोजमाप माना, मालकीचे किंवा संपूर्ण रहदारी मार्गाचे नाही। तुम्ही ज्या प्रवेश नेटवर्कपासून सुरुवात करता आणि एंडपॉइंट्समधील ट्रान्झिट अवलंबित्वे हे वेगळे प्रश्न आहेत ज्यांचे उत्तर एंडपॉइंट पत्ते देऊ शकत नाहीत। जेव्हा एखादा मार्ग किंवा रिले निवड तुम्ही बसलेल्या ठिकाणाहून निरीक्षण करता येत नाही, तेव्हा विशिष्ट नेटवर्क आज मार्ग कसे निवडते याबद्दल सामान्य दावा आणू नका, त्याला अज्ञात म्हणून चिन्हांकित करा। अनिरीक्षित असणे निरीक्षण-अशक्य असण्यासारखे नाही, पण तो पुरावाही नाही।
जोखमीला नाव देण्यापूर्वी निरीक्षणाला नाव द्या
बहुतेक अवलंबित्व-पुनरावलोकनांमध्ये तीन निष्कर्ष मिसळतात, आणि ते वेगळे करणे हे कामाचा मोठा भाग आहे। एन्क्रिप्टेड रहदारीची निष्क्रिय दृश्यमानता एक निष्कर्ष आहे। सामायिक व्यवस्थापन प्रवेश दुसरा आहे, कारण तो दृश्य नव्हे तर कृती सूचित करतो। खाते-जोडणी तिसरी आहे, कारण ती कोणताही तांत्रिक प्रवेश न देता ओळखी जोडते।
यातील RFC 6973 मधील गोपनीयता मार्गदर्शन यासाठी व्यवहार्य स्वरूप देते: प्रत्येक घटक काय शिकतो त्याची यादी करा, नंतर ते अन्यत्र ठेवलेल्या माहितीसोबत कसे जोडता येईल ते विचारा। मार्गावरील दोन बिंदूंनी समान रहदारी नमुने निरीक्षण केल्यास परस्परसंबंधाची चिंता निर्माण होऊ शकते, पण ते तुम्हाला कोणी ओळखले गेले याची मोजलेली संभाव्यता देत नाहीत। चिंता लिहा, नंतर ती पुष्टी करणारे निरीक्षण लिहा।
दोन टनेल सेवा आणि भाड्याने घेतलेल्या प्रॉक्सीच्या साखळीकडे परत जा। प्रॉक्सीची व्यवस्थापन ओळखपत्रे एका टनेल सर्व्हरसोबत पुनर्प्राप्ती खाते सामायिक करत असतील, तर एकच प्रशासकीय तडजोड दोन्ही सीमा ओलांडू शकते। जर एकमेव ओव्हरलॅप म्हणजे एक होस्टिंग कंपनी दोन्ही मशीन चालवते, तर पुनरावलोकनाने त्या कंपनीकडे कोणते अधिकार आहेत आणि कोणती माहिती संरक्षित राहते हे सांगितले पाहिजे। तेच तीन हॉप, वेगळा निष्कर्ष।
नोंदवही ही अनामिकतेची प्रमाणपत्र नाही आणि कधीही होणार नाही। तिचे मूल्य अधिक संकुचित आणि व्यावहारिक आहे: ती दाखवते की स्वातंत्र्य कुठे स्थापित आहे, कुठे गृहीत धरले आहे, आणि कोणती एक अज्ञात ओळ निर्णय हलवेल। पुढच्या वेळी ती ओळ निवडा, आणि त्याचे उत्तर मिळेपर्यंत आकृतीचा उर्वरित भाग तसाच ठेवा।