Apa Itu XDP dan Bagaimana Cara Kerjanya Membangun Perlindungan Anti-DDoS?

Pengenalan XDP, dan Bagaimana Ini Dapat Membantu Membangun Perlindungan Anti-DDoS?

Jika Anda menjalankan API publik, reverse proxy, layanan game, atau beban kerja lain yang menghadap internet, Anda dapat mencapai titik yang menyakitkan di mana server sibuk dengan lalu lintas yang tidak pernah berguna sejak awal. Aplikasi tidak selalu gagal karena tidak dapat menangani pengguna nyata. Aplikasi gagal karena host menghabiskan waktu CPU menerima, mengurai, mengklasifikasikan, dan membawa paket sampah lebih dalam ke Linux sebelum ada yang mengatakan “tidak.” Banyak masalah anti-DDoS dimulai dari sana: bukan sebagai cerita bandwidth, tetapi sebagai cerita biaya pemrosesan paket.

Itu penting bagi lebih dari sekadar spesialis kernel. Developer, self-hoster, operator VPS dan server dedicated, dan bahkan pembaca bisnis yang membandingkan opsi ketahanan semuanya menghadapi pertanyaan dasar yang sama: seberapa awal lalu lintas buruk dapat ditolak sebelum menghabiskan waktu dan sumber daya yang seharusnya milik pekerjaan nyata? Beberapa serangan menghancurkan uplink itu sendiri, tetapi banyak situasi yang merusak muncul lebih awal sebagai tekanan paket-per-detik pada host jauh sebelum lini sepenuhnya jenuh.

Di sinilah XDP menjadi layak dipahami. Ini tidak menggantikan mitigasi upstream, firewall, atau kontrol yang menyadari aplikasi. Yang ditawarkannya adalah checkpoint yang jauh lebih awal dalam jalur paket Linux. Artikel ini menjelaskan apa itu XDP, mengapa posisi “lebih awal” itu penting untuk pekerjaan anti-DDoS, dan di mana itu cocok dalam tumpukan yang realistis. Untuk mengikuti sisanya, Anda hanya perlu set kosakata yang sangat kecil terlebih dahulu.

Kata Kunci XDP yang Perlu Anda Ketahui dalam 2 Menit

Beberapa istilah seputar XDP saling tumpang tindih, dan pada awalnya terdengar lebih menakutkan daripada kenyataannya. Itu normal. Tujuan glosarium ini bukan untuk mengubah artikel menjadi pelajaran internals Linux. Ini hanya cukup bahasa untuk membantu penjelasan selanjutnya berjalan dengan lancar.

Jika Anda hanya mengingat satu jalan pintas mental dari tabel itu, buatlah ini: eBPF adalah mekanisme yang dapat diprogram, dan XDP adalah satu tempat spesifik di mana mekanisme itu dapat berjalan. Dengan itu, langkah selanjutnya adalah pertanyaan yang lebih sederhana dan lebih berguna: apa yang sebenarnya dilakukan XDP?

Apa Sebenarnya XDP

XDP adalah hook pemrosesan paket awal di Linux. Ini memungkinkan sistem menjalankan program eBPF kecil pada paket segera setelah paket tersebut tiba di antarmuka jaringan. Pada saat itu, Linux dapat membuat keputusan cepat: biarkan paket melanjutkan (XDP_PASS), lepaskan segera (XDP_DROP), atau tangani dengan cara lain yang ditentukan. Untuk artikel ini, bagian penting sangat sederhana: XDP dapat mengatakan “biarkan lewat” atau “hentikan di sini” sangat awal.

Linux menggunakan eBPF dalam beberapa konteks, bukan hanya jaringan. XDP adalah versi yang berfokus pada jaringan yang dibangun untuk penanganan awal paket masuk. Jadi XDP bukan sinonim lain untuk eBPF. Ini adalah satu alat berbasis eBPF dengan peran yang sangat spesifik.

Peran itulah yang membuat XDP berguna untuk pekerjaan anti-DDoS. XDP berjalan sebelum paket melewati bagian normal yang lebih berat dari jalur jaringan Linux. Dengan demikian, Linux dapat memutuskan beberapa lalu lintas sebelum mengeluarkan lebih banyak usaha untuk firewall, pelacakan koneksi, soket, dan akhirnya aplikasi itu sendiri. Itulah mengapa keuntungan sebenarnya dari XDP bukan hanya penyaringan — ini adalah penyaringan lebih awal.

