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