Stateful Mitigation: Pentingnya, dan Bagaimana Kami Menyediakannya

Apa itu Stateful Mitigation

Herza Cloud telah bekerjasama dengan Path.net telah menerapkan jaringan global yang tangguh menggunakan stateful mitigation. Pelajari apa itu, dan bagaimana teknisi kami memanfaatkannya untuk unggul dalam perlindungan DDoS untuk Anda.

Apa itu Stateful Mitigation?

Ketika kita berbicara tentang “status”, ini mengacu pada informasi yang dipertahankan tentang urutan paket tertentu. Ini biasanya dilakukan dengan melacak pengidentifikasi, termasuk namun tidak terbatas pada, alamat IP dan port sumber dan tujuan. Ketika sebuah paket tiba, pencarian dapat dilakukan di tabel koneksi untuk mengidentifikasi apakah paket tersebut milik koneksi yang ada atau tidak. Status sudah ada dalam banyak kasus penggunaan yang berbeda. Transmission Control Protocol (TCP) adalah protokol layer transport berorientasi koneksi yang membutuhkan jabat tangan tiga arah sebelum dua perangkat akhir dapat berkomunikasi. Ketika paket SYN (“sinkronisasi”) diterima, yang merupakan langkah pertama pembentukan koneksi, sumber daya harus dialokasikan untuk “mengingat” klien (status). Dalam kasus kami, kami ingin membahas bagaimana ini cocok dengan mitigasi DDoS.

Aoa itu Stateful Mitigation
Source: ResearchGate

Mengapa itu penting?

Biasanya, serangan DDoS dapat dikurangi dengan memblokir lalu lintas dengan atribut berbeda dari lalu lintas yang sah. Ini mungkin termasuk nilai tidak valid yang tidak sesuai dengan protokol. Misalnya, header TCP dapat membawa flag, tetapi hanya beberapa kombinasi yang masuk akal dan dengan demikian diizinkan untuk digunakan oleh aplikasi. Bit SYN digunakan selama pembentukan koneksi, sedangkan FIN digunakan untuk mengakhiri koneksi. Mengingat informasi ini, tidak masuk akal jika keduanya digunakan secara bersamaan. Paket SYN-FIN dapat diblokir secara efektif tanpa risiko menjatuhkan serangan apa pun. Ini menimbulkan pertanyaan: Jadi mengapa mitigasi stateful penting?

Sayangnya, hal ini tidak selalu terjadi. Untuk serangan yang lebih canggih, lalu lintas DDoS tidak dapat difilter begitu saja dengan memeriksa karakteristik paket. Dalam hal ini, kita tidak dapat memutuskan apakah suatu paket harus dijatuhkan atau tidak tanpa mengetahui bagaimana paket tersebut berhubungan dengan lalu lintas yang dikirim sebelumnya. Di sinilah peran negara. Menggunakan mitigasi stateful, kita dapat memblokir paket-paket ini yang berasal dari serangan DDoS yang tidak dapat dibedakan dari lalu lintas yang sah.

Vektor yang paling umum

Anda mungkin bertanya-tanya apa serangan canggih yang menuntut mitigasi stateful ini. Di bawah ini, saya membahas beberapa strategi yang mungkin digunakan penyerang untuk mengatasi penerapan mitigasi DDoS yang tidak stateful atau tidak mengimplementasikan state dengan cukup baik.

SYN-ACK Floods

Paket SYN-ACK adalah langkah kedua dalam jabat tangan tiga arah TCP. Dalam model klien-server di mana klien adalah yang memulai koneksi, server akan membalas klien dengan SYN-ACK (“pengakuan sinkronisasi”). Banjir SYN-ACK adalah saat penyerang mencoba menjenuhkan sumber daya host dengan mengirimkan paket-paket ini dengan kecepatan tinggi, dengan maksud untuk membanjiri sistem atau jaringan. Saat paket SYN-ACK tiba di server, ia harus mencoba mencari tahu mengapa ia menerima lalu lintas di luar negara bagian ini. Dengan sejumlah besar paket ini tiba dengan cepat, sistem akan terlalu sibuk mencoba menangani lalu lintas jahat sehingga tidak dapat menangani lalu lintas yang sah. Bahkan untuk penyebaran kecil firewall stateful, hal ini menantang untuk dikurangi. Modul stateful harus melakukan pencarian untuk memeriksa apakah paket yang datang milik koneksi yang ada. Bergantung pada kekuatan pemrosesannya dan solusi yang digunakan, ini mungkin jauh lebih baik, tetapi tetap tidak ideal.