Selain itu, XDP berguna untuk lebih dari sekadar anti-DDoS. Ini juga dapat mendukung pengarahan lalu lintas dan tugas penanganan paket lainnya. Tetapi anti-DDoS adalah tempat paling mudah untuk melihat nilainya, karena manfaatnya bermuara pada satu ide praktis: semakin cepat lalu lintas buruk ditolak, semakin sedikit pekerjaan yang tidak berguna yang harus dilakukan server. Dan untuk memahami mengapa itu sangat penting, langkah berikutnya adalah melihat dengan tepat di mana XDP berada di jalur penerimaan paket.

Model Mental: XDP Adalah Gerbang, Bukan Meja Resepsi

Cara termudah untuk membayangkan XDP adalah sebagai petugas keamanan di gerbang, bukan resepsionis yang lebih dalam di dalam gedung. Jika pengunjung yang jelas tidak diinginkan ditolak di gerbang, gedung menghindari rantai panjang pekerjaan yang sia-sia. Tidak ada yang membuka pintu dalam, memasukkan mereka ke dalam sistem, atau membawa mereka melalui lorong. Jika Anda menunggu sampai meja resepsi untuk menolak mereka, gedung sudah menghabiskan waktu dan perhatian untuk orang yang salah.

Penanganan paket Linux bekerja dengan cara yang sama. Dalam jalur penerimaan yang disederhanakan, paket tiba dari NIC dan driver, mencapai XDP, dan hanya kemudian melanjutkan ke dalam stack jaringan kernel yang lebih kaya yang memberi makan conntrack, firewalling, socket, dan akhirnya aplikasi. Secara visual, jalurnya terlihat seperti ini:

NIC / driver
    ↓
XDP  ← earliest checkpoint
    ↓
kernel networking stack
    ↓
conntrack / firewall
    ↓
socket
    ↓
application

Dalam mode native, XDP dapat bertindak sebelum Linux mengalokasikan dan mengisi struktur sk_buff biasa — objek paket kernel yang lebih kaya yang diharapkan oleh sisa stack. Detail itu terdengar kecil, tetapi itu adalah jantung dari cerita kinerja. Jika paket jelas tidak diinginkan, menjatuhkannya sebelum Linux membangun struktur normal itu berarti lebih sedikit pekerjaan CPU, lebih sedikit perubahan memori, dan lebih sedikit tekanan hilir. XDP_PASS ada karena tidak setiap paket itu buruk; itu adalah tindakan “lanjutkan” yang memungkinkan lalu lintas yang sah terus bergerak. XDP_DROP adalah bintang anti-DDoS karena mengakhiri perjalanan sebelum bagian yang mahal dimulai. Tindakan lain seperti REDIRECT juga ada, tetapi mereka tidak penting untuk penjelasan ini.

Setelah penempatan jelas, nilai anti-DDoS — dan keterbatasannya — menjadi jauh lebih mudah untuk dinilai secara realistis.

Bagaimana XDP Membantu Anti-DDoS — dan Di Mana Batasannya Dimulai

Kasus anti-DDoS untuk XDP sangat jelas: ini adalah cara murah untuk menolak sampah yang jelas sebelum Linux menghabiskan sumber daya pada conntrack, penanganan socket, dan pengiriman user-space. Jika host sedang dipenuhi dengan lalu lintas tingkat tinggi yang seharusnya tidak pernah mencapai aplikasi, setiap paket yang dijatuhkan lebih awal adalah pekerjaan yang tidak lagi harus dilakukan server nanti. Itulah mengapa XDP paling kuat di tepi L3/L4 dari masalah: alamat sumber yang sudah Anda curigai, protokol yang tidak Anda inginkan, atau pola lalu lintas yang jelas tidak sah untuk beban kerja.

