لنعد الوكلاء "المفتش"

ليس سراً أن النظام الآلي "Revizor" يراقب التحكم في الحجب في قائمة المعلومات المحظورة في روسيا. كيف يعمل مكتوب بشكل جيد هنا في هذا مقال عن هبرالصورة من هناك:

مثبتة مباشرة على المزود وحدة "المدقق الوكيل":

وحدة "المدقق الوكيل" هي عنصر هيكلي لنظام "المفتش" الآلي (AS "المفتش"). تم تصميم هذا النظام للتحكم في وفاء مشغلي الاتصالات بمتطلبات تقييد الوصول في إطار الأحكام المنصوص عليها في المواد 15.1-15.4 من القانون الاتحادي الصادر في 27 يوليو 2006 رقم 149-FZ "بشأن المعلومات وتقنيات المعلومات و حماية المعلومات ".

الغرض الرئيسي من إنشاء AS "Revizor" هو ضمان مراقبة امتثال مشغلي الاتصالات للمتطلبات المنصوص عليها في المواد 15.1-15.4 من القانون الاتحادي الصادر في 27 يوليو 2006 رقم 149-FZ "بشأن المعلومات وتقنيات المعلومات وحماية المعلومات "من حيث تحديد حقائق الوصول إلى المعلومات المحظورة والحصول على المواد الداعمة (البيانات) حول انتهاكات تقييد الوصول إلى المعلومات المحظورة.

مع الأخذ في الاعتبار حقيقة أنه ، إن لم يكن كل شيء ، قام العديد من مزودي الخدمة بتثبيت هذا الجهاز في المنزل ، كان ينبغي أن يكون قد تحول إلى شبكة كبيرة من منارات التحقيق مثل RIPE أطلس وأكثر من ذلك ، ولكن مع وصول مغلق. ومع ذلك ، فإن المنارة هي منارة لإرسال الإشارات في كل الاتجاهات ، ولكن ماذا لو أمسكنا بها ورأينا ما اصطدمنا به وكم؟

قبل العد ، دعنا نرى لماذا قد يكون هذا ممكنًا.

بعض نظرية

يتحقق الوكلاء من توفر المورد ، بما في ذلك من خلال طلبات HTTP (S) ، مثل هذا:

TCP, 14678  >  80, "[SYN] Seq=0"
TCP, 80  >  14678, "[SYN, ACK] Seq=0 Ack=1"
TCP, 14678  >  80, "[ACK] Seq=1 Ack=1"

HTTP, "GET /somepage HTTP/1.1"
TCP, 80  >  14678, "[ACK] Seq=1 Ack=71"
HTTP, "HTTP/1.1 302 Found"

TCP, 14678  >  80, "[FIN, ACK] Seq=71 Ack=479"
TCP, 80  >  14678, "[FIN, ACK] Seq=479 Ack=72"
TCP, 14678  >  80, "[ACK] Seq=72 Ack=480"

بالإضافة إلى الحمولة ، يتكون الطلب أيضًا من مرحلة إعداد الاتصال: التبادل SYN и SYN-ACK، ومراحل إنهاء الاتصال: FIN-ACK.

يحتوي سجل المعلومات المحظورة على عدة أنواع من الأقفال. من الواضح ، إذا تم حظر المورد بواسطة عنوان IP أو اسم المجال ، فلن نرى أي طلبات. هذه هي أكثر أنواع الحظر تدميراً والتي تؤدي إلى عدم توفر جميع الموارد على عنوان IP واحد أو جميع المعلومات الموجودة على المجال. هناك أيضًا نوع "URL" للحظر. في هذه الحالة ، يجب على نظام التصفية تحليل رأس طلب HTTP لتحديد ما يجب حظره بالضبط. وقبل ذلك ، كما يتضح أعلاه ، يجب أن تكون هناك مرحلة إعداد اتصال يمكنك محاولة تتبعها ، نظرًا لأن الفلتر سيفقدها على الأرجح.

