Bukan rahsia lagi bahawa kawalan menyekat pada senarai maklumat yang dilarang di Rusia dipantau oleh sistem automatik "Inspektor". Cara ia berfungsi ditulis dengan baik di sini , gambar dari tempat yang sama:
Dipasang terus pada pembekal :
Modul "Agen Inspektor" ialah elemen struktur sistem automatik "Inspektor" (AS "Inspektor"). Sistem ini direka bentuk untuk memantau pematuhan oleh pengendali telekomunikasi dengan keperluan sekatan akses dalam rangka kerja peruntukan yang ditetapkan oleh Artikel 15.1-15.4 Undang-undang Persekutuan 27 Julai 2006 No. 149-FZ βMengenai Maklumat, Teknologi Maklumat dan Perlindungan Maklumat. β
Tujuan utama mewujudkan AS "Revizor" adalah untuk memastikan pemantauan pematuhan operator telekom dengan keperluan yang ditetapkan oleh Artikel 15.1-15.4 Undang-undang Persekutuan 27 Julai 2006 No. 149-FZ "Mengenai Maklumat, Teknologi Maklumat dan Perlindungan Maklumat " dari segi mengenal pasti fakta akses kepada maklumat yang dilarang dan mendapatkan bahan sokongan (data) tentang pelanggaran untuk menyekat akses kepada maklumat yang dilarang.
Mengambil kira hakikat bahawa, jika tidak semua, maka banyak pembekal telah memasang peranti ini, sepatutnya terdapat rangkaian besar probe suar seperti dan lebih banyak lagi, tetapi dengan akses tertutup. Walau bagaimanapun, suar ialah suar untuk menghantar isyarat ke semua arah, tetapi bagaimana jika kita menangkapnya dan melihat apa yang kita tangkap dan berapa banyak?
Sebelum kita mengira, mari lihat mengapa ini mungkin berlaku.
Sedikit teori
Ejen menyemak ketersediaan sumber, termasuk melalui permintaan HTTP(S), seperti yang ini:
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"
Sebagai tambahan kepada muatan, permintaan itu juga terdiri daripada fasa penubuhan sambungan: pertukaran SYN ΠΈ SYN-ACK, dan fasa penyiapan sambungan: FIN-ACK.
Daftar maklumat yang dilarang mengandungi beberapa jenis penyekatan. Jelas sekali, jika sumber disekat oleh alamat IP atau nama domain, maka kami tidak akan melihat sebarang permintaan. Ini adalah jenis penyekatan yang paling merosakkan, yang membawa kepada ketidakbolehcapaian semua sumber pada satu alamat IP atau semua maklumat pada domain. Terdapat juga jenis penyekatan "mengikut URL". Dalam kes ini, sistem penapisan mesti menghuraikan pengepala permintaan HTTP untuk menentukan dengan tepat apa yang hendak disekat. Dan sebelum itu, seperti yang dapat dilihat di atas, harus ada fasa penubuhan sambungan yang boleh anda cuba jejaki, kerana kemungkinan besar penapis akan terlepasnya.
Untuk melakukan ini, anda perlu memilih domain percuma yang sesuai dengan jenis penyekatan "URL" dan HTTP untuk memudahkan kerja sistem penapisan, sebaik-baiknya telah lama ditinggalkan, untuk meminimumkan kemasukan trafik luar kecuali daripada Ejen. Tugas ini ternyata tidak sukar sama sekali; terdapat banyak domain percuma dalam daftar maklumat terlarang dan untuk setiap selera. Oleh itu, domain tersebut telah dibeli dan dipautkan kepada alamat IP pada VPS yang dijalankan tcpdump dan pengiraan bermula.
Audit "Auditor"
Saya menjangkakan untuk melihat letusan permintaan berkala, yang pada pendapat saya akan menunjukkan tindakan terkawal. Tidak mustahil untuk mengatakan bahawa saya tidak melihatnya sama sekali, tetapi pastinya tiada gambaran yang jelas:
Yang tidak menghairankan, walaupun pada domain yang tiada siapa perlukan dan pada IP yang tidak pernah digunakan, hanya akan ada satu tan maklumat yang tidak diminta, seperti Internet moden. Tetapi mujurlah, saya hanya memerlukan permintaan untuk URL tertentu, jadi semua pengimbas dan pemecah kata laluan ditemui dengan cepat. Juga, agak mudah untuk memahami di mana banjir itu berdasarkan permintaan yang sama. Seterusnya, saya menyusun kekerapan berlakunya alamat IP dan melalui keseluruhan bahagian atas secara manual, memisahkan mereka yang terlepas pada peringkat sebelumnya. Selain itu, saya memotong semua sumber yang dihantar dalam satu pakej, tidak banyak lagi. Dan inilah yang berlaku:
Penyimpangan lirik yang kecil. Lebih sedikit daripada sehari kemudian, penyedia pengehosan saya menghantar surat dengan kandungan yang agak diperkemas, mengatakan bahawa kemudahan anda mengandungi sumber daripada senarai larangan RKN, jadi ia disekat. Pada mulanya saya fikir akaun saya telah disekat, ini tidak berlaku. Kemudian saya fikir mereka hanya memberi amaran kepada saya tentang sesuatu yang saya sudah tahu. Tetapi ternyata hoster menghidupkan penapisnya di hadapan domain saya dan akibatnya saya mengalami penapisan berganda: daripada penyedia dan dari hoster. Penapis hanya melepasi hujung permintaan: FIN-ACK ΠΈ RST memotong semua HTTP pada URL yang dilarang. Seperti yang anda lihat dari graf di atas, selepas hari pertama saya mula menerima kurang data, tetapi saya masih menerimanya, yang cukup untuk tugas mengira sumber permintaan.
Sampai ke intinya. Pada pendapat saya, dua letusan jelas kelihatan setiap hari, yang pertama lebih kecil, selepas tengah malam waktu Moscow, yang kedua lebih dekat ke 6 pagi dengan ekor sehingga 12 tengah hari. Puncak tidak berlaku pada masa yang sama. Pada mulanya, saya ingin memilih alamat IP yang jatuh hanya dalam tempoh ini dan setiap satu dalam semua tempoh, berdasarkan andaian bahawa semakan oleh Ejen dilakukan secara berkala. Tetapi setelah disemak dengan teliti, saya dengan cepat mendapati tempoh yang jatuh ke dalam selang lain, dengan frekuensi lain, sehingga satu permintaan setiap jam. Kemudian saya berfikir tentang zon waktu dan mungkin ia ada kaitan dengannya, kemudian saya fikir secara umum sistem itu mungkin tidak disegerakkan secara global. Di samping itu, NAT mungkin akan memainkan peranan dan Ejen yang sama boleh membuat permintaan daripada IP awam yang berbeza.
Oleh kerana matlamat awal saya tidak tepat, saya mengira semua alamat yang saya temui dalam seminggu dan mendapat - 2791. Bilangan sesi TCP yang ditubuhkan daripada satu alamat adalah secara purata 4, dengan median 2. Sesi teratas bagi setiap alamat: 464, 231, 149, 83, 77. Maksimum daripada 95% sampel ialah 8 sesi bagi setiap alamat. Median tidak terlalu tinggi, izinkan saya mengingatkan anda bahawa graf menunjukkan keberkalaan harian yang jelas, jadi seseorang boleh menjangkakan sesuatu sekitar 4 hingga 8 dalam 7 hari. Jika kita membuang semua sesi yang berlaku sekali, kita akan mendapat median bersamaan dengan 5. Tetapi saya tidak boleh mengecualikannya berdasarkan kriteria yang jelas. Sebaliknya, semakan rawak menunjukkan bahawa ia berkaitan dengan permintaan untuk sumber terlarang.
Alamat adalah alamat, tetapi di Internet, sistem autonomi - AS, yang ternyata lebih penting 1510, secara purata 2 alamat setiap AS dengan median 1. Alamat teratas setiap AS: 288, 77, 66, 39, 27. Maksimum 95% daripada sampel ialah 4 alamat setiap AS. Di sini median dijangka - satu Ejen bagi setiap pembekal. Kami juga mengharapkan yang teratas - terdapat pemain besar di dalamnya. Dalam rangkaian yang besar, Ejen mungkin harus ditempatkan di setiap wilayah kehadiran pengendali, dan jangan lupa tentang NAT. Jika kita mengambilnya mengikut negara, maksimum ialah: 1409 - RU, 42 - UA, 23 - CZ, 36 dari wilayah lain, bukan RIPE NCC. Permintaan dari luar Rusia menarik perhatian. Ini mungkin boleh dijelaskan oleh ralat geolokasi atau ralat pendaftar semasa mengisi data. Atau fakta bahawa syarikat Rusia mungkin tidak mempunyai akar Rusia, atau mempunyai pejabat perwakilan asing kerana ia lebih mudah, yang wajar apabila berurusan dengan organisasi asing RIPE NCC. Sesetengah bahagian sudah pasti berlebihan, tetapi sukar untuk dipisahkan, kerana sumber itu disekat, dan dari hari kedua di bawah sekatan berganda, dan kebanyakan sesi hanyalah pertukaran beberapa paket perkhidmatan. Mari kita bersetuju bahawa ini adalah sebahagian kecil.
Nombor ini sudah boleh dibandingkan dengan bilangan pembekal di Rusia. lesen untuk "Perkhidmatan komunikasi untuk penghantaran data, tidak termasuk suara" - 6387, tetapi ini adalah anggaran yang sangat tinggi dari atas, tidak semua lesen ini terpakai khusus kepada penyedia Internet yang perlu memasang Ejen. Di zon RIPE NCC terdapat bilangan AS yang sama yang didaftarkan di Rusia - 6230, yang mana tidak semuanya adalah pembekal. dan menerima 3940 syarikat pada 2017, dan ini agak anggaran dari atas. Walau apa pun, kami mempunyai dua setengah kali ganda bilangan AS yang bercahaya. Tetapi di sini perlu difahami bahawa AS tidak sama dengan pembekal. Sesetengah pembekal tidak mempunyai AS sendiri, ada yang mempunyai lebih daripada satu. Jika kita menganggap bahawa setiap orang masih mempunyai Ejen, maka seseorang menapis lebih kuat daripada yang lain, supaya permintaan mereka tidak dapat dibezakan dengan sampah, jika mereka sampai kepada mereka sama sekali. Tetapi untuk penilaian kasar ia agak boleh diterima, walaupun ada sesuatu yang hilang kerana kelalaian saya.
Mengenai DPI
Walaupun pembekal pengehosan saya menghidupkan penapisnya bermula dari hari kedua, berdasarkan maklumat dari hari pertama kami dapat menyimpulkan bahawa penyekatan berfungsi dengan jayanya. Hanya 4 sumber yang dapat melalui dan telah menyelesaikan sepenuhnya sesi HTTP dan TCP (seperti dalam contoh di atas). 460 lagi boleh dihantar GET, tetapi sesi ditamatkan serta-merta oleh RST. Beri perhatian kepada 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 ini boleh berbeza: kurang RST atau lebih banyak penghantaran semula - juga bergantung pada apa yang dihantar oleh penapis ke nod sumber. Walau apa pun, ini adalah templat yang paling boleh dipercayai, dari mana jelas bahawa ia adalah sumber terlarang yang diminta. Tambahan pula sentiasa ada jawapan yang muncul dalam sesi dengan TTL lebih besar daripada pakej sebelumnya dan seterusnya.
Anda tidak dapat melihatnya dari yang lain 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"
Atau begitu:
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"
...
Perbezaannya pasti kelihatan TTL jika sesuatu datang dari penapis. Tetapi selalunya tiada apa yang mungkin tiba sama sekali:
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"
...
Atau begitu:
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"
...
Dan semua ini diulang dan diulang dan diulang, seperti yang dapat dilihat pada graf, lebih daripada sekali, setiap hari.
Mengenai IPv6
Berita baiknya ialah ia wujud. Saya boleh mengatakan dengan pasti bahawa permintaan berkala kepada sumber terlarang berlaku daripada 5 alamat IPv6 yang berbeza, iaitu kelakuan Ejen yang saya jangkakan. Selain itu, salah satu alamat IPv6 tidak termasuk dalam penapisan dan saya melihat sesi penuh. Dari dua lagi saya melihat hanya satu sesi yang belum selesai, satu daripadanya diganggu oleh RST daripada penapis, kedua dalam masa. Jumlah keseluruhan 7.
Oleh kerana alamatnya sedikit, saya kaji kesemuanya secara terperinci dan ternyata hanya ada 3 penyedia di sana, mereka boleh diberi tepukan gemuruh! Alamat lain ialah hosting awan di Rusia (tidak menapis), satu lagi adalah pusat penyelidikan di Jerman (ada penapis, di mana?). Tetapi mengapa mereka menyemak ketersediaan sumber terlarang pada jadual adalah soalan yang baik. Dua yang selebihnya membuat satu permintaan dan terletak di luar Rusia, dan salah satu daripadanya ditapis (sedang dalam transit, selepas semua?).
Penyekatan dan Ejen merupakan penghalang besar kepada IPv6, yang pelaksanaannya tidak bergerak dengan pantas. memang sedih. Mereka yang menyelesaikan masalah ini boleh berbangga dengan diri mereka sendiri.
Kesimpulannya
Saya tidak berusaha untuk ketepatan 100%, harap maafkan saya untuk ini, saya harap seseorang ingin mengulangi kerja ini dengan lebih ketepatan. Adalah penting bagi saya untuk memahami sama ada pendekatan ini akan berfungsi secara prinsip. Jawapannya ya. Sebagai anggaran pertama, angka yang diperoleh, saya fikir, agak boleh dipercayai.
Apa lagi yang boleh dilakukan dan apa yang saya malas lakukan ialah mengira permintaan DNS. Ia tidak ditapis, tetapi ia juga tidak memberikan banyak ketepatan kerana ia hanya berfungsi untuk domain, dan bukan untuk keseluruhan URL. Kekerapan harus kelihatan. Jika anda menggabungkannya dengan perkara yang boleh dilihat secara langsung dalam pertanyaan, ini akan membolehkan anda mengasingkan yang tidak perlu dan mendapatkan maklumat lanjut. Malah mungkin untuk menentukan pembangun DNS yang digunakan oleh pembekal dan banyak lagi.
Saya sama sekali tidak menjangkakan bahawa hoster juga akan menyertakan penapisnya sendiri untuk VPS saya. Mungkin ini amalan biasa. Akhirnya, RKN menghantar permintaan untuk memadamkan sumber kepada hoster. Tetapi ini tidak memeranjatkan saya dan dalam beberapa cara malah berkesan untuk kelebihan saya. Penapis berfungsi dengan sangat berkesan, memotong semua permintaan HTTP yang betul kepada URL yang dilarang, tetapi tidak betul yang telah melalui penapis pembekal sebelum ini mencapainya, walaupun hanya dalam bentuk pengakhiran: FIN-ACK ΠΈ RST - tolak untuk tolak dan ia hampir menjadi tambah. By the way, IPv6 tidak ditapis oleh hoster. Sudah tentu, ini menjejaskan kualiti bahan yang dikumpul, tetapi ia masih memungkinkan untuk melihat kekerapan. Ternyata ini adalah perkara penting apabila memilih tapak untuk meletakkan sumber; jangan lupa untuk mengambil minat dalam isu mengatur kerja dengan senarai tapak terlarang dan permintaan daripada RKN.
Pada mulanya, saya membandingkan AS "Inspektor" dengan . Perbandingan ini agak wajar dan rangkaian besar Ejen boleh memberi manfaat. Contohnya, menentukan kualiti ketersediaan sumber daripada pembekal yang berbeza di bahagian yang berlainan di negara ini. Anda boleh mengira kelewatan, anda boleh membina graf, anda boleh menganalisis semuanya dan melihat perubahan yang berlaku di peringkat tempatan dan global. Ini bukan cara yang paling langsung, tetapi ahli astronomi menggunakan "lilin standard", mengapa tidak menggunakan Ejen? Mengetahui (setelah menemui) tingkah laku standard mereka, anda boleh menentukan perubahan yang berlaku di sekeliling mereka dan cara ini mempengaruhi kualiti perkhidmatan yang disediakan. Dan pada masa yang sama, anda tidak perlu meletakkan probe secara bebas pada rangkaian; Roskomnadzor telah memasangnya.
Satu lagi perkara yang ingin saya sentuh ialah setiap alatan boleh menjadi senjata. AS "Inspektor" ialah rangkaian tertutup, tetapi Ejen menyerahkan semua orang dengan menghantar permintaan untuk semua sumber daripada senarai yang dilarang. Mempunyai sumber sedemikian tidak menimbulkan sebarang masalah sama sekali. Secara keseluruhan, pembekal melalui Ejen, tanpa disedari, memberitahu lebih banyak tentang rangkaian mereka daripada yang mungkin berbaloi: jenis DPI dan DNS, lokasi Ejen (nod pusat dan rangkaian perkhidmatan?), penanda rangkaian kelewatan dan kerugian - dan ini adalah hanya yang paling jelas. Sama seperti seseorang boleh memantau tindakan Ejen untuk meningkatkan ketersediaan sumber mereka, seseorang boleh melakukan ini untuk tujuan lain dan tiada halangan untuk ini. Hasilnya ialah instrumen bermata dua dan sangat pelbagai rupa, sesiapa sahaja boleh melihat ini.
Sumber: www.habr.com