Ini paling penting selama banjir sampah di mana bagian yang menyakitkan bukan volume data mentah tetapi penanganan paket berulang. Proxy terbalik, layanan berat UDP, atau API publik dapat menjadi lambat jauh sebelum uplink sepenuhnya jenuh jika host sibuk mengklasifikasikan omong kosong. XDP memberi Anda cara untuk memotong beberapa pemborosan itu dekat dengan pintu.

📝 Catatan: XDP melindungi sumber daya host lebih baik daripada melindungi tautan upstream yang jenuh. Jika tautan yang menghadap penyedia sudah penuh, penjatuhan awal tingkat host terlambat untuk memperbaiki jalur jaringan dengan sendirinya.

Perbedaan itu adalah alasan utama mengapa XDP termasuk dalam desain berlapis daripada di atas batu loncatan. Tabel berikut adalah versi praktis dari XDP vs nftables vs mitigasi upstream/penyedia:

Dengan kata lain, XDP dan nftables bukan musuh. Mereka menyelesaikan bagian berbeda dari jalur. nftables lebih kaya dan stateful. xdp-filter — alat demo yang digunakan dalam artikel ini — sengaja sederhana dan stateless, yang persis mengapa berguna untuk menunjukkan model XDP tanpa berpura-pura menggantikan firewall lengkap. Jika Anda membutuhkan pelacakan koneksi, daftar izin berlapis, penanganan status balasan, atau aturan yang menyadari aplikasi, Anda sudah menggambarkan masalah yang termasuk lebih dalam daripada utilitas demo ini.

Operator produksi memang menggunakan penjatuhan gaya XDP karena pembuangan awal mengurangi pekerjaan hilir. Cerita L4Drop Cloudflare adalah contoh terkenal mengapa model itu menjadi menarik dalam operasi nyata. Tetapi pelajaran penting bukan hanya angka paket-per-detik headline. Ini adalah logika desain: tolak lalu lintas buruk lebih awal sehingga sisa mesin dapat terus melayani lalu lintas nyata lebih lama.

Hasil dunia nyata sangat bergantung pada lingkungan. Dukungan NIC dan driver, apakah XDP berjalan dalam mode native atau skb, dan bentuk lalu lintas masuk semuanya mempengaruhi berapa banyak manfaat yang sebenarnya Anda dapatkan. Itulah mengapa angka paket-per-detik headline dari vendor atau hyperscaler paling baik diperlakukan sebagai bukti bahwa model penjatuhan awal berfungsi, bukan sebagai angka yang setiap VPS harus harapkan. Dengan itu dalam pikiran, bagian berikutnya menunjukkan seperti apa XDP pada host Ubuntu nyata melalui beberapa snapshot operator yang aman.

Seperti Apa XDP dalam Praktik — Snapshot Perintah

Bagian ini adalah snapshot proof-of-concept. Tujuannya adalah membuat XDP terasa nyata di Ubuntu 24.04 dengan rangkaian perintah yang relevan: cukup untuk memuat filter, memeriksa apa yang terpasang, menambahkan satu aturan berisiko rendah, dan membaca penghitung yang penting.

Sebelum melanjutkan ke setup XDP, Anda perlu menemukan dan memilih nama antarmuka terlebih dahulu.

ip -br link

Instal prasyarat.

sudo apt update
sudo apt install -y xdp-tools

Dalam perintah di bawah, ganti <ifname> dengan nama antarmuka jaringan aktual Anda, seperti eth0 atau ens3.

sudo xdp-filter load -m skb <ifname>

Dua perintah pertama bertanggung jawab untuk menginstal alat yang diperlukan, memastikan bahwa lingkungan memiliki semua yang diperlukan untuk menjalankan demo.

Perintah ketiga kemudian memuat xdp-filter dalam mode skb dengan kebijakan allow default. Pada host Ubuntu yang digunakan untuk artikel ini, itu menghasilkan varian xdpfilt_alw_all dengan rangkaian fitur lengkap tcp,udp,ipv6,ipv4,ethernet,allow. Memilih -m skb menghindari asumsi dukungan XDP native di NIC atau driver Anda, menjadikannya jalur yang lebih aman untuk proof of concept pertama.

Untuk memverifikasi bahwa program benar-benar terpasang, jalankan:

sudo xdp-filter status
ip -details link show dev <ifname>

