🧖🏽 ♍️ 📻 Laporan Keamanan dan Ketersediaan Jaringan Tahunan Qrator Labs 👻 👩🏿‍🤝‍👩🏾 👩🏿‍🔧

Kami memiliki tradisi di Qrator Labs - pada awalnya, dan Februari jelas bukan akhir, setiap tahun menerbitkan laporan pada tahun sebelumnya.

Seperti entitas abadi, dikelilingi oleh banyak cerita terkait. Misalnya, sudah menjadi pertanda "baik" ketika pada awal Januari serangan DDoS lain tiba di halaman perusahaan kami, yang kami tidak punya waktu untuk melihat dalam laporan. 2020 adalah setengah pengecualian - kami berhasil menggambarkan vektor serangan (amplifikasi TCP SYN-ACK), tetapi bagi kami, di qrator.net, bahwa tamu datang (dan bukan satu) hanya pada tanggal 18 Januari, tetapi langsung dengan tamu: 116 Gbps pada 26 Mpps.

Patut diakui bahwa menceritakan kembali peristiwa tahun lalu adalah genre yang spesifik. Oleh karena itu, kami memutuskan dalam proses refleksi untuk fokus pada apa yang akan terjadi - terutama dengan tim dan produk kami - tahun ini, jadi jangan heran membaca tentang rencana pengembangan kami.

Kami akan mulai dengan dua topik paling menarik bagi kami tahun lalu: amplifikasi SYN-ACK dan "optimisasi" BGP.

Amplifikasi TCP SYN-ACK dan protokol lainnya

Pertumbuhan pasar IoT, antara lain, berarti bahwa penyerang dapat mengeksploitasi perangkat rentan jika mereka mau, menciptakan bandwidth serangan yang signifikan - seperti yang terjadi pada pertengahan tahun ketika protokol WSDD digunakan untuk menyebabkan kerusakan yang terlihat. Protokol ARMS Apple, yang digunakan untuk mendapatkan koefisien amplifikasi urutan 35,5, juga terlihat dalam serangan pada jaringan penyaringan Qrator Labs.

Selama 2019, publik juga belajar tentang amplifier baru (PCAP), dan juga secara pribadi melihat vektor serangan yang sudah lama diketahui melibatkan TCP - SYN-ACK. Perbedaan utama antara metode ini dan amplifikasi UDP pada umumnya adalah bahwa vektor SYN-ACK tidak menggunakan respons yang lebih besar dari permintaan - sebagai gantinya, ia hanya mencoba menjawab permintaan TCP beberapa kali, sehingga menciptakan koefisien amplifikasi yang terlihat. Karena cloud publik di Internet merespons paket dengan spoofing alamat sumber, serangan yang melibatkan vektor amplifikasi SYN-ACK telah menjadi salah satu ancaman jaringan paling serius. Apogee terjadi ketika penyedia hosting awan utama Servers.com beralih ke Qrator Labsdengan permintaan bantuan dalam menetralkan serangan DDoS, termasuk vektor SYN-ACK.

Yang cukup menarik adalah kenyataan bahwa metode reaksi yang paling sering digunakan di masa lalu dalam bentuk dumping semua lalu lintas UDP, yang secara virtual menetralkan bagian terbesar dari serangan menggunakan amplifikasi, sama sekali tidak membantu menetralkan vektor SYN-ACK. Perusahaan-perusahaan Internet yang lebih kecil memiliki kesulitan besar dalam menetralkan ancaman-ancaman seperti itu, karena itu memerlukan penggunaan langkah-langkah komprehensif untuk memerangi serangan DDoS.

Meskipun amplifikasi TCP SYN-ACK bukanlah hal baru, sejauh ini tetap vektor serangan yang relatif tidak dikenal. Penyerang mengirim paket SYN ke semua layanan TCP publik di Internet, mengganti alamat sumber dengan alamat korban, dan masing-masing layanan ini merespons beberapa kali dalam upaya untuk membangun koneksi - biasanya dari 3 hingga 5. Untuk waktu yang sangat lama, vektor serangan ini dianggap tidak berarti, dan hanya pada bulan Juli 2019 kita melihat bahwa penyerang mampu menghasilkan bandwidth serangan yang cukup untuk mengguncang infrastruktur jaringan yang sangat besar dan didistribusikan. Ini khususnya tidak biasa, mengingat fakta yang telah disebutkan tentang kurangnya "amplifikasi tanggapan" seperti itu dan penggunaan hanya kemungkinan penyambungan kembali dalam protokol jika terjadi kegagalan. Untuk mereka,siapa pun yang tertarik pada protokol lain dengan "kemampuan" yang serupa, Anda dapat menunjuk ke protokol QUIC, yang sudah menyediakan opsi kepada server untuk menanggapi permintaan klien dengan respons yang diperbesar (walaupun konsep protokol juga "merekomendasikan" untuk tidak mengirim respons lebih dari tiga kali ukuran permintaan).

Amplifikasi telah berhenti menjadi ancaman dengan koefisien sekitar 100x - jelas bahwa 3-5x sudah cukup hari ini. Solusi untuk masalah ini hampir tidak mungkin tanpa menghilangkan fenomena lalu lintas "palsu" sebagai kategori - penyerang seharusnya tidak dapat mensimulasikan pengenal jaringan seseorang dan membanjirinya dengan lalu lintas dari sumber konten yang sah. BCP38 (serangkaian praktik terbaik dan yang diterima secara umum untuk mengatur jaringan dan memecahkan situasi yang bermasalah) tidak bekerja sama sekali, dan pembuat protokol transportasi baru - seperti QUIC - menilai dengan buruk bahaya yang ditimbulkan bahkan oleh kemampuan amplifikasi yang sangat kecil. Mereka ada di sisi lain.

