Bukan rahasia lagi bahwa sistem otomatis "Inspektur" memonitor kontrol kunci pada daftar informasi yang dilarang di Rusia. Cara kerjanya ditulis dengan baik di sini di
artikel Habr ini , gambarnya dari sana:
Modul "Agen Auditor" penyedia dipasang langsung di penyedia:
Modul "Agen Auditor" adalah elemen struktural dari sistem otomatis "Auditor" (AS "Auditor"). Sistem ini dirancang untuk memantau kepatuhan operator telekomunikasi dengan pembatasan akses dalam kerangka kerja ketentuan yang ditetapkan oleh Pasal 15.1-15.4 Undang-Undang Federal 27 Juli 2006 No. 149- “Tentang Informasi, Teknologi Informasi, dan Perlindungan Informasi”.
Tujuan utama menciptakan Auditor AS adalah untuk memantau kepatuhan operator telekomunikasi dengan persyaratan yang ditetapkan oleh Pasal 15.1-15.4 Undang-Undang Federal 27 Juli 2006 No. 149- “Tentang Informasi, Teknologi Informasi, dan Perlindungan Informasi” tentang identifikasi fakta akses ke informasi yang dilarang. dan mendapatkan materi pendukung (data) tentang pelanggaran untuk membatasi akses ke informasi yang dilarang.
Mengingat bahwa, jika tidak semua, maka banyak penyedia memasang perangkat ini di rumah, mereka seharusnya sudah mendapat jaringan besar probe suar seperti
RIPE Atlas dan bahkan lebih, tetapi dengan akses tertutup. Namun, mercusuar adalah mercusuar untuk mengirim sinyal ke segala arah, tetapi bagaimana jika kita menangkapnya dan melihat apa yang kita tangkap dan berapa banyak?
Sebelum menghitung, mari kita lihat mengapa ini mungkin terjadi.
Sedikit teori
Agen memeriksa ketersediaan sumber daya, termasuk melalui permintaan HTTP (S), seperti contoh 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"
Permintaan, selain muatan, juga terdiri dari fase pengaturan koneksi: pertukaran
SYN dan
SYN-ACK , dan fase penyelesaian koneksi:
FIN-ACK .
Registri informasi terlarang berisi beberapa jenis kunci. Jelas, jika sumber daya diblokir oleh alamat IP atau nama domain, maka kami tidak akan melihat permintaan apa pun. Ini adalah jenis kunci yang paling merusak yang menyebabkan tidak dapat diaksesnya semua sumber daya pada alamat IP yang sama atau semua informasi pada domain. Ada juga jenis pemblokiran URL. Dalam hal ini, sistem pemfilteran harus menguraikan header permintaan HTTP untuk menentukan dengan tepat apa yang akan diblokir. Dan sebelum itu, seperti yang dapat dilihat di atas, fase pengaturan koneksi harus terjadi, yang dapat Anda coba lacak, karena kemungkinan besar filter akan melewatinya.
Untuk melakukan ini, Anda harus memilih domain gratis yang cocok dengan jenis pemblokiran "dengan URL" dan HTTP, untuk memudahkan pekerjaan sistem penyaringan, lebih baik ditinggalkan dalam waktu lama, untuk meminimalkan masuknya lalu lintas yang asing kecuali dari Agen. Tugas ini sama sekali tidak sulit, ada banyak domain gratis di registri informasi yang dilarang untuk setiap selera. Oleh karena itu, domain diperoleh, diikat ke alamat IP pada VPS dengan
tcpdump berjalan, dan penghitungan dimulai.
Audit "Auditor"
Saya berharap melihat ledakan permintaan secara berkala, yang menurut saya akan mengindikasikan tindakan terkendali. Ini bukan untuk mengatakan bahwa saya tidak melihat ini sama sekali, tetapi jelas tidak ada gambaran yang jelas:
Tidak mengherankan, bahkan domain yang tidak perlu untuk IP yang tidak digunakan hanya akan menerima banyak informasi yang tidak diminta, seperti Internet modern. Tapi untungnya, saya hanya membutuhkan permintaan untuk URL tertentu, sehingga semua perayap dan brute kata sandi dengan cepat ditemukan. Selain itu, cukup sederhana untuk memahami di mana banjir terjadi dengan massa jenis permintaan yang sama. Kemudian saya mengkompilasi frekuensi kemunculan alamat IP dan berjalan di atas secara manual memisahkan mereka yang tergelincir pada langkah sebelumnya. Selain itu, saya memotong semua sumber yang mengirim satu paket, tidak banyak dari mereka. Dan ternyata ini:
Penyimpangan liris sedikit. Sedikit lebih dari sehari kemudian, penyedia hosting saya mengirim pesan yang agak ramping, mereka mengatakan bahwa di fasilitas Anda ada sumber daya dari daftar ILV yang dilarang sehingga diblokir. Awalnya saya pikir mereka memblokir akun saya, ternyata tidak. Kemudian saya berpikir bahwa mereka hanya memperingatkan saya tentang apa yang sudah saya ketahui. Tetapi ternyata hoster menyalakan filternya di depan domain saya dan sebagai hasilnya, saya mendapat penyaringan ganda: dari penyedia dan tuan rumah. Filter hanya melewatkan ujung permintaan:
FIN-ACK dan
RST memotong semua HTTP di URL terlarang. Seperti yang dapat Anda lihat dari grafik di atas, setelah hari pertama saya mulai menerima lebih sedikit data, tetapi saya masih menerimanya, yang cukup untuk tugas menghitung sumber kueri.
Langsung ke intinya. Menurut pendapat saya, dua semburan terlihat jelas setiap hari, yang pertama kurang setelah tengah malam di Moskow, yang kedua lebih dekat ke 6 di pagi hari dengan ekor hingga 12 hari. Puncaknya tidak terjadi tepat pada saat yang bersamaan. Pertama, saya ingin menyoroti alamat IP yang jatuh hanya pada periode ini dan masing-masing di semua periode, berdasarkan asumsi bahwa Agen memeriksa secara berkala. Tetapi setelah melihat dengan cermat, saya dengan cepat menemukan periode jatuh ke interval lain, dengan frekuensi yang berbeda, hingga satu permintaan setiap jam. Lalu saya memikirkan zona waktu dan apa yang mungkin ada di dalamnya, lalu saya berpikir bahwa secara umum sistem mungkin tidak disinkronkan secara global. Selain itu, yang pasti, NAT akan memainkan perannya, dan Agen yang sama dapat membuat permintaan dari IP publik yang berbeda.
Karena tujuan awal saya tidak tepat, saya menghitung semua alamat yang saya dapatkan dalam seminggu dan mendapatkan
2791 . Jumlah sesi TCP yang ditetapkan dari satu alamat rata-rata adalah 4, dengan median 2. Sesi teratas per alamat: 464, 231, 149, 83, 77. Maksimal 95% dari sampel adalah 8 sesi per alamat. Mediannya tidak terlalu tinggi, saya ingat bahwa jadwal menunjukkan frekuensi harian yang jelas, sehingga Anda dapat mengharapkan sesuatu sekitar 4 hingga 8 dalam 7 hari. Jika Anda membuang semua sesi rapat satu kali, maka kami hanya mendapatkan median sama dengan 5. Tapi saya tidak bisa mengecualikannya secara jelas. Sebaliknya, pemeriksaan mendadak menunjukkan bahwa hal itu terkait dengan permintaan sumber daya terlarang.
Alamat, dan di Internet, sistem otonom lebih penting - AS, yang
1510 keluar, rata-rata 2 alamat AS dengan median 1. Alamat teratas AS: 288, 77, 66, 39, 27. Maksimal 95% dari sampel adalah 4 alamat pada SEBAGAI. Di sini median diharapkan - satu Agen per penyedia. Kami juga mengharapkan top - ada pemain besar di dalamnya. Dalam jaringan besar, Agen mungkin harus ada di setiap wilayah keberadaan operator, dan jangan lupa tentang NAT. Jika Anda mengambil berdasarkan negara, maksimum akan menjadi: 1409 - RU, 42 - UA, 23 - CZ, 36 dari daerah lain, bukan RIPE NCC. Permintaan bukan dari Rusia menarik perhatian. Mungkin ini bisa dijelaskan oleh kesalahan geolokasi atau kesalahan pendaftar saat mengisi data. Atau fakta bahwa perusahaan Rusia mungkin memiliki akar non-Rusia, atau memiliki kantor perwakilan asing karena sangat sederhana sehingga wajar untuk berurusan dengan organisasi asing RIPE NCC. Beberapa bagian tidak diragukan lagi berlebihan, tetapi sulit untuk memisahkannya, karena sumber dayanya dikunci, dan dari hari kedua di bawah kunci ganda, dan sebagian besar sesi hanyalah pertukaran beberapa paket layanan. Mari kita sepakati fakta bahwa ini adalah sebagian kecil.
Angka-angka ini sudah bisa dibandingkan dengan jumlah penyedia di Rusia.
Menurut ILV, lisensi untuk "Layanan komunikasi untuk transmisi data, kecuali untuk suara" adalah 6387, tetapi ini adalah peringkat yang sangat diganggu dari atas, tidak semua lisensi ini khusus untuk penyedia Internet yang perlu menginstal Agen. Di zona RIPE NCC, jumlah AS yang serupa yang terdaftar di Rusia adalah 6230, di mana tidak semua penyedia.
UserSide membuat perhitungan yang lebih ketat dan menerima 3940 perusahaan pada 2017, dan ini lebih merupakan perkiraan dari atas. Bagaimanapun, kami memiliki jumlah AS yang diterangi dua setengah kali lebih sedikit. Tapi di sini perlu dipahami bahwa AS tidak sepenuhnya sama dengan penyedia. Beberapa penyedia tidak memiliki SA sendiri, beberapa memiliki lebih dari satu. Jika kita menganggap bahwa Agen masih berdiri di semua orang, maka seseorang menyaring lebih dari yang lain, sehingga permintaan mereka tidak dapat dibedakan dari sampah, jika memang ada. Tetapi untuk penilaian kasar itu cukup dapat ditoleransi, bahkan jika ada sesuatu yang hilang karena pengawasan saya.
Tentang DPI
Terlepas dari kenyataan bahwa penyedia hosting saya telah mengaktifkan filternya sejak hari kedua, menurut informasi untuk hari pertama, kami dapat menyimpulkan bahwa kunci berhasil. Hanya 4 sumber yang dapat menerobos dan telah menyelesaikan sesi HTTP dan TCP (seperti pada contoh di atas). 460 lainnya dapat mengirim
GET , tetapi sesi langsung berakhir pada
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"
Variasi ini dapat berbeda: lebih sedikit
RST atau lebih mentransmisikan ulang - ini juga tergantung pada apa yang dikirim filter ke node sumber. Bagaimanapun, ini adalah templat yang paling dapat diandalkan, dari mana jelas bahwa sumber terlarang diminta. Plus, selalu ada jawaban yang muncul dalam sesi dengan
TTL lebih besar dari pada paket sebelumnya dan selanjutnya.
Bahkan
GET tidak terlihat dari yang lain:
TTL 50, TCP, 14678 > 80, "[SYN] Seq=0" TTL 64, TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=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"
Perbedaan dalam
TTL pasti terlihat jika ada yang datang dari filter. Tetapi seringkali ia tidak bisa terbang 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"
Dan semua ini berulang dan berulang dan berulang, seperti dapat dilihat pada grafik, tepatnya lebih dari sekali, setiap hari.
Tentang IPv6
Berita baiknya adalah dia. Saya dapat dengan andal mengatakan bahwa dari 5 alamat IPv6 yang berbeda ada permintaan berkala terhadap sumber daya terlarang, persis perilaku Agen yang saya harapkan. Selain itu, salah satu alamat IPv6 tidak termasuk dalam penyaringan dan saya melihat sesi lengkap. Dengan dua lagi, saya hanya melihat satu sesi yang tidak lengkap, salah satunya diinterupsi oleh
RST dari filter, yang kedua kalinya. Sebanyak
7 .
Karena ada beberapa alamat, saya mempelajari semuanya secara terperinci dan ternyata hanya ada 3 penyedia di sana, Anda dapat memuji mereka berdiri! Alamat lain adalah hosting awan di Rusia (tidak memfilter), yang lain adalah pusat penelitian di Jerman (ada filter, di mana?). Tapi mengapa mereka memeriksa jadwal ketersediaan sumber daya yang dilarang adalah pertanyaan yang bagus. Dua sisanya membuat satu permintaan dan tidak berada di perbatasan Rusia, dengan salah satu dari mereka disaring (apakah masih dalam perjalanan?).
Kunci dan Agen adalah rem besar pada IPv6, implementasi yang karenanya tidak bergerak sangat cepat. Ini menyedihkan. Mereka yang telah menyelesaikan tugas ini sepenuhnya bangga dengan diri mereka sendiri.
Kesimpulannya
Saya tidak mengejar akurasi 100%, saya meminta Anda untuk memaafkan saya untuk ini, saya berharap seseorang ingin mengulangi pekerjaan ini dengan akurasi yang lebih besar. Penting bagi saya untuk memahami apakah pendekatan seperti itu akan berhasil secara prinsip. Jawabannya adalah. Angka-angka yang dihasilkan dalam perkiraan pertama, saya pikir, cukup dapat diandalkan.
Apa lagi yang bisa dilakukan dan apa yang terlalu malas saya lakukan adalah menghitung permintaan DNS. Mereka tidak difilter, tetapi juga tidak memberikan banyak akurasi karena hanya berfungsi untuk domain, dan tidak untuk seluruh URL. Frekuensi harus terlihat. Jika Anda menggabungkan dengan apa yang langsung terlihat dalam permintaan, ini akan memungkinkan Anda untuk memisahkan kelebihan dan mendapatkan informasi lebih lanjut. Bahkan mungkin untuk mengidentifikasi pengembang DNS yang digunakan oleh penyedia dan banyak lagi.
Saya benar-benar tidak berharap bahwa untuk VPS saya, hoster juga akan menyertakan filternya sendiri. Mungkin ini adalah praktik umum. Pada akhirnya, ILV mengirimkan permintaan untuk menghapus sumber daya ke hoster. Tetapi itu tidak mengejutkan saya dan bahkan bermain untuk beberapa keuntungan. Filter bekerja sangat efisien dengan memotong semua permintaan HTTP yang benar ke URL terlarang, tetapi bukan yang benar yang melewati filter penyedia sebelumnya, bahkan jika hanya dalam bentuk akhir:
FIN-ACK dan
RST - minus minus dan hampir mendapat nilai tambah. Omong-omong, hoster IPv6 tidak difilter. Tentu saja, ini mempengaruhi kualitas materi yang dikumpulkan, tetapi masih memungkinkan untuk melihat frekuensinya. Ini ternyata menjadi poin penting ketika memilih situs untuk menempatkan sumber daya, jangan lupa untuk tertarik dengan masalah pengorganisasian pekerjaan dengan daftar situs terlarang dan pertanyaan dari ILV.
Pada awalnya, saya membandingkan AC "Auditor" dengan
RIPE Atlas . Perbandingan ini dibenarkan dan jaringan besar Agen dapat bermanfaat. Misalnya, menentukan kualitas ketersediaan sumber daya dari berbagai penyedia di berbagai bagian 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, tetapi para astronom menggunakan "lilin standar", mengapa tidak menggunakan Agen? Mengetahui (menemukan) perilaku standar mereka, Anda dapat menentukan perubahan yang terjadi di sekitar mereka dan bagaimana hal ini memengaruhi kualitas layanan yang diberikan. Dan pada saat yang sama, Anda tidak perlu menginstal secara independen probe di jaringan, mereka sudah disediakan oleh Roskomnadzor.
Poin lain yang ingin saya sentuh adalah bahwa setiap alat dapat menjadi senjata. SEBAGAI "Inspektur" adalah jaringan tertutup, tetapi Agen menyerahkan semua orang dengan jeroan ayam itik dengan mengirimkan permintaan untuk semua sumber daya dari daftar terlarang. Untuk mendapatkan sumber daya semacam itu tidak sepenuhnya mewakili masalah. Secara keseluruhan, penyedia melalui Agen, yang secara sukarela mengatakan tentang jaringan mereka jauh lebih berharga daripada itu: jenis DPI dan DNS, lokasi Agen (simpul pusat dan jaringan layanan?), Penanda keterlambatan dan kerugian jaringan - dan ini hanya yang paling jelas. Sama seperti seseorang dapat memantau tindakan Agen untuk meningkatkan ketersediaan sumber daya mereka, seseorang dapat melakukan ini untuk tujuan lain dan tidak ada hambatan. Instrumen bermata dua dan sangat beragam ternyata, siapa pun dapat diyakinkan tentang hal ini.