Sio siri kwamba udhibiti wa kuzuia kwenye orodha ya habari iliyokatazwa nchini Urusi inafuatiliwa na mfumo wa automatiska "Mkaguzi". Jinsi inavyofanya kazi imeandikwa vizuri hapa katika hili , picha kutoka sehemu moja:
Imewekwa moja kwa moja kwa mtoa huduma :
Moduli ya "Mkaguzi wa Wakala" ni kipengele cha kimuundo cha mfumo wa kiotomatiki "Mkaguzi" (AS "Mkaguzi"). Mfumo huu umeundwa ili kufuatilia kufuata kwa waendeshaji wa mawasiliano ya simu na mahitaji ya vizuizi vya ufikiaji ndani ya mfumo wa masharti yaliyowekwa na Kifungu cha 15.1-15.4 cha Sheria ya Shirikisho ya Julai 27, 2006 No. 149-FZ "Kwenye Habari, Teknolojia ya Habari na Ulinzi wa Habari. ”
Madhumuni makuu ya kuunda AS “Revizor” ni kuhakikisha ufuatiliaji wa utiifu wa waendeshaji wa mawasiliano ya simu na mahitaji yaliyowekwa na Kifungu cha 15.1-15.4 cha Sheria ya Shirikisho ya tarehe 27 Julai 2006 Na. 149-FZ “Kwenye Taarifa, Teknolojia ya Habari na Taarifa. Ulinzi” katika suala la kutambua ukweli wa ufikiaji wa habari iliyopigwa marufuku na kupata nyenzo za kusaidia (data) kuhusu ukiukaji ili kuzuia ufikiaji wa habari iliyopigwa marufuku.
Kwa kuzingatia ukweli kwamba, ikiwa sio wote, basi watoa huduma wengi wameweka kifaa hiki, kunapaswa kuwa na mtandao mkubwa wa uchunguzi wa beacon kama vile. na hata zaidi, lakini kwa ufikiaji uliofungwa. Hata hivyo, beacon ni mwanga wa kutuma ishara kwa pande zote, lakini vipi ikiwa tutawakamata na kuona kile tulichokamata na ngapi?
Kabla ya kuhesabu, hebu tuone ni kwa nini hii inaweza hata kuwa inawezekana.
Nadharia kidogo
Mawakala hukagua upatikanaji wa nyenzo, ikijumuisha kupitia maombi ya HTTP(S), kama hili:
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"
Mbali na mzigo wa malipo, ombi pia lina awamu ya kuanzisha uhusiano: kubadilishana SYN и SYN-ACK, na hatua za kukamilisha muunganisho: FIN-ACK.
Daftari ya habari iliyokatazwa ina aina kadhaa za kuzuia. Kwa wazi, ikiwa rasilimali imezuiwa na anwani ya IP au jina la kikoa, basi hatutaona maombi yoyote. Hizi ni aina za uharibifu zaidi za kuzuia, ambazo husababisha kutopatikana kwa rasilimali zote kwenye anwani moja ya IP au taarifa zote kwenye kikoa. Pia kuna aina ya "kwa URL" ya kuzuia. Katika kesi hii, mfumo wa kuchuja lazima uchanganue kichwa cha ombi la HTTP ili kuamua nini hasa cha kuzuia. Na kabla yake, kama inavyoonekana hapo juu, kunapaswa kuwa na awamu ya uanzishaji wa unganisho ambayo unaweza kujaribu kufuatilia, kwani uwezekano mkubwa kichungi kitakosa.
Ili kufanya hivyo, unahitaji kuchagua kikoa cha bure kinachofaa na "URL" na aina ya kuzuia HTTP ili kuwezesha kazi ya mfumo wa kuchuja, ikiwezekana ulioachwa kwa muda mrefu, ili kupunguza uingiaji wa trafiki ya nje isipokuwa kutoka kwa Mawakala. Kazi hii iligeuka kuwa sio ngumu kabisa; kuna vikoa vingi vya bure kwenye rejista ya habari iliyokatazwa na kwa kila ladha. Kwa hivyo, kikoa kilinunuliwa na kuunganishwa na anwani za IP kwenye VPS inayoendesha tcpdump na kuhesabu kuanza.
Ukaguzi wa "Wakaguzi"
Nilitarajia kuona maombi mengi ya mara kwa mara, ambayo kwa maoni yangu yangeonyesha hatua zinazodhibitiwa. Haiwezekani kusema kwamba sikuiona kabisa, lakini hakika hakukuwa na picha wazi:
Ambayo haishangazi, hata kwenye kikoa ambacho hakuna mtu anayehitaji na kwenye IP isiyotumiwa kamwe, kutakuwa na tani tu ya habari isiyoombwa, vile ni Internet ya kisasa. Lakini kwa bahati nzuri, nilihitaji tu maombi ya URL maalum, kwa hivyo skana zote na viboreshaji vya nenosiri vilipatikana haraka. Pia, ilikuwa rahisi kuelewa mahali ambapo mafuriko yalitokana na wingi wa maombi sawa. Ifuatayo, nilikusanya mzunguko wa kutokea kwa anwani za IP na nikapitia sehemu ya juu kwa mikono, nikiwatenganisha wale waliokosa katika hatua za awali. Zaidi ya hayo, nilikata vyanzo vyote vilivyotumwa kwenye mfuko mmoja, hapakuwa na wengi wao tena. Na hii ndio ilifanyika:
Kicheko kidogo cha sauti. Zaidi ya siku moja baadaye, mtoa huduma wangu mwenyeji alituma barua iliyo na maudhui yaliyoratibiwa, akisema kuwa vifaa vyako vina rasilimali kutoka kwa orodha iliyopigwa marufuku ya RKN, kwa hivyo imezuiwa. Mwanzoni nilidhani kwamba akaunti yangu ilikuwa imefungwa, hii haikuwa hivyo. Kisha nikafikiri kwamba walikuwa wakinionya tu kuhusu jambo ambalo tayari nilijua kulihusu. Lakini ikawa kwamba mhudumu aligeuka chujio chake mbele ya kikoa changu na kwa sababu hiyo nilikuja chini ya kuchuja mara mbili: kutoka kwa watoa huduma na kutoka kwa mhudumu. Kichujio kilipitisha tu miisho ya maombi: FIN-ACK и RST kukata HTTP yote kwa URL iliyopigwa marufuku. Kama unavyoona kutoka kwa grafu hapo juu, baada ya siku ya kwanza nilianza kupokea data kidogo, lakini bado niliipokea, ambayo ilikuwa ya kutosha kwa kazi ya kuhesabu vyanzo vya ombi.
Fika kwenye uhakika. Kwa maoni yangu, kupasuka mbili kunaonekana wazi kila siku, kwanza ndogo, baada ya usiku wa manane wakati wa Moscow, pili karibu na 6 asubuhi na mkia hadi saa 12 jioni. Kilele haitokei kwa wakati mmoja. Mwanzoni, nilitaka kuchagua anwani za IP ambazo zilianguka tu katika vipindi hivi na kila moja katika vipindi vyote, kwa kuzingatia dhana kwamba ukaguzi na Wakala hufanywa mara kwa mara. Lakini baada ya kukagua kwa uangalifu, niligundua haraka vipindi vinavyoanguka katika vipindi vingine, na masafa mengine, hadi ombi moja kila saa. Kisha nikafikiria kuhusu maeneo ya saa na kwamba labda ilikuwa na kitu cha kufanya nao, basi nikafikiri kwamba kwa ujumla mfumo huo unaweza usilandanishwe kimataifa. Kwa kuongeza, NAT pengine itachukua jukumu na Wakala sawa anaweza kufanya maombi kutoka kwa IP tofauti za umma.
Kwa kuwa lengo langu la awali halikuwa haswa, nilihesabu anwani zote ambazo nilipata katika wiki moja na kupata - 2791. Idadi ya vikao vya TCP vilivyoanzishwa kutoka kwa anwani moja ni wastani wa 4, na wastani wa 2. Vikao vya juu kwa kila anwani: 464, 231, 149, 83, 77. Upeo kutoka 95% ya sampuli ni vikao 8 kwa anwani. Wastani sio juu sana, wacha nikukumbushe kwamba grafu inaonyesha upimaji wa kila siku wazi, kwa hivyo mtu anaweza kutarajia kitu karibu 4 hadi 8 katika siku 7. Ikiwa tunatupa nje vikao vyote vinavyotokea mara moja, tutapata wastani sawa na 5. Lakini sikuweza kuwatenga kwa kuzingatia kigezo wazi. Kinyume chake, ukaguzi wa nasibu ulionyesha kuwa yalihusiana na maombi ya rasilimali iliyopigwa marufuku.
Anwani ni anwani, lakini kwenye mtandao, mifumo ya uhuru - AS, ambayo iligeuka kuwa muhimu zaidi 1510, kwa wastani anwani 2 kwa kila AS yenye wastani wa 1. Anwani za juu kwa kila AS: 288, 77, 66, 39, 27. Kiwango cha juu cha 95% ya sampuli ni anwani 4 kwa kila AS. Hapa wastani anatarajiwa - Wakala mmoja kwa kila mtoaji. Pia tunatarajia kilele - kuna wachezaji wakubwa ndani yake. Katika mtandao mkubwa, Mawakala wanapaswa kuwa iko katika kila eneo la uwepo wa operator, na usisahau kuhusu NAT. Ikiwa tutaichukua kwa nchi, upeo utakuwa: 1409 - RU, 42 - UA, 23 - CZ, 36 kutoka mikoa mingine, sio RIPE NCC. Maombi kutoka nje ya Urusi huvutia umakini. Labda hii inaweza kuelezewa na makosa ya eneo la kijiografia au makosa ya msajili wakati wa kujaza data. Au ukweli kwamba kampuni ya Kirusi haiwezi kuwa na mizizi ya Kirusi, au kuwa na ofisi ya mwakilishi wa kigeni kwa sababu ni rahisi, ambayo ni ya asili wakati wa kushughulika na shirika la kigeni RIPE NCC. Sehemu fulani bila shaka ni ya juu sana, lakini ni vigumu kuitenganisha, kwa kuwa rasilimali iko chini ya kuzuia, na kutoka siku ya pili chini ya kuzuia mara mbili, na vikao vingi ni kubadilishana tu ya pakiti kadhaa za huduma. Tukubaliane kuwa hii ni sehemu ndogo.
Nambari hizi tayari zinaweza kulinganishwa na idadi ya watoa huduma nchini Urusi. leseni za “Huduma za mawasiliano za utumaji data, bila kujumuisha sauti” - 6387, lakini hili ni kadirio la juu sana kutoka juu, si leseni hizi zote zinazotumika mahususi kwa watoa huduma za Intaneti wanaohitaji kusakinisha Ajenti. Katika ukanda wa RIPE NCC kuna idadi sawa ya AS iliyosajiliwa nchini Urusi - 6230, ambayo sio wote ni watoa huduma. na kupokea makampuni 3940 katika 2017, na hii ni badala ya makadirio kutoka juu. Kwa hali yoyote, tuna mara mbili na nusu chini ya idadi ya AS zilizoangaziwa. Lakini hapa inafaa kuelewa kuwa AS sio sawa kabisa na mtoaji. Watoa huduma wengine hawana AS yao wenyewe, wengine wana zaidi ya mmoja. Ikiwa tunadhani kwamba kila mtu bado ana Mawakala, basi mtu huchuja kwa nguvu zaidi kuliko wengine, ili maombi yao yawe tofauti na takataka, ikiwa yanawafikia kabisa. Lakini kwa tathmini mbaya inaweza kuvumiliwa, hata ikiwa kitu kilipotea kwa sababu ya uangalizi wangu.
Kuhusu DPI
Licha ya ukweli kwamba mtoa huduma wangu wa mwenyeji aliwasha chujio chake kuanzia siku ya pili, kulingana na taarifa kutoka siku ya kwanza tunaweza kuhitimisha kuwa kuzuia kunafanya kazi kwa mafanikio. Vyanzo 4 pekee ndivyo vilivyoweza kupitia na kukamilisha vipindi vya HTTP na TCP (kama ilivyo kwenye mfano hapo juu). Nyingine 460 zinaweza kutumwa GET, lakini kikao kimekatishwa mara moja na RST. Makini na 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"
Tofauti za hii inaweza kuwa tofauti: chini RST au uhamishaji zaidi - pia inategemea kile kichungi hutuma kwa nodi ya chanzo. Kwa hali yoyote, hii ndiyo template ya kuaminika zaidi, ambayo ni wazi kwamba ilikuwa ni rasilimali iliyokatazwa ambayo iliombwa. Pamoja kila wakati kuna jibu ambalo linaonekana kwenye kikao na TTL kubwa kuliko katika vifurushi vilivyotangulia na vilivyofuata.
Huwezi hata kuiona kutoka kwa wengine 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"
Au hivyo:
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"
...
Tofauti inaonekana dhahiri TTL ikiwa kitu kinatoka kwenye kichungi. Lakini mara nyingi hakuna kitu kinachoweza kufika kabisa:
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"
...
Au hivyo:
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"
...
Na hii yote inarudiwa na kurudiwa na kurudiwa, kama inavyoonekana kwenye grafu, zaidi ya mara moja, kila siku.
Kuhusu IPv6
Habari njema ni kwamba ipo. Ninaweza kusema kwa uhakika kwamba maombi ya mara kwa mara kwa rasilimali iliyopigwa marufuku hutokea kutoka kwa anwani 5 tofauti za IPv6, ambayo ni tabia haswa ya Mawakala ambayo nilitarajia. Kwa kuongezea, moja ya anwani za IPv6 haingii chini ya uchujaji na naona kikao kamili. Kutoka mbili zaidi niliona kikao kimoja tu ambacho hakijakamilika, ambacho kimoja kiliingiliwa na RST kutoka kwa kichungi, pili kwa wakati. Jumla 7.
Kwa kuwa kuna anwani chache, nilisoma zote kwa undani na ikawa kwamba kuna watoa huduma 3 tu huko, wanaweza kupewa ovation iliyosimama! Anwani nyingine ni mwenyeji wa wingu nchini Urusi (haina chujio), mwingine ni kituo cha utafiti nchini Ujerumani (kuna chujio, wapi?). Lakini kwa nini wanaangalia upatikanaji wa rasilimali zilizopigwa marufuku kwenye ratiba ni swali zuri. Wawili waliobaki walifanya ombi moja na ziko nje ya Urusi, na mmoja wao huchujwa (katika usafiri, baada ya yote?).
Kuzuia na Mawakala ni kikwazo kikubwa kwa IPv6, ambayo utekelezaji wake hauendi haraka sana. Inasikitisha. Wale ambao walitatua tatizo hili wanaweza kujivunia kikamilifu.
Kwa kumalizia
Sikujitahidi kwa usahihi wa 100%, tafadhali nisamehe kwa hili, natumaini mtu anataka kurudia kazi hii kwa usahihi zaidi. Ilikuwa muhimu kwangu kuelewa ikiwa mbinu hii ingefanya kazi kimsingi. Jibu ni ndiyo. Takwimu zilizopatikana, kama makadirio ya kwanza, nadhani, ni za kuaminika kabisa.
Nini kingine kingeweza kufanywa na nilichokuwa mvivu sana kufanya ni kuhesabu maombi ya DNS. Hazijachujwa, lakini pia hazitoi usahihi mwingi kwani zinafanya kazi kwa kikoa pekee, na sio kwa URL nzima. Frequency inapaswa kuonekana. Ikiwa unachanganya na kile kinachoonekana moja kwa moja kwenye maswali, hii itakuruhusu kutenganisha isiyo ya lazima na kupata habari zaidi. Inawezekana hata kuamua watengenezaji wa DNS inayotumiwa na watoa huduma na mengi zaidi.
Sikutarajia kabisa kuwa mwenyeji pia angejumuisha kichungi chake cha VPS yangu. Labda hii ni mazoezi ya kawaida. Mwishowe, RKN inatuma ombi la kufuta rasilimali kwa mwenyeji. Lakini hii haikunishangaza na kwa njia fulani hata ilifanya kazi kwa faida yangu. Kichujio kilifanya kazi kwa ufanisi mkubwa, kukata maombi yote sahihi ya HTTP kwa URL iliyopigwa marufuku, lakini si sahihi ambayo hapo awali yalipitia kichujio cha watoa huduma yaliwafikia, ingawa tu katika mfumo wa miisho: FIN-ACK и RST - minus kwa minus na karibu iligeuka kuwa plus. Kwa njia, IPv6 haikuchujwa na mhudumu. Bila shaka, hii iliathiri ubora wa nyenzo zilizokusanywa, lakini bado ilifanya iwezekanavyo kuona mzunguko. Ilibadilika kuwa hii ni hatua muhimu wakati wa kuchagua tovuti ya kuweka rasilimali; usisahau kupendezwa na suala la kuandaa kazi na orodha ya tovuti zilizopigwa marufuku na maombi kutoka kwa RKN.
Mwanzoni, nililinganisha "Mkaguzi" wa AS na . Ulinganisho huu ni sahihi kabisa na mtandao mkubwa wa Mawakala unaweza kuwa wa manufaa. Kwa mfano, kubainisha ubora wa upatikanaji wa rasilimali kutoka kwa watoa huduma mbalimbali katika sehemu mbalimbali za nchi. Unaweza kuhesabu ucheleweshaji, unaweza kuunda grafu, unaweza kuchanganua yote na kuona mabadiliko yanayotokea ndani na kimataifa. Hii sio njia ya moja kwa moja, lakini wanaastronomia hutumia "mishumaa ya kawaida", kwa nini usitumie Wakala? Kujua (baada ya kupata) tabia zao za kawaida, unaweza kuamua mabadiliko yanayotokea karibu nao na jinsi hii inathiri ubora wa huduma zinazotolewa. Na wakati huo huo, hauitaji kuweka probes kwa uhuru kwenye mtandao; Roskomnadzor tayari imeziweka.
Jambo lingine ninalotaka kugusia ni kwamba kila chombo kinaweza kuwa silaha. AS "Inspekta" ni mtandao uliofungwa, lakini Mawakala hukabidhi kila mtu kwa kutuma maombi ya rasilimali zote kutoka kwa orodha iliyopigwa marufuku. Kuwa na rasilimali kama hiyo haitoi shida yoyote. Kwa jumla, watoa huduma kupitia Mawakala, bila kujua, wanasema mengi zaidi kuhusu mtandao wao kuliko inavyowezekana: aina za DPI na DNS, eneo la Wakala (nodi ya kati na mtandao wa huduma?), alama za mtandao za ucheleweshaji na hasara - na hii ni tu dhahiri zaidi. Kama vile mtu anavyoweza kufuatilia vitendo vya Mawakala ili kuboresha upatikanaji wa rasilimali zao, mtu anaweza kufanya hivi kwa madhumuni mengine na hakuna vikwazo kwa hili. Matokeo yake ni chombo chenye ncha mbili na chenye sura nyingi sana, mtu yeyote anaweza kuona hili.
Chanzo: mapenzi.com