للقيام بذلك ، تحتاج إلى تحديد مجال مجاني مناسب بنوع الحظر "بواسطة URL" و HTTP ، من أجل تسهيل عمل نظام التصفية ، ويفضل أن يكون نظامًا مهجورًا منذ فترة طويلة ، لتقليل دخول حركة المرور الخارجية باستثناء من الوكلاء. تبين أن هذه المهمة ليست صعبة على الإطلاق ، فهناك الكثير من المجالات المجانية في تسجيل المعلومات المحظورة ولكل ذوق. لذلك ، تم شراء المجال ، مرتبطًا بعناوين IP على VPS قيد التشغيل tcpdump وبدأ العد.

مراجعة "مراجعي الحسابات"

كنت أتوقع أن أرى دفعات دورية من الطلبات ، والتي من شأنها أن تشير ، في رأيي ، إلى إجراء محكوم. من المستحيل أن أقول إنني لم أره على الإطلاق ، لكن بالتأكيد لم تكن هناك صورة واضحة:

وهذا ليس مفاجئًا ، فحتى المجال غير الضروري على عنوان IP لم يتم استخدامه مطلقًا سيتلقى فقط كتلة من المعلومات غير المرغوب فيها ، مثل الإنترنت الحديث. لكن لحسن الحظ ، كنت بحاجة فقط إلى طلبات للحصول على عنوان URL محدد ، لذلك تم العثور بسرعة على جميع الماسحات الضوئية والقوة الغاشمة لكلمة المرور. أيضًا ، كان من السهل جدًا فهم مكان حدوث الفيضان بسبب كتلة الطلبات من نفس النوع. ثم جمعت تواتر حدوث عناوين IP ومشيت عبر الجزء العلوي بأكمله يدويًا مع فصل أولئك الذين تسللوا في المراحل السابقة. بالإضافة إلى ذلك ، قمت بقطع جميع المصادر التي أرسلت حزمة واحدة في كل مرة ، لم يكن هناك الكثير منها. وهذا ما حدث:

استطرادا غنائي صغير. بعد أكثر من يوم بقليل ، أرسل مزود الاستضافة الخاص بي خطابًا يحتوي على محتوى مبسط إلى حد ما ، قائلاً إن منشآتك بها مورد من القائمة المحظورة لـ ILV ، لذلك تم حظرها. في البداية اعتقدت أنه تم حظر حسابي ، لم يكن كذلك. ثم ظننت أنني تلقيت للتو تحذيرات بشأن ما أعرفه بالفعل. ولكن اتضح أن المستضيف قام بتشغيل عامل التصفية الخاص به أمام نطاقي ، ونتيجة لذلك ، تعرضت لفلترة مزدوجة: من مقدمي الخدمة ومن المضيف. اجتاز المرشح نهايات الطلبات فقط: FIN-ACK и RST قطع كل HTTP على عنوان URL المحظور. كما ترى من الرسم البياني أعلاه ، بعد اليوم الأول بدأت في تلقي بيانات أقل ، لكنني ما زلت أتلقىها ، وهو ما كان كافياً لمهمة حساب مصادر الاستعلام.

أوضح ماذا تقصد. في رأيي ، تظهر رشقتان بوضوح كل يوم ، الأولى أصغر ، بعد منتصف الليل بتوقيت موسكو ، والثانية أقرب إلى السادسة صباحًا مع ذيل يصل إلى 6 ظهرًا. الذروة لا تحدث بالضبط في نفس الوقت. في البداية ، أردت تسليط الضوء على عناوين IP التي وقعت فقط في هذه الفترات وكل فترة في جميع الفترات ، بناءً على افتراض أن عمليات التحقق من الوكيل يتم إجراؤها بشكل دوري. ولكن عند الفحص الدقيق ، اكتشفت بسرعة فترات تقع في فترات زمنية أخرى ، مع ترددات أخرى ، حتى طلب واحد كل ساعة. ثم فكرت في المناطق الزمنية وقد يكون الأمر كذلك ، ثم اعتقدت أنه بشكل عام قد لا تتم مزامنة النظام عالميًا. بالإضافة إلى ذلك ، بالتأكيد ، ستلعب NAT دورها ويمكن للوكيل نفسه تقديم طلبات من عناوين IP عامة مختلفة.