Jaringan memerlukan cara yang andal untuk membuang atau setidaknya membatasi lalu lintas palsu - dan alat ini harus memiliki informasi yang cukup tentang keabsahan sumber permintaan. Jaringan cloud yang dimiliki oleh perusahaan seperti Amazon, Akamai, Google dan Azure saat ini adalah target yang hampir ideal untuk amplifikasi TCP - mereka memiliki banyak perangkat keras yang kuat yang dapat memenuhi hampir semua tujuan penyerang.

Sulit untuk menghilangkan konsekuensi dari serangan seperti itu di Internet modern. Seperti yang telah disebutkan, antarmuka modern dan antarmuka aplikasi dan perpustakaan yang digunakan untuk membuatnya terintegrasi satu sama lain. Menggunakan kemampuan solusi perangkat lunak sumber terbuka yang terletak di dalam cloud besar di tumpukan pengembangan mereka sendiri dapat menyebabkan masalah serius sebagai akibat dari serangan yang menggunakan amplifikasi SYN-ACK dari cloud yang sama. Repositori yang rusak dan file konfigurasi yang tidak diperbarui akibat pemblokiran (karena alamat palsu dari sumber permintaan, alamat Anda) dari sisi penyedia layanan cloud adalah situasi di mana tidak ada yang mau. Selama 2019, kami menghadapi situasi ini beberapa kali, menangani keluhan dari perusahaan yang terkena dampak,menemukan ketergantungan kritis yang tak terbayangkan untuk pertama kalinya selama keberadaan dan perkembangannya.

Pengembangan lebih lanjut dari protokol BGP diperlukan untuk menggunakannya dalam memerangi spoofing dalam tumpukan protokol TCP / IP. Tabel perutean pada dasarnya berbeda dari tabel subnet, dan kita perlu mengajarkan jaringan untuk dengan cepat mengisolasi dan membuang paket tidak sah - dengan kata lain, memberikan otentikasi pada tingkat infrastruktur jaringan. Perhatian harus diberikan bukan pada "alamat tujuan", tetapi ke "alamat sumber" agar sesuai dengan informasi yang terkandung dalam tabel routing.

BGP - "pengoptimal"

Insiden BGP selalu berlangsung. Menurut skala saat ini besarnya insiden jaringan, kebocoran rute dan intersepsi subnet yang diiklankan yang telah menyebar cukup jauh membawa bahaya utama dalam tingkat penyebaran dan waktu yang diperlukan untuk menghilangkan konsekuensinya. Mungkin ini disebabkan oleh fakta bahwa pengembangan komponen jaringan itu sendiri jauh lebih lambat daripada dunia pengembangan perangkat keras dan perangkat lunak baru. Untuk waktu yang lama, ini benar - saatnya meninggalkan warisan ini. Penting untuk menginvestasikan waktu dan uang dalam perangkat lunak dan perangkat keras jaringan, serta pada orang yang mengkonfigurasi filter BGP.

Insiden 2019 yang melibatkan pengoptimal BGP menunjukkan bahwa statistik BGP yang diandalkan semua orang memiliki banyak masalah. Faktanya adalah bahwa dalam pengumuman BGP yang diterima dari rekan, Anda dapat mengubah hampir semua konten sebelum diumumkan lagi - protokolnya sangat fleksibel. Ini persis seperti yang digunakan pengoptimal: awalan jaringan yang lebih besar atau lebih kecil, bersama dengan filter siaga dan opsi preferensi lokal. Jika seseorang memisahkan awalan menjadi dua yang lebih kecil, mereka biasanya akan memenangkan kompetisi untuk hak mentransmisikan lalu lintas. Pengoptimal mengambil rute yang benar dan mengumumkan bagian yang lebih kecil - cukup mudah. Dan itu bekerja dengan memecah bagian besar dari Internet.

Pengoptimal BGP ada karena sejumlah besar perusahaan ingin mengontrol arus lalu lintas keluar secara otomatis, tanpa memikirkan lalu lintas seperti itu. Menerima rute yang seharusnya tidak ada adalah kesalahan besar, karena tidak ada rute seperti itu dari titik asal mereka.

Banyak teks ditulis untuk 2019, termasuk oleh perusahaan kami., tentang risiko “optimasi BGP.” Dalam kasus Verizon, tentu saja, membuat kebijakan pemfilteran baru untuk setiap konsumen baru layanan tidak menyenangkan. Dan juga diketahui bahwa Verizon tidak memiliki filter, karena butuh ratusan rute bermasalah dari klien AS396531 sendiri, yang merupakan "rintisan" - sistem otonom dengan satu koneksi. Apalagi raksasa telekomunikasi itu juga tidak memiliki batas subnet untuk koneksi ini. Bahkan tidak ada pemeriksaan dasar untuk keberadaan operator Tier-1 lainnya dalam perjalanan dari konsumen (jenis pemeriksaan ini dimulai secara default dan tidak memerlukan dukungan atau perubahan).

Di media, insiden ini, termasuk Verizon dan Cloudflare, dibahas dengan cukup bersemangat. Selain tindakan yang mungkin dilakukan oleh Verizon, banyak yang telah mencatat manfaat RPKI dan catatan maksimum yang ketat dalam ROA. Tapi bagaimana dengan maxLength? Diketahui bahwa dengan pemeriksaan ketat dari panjang rekaman maksimum, semua pengumuman dengan indikasi subnet yang lebih kecil menjadi salah saat memeriksa ROA. Diketahui juga bahwa ada kebijakan untuk mengatur ulang jalur yang tidak valid. Ada juga konsep dalam IETF, yang menunjukkan bahwa maxLength harus sama dengan panjang awalan jaringan.

