Bukan rahasia lagi bahwa kontrol pemblokiran pada daftar informasi terlarang di Rusia dipantau oleh sistem otomatis “Inspektur”. Cara kerjanya ditulis dengan baik di sini , gambar dari tempat yang sama:
Dipasang langsung di penyedia :
Modul "Agen Inspektur" adalah elemen struktural dari sistem otomatis "Inspektur" (AS "Inspektur"). Sistem ini dirancang untuk memantau kepatuhan operator telekomunikasi terhadap persyaratan pembatasan akses dalam kerangka ketentuan yang ditetapkan oleh Pasal 15.1-15.4 Undang-Undang Federal 27 Juli 2006 No. 149-FZ “Tentang Informasi, Teknologi Informasi dan Perlindungan Informasi. ”
Tujuan utama pembuatan AS "Revizor" adalah untuk memastikan pemantauan kepatuhan operator telekomunikasi terhadap persyaratan yang ditetapkan oleh Pasal 15.1-15.4 Undang-Undang Federal 27 Juli 2006 No. 149-FZ "Tentang Informasi, Teknologi Informasi, dan Perlindungan Informasi dalam hal mengidentifikasi fakta akses terhadap informasi terlarang dan memperoleh materi pendukung (data) tentang pelanggaran untuk membatasi akses terhadap informasi terlarang.
Mempertimbangkan fakta bahwa, jika tidak semua, maka banyak penyedia telah memasang perangkat ini, seharusnya ada jaringan besar probe suar seperti dan bahkan lebih, tetapi dengan akses tertutup. Namun, beacon adalah suar yang mengirimkan sinyal ke segala arah, tapi bagaimana jika kita menangkapnya dan melihat apa yang kita tangkap dan berapa banyak?
Sebelum kita menghitungnya, mari kita lihat mengapa hal ini mungkin terjadi.
Sedikit teori
Agen memeriksa ketersediaan sumber daya, termasuk melalui permintaan HTTP(S), seperti 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"
Selain payload, permintaan juga terdiri dari fase pembentukan koneksi: pertukaran SYN и SYN-ACK, dan fase penyelesaian koneksi: FIN-ACK.
Daftar informasi terlarang berisi beberapa jenis pemblokiran. Jelasnya, jika sumber daya diblokir berdasarkan alamat IP atau nama domain, maka kami tidak akan melihat permintaan apa pun. Ini adalah jenis pemblokiran yang paling merusak, yang mengakibatkan tidak dapat diaksesnya semua sumber daya di satu alamat IP atau semua informasi di domain. Ada juga jenis pemblokiran “berdasarkan URL”. Dalam hal ini, sistem pemfilteran harus mengurai header permintaan HTTP untuk menentukan dengan tepat apa yang harus diblokir. Dan sebelumnya, seperti terlihat di atas, harus ada fase pembuatan koneksi yang bisa Anda coba lacak, karena kemungkinan besar filter akan melewatkannya.
Untuk melakukan ini, Anda perlu memilih domain gratis yang sesuai dengan jenis pemblokiran "URL" dan HTTP untuk memfasilitasi kerja sistem pemfilteran, sebaiknya yang sudah lama ditinggalkan, untuk meminimalkan masuknya lalu lintas asing kecuali dari Agen. Tugas ini ternyata tidak sulit sama sekali, ada cukup banyak domain gratis di daftar informasi terlarang dan untuk setiap selera. Oleh karena itu, domain tersebut dibeli dan ditautkan ke alamat IP pada VPS yang berjalan tcpdump dan penghitungan pun dimulai.
Audit "Auditor"
Saya memperkirakan akan melihat lonjakan permintaan secara berkala, yang menurut saya mengindikasikan tindakan terkendali. Tidak mungkin untuk mengatakan bahwa saya tidak melihatnya sama sekali, tetapi yang pasti tidak ada gambaran yang jelas:
Hal ini tidak mengherankan, bahkan pada domain yang tidak diperlukan oleh siapa pun dan pada IP yang tidak pernah digunakan, akan ada banyak sekali informasi yang tidak diminta, seperti Internet modern. Namun untungnya, saya hanya memerlukan permintaan untuk URL tertentu, sehingga semua pemindai dan pemecah kata sandi dapat ditemukan dengan cepat. Selain itu, cukup mudah untuk memahami penyebab banjir berdasarkan banyaknya permintaan serupa. Selanjutnya, saya mengkompilasi frekuensi kemunculan alamat IP dan memeriksa seluruh bagian atas secara manual, memisahkan mereka yang melewatkannya pada tahap sebelumnya. Apalagi semua sumber yang dikirim dalam satu paket sudah saya hilangkan, jumlahnya sudah tidak banyak lagi. Dan inilah yang terjadi:
Penyimpangan liris kecil. Kurang lebih sehari kemudian, penyedia hosting saya mengirimkan surat dengan konten yang agak sederhana, mengatakan bahwa fasilitas Anda mengandung sumber daya dari daftar terlarang RKN, sehingga diblokir. Awalnya saya mengira akun saya diblokir, ternyata tidak. Kemudian saya berpikir bahwa mereka hanya memperingatkan saya tentang sesuatu yang sudah saya ketahui. Namun ternyata penghosting mengaktifkan filternya di depan domain saya dan akibatnya saya mendapat penyaringan ganda: dari penyedia dan dari penghosting. Filter hanya meneruskan akhir permintaan: FIN-ACK и RST memotong semua HTTP pada URL terlarang. Seperti yang Anda lihat dari grafik di atas, setelah hari pertama saya mulai menerima lebih sedikit data, namun saya masih menerimanya, yang cukup untuk tugas menghitung sumber permintaan.
Langsung ke intinya. Menurut saya, dua semburan terlihat jelas setiap hari, yang pertama lebih kecil, setelah tengah malam waktu Moskow, yang kedua mendekati jam 6 pagi dengan ekor hingga jam 12 siang. Puncaknya tidak terjadi pada waktu yang bersamaan. Pada awalnya, saya ingin memilih alamat IP yang hanya ada pada periode ini dan masing-masing alamat IP pada semua periode, berdasarkan asumsi bahwa pemeriksaan oleh Agen dilakukan secara berkala. Namun setelah meninjau dengan cermat, saya segera menemukan periode yang berada dalam interval lain, dengan frekuensi lain, hingga satu permintaan setiap jam. Lalu saya berpikir tentang zona waktu dan mungkin ada hubungannya dengan mereka, lalu saya berpikir bahwa secara umum sistemnya mungkin tidak tersinkronisasi secara global. Selain itu, NAT mungkin akan berperan dan Agen yang sama dapat membuat permintaan dari IP publik yang berbeda.
Karena tujuan awal saya tidak tepat, saya menghitung semua alamat yang saya temukan dalam seminggu dan mendapatkan - 2791. Jumlah sesi TCP yang dibuat dari satu alamat rata-rata 4, dengan median 2. Sesi teratas per alamat: 464, 231, 149, 83, 77. Maksimum dari 95% sampel adalah 8 sesi per alamat. Mediannya tidak terlalu tinggi, izinkan saya mengingatkan Anda bahwa grafik menunjukkan periodisitas harian yang jelas, sehingga kita dapat memperkirakan sekitar 4 hingga 8 dalam 7 hari. Jika kita membuang semua sesi yang terjadi satu kali, kita akan mendapatkan median yang sama dengan 5. Tapi saya tidak bisa mengecualikan sesi tersebut berdasarkan kriteria yang jelas. Sebaliknya, pemeriksaan acak menunjukkan bahwa hal tersebut terkait dengan permintaan sumber daya terlarang.
Alamat adalah alamat, tetapi di Internet, sistem otonom - AS, yang ternyata lebih penting 1510, rata-rata 2 alamat per AS dengan median 1. Alamat teratas per AS: 288, 77, 66, 39, 27. Maksimal 95% sampel adalah 4 alamat per AS. Di sini median diharapkan - satu Agen per penyedia. Kami juga mengharapkan yang teratas – ada pemain besar di dalamnya. Dalam jaringan yang besar, Agen mungkin harus berlokasi di setiap wilayah keberadaan operator, dan jangan lupakan NAT. Kalau kita ambil per negara, maksimalnya adalah: 1409 - RU, 42 - UA, 23 - CZ, 36 dari wilayah lain, bukan RIPE NCC. Permintaan dari luar Rusia menarik perhatian. Hal ini mungkin disebabkan oleh kesalahan geolokasi atau kesalahan registrar saat mengisi data. Atau fakta bahwa perusahaan Rusia mungkin tidak berasal dari Rusia, atau memiliki kantor perwakilan asing karena lebih mudah, hal yang wajar ketika berhadapan dengan organisasi asing RIPE NCC. Beberapa bagian tidak diragukan lagi berlebihan, tetapi sulit untuk memisahkannya, karena sumber daya berada di bawah pemblokiran, dan sejak hari kedua berada di bawah pemblokiran ganda, dan sebagian besar sesi hanyalah pertukaran beberapa paket layanan. Mari kita sepakat bahwa ini adalah bagian kecil.
Angka-angka ini sudah bisa dibandingkan dengan jumlah penyedia di Rusia. lisensi untuk "Layanan komunikasi untuk transmisi data, tidak termasuk suara" - 6387, tetapi ini adalah perkiraan yang sangat tinggi dari atas, tidak semua lisensi ini berlaku khusus untuk penyedia Internet yang perlu menginstal Agen. Di zona RIPE NCC terdapat jumlah AS yang serupa yang terdaftar di Rusia - 6230, yang tidak semuanya merupakan penyedia. dan menerima 3940 perusahaan pada tahun 2017, dan ini merupakan perkiraan dari atas. Bagaimanapun, kita memiliki jumlah AS yang menyala dua setengah kali lebih sedikit. Namun di sini perlu dipahami bahwa AS tidak sepenuhnya setara dengan penyedia. Ada yang tidak mempunyai AS sendiri, ada pula yang lebih dari satu. Jika kita berasumsi bahwa setiap orang masih memiliki Agen, maka seseorang memfilter lebih kuat daripada yang lain, sehingga permintaan mereka tidak dapat dibedakan dari sampah, jika mereka menjangkau mereka sama sekali. Tapi untuk penilaian kasarnya cukup lumayan, walaupun ada yang hilang karena kekhilafan saya.
Tentang DPI
Terlepas dari kenyataan bahwa penyedia hosting saya mengaktifkan filternya mulai hari kedua, berdasarkan informasi dari hari pertama kami dapat menyimpulkan bahwa pemblokiran berhasil. Hanya 4 sumber yang mampu melewati dan menyelesaikan sesi HTTP dan TCP sepenuhnya (seperti pada contoh di atas). 460 lainnya dapat dikirim GET, tapi sesi segera diakhiri oleh RST. perhatikan 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"
Variasinya bisa berbeda: lebih sedikit RST atau lebih transmisi ulang - juga bergantung pada apa yang dikirim filter ke node sumber. Bagaimanapun, ini adalah templat yang paling andal, yang jelas bahwa yang diminta adalah sumber daya terlarang. Ditambah lagi selalu ada jawaban yang muncul di sesi bersama TTL lebih besar dibandingkan paket sebelumnya dan selanjutnya.
Anda bahkan 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 lebih:
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"
...
Perbedaannya jelas terlihat TTL jika ada sesuatu yang keluar dari filter. Namun seringkali tidak ada hasil 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 lebih:
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 berulang, berulang, dan berulang, seperti terlihat pada grafik, lebih dari sekali, setiap hari.
Tentang IPv6
Kabar baiknya adalah hal itu ada. Saya dapat dengan andal mengatakan bahwa permintaan berkala ke sumber daya terlarang terjadi dari 5 alamat IPv6 berbeda, persis seperti perilaku Agen yang saya harapkan. Selain itu, salah satu alamat IPv6 tidak termasuk dalam pemfilteran dan saya melihat sesi penuh. Dari dua sesi lagi saya hanya melihat satu sesi yang belum selesai, salah satunya disela oleh RST dari filter, kedua kalinya. Jumlah total 7.
Karena alamatnya sedikit, saya pelajari semuanya secara detail dan ternyata hanya ada 3 penyedia di sana, mereka bisa diberi tepuk tangan meriah! Alamat lainnya adalah cloud hosting di Rusia (tidak memfilter), satu lagi adalah pusat penelitian di Jerman (ada filternya, di mana?). Tetapi mengapa mereka memeriksa ketersediaan sumber daya terlarang secara terjadwal adalah pertanyaan yang bagus. Dua sisanya mengajukan satu permintaan dan berlokasi di luar Rusia, dan salah satunya disaring (lagipula, dalam perjalanan?).
Pemblokiran dan Agen merupakan hambatan besar bagi IPv6, yang implementasinya tidak berjalan dengan sangat cepat. Sedih. Mereka yang memecahkan masalah ini bisa bangga pada diri mereka sendiri.
Sebagai kesimpulan
Saya tidak mengupayakan akurasi 100%, mohon maafkan saya untuk ini, saya harap seseorang ingin mengulangi pekerjaan ini dengan akurasi yang lebih besar. Penting bagi saya untuk memahami apakah pendekatan ini pada prinsipnya akan berhasil. Jawabannya iya. Angka-angka yang diperoleh, sebagai perkiraan pertama, menurut saya cukup dapat diandalkan.
Apa lagi yang bisa dilakukan dan yang membuat saya terlalu malas adalah menghitung permintaan DNS. Mereka tidak difilter, tetapi juga tidak memberikan banyak akurasi karena hanya berfungsi untuk domain, dan tidak untuk keseluruhan URL. Frekuensinya harus terlihat. Jika Anda menggabungkannya dengan apa yang terlihat langsung di kueri, ini akan memungkinkan Anda memisahkan hal-hal yang tidak perlu dan mendapatkan lebih banyak informasi. Bahkan dimungkinkan untuk menentukan pengembang DNS yang digunakan oleh penyedia dan banyak lagi.
Saya sama sekali tidak menyangka bahwa hoster juga akan menyertakan filternya sendiri untuk VPS saya. Mungkin ini adalah praktik yang umum. Pada akhirnya, RKN mengirimkan permintaan untuk menghapus sumber daya ke hoster. Namun hal ini tidak mengejutkan saya dan dalam beberapa hal bahkan menguntungkan saya. Filter ini bekerja dengan sangat efektif, memutus semua permintaan HTTP yang benar ke URL yang dilarang, namun tidak menerima permintaan HTTP yang benar yang sebelumnya melewati filter penyedia, meskipun hanya dalam bentuk akhiran: FIN-ACK и RST - minus untuk minus dan ternyata hampir menjadi plus. Omong-omong, IPv6 tidak difilter oleh hoster. Tentu saja hal ini mempengaruhi kualitas materi yang dikumpulkan, namun tetap memungkinkan untuk melihat frekuensinya. Ternyata ini menjadi poin penting dalam memilih situs untuk menempatkan sumber daya, jangan lupa perhatikan masalah pengorganisasian pekerjaan dengan daftar situs terlarang dan permintaan dari RKN.
Pada awalnya saya membandingkan AS "Inspektur" dengan . Perbandingan ini cukup beralasan dan jaringan Agen yang luas dapat bermanfaat. Misalnya saja menentukan kualitas ketersediaan sumber daya dari berbagai penyedia di berbagai wilayah negara. Anda dapat menghitung penundaan, Anda dapat membuat grafik, Anda dapat menganalisis semuanya dan melihat perubahan yang terjadi baik secara lokal maupun global. Ini bukan cara yang paling langsung, tapi para astronom menggunakan “lilin standar”, mengapa tidak menggunakan Agen? Mengetahui (menemukan) perilaku standar mereka, Anda dapat mengetahui perubahan yang terjadi di sekitar mereka dan bagaimana hal ini mempengaruhi kualitas layanan yang diberikan. Dan pada saat yang sama, Anda tidak perlu menempatkan probe secara mandiri di jaringan, Roskomnadzor sudah menginstalnya.
Hal lain yang ingin saya sampaikan adalah bahwa setiap alat bisa menjadi senjata. SEBAGAI "Inspektur" adalah jaringan tertutup, tetapi Agen menyerahkan semua orang dengan mengirimkan permintaan untuk semua sumber daya dari daftar terlarang. Memiliki sumber daya seperti itu tidak menimbulkan masalah sama sekali. Secara total, penyedia melalui Agen, tanpa disadari, memberi tahu lebih banyak tentang jaringan mereka daripada manfaatnya: jenis DPI dan DNS, lokasi Agen (node pusat dan jaringan layanan?), penanda jaringan mengenai penundaan dan kehilangan - dan ini adalah hanya yang paling jelas. Sama seperti seseorang yang dapat memantau tindakan Agen untuk meningkatkan ketersediaan sumber dayanya, seseorang juga dapat melakukan ini untuk tujuan lain dan tidak ada hambatan untuk hal ini. Hasilnya adalah instrumen bermata dua dan sangat beragam, siapa pun dapat melihatnya.
Sumber: www.habr.com