این راز نیست که کنترل مسدود کردن لیست اطلاعات ممنوعه در روسیه توسط سیستم خودکار "بازرس" نظارت می شود. نحوه کار در اینجا به خوبی نوشته شده است ، عکس از همان مکان:
مستقیماً در ارائه دهنده نصب می شود :
ماژول "عامل بازرس" یک عنصر ساختاری از سیستم خودکار "بازرس" (AS "بازرس") است. این سیستم برای نظارت بر انطباق اپراتورهای مخابراتی با الزامات محدودیت دسترسی در چارچوب مقررات تعیین شده توسط مواد 15.1-15.4 قانون فدرال 27 ژوئیه 2006 شماره 149-FZ "در مورد اطلاعات، فناوری های اطلاعات و حفاظت از اطلاعات" طراحی شده است. ”
هدف اصلی ایجاد AS "Revizor" اطمینان از نظارت بر انطباق اپراتورهای مخابراتی با الزامات تعیین شده توسط مواد 15.1-15.4 قانون فدرال 27 ژوئیه 2006 شماره 149-FZ "در مورد اطلاعات، فناوری های اطلاعات و اطلاعات" است. حفاظت» از نظر شناسایی حقایق دسترسی به اطلاعات ممنوع و به دست آوردن مطالب (داده) پشتیبانی در مورد تخلفات برای محدود کردن دسترسی به اطلاعات ممنوعه.
با در نظر گرفتن این واقعیت که اگر نه همه، بسیاری از ارائه دهندگان این دستگاه را نصب کرده اند، باید شبکه بزرگی از کاوشگرهای چراغ دریایی مانند و حتی بیشتر، اما با دسترسی بسته. با این حال، یک فانوس دریایی یک فانوس دریایی برای ارسال سیگنال در همه جهات است، اما اگر آنها را بگیریم و ببینیم چه چیزهایی را گرفتیم و چه تعداد؟
قبل از شمارش، بیایید ببینیم که چرا این ممکن است حتی ممکن باشد.
کمی تئوری
نمایندگان در دسترس بودن یک منبع را بررسی می کنند، از جمله از طریق درخواست های 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 انتخاب کنید تا کار سیستم فیلترینگ، ترجیحاً مدت‌ها رها شده، تسهیل شود تا ورود ترافیک اضافی به جز از Agents به حداقل برسد. معلوم شد که این کار اصلاً دشوار نیست؛ دامنه های رایگان زیادی در ثبت اطلاعات ممنوعه و برای هر سلیقه وجود دارد. بنابراین، دامنه خریداری شد و به آدرس های IP در یک VPS در حال اجرا پیوند داده شد tcpdump و شمارش شروع شد
حسابرسی "حسابرسان"
انتظار داشتم شاهد انبوه درخواست‌های دوره‌ای باشم که به نظر من نشان‌دهنده اقدام کنترل‌شده است. نمی توان گفت که اصلاً آن را ندیده ام، اما قطعاً تصویر واضحی وجود نداشت:
که تعجب آور نیست، حتی در دامنه ای که هیچ کس به آن نیاز ندارد و در یک IP هرگز استفاده نشده، به سادگی تعداد زیادی اطلاعات ناخواسته وجود خواهد داشت، مانند اینترنت مدرن. اما خوشبختانه، من فقط به درخواست یک URL خاص نیاز داشتم، بنابراین تمام اسکنرها و کرکرهای رمز عبور به سرعت پیدا شدند. همچنین، فهمیدن اینکه سیل بر اساس انبوه درخواست‌های مشابه کجاست، کاملاً آسان بود. در مرحله بعد، فرکانس وقوع آدرس‌های IP را جمع‌آوری کردم و تمام قسمت‌های بالای صفحه را به صورت دستی مرور کردم و افرادی را که در مراحل قبلی آن را از دست دادند، جدا کردم. علاوه بر این، من تمام منابعی که در یک بسته ارسال شده بود را حذف کردم، دیگر تعداد زیادی از آنها وجود نداشت. و این چیزی است که اتفاق افتاد:
یک انحراف غزلی کوچک. کمی بیشتر از یک روز بعد، ارائه دهنده میزبانی من نامه ای با محتوای نسبتاً ساده ارسال کرد و گفت که امکانات شما حاوی منبعی از لیست ممنوعه RKN است، بنابراین مسدود شده است. اول فکر کردم حسابم مسدود شده، اینطور نبود. سپس فکر کردم که آنها صرفاً در مورد چیزی که قبلاً می دانستم به من هشدار می دهند. اما معلوم شد که هاست فیلتر خود را در مقابل دامنه من روشن کرده است و در نتیجه من تحت فیلتر دوگانه قرار گرفتم: از ارائه دهندگان و از میزبان. فیلتر فقط از انتهای درخواست ها عبور کرد: FIN-ACK и RST قطع کردن تمام HTTP در یک URL ممنوعه. همانطور که از نمودار بالا می بینید، پس از روز اول شروع به دریافت داده های کمتری کردم، اما همچنان آن را دریافت کردم، که برای کار شمارش منابع درخواست کاملاً کافی بود.
برو سر اصل مطلب. به نظر من، هر روز دو انفجار به وضوح قابل مشاهده است، اولی کوچکتر، بعد از نیمه شب به وقت مسکو، دومی نزدیک به ساعت 6 صبح با دم تا ساعت 12 ظهر. اوج دقیقا در یک زمان اتفاق نمی افتد. در ابتدا می‌خواستم آدرس‌های IP را انتخاب کنم که فقط در این دوره‌ها و هر کدام در تمام دوره‌ها سقوط کرده‌اند، بر اساس این فرض که بررسی‌های Agents به صورت دوره‌ای انجام می‌شود. اما پس از بررسی دقیق، به سرعت دوره هایی را کشف کردم که در فواصل دیگر، با فرکانس های دیگر، تا یک درخواست در هر ساعت قرار می گیرند. سپس به مناطق زمانی فکر کردم و اینکه شاید ربطی به آنها داشته باشد، سپس فکر کردم که به طور کلی ممکن است این سیستم در سطح جهانی هماهنگ نباشد. علاوه بر این، NAT احتمالاً نقش خواهد داشت و همان Agent می تواند از 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 است. در اینجا میانگین انتظار می رود - یک نماینده برای هر ارائه دهنده. ما همچنین از اوج انتظار داریم - بازیکنان بزرگی در آن حضور دارند. در یک شبکه بزرگ، Agents احتمالاً باید در هر منطقه از حضور اپراتور قرار داشته باشد و NAT را فراموش نکنید. اگر آن را بر اساس کشور بگیریم، حداکثر خواهد بود: 1409 - RU، 42 - UA، 23 - CZ، 36 از مناطق دیگر، نه RIPE NCC. درخواست های خارج از روسیه جلب توجه می کند. این را احتمالاً می توان با خطاهای موقعیت جغرافیایی یا خطاهای ثبت کننده هنگام پر کردن داده ها توضیح داد. یا اینکه ممکن است یک شرکت روسی ریشه روسی نداشته باشد یا نمایندگی خارجی داشته باشد زیرا این کار راحت تر است، که طبیعی است هنگام برخورد با یک سازمان خارجی RIPE NCC. برخی از بخش ها بدون شک اضافی هستند، اما جدا کردن آن به طور قابل اعتماد دشوار است، زیرا منبع در حال مسدود شدن است، و از روز دوم تحت مسدود شدن مضاعف است، و اکثر جلسات فقط تبادل چندین بسته خدمات هستند. بیایید قبول کنیم که این بخش کوچکی است.
این اعداد را می توان با تعداد ارائه دهندگان در روسیه مقایسه کرد. مجوزهای "خدمات ارتباطی برای انتقال داده، به استثنای صدا" - 6387، اما این یک تخمین بسیار بالا از بالا است، همه این مجوزها به طور خاص برای ارائه دهندگان اینترنت که نیاز به نصب Agent دارند اعمال نمی شود. در منطقه RIPE NCC تعداد مشابهی از ASهای ثبت شده در روسیه وجود دارد - 6230 که همه آنها ارائه دهنده نیستند. و در سال 3940، 2017 شرکت را دریافت کرد، و این بیشتر یک تخمین از بالا است. در هر صورت، ما دو و نیم برابر کمتر AS های نورانی داریم. اما در اینجا شایان ذکر است که AS دقیقاً برابر با ارائه دهنده نیست. برخی از ارائه دهندگان AS خود را ندارند، برخی بیش از یک دارند. اگر فرض کنیم که همه هنوز Agent دارند، آنگاه شخصی قوی‌تر از دیگران فیلتر می‌کند، به طوری که اگر درخواست‌هایش اصلاً به آنها برسد، از زباله‌ها قابل تشخیص نیستند. اما برای یک ارزیابی تقریبی کاملا قابل تحمل است، حتی اگر چیزی به دلیل نظارت من از بین رفته باشد.
درباره 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 مختلف انجام می شود که دقیقاً همان رفتار Agents است که من انتظار داشتم. علاوه بر این، یکی از آدرس های IPv6 تحت فیلتر قرار نمی گیرد و من یک جلسه کامل می بینم. از دو جلسه دیگر فقط یک جلسه ناتمام دیدم که یکی از آن ها قطع شد RST از فیلتر، دوم در زمان. مبلغ کل 7.
از آنجایی که آدرس های کمی وجود دارد، من همه آنها را با جزئیات مطالعه کردم و معلوم شد که فقط 3 ارائه دهنده آنجا هستند، می توان آنها را تشویق کرد! آدرس دیگر میزبانی ابری در روسیه است (فیلتر نمی کند)، دیگری یک مرکز تحقیقاتی در آلمان است (فیلتر وجود دارد، کجا؟). اما اینکه چرا آنها در دسترس بودن منابع ممنوعه را در یک برنامه زمانی بررسی می کنند، سوال خوبی است. دو نفر باقی مانده یک درخواست کردند و در خارج از روسیه قرار دارند و یکی از آنها فیلتر شده است (بالاخره در حال حمل و نقل؟).
Blocking و Agents مانع بزرگی برای IPv6 هستند که پیاده سازی آن خیلی سریع پیش نمی رود. آن غم انگیز است. کسانی که این مشکل را حل کردند می توانند کاملاً به خود افتخار کنند.
در نتیجه
من برای دقت 100% تلاش نکردم، لطفاً مرا به خاطر این موضوع ببخشید، امیدوارم کسی بخواهد این کار را با دقت بیشتری تکرار کند. برای من مهم بود که بفهمم آیا این رویکرد در اصل کار می کند یا خیر. پاسخ بله است. ارقام به دست آمده، به عنوان اولین تقریب، به نظر من، کاملا قابل اعتماد هستند.
کار دیگری که می‌توانست انجام شود و من برای انجام آن تنبلی داشتم، شمارش درخواست‌های DNS بود. آنها فیلتر نمی شوند، اما همچنین دقت زیادی ارائه نمی دهند زیرا فقط برای دامنه کار می کنند و نه برای کل URL. فرکانس باید قابل مشاهده باشد. اگر آن را با آنچه که مستقیماً در جستارها قابل مشاهده است ترکیب کنید، این به شما امکان می دهد موارد غیر ضروری را جدا کرده و اطلاعات بیشتری دریافت کنید. حتی امکان تعیین توسعه دهندگان DNS مورد استفاده توسط ارائه دهندگان و موارد دیگر وجود دارد.
من مطلقاً انتظار نداشتم که میزبان فیلتر خود را برای VPS من نیز داشته باشد. شاید این یک رویه رایج باشد. در پایان، RKN درخواست حذف منبع را به میزبان ارسال می کند. اما این من را غافلگیر نکرد و از جهاتی حتی به نفع من بود. این فیلتر بسیار مؤثر عمل کرد و تمام درخواست‌های HTTP صحیح را به یک URL ممنوعه قطع کرد، اما درخواست‌های صحیحی را که قبلاً از فیلتر ارائه‌دهندگان عبور کرده بودند، به آنها رسیده بود، البته فقط به شکل انتهایی: FIN-ACK и RST - منهای برای منهای و تقریباً یک امتیاز مثبت بود. ضمنا IPv6 توسط هاست فیلتر نشده است. البته این موضوع بر کیفیت مطالب جمع آوری شده تأثیر گذاشت، اما باز هم امکان مشاهده فرکانس را فراهم کرد. معلوم شد که این نکته مهمی در هنگام انتخاب سایت برای قرار دادن منابع است؛ فراموش نکنید که به موضوع سازماندهی کار با لیست سایت های ممنوعه و درخواست های RKN علاقه مند شوید.
در ابتدا، AS "بازرس" را با . این مقایسه کاملاً موجه است و یک شبکه بزرگ از نمایندگان می تواند سودمند باشد. به عنوان مثال، تعیین کیفیت در دسترس بودن منابع از ارائه دهندگان مختلف در نقاط مختلف کشور. می‌توانید تأخیرها را محاسبه کنید، می‌توانید نمودار بسازید، می‌توانید همه آنها را تجزیه و تحلیل کنید و تغییراتی را که هم در سطح محلی و هم در سطح جهانی رخ می‌دهند، ببینید. این مستقیم ترین راه نیست، اما ستاره شناسان از "شمع های استاندارد" استفاده می کنند، چرا از Agents استفاده نمی کنند؟ با دانستن (با یافتن) رفتار استاندارد آنها، می توانید تغییراتی را که در اطراف آنها رخ می دهد و اینکه چگونه بر کیفیت خدمات ارائه شده تأثیر می گذارد، تعیین کنید. و در عین حال، نیازی به قرار دادن مستقل پروب ها در شبکه ندارید؛ Roskomnadzor قبلاً آنها را نصب کرده است.
نکته دیگری که می خواهم به آن اشاره کنم این است که هر ابزاری می تواند یک سلاح باشد. AS "Inspector" یک شبکه بسته است، اما Agents با ارسال درخواست برای همه منابع از لیست ممنوعه، همه را تحویل می دهند. داشتن چنین منبعی به هیچ وجه مشکلی ایجاد نمی کند. در مجموع، ارائه دهندگان از طریق Agents، ناخواسته، چیزهای بیشتری در مورد شبکه خود می گویند که احتمالاً ارزشش را دارد: انواع DPI و DNS، مکان عامل (گره مرکزی و شبکه خدمات؟)، نشانگرهای شبکه تاخیر و تلفات - و این فقط واضح ترین همانطور که کسی می تواند اقدامات Agents را برای بهبود در دسترس بودن منابع خود نظارت کند، کسی می تواند این کار را برای اهداف دیگری انجام دهد و هیچ مانعی برای این کار وجود ندارد. نتیجه یک ساز دو لبه و بسیار چند وجهی است، هر کسی می تواند این را ببیند.
منبع: www.habr.com