Cloudflare mengikuti praktik terbaik. Namun, ada masalah kecil. Verizon tidak mendukung kebijakan reset untuk rute yang tidak valid. Mungkin dia tidak memiliki verifikasi RPKI sama sekali. Akibatnya, semua rute dengan subnet yang lebih kecil menyebar lebih jauh, meskipun mereka salah dari sudut pandang validasi Rute Asal dan menarik semua lalu lintas ke diri mereka sendiri. Pada saat yang sama, meskipun statusnya Tidak Valid, Cloudflare tidak dapat mengumumkan rute yang sama, karena pemasoknya akan menjatuhkannya sebagai salah.

Kebocoran rute dapat dihilangkan dengan hanya memanipulasi atribut AS_PATH dalam bentuk: ASx AS396531 ASx (di mana ASx adalah jumlah sistem sumber otonom) selama pembuatan pengumuman - ini akan membantu untuk menghindari kebocoran dengan menggunakan mekanisme deteksi loop sementara masalah diselesaikan dengan cara lain. Meskipun setiap kali dengan manipulasi seperti itu perlu diingat kebijakan tersebut.

Paling sering dalam kehidupan nyata, metode standar digunakan - keluhan. Apa yang menghasilkan waktu tunggu ekstra. Komunikasi dapat menyakitkan, dan kami tidak dapat menyalahkan Cloudflare untuk ini - mereka melakukan semua yang mereka bisa, mengingat keadaan.

Apa hasilnya? Terkadang kita ditanya seberapa sulit menggunakan BGP untuk mengatur sesuatu yang buruk. Misalkan Anda adalah penjahat pemula. Hal ini diperlukan untuk terhubung ke operator telekomunikasi besar, yang buruk dengan pengaturan filter. Kemudian pilih target apa saja dan ambil awalan jaringannya dengan mengumumkan bagian-bagian yang lebih kecil. Juga, jangan lupa untuk membuang semua paket transit. Selamat! Anda baru saja membuat lubang hitam di Internet untuk semua lalu lintas transit layanan ini melalui penyedia Anda. Korban akan kehilangan uang sungguhan karena penolakan layanan dan, sangat mungkin, akan menderita kerugian reputasi yang signifikan. Diperlukan setidaknya satu jam untuk menemukan penyebab insiden seperti itu, dan satu jam diperlukan untuk ituuntuk mengembalikan semuanya ke normal - asalkan situasi seperti itu tidak disengaja dan ada niat baik untuk resolusi di antara semua peserta.

Pada bulan Maret 2019, ada kasus lain , yang pada suatu waktu kami tidak mengaitkan dengan optimasi BGP. Namun, itu juga patut mendapat perhatian.

Bayangkan Anda adalah penyedia transit yang mengumumkan subnet dari pelanggan Anda sendiri. Jika klien tersebut memiliki beberapa penyedia, dan bukan Anda satu, Anda hanya akan menerima sebagian dari traffic mereka. Tetapi semakin banyak lalu lintas, semakin besar keuntungannya. Jadi, Anda memutuskan untuk mengiklankan subnet yang lebih kecil dari jaringan ini dengan atribut AS_PATH yang sama untuk mendapatkan semua lalu lintas untuk jaringan tersebut. Dengan sisa uang, tentu saja.

Apakah ROA akan membantu dalam kasus ini? Mungkin ya, tetapi hanya jika Anda memutuskan untuk tidak menggunakan maxLength sama sekali dan Anda tidak memiliki catatan ROA dengan awalan berpotongan. Untuk beberapa operator telekomunikasi, opsi ini tidak layak.

Jika kita berbicara tentang mekanisme keamanan BGP lainnya, maka ASPA tidak akan membantu dalam jenis intersepsi ini, karena AS_PATH termasuk dalam jalur yang benar. BGPSec saat ini tidak efisien karena kurangnya dukungan dan kemampuan yang tersisa untuk melakukan serangan downgrade.

Masih ada motif untuk meningkatkan keuntungan karena diterimanya semua lalu lintas sistem otonom dengan beberapa penyedia dan tidak adanya sarana perlindungan.

Jumlah total loop statis dalam jaringan.

Apa yang masih bisa dilakukan? Langkah yang jelas dan paling radikal adalah meninjau kebijakan perutean saat ini. Ini akan membantu Anda membagi ruang alamat menjadi bagian sekecil mungkin (tanpa persimpangan) yang ingin Anda umumkan. Tandatangani ROA hanya untuk rute ini menggunakan opsi maxLength. Validasi ROV saat ini dapat menyelamatkan Anda dari serangan seperti itu. Tetapi sekali lagi, beberapa tidak mampu menggunakan hanya subnet terkecil.

Menggunakan Radar.Qrator, Anda dapat melacak peristiwa semacam itu. Untuk melakukan ini, kami memerlukan informasi dasar tentang awalan Anda. Anda dapat membuat sesi BGP dengan seorang kolektor dan memberikan informasi tentang visibilitas Anda ke Internet. Kami juga menghargai secara positif mereka yang siap mengirimi kami tabel perutean penuh (tampilan penuh) - ini membantu melacak tingkat insiden, tetapi untuk keuntungan Anda sendiri dan mulai menggunakan alat ini, daftar rute hanya cukup untuk awalan Anda. Jika Anda sudah memiliki sesi dengan Radar.Qrator, harap periksa bahwa Anda mengirim rute. Untuk deteksi otomatis dan pemberitahuan serangan pada ruang alamat Anda, informasi ini diperlukan.

