Није тајна да контролу блокирања на листи забрањених информација у Русији прати аутоматизовани систем „Инспектор“. Како то функционише је добро написано овде у овоме , слика са истог места:
Инсталиран директно код провајдера :
Модул „Агент Инспецтор“ је структурни елемент аутоматизованог система „Инспектор“ (АС „Инспектор“). Овај систем је дизајниран да надгледа усклађеност телеком оператера са захтевима за ограничење приступа у оквиру одредби утврђених члановима 15.1-15.4 Федералног закона од 27. јула 2006. бр. 149-ФЗ „О информацијама, информационим технологијама и заштити информација. ”
Главна сврха стварања АС „Ревизор” је да обезбеди праћење усклађености телеком оператера са захтевима утврђеним члановима 15.1-15.4 Савезног закона од 27. јула 2006. бр. 149-ФЗ „О информацијама, информационим технологијама и информацијама Заштита” у смислу идентификовања чињеница о приступу забрањеним информацијама и прибављања пратећих материјала (података) о кршењима ради ограничавања приступа забрањеним информацијама.
Узимајући у обзир чињеницу да су, ако не сви, онда многи провајдери инсталирали овај уређај, требало је да постоји велика мрежа беацон сонди попут па чак и више, али са затвореним приступом. Ипак, светионик је светионик за слање сигнала у свим правцима, али шта ако их ухватимо и видимо шта смо ухватили и колико?
Пре него што пребројимо, хајде да видимо зашто је то уопште могуће.
Мало теорије
Агенти проверавају доступност ресурса, укључујући преко ХТТП(С) захтева, као што је овај:
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.
Регистар забрањених информација садржи неколико врста блокирања. Очигледно, ако је ресурс блокиран ИП адресом или именом домена, нећемо видети никакве захтеве. Ово су најразорнији типови блокирања, који доводе до недоступности свих ресурса на једној ИП адреси или свих информација на домену. Постоји и тип блокирања „по УРЛ-у“. У овом случају, систем за филтрирање мора да анализира заглавље ХТТП захтева да би тачно одредио шта да блокира. А пре тога, као што се може видети изнад, требало би да постоји фаза успостављања везе коју можете покушати да пратите, јер ће је филтер највероватније пропустити.
Да бисте то урадили, потребно је да изаберете одговарајући бесплатни домен са типом блокирања „УРЛ“ и ХТТП како бисте олакшали рад система за филтрирање, по могућству дуго напуштеног, како би се минимизирао улазак страног саобраћаја осим од агената. Овај задатак се показао нимало тешким, у регистру забрањених информација има доста бесплатних домена и за свачији укус. Стога је домен купљен и повезан са ИП адресама на ВПС-у који ради tcpdump и пребројавање је почело.
Ревизија "Ревизора"
Очекивао сам да ћу видети периодичне навале захтева, што би по мом мишљењу указивало на контролисану акцију. Немогуће је рећи да га уопште нисам видео, али дефинитивно није било јасне слике:
Што није изненађујуће, чак и на домену који никоме није потребан и на никад коришћеном ИП-у, једноставно ће бити гомила нежељених информација, какав је савремени интернет. Али на срећу, били су ми потребни само захтеви за одређени УРЛ, тако да су сви скенери и крекери лозинки брзо пронађени. Такође, било је прилично лако разумети где је поплава на основу масе сличних захтева. Затим сам саставио учесталост појављивања ИП адреса и ручно прошао кроз цео врх, одвајајући оне који су то пропустили у претходним фазама. Поред тога, исекао сам све изворе који су послати у једном пакету, више их није било много. И ево шта се десило:
Мала лирска дигресија. Нешто више од једног дана касније, мој хостинг провајдер је послао писмо прилично поједностављеног садржаја, рекавши да ваши објекти садрже ресурс са РКН листе забрањених, па је блокиран. Прво сам мислио да ми је налог блокиран, није било тако. Тада сам помислио да ме једноставно упозоравају на нешто о чему сам већ знао. Али испоставило се да је хостер укључио свој филтер испред мог домена и као резултат тога дошао сам под двоструко филтрирање: од провајдера и од хостера. Филтер је прошао само крајеве захтева: FIN-ACK и RST одсецање свих ХТТП на забрањеној УРЛ адреси. Као што видите из горњег графикона, након првог дана почео сам да добијам мање података, али сам их ипак добио, што је било сасвим довољно за задатак пребројавања извора захтева.
Доћи до тачке. По мом мишљењу, сваки дан се јасно виде два рафала, први мањи, после поноћи по московском времену, други ближе 6 ујутро са репом до 12 сати. Врхунац се не јавља тачно у исто време. Прво сам желео да изаберем ИП адресе које су падале само у овим периодима и свака у свим периодима, на основу претпоставке да се провере од стране агената врше периодично. Али након пажљивог прегледа, брзо сам открио да периоди падају у друге интервале, са другим фреквенцијама, до једног захтева сваког сата. Онда сам размишљао о временским зонама и да можда то има неке везе са њима, онда сам помислио да генерално систем можда није синхронизован глобално. Поред тога, НАТ ће вероватно играти улогу и исти агент може да шаље захтеве са различитих јавних ИП адреса.
Пошто мој почетни циљ није био баш, пребројао сам све адресе на које сам наишао за недељу дана и добио - 2791. Број ТЦП сесија успостављених са једне адресе је у просеку 4, са медијаном од 2. Највеће сесије по адреси: 464, 231, 149, 83, 77. Максимум од 95% узорка је 8 сесија по адреси. Медијана није баш висока, да подсетим да график показује јасну дневну периодичност, тако да се може очекивати нешто око 4 до 8 за 7 дана. Ако избацимо све сесије које се једном дешавају, добићемо медијану једнаку 5. Али нисам могао да их искључим на основу јасног критеријума. Напротив, насумична провера је показала да су у вези са захтевима за забрањени ресурс.
Адресе су адресе, али на Интернету аутономни системи - АС, што се показало важнијим 1510, у просеку 2 адресе по АС са медијаном од 1. Врх адресе по АС: 288, 77, 66, 39, 27. Максималних 95% узорка су 4 адресе по АС. Овде се очекује медијана - један агент по провајдеру. Очекујемо и врх - у њему су велики играчи. У великој мрежи, агенти би вероватно требало да буду лоцирани у сваком региону присуства оператера, и не заборавите на НАТ. Ако узмемо по земљи, максимуми ће бити: 1409 - РУ, 42 - УА, 23 - ЦЗ, 36 из других региона, а не РИПЕ НЦЦ. Захтеви изван Русије привлаче пажњу. Ово се вероватно може објаснити грешкама геолокације или грешкама регистратора приликом попуњавања података. Или чињеница да руска компанија можда нема руске корене, или има страно представништво јер је лакше, што је природно када се ради са страном организацијом РИПЕ НЦЦ. Неки део је несумњиво сувишан, али га је поуздано тешко одвојити, пошто је ресурс под блокадом, а од другог дана под двоструком блокадом, а већина сесија је само размена неколико сервисних пакета. Сложимо се да је ово мали део.
Ове бројке се већ могу упоредити са бројем провајдера у Русији. лиценце за „Комуникационе услуге за пренос података, искључујући глас” - 6387, али ово је веома висока процена одозго, не односе се све ове лиценце посебно на Интернет провајдере који треба да инсталирају Агент. У зони РИПЕ НЦЦ постоји сличан број АС-а регистрованих у Русији - 6230, од којих нису сви провајдери. и примио 3940 компанија у 2017. и ово је пре процена одозго. У сваком случају, имамо два и по пута мањи број осветљених АС-а. Али овде је вредно разумети да АС није стриктно једнак добављачу. Неки провајдери немају сопствени АС, неки имају више од једног. Ако претпоставимо да још увек сви имају Агенте, онда неко јаче филтрира од других, тако да се њихови захтеви не разликују од смећа, ако уопште дођу до њих. Али за грубу процену то је сасвим подношљиво, чак и ако је нешто изгубљено мојим превидом.
О ДПИ
И поред тога што је мој хостинг провајдер укључио филтер од другог дана, на основу информација од првог дана можемо закључити да блокирање функционише успешно. Само 4 извора су успела да прођу и имају потпуно завршене ХТТП и ТЦП сесије (као у примеру изнад). Може се послати још 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"
...
И све се то понавља и понавља и понавља, као што се види на графикону, више пута, сваки дан.
О ИПв6
Добра вест је да постоји. Поуздано могу да кажем да се периодични захтеви ка забрањеном ресурсу јављају са 5 различитих ИПв6 адреса, што је управо понашање агената које сам очекивао. Штавише, једна од ИПв6 адреса не потпада под филтрирање и видим пуну сесију. Од још две видео сам само једну недовршену сесију, од којих је једна прекинута RST из филтера, други по времену. Укупан износ 7.
Пошто је мало адреса, све сам их детаљно проучио и испоставило се да тамо има само 3 провајдера, може им се дати овације! Друга адреса је хостинг у облаку у Русији (не филтрира), друга је истраживачки центар у Немачкој (постоји филтер, где?). Али зашто проверавају доступност забрањених ресурса на распореду је добро питање. Преостала два су дала један захтев и налазе се ван Русије, а један од њих је филтриран (уосталом у транзиту?).
Блокирање и агенти су велика препрека за ИПв6, чија имплементација се не креће баш брзо. То је тужно. Они који су решили овај проблем могу бити у потпуности поносни на себе.
У закључку
Нисам тежио 100% тачности, опростите ми на овоме, надам се да неко жели да понови овај рад са већом тачношћу. Било ми је важно да схватим да ли ће овај приступ у принципу функционисати. Одговор је да. Добијене бројке, као прва апроксимација, мислим да су прилично поуздане.
Шта је друго могло да се уради и што сам био лењ да пребројим ДНС захтеве. Они нису филтрирани, али такође не пружају велику тачност јер раде само за домен, а не за цео УРЛ. Учесталост треба да буде видљива. Ако га комбинујете са оним што је видљиво директно у упитима, то ће вам омогућити да одвојите непотребно и добијете више информација. Чак је могуће одредити програмере ДНС-а које користе провајдери и још много тога.
Апсолутно нисам очекивао да ће хостер укључити и сопствени филтер за мој ВПС. Можда је ово уобичајена пракса. На крају, РКН шаље захтев за брисање ресурса хостеру. Али ово ме није изненадило и на неки начин је чак ишло у моју корист. Филтер је функционисао веома ефикасно, одсецајући све исправне ХТТП захтеве ка забрањеној УРЛ адреси, али не и исправне оне који су претходно прошли кроз филтер провајдера до њих, додуше само у облику завршетака: FIN-ACK и RST - минус за минус и скоро се испоставило да је плус. Иначе, хостер није филтрирао ИПв6. Наравно, то је утицало на квалитет прикупљеног материјала, али је ипак омогућило да се види фреквенција. Испоставило се да је ово важна тачка при избору локације за постављање ресурса; не заборавите да се заинтересујете за питање организовања рада са листом забрањених локација и захтевима РКН-а.
На почетку сам упоредио АС „Инспектор“ са . Ово поређење је сасвим оправдано и велика мрежа агената може бити од користи. На пример, утврђивање квалитета доступности ресурса од различитих провајдера у различитим деловима земље. Можете израчунати кашњења, можете градити графиконе, можете све то анализирати и видети промене које се дешавају и локално и глобално. Ово није најдиректнији начин, али астрономи користе „стандардне свеће“, зашто не користе Агенте? Познавајући (проналазећи) њихово стандардно понашање, можете одредити промене које се дешавају око њих и како то утиче на квалитет пружених услуга. И у исто време, не морате самостално постављати сонде на мрежу; Роскомнадзор их је већ инсталирао.
Још једна ствар коју желим да дотакнем је да сваки алат може бити оружје. АС "Инспектор" је затворена мрежа, али Агенти предају свакога слањем захтева за све ресурсе са забрањене листе. Поседовање таквог ресурса уопште не представља проблеме. Укупно, провајдери преко агената, несвесно, говоре много више о својој мрежи него што се вероватно исплати: ДПИ и ДНС типови, локација агента (централни чвор и сервисна мрежа?), мрежни маркери кашњења и губитака - а ово је само најочигледније. Као што неко може да прати акције агената да побољша доступност својих ресурса, неко то може да ради у друге сврхе и за то нема препрека. Резултат је инструмент са две оштрице и веома многострани, ово свако може да види.
Извор: ввв.хабр.цом