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

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

Jika Anda menjalankan API publik, reverse proxy, layanan game, atau beban kerja lain yang menghadap internet, Anda bisa mencapai titik menyakitkan di mana server sibuk menangani 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 untuk 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 masalah bandwidth, melainkan sebagai masalah biaya pemrosesan paket.

Hal ini penting bagi lebih dari sekadar spesialis kernel. Pengembang, self-hoster, operator VPS dan server dedicated, 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 menjadi milik pekerjaan nyata? Beberapa serangan menghancurkan uplink itu sendiri, tetapi banyak situasi merusak muncul lebih awal sebagai tekanan paket-per-detik pada host jauh sebelum jalur sepenuhnya jenuh.

Di situlah XDP menjadi layak untuk dipahami. XDP tidak menggantikan mitigasi upstream, firewall, atau kontrol yang sadar aplikasi. Yang ditawarkannya adalah titik pemeriksaan 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 XDP cocok dalam tumpukan yang realistis. Untuk mengikuti selebihnya, Anda hanya membutuhkan kosakata yang sangat kecil terlebih dahulu.

Kata Kunci XDP yang Anda Butuhkan dalam 2 Menit

Beberapa istilah seputar XDP saling tumpang tindih, dan pada awalnya terdengar lebih menakutkan dari yang sebenarnya. Itu normal. Tujuan glosarium ini bukan untuk mengubah artikel menjadi pelajaran internal Linux. Ini hanya cukup bahasa untuk membantu penjelasan selanjutnya tersampaikan dengan jelas.

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

Apa Sebenarnya XDP Itu

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

Linux menggunakan eBPF dalam beberapa konteks, tidak hanya jaringan. XDP adalah versi yang berfokus pada jaringan yang dibangun untuk penanganan sangat awal paket yang masuk. Jadi XDP bukan kata lain untuk eBPF. XDP 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 menghabiskan lebih banyak upaya pada firewalling, pelacakan koneksi, socket, dan akhirnya aplikasi itu sendiri. Itulah mengapa keunggulan nyata XDP bukan hanya pemfilteran — melainkan pemfilteran yang lebih awal.

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

Model Mental: XDP Adalah Gerbang, Bukan Meja Resepsionis

Cara termudah untuk membayangkan XDP adalah sebagai petugas keamanan di gerbang, bukan resepsionis yang lebih dalam di dalam gedung. Jika tamu yang jelas tidak diinginkan ditolak di gerbang, gedung menghindari rangkaian panjang pekerjaan yang sia-sia. Tidak ada yang membuka pintu dalam, mendaftarkan mereka ke sistem, atau mengantar mereka melalui koridor. Jika Anda menunggu hingga meja resepsionis untuk menolak mereka, gedung sudah menghabiskan waktu dan perhatian pada 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 baru kemudian melanjutkan ke tumpukan 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 native mode, XDP dapat bertindak sebelum Linux mengalokasikan dan mengisi struktur sk_buff yang biasa — objek paket kernel yang lebih kaya yang diharapkan oleh sisa tumpukan. Detail itu terdengar kecil, tetapi itulah inti dari cerita kinerja. Jika paket jelas tidak diinginkan, menjatuhkannya sebelum Linux membangun struktur normal tersebut berarti lebih sedikit pekerjaan CPU, lebih sedikit churn memori, dan lebih sedikit tekanan downstream. XDP_PASS ada karena tidak setiap paket buruk; itu adalah tindakan “lanjutkan” yang membiarkan lalu lintas sah terus bergerak. XDP_DROP adalah bintang anti-DDoS karena mengakhiri perjalanan sebelum bagian yang mahal dimulai. Tindakan lain seperti REDIRECT juga ada, tetapi tidak penting untuk penjelasan ini.

Setelah penempatannya jelas, nilai anti-DDoS — dan batasannya — 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 sebuah host sedang dibombardir dengan lalu lintas tinggi yang seharusnya tidak pernah mencapai aplikasi, setiap paket yang dijatuhkan lebih awal adalah pekerjaan yang tidak perlu lagi dilakukan server nanti. Itulah mengapa XDP paling kuat di tepi L3/L4 dari masalah: alamat sumber yang sudah tidak Anda percaya, 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. Reverse proxy, 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 sebagian 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, early drop di tingkat host sudah terlambat untuk memperbaiki jalur jaringan dengan sendirinya.

Perbedaan itu adalah alasan utama XDP termasuk dalam desain berlapis daripada di atas podium. Tabel berikut adalah versi praktis dari XDP vs nftables vs upstream/provider mitigation:

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

Operator produksi menggunakan penjatuhan gaya XDP karena pembuangan awal mengurangi pekerjaan downstream. Kisah L4Drop Cloudflare adalah contoh terkenal mengapa model itu menjadi menarik dalam operasi nyata. Tetapi pelajaran pentingnya bukan hanya angka paket-per-detik di 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 yang masuk semuanya mempengaruhi seberapa besar manfaat yang sebenarnya Anda dapatkan. Itulah mengapa angka paket-per-detik dari vendor atau hyperscaler sebaiknya diperlakukan sebagai bukti bahwa model early-drop bekerja, bukan sebagai angka yang diharapkan setiap VPS. Dengan itu dalam pikiran, bagian selanjutnya 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 kumpulan perintah yang relevan: cukup untuk memuat filter, memeriksa apa yang terlampir, menambahkan satu aturan berisiko rendah, dan membaca penghitung yang penting.

Sebelum melanjutkan ke pengaturan 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 ini, ganti <ifname> dengan nama antarmuka jaringan Anda yang sebenarnya, 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 dibutuhkan 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 set 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 terlampir, 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, set fitur yang dimuat menunjukkan tcp,udp,ipv6,ipv4,ethernet,allow. Dalam ip -details link show, lampiran xdpgeneric dan program xdp_dispatcher mengonfirmasi bahwa generic XDP aktif pada antarmuka tersebut.

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