Kami ulangi - jika situasi serupa terdeteksi, Anda dapat mencoba menangkalnya. Pendekatan pertama adalah pengumuman sendiri jalur dengan awalan subnet yang lebih kecil. Pada serangan berikutnya pada awalan ini - ulangi. Pendekatan kedua adalah menghukum penyerang dengan menolak akses sistem otonom ke jalur Anda. Seperti yang dijelaskan sebelumnya, ini dicapai dengan menambahkan nomor sistem otonom penyerang ke AS_PATH dari jalur lama Anda, menyebabkan perlindungan terhadap loop bekerja.

Bank

Pada tahun 2019, kami melakukan penelitian di Rusia , yang menunjukkan bahwa lembaga keuangan mencatat peningkatan pentingnya keamanan informasi dan mulai memberikan investasi semacam itu prioritas yang lebih tinggi.

Bank-bank responden mengidentifikasi kerusakan keuangan dan reputasi sebagai konsekuensi paling serius dari pelanggaran keamanan informasi.

Sebagian besar lembaga keuangan yang disurvei menganggap solusi hibrid sebagai cara paling efektif untuk melawan serangan penolakan layanan yang didistribusikan.

Dinamika dua tahun terakhir jelas menunjukkan bahwa bidang keamanan informasi tumbuh sangat pesat: selama 2 tahun terakhir, sebagian besar bank telah meningkatkan investasi dalam keamanan informasi. Keamanan dunia maya telah menjadi nyata di tingkat manajemen perusahaan. Para pemimpin bisnis mulai lebih memperhatikan proses penerapan kebijakan keamanan, dan posisi Direktur Keamanan Informasi telah memperoleh peran baru. Manajer SI secara bertahap berubah menjadi penasihat utama bagi manajer puncak organisasi keuangan, memperkenalkan taktik bisnis dan strategi keamanan sesuai dengan kebutuhan perusahaan.

Perdagangan elektronik

Penelitian serupa dilakukan di bidang e-commerce, di mana kami menemukan bahwa serangan DDoS tetap menjadi ancaman signifikan bagi ritel Rusia, terutama untuk mengembangkan saluran layanan digital. Jumlah serangan di segmen ini terus bertambah.

Di beberapa segmen pasar, meskipun stabilisasi dan konsolidasi secara keseluruhan, kepercayaan pada kebersihan pesaing masih pada tingkat yang rendah. Pada saat yang sama, toko online besar sebagian besar mempercayai konsumen mereka dan tidak menganggap motif pribadi pelanggan sebagai penyebab serius serangan cyber.

Sebagai aturan, bisnis e-commerce menengah dan besar belajar tentang kesiapan mereka untuk serangan DDoS hanya dalam praktek, melewati "tes pertempuran". Perlunya penilaian risiko awal persiapan proyek masih jauh dari yang diakui oleh semua, dan bahkan lebih sedikit perusahaan yang benar-benar melakukan penilaian seperti itu. Alasan utama peretasan, responden menganggap tidak berfungsinya toko, serta pencurian basis pengguna.

Secara umum, tingkat kematangan ritel dalam pendekatan untuk memastikan keamanan siber meningkat. Jadi, semua responden menggunakan beberapa cara perlindungan DDoS dan WAF.
Dalam studi lebih lanjut, direncanakan untuk menyertakan sampel representatif dari bisnis online kecil di antara responden dan untuk mempelajari secara rinci segmen pasar ini, risiko dan tingkat keamanan saat ini.

DNS-over-HTTPS vs DNS-over-TLS

Salah satu topik terpanas tahun 2019 adalah perdebatan mengenai teknologi mana yang dimiliki di masa depan - DoH atau DoT. Kontradiksi awal disebabkan oleh perbedaan signifikan dalam badan legislatif yang berbeda (GDPR UE versus undang-undang federal dan negara bagian di AS) dan persaingan di pasar browser utama: Google Chrome dan Mozilla Firefox, serta Apple Safari. Kami tidak siap untuk mengatakan apakah pengenalan salah satu dari teknologi ini akan mengurangi jumlah amplifier di Internet. Namun, dengan opsi DoT ini tampaknya lebih mungkin dari sudut pandang arsitektur karena penciptaan koneksi aman antara resolvers DNS. Mengenai perkiraan lainnya, kami akan menunggu keputusan yang akan diambil pasar.

Industri yang paling banyak diserang pada 2019.

Kerentanan pengakuan TCP

Pada Juni 2019, rincian pertama tentang keberadaan kerentanan serius muncul di beberapa implementasi dari tumpukan protokol TCP / IP, seperti yang dilaporkan oleh Netflix . Agaknya, masalah ini awalnya ditemukan di sistem operasi FreeBSD, setelah itu perusahaan kami menerima konfirmasi keberadaan kerentanan yang sama dan lainnya di Linux.

CVE-2019-11477 (SACK Panic) yang paling berbahaya, yang dapat memungkinkan penyerang untuk memanggil kernel panik menggunakan urutan paket yang dibentuk secara khusus. Tiga kerentanan lain dapat menyebabkan konsumsi sumber daya yang berlebihan, yang dapat mengakibatkan penolakan layanan.