Ada dua cara berbeda bagi penyerang untuk melakukan banjir SYN-ACK. Yang pertama melibatkan penggunaan botnet, dan memiliki semua perangkat yang terinfeksi (sering disebut sebagai “bot”, “budak”, atau “zombie”) mengirim paket TCP SYN-ACK palsu ke target. Dengan sejumlah besar bot yang tersedia untuk penyerang, dia dapat dengan cepat membebani target dengan lebih banyak lalu lintas daripada yang dapat ditanganinya.

SYN-ACK Floods
Source: SpringerLink

Metode lain, yang menjadi lebih menonjol selama setahun terakhir, disebut sebagai refleksi TCP. Dalam serangan ini, penyerang mengirimkan paket TCP SYN palsu ke server yang sah. Paket palsu ini memiliki alamat IP sumber yang dipalsukan dengan milik korban. Setelah paket SYN palsu tiba di server, tidak ada cara untuk mengetahui bahwa alamat IP sumber yang disimpan di header IP sebenarnya bukan milik pengirim. Server membalas ke host dengan paket SYN-ACK. Dalam hal ini, tuan rumah adalah korbannya, dan menerima lalu lintas yang tidak diinginkan dari perangkat yang sepenuhnya sah. Ini disebut refleksi karena penyerang telah menggunakan host lain untuk memantulkan permintaannya, dan dari sana memantulkannya ke korban. Ketika ini terjadi puluhan atau ratusan ribu kali per detik, target dapat dengan mudah dibanjiri dengan lalu lintas serangan yang terlalu banyak sehingga tidak dapat menerima lalu lintas yang sah, sehingga menyebabkan Distributed Reflected Denial of Service (DRDoS). Perangkat yang paling umum digunakan sebagai reflektor (host memantulkan lalu lintas ke korban) biasanya adalah server web, tetapi bisa juga berupa server SMTP atau layanan TCP lainnya.

ACK Floods

Sama seperti banjir SYN-ACK, paket TCP out-of-state ini digunakan untuk membingungkan host dan menghabiskan sumber daya dengan mengirimkan paket yang bukan milik koneksi yang ada. Kami tidak akan membahas terlalu banyak detail tentang banjir ACK karena cara kerjanya sangat mirip dengan banjir SYN-ACK, kecuali hanya ada satu cara yang masuk akal untuk meluncurkan serangan ini. Seperti kebanyakan serangan lainnya, botnet digunakan untuk mengirim paket TCP ACK buatan dari sejumlah besar perangkat IoT yang terinfeksi.

UDP Floods

Kami telah membahas cara jabat tangan tiga arah TCP dapat disalahgunakan untuk merusak jaringan lain di Internet. Bagaimana dengan protokol lain?

Dengan sebagian besar serangan berbasis UDP, mereka cukup mudah untuk dimitigasi. Untuk amplifikasi UDP, seseorang dapat memilih untuk menilai-batas vektor amplifikasi umum, seperti Memcache. Dengan banjir umum yang dikirim dari botnet, lalu lintas DDoS biasanya dapat dihentikan dengan mengidentifikasi atribut umum yang membedakannya dari lalu lintas biasa. Seperti yang telah kami katakan, ini tidak selalu terjadi, dan dengan protokol tanpa koneksi yang sering dimanfaatkan untuk melancarkan serangan, tidak terkecuali UDP.

Mari kita lihat beberapa lalu lintas yang berasal dari klien di server game.

Sekarang mari kita periksa serangan DDoS yang dikirim ke jenis server game yang sama.

Wahhh, yang mana?! Dengan memeriksa dua sampel lalu lintas yang berbeda ini, kami tidak memiliki cara untuk mengetahui mana klien yang sah, dan mana yang merupakan serangan DDoS! Dengan serangan yang cukup terfokus, penyerang dapat menyesuaikannya agar terlihat sangat mirip dengan lalu lintas reguler untuk layanan tersebut. Ini membutuhkan mitigasi stateful lanjutan untuk membuat keputusan pada paket berdasarkan lalu lintas sebelumnya.