Selanjutnya, periksa penemuan kapabilitas. Ini memberi tahu Anda apa yang diekspos NIC dan driver dalam permukaan XDP, bukan apa kinerja akhir Anda.

sudo xdp-loader features <ifname>

Output yang tepat bervariasi berdasarkan hardware, tetapi hasil yang representatif sering mengandung baris seperti ini:

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

Selanjutnya, verifikasi bagaimana XDP loader mengelola program dan mode apa yang sedang dijalankannya.

sudo xdp-loader status

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

Ini adalah pemeriksaan operator yang kecil namun penting. Ini mengonfirmasi bahwa XDP bukan hanya konsep aturan yang hidup di user space — ada program yang dimuat pada antarmuka, dan kolom mode memberi tahu Anda apakah Anda melihat native atau skb.

Sekarang tambahkan satu contoh aturan aman menggunakan alamat IP dokumentasi. Flag -s berguna karena mencetak status aturan yang dihasilkan segera alih-alih membiarkan Anda dengan keberhasilan yang diam.

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 melanjutkan melalui jalur normal.

Contoh ini sengaja dibuat membosankan. Dalam istilah anti-DDoS, ini juga menunjukkan versi paling sederhana dari aturan early drop: lalu lintas dari sumber yang tidak Anda inginkan dapat ditolak sebelum sisa host banyak berinvestasi padanya.

Terakhir, periksa keseluruhan status dalam satu tempat.

sudo xdp-filter status

Pada sistem yang umum, 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, set fitur efektif, dan status penghitung per aturan dalam satu perintah. XDP_ABORTED, jika muncul, terutama merupakan bucket error/debug daripada tindakan yang Anda rencanakan. Yang lebih penting, jika penghitung drop tetap di 0, itu tidak berarti filter gagal. Itu hanya berarti tidak ada paket yang cocok yang mengenai aturan selama jendela pengambilan.

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

Melihat demo yang aman membuat ide menjadi konkret. Keputusan nyata, bagaimanapun, bukan apakah perintah berjalan. Ini adalah apakah lapisan ekstra ini sepadan dengan kompleksitas operasional pada jenis infrastruktur yang sebenarnya Anda kelola.

Kapan XDP Layak Dipertimbangkan untuk VPS dan Server Dedicated

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 berat UDP yang terekspos internet, dan host yang secara teratur melihat cukup lalu lintas sampah untuk menekan jalur jaringan bahkan ketika aplikasi itu sendiri bukan bottleneck. Dalam lingkungan tersebut, penolakan lebih awal dapat mendapatkan kembali headroom server yang nyata.

Ada juga banyak kasus di mana pemfilteran yang lebih sederhana sudah cukup. Situs web dengan lalu lintas rendah, alat internal, kotak staging, atau layanan yang persyaratan nyatanya adalah firewalling host stateful daripada bantuan packet-rate biasanya tidak membutuhkan XDP terlebih dahulu. Jika nftables sudah mencakup risiko tanpa tekanan jalur paket yang terlihat, menambahkan lapisan lain mungkin menciptakan lebih banyak bagian yang bergerak daripada nilai.

Sebagai kerangka keputusan cepat:

• Firewalling biasanya sudah cukup ketika lalu lintas ringan, kebijakan membutuhkan status atau logika layanan yang lebih kaya, dan host tidak terlihat membakar CPU pada paket sampah.
• XDP layak dievaluasi ketika lalu lintas yang tidak diinginkan mencapai host cukup sering sehingga early drop dapat melindungi CPU, conntrack, dan kapasitas socket.
• Mitigasi upstream tetap wajib ketika mode kegagalan nyata adalah kejenuhan tautan penyedia atau banjir 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 dengan baik untuk demo. Server dedicated biasanya memberi Anda lebih banyak kontrol atas driver, hardware, dan observabilitas, sehingga peluang dukungan native-mode yang berarti lebih baik di sana — tetapi bahkan pada bare metal, XDP masih merupakan satu lapisan, bukan keseluruhan jawaban. Jika Anda mengevaluasi AlexHost atau penyedia lain, ajukan tiga pertanyaan terpisah alih-alih menggabungkannya: penanganan DDoS upstream apa yang ada, berapa banyak headroom host yang diberikan paket tersebut kepada Anda, dan kontrol tingkat host apa yang realistis pada platform tersebut?

Kesimpulan: XDP Adalah Lapisan Early-Drop, Bukan Perisai Keseluruhan

Cara paling bersih untuk memikirkan XDP adalah ini: XDP memberi Linux titik pemeriksaan pertama yang cepat untuk lalu lintas buruk yang jelas dan banjir paket, yang berarti XDP melindungi sumber daya server lebih baik daripada melindungi tautan upstream yang jenuh. Itulah mengapa XDP penting dalam percakapan anti-DDoS. XDP tidak menggantikan mitigasi upstream, firewalling stateful, atau kontrol yang sadar aplikasi. XDP membantu dengan membuat host melakukan lebih sedikit pekerjaan yang sia-sia.

Jadi aturan praktisnya sederhana. Jika lalu lintas yang tidak diinginkan membuang CPU host sebelum beban kerja nyata dapat merespons, XDP layak dievaluasi sebagai lapisan early-drop. Jika masalah utamanya adalah uplink yang penuh atau kebijakan yang bergantung pada status dan logika aplikasi, XDP termasuk di belakang mitigasi upstream dan pemfilteran yang lebih dalam daripada di depannya 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 early-drop yang sama.