Menonaktifkan fungsionalitas SACK dapat menyebabkan peningkatan keterlambatan, namun, ini akan melindungi server dari kemungkinan serangan penolakan layanan - penurunan sementara dalam kinerja TCP / IP, menurut Qrator Labs, adalah cara yang masuk akal untuk menetralkan kerentanan serius. Tambalan yang mencakup kerentanan ini telah lama tersedia dan direkomendasikan untuk dipasang.

Masa depan perutean BGP

Pada akhir 2019, Radar.Qrator adalah platform pengumpulan dan analisis perutean global BGP terbesar dengan lebih dari 650 sesi yang telah mapan.

Tim Radar.Qrator bekerja untuk meningkatkan kegunaan dan keandalan layanan, membuat perbaikan pada model hubungan BGP, yang merupakan dasar dari layanan berbayar untuk memantau sistem otonom secara real time.

Pada 2019, berbagai upaya dilakukan untuk mempercepat proses pemrosesan data dan implementasi SLA, yang menjamin kualitas aliran data analitik. Hari ini Radar adalah platform analitik terbesar dan pengumpul BGP di dunia, dengan lebih dari 600 sesi yang telah ditetapkan, dan kami berharap dapat menggunakan data secara penuh untuk memberi tahu konsumen tentang bagian berbayar dari layanan tentang semua peristiwa yang terjadi dalam perutean BGP tanpa penundaan.

Radar.Qrator tumbuh lebih cepat dari yang diharapkan - baik dalam hal jumlah pengunjung situs web dan jumlah pelanggan pada saat yang sama. Pada tahun 2020, berkat umpan balik dari pelanggan, beberapa perbaikan signifikan akan disajikan sekaligus, salah satunya adalah penyimpanan insiden baru untuk setiap sistem otonom.

Salah satu masalah yang kami temui adalah waktu respons yang diharapkan di antarmuka web Radar, dapat diakses oleh setiap pengunjung ke situs. Dengan peningkatan jumlah data, menjadi perlu untuk memperbarui model penyimpanan data dan arsitektur permintaan pengguna untuk itu. Radar harus dapat dengan cepat mengirimkan semua data untuk periode yang diminta kepada pengunjung mana pun.

Skema yang diusulkan dari mekanisme ASPA.

Kami juga berharap bahwa selama tahun ini ASPAakan menjadi RFC - standar jaringan yang disetujui. Kebutuhan akan kombinasi yang lebih luas dari IRR / RPKI, dan lebih ringan dari solusi BGPSec, jelas bagi semua orang di industri ini. Pada tahun 2019, menjadi jelas bagaimana konfigurasi BGP yang salah dapat menyebabkan kebocoran rute dengan konsekuensi yang mengerikan dalam bentuk tidak tersedianya sejumlah besar layanan yang melibatkan penyedia layanan Internet terbesar. Yang mengejutkan, insiden ini sekali lagi membuktikan bahwa tidak ada peluru perak yang dapat mengatasi semua skenario yang mungkin terjadi dalam perkembangan mereka.

Penyedia Internet terbesar di dunia perlu mendukung gerakan awal. Melibatkan komunitas besar yang dapat membantu menemukan sumber pengalihan rute adalah langkah selanjutnya. Secara sederhana, ASPA adalah entitas baru yang menggabungkan kemampuan ROA dan RPKI saat ini - ASPA menerapkan prinsip sederhana: "Kenali pemasok Anda." Pemilik AS hanya perlu mengetahui upstreamnya untuk menerapkan cara yang cukup andal untuk melindungi terhadap insiden perutean BGP.

Seperti dalam kasus ROA, ASPA memungkinkan Anda untuk memfilter rute untuk koneksi apa pun: dengan penyedia yang lebih tinggi, tetangga, atau, tentu saja, konsumen. Kombinasi ROA dan ASPA dapat memecahkan bagian terbesar dari tugas keamanan jaringan tanpa perlu perubahan mendasar pada protokol itu sendiri, menyaring serangan yang disengaja dan kesalahan yang terkait dengan faktor manusia. Namun, itu juga akan perlu untuk menunggu dukungan dari produsen perangkat lunak dan perangkat keras - meskipun ada kepercayaan bahwa dukungan open source tidak akan lama datang.

Salah satu keunggulan utama ASPA adalah ide yang sangat sederhana. Pada tahun 2020, direncanakan untuk menyelesaikan pekerjaan pada konsep protokol, dan jika berhasil, IETF dan co-penulis rancangan akan mencapai konsensus tentang konsolidasi status protokol.

Pengembangan Saat Ini dan Masa Depan Jaringan Filtrasi Qrator

Logika penyaringan

Selama dua tahun sebelumnya, kami telah menginvestasikan banyak waktu dan upaya dalam meningkatkan logika penyaringan, yang merupakan dasar dari layanan mitigasi serangan yang kami sediakan. Sampai saat ini, mereka sudah bekerja di seluruh jaringan, menunjukkan peningkatan yang signifikan dalam efisiensi operasional dan penurunan beban pada memori dan prosesor pusat pada titik-titik kehadiran. Filter baru juga memungkinkan Anda untuk menganalisis permintaan secara serempak dan menyediakan berbagai tugas JavaScript untuk memeriksa keabsahan pengunjung, meningkatkan kualitas deteksi serangan.

Alasan utama untuk memperbarui logika pemfilteran adalah kebutuhan untuk mendeteksi seluruh kelas bot dari permintaan pertama. Qrator Labs menggunakan kombinasi cek dengan dan tanpa penghafalan negara, dan hanya setelah konfirmasi keabsahan pengguna mengirimkan permintaan lebih lanjut ke server yang dilindungi. Oleh karena itu, perlu bahwa filter bekerja sangat cepat - serangan DDoS modern lulus dengan intensitas puluhan juta paket per detik, dan beberapa di antaranya dapat satu kali, permintaan unik.

