Roskomnadzor की साइटों की सूची के साथ समस्याएं। टेलीकॉम ऑपरेटर, सतर्क रहें

हाय, हैब्र।


हमने पहले ही लिखा था कि हमारे नेटवर्क और हमारे ग्राहकों की साइटों के प्रवेश को रोकने की स्वचालित निगरानी के लिए रोसकोमनादज़ोर की निषिद्ध सामग्रियों की सूची तक पहुँच प्राप्त करना गैर-तुच्छ कैसे था। दुर्भाग्य से, कई रेक पर हमले की कहानी एक निरंतरता है, इसलिए हम इसे साझा करना चाहते हैं। वर्णित जानकारी मुख्य रूप से दूरसंचार ऑपरेटरों के लिए उपयोगी होगी, जो हम स्थिति पर नजर रखते हैं, वे रोसकोम्नाडज़ोर सूची में संसाधन हैं।

इसलिए, नवंबर में स्वचालित निगरानी शुरू करते हुए, हमने घंटे X - सूची में एक ग्राहक संसाधन की उपस्थिति का इंतजार करना शुरू कर दिया। एक तरफ, निश्चित रूप से, सुखद बात यह है कि आपको क्लाइंट से संपर्क करने और अवरुद्ध जानकारी को हटाने के मुद्दे को हल करने की आवश्यकता है, यह पर्याप्त नहीं है, खासकर जब से हम याद करते हैं कि वे प्रतिक्रिया के लिए 1 दिन देते हैं, जो टेलीकॉम ऑपरेटर को ज्ञापन में लिखा जाता है , दूसरी तरफ। दूसरी ओर, पहले किए गए सभी परीक्षण सिंथेटिक एक ही रास्ता या किसी अन्य थे, और अंदर डेवलपर बेसब्री से वास्तविक डेटा पर काम करने के लिए इंतजार कर रहा था, हर संभव तरीके से तकनीकी सहायता और प्रशासकों को खुशी से सूचित कर रहा था। आखिरकार, यह कितना सुखद है (डेवलपर्स के लिए, प्रशासकों के लिए) लॉग जानकारी में देखने के लिए कि सर्वर क्रैश हो गया है, लेकिन डुप्लिकेट एक - लोड को अपने ऊपर खींच लिया, कि मास्टर बेस गिर गया, लेकिन प्रतिकृति ने इसे बदल दिया, आदि। एक शब्द में, सिस्टम को कार्रवाई में देखना सिर्फ दिलचस्प था।

और इसलिए, 27 दिसंबर को, हमें Roskomnadzor से एक ईमेल मिला कि हमारी क्लाइंट साइट www.tourister.ru का पेज दुर्भाग्यपूर्ण सूची में है। तथ्य यह है कि Turister.ru पर्यटकों के लिए एक ऐसा सामाजिक नेटवर्क है जहां लोग विभिन्न यात्राओं के बारे में समीक्षा, समीक्षा और जीवन हैक करते हैं। और एक अवरुद्ध लेख में यह बताया गया कि एम्स्टर्डम कैसे जाना है और वहां क्या घास खरीदने लायक है। यह ध्यान देने योग्य है कि अवरुद्ध करने का कारण काफी समझ में आता है और कोई विशेष प्रश्न नहीं उठाता है, इसलिए हमने जल्दी से संसाधन प्रशासन से संपर्क किया और परिणामस्वरूप लेख को हटा दिया गया। सब कुछ खुश और अंत लग रहा था, लेकिन हम एक चीज से चिंतित थे - इस सभी समय के लिए निषिद्ध संसाधनों की हमारी निगरानी ने इस स्थिति पर प्रतिक्रिया नहीं की। यानी कर्मचारियों की सूची में, अगले हौसले से भरे डंप के बारे में रिपोर्ट हमारे हेल्पडेस्क में आई, लेकिन इस बात की कोई जानकारी नहीं थी कि Tourister.ru को हटा दिया गया था:



बेशक, चीजों के इस क्रम ने हमें बहुत चिंतित किया और हमने डाउनलोड किए गए डंपों की जांच करना शुरू कर दिया, क्योंकि विशेष रूप से इसी तरह की स्थिति के मामले में, हम लोड किए गए डेटाबेस का इतिहास रखते हैं।

