Не е тајна дека контролата на блокирањето на списокот на забранети информации во Русија ја следи автоматскиот систем „Инспектор“. Како функционира е добро напишано овде во ова , слика од истото место:
Инсталиран директно кај провајдерот :
Модулот „Агент инспектор“ е структурен елемент на автоматизираниот систем „Инспектор“ (AS „Инспектор“). Овој систем е дизајниран да ја следи усогласеноста на телекомуникациските оператори со барањата за ограничување на пристапот во рамките на одредбите утврдени со членовите 15.1-15.4 од Федералниот закон од 27 јули 2006 година бр. 149-ФЗ „За информации, информациски технологии и заштита на информациите. ”
Главната цел на создавањето на 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 за да се олесни работата на системот за филтрирање, по можност долго напуштен, за да се минимизира влезот на вонреден сообраќај, освен од агенти. Оваа задача се покажа дека не е воопшто тешка, има доста бесплатни домени во регистарот на забранети информации и за секој вкус. Затоа, доменот беше купен и поврзан со IP адреси на VPS што работи tcpdump и почна броењето.
Ревизија на „Ревизори“
Очекував да видам периодични изливи на барања, што според мене би укажало на контролирана акција. Невозможно е да се каже дека воопшто не го видов, но дефинитивно немаше јасна слика:
Што не е изненадувачки, дури и на домен што никому не му е потребен и на никогаш некористена IP адреса, едноставно ќе има еден тон несакани информации, таков е модерниот Интернет. Но, за среќа, ми требаа само барања за специфичен URL, така што сите скенери и кракери за лозинка беа брзо пронајдени. Исто така, беше лесно да се разбере каде се засновала поплавата врз основа на масата на слични барања. Следно, ја составив фреквенцијата на појавување на IP адреси и рачно го поминав целиот врв, раздвојувајќи ги оние што го пропуштија во претходните фази. Дополнително, ги отсеков сите извори што беа испратени во еден пакет, веќе ги немаше многу. И еве што се случи:
Мала лирска дигресија. Нешто повеќе од еден ден подоцна, мојот хостинг провајдер испрати писмо со прилично рационализирана содржина, велејќи дека вашите капацитети содржат ресурс од списокот на забранети RKN, па затоа е блокиран. Отпрвин мислев дека мојот профил е блокиран, тоа не беше случај. Тогаш помислив дека едноставно ме предупредуваат за нешто за што веќе знаев. Но, испадна дека хостерот го вклучил својот филтер пред мојот домен и како резултат на тоа дојдов под двојно филтрирање: од провајдерите и од хостерот. Филтерот ги помина само краевите на барањата: 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. Несомнено, некој дел е излишен, но сигурно е тешко да се одвои, бидејќи ресурсот е под блокирање, а од вториот ден под двојно блокирање, а повеќето сесии се само размена на неколку пакети на услуги. Да се согласиме дека ова е мал дел.
Овие бројки веќе може да се споредат со бројот на провајдери во Русија. лиценци за „Комуникациски услуги за пренос на податоци, со исклучок на глас“ - 6387, но ова е многу висока проценка од погоре, не сите овие лиценци се однесуваат конкретно за интернет провајдери кои треба да инсталираат агент. Во зоната RIPE NCC има сличен број на AS-и регистрирани во Русија - 6230, од кои не сите се даватели. и доби 3940 компании во 2017 година, а ова е попрво проценка одозгора. Во секој случај, имаме два и пол пати помал број на осветлени AS. Но, тука вреди да се разбере дека 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 провајдери таму, може да им се даде овации! Друга адреса е облак хостинг во Русија (не филтрира), друга е истражувачки центар во Германија (има филтер, каде?). Но, зошто тие ја проверуваат достапноста на забранетите ресурси на распоред е добро прашање. Останатите двајца поднесоа едно барање и се наоѓаат надвор од Русија, а еден од нив е филтриран (во транзит, сепак?).
Блокирањето и агентите се голема пречка за IPv6, чија имплементација не се движи многу брзо. Тажно е. Оние кои го решиле овој проблем можат да бидат целосно горди на себе.
Во заклучок
Не се стремев кон 100% точност, те молам прости ми за ова, се надевам дека некој сака да ја повтори оваа работа со поголема точност. За мене беше важно да разберам дали овој пристап ќе функционира во принцип. Одговорот е да. Како прво приближување, добиените бројки мислам дека се доста сигурни.
Што друго можеше да се направи и она што бев премногу мрзлив да го направам е да бројам барања за DNS. Тие не се филтрирани, но исто така не даваат голема точност бидејќи работат само за доменот, а не за целиот URL. Фреквенцијата треба да биде видлива. Ако го комбинирате со она што е видливо директно во прашањата, ова ќе ви овозможи да ги издвоите непотребните и да добиете повеќе информации. Дури е можно да се одредат развивачите на DNS што ги користат провајдерите и многу повеќе.
Апсолутно не очекував дека хостерот исто така ќе вклучи свој филтер за мојот VPS. Можеби ова е вообичаена практика. На крајот, RKN испраќа барање за бришење на ресурсот до хостерот. Но, ова не ме изненади и на некој начин дури работеше во моја корист. Филтерот работеше многу ефикасно, отсекувајќи ги сите точни барања за HTTP на забранета URL-адреса, но не точните што претходно поминале низ филтерот на добавувачите стигнале до него, иако само во форма на завршетоци: FIN-ACK и RST - минус за минус и за малку ќе испадна плус. Патем, IPv6 не беше филтриран од хостерот. Се разбира, тоа влијаеше на квалитетот на собраниот материјал, но сепак овозможи да се види фреквенцијата. Се испостави дека ова е важна точка при изборот на локација за поставување ресурси, не заборавајте да се интересирате за прашањето за организирање работа со списокот на забранети локации и барања од RKN.
На почетокот го споредив АС „Инспекторот“ со . Оваа споредба е сосема оправдана и голема мрежа на агенти може да биде од корист. На пример, одредување на квалитетот на достапноста на ресурсите од различни добавувачи во различни делови на земјата. Можете да пресметате доцнења, можете да изградите графикони, можете да го анализирате сето тоа и да ги видите промените што се случуваат и локално и глобално. Ова не е најдиректниот начин, но астрономите користат „стандардни свеќи“, зошто да не користат агенти? Знаејќи (имајќи го најдовте) нивното стандардно однесување, можете да ги одредите промените што се случуваат околу нив и како тоа влијае на квалитетот на дадените услуги. И во исто време, не треба самостојно да поставувате сонди на мрежата Роскомнадзор веќе ги има инсталирано.
Друга точка на која сакам да допрам е дека секоја алатка може да биде оружје. АС „Инспектор“ е затворена мрежа, но агентите ги предаваат сите со испраќање барања за сите ресурси од забранетата листа. Имањето таков ресурс воопшто не претставува никакви проблеми. Севкупно, провајдерите преку агентите, несвесно, кажуваат многу повеќе за нивната мрежа отколку што веројатно вреди: типови DPI и DNS, локација на агентот (централен јазол и услужна мрежа?), мрежни маркери за одложувања и загуби - и ова е само најочигледното. Како што некој може да ги следи активностите на агентите за да ја подобри достапноста на нивните ресурси, некој може да го прави тоа за други цели и нема пречки за тоа. Резултатот е инструмент со две острици и многу повеќеслојни, секој може да го види ова.
Извор: www.habr.com