Pada tahun 2020, sebagai bagian dari proses ini, perubahan signifikan juga akan dilakukan pada proses lalu lintas “onboarding”, yaitu, awal pekerjaan dengan layanan yang dilindungi baru. Lalu lintas setiap layanan unik dengan caranya sendiri dan kami berusaha untuk memastikan bahwa, tidak peduli apa pun, klien baru dengan cepat menerima netralisasi lengkap dari semua jenis serangan, bahkan jika model tidak terlatih dengan baik. Sebagai hasilnya, kami akan memastikan penyaringan yang lebih halus saat terhubung di bawah serangan, dan awal penyaringan akan disertai dengan lebih sedikit positif palsu. Semua ini penting ketika layanan dan orang-orang di belakangnya berada di tengah perjuangan untuk bertahan hidup di bawah serangan jaringan besar-besaran.

Distribusi serangan DDoS untuk 2019 oleh band yang digunakan.

HTTP / 2

Masalah dengan implementasi protokol HTTP / 2 (penolakan kerentanan layanan) sebagian besar diselesaikan selama 2019, yang memungkinkan kami untuk mengaktifkan dukungan untuk protokol ini di dalam jaringan penyaringan Qrator.

Sekarang pekerjaan sedang berlangsung secara aktif untuk memberikan perlindungan HTTP / 2 untuk setiap klien, menyelesaikan periode pengujian yang panjang dan mendalam. Seiring dengan dukungan untuk HTTP / 2, TLS 1.3 memperkenalkan kemungkinan menggunakan eSNI dengan penerbitan otomatis sertifikat keamanan Let's Encrypt.

Saat ini, HTTP / 2 tersedia berdasarkan permintaan sebagai opsi tambahan.

Kontainer dan Orkestrasi

Tren kontainerisasi saat ini tidak kompatibel dengan pendekatan keamanan kami. Ini berarti bahwa bekerja dengan Kubernetes harus mengatasi berbagai tantangan. Keamanan dan aksesibilitas adalah salah satu prioritas tertinggi, yang tidak memungkinkan kami untuk bergantung pada praktik umum di antara mereka yang bekerja dengan Kubernetes, pertama-tama memberikan proses pengaturan penuh kontrol proses orkestrasi pada sistem operasi dengan semua fitur - ini akan membuat kami secara eksklusif atas belas kasihan para pengembang dan pengaya Kubernetes. Sejauh ini, Kubernetes tidak memiliki semua kemampuan yang diperlukan di luar kotak, dan beberapa bahkan disembunyikan oleh negara “gunakan apa adanya, tidak ada jaminan” dan tidak dapat diselidiki secara terperinci. Tetapi semua ini tidak berpaling dari pekerjaan lebih lanjut tentang implementasi Kubernetes dalam pengelolaan jaringan penyaringan,secara bertahap menyesuaikannya dengan persyaratan kami dan menjadikannya bagian yang cukup penting dari infrastruktur internal.

Masa depan pengembangan dan pengembangan jaringan yang terdistribusi dan toleran terhadap kesalahan membutuhkan pengenalan alat yang tepat (CI / CD dan pengujian otomatis adalah bagian darinya) dan kemampuan untuk menggunakannya untuk menciptakan dan mengelola sistem yang stabil dan andal. Karena jumlah data hanya meningkat, upaya pemantauan harus tumbuh setelahnya. Cara paling alami untuk membangun pemantauan adalah menyediakan metode komunikasi yang aman dan mudah diamati untuk aplikasi. Kami percaya bahwa Kubernetes telah membuktikan keserbagunaan dan penerapannya, dan spesialisasi lebih lanjut untuk kebutuhan infrastruktur yang berperang melawan serangan DDoS adalah kenyataan bekerja dengan solusi open source apa pun.

Ubah durasi rata-rata serangan DDoS dari 2018 ke 2019.

Yandex.Cloud dan Ingress 2.0

Pada tahun 2019, bersama-sama dengan Yandex.Cloud, kami menyajikan versi terbaru dari layanan kami untuk menyaring lalu lintas masuk - Ingress, secara signifikan memperluas kemampuan penyaringan dan konfigurasinya, memberikan pengguna akhir dengan antarmuka manajemen yang jelas. Versi baru layanan sudah berfungsi di jaringan penyaringan Qrator Labs, serta di jaringan Yandex.Cloud.

Tim Yandex.Cloud telah berjalan jauh bersama kami, menggabungkan dua infrastruktur menggunakan node fisik Qrator Labs yang terletak di dalam infrastruktur mitra yang bekerja pada lalu lintasnya.

Akhirnya, setelah periode pengujian mendalam, versi baru Ingress siap digunakan. Dengan bantuan Yandex, kami dapat membuat salah satu solusi terbaik untuk menyaring lalu lintas masuk, yang dibuat khusus untuk kebutuhan layanan yang menghasilkan banyak konten.

Kami juga menganggap ini sangat sukses karena versi baru dari layanan ini intuitif untuk pengguna akhir dan memungkinkan Anda untuk lebih fleksibel mengkonfigurasi parameter penyaringan.

Sertifikat TLS 1.3 dan ECDSA

Pada awal 2019, Qrator Labs menulis tentang mendukung TLS versi 1.3 sambil menonaktifkan SSL v.3. Karena ketersediaan layanan netralisasi DDoS tanpa mengungkapkan kunci enkripsi, perbaikan tambahan dibuat untuk skema penyaringan ini, meningkatkan kecepatan dan keandalan terjemahan syslog. Mari kita ingat hasil pengukuran kinerja .

