Posted on

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

Posted on

Apa itu eBPF, XDP and Network Security?

Apa itu eBPF, XDP

Akhir-akhir ini sedang trending pertanyaan apa itu eBPF dan XDP. Di Herza Cloud, Salah satu inovasi terbaru untuk solusi Anti DDoS adalah pengembangan kami untuk Firewall Filter Layer 7 dengan eBPF dan XDP.

Kami tidak takut merusak barang dan bergerak cepat. Kami telah memupuk budaya teknik yang kuat yang mendorong inovasi dan kami yakin ini penting, karena memungkinkan anggota tim kami melakukan yang lebih baik waktu demi waktu.

eBPF dan XDP adalah teknologi terbaru yang perlu Anda tambahkan ke kosakata tren teknologi trending saat ini, bersama dengan Blockchain dan Cyberwarfare.

Dalam artikel ini, kami akan menyelami sedikit tentang kegunaan eBPF dan XDP, namun kami akan berfokus pada bagaimana kami menggabungkan teknologi menarik ini kedalam keamanan jaringan kami, terkhusus layanan keamanan Anti DDoS dan berbagi bagian dari perjalanan kami melakukannya.

Apa itu eBPF?

Apa yang dimulai dengan tujuan sederhana dari pemfilteran paket jaringan, eBPF dengan cepat berkembang menjadi salah satu alat paling kuat yang tersedia untuk Linux. Diadopsi oleh orang-orang seperti Netflix, Amazon, Google, Microsoft dll dan dijuluki “Kekuatan super untuk Linux” oleh beberapa orang, ini memungkinkan Anda untuk menjalankan “ring 3 user-space code” dalam kernel pada ring 0, di dalam mesin virtual.

eBPF telah terbukti menjadi alat yang sangat berharga untuk pemfilteran serta klasifikasi paket, diagnostik dan pelacakan jaringan, serta analisis kinerja antara lain di dalam Herza Cloud.

Artikel ini https://lwn.net/Articles/740157/ dapat memberikan informasi lebih lanjut tentang eBPF.

Apa itu XDP?

“XDP atau eXpress Data Path memberikan performa tinggi, jalur data jaringan yang dapat diprogram di kernel Linux sebagai bagian dari IO Visor Project. XDP menyediakan pemrosesan paket bare metal pada titik terendah dalam tumpukan perangkat lunak yang menjadikannya ideal untuk kecepatan tanpa mengurangi kemampuan pemrograman. Selain itu, fungsi baru dapat diimplementasikan secara dinamis dengan jalur cepat terintegrasi tanpa modifikasi kernel” – iovisor.org

Lihat https://www.iovisor.org/technology/xdp untuk informasi lebih lanjut tentang XDP.

eBPF dan XDP untuk Keamanan Jaringan

Mengapa kita ingin menggunakan eBPF dan XDP?

Hanya karena itu sangat memperkuat kemampuan Deteksi, Analisis, dan Mitigasi serangan DDoS dengan lebih terarah. Dengan memfilter paket pada tingkat silikon dengan perangkat keras seperti Mellanox Connect-X5, kami dapat mengungguli solusi lain yang telah kami uji secara andal.

Selain manfaat kinerja yang jelas, eBPF dan XDP bersama-sama memungkinkan kami menambahkan lapisan keamanan tambahan pada tingkat serendah mungkin. Hal ini bersama-sama dengan teknologi keamanan jaringan milik kami lainnya menambahkan hingga melebihi persyaratan Keamanan dari setiap Pemerintah, Perusahaan atau organisasi mana pun dengan data sensitif, dan platform Herza Cloud Network Intelligence & Analytics menyediakan analitik berkelanjutan secara real-time, memberi pelanggan visibilitas yang tak tertandingi dan wawasan yang dibutuhkan melalui jaringan dan infrastruktur.

Tapi seperti teknologi baru lainnya, ini bukannya tanpa masalah dan bahkan kadang-kadang kita merasa seperti kita memotong diri kita sendiri di ujung tombak, karena area yang kita injak benar-benar belum dieksplorasi.

Mari ambil cuplikan kode untuk menemukan data header IP terkait dengan header ETH (kode ini dapat ditemukan di beberapa contoh eBPF, dan kami juga menggunakan versinya):

static __always_inline bool parse_eth(struct ethhdr* eth,
                                      void* data_end,
                                      u16* eth_proto,
                                      u64* l3_offset) {
    u16 eth_type = eth->h_proto;
    u64 offset = 0;

    if ((void*)(eth + 1) > data_end)
        return false;

    /* Skip non 802.3 Ethertypes */
    if (unlikely(ntohs(eth_type) < ETH_P_802_3_MIN))
        return false;

        /* Handle (double) VLAN tagged packet */
#pragma unroll
    for (int i = 0; i < 2; ++i) {
        if (eth_type == htons(ETH_P_8021Q) || eth_type == htons(ETH_P_8021AD)) {
            struct vlan_hdr* vlan_hdr;

            vlan_hdr = (void*)eth + offset;
            offset += sizeof(*vlan_hdr);
            if ((void*)(eth + 1) + offset > data_end)
                return false;
            eth_type = vlan_hdr->h_vlan_encapsulated_proto;
        }
    }

    *eth_proto = ntohs(eth_type);
    *l3_offset = offset;
    return true;
}

Dalam hal ini offset memiliki salah satu dari 3 nilai constant values: 0, sizeof(struct vlan_hdr) atau 2 * sizeof(struct vlan_hdr), yang terlihat saat melihat bytecode yang dikompilasi. offset disimpan dalam register r4, dan inilah yang terjadi padanya:

$ llvm-objdump -S -no-show-raw-insn xdp_l3offset_kern.o

; offset = 0;
      15:       r4 = 0
; offset += sizeof(*vlan_hdr);
      20:       r4 = 4
; offset += sizeof(*vlan_hdr);
      26:       r5 = r4
      27:       r5 += 4
      // ...
      35:       r4 = r5

We know that the value is [0-8], and the in-kernel eBPF verifier knows it too, as it tracks registers’ values to make sure that operations on the packet are well defined:

    if (eth_proto == ETH_P_IP) {
        struct iphdr* ip = (void*)(eth + 1) + l3_offset;
        if ((void*)(ip + 1) > data_end)
            return XDP_DROP;

        // Will print the protocol number to /sys/kernel/debug/tracing/trace_pipe
        bpf_trace_printk("ipproto: %u\n", ip->protocol);
    }

$ llvm-objdump -S -no-show-raw-insn xdp_l3offset_kern.o

; struct iphdr* ip = (void*)(eth + 1) + l3_offset;
; r2 contains the packet pointer
      42:       r2 += r4

Pada hari-hari awal pengembangan kami dengan XDP dan eBPF, kami mengalami banyak masalah dan karenanya kami dengan senang hati membagikan informasi ini dengan komunitas open source yang lebih luas dengan harapan dapat membantu seseorang di luar sana.

Kami juga senang untuk membagikan informasi ini sebagai pembaruan dan bersemangat untuk memberi tahu Anda berita dan berbagi pembaruan sepanjang perjalanan teknologi kami, dan saat kami merilis fitur dan produk baru, kami akan terus mengabari Anda.