वैसे, मैं डंप के बारे में एक दिलचस्प विशेषता को अलग से नोट करना चाहूंगा। जैसा कि आप जानते हैं, साइट zapret-info.gov.ru रजिस्ट्री डेटाबेस को उतारने के लिए एक आरपीसी इंटरफ़ेस प्रदान करती है। प्रलेखन में 3 विधियां घोषित की गई हैं :

1. getLastDumpDate - रजिस्ट्री से अनलोड के अंतिम अद्यतन का टाइमस्टैम्प लौटाता है।
2. sendRequest - अनुरोध भेजने के लिए एक विधि, जिसके जवाब में एक परिणाम कोड लौटाया जाता है।
3. getResult परिणाम प्राप्त करने की विधि है।

वास्तव में, निम्नलिखित मामले को मान लिया गया है:

• हम टाइमस्टैम्प के लिए एक अनुरोध करते हैं, और अगर यह पिछली बार बदल गया है, तो हम आगे की कार्रवाई करते हैं। सिद्धांत रूप में, यह तार्किक है - हम ट्रैफ़िक को बचाते हैं और अनावश्यक लोड से रोसकोमनादज़ोर के सर्वर (?) की रक्षा करते हैं। यदि टाइमस्टैम्प अपरिवर्तित है, तो हम इस डंप के संसाधनों की निगरानी करते हैं।
• हम एक अनुरोध बनाते हैं और भेजते हैं। हमें कोड मिलता है।
• कोड द्वारा - हम एक डंप प्राप्त करते हैं और पहले से ही इस पर अपने संसाधनों की जांच करते हैं।

हमने इसे लागू किया, लेकिन बहुत जल्दी हमने देखा कि प्रत्येक निगरानी रिपोर्ट में एक ताज़ा डाउनलोड किया हुआ डंप होता है, जबकि फ़ाइल आकार और समाहित दस्तावेज़ों की संख्या अपरिवर्तित रहती है। डिफेंस-टूल के माध्यम से फाइलों के त्वरित रन से पता चला कि फाइलें केवल टाइमस्टैम्प मूल्य में भिन्न होती हैं। वास्तव में, अंतिम अपलोड की तारीख वर्तमान समय का मूल्य है, जिसमें मिनट और सेकंड छूट गए हैं। परिणामस्वरूप, ट्रैफ़िक और संसाधनों को बचाने का पूरा विचार बस काम नहीं करता है।

इसलिए, पिछले कुछ दिनों में सभी डंपों को देखने के बाद, हम इस नतीजे पर पहुंचे कि उनके पास दौरे के समय पेज को ब्लॉक करने के बारे में रिकॉर्ड नहीं है:



इसी समय, zapret-info वेब इंटरफ़ेस नियमित रूप से लॉक के बारे में जानकारी प्रदर्शित करता है:



बेशक , हमने zapret-info@rsoc.ru को प्रश्नों के साथ एक पत्र लिखा था, लेकिन अभी तक हमें जवाब नहीं मिला है।

निष्कर्ष के रूप में, मैं इस विषय पर पिछले लेख से खुद को उद्धृत करना चाहूंगा:

कभी-कभी सरकारी एजेंसियों के साथ काम करने से जुड़े कार्य पूरी तरह से अप्रत्याशित जगह पर हस्तक्षेप कर सकते हैं।

तो, प्रिय दूरसंचार ऑपरेटरों, सावधान रहें।

UPD: टिप्पणियों में, Roskomnadzor, Ksenzov Maxim Yuryevich, Ksenzov के डिप्टी हेड, zapret-info के काम से जुड़े सवालों के जवाब देते हैं। हैबर-यूज़र्स का ध्यान, आइए केवल केन्सज़ोव को माइनस न करें क्योंकि वह संगठन का प्रतिनिधि है, रजिस्ट्री को ध्यान में रखते हुए कि हर कोई यहाँ नफरत करता है, क्योंकि तब हम "दूसरी तरफ" से जवाब और टिप्पणियां सुनने का अवसर खो देंगे।