Jenis tanda tangan	Jabat tangan per detik
ECDSA (prime256v1 / nistp256)	3358.6
RSA 2048	972.5

Seperti yang Anda lihat, pada inti yang sama dari Intel® Xeon® Silver 4114 CPU @ 2.20GHz (dirilis pada kuartal ketiga 17), perbedaan total antara kinerja ECDSA dan RSA yang diterima secara umum dengan panjang kunci 2048 bit adalah 3,5 kali.

Mari kita lihat hasil menjalankan perintah openssl -speed untuk ECDSA dan RSA pada prosesor yang sama.

Jenis tanda tangan	tanda	memeriksa	tanda / dtk	verifikasi / dtk
RSA 2048 bit	717 μs	20,2 μs	1393.9	49458.2
256 bit ECDSA (nistp256)	25,7 μs	81,8 μs	38971.6	12227.1

Di sini kita dapat menemukan konfirmasi dari tesis yang ditulis sebelumnya tentang bagaimana operasi komputasi dari tanda tangan dan verifikasi berbeda antara ECC dan RSA. Saat ini, dipersenjatai dengan TLS 1.3, kriptografi berdasarkan kurva eliptik memberikan peningkatan yang signifikan dalam kinerja server dengan sebuah tingkat yang lebih tinggi perlindungan dibandingkan dengan RSA. Ini adalah alasan utama mengapa kami di Qrator Labs merekomendasikan dan sangat mendorong pelanggan yang siap untuk menggunakan sertifikat ECDSA juga. Pada CPU modern, peningkatan kinerja yang mendukung ECDSA adalah 5x.

Perbaikan yang lebih kecil

Salah satu inovasi penting yang kecil dan tidak mencolok, namun demikian selama 2019 adalah pengenalan proses pengecekan status hulu secara aktif. Jika karena alasan tertentu sesuatu terjadi selama salah satu koneksi superior klien kami selama serangan, layanan penyaringan akan menjadi yang pertama mengetahuinya, mengambil koneksi dari operasi sampai masalah teratasi. Dalam hal ini ia membantu tidak hanya memonitor kesalahan dan kondisi lalu lintas, tetapi juga mengatur antarmuka pemeriksaan aksesibilitas khusus, yang dilakukan bersama dengan konsumen layanan.

Pada akhir 2019, pembaruan besar antarmuka pengguna layanan penyaringan dibuat. Dan meskipun kemungkinan menggunakan versi lama akun pribadi Anda disediakan, fitur-fitur baru sudah dikembangkan di bagian yang diperbarui, yang menyediakan fungsionalitas yang lebih luas, misalnya, pengelolaan sertifikat TLS.

Sementara versi lama akun pribadi menggunakan rendering sisi server, versi yang diperbarui dalam tradisi terbaik web modern adalah aplikasi JavaScript yang berjalan pada klien yang berkomunikasi dengan server melalui REST API. Pendekatan ini akan memungkinkan Anda untuk dengan cepat memberikan fungsi-fungsi baru kepada pengguna, sambil memberikan peluang yang lebih dalam untuk pengaturan individual dari setiap akun pribadi konsumen individu. Salah satunya adalah bagian Analytics, di mana dimungkinkan untuk menyesuaikan metrik individual, yang jumlahnya terus meningkat.

Perbandingan dua kelompok klasifikasi utama untuk serangan DDoS untuk 2019.

IPv6

Qrator Labs secara aktif bersiap untuk mulai menggunakan IPv6 sebagai bagian dari layanan penyaringan lalu lintas. Untuk perusahaan cybersecurity apa pun, transisi semacam itu tidak boleh bersifat elementer. Karena sifat serangan DDoS, serangan penetral jaringan menggunakan IPv6 memerlukan perubahan radikal dalam pendekatan, karena tidak lagi mungkin untuk berurusan dengan segala bentuk "daftar", berurusan dengan batas teoritis dari ^2.128 alamat IP. Dan ini hanya tentang TCP, tidak mempertimbangkan UDP.

Bagi kami, 2020 akan menjadi tahun IPv6. Dengan menipisnya ruang alamat IPv4 gratis, tidak ada cara lain untuk mengembangkan jaringan yang memenuhi persyaratan di masa depan. Kami berharap bahwa kami akan dapat secara efektif menjawab semua tantangan yang kami hadapi dalam rangka menetralkan serangan IPv6. Pertama-tama, ini berarti bahwa kami akan dapat mengumumkan subnet IPv6 dari layanan penyaringan konsumen menggunakan jaringan kami, sambil menawarkan layanan keamanan siber kelas satu.

Antibot

Pada tahun 2019, industri mengamati pertempuran sengit antara sidik jari (identifikasi pengunjung) dan upaya untuk membatasinya. Keinginan pemilik dan pengembang layanan Internet untuk membatasi atau memisahkan permintaan dari pengguna yang sah dari permintaan otomatis dari bot dapat dipahami. Di sisi lain, tidak ada yang aneh dalam keinginan pengembang browser untuk mengamankan pengguna perangkat lunak. Selama bertahun-tahun, Qrator Labs mengingatkan pasar bahwa jika beberapa informasi tersedia untuk umum dan tidak diperlukan otorisasi untuk menerimanya, maka kemungkinan melindunginya dari penguraian otomatis cenderung nol. Pada saat yang sama, kami mengingatkan pemilik bisnis digital bahwa mereka memiliki hak untuk memilih apa yang harus dilakukan dengan permintaan yang datang ke server. Pendekatan proaktif dalam situasi tertentu membantu menilai dan mengidentifikasi ancaman.

