UDP Banjir dari Google atau bagaimana tidak menghilangkan semua Youtube

Suatu malam musim semi yang indah, ketika saya tidak ingin pulang, dan keinginan yang tak kenal lelah untuk hidup dan belajar jatuh dan terbakar seperti besi panas, muncul ide untuk menyodok fitur nyasar yang menggoda di firewall yang disebut " kebijakan IP DOS ".
Setelah belaian awal dan pengenalan manual, saya mengaturnya dalam mode Pass-and-Log untuk melihat knalpot secara umum dan kegunaan yang meragukan dari pengaturan ini.
Setelah beberapa hari (sehingga statistik dikumpulkan, tentu saja, dan bukan karena saya lupa), saya melihat log dan, menari di tempat, bertepuk tangan - tidak ada entri sama sekali. Tampaknya lebih mudah - aktifkan kebijakan dalam mode pemblokiran semua banjir, pemindaian, yang menetapkan sesi setengah terbuka dengan larangan selama satu jam dan tidur dengan tenang dengan pengetahuan bahwa perbatasan dikunci. Tetapi tahun ke-34 kehidupan mengatasi maximalisme muda dan di suatu tempat di belakang otak terdengar suara tipis: "Ayo angkat kelopak mata kita dan lihat siapa alamat firewall kita yang dicintai yang dikenal sebagai pembuat banjir yang berbahaya? Nah, dalam urutan delirium. "

Kami mulai menganalisis data yang diperoleh dari daftar anomali. Saya mengarahkan alamat melalui skrip Powershell sederhana dan mata saya tertuju pada huruf google yang akrab.



Saya menggosok mata, berkedip sekitar lima menit, untuk memastikan bahwa saya tidak memikirkannya - itu benar-benar ada dalam daftar orang-orang yang dianggap firewall sebagai pembuat banjir yang berbahaya, jenis serangannya adalah udp float , alamat milik korporasi yang baik.






Aku menggaruk kepalaku, secara bersamaan mengatur pengambilan paket pada antarmuka eksternal untuk analisis lebih lanjut. Pikiran pelangi melintas di benak saya: "Bagaimana mungkin ada sesuatu yang terinfeksi dalam lingkup Google? Dan apakah saya menemukan ini? Baiklah, baik, baik - penghargaan, penghargaan dan karpet merah, dan kasino Anda dengan blackjack dan, yah, Anda mengerti ... "

Saya mem-parsing file Wireshark yang dihasilkan.
Ya, memang, dari alamat dari Google scoop, paket UDP dari port 443 ke port acak pada perangkat saya ditampilkan.
Tapi tunggu sebentar ... Di sini protokol berubah dari UDP ke GQUIC .
Semen Semenych ...



Segera saya ingat laporan dari High Toad oleh Alexander Tobol " UDP terhadap TCP atau masa depan tumpukan jaringan" ( tautan ).
Di satu sisi, ada sedikit kekecewaan - baik untuk Anda, pria, kemenangan, atau kehormatan. Di sisi lain, masalahnya jelas, masih harus memahami di mana dan berapa banyak yang harus digali.
Beberapa menit komunikasi dengan Korporat Kebaikan - dan semuanya jatuh pada tempatnya. Dalam upaya untuk meningkatkan kecepatan pengiriman konten, Google mengumumkan kembali pada tahun 2012 protokol QUIC , yang memungkinkan Anda untuk menghapus sebagian besar kekurangan TCP (ya, ya, dalam artikel ini, Rrraz dan Two merujuk pada pendekatan yang sepenuhnya revolusioner, tetapi, jujur ​​saja, saya ingin fotochki dengan kucing dimuat dengan cepat, dan bukan ini revolusi kesadaran dan kemajuan Anda). Seperti yang ditunjukkan oleh penelitian lebih lanjut, banyak organisasi sekarang beralih ke opsi pengiriman konten yang serupa.
Masalahnya adalah milik saya dan, saya pikir, tidak hanya dalam kasus saya ternyata pada akhirnya ada banyak paket dan firewall menganggapnya sebagai banjir.
Ada beberapa solusi:
1. Tambahkan ke daftar pengecualian untuk Kebijakan DoS pada lingkup firewall dari alamat Google . Hanya memikirkan kisaran alamat yang mungkin, mata itu mulai berkedut dengan gugup - gagasan itu ditunda sebagai khayalan.
2. Meningkatkan ambang respons untuk kebijakan banjir udp juga tidak aman, tetapi tiba-tiba seseorang yang benar-benar jahat akan lolos.
3. Melarang panggilan dari jaringan internal via UDP ke port 443 out.
Setelah membaca tambahan tentang implementasi dan integrasi QUIC di Google Chrome , opsi terakhir diadopsi sebagai indikasi tindakan. Faktanya adalah, dicintai oleh semua orang di mana saja dan tanpa belas kasihan (saya tidak mengerti mengapa, lebih baik untuk mendapatkan Firefox -rambut merah yang ceroboh karena memakan RAM yang gigabytes), Google Chrome pada awalnya mencoba membuat koneksi menggunakan QUIC yang dideritanya, tetapi jika keajaiban tidak terjadi , lalu dia kembali ke metode yang sudah terbukti seperti TLS , meskipun dia malu akan hal ini.

Kami membuat entri untuk layanan QUIC di firewall:



Kami mengonfigurasi aturan baru dan menempatkannya di tempat yang lebih tinggi dalam rantai.



Setelah dimasukkannya aturan dalam daftar anomali, diam dan mulus, dengan pengecualian pelanggar yang benar-benar jahat.



Terima kasih atas perhatiannya.

Sumber daya yang digunakan:
1. Laporan Alexander Tobol
2. Deskripsi protokol QUIC dari Infopulse
3. Wikipedia
4. KB dari Fortinet