Dalam xdp-filter status, Anda ingin melihat antarmuka Anda terdaftar dengan skb mode; pada host pengujian di sini, rangkaian fitur yang dimuat menunjukkan tcp,udp,ipv6,ipv4,ethernet,allow. Dalam ip -details link show, lampiran xdpgeneric dan program xdp_dispatcher mengkonfirmasi bahwa XDP generik aktif di antarmuka tersebut.

⚠️ Peringatan: Jangan menguji kebijakan deny-default atau aturan drop luas pada antarmuka jarak jauh langsung yang membawa sesi SSH Anda kecuali Anda memiliki pemulihan konsol. Artikel ini tetap menggunakan kebijakan allow dan satu aturan alamat dokumentasi untuk alasan yang tepat.

Selanjutnya, periksa penemuan kemampuan. Ini memberi tahu Anda apa yang diekspos NIC dan driver di permukaan XDP, bukan apa yang akan menjadi kinerja akhir Anda.

sudo xdp-loader features <ifname>

Output yang tepat bervariasi menurut perangkat keras, tetapi hasil yang representatif sering kali berisi baris seperti ini:

Yang paling penting di sini adalah NETDEV_XDP_ACT_BASIC, karena itu memberi tahu Anda bahwa jalur mengekspos model aksi XDP inti. Bendera tambahan seperti dukungan redirect berguna, tetapi tidak diperlukan untuk proof of concept anti-DDoS sederhana.

Selanjutnya, verifikasi bagaimana pemuat XDP mengelola program dan mode mana yang sedang dijalankannya.

sudo xdp-loader status

Pada sistem yang berfungsi, tampilan status mungkin terlihat seperti ini:

Ini adalah pemeriksaan operator kecil tetapi penting. Ini mengkonfirmasi bahwa XDP bukan hanya konsep aturan yang hidup di ruang pengguna — ada program yang dimuat di antarmuka, dan kolom mode memberi tahu Anda apakah Anda melihat native atau skb.

Sekarang tambahkan satu aturan contoh aman menggunakan alamat IP dokumentasi. Bendera -s membantu karena langsung mencetak status aturan yang dihasilkan alih-alih membiarkan Anda dengan kesuksesan senyap.

sudo xdp-filter ip -s -m src 192.0.2.1

Respons yang representatif mungkin terlihat seperti ini:

📝 Catatan: xdp-filter default ke kebijakan allow. Dengan kata lain, paket yang cocok dengan aturan dijatuhkan, dan paket yang tidak cocok dengan aturan terus melalui jalur normal.

Contoh ini sengaja membosankan. Dalam istilah anti-DDoS, ini juga menunjukkan versi paling sederhana dari aturan drop awal: lalu lintas dari sumber yang tidak Anda inginkan dapat ditolak sebelum sisa host menginvestasikan banyak pekerjaan di dalamnya.

Terakhir, periksa keadaan keseluruhan di satu tempat.

sudo xdp-filter status

Pada sistem tipikal, pola output adalah yang paling informatif.

Tampilan status ini adalah tempat proof of concept menjadi berguna secara operasional. Anda dapat melihat antarmuka yang dimuat, mode aktif, varian xdp-filter aktif, rangkaian fitur efektif, dan status penghitung per-aturan dalam satu perintah. XDP_ABORTED, jika muncul, terutama merupakan bucket kesalahan/debug daripada aksi yang Anda rencanakan. Lebih penting lagi, jika penghitung drop tetap di 0, itu tidak berarti filter gagal. Ini hanya berarti tidak ada paket yang cocok yang mengenai aturan selama jendela penangkapan.

💡 Takeaway: Perlakukan xdp-filter sebagai alat proof-of-concept sederhana dan stateless, bukan pengganti nftables. Juga ingat bahwa paket yang dijatuhkan di lapisan XDP mungkin tidak pernah muncul di jalur tcpdump biasa, yang membuat output status dan penghitung asli XDP menjadi metode validasi yang lebih andal. Jika Anda menginginkan tampilan langsung nanti, sudo xdp-filter poll -i 2000 adalah langkah opsional berikutnya yang masuk akal — tetapi hanya ketika antarmuka sudah memiliki lalu lintas menarik yang cukup untuk membuat output itu berguna.