Ketika bot menghasilkan peningkatan pangsa lalu lintas, kami dapat mengharapkan momen di masa depan ketika layanan besar akan menciptakan antarmuka khusus untuk bot yang baik, memberi mereka informasi yang sah. Sisanya akan diblokir. Bahkan sekarang, pada awal tahun 2020, dapat dikatakan bahwa bukan pengguna yang 100% sah tidak akan dapat langsung mengakses sumber daya apa pun di Internet - banyak yang tidak akan mengizinkan ini jika, katakanlah, Anda hanya mengubah agen pengguna peramban menjadi agen yang sewenang-wenang.

Di dalam Qrator Labs, layanan antibot telah berkembang secara aktif selama beberapa tahun, dan pada tahun 2020 kami berharap untuk menawarkannya kepada pelanggan pertama kami sebagai bagian dari layanan beta. Layanan ini akan beroperasi dalam mode semi dan otomatis, sehingga memungkinkan untuk mengidentifikasi dan menetapkan aturan keamanan terhadap sejumlah permintaan otomatis atau keluar dari bot.

Peralatan

Setelah menguji prosesor AMD yang baru, karyawan yang bertanggung jawab di perusahaan sangat tertarik sehingga pada kuartal pertama 2020 Qrator Labs akan menugaskan titik kehadiran baru di Osaka, Jepang, yang sepenuhnya dibangun di atas prosesor AMD. PCI Express Generasi ke-4, tersedia dengan AMD CPU, berjanji untuk menggandakan bandwidth antara CPU dan antarmuka jaringan. Selama tahun ini, penggunaan ligamen ini dalam skenario yang paling menegangkan akan diuji dan dievaluasi. Saluran antara antarmuka jaringan dan prosesor secara bertahap menjadi leher sempit dengan peningkatan jumlah data yang dikirim dalam jaringan. Kombinasi core tambahan, cache yang lebih besar dan versi PCI Express yang baru menjanjikan hasil yang baik.

Alasan lain untuk menggunakan CPU AMD adalah kebutuhan untuk mendiversifikasi arsitektur jaringan, meskipun ini adalah titik pertama kehadiran untuk Qrator Labs, dibangun sepenuhnya pada prosesor baru.

Kami sangat menantikan dimulainya pekerjaan peralatan baru, yang peluncurannya akan dilaporkan secara terpisah pada awal tahun 2020. Kami berharap bahwa kombinasi prosesor AMD dan kartu jaringan berkinerja tinggi menggunakan PCI Express 4 akan memenuhi persyaratan kami. Pasar Asia adalah salah satu yang paling cepat berkembang, dan saya ingin menghargai prospek lebih lanjut untuk menetralisir serangan DDoS dengan peralatan baru di sana.

Pada saat yang sama, kedatangan prosesor Intel generasi baru juga diharapkan - Ice Lake. Penggunaan lebih lanjut mereka dalam infrastruktur kami akan sangat tergantung pada hasil pengujian dan perbandingan mereka.

Selain prosesor, seluruh industri mengharapkan rilis kartu jaringan seri Intel 800. Pada tahun 2020, kami akan mencoba untuk menemukan mereka aplikasi di dalam infrastruktur jaringan filtrasi.

Mengenai sakelar - Qrator Labs terus bekerja dengan Mellanox, yang telah berulang kali membuktikan dirinya sebagai pemasok dan mitra yang andal.

Mengatakan ini tidak mudah, tetapi sementara Broadcom mendominasi pasar peralatan jaringan, kami berharap bergabung dengan NVidia akan memberi Mellanox peluang untuk kompetisi yang layak.

Perbaikan di masa depan untuk jaringan penyaringan

Selama tahun 2020, perusahaan kami berharap untuk secara signifikan memperdalam kemitraannya dengan pemasok berbagai layanan dan layanan, seperti Firewall Aplikasi Web dan Jaringan Pengiriman Konten dalam jaringan penyaringan. Kami selalu berusaha untuk mengintegrasikan berbagai pemasok ke dalam infrastruktur untuk memberikan kombinasi terbaik dari layanan yang mungkin bagi konsumen. Pada akhir tahun 2020, direncanakan untuk mengumumkan ketersediaan sejumlah penyedia layanan baru bersama dengan Qrator.

2019 juga mengungkapkan sejumlah pertanyaan tentang perlindungan teknologi WebSockets. Prevalensi dan popularitasnya hanya tumbuh, dan kompleksitas perlindungan yang tepat tidak berkurang. Selama tahun 2020, kami berharap dapat bekerja dengan beberapa pelanggan kami menggunakan teknologi WebSockets untuk menemukan cara terbaik untuk melindunginya, bahkan jika kami mengirim data yang sewenang-wenang (tidak diketahui).

Apa yang kita lakukan bukanlah pengetahuan dan bukan wahyu. Perusahaan datang ke pasar ini lebih lambat dari banyak pesaing. Tim berusaha keras untuk melakukan sesuatu yang unik dan bekerja. Bagian dari peluang ini juga terletak pada minat tulus karyawan perusahaan dalam penelitian akademis dan ilmiah dalam bidang-bidang utama upaya, yang memungkinkan kita dipersiapkan untuk peristiwa "mendadak".

Karena Anda telah membaca hingga akhir, inilah .pdf untuk distribusi . Jangan lupa tentang keamanan jaringan sendiri - dan jangan berikan kepada orang lain.

Laporan Keamanan dan Ketersediaan Jaringan Tahunan Qrator Labs