نظرًا لأن هدفي الأصلي لم يكن بالضبط ، فقد أحسبت عمومًا جميع العناوين التي تلقيتها في غضون أسبوع وحصلت عليها - 2791. عدد جلسات برنامج التعاون الفني التي تم إنشاؤها من عنوان واحد هو 4 في المتوسط ​​، بمتوسط ​​2. جلسات عليا لكل عنوان: 464 ، 231 ، 149 ، 83 ، 77. الحد الأقصى من 95٪ من العينة هو 8 جلسات لكل عنوان. المتوسط ​​ليس مرتفعًا جدًا ، دعني أذكرك أن الرسم البياني يظهر دورية يومية واضحة ، لذلك يمكنك أن تتوقع شيئًا يتراوح من 4 إلى 8 في 7 أيام. إذا تخلصنا من جميع الجلسات التي تحدث مرة واحدة ، فسنحصل فقط على متوسط ​​يساوي 5. لكنني لم أستطع استبعادها على أساس واضح. على العكس من ذلك ، أظهر الفحص العشوائي أنها مرتبطة بطلبات مصدر محظور.

العناوين هي العناوين ، وعلى الإنترنت ، تعتبر الأنظمة المستقلة أكثر أهمية - AS ، والتي تبين أنها كذلك 1510، متوسط ​​عنوانين لكل AS بمتوسط ​​2. أهم العناوين لكل AS: 1 ، 288 ، 77 ، 66 ، 39. الحد الأقصى من 27٪ من العينة هو 95 عناوين لكل AS. هنا يتوقع الوسيط - وكيل واحد لكل مزود. القمة متوقعة أيضًا - هناك لاعبون كبار فيها. في شبكة كبيرة ، من المحتمل أن يكون الوكلاء في كل منطقة من مناطق وجود المشغل ، ولا تنسى NAT. إذا أخذناها حسب البلد ، فستكون الحدود القصوى: 4 - RU ، 1409 - UA ، 42 - CZ ، 23 من مناطق أخرى ، وليس RIPE NCC. الطلبات ليست من روسيا تجذب الانتباه. على الأرجح ، يمكن تفسير ذلك من خلال أخطاء تحديد الموقع الجغرافي أو أخطاء المسجل عند ملء البيانات. أو حقيقة أن شركة روسية قد لا يكون لها جذور روسية ، أو أن يكون لها مكتب تمثيلي أجنبي لأنه أسهل بهذه الطريقة ، وهو أمر طبيعي عند التعامل مع منظمة أجنبية RIPE NCC. جزء ما هو بلا شك غير ضروري ، ولكن من الصعب أصلاً فصله ، نظرًا لأن المورد قيد الحظر ، ومن اليوم الثاني يخضع لحظر مزدوج ، ومعظم الجلسات هي مجرد تبادل لعدة حزم خدمة. دعنا نتفق على أن هذا جزء صغير.

