Ora ana rahasia manawa kontrol pamblokiran ing dhaptar informasi sing dilarang ing Rusia dipantau dening sistem otomatis "Inspektur". Cara kerjane ditulis kanthi apik ing kene , gambar saka panggonan sing padha:
Dipasang langsung ing panyedhiya :
Modul "Agen Inspektur" minangka unsur struktural saka sistem otomatis "Inspektur" (AS "Inspektur"). Sistem iki dirancang kanggo ngawasi selaras karo operator telekomunikasi karo syarat watesan akses ing framework saka pranata ditetepake dening Artikel 15.1-15.4 saka Hukum Federal 27 Juli 2006 No. 149-FZ "Ing Informasi, Teknologi Informasi lan Protection Informasi. ”
Tujuan utama nggawe AS "Revizor" yaiku kanggo mesthekake ngawasi kepatuhan operator telekomunikasi karo syarat sing ditetepake dening Artikel 15.1-15.4 saka Hukum Federal 27 Juli 2006 No. 149-FZ "On Information, Information Technologies and Information Protection " ing babagan ngenali kasunyatan akses menyang informasi sing dilarang lan entuk bahan pendukung (data) babagan pelanggaran kanggo mbatesi akses menyang informasi sing dilarang.
Ngelingi kasunyatan manawa, yen ora kabeh, mula akeh panyedhiya wis nginstal piranti iki, mesthine ana jaringan probe beacon sing gedhe kaya lan malah liyane, nanging karo akses ditutup. Nanging, beacon minangka mercusuar kanggo ngirim sinyal ing kabeh arah, nanging apa yen kita nyekel lan ndeleng apa sing kejiret lan pira?
Sadurunge ngetung, ayo ndeleng kenapa iki bisa uga.
Minangka teori
Agen mriksa kasedhiyan sumber daya, kalebu liwat panjalukan HTTP(S), kayata:
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"
Saliyane payload, request uga kasusun saka phase panyiapan sambungan: exchange SYN и SYN-ACK, lan fase rampung sambungan: FIN-ACK.
Daftar informasi sing dilarang ngemot sawetara jinis pamblokiran. Temenan, yen sumber daya diblokir dening alamat IP utawa jeneng domain, banjur kita ora bakal weruh panjalukan. Iki minangka jinis pamblokiran sing paling ngrusak, sing nyebabake ora bisa diakses kabeh sumber daya ing siji alamat IP utawa kabeh informasi ing domain. Ana uga jinis pamblokiran "dening URL". Ing kasus iki, sistem panyaring kudu ngurai header panjalukan HTTP kanggo nemtokake apa sing kudu diblokir. Lan sadurunge, kaya sing bisa dideleng ing ndhuwur, kudu ana fase panyiapan sambungan sing bisa dilacak, amarga panyaring kasebut bakal ilang.
Kanggo nindakake iki, sampeyan kudu milih domain gratis sing cocog karo "URL" lan jinis pamblokiran HTTP kanggo nggampangake karya sistem panyaring, luwih suwe ditinggalake, kanggo nyilikake entri lalu lintas asing kajaba saka Agen. Tugas iki ora angel banget, ana cukup akeh domain gratis ing daftar informasi sing dilarang lan kanggo saben rasa. Mulane, domain kasebut dituku lan disambungake menyang alamat IP ing VPS sing mlaku tcpdump lan pancacahan diwiwiti.
Audit "Auditor"
Aku ngarep-arep bisa ndeleng panjaluk kanthi periodik, sing miturut pendapatku bakal nuduhake tumindak sing dikontrol. Ora mungkin ujar manawa aku ora weruh, nanging ora ana gambar sing jelas:
Sing ora nggumunake, sanajan ing domain sing ora ana sing dibutuhake lan ing IP sing ora tau digunakake, mung bakal ana akeh informasi sing ora dikarepake, kayata Internet modern. Nanging untunge, aku mung butuh panjaluk URL tartamtu, mula kabeh pemindai lan krupuk sandi cepet ditemokake. Uga, iku cukup gampang kanggo ngerti ngendi banjir adhedhasar massa panjalukan padha. Sabanjure, aku nyusun frekuensi kedadeyan alamat IP lan ngliwati kabeh ndhuwur kanthi manual, misahake sing ora kejawab ing tahap sadurunge. Tambahan, aku Cut metu kabeh sumber sing dikirim ing siji paket, ana ora akeh maneh. Lan iki kedadeyan:
A digression lyrical cilik. Luwih sedina, panyedhiya hostingku ngirim layang isine rada ramping, jarene fasilitasmu ana sumber saka daftar larangan RKN, mula diblokir. Kaping pisanan aku mikir yen akunku diblokir, ora kaya ngono. Banjur aku mikir yen dheweke mung ngelingake aku babagan prekara sing wis dakngerteni. Nanging ternyata hoster nguripake panyaring ing ngarep domainku lan minangka asil aku ngalami panyaring ganda: saka panyedhiya lan saka hoster. Filter mung ngliwati panjalukan: FIN-ACK и RST nglereni kabeh HTTP ing URL sing dilarang. Nalika sampeyan bisa ndeleng saka grafik ing ndhuwur, sawise dina pisanan aku wiwit nampa kurang data, nanging aku isih nampa, kang cukup kanggo tugas ngetang sumber request.
Njaluk menyang titik. Miturut pendapatku, rong bledosan katon jelas saben dina, sing pisanan luwih cilik, sawise tengah wengi wektu Moskow, sing kapindho nyedhaki jam 6 esuk kanthi buntut nganti jam 12 awan. Puncak kasebut ora kedadeyan ing wektu sing padha. Kaping pisanan, aku pengin milih alamat IP sing mung tiba ing wektu kasebut lan saben wektu, adhedhasar asumsi yen mriksa Agen ditindakake sacara periodik. Nanging sawise ditinjau kanthi ati-ati, aku cepet nemokake wektu sing tiba ing interval liyane, kanthi frekuensi liyane, nganti siji panjaluk saben jam. Banjur aku mikir babagan zona wektu lan bisa uga ana hubungane karo dheweke, mula aku mikir yen umume sistem kasebut ora bisa disinkronake sacara global. Kajaba iku, NAT bisa uga duwe peran lan Agen sing padha bisa njaluk panjaluk saka IP umum sing beda.
Amarga tujuan awalku ora persis, aku ngetung kabeh alamat sing aku temokake sajrone seminggu lan entuk - 2791. Jumlah sesi TCP sing ditetepake saka siji alamat rata-rata 4, kanthi rata-rata 2. Sesi paling ndhuwur saben alamat: 464, 231, 149, 83, 77. Maksimum saka 95% sampel yaiku 8 sesi saben alamat. Median ora dhuwur banget, supaya aku ngelingake yen grafik nuduhake periodicity saben dina sing jelas, saengga bisa nyana udakara 4 nganti 8 ing 7 dina. Yen kita mbuwang kabeh sesi sing kedadeyan sapisan, kita bakal entuk median sing padha karo 5. Nanging aku ora bisa ngilangi adhedhasar kritéria sing jelas. Ing nalisir, mriksa acak nuduhake yen padha related kanggo panjalukan kanggo sumber dilarang.
Alamat minangka alamat, nanging ing Internet, sistem otonom - AS, sing dadi luwih penting 1510, rata-rata 2 alamat saben AS kanthi rata-rata 1. Alamat paling dhuwur saben AS: 288, 77, 66, 39, 27. Maksimum 95% sampel yaiku 4 alamat saben AS. Kene median samesthine - siji Agen saben panyedhiya. Kita uga ngarepake ndhuwur - ana pemain gedhe. Ing jaringan gedhe, Agen mbokmenawa kudu dumunung ing saben wilayah saka ngarsane operator, lan aja lali bab NAT. Yen kita njupuk miturut negara, maksimum bakal: 1409 - RU, 42 - UA, 23 - CZ, 36 saka wilayah liyane, ora RIPE NCC. Panjaluk saka njaba Rusia narik kawigaten. Iki bisa uga diterangake kanthi kesalahan geolokasi utawa kesalahan registrar nalika ngisi data. Utawa kasunyatan manawa perusahaan Rusia ora duwe akar Rusia, utawa duwe kantor perwakilan manca amarga luwih gampang, sing alami nalika nangani organisasi manca RIPE NCC. Sawetara bagean temtunipun superfluous, nanging andal angel kanggo misahake, amarga sumber daya ing Watesan, lan saka dina kapindho ing pamblokiran pindho, lan paling sesi mung ijol-ijolan sawetara paket layanan. Ayo padha setuju yen iki minangka bagean cilik.
Nomer kasebut wis bisa dibandhingake karo jumlah panyedhiya ing Rusia. lisensi kanggo "Layanan komunikasi kanggo transmisi data, ora kalebu swara" - 6387, nanging iki prakiraan dhuwur banget saka ndhuwur, ora kabeh lisensi iki ditrapake khusus kanggo panyedhiya Internet sing kudu nginstal Agen. Ing zona RIPE NCC ana jumlah sing padha saka AS sing didaftar ing Rusia - 6230, sing ora kabeh panyedhiya. lan nampa 3940 perusahaan ing 2017, lan iki luwih ngira saka ndhuwur. Ing kasus apa wae, kita duwe jumlah AS sing padhang kaping pindho lan kaping pindho. Nanging ing kene kudu dingerteni manawa AS ora padha karo panyedhiya. Sawetara panyedhiya ora duwe AS dhewe, sawetara duwe luwih saka siji. Yen kita nganggep manawa saben wong isih duwe Agen, mula ana sing nyaring luwih kuat tinimbang liyane, saengga panjaluke ora bisa dibedakake karo sampah, yen tekan kabeh. Nanging kanggo taksiran kasar iku cukup lumayan, sanajan ana sing ilang amarga kelalaianku.
Babagan DPI
Senadyan kasunyatan manawa panyedhiya hosting saya nguripake panyaring kasebut wiwit dina kapindho, adhedhasar informasi saka dina pisanan, kita bisa nyimpulake yen pamblokiran kasebut sukses. Mung 4 sumber sing bisa liwat lan wis rampung ngrampungake sesi HTTP lan TCP (kaya ing conto ing ndhuwur). 460 liyane bisa dikirim GET, nanging sesi langsung mungkasi dening RST. Pay manungsa waé kanggo 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"
Variasi iki bisa beda: kurang RST utawa luwih retransmits - uga gumantung apa sing dikirim Filter menyang simpul sumber. Ing kasus apa wae, iki minangka cithakan sing paling dipercaya, sing jelas manawa sumber sing dilarang sing dijaluk. Plus tansah ana jawaban sing katon ing sesi karo TTL luwih gedhe tinimbang ing paket sadurunge lan sakteruse.
Sampeyan malah ora bisa ndeleng saka liyane 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"
Utawa:
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"
...
Bentenipun mesthi katon TTL yen soko teka saka Filter. Nanging asring ora ana sing bisa teka:
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"
...
Utawa:
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"
...
Lan kabeh iki bola-bali lan bola-bali lan bola-bali, kaya sing bisa dideleng ing grafik, luwih saka sepisan, saben dina.
Babagan IPv6
Kabar apik iku ana. Aku bisa dipercaya manawa panjaluk periodik menyang sumber sing dilarang dumadi saka 5 alamat IPv6 sing beda-beda, yaiku prilaku Agen sing dakkarepake. Kajaba iku, salah sawijining alamat IPv6 ora ana ing nyaring lan aku ndeleng sesi lengkap. Saka loro liyane aku weruh mung siji sesi durung rampung, siji kang diselani dening RST saka panyaring, kaping pindho ing wektu. Jumlah total 7.
Amarga ana sawetara alamat, aku sinau kabeh kanthi rinci lan ternyata mung ana 3 panyedhiya ing kana, bisa diwenehi standing ovation! Alamat liyane yaiku cloud hosting ing Rusia (ora nyaring), liyane minangka pusat riset ing Jerman (ana filter, ing endi?). Nanging kenapa dheweke mriksa kasedhiyan sumber daya sing dilarang ing jadwal minangka pitakonan sing apik. Loro sing isih ana nggawe siji panjaluk lan dumunung ing njaba Rusia, lan salah sijine disaring (ing transit, sawise kabeh?).
Pamblokiran lan Agen minangka alangan gedhe kanggo IPv6, implementasine ora cepet banget. Sedhih. Wong-wong sing ngrampungake masalah iki bisa kanthi bangga karo awake dhewe.
Ing kesimpulan
Aku ora ngupayakake akurasi 100%, nyuwun pangapunten babagan iki, muga-muga ana sing pengin mbaleni karya iki kanthi luwih akurat. Iku penting kanggo kula kanggo ngerti apa pendekatan iki bakal bisa ing asas. Jawabane ya. Angka sing dipikolehi, minangka perkiraan pisanan, aku mikir, cukup dipercaya.
Apa maneh sing bisa ditindakake lan apa sing dakkarepake yaiku ngetung panjaluk DNS. Dheweke ora disaring, nanging uga ora nyedhiyakake akurasi amarga mung bisa digunakake kanggo domain, lan ora kanggo kabeh URL. Frekuensi kudu katon. Yen sampeyan gabungke karo apa sing katon langsung ing pitakon, iki bakal ngidini sampeyan misahake sing ora perlu lan entuk informasi luwih lengkap. Malah bisa nemtokake pangembang DNS sing digunakake dening panyedhiya lan liya-liyane.
Aku pancene ora ngarep-arep yen hoster uga bakal kalebu filter dhewe kanggo VPSku. Mungkin iki praktik umum. Pungkasane, RKN ngirim panjaluk kanggo mbusak sumber kasebut menyang hoster. Nanging iki ora kaget aku lan ing sawetara cara malah bisa kanggo kauntungan sandi. Filter kasebut bisa digunakake kanthi efektif, ngilangi kabeh panjaluk HTTP sing bener menyang URL sing dilarang, nanging ora bener sing sadurunge wis liwati panyaring panyedhiya, sanajan mung ing wangun pungkasan: FIN-ACK и RST - minus kanggo minus lan meh dadi plus. Miturut cara, IPv6 ora disaring dening hoster. Mesthi, iki kena pengaruh kualitas materi sing diklumpukake, nanging isih bisa ndeleng frekuensi kasebut. Ternyata iki minangka titik penting nalika milih situs kanggo nempatake sumber daya, aja lali njupuk kapentingan ing masalah ngatur karya kanthi dhaptar situs sing dilarang lan panjaluk saka RKN.
Ing wiwitan, aku dibandhingake AS "Inspektur" karo . Perbandhingan iki cukup dibenerake lan jaringan Agen sing akeh bisa migunani. Contone, nemtokake kualitas kasedhiyan sumber daya saka macem-macem panyedhiya ing macem-macem negara. Sampeyan bisa ngetung wektu tundha, sampeyan bisa nggawe grafik, sampeyan bisa nganalisa kabeh lan ndeleng owah-owahan sing kedadeyan ing lokal lan global. Iki dudu cara sing paling langsung, nanging para astronom nggunakake "lilin standar", kenapa ora nggunakake Agen? Ngerti (wis nemokake) prilaku standar, sampeyan bisa nemtokake owah-owahan sing kedadeyan ing saubengé lan carane iki mengaruhi kualitas layanan sing diwenehake. Lan ing wektu sing padha, sampeyan ora perlu nyelehake probe ing jaringan kanthi mandiri; Roskomnadzor wis diinstal.
Titik liyane sing dakkarepake yaiku saben alat bisa dadi senjata. AS "Inspektur" minangka jaringan sing ditutup, nanging Agen nyerahake kabeh wong kanthi ngirim panjaluk kabeh sumber daya saka dhaptar sing dilarang. Nduweni sumber daya kasebut ora nyebabake masalah. Secara total, panyedhiya liwat Agen, tanpa disengaja, nyritakake luwih akeh babagan jaringan tinimbang sing cocog: jinis DPI lan DNS, lokasi Agen (jaringan simpul tengah lan jaringan layanan?), tandha jaringan telat lan kerugian - lan iki mung sing paling ketok. Kaya wong bisa ngawasi tumindak Agen kanggo nambah kasedhiyan sumber daya, wong bisa nindakake iki kanggo tujuan liyane lan ora ana alangan kanggo iki. Asil punika instrument pindho edged lan banget multifaceted, sapa bisa ndeleng iki.
Source: www.habr.com