Не е тайна, че контролът върху блокирането на информацията в Русия се осъществява чрез автоматизирана система «Ревизор». Как точно работи това, е добре описано в тази , изображение оттам:
Непосредствено при доставчика се инсталира :
Модул «Агент Ревизор» е структурен елемент на автоматизирана система «Ревизор» (АС «Ревизор»). Тази система е предназначена за упражняване на контрол върху изпълнението на изискванията на операторите на комуникации по отношение на ограничаването на достъпа в рамките на разпоредбите, установени в статии 15.1-15.4 от Федералния закон от 27 юли 2006 г. № 149-ФЗ «За информацията, информационните технологии и защита на информацията».
Основната цел на създаването на АС «Ревизор» е осигуряване на мониторинг на спазването на изискванията, установени в статии 15.1-15.4 от Федералния закон от 27 юли 2006 г. № 149-ФЗ «За информацията, информационните технологии и защита на информацията», по отношение на установяване на факти за достъп до забранена информация и получаване на доказателствени материали (данни) за нарушения на ограниченията на достъпа до забранена информация.
С оглед на факта, че ако не всички, то много доставчици са инсталирали това устройство у себе си, би трябвало да се получи голяма мрежа от пробници-мигачи, подобна на и дори повече, но с ограничен достъп. Въпреки това, маякът е маяк, за да изпраща сигнали навсякъде, а какво, ако уловим сигналите и видим какво сме хванали и колко?
Преди да сметнем, да видим защо това въобще може да е възможно.
Няколко теории
Агентите проверяват наличността на ресурса, включително чрез 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 адреси и преминах през целия топ ръчно, отделяйки тези, които сме пропуснали на предишните етапи. В допълнение изрязах всички източници, които изпратиха по един пакет, които вече не бяха много. И получи се следното:
Небольшо лирическо отклонение. Часове повече след това, моят хостинг доставчик изпрати писмо с доста неясно съдържание, в което пишеше, че на вашите мощности има ресурс от забранен списък, поради което той се блокира. Първо помислих, че блокират акаунта ми, но не беше така. След това си помислих, че просто ме предупреждават за нещо, което вече знаех. Но се оказа, че хостерът е включил своя филтър преди моя домейн и в крайна сметка попаднах под двойно филтриране: от страна на доставчиците и от страна на хостера. Филтърът пропускаше само край на заявките: FIN-ACK и RST изрязвайки целия HTTP по забранен URL. Както се вижда от графиката по-горе, след първите 24 часа започнах да получавам по-малко данни, но все още ги получавах, което беше напълно достатъчно за задачата за изчисляване на източниците на заявки.
По-подробно. На моя поглед, напълно ясно се виждат два пика всеки ден, първият по-малък, след полунощ по московско време, вторият по-близо до 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 могат да изпратят ИЗИСКВАНЕ, но сесията моментално се прекъсва по 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 повече от в предишните и последващите пакети.
От останалите не се вижда дори ИЗИСКВАНЕ:
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. Може би това е обичайна практика. В крайна сметка РКН изпраща заявка за премахване на ресурса точно на хостера. Но това не ме изненада и дори някъде изигра в моя полза. Филтърът работеше много ефективно, отсявайки всички правилни HTTP заявки към забранения URL, но неправилните, преминали до това през филтъра на провайдера, стигаха, макар и само под формата на краища: FIN-ACK и RST — минус на минус и почти стана плюс. Между другото, IPv6 хостера не беше филтриран. Разбира се, това повлия на качеството на събраните материали, но все пак даде възможност да видим периодичността. Оказа се, че това е важен момент при избора на платформа за разполагане на ресурси, не забравяйте да се интересувате от организацията на работата с списъка на забранените сайтове и запитванията от РКН.
В началото сравних АС „Ревизор“ с . Това сравнение е напълно оправдано и голяма мрежа от Агенти може да носи полза. Например, определяне на качеството на достъпност на ресурса от различни провайдери от различни части на страната. Можем да измерим забавяния, можем да строим графики, можем да анализираме всичко това и да виждаме промените, които се случват както локално, така и глобално. Това не е най-прекият път, но астрономите използват „стандартни свещи“, защо да не използваме Агенти? Знаейки (намирайки) тяхното стандартно поведение, можем да определим промените, които се случват около тях и как това влияе на качеството на предоставяните услуги. И при това не е нужно сами да поставяте пробници по мрежата, те вече са поставени от Роскомнадзор.
Още един момент, който искам да засягам, всеки инструмент може да бъде оръжие. АС „Ревизор“ е затворена мрежа, но Агенти разкриват всичко, като изпращат запитвания към всички ресурси от забранения списък. Да придобиеш такъв ресурс не представлява никакви проблеми. В крайна сметка, провайдерите чрез Агенти, сами без да искат, разказват за мрежата си много повече, отколкото би следвало: типове DPI и DNS, местоположение на Агента (централна възел и обслужваща мрежа?), мрежови маркери на забавяния и загуби — и това е само най-очевидното. Както някой може да наблюдава действията на Агенти, за да подобри достъпността на ресурсите си, така и някой може да прави това с други цели и няма пречки за това. Получи се двустранно остър и многостранен инструмент, всеки може да се убеди в това.
Източник: habr.com