Melihat demo yang aman membuat idenya konkret. Keputusan sebenarnya, bagaimanapun, bukan apakah perintah berjalan. Ini adalah apakah lapisan tambahan ini layak untuk kompleksitas operasional pada jenis infrastruktur yang benar-benar Anda kelola.

Kapan XDP Layak Dipertimbangkan untuk VPS dan Dedicated Servers

XDP menjadi menarik ketika beban kerja yang menghadap publik kehilangan waktu CPU yang berarti untuk paket yang tidak diinginkan sebelum aplikasi dapat merespons secara normal. Kandidat yang baik termasuk API publik, reverse proxy, gateway, layanan UDP-heavy yang terbuka ke internet, dan host yang secara teratur melihat cukup traffic sampah untuk membebani jalur jaringan bahkan ketika aplikasi itu sendiri bukan bottleneck. Di lingkungan tersebut, penolakan lebih awal dapat mengembalikan headroom server yang nyata.

Ada juga banyak kasus di mana filtering yang lebih sederhana sudah cukup. Website dengan traffic rendah, tool internal, staging box, atau layanan yang persyaratan sebenarnya adalah firewalling host yang stateful daripada relief packet-rate biasanya tidak memerlukan XDP terlebih dahulu. Jika nftables sudah mencakup risiko tanpa tekanan path paket yang terlihat, menambahkan layer lain mungkin menciptakan lebih banyak moving parts daripada nilai.

Sebagai framework keputusan cepat:

• Firewalling biasanya cukup ketika traffic ringan, kebijakan memerlukan state atau logika layanan yang lebih kaya, dan host tidak terlihat jelas membakar CPU pada paket sampah.
• XDP menjadi layak dievaluasi ketika traffic yang tidak diinginkan mencapai host cukup sering sehingga early drop dapat melindungi CPU, conntrack, dan kapasitas socket.
• Mitigasi upstream tetap wajib ketika mode kegagalan sebenarnya adalah saturasi link penyedia atau flooding volumetrik yang lebih besar sebelum paket bahkan mencapai server Anda.

Pengguna VPS harus mengingat satu peringatan: jalur NIC virtual dan abstraksi penyedia dapat membatasi ekspektasi native-mode bahkan ketika mode skb bekerja baik untuk demo. Dedicated server biasanya memberi Anda kontrol lebih besar atas driver, hardware, dan observability, jadi peluang dukungan native-mode yang bermakna lebih baik di sana — tetapi bahkan pada bare metal, XDP masih satu layer, bukan seluruh jawaban. Jika Anda mengevaluasi AlexHost atau penyedia lain, tanyakan tiga pertanyaan terpisah alih-alih menggabungkannya: apa penanganan DDoS upstream yang ada, berapa banyak headroom host yang diberikan paket, dan kontrol level-host apa yang realistis di platform itu?

Kesimpulan: XDP Adalah Lapisan Penghapusan Awal, Bukan Perisai Lengkap

Cara paling jelas untuk berpikir tentang XDP adalah ini: ini memberikan Linux checkpoint cepat pertama untuk lalu lintas buruk yang jelas dan banjir paket, yang berarti melindungi sumber daya server dengan lebih baik daripada melindungi tautan hulu yang jenuh. Itulah mengapa XDP penting dalam percakapan anti-DDoS. Ini tidak menggantikan mitigasi hulu, firewall stateful, atau kontrol yang menyadari aplikasi. Ini membantu dengan membuat host melakukan lebih sedikit pekerjaan yang sia-sia.

Jadi aturan praktisnya sederhana. Jika lalu lintas yang tidak diinginkan membuang-buang CPU host sebelum beban kerja nyata dapat merespons, XDP layak dievaluasi sebagai lapisan penghapusan awal. Jika masalah utamanya adalah uplink penuh atau kebijakan yang bergantung pada state dan logika aplikasi, XDP sebaiknya berada di belakang mitigasi hulu dan penyaringan yang lebih dalam daripada di depan mereka sebagai jawaban lengkap. Langkah alami berikutnya dari sini adalah tindak lanjut tentang menulis program XDP kustom atau membangun pertahanan berlapis yang lebih kaya di sekitar ide penghapusan awal yang sama.