عد عملاء "ممتحن"

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



يتم تثبيت وحدة "Agent Auditor" الخاصة بالمزود مباشرة في المزود:

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

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

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

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

قليلا من الناحية النظرية

يتحقق الوكلاء من توفر المورد ، بما في ذلك من خلال طلبات 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 في الصباح مع ذيل يصل إلى 12 يومًا. الذروة لا تحدث بالضبط في نفس الوقت. أولاً ، أردت تسليط الضوء على عناوين IP التي سقطت فقط في هذه الفترات وكل منها في جميع الفترات ، بناءً على افتراض أن الوكلاء يتحققون بشكل دوري. ولكن عند المشاهدة الدقيقة ، اكتشفت بسرعة فترات تندرج في فواصل زمنية أخرى ، بترددات مختلفة ، وحتى طلب واحد كل ساعة. ثم فكرت في المناطق الزمنية وما هو ممكن فيها ، ثم اعتقدت أنه بشكل عام قد لا تتم مزامنة النظام على مستوى العالم. بالإضافة إلى ذلك ، بالتأكيد ، ستلعب NAT دورها ، ويمكن للوكيل نفسه تقديم طلبات من مختلف عناوين IP العامة.

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

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

يمكن بالفعل مقارنة هذه الأرقام بعدد مقدمي الخدمات في روسيا. وفقًا لـ ILV ، فإن تراخيص "خدمات الاتصالات لنقل البيانات ، باستثناء الصوت" ، هي 6387 ، ولكن هذا تصنيف مرعب للغاية من أعلى ، وليس كل هذه التراخيص مخصصة لموفري الإنترنت الذين يحتاجون إلى تثبيت Agent. في منطقة RIPE NCC ، يوجد عدد مماثل من AS مسجل في روسيا هو 6230 ، وليس كل مقدمي الخدمات. قام UserSide بحساب أكثر صرامة وتلقى 3940 شركة في عام 2017 ، وهذا على الأرجح تقدير من أعلاه. في أي حال ، لدينا عدد مرات مضيئة كما مرتين ونصف. ولكن من الجدير هنا أن نفهم أن 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 .

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

Locks and Agents عبارة عن كبح كبير على IPv6 ، وبالتالي فإن تطبيقه لا يتحرك بسرعة كبيرة. هذا محزن. أولئك الذين حلوا هذه المهمة فخورون تماما بأنفسهم.

في الختام

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

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

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

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

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