يمكن مقارنة هذه الأرقام بالفعل مع عدد مقدمي الخدمة في روسيا. وفقًا لـ RKN تراخيص "خدمات الاتصال لنقل البيانات ، باستثناء الصوت" - 6387 ، ولكن هذا تقدير مرتفع للغاية من الأعلى ، ولا تنطبق جميع هذه التراخيص بشكل خاص على مزودي الإنترنت الذين يحتاجون إلى تثبيت وكيل. في منطقة RIPE NCC ، هناك عدد مماثل من AS مسجل في روسيا هو 6230 ، وليس كل مقدمي الخدمة. UserSide أجرى حسابات أكثر صرامة وحصلت على 3940 شركة في عام 2017 ، وهذا تقدير أعلى بالأحرى. على أي حال ، لدينا عدد أقل مرتين ونصف من ASs المضيئة. ولكن هنا يجدر بنا أن نفهم أن AS لا يساوي بدقة المزود. لا يمتلك بعض مقدمي الخدمة AS الخاصة بهم ، والبعض الآخر لديهم أكثر من واحد. إذا افترضنا أن كل شخص لا يزال لديه وكلاء ، فعندئذٍ يقوم شخص ما بتصفية أكثر من الآخرين ، لذلك لا يمكن تمييز طلباتهم عن القمامة ، إذا وصلت على الإطلاق. لكن بالنسبة لتقدير تقريبي ، فهو مقبول تمامًا ، حتى لو فقد شيء ما بسبب إشرافي.

حول DPI

على الرغم من حقيقة أن مزود الاستضافة الخاص بي قام بتشغيل الفلتر الخاص به بدءًا من اليوم الثاني ، وفقًا للمعلومات الخاصة باليوم الأول ، يمكننا أن نستنتج أن الحظر يعمل بنجاح. تمكنت 4 مصادر فقط من الاختراق وأكملت جلسات HTTP و TCP بالكامل (كما في المثال أعلاه). يمكن إرسال 460 آخر GET، ولكن تم إنهاء الجلسة على الفور بواسطة RST. انتبه على TTL:

TTL 50, TCP, 14678  >  80, "[SYN] Seq=0"
TTL 64, TCP, 80  >  14678, "[SYN, ACK] Seq=0 Ack=1"
TTL 50, TCP, 14678  >  80, "[ACK] Seq=1 Ack=1"

HTTP, "GET /filteredpage HTTP/1.1"
TTL 64, TCP, 80  >  14678, "[ACK] Seq=1 Ack=294"

#Вот это прислал фильтр
TTL 53, TCP, 14678  >  80, "[RST] Seq=3458729893"
TTL 53, TCP, 14678  >  80, "[RST] Seq=3458729893"

HTTP, "HTTP/1.1 302 Found"

#А это попытка исходного узла получить потерю
TTL 50, TCP ACKed unseen segment, 14678 > 80, "[ACK] Seq=294 Ack=145"

TTL 50, TCP, 14678  >  80, "[FIN, ACK] Seq=294 Ack=145"
TTL 64, TCP, 80  >  14678, "[FIN, ACK] Seq=171 Ack=295"

TTL 50, TCP Dup ACK 14678 > 80 "[ACK] Seq=295 Ack=145"

#Исходный узел понимает что сессия разрушена
TTL 50, TCP, 14678  >  80, "[RST] Seq=294"
TTL 50, TCP, 14678  >  80, "[RST] Seq=295"

يمكن أن تكون الاختلافات في هذا مختلفة: أقل RST أو المزيد من عمليات إعادة الإرسال - يعتمد ذلك أيضًا على ما يرسله الفلتر إلى العقدة المصدر. على أي حال ، هذا هو النمط الأكثر موثوقية والذي يمكن من خلاله ملاحظة أن المورد المحظور هو المطلوب. بالإضافة إلى أن هناك دائمًا رد يظهر في الجلسة مع TTL أكبر من الحزم السابقة واللاحقة.

لا يمكنك حتى أن ترى من البقية GET:

TTL 50, TCP, 14678  >  80, "[SYN] Seq=0"
TTL 64, TCP, 80  >  14678, "[SYN, ACK] Seq=0 Ack=1"

#Вот это прислал фильтр
TTL 53, TCP, 14678  >  80, "[RST] Seq=1"

أو هكذا:

TTL 50, TCP, 14678  >  80, "[SYN] Seq=0"
TTL 64, TCP, 80  >  14678, "[SYN, ACK] Seq=0 Ack=1"
TTL 50, TCP, 14678  >  80, "[ACK] Seq=1 Ack=1"