Bagaimana Herza Cloud menangani stateful mitigation

Banyak penyedia mitigasi DDoS gagal memitigasi serangan canggih semacam itu; Deteksi DDoS berbasis tanda tangan tidak dapat mengenali banjir tertentu, dan lalu lintas klien yang sah seringkali dapat dihentikan dalam proses mitigasi serangan semacam itu. Server game sangat rentan untuk menyelesaikan bencana bahkan dari serangan kecil, dan terutama jika layanan mitigasi menyebabkan hilangnya paket untuk klien. Path telah menerapkan firewall yang sepenuhnya stateful untuk memblokir jenis serangan yang paling canggih sekalipun, termasuk namun tidak terbatas pada, banjir SYN, SYN-ACK, dan ACK. Ketika serangan DDoS akan segera terjadi, jaringan global 2,8 Tbps kami bekerja untuk menyaring semua bentuk serangan, baik negara diperlukan atau tidak untuk memitigasinya. Baru-baru ini, kami telah memperkenalkan filter aplikasi, yang memfilter lalu lintas di tepi yang tidak membatasi layanan yang ingin dilindungi pengguna. Anda dapat membaca lebih lanjut tentang filter aplikasi Path di sini. Semua filter ini bersifat stateful, artinya kita tidak hanya dapat mencegah lalu lintas yang tidak menarik bagi aplikasi, tetapi juga lalu lintas yang tidak masuk akal untuk diterima aplikasi mengingat keadaan saat ini dipertahankan tentang host tertentu.

Sebagian besar produk yang digunakan untuk melindungi jaringan kami dari serangan DDoS diimplementasikan menggunakan eBPF dan XDP untuk kecepatan pemrosesan paket bare-metal, dan hanya perangkat keras tingkat perusahaan tingkat atas yang digunakan untuk mencapai kinerja paling mutakhir.

Perlindungan DDoS menggunakan eBPF/XDP

Perlindungan DDoS menggunakan eBPF/XDP

“Bekerja lebih cerdas, bukan lebih keras” adalah motif yang didukung oleh para Engineer di Herza Cloud, itulah sebabnya kami terus mengembangkan teknik mitigasi DDoS (Distributed Denial-of-Service) dengan cara yang belum pernah terjadi sebelumnya menggunakan kekuatan eBPF dan XDP. Penambahan terbaru kami, yang dikenal sebagai filter, memungkinkan pelanggan menerima perlindungan tanpa hambatan dari banyak serangan yang berbeda, baik yang dikenal maupun tidak dikenal, dengan mengklik tombol.

Cara kerja eBPF dan XDP

Jika Anda tidak familiar dengan apa itu eBPF atau XDP, kami memberikan pengenalan singkat tentang teknologi yang cukup baru ini di postingan blog kami berjudul Apa itu eBPF, XDP and Network Security. Pada dasarnya, ini memungkinkan seseorang untuk memfilter paket secara terprogram dengan kecepatan sangat tinggi. Perusahaan besar seperti Cloudflare dan Facebook sudah memanfaatkan fleksibilitasnya untuk memeras kinerja sebanyak mungkin dari sistem mereka.

Mengatasi solusi mitigasi DDoS saat ini

Cara paling menonjol untuk bertahan melawan serangan DDoS melibatkan penerapan beberapa aturan untuk memblokir serangan yang umum dan dikenal. Solusi ini sering mendasarkan stacking mereka pada pemfilteran berurutan, di mana rangkaian aturan diterapkan. Setiap kali sebuah paket datang, paket tersebut harus melintasi setiap aturan satu per satu hingga menemukan kecocokan. Pendekatan ini secara linier akan meningkatkan seberapa mahal untuk memfilter paket, dan membatasi skalabilitas seiring berkembangnya aturan. iptables, program ruang pengguna untuk memfilter paket di kernel Linux, adalah salah satu penyebab terbesar, namun tidak jelas berapa banyak perusahaan yang masih menggunakan perangkat lunak ini untuk mendorong mitigasi DDoS mereka.

iptables performance (source: RedHat Developers)

Kekhawatiran lain adalah di mana penyaringan paket dilakukan. Banyak layanan menggunakan “pusat scrubbing”, yang melibatkan pengubahan rute lalu lintas jauh untuk mengurangi serangan, dan dengan demikian menurunkan kinerja. Dalam skenario tertentu, overhead dari pengalihan yang mahal ini dapat berdampak pada jaringan hampir sama buruknya dengan serangan itu.

