Не е тайна, че контролът върху блокирането на списъка със забранена информация в Русия се следи от автоматизираната система „Инспектор“. Как работи е написано добре тук в това , снимка от същото място:
Инсталиран директно от доставчика :
Модул "Агент Инспектор" е структурен елемент на автоматизирана система "Инспектор" (АС "Инспектор"). Тази система е предназначена да следи за спазването от страна на телекомуникационните оператори на изискванията за ограничаване на достъпа в рамките на разпоредбите, установени от членове 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, за да улесните работата на системата за филтриране, за предпочитане отдавна изоставена, за да минимизирате навлизането на външен трафик, освен от Агенти. Тази задача се оказа никак трудна, в регистъра на забранената информация има доста безплатни домейни и за всеки вкус. Следователно домейнът беше закупен и свързан с 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, някои имат повече от един. Ако приемем, че всеки все още има агенти, тогава някой филтрира по-силно от другите, така че заявките им да са неразличими от боклука, ако изобщо стигнат до тях. Но за груба преценка е доста поносимо, дори ако нещо се загуби поради моя недоглеждане.
Относно 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.
В началото сравних АС "Инспектор". . Това сравнение е напълно оправдано и голяма мрежа от агенти може да бъде от полза. Например определяне на качеството на наличността на ресурси от различни доставчици в различни части на страната. Можете да изчислявате закъснения, можете да изграждате графики, можете да анализирате всичко и да видите промените, настъпващи както локално, така и глобално. Това не е най-директният начин, но астрономите използват „стандартни свещи“, защо не използвате агенти? Познавайки (намерили) тяхното стандартно поведение, можете да определите промените, които настъпват около тях и как това се отразява на качеството на предоставяните услуги. И в същото време не е необходимо самостоятелно да поставяте сонди в мрежата; Roskomnadzor вече ги е инсталирал.
Друг момент, който искам да засегна е, че всеки инструмент може да бъде оръжие. AS "Инспектор" е затворена мрежа, но Агентите предават всички, като изпращат заявки за всички ресурси от забранения списък. Наличието на такъв ресурс не създава никакви проблеми. Като цяло доставчиците чрез агенти, без да искат, казват много повече за своята мрежа, отколкото вероятно си струва: типове DPI и DNS, местоположение на агента (централен възел и обслужваща мрежа?), мрежови маркери на закъснения и загуби - и това е само най-очевидните. Точно както някой може да наблюдава действията на Агентите, за да подобри наличността на техните ресурси, някой може да прави това за други цели и няма пречки за това. Резултатът е двуостър и многостранен инструмент, всеки може да види това.
Източник: www.habr.com