Не секрет, що за контролем блокувань за списком забороненої інформації у Росії стежить автоматизована система «Ревізор». Як це працює непогано написано ось у цій , картинка звідти ж:
Безпосередньо у провайдера встановлюється :
Модуль "Агент Ревізор" є структурним елементом автоматизованої системи "Ревізор" (АС "Ревізор"). Ця система призначена для здійснення контролю за виконанням операторами зв'язку вимог щодо обмеження доступу в рамках положень, встановлених статтями 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-адресою. Як видно з графіка вище, після першої доби я став отримувати менше даних, але я все одно їх отримував чогось цілком вистачило для завдання підрахунку джерел запитів.
Ближче до діла. На мій погляд абсолютно чітко видно два сплески щодня, перший поменше, після опівночі по Москві, другий ближче до 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
Незважаючи на те, що мій хостинг провайдер включив свій фільтр починаючи з другої доби, за інформацією за перший день можна зробити висновок, що блокування працюють успішно. Тільки чотири джерела змогли пробитися і мають повністю закінчені HTTP і TCP сесії (як у прикладі вище). Ще 4 можуть надіслати 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 хостер увімкне ще й свій фільтр. Можливо це проста практика. Зрештою РКН надсилає запит видалення ресурсу саме хостеру. Але мене це не здивувало і навіть десь зіграло на користь. Фільтр працював дуже ефективно зрізуючи всі правильні HTTP запити до забороненої URL-адреси, але не правильні, що пройшли до цього через фільтр провайдерів долітали, нехай тільки у вигляді кінцівок: FIN-ACK и RST - Мінус на мінус і майже вийшов плюс. До речі, IPv6 хостер не фільтрувався. Звичайно, це вплинуло на якість зібраного матеріалу, але все одно дало можливість побачити періодичність. Виявилося, що це важливий момент при виборі майданчика для розміщення ресурсів, не забувайте цікавитися питанням організації роботи зі списком заборонених сайтів та запитами від РКН.
На початку я порівняв АС «Ревізор» з . Це порівняння цілком виправдане і велика мережа Агентів може приносити користь. Наприклад, визначення якості доступності ресурсу різних провайдерів різних частин країни. Можна порахувати затримки, можна будувати графіки, можна це аналізувати і бачити зміни що відбуваються як локально і глобально. Це не найпряміший шлях, але використовують астрономи «стандартні свічки», чому не використовувати Агенти? Знаючи (знайшовши) їхню стандартну поведінку можна визначати зміни, які відбуваються навколо них і як це впливає на якість послуг. І при цьому не треба самостійно розставляти пробники по мережі, їх уже поставив Роскомнагляд.
Ще один момент, який я хочу торкнутися, кожен інструмент може бути зброєю. АС «Ревізор» закрита мережа, але Агенти здають усіх із потрохами надсилаючи запити на всі ресурси із забороненого списку. Одержати такий ресурс не є рівним рахунком жодних проблем. Отже, провайдери через Агентів, самі того не бажаючи розповідають про свою мережу набагато більше, ніж можна було б: типи DPI і DNS, місце розташування Агента (центрального вузла та службової мережі?), мережеві маркери затримок і втрат — і це тільки очевидне. Так само, як хтось може моніторити дії Агентів для покращення доступності своїх ресурсів, хтось може це робити в інших цілях і цьому немає перешкод. Двогострий і дуже багатогранний інструмент вийшов, будь-хто може в цьому переконатися.
Джерело: habr.com