Lebih mendasar lagi, masalahnya terletak pada pola pikir. Dengan Internet yang terus tumbuh dan berkembang, penyerang tidak terlalu jauh di belakang. Serangan DDoS baru meningkat setiap hari, dan terlepas dari upaya terbaik, tidak mungkin untuk melacak setiap serangan. Ini menimbulkan pertanyaan tentang bagaimana penyedia mitigasi DDoS tradisional akan menangani serangan yang belum mereka temui.

Ketika Aplikasi Filter Lebih Berfungsi

Menggunakan firewall rules, seringkali sulit untuk mengungkapkan dengan tepat apa yang diinginkan pengguna. Biasanya, tingkat kontrol paling terperinci yang dapat Anda terima mencakup kemampuan memfilter pada lapisan transport, yang hanya mencakup UDP dan TCP. Meskipun ini bagus untuk memblokir serangan yang tidak terkoordinasi dengan baik dengan memblokir atau membatasi lalu lintas di porta, ini tidak cukup.

Misalnya, Anda memiliki server OpenVPN yang berjalan di port UDP 1194. Jika lalu lintas UDP di port lain tidak diperlukan, mungkin terlihat seperti ini:

PROTOCOLSOURCE IPSOURCE PORTDESTINATION PORTACTION
UDP1194Accept
UDPDrop

Jika serangan DDoS berbasis UDP menargetkan port selain 1194, solusi ini akan berfungsi dengan baik. Namun, apa yang akan dilakukan ACL (Access Control List) ini ketika penyerang menargetkan port UDP 1194? Itu akan mengizinkannya! Ini belum tentu kesalahan firewall Anda karena melakukan sesuatu selain yang diperintahkan; itu memberikan persis apa yang diminta. Masalahnya adalah bahwa pengguna tidak memiliki tingkat kontrol yang cukup baik untuk mewakili apa yang diperlukan dengan benar. Yang ingin kami sampaikan adalah bahwa semua lalu lintas OpenVPN harus diizinkan di port ini, bukan semua lalu lintas UDP. Dengan berapa banyak serangan DDoS yang menyalahgunakan properti UDP tanpa koneksi, mengizinkan semuanya tidak dapat diterima. Jadi bagaimana kita membuat keputusan pada paket yang setepat mungkin? Jawabannya: filter aplikasi pada Layer 7.

Di Herza Cloud, kami telah menghilangkan rasa frustrasi itu. Menggunakan eBPF/XDP, filter aplikasi diterapkan di tepi jaringan untuk jumlah protokol yang terus bertambah. Segera setelah filter diterapkan, semua lalu lintas yang menuju ke layanan tertentu melewati filter aplikasi ini, di mana perangkat lunak memastikan bahwa setiap paket terbatas pada konvensi yang digunakan aplikasi. Ini dilakukan melalui penelitian yang cermat untuk menemukan apa yang membedakan paket milik aplikasi yang ingin kami lindungi dari paket lain. Semua filter aplikasi kami menggunakan Stateful Mitigation untuk memblokir jenis Floods / DDoS yang paling canggih sekalipun. Bersihkan lalu lintas melewati dengan mulus, sementara paket berbahaya atau tidak sah ditolak; semua tanpa intervensi apa pun yang diperlukan, atau kemungkinan bahwa lalu lintas klien dapat dihentikan dalam proses. Saat ini kami telah membuat filter aplikasi untuk sejumlah layanan berbeda, termasuk OpenVPN, TeamSpeak 3, TLS, dan banyak lagi!

Hasil

Sejak rilis awal filter aplikasi kami, klien mendapat manfaat dari tingkat ketahanan yang tak tertandingi terhadap DDoS, apakah itu serangan volumetrik, banjir aplikasi bandwidth rendah, atau apa pun di antaranya! Filter aplikasi Path bukan hanya cara yang lebih logis untuk menyediakan pemfilteran paket, tetapi juga sangat efisien, sangat terukur, dan lebih tahan masa depan. Path berencana untuk melanjutkan perluasan teknologi ini, karena infrastruktur kami menjadi lebih modular.

One of our application filters are shown above withstanding an attack