#Вот это прислал фильтр
TTL 53, TCP, 14678  >  80, "[RST, PSH] Seq=1"

TTL 50, TCP ACKed unseen segment, 14678 > 80, "[FIN, ACK] Seq=89 Ack=172"
TTL 50, TCP ACKed unseen segment, 14678 > 80, "[FIN, ACK] Seq=89 Ack=172"

#Опять фильтр, много раз
TTL 53, TCP, 14678  >  80, "[RST, PSH] Seq=1"
...

يمكنك بالتأكيد رؤية الفرق في TTL إذا وصل شيء من المرشح. لكن في كثير من الأحيان لا يمكن لأي شيء أن يطير على الإطلاق:

TCP, 14678  >  80, "[SYN] Seq=0"
TCP, 80  >  14678, "[SYN, ACK] Seq=0 Ack=1"
TCP Retransmission, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
...

أو هكذا:

TCP, 14678  >  80, "[SYN] Seq=0"
TCP, 80  >  14678, "[SYN, ACK] Seq=0 Ack=1"
TCP, 14678  >  80, "[ACK] Seq=1 Ack=1"

#Прошло несколько секунд без трафика

TCP, 80  >  14678, "[FIN, ACK] Seq=1 Ack=1"
TCP Retransmission, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
...

وكل هذا يتكرر ويتكرر ويتكرر ، كما ترون على الرسم البياني ، ليس مرة واحدة بالضبط كل يوم.

حول IPv6

الخبر السار هو هو. أستطيع أن أقول على وجه اليقين أن هناك طلبات دورية للمصدر المحظور من 5 عناوين IPv6 مختلفة ، وهو بالضبط سلوك الوكلاء الذي توقعته. علاوة على ذلك ، لا يندرج أحد عناوين IPv6 تحت التصفية وأرى جلسة كاملة. من بين جلستين أخريين ، رأيت جلسة واحدة غير مكتملة ، تم مقاطعة واحدة منها RST من الفلتر ، والثاني في الوقت المناسب. المبلغ الإجمالي 7.

نظرًا لوجود عدد قليل من العناوين ، فقد قمت بدراستها جميعًا بالتفصيل واتضح أن هناك في الواقع ثلاثة مزودين فقط ، ويمكن أن يتم ترحيبي بهم بحفاوة بالغة! عنوان آخر هو استضافة سحابية في روسيا (لا يتم التصفية) ، وآخر هو مركز أبحاث في ألمانيا (هل يوجد مرشح ، أين؟). لكن لماذا يتحققون من توافر الموارد المحظورة في جدول هو سؤال جيد. قدم الاثنان المتبقيان طلبًا واحدًا ويقعان خارج روسيا ، وتم تصفية أحدهما (بعد كل شيء ، قيد العبور؟).

تعتبر الأقفال والوكلاء بمثابة كبح كبير على IPv6 ، والذي لا يتحرك بسرعة كبيرة على أي حال. أنه لأمر محزن. يمكن لأولئك الذين حلوا هذه المشكلة أن يكونوا فخورين بأنفسهم تمامًا.

في الختام

لم أتابع الدقة بنسبة 100٪ ، أطلب منك أن تسامحني على هذا ، أتمنى أن يكرر أحد هذا العمل بدقة أكبر. كان من المهم بالنسبة لي أن أفهم ما إذا كان مثل هذا النهج سيعمل من حيث المبدأ. الجواب هو سوف. أعتقد أن الأرقام التي تم الحصول عليها في التقريب الأول موثوقة تمامًا.

ما الذي يمكن فعله أيضًا وما كنت كسولًا جدًا لفعله - احسب طلبات DNS. لم يتم تصفيتها ، لكنها لا تقدم الكثير من الدقة أيضًا ، لأنها تعمل فقط للمجال ، وليس عنوان URL بأكمله. يجب أن تكون الدورية مرئية. إذا تم دمجها مع ما هو مرئي مباشرة في الاستعلامات ، فسيتيح لك ذلك فصل الفائض والحصول على مزيد من المعلومات. بل إنه من الممكن تحديد مطوري DNS الذين يستخدمهم مزودو خدمات الإنترنت وغير ذلك الكثير.

لم أكن أتوقع على الإطلاق أنه بالنسبة لخادم VPS الخاص بي ، فإن المضيف سيشمل أيضًا عامل التصفية الخاص به. ربما هذه ممارسة شائعة. في النهاية ، يرسل RKN طلبًا لحذف المورد فقط إلى المضيف. لكن ذلك لم يفاجئني ، بل وحتى في مكان ما لعب لصالحه. عمل عامل التصفية بشكل فعال للغاية ، حيث تم قطع جميع طلبات HTTP الصالحة إلى عنوان URL المحظور ، ولكن ليس الطلبات الصحيحة ، والتي كانت قد مرت سابقًا من خلال مرشح الموفر ، ولكن فقط في شكل نهايات: FIN-ACK и RST - ناقص إلى ناقص وكاد أن يكون زائدًا. بالمناسبة ، لم يتم تصفية IPv6 من قبل المضيف. بالطبع ، أثر هذا على جودة المواد التي تم جمعها ، لكنه لا يزال يجعل من الممكن رؤية التواتر. اتضح أن هذه نقطة مهمة عند اختيار موقع لاستضافة الموارد ، فلا تنس أن تهتم بتنظيم العمل بقائمة المواقع المحظورة والطلبات من RKN.

في البداية ، قارنت AS "Revizor" بـ RIPE أطلس. هذه المقارنة مبررة تمامًا ويمكن أن تكون شبكة كبيرة من الوكلاء مفيدة. على سبيل المثال ، تحديد جودة توافر مورد من مختلف مقدمي الخدمات في أجزاء مختلفة من الدولة. يمكنك حساب التأخيرات ، يمكنك إنشاء الرسوم البيانية ، يمكنك تحليلها جميعًا ورؤية التغييرات التي تحدث محليًا وعالميًا. ليست هذه هي الطريقة الأكثر مباشرة ، لكن علماء الفلك يستخدمون "الشموع القياسية" ، فلماذا لا تستخدم الوكلاء؟ معرفة (إيجاد) سلوكهم القياسي ، من الممكن تحديد التغييرات التي تحدث من حولهم وكيف يؤثر ذلك على جودة الخدمات المقدمة. وفي الوقت نفسه ، لا تحتاج إلى وضع المجسات بشكل مستقل عبر الشبكة ، فقد تم بالفعل تثبيتها بواسطة Roskomnadzor.

نقطة أخرى أريد أن أتطرق إليها هي أن كل أداة يمكن أن تكون سلاحًا. AS "Revizor" هي شبكة مغلقة ، لكن الوكلاء يتخلون عن الجميع بإرسال طلبات لجميع الموارد من القائمة المحظورة. وجود مثل هذا المورد لا يمثل أي مشاكل على الإطلاق. في المجموع ، يخبر مقدمو الخدمة من خلال الوكلاء ، عن غير قصد ، الكثير عن شبكتهم أكثر مما قد يكون مفيدًا: أنواع DPI و DNS وموقع الوكيل (العقدة المركزية وشبكة الخدمة؟) وتأخير الشبكة وعلامات الخسارة - وهذا هو الأكثر بديهي. مثلما يمكن لشخص ما مراقبة تصرفات الوكلاء لتحسين توافر مواردهم ، يمكن لشخص ما القيام بذلك لأغراض أخرى ولا توجد عقبات أمام ذلك. لقد ظهرت أداة ذات حدين ومتعددة الأوجه ، يمكن لأي شخص أن يقتنع بذلك.

المصدر: www.habr.com