VPN एक्झिटमधून येणाऱ्या गैरवापराच्या रहदारीची तक्रार कशी करावी
VPN एक्झिटमधून येणाऱ्या गैरवापराची तक्रार करा: रहदारी थांबवणे आणि व्यक्तीची ओळख पटवणे वेगळे ठेवा, कारवाई करू शकणारे माध्यम निवडा आणि मर्यादित पुरावे पाठवा.
VPN एक्झिटमधून येणारी रहदारी कोणी पाठवले हे न सांगताही गैरवापर असू शकते, आणि तुम्ही लिहिणारा अहवाल तीनपैकी कोणत्या प्रश्नाचे उत्तर देत आहात यावर अवलंबून असतो. रहदारी थांबवणे हे आज तुमचे काम आहे. पुरावे जतन करणे ही प्रक्रिया आहे. व्यक्तीची ओळख पटवण्यासाठी कायदेशीर प्रक्रिया लागते, जी बहुधा तुमच्याकडे नाही. हे तीन एकाच तक्रारीत मिसळल्यास अहवाल अपयशी ठरतात, कारण प्राप्तकर्ता फक्त आपल्या वाट्यावरच कारवाई करू शकतो.
प्रथम तीन प्रश्न वेगळे करा
तुम्हाला कोणता परिणाम हवा आहे हे ठरवून सुरुवात करा. उद्दिष्ट विनंत्या थांबवणे असेल, तर आज तुम्ही पत्ता श्रेणी अडवू शकता, खात्याचा दर मर्यादित करू शकता किंवा अंतिम बिंदू कठोर करू शकता, आणि गैरवापर अहवाल गौण आहे. उद्दिष्ट तपासणीत टिकणारी नोंद असेल, तर तुम्हाला वेळेच्या ठसे, विनंती ओळखणी आणि सुरक्षित जागी ठेवलेली न संपादित मूळ प्रत लागते. उद्दिष्ट पत्त्यामागील नाव असेल, तर तुम्हाला ऑपरेटरची कायदेशीर प्रक्रिया किंवा न्यायालयाचा आदेश लागतो, आणि कोणतीही खाजगी तक्रार त्याला पर्याय ठरत नाही.
ती मिसळल्यास नेहमीचा निरुपयोगी अहवाल तयार होतो: रागावलेला परिच्छेद, वेळ क्षेत्र नाही, ग्राहक तपशिलांची मागणी, आणि प्राप्तकर्त्याला मदत करायची असली तरी काय करता आले असते याचा कोणताही संकेत नाही. असा अहवाल कोणत्याही कारवाईशिवाय बंद होतो, आणि पाठवणारा गैरवापर डेस्क काहीच करत नाहीत असा निष्कर्ष काढतो. प्राप्तकर्त्याकडे कारवाई करण्यासारखे काहीच नव्हते.
ईमेल उघडण्यापूर्वी तीन उत्तरे लिहून ठेवा. तीच सूर, लांबी आणि विनंती ठरवतात.
एक्झिट पत्ता काय सिद्ध करतो आणि काय नाही
VPN शी जोडलेला पत्ता तुम्हाला सांगतो की रहदारी इंटरनेटमध्ये कुठून आली, ती कोणी सुरू केली हे नाही. व्यावसायिक एक्झिट अनेक ग्राहक एकाच वेळी सामायिक करतात, आणि त्यापुढील वाहक-स्तरीय NAT पोर्ट श्रेणी वापरून एक सार्वजनिक पत्ता हजारो ग्राहकांमध्ये विभागू शकते. RFC 6269 ते पत्ता-सामायिकरणाचे प्रतिरूप वर्णन करतो, आणि व्यावहारिक परिणाम असा की स्रोत पत्ता आणि वेळेचा ठसा ग्राहकाची ओळख फक्त तेव्हाच पटवू शकतात जेव्हा ऑपरेटरकडे त्या क्षणाचे नकाशन अजून असेल.
तुम्ही जे सिद्ध करू शकता ते नोंदवा. म्हणजे UTC वेळेत मूळ क्षेत्र नोंदवलेला वेळेचा ठसा, स्रोत पत्ता, स्रोत पोर्ट, प्रोटोकॉल आणि विनंती ओळखणी, आणि कृती प्रमाणित खात्यातून आली की अनामिक विनंतीतून. कच्ची नोंद ठेवा, नंतर प्राप्तकर्त्यासाठी संपादित प्रत तयार करा. लॉगमधील मूळ ओळीसाठी स्क्रीनशॉट हा कमजोर पर्याय आहे.
जतन कालावधी लहान असतात आणि ऑपरेटरनुसार वेगळे असतात. जितक्या लवकर विचाराल, तितकी नकाशन अजून असण्याची शक्यता जास्त, आणि समस्या आधीच कमी केली असली तरी लवकर तक्रार करण्याचे हेच मुख्य कारण आहे.
खरोखर कारवाई करू शकणारे माध्यम निवडा
तीन माध्यमे आहेत आणि ती परस्पर बदलता येत नाहीत. एक्झिट ऑपरेटरचा गैरवापर डेस्क आपल्या ग्राहकाची चौकशी करू शकतो आणि खाते निलंबित करू शकतो. पत्ता श्रेणीचा नोंदणी संपर्क whois नोंद जुनी झाली किंवा पुनर्विक्रेत्याची असल्यास योग्य ऑपरेटरकडे पाठवू शकतो. कायदा अंमलबजावणी संस्था संशयित गुन्हा, धमक्या आणि गंभीर उल्लंघन पाहतात, आणि बहुतेक न्यायक्षेत्रांत प्रकटीकरणास भाग पाडू शकते तेच माध्यम.
| Channel | What it can do | What it cannot do |
|---|---|---|
| Exit operator abuse desk | Investigate, warn or suspend the account | Disclose a subscriber to a private complainant |
| Registry contact | Identify the network holder and its abuse address | Act on the incident itself |
| Law enforcement | Preserve and compel records under legal process | Move faster than your own mitigation |
दोन अटी माध्यम निवडतात. घटना सुरू आहे का, जी प्रथम निवारण आणि समांतर तक्रारीच्या बाजूने आहे, की जुनी आहे, जी सर्वांपेक्षा आधी पुरावे जतन करण्याच्या बाजूने आहे? रहदारी थांबायला हवी आहे का, ज्यावर तीनही परिणाम करू शकतात, की ओळख हवी आहे, जी फक्त कायदेशीर मार्ग देऊ शकतो? तिसरी अट किती तपशील पाठवायचे ते ठरवते: एक्झिट चालवणाऱ्या ऑपरेटरला तांत्रिक तपशील लागतात, तर नोंदणी संपर्काला फक्त पत्ता श्रेणी आणि समस्या पुरेसे आहेत.
घटना सुरू असलेला गुन्हा असेल, तर गैरवापर डेस्क आणि अधिकारी हे पर्याय नाहीत. दोघांनाही तक्रार करा, आणि ऑपरेटरला सांगा की कायदेशीर विनंती येऊ शकते, जेणेकरून त्याचे स्वतःचे जतन धोरण सक्रिय होईल.
प्राप्तकर्ता ज्यावर कारवाई करू शकेल असा अहवाल लिहा
संदेश एका मिनिटात वाचता येईल इतका छोटा ठेवा. एक परिच्छेद काय घडले आणि कधी हे सांगतो, एक खंड अचूक वेळेच्या ठशांसह पुरावे सूचीबद्ध करतो, एक ओळ तुम्ही आधीच काय केले हे सांगते आणि एक ओळ तुम्ही काय मागता हे सांगते. प्रकरण संदर्भाची विनंती शेवटी ठेवा, जेणेकरून व्यस्त विश्लेषक संभाषणाऐवजी क्रमांकाने उत्तर देऊ शकेल.
तुम्ही पाठवत असलेल्या प्रतीतून गुपिते काढा. पासवर्ड, सत्र टोकन, असंबंधित वैयक्तिक डेटा आणि अंतर्गत होस्टनावे प्राप्तकर्त्याला मदत करत नाहीत आणि तुमची स्वतःची जोखीम वाढवतात. घटना कायदेशीर पुरावा बनू शकत असेल, तर न संपादित मूळ मर्यादित प्रवेशाच्या जागी आणि नोंदवलेल्या हॅशसह ठेवा. खालील आदेश काहीही लिहिण्यापूर्वी पत्त्याबद्दलची सार्वजनिक तथ्ये गोळा करतात.
whois 198.51.100.7 | grep -iE 'orgname|netrange|abuse'
dig +short -x 198.51.100.7
grep '198.51.100.7' /var/log/nginx/access.log | head -n 20तुम्ही प्रत्यक्ष पाहिलेला पत्ता टाका, आणि वरीलसारखी दस्तऐवजीकरण श्रेणी जिवंत नोंद परत करणार नाही हे लक्षात घ्या. whois आउटपुटने VPN ब्रँडऐवजी होस्टिंग पुरवठादाराचे नाव दिले, तर तोच योग्य प्राप्तकर्ता आहे, कारण पत्ता वाटप आणि ग्राहक संबंध त्याच्याकडे आहेत.
उत्तर हाताळा आणि नोंद ठेवा
शांतता म्हणजे काहीच घडले नाही असे नाही. ऑपरेटर नियमितपणे अहवालावर कारवाई करतात, तक्रारदाराला न सांगता, कारण ते ग्राहक माहिती उघड करू शकत नाहीत आणि त्यांचे धोरण तसे करण्यास मनाई करू शकते. प्रकरण क्रमांकासह छोटी पोच ही तुम्ही अपेक्षू शकता ती कमाल आहे, आणि अधिक तांत्रिक तपशील मागणे हा विलंब नव्हे तर चांगला संकेत आहे.
अहवाल खुला असताना कोणत्याही पत्त्यावर किंवा पुरवठादारावर आरोप प्रकाशित करू नका. सामायिक एक्झिटला दोषी म्हणणे त्या एक्झिटच्या इतर सर्व ग्राहकांना शिक्षा देते आणि प्रकरणानंतर कायदेशीर प्रक्रियेत गेल्यास हानी करू शकते. NIST चे घटना-प्रतिसाद मार्गदर्शन घटना नोंदींचे उगमस्थान आणि गोपनीयता प्रतिसादाचा भाग मानते, त्यानंतरचे कागदी काम नाही.
तुमच्या स्वतःच्या नोंदींमध्ये चक्र बंद करा: काय पाठवले, कोणाला, कधी, आणि त्यामुळे काय बदलले. हाच इतिहास पुढील घटनेला गोंधळातून ज्ञात पहिल्या पावलासह प्रक्रियेत बदलतो.