Keamanan Linux Server bukan hanya tentang mengamankan SSH, memasang firewall, atau memperbarui aplikasi yang berjalan di atasnya. Salah satu komponen paling penting yang sering luput dari perhatian administrator adalah kernel Linux.

Kernel merupakan inti sistem operasi yang bertanggung jawab mengelola memori, proses, perangkat keras, serta komunikasi jaringan. Apabila terdapat kerentanan pada kernel, dampaknya dapat menjangkau seluruh layanan yang berjalan di dalam server.

Salah satu kerentanan yang perlu mendapatkan perhatian administrator infrastruktur adalah CVE-2026-98432, yaitu kerentanan Use-After-Free pada subsistem jaringan IPv4 TCP Linux Kernel.

Kerentanan ini berkaitan dengan race condition ketika kernel memproses permintaan koneksi TCP secara bersamaan. Dalam kondisi tertentu, sebuah objek memori yang masih digunakan oleh proses lain dapat dibebaskan terlalu cepat.

Kondisi tersebut berpotensi menyebabkan kernel crash, Denial of Service (DoS), hingga kerusakan memori yang lebih serius.

Berdasarkan pengumuman Linux Kernel CVE Team, kerentanan ini memperoleh skor CVSS 3.1 sebesar 9.8 dengan kategori Critical. Artinya, kerentanan tersebut memiliki karakteristik eksploitasi melalui jaringan, tidak memerlukan autentikasi, dan tidak membutuhkan interaksi pengguna. Git at Google+1

Bagi administrator Linux, langkah mitigasi tidak boleh berhenti pada pemeriksaan versi kernel. Diperlukan proses identifikasi sistem, evaluasi layanan jaringan, pemasangan pembaruan keamanan, pengujian, hingga monitoring setelah patch diterapkan.

Artikel ini membahas langkah-langkah praktis untuk mengamankan Linux Server dari CVE-2026-98432, termasuk implementasi pada Debian, Ubuntu, Rocky Linux, RHEL, dan Amazon Linux.

Catatan penting: Panduan ini membahas mitigasi berdasarkan informasi publik hingga 31 Oktober 2026. Status patch distribusi dapat berubah. Selalu gunakan advisory resmi vendor untuk menentukan apakah paket kernel tertentu sudah diperbaiki.

1. Mengenal Risiko CVE-2026-98432

1.1 Apa yang membuat kerentanan ini berbahaya?

CVE-2026-98432 merupakan kerentanan pada implementasi IPv4 TCP di Linux Kernel.

Masalah utamanya berkaitan dengan pengelolaan objek inet_opt dan ireq_opt.

Ketika kernel memproses koneksi TCP, informasi tertentu disimpan dalam objek memori yang berkaitan dengan socket. Pada kondisi konkurensi tertentu, kepemilikan objek tersebut dapat berpindah ke socket baru, sementara CPU lain masih mengakses objek yang sama.

Jika objek memori dibebaskan sebelum seluruh pembacaan selesai, terjadilah kondisi Use-After-Free.

Dampak potensialnya meliputi:

• Kernel panic dan server mengalami crash.
• Denial of Service yang mengganggu ketersediaan layanan.
• Memory corruption.
• Potensi eksekusi kode dalam konteks kernel apabila kondisi eksploitasi mendukungnya.

Perlu dibedakan antara dampak yang secara teknis dimungkinkan dan eksploitasi yang telah terbukti terjadi di lingkungan produksi. Administrator tidak boleh menganggap setiap server terdampak pasti dapat diambil alih menggunakan remote code execution.

1.2 Mengapa administrator harus segera melakukan mitigasi?

Berbeda dengan kerentanan aplikasi yang hanya memengaruhi satu layanan, kerentanan kernel berpotensi memengaruhi seluruh sistem.

Bayangkan sebuah server Linux menjalankan beberapa layanan:

• Web server Apache atau Nginx.
• Database MariaDB atau PostgreSQL.
• SSH untuk administrasi.
• Docker dan container.
• Kubernetes worker node.
• Monitoring Prometheus dan Grafana.

Apabila kernel mengalami gangguan serius, layanan-layanan tersebut dapat ikut terdampak.

Karena itu, mitigasi CVE-2026-98432 harus diperlakukan sebagai bagian dari pengelolaan risiko infrastruktur, bukan sekadar aktivitas update rutin.

2. Strategi Mitigasi CVE-2026-98432

Mitigasi yang efektif harus dilakukan secara berlapis.

Alur pengamanan Linux Server

1. Inventarisasi seluruh server Linux dan versi kernel.
2. Identifikasi layanan TCP dan permukaan serangan.
3. Periksa status kerentanan berdasarkan advisory vendor.
4. Batasi paparan jaringan menggunakan firewall.
5. Pasang security update kernel.
6. Reboot dan verifikasi kernel aktif.
7. Lakukan monitoring dan dokumentasi hasil mitigasi.

Jangan langsung melakukan perubahan konfigurasi pada server produksi tanpa mengetahui dampaknya terhadap aplikasi dan jaringan.

3. Identifikasi Sistem Linux yang Digunakan

Langkah pertama adalah mengetahui sistem operasi, arsitektur, serta kernel yang digunakan.

3.1 Memeriksa distribusi Linux

Jalankan:

cat /etc/os-release

Perintah ini menampilkan informasi distribusi, versi, dan identitas sistem operasi.

Contoh informasi:

PRETTY_NAME="Debian GNU/Linux 13"
VERSION_ID="13"
ID=debian

Informasi ini membantu administrator menentukan sumber security advisory yang tepat.

3.2 Memeriksa versi kernel aktif

uname -r

Contoh:

6.12.0-1-amd64

Perintah tersebut menampilkan kernel yang sedang digunakan oleh sistem.

Perlu diperhatikan bahwa versi kernel yang sedang berjalan belum tentu sama dengan versi kernel terbaru yang sudah terpasang.

3.3 Memeriksa arsitektur sistem

uname -m

Contoh hasil:

x86_64

Informasi arsitektur diperlukan untuk memastikan paket kernel yang akan dipasang sesuai dengan platform server.

3.4 Memeriksa seluruh informasi kernel

uname -a

3.5 Memeriksa paket kernel Debian dan Ubuntu

dpkg -l | grep linux-image

Untuk melihat kernel yang tersedia:

ls -lh /boot/vmlinuz-*

3.6 Memeriksa paket kernel RHEL dan turunannya

rpm -qa | grep kernel

Untuk melihat kernel yang sedang digunakan:

rpm -q kernel-core

Penting: Jangan menentukan status kerentanan hanya berdasarkan uname -r. Distribusi Linux dapat melakukan backport patch keamanan tanpa mengubah nomor versi upstream kernel. Status perbaikan harus diperiksa melalui paket dan advisory vendor.

4. Identifikasi Layanan TCP yang Terbuka

Setelah mengetahui sistem operasi, administrator perlu memetakan layanan yang menerima koneksi jaringan.

4.1 Melihat seluruh port listening

sudo ss -tulnp

Perintah tersebut menampilkan:

• TCP dan UDP.
• Port listening.
• Alamat IP binding.
• Proses yang menggunakan port.

4.2 Melihat layanan TCP listening

sudo ss -lntp

4.3 Melihat koneksi TCP aktif

sudo ss -ant

4.4 Memeriksa service yang sedang berjalan

systemctl --type=service --state=running

Beberapa port yang perlu diperhatikan:

Port	Layanan	Rekomendasi
22	SSH	Batasi sumber akses
80	HTTP	Gunakan reverse proxy dan firewall
443	HTTPS	Pastikan hanya layanan yang diperlukan terbuka
3306	MySQL/MariaDB	Batasi ke jaringan aplikasi
5432	PostgreSQL	Jangan ekspos ke internet
6379	Redis	Batasi ke jaringan internal

Port tersebut bukan penyebab langsung CVE-2026-98432. Pemeriksaan bertujuan mengidentifikasi permukaan serangan dan menentukan layanan yang perlu dilindungi.

5. Periksa Konfigurasi MPTCP dan TCP Migration

Kerentanan ini berkaitan dengan pengelolaan socket TCP dan kondisi konkurensi pada subsistem IPv4.

Karena itu, pemeriksaan konfigurasi jaringan tambahan dapat membantu administrator memahami karakteristik sistem.

5.1 Memeriksa status Multipath TCP

Multipath TCP (MPTCP) merupakan pengembangan TCP yang memungkinkan satu koneksi menggunakan beberapa jalur jaringan.

Periksa statusnya:

sysctl net.mptcp.enabled

Contoh:

net.mptcp.enabled = 1

Nilai 1 menunjukkan MPTCP diaktifkan, sedangkan 0 menunjukkan MPTCP dinonaktifkan.

5.2 Memeriksa konfigurasi TCP request migration

Jalankan:

sysctl net.ipv4.tcp_migrate_req

Fitur ini berkaitan dengan kemampuan memindahkan pending connection request ke socket lain dalam skenario tertentu.

Periksa juga program BPF yang terpasang:

sudo bpftool prog show

Jika bpftool belum tersedia, instal paket yang sesuai dengan distribusi Linux.

Contoh Debian dan Ubuntu:

sudo apt install bpftool

Catatan: Jangan langsung menonaktifkan fitur TCP migration atau MPTCP tanpa memahami kebutuhan aplikasi. Perubahan tersebut dapat memengaruhi aplikasi yang menggunakan fitur jaringan khusus.

6. Memperbarui Kernel Linux untuk Menutup Kerentanan

Mitigasi utama

Solusi paling penting adalah memasang kernel yang telah mendapatkan perbaikan resmi.

Firewall, pembatasan port, dan konfigurasi tambahan hanya berfungsi mengurangi paparan serangan. Semuanya tidak menggantikan patch kernel.

6.1 Update kernel Debian 12 dan Debian 13

Perbarui informasi repository:

sudo apt update

Periksa paket yang dapat diperbarui:

apt list --upgradable

Lakukan pembaruan:

sudo apt full-upgrade

Periksa paket kernel yang terpasang:

dpkg -l | grep linux-image

Pastikan paket yang diterima merupakan paket yang telah diperbaiki berdasarkan Debian Security Tracker.

Untuk kernel Debian, jangan hanya membandingkan nomor versi dengan upstream. Debian dapat menerapkan perbaikan melalui revisi paket distribusinya.

6.2 Update kernel Ubuntu Server

Pada Ubuntu Server, jalankan:

sudo apt update
sudo apt upgrade

Jika pembaruan kernel tersedia melalui repository resmi:

sudo apt full-upgrade

Periksa status pembaruan keamanan:

ubuntu-security-status

Periksa informasi paket kernel:

apt-cache policy linux-image-generic

Ubuntu memiliki beberapa varian kernel, termasuk:

• Generic kernel.
• HWE kernel.
• AWS kernel.
• Azure kernel.
• GCP kernel.
• Oracle cloud kernel.

Setiap varian dapat memiliki jadwal pembaruan yang berbeda. Gunakan paket yang sesuai dengan platform dan advisory Ubuntu.

6.3 Update Rocky Linux, AlmaLinux, dan RHEL

Untuk sistem berbasis RPM:

sudo dnf check-update

Lakukan pembaruan:

sudo dnf upgrade --refresh

Periksa paket kernel:

rpm -qa | grep kernel

Periksa kernel default yang akan digunakan saat boot:

sudo grubby --default-kernel

Administrator RHEL dan turunannya harus memeriksa advisory keamanan masing-masing sebelum menyimpulkan bahwa sistem sudah terlindungi.

6.4 Update Amazon Linux 2023

Untuk Amazon Linux 2023:

sudo dnf update kernel --releasever=latest

Setelah paket berhasil diperbarui, lakukan reboot terencana.

sudo reboot

AWS telah menerbitkan informasi pembaruan kernel khusus CVE-2026-98432. Pada Amazon Linux 2023, administrator perlu memperhatikan jenis paket kernel dan versi yang dinyatakan sudah diperbaiki. Linux kernel IPv4 TCP use-after-free Issue

6.5 Mengapa reboot diperlukan?

Paket kernel yang sudah diperbarui tidak otomatis menggantikan kernel yang sedang berjalan.

Misalnya:

• Kernel aktif: versi lama.
• Kernel terpasang: versi terbaru.
• Server belum reboot: kernel lama masih aktif.

Untuk mengaktifkan kernel baru:

sudo reboot

Lakukan reboot melalui maintenance window, terutama pada server database, virtualisasi, Kubernetes, dan layanan produksi.

7. Memahami Versi Kernel Upstream yang Sudah Diperbaiki

Linux Kernel CVE Team telah mengumumkan perbaikan pada sejumlah cabang kernel.

Cabang kernel	Versi upstream fixed
5.10	5.10.272
5.15	5.15.223
6.1	6.1.190
6.6	6.6.159
6.12	6.12.113
6.18	6.18.56
7.2	7.2.10
7.3	Perbaikan tersedia pada 7.3-rc7

Sumber: Pengumuman Linux Kernel CVE Team. Git at Google+1

Versi di atas merupakan referensi upstream. Nomor tersebut bukan persyaratan universal untuk seluruh distribusi Linux.

Sebagai contoh, sebuah distribusi dapat menggunakan kernel dengan nomor versi dasar lebih rendah, tetapi sudah menyertakan perbaikan melalui mekanisme backport.

Karena itu, gunakan referensi berikut untuk pemeriksaan:

• Linux Kernel – Kernel.org
• Debian Security Tracker
• Ubuntu Security
• Red Hat Security Advisory
• AWS Security Bulletin
• Oracle Linux Security

8. Mitigasi Sementara Menggunakan Firewall

Mitigasi sementara

Bagaimana jika patch kernel belum tersedia?

Dalam kondisi tersebut, administrator perlu mengurangi permukaan serangan dengan membatasi lalu lintas jaringan yang tidak diperlukan.

Strategi yang dapat diterapkan:

1. Batasi koneksi TCP dari jaringan publik.
2. Gunakan firewall pada host dan perimeter.
3. Terapkan network segmentation.
4. Batasi akses database hanya dari application server.
5. Hindari mengekspos layanan internal ke internet.
6. Gunakan VPN untuk akses administratif.
7. Terapkan security group pada cloud infrastructure.

8.1 Mitigasi IP Options menggunakan nftables

Red Hat menyediakan contoh mitigasi untuk memblokir paket IPv4 TCP yang menggunakan IP header options. Red Hat Customer Portal

Buat file konfigurasi:

sudo nano /etc/nftables.d/cve-2026-98432.nft

Masukkan aturan berikut:

table inet cve_2026_98432 {
    chain input {
        type filter hook input priority -310;
        policy accept;

        ip protocol tcp ip hdrlength > 5 counter drop
    }
}

Penjelasan aturan:

• table inet: Membuat tabel firewall keluarga inet.
• chain input: Memproses paket yang menuju host.
• hook input: Menghubungkan chain dengan jalur input kernel.
• priority -310: Menentukan urutan pemrosesan firewall.
• ip protocol tcp: Memilih paket TCP IPv4.
• ip hdrlength > 5: Mendeteksi IP header yang memiliki panjang lebih dari lima unit 32-bit.
• counter drop: Menghitung dan membuang paket yang sesuai.

Panjang header IPv4 normal tanpa options adalah 20 byte atau lima unit 32-bit. Dengan demikian, aturan tersebut membuang paket TCP IPv4 yang membawa IP header options.

Validasi konfigurasi:

sudo nft --check --file \
/etc/nftables.d/cve-2026-98432.nft

Jika valid, terapkan:

sudo nft --file \
/etc/nftables.d/cve-2026-98432.nft

Periksa aturan:

sudo nft list table inet cve_2026_98432

Periksa counter:

sudo nft list chain inet \
cve_2026_98432 input

Perhatian: Aturan tersebut merupakan contoh mitigasi, bukan patch kernel. Aturan juga dapat memblokir lalu lintas sah yang membutuhkan IPv4 options. Uji terlebih dahulu pada lingkungan staging dan pastikan konfigurasi tidak mengganggu layanan jaringan.

Aturan di atas hanya memproses paket yang masuk melalui jalur input host. Jika server memiliki fungsi forwarding atau routing, evaluasi pula jalur lalu lintas yang relevan.

8.2 Menghapus aturan mitigasi setelah patch

Setelah administrator memastikan kernel sudah diperbaiki, aturan sementara dapat dihapus jika tidak lagi diperlukan.

sudo nft delete table inet cve_2026_98432

Pastikan konfigurasi permanen nftables juga tidak memuat aturan lama.

9. Mitigasi Tambahan: Menonaktifkan MPTCP

Pada server yang tidak menggunakan Multipath TCP, administrator dapat mempertimbangkan penonaktifan MPTCP sebagai tindakan defense-in-depth.

Periksa status:

sysctl net.mptcp.enabled

Nonaktifkan sementara:

sudo sysctl -w net.mptcp.enabled=0

Agar konfigurasi tetap berlaku setelah reboot, buat file:

sudo nano /etc/sysctl.d/99-disable-mptcp.conf

Masukkan:

net.mptcp.enabled = 0

Terapkan konfigurasi:

sudo sysctl --system

Verifikasi:

sysctl net.mptcp.enabled

Hasil yang diharapkan:

net.mptcp.enabled = 0

Namun, terdapat satu hal yang perlu dipahami.

Menonaktifkan MPTCP bukan solusi menyeluruh untuk CVE-2026-98432.

Kerentanan utama berada pada pemrosesan TCP IPv4. Penonaktifan MPTCP merupakan tindakan tambahan untuk mengurangi kondisi tertentu, bukan pengganti pembaruan kernel. Linux kernel IPv4 TCP use-after-free Issue+1

10. Hardening Linux Server Setelah Mitigasi

Memasang patch tidak berarti seluruh risiko keamanan server sudah hilang.

Administrator tetap perlu menerapkan hardening untuk mengurangi kemungkinan serangan terhadap layanan lain.

Area	Rekomendasi
Firewall	Default deny untuk koneksi yang tidak diperlukan
SSH	Gunakan SSH key authentication
Database	Jangan membuka port database ke internet
Network	Pisahkan jaringan server dan pengguna
Kernel	Gunakan security update terbaru
Monitoring	Pantau kernel panic dan anomali jaringan
Access Control	Terapkan least privilege
Backup	Siapkan backup dan prosedur pemulihan
Logging	Sentralisasikan log keamanan
Patch Management	Terapkan jadwal pembaruan berkala

10.1 Hardening SSH

Edit konfigurasi:

sudo nano /etc/ssh/sshd_config

Contoh pengaturan:

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no

Pengaturan harus disesuaikan dengan metode autentikasi yang digunakan.

Sebelum menerapkan perubahan, pastikan akses SSH menggunakan key sudah berfungsi agar administrator tidak kehilangan akses ke server.

Validasi:

sudo sshd -t

Kemudian reload:

sudo systemctl reload ssh

Pada sebagian distribusi, nama servicenya adalah sshd.

10.2 Hardening Database

Periksa alamat binding database.

Untuk MariaDB/MySQL, periksa konfigurasi:

bind-address = 127.0.0.1

Jika database perlu diakses oleh application server, gunakan alamat IP internal yang sesuai dan batasi akses menggunakan firewall.

Untuk PostgreSQL, periksa:

listen_addresses = 'localhost'

Jangan membuka port database ke seluruh jaringan publik tanpa kebutuhan yang jelas.

10.3 Network Segmentation

Pisahkan infrastruktur menjadi beberapa segmen jaringan:

• Management network.
• Application network.
• Database network.
• Monitoring network.
• User network.

Dengan segmentasi, akses antarkomponen dapat dikontrol berdasarkan kebutuhan.

Contohnya, database hanya menerima koneksi dari application server, sedangkan administrator mengakses server melalui management network atau VPN.

11. Monitoring dan Threat Hunting Linux Server

Setelah mitigasi diterapkan, administrator harus memastikan server tetap berjalan normal dan tidak menunjukkan indikasi gangguan.

Monitoring tidak hanya bertujuan menemukan serangan, tetapi juga mendeteksi dampak perubahan kernel terhadap infrastruktur.

11.1 Monitoring log kernel secara langsung

sudo journalctl -kf

Perintah tersebut menampilkan log kernel secara real-time.

Perhatikan pesan yang berhubungan dengan:

• Kernel panic.
• General protection fault.
• Use-after-free.
• Network stack error.
• TCP connection anomaly.
• Memory corruption.

11.2 Memeriksa log kernel sebelumnya

sudo dmesg -T | tail -100

Untuk melakukan pencarian pesan yang berkaitan dengan gangguan kernel:

sudo journalctl -k | grep -Ei \
'panic|oops|use.after.free|general protection fault'

11.3 Monitoring koneksi TCP

watch -n 2 'ss -s'

Perintah ini menampilkan statistik koneksi TCP secara berkala.

Untuk melihat koneksi berdasarkan status:

sudo ss -ant

11.4 Monitoring resource server

Instalasi htop:

sudo apt install htop

Jalankan:

htop

Periksa penggunaan resource lainnya:

uptime
free -h
df -h

11.5 Menggunakan centralized monitoring

Untuk infrastruktur dengan banyak server, monitoring manual tidak cukup.

Beberapa teknologi yang dapat digunakan:

Fichier:Prometheus software logo.svg – Wikisource

Prometheus

Mengumpulkan metrik sistem, penggunaan resource, dan kondisi server.

Cloud Infrastructure monitoring with Grafana Cloud | Grafana Labs

Grafana

Menyajikan dashboard visual untuk memantau kondisi seluruh infrastruktur.

Loki Setup – Wayne’s Substack

Loki

Mengumpulkan dan melakukan pencarian log dari banyak server.

Bringing AI to Wazuh SIEM: How MCP Server Enables Natural Language Security Queries | by Syed Jawad | Medium

Wazuh

Membantu mendeteksi aktivitas mencurigakan, memantau integritas sistem, dan melakukan security monitoring.

Untuk kebutuhan yang lebih kompleks, integrasikan sistem tersebut dengan SIEM agar administrator dapat melakukan korelasi peristiwa keamanan dari berbagai sumber.

Penting: Tidak ditemukannya pesan use-after-free atau kernel panic bukan bukti bahwa server sudah aman. Bukti utama mitigasi adalah paket kernel yang telah diperbaiki berdasarkan advisory vendor dan kernel tersebut sudah aktif digunakan.

12. Strategi Pencegahan untuk Infrastruktur Sekolah dan Perusahaan

Lingkungan sekolah, perusahaan, dan instansi pemerintah sering memiliki banyak server yang menjalankan layanan berbeda.

Contohnya:

• Server website.
• Server aplikasi akademik.
• Server database.
• Server file sharing.
• Server virtualisasi.
• Server monitoring.
• Server container dan Kubernetes.
• Server autentikasi dan manajemen jaringan.

Jika pembaruan keamanan hanya dilakukan pada satu server, masih terdapat kemungkinan server lain menggunakan kernel yang rentan.

Oleh karena itu, diperlukan kebijakan pengelolaan keamanan kernel secara menyeluruh.

12.1 Inventarisasi seluruh server

Buat daftar seluruh server Linux beserta informasi berikut:

Informasi	Contoh
Hostname	web-server-01
OS	Debian 13
Kernel	6.12.x
IP Address	192.168.10.10
Fungsi	Web Server
Internet-facing	Ya
Status patch	Perlu verifikasi
Maintenance	Terjadwal

Inventarisasi dapat dilakukan menggunakan Ansible agar pemeriksaan banyak server lebih mudah.

12.2 Prioritaskan server berdasarkan tingkat risiko

Urutan prioritas mitigasi yang disarankan:

1. Server dengan port TCP yang dapat diakses langsung dari internet.
2. Server aplikasi dan database yang bersifat kritis.
3. Server virtualisasi dan container host.
4. Server internal dengan akses jaringan luas.
5. Server pengujian dan development.

Prioritas tersebut merupakan strategi operasional berdasarkan paparan dan dampak bisnis, bukan klasifikasi resmi tingkat kerentanan.

12.3 Terapkan patch management terjadwal

Buat kebijakan pembaruan keamanan yang jelas.

Contoh:

Aktivitas	Frekuensi
Pemeriksaan security advisory	Harian
Inventarisasi kernel	Mingguan
Evaluasi patch kritis	Segera
Pengujian patch	Sebelum produksi
Update server	Sesuai risiko dan maintenance
Audit keamanan	Bulanan

Untuk kerentanan Critical yang dapat dieksploitasi melalui jaringan, jangan menunggu jadwal update bulanan jika patch resmi sudah tersedia dan dapat diterapkan dengan aman.

12.4 Terapkan pengujian sebelum produksi

Sebelum memperbarui server produksi:

1. Siapkan server staging.
2. Pasang kernel terbaru.
3. Reboot sistem.
4. Uji aplikasi.
5. Uji koneksi jaringan.
6. Periksa database dan layanan.
7. Pastikan monitoring normal.
8. Dokumentasikan hasil pengujian.

Langkah ini membantu mencegah gangguan akibat ketidakcocokan kernel, driver, atau modul pihak ketiga.

12.5 Perhatikan lingkungan virtualisasi dan container

Administrator harus memahami perbedaan perlindungan kernel pada virtual machine dan container.

Containers vs Virtual Machines: The Kernel-Level Truth Every Engineer Must Understand | by Dr. Fadi Shaar | TechSync | Medium

medium.com

Virtual Machine (VM)

Setiap VM umumnya memiliki kernel sendiri. Karena itu, pembaruan kernel host tidak otomatis memperbarui kernel guest.

Container

Container biasa berbagi kernel host. Oleh karena itu, memperbarui image container tidak otomatis memperbaiki kerentanan kernel host.

Contoh lingkungan yang perlu diperiksa:

• Proxmox VE.
• Docker.
• Kubernetes.
• RKE2.
• Containerd.
• OpenShift.

Untuk Kubernetes, jangan hanya memeriksa container image. Periksa juga kernel pada seluruh worker node dan control-plane node yang menjalankan workload Linux.

Jika menggunakan Proxmox, periksa kernel hypervisor dan kernel setiap guest VM secara terpisah.

12.6 Siapkan backup dan prosedur recovery

Sebelum melakukan pembaruan kernel pada sistem kritis:

• Pastikan backup database tersedia.
• Pastikan konfigurasi sistem tersimpan.
• Pastikan snapshot VM tersedia jika sesuai.
• Siapkan kernel sebelumnya sebagai opsi boot pemulihan.
• Dokumentasikan prosedur rollback.
• Pastikan akses console atau out-of-band management tersedia.

Snapshot bukan pengganti backup. Keduanya memiliki fungsi dan karakteristik pemulihan yang berbeda.

13. Tutorial Step-by-Step: Mengamankan Debian atau Ubuntu Server

Bagian ini merupakan contoh implementasi praktis untuk administrator yang ingin melakukan pemeriksaan dan mitigasi secara berurutan.

Praktik langsung

Langkah 1. Identifikasi sistem operasi

cat /etc/os-release

Langkah 2. Catat kernel yang aktif

uname -r

Simpan hasilnya untuk dokumentasi sebelum pembaruan.

Langkah 3. Periksa paket kernel

dpkg -l | grep linux-image

Langkah 4. Periksa layanan TCP

sudo ss -lntp

Identifikasi layanan yang menerima koneksi dari jaringan publik.

Langkah 5. Periksa status MPTCP

sysctl net.mptcp.enabled

Langkah 6. Periksa security advisory

Buka Debian Security Tracker atau Ubuntu Security untuk memeriksa status CVE-2026-98432 sesuai distribusi dan paket yang digunakan.

Jangan berasumsi bahwa apt full-upgrade otomatis memasang perbaikan jika vendor belum menerbitkannya.

Langkah 7. Perbarui paket

Jika perbaikan tersedia:

sudo apt update
sudo apt full-upgrade

Langkah 8. Periksa kernel baru

ls -lh /boot/vmlinuz-*

Pastikan kernel yang telah diperbaiki benar-benar terpasang.

Langkah 9. Jadwalkan reboot

sudo reboot

Lakukan setelah memastikan layanan siap menghadapi maintenance.

Langkah 10. Verifikasi kernel aktif

uname -r

Bandingkan hasilnya dengan versi paket yang telah dinyatakan fixed oleh vendor.

Langkah 11. Periksa layanan

systemctl --failed

Kemudian:

sudo ss -lntp

Pastikan layanan penting kembali berjalan dan port yang diperlukan tersedia.

Langkah 12. Periksa log kernel

sudo journalctl -k -b

Periksa apakah terdapat error yang muncul setelah reboot.

Langkah 13. Dokumentasikan hasil

Catat:

• Versi kernel sebelum patch.
• Versi kernel setelah patch.
• Paket keamanan yang dipasang.
• Waktu maintenance.
• Status layanan.
• Hasil pengujian aplikasi.
• Status akhir mitigasi.

14. Kesalahan yang Sering Terjadi Saat Mitigasi

Beberapa kesalahan berikut dapat menyebabkan administrator merasa server sudah aman, padahal proses mitigasi belum selesai.

14.1 Hanya memeriksa versi kernel

Penyebab: Administrator menggunakan uname -r sebagai satu-satunya indikator keamanan.

Dampak: Status patch dapat disimpulkan secara keliru karena mekanisme backport distribusi.

Solusi: Periksa advisory vendor dan versi paket yang telah diperbaiki.

14.2 Menganggap update paket otomatis mengaktifkan kernel baru

Penyebab: Administrator tidak melakukan reboot setelah pembaruan kernel.

Dampak: Server masih menggunakan kernel lama yang berjalan di memori.

Solusi: Jadwalkan reboot dan verifikasi menggunakan uname -r.

14.3 Menganggap firewall sebagai solusi permanen

Penyebab: Administrator hanya membatasi koneksi tanpa memasang patch.

Dampak: Kerentanan tetap berada di dalam kernel.

Solusi: Gunakan firewall sebagai mitigasi sementara dan tetap prioritaskan kernel yang telah diperbaiki.

14.4 Menonaktifkan MPTCP tanpa analisis

Penyebab: Menganggap MPTCP sebagai satu-satunya penyebab kerentanan.

Dampak: Aplikasi yang membutuhkan Multipath TCP dapat mengalami gangguan.

Solusi: Periksa ketergantungan aplikasi dan pahami bahwa MPTCP bukan akar seluruh kerentanan.

14.5 Hanya memperbarui container image

Penyebab: Administrator menganggap container memiliki kernel sendiri.

Dampak: Kernel host yang rentan tetap digunakan oleh container.

Solusi: Periksa dan perbarui kernel host serta seluruh VM yang relevan.

14.6 Tidak melakukan pengujian setelah reboot

Penyebab: Proses mitigasi dianggap selesai setelah server menyala kembali.

Dampak: Layanan dapat gagal berjalan atau mengalami perubahan perilaku.

Solusi: Periksa service, koneksi TCP, database, monitoring, dan aplikasi.

15. Tips Profesional untuk Administrator Linux

Berikut rekomendasi tambahan untuk membangun sistem pengelolaan keamanan yang lebih matang.

Pertama, gunakan konfigurasi firewall berlapis. Kombinasikan host firewall, network firewall, dan cloud security group. Hindari mengandalkan satu lapisan perlindungan.

Kedua, gunakan automation. Ansible dapat digunakan untuk menginventarisasi kernel, memeriksa paket, mengumpulkan status service, dan menjalankan pemeriksaan pascapembaruan.

Ketiga, pisahkan jaringan manajemen. Akses administratif sebaiknya hanya tersedia melalui VPN atau jaringan manajemen khusus.

Keempat, terapkan patch management terpusat. Pastikan setiap server memiliki jadwal pembaruan dan mekanisme pelaporan.

Kelima, integrasikan monitoring dan alerting. Gunakan Prometheus, Grafana, Loki, dan Wazuh untuk membangun visibilitas infrastruktur.

Keenam, dokumentasikan perubahan. Setiap pembaruan kernel harus memiliki catatan versi, waktu pelaksanaan, pengujian, dan hasil akhir.

Ketujuh, siapkan pemulihan. Pastikan administrator dapat melakukan recovery apabila pembaruan menyebabkan gangguan.

17. Kesimpulan

CVE-2026-98432 merupakan kerentanan serius pada subsistem IPv4 TCP Linux Kernel yang berkaitan dengan race condition dan Use-After-Free.

Kerentanan ini menunjukkan bahwa keamanan server tidak cukup hanya mengandalkan firewall, autentikasi SSH, atau pembaruan aplikasi. Kernel sebagai fondasi sistem operasi juga harus menjadi bagian utama dari strategi keamanan infrastruktur.

Ada beberapa hal penting yang perlu diingat:

1. Inventarisasi seluruh server Linux yang digunakan.
2. Periksa status kerentanan melalui advisory resmi masing-masing vendor.
3. Identifikasi layanan TCP yang dapat diakses dari jaringan publik.
4. Gunakan firewall sebagai lapisan mitigasi sementara.
5. Jangan menganggap penonaktifan MPTCP sebagai solusi menyeluruh.
6. Pasang kernel security update yang telah diperbaiki.
7. Lakukan reboot untuk mengaktifkan kernel baru.
8. Verifikasi kernel aktif dan kondisi layanan setelah pembaruan.
9. Terapkan monitoring, patch management, backup, dan prosedur recovery.
10. Periksa kernel host virtualisasi dan seluruh sistem guest secara terpisah.

Rekomendasi utama: Jangan menunda pembaruan kernel pada server yang terdampak. Jika patch resmi belum tersedia, kurangi paparan jaringan, terapkan mitigasi yang direkomendasikan vendor, dan pantau perkembangan security advisory secara berkala.

Dengan pendekatan tersebut, administrator dapat mengurangi risiko serangan sekaligus membangun infrastruktur Linux yang lebih tangguh, terukur, dan mudah dikelola.

Frequently Asked Questions (FAQ)

Pertanyaan: Apa itu CVE-2026-98432?

Jawaban: CVE-2026-98432 adalah kerentanan Use-After-Free pada subsistem jaringan IPv4 TCP Linux Kernel yang disebabkan oleh race condition ketika kernel memproses permintaan koneksi TCP secara bersamaan.

Pertanyaan: Seberapa berbahaya CVE-2026-98432?

Jawaban: Linux Kernel CVE Team memberikan skor CVSS 3.1 sebesar 9.8 atau Critical. Dampaknya dapat berupa Denial of Service, memory corruption, dan potensi Remote Code Execution pada kondisi tertentu.

Pertanyaan: Apakah semua distribusi Linux terdampak?

Jawaban: Kerentanan diperkenalkan pada upstream kernel sejak versi 4.4. Namun, status setiap distribusi bergantung pada kernel, paket, dan patch backport yang digunakan. Periksa advisory resmi vendor.

Pertanyaan: Bagaimana cara mengetahui Linux Server terdampak CVE-2026-98432?

Jawaban: Periksa distribusi menggunakan cat /etc/os-release, versi kernel menggunakan uname -r, dan status perbaikan melalui security advisory distribusi Linux yang digunakan.

Pertanyaan: Apakah menjalankan apt upgrade sudah cukup untuk mengatasi kerentanan ini?

Jawaban: Belum tentu. Perintah tersebut hanya memasang pembaruan yang tersedia di repository. Pastikan paket kernel sudah mengandung perbaikan CVE dan lakukan reboot agar kernel baru aktif.

Pertanyaan: Apakah menonaktifkan MPTCP dapat memperbaiki CVE-2026-98432?

Jawaban: Tidak sepenuhnya. Penonaktifan MPTCP merupakan mitigasi tambahan untuk mengurangi kondisi tertentu, bukan pengganti patch kernel.

Pertanyaan: Apakah firewall dapat mencegah eksploitasi CVE-2026-98432?

Jawaban: Firewall dapat mengurangi paparan serangan dengan membatasi lalu lintas tertentu. Namun, firewall bukan perbaikan permanen terhadap kerentanan kernel.

Pertanyaan: Apakah server Debian dan Ubuntu harus melakukan reboot setelah update kernel?

Jawaban: Ya. Reboot diperlukan agar sistem menggunakan kernel baru yang telah diperbaiki, kecuali administrator menggunakan mekanisme live patch yang secara resmi mendukung perbaikan tersebut.

Pertanyaan: Apakah Docker dan Kubernetes juga terdampak?

Jawaban: Container biasa menggunakan kernel host. Oleh karena itu, kernel host harus diperbarui. Pada Kubernetes, administrator perlu memeriksa seluruh node yang menjalankan workload Linux.

Pertanyaan: Bagaimana cara memastikan server sudah aman?

Jawaban: Pastikan paket kernel telah dinyatakan fixed oleh vendor, kernel yang diperbaiki sudah aktif, layanan berjalan normal, firewall sesuai kebutuhan, dan monitoring tidak menunjukkan gangguan baru.

🔐 LINUX SERVER SECURITY ALERT!

CVE-2026-98432 menjadi pengingat bahwa keamanan server tidak cukup hanya dengan memasang firewall dan mengamankan SSH. Kernel Linux juga harus mendapatkan perhatian serius.

Dalam artikel ini kita telah membahas:
✅ Identifikasi Linux Server terdampak.
✅ Pemeriksaan versi kernel dan layanan TCP.
✅ Mitigasi menggunakan nftables.
✅ Hardening Linux Server.
✅ Pembaruan kernel dan verifikasi patch.
✅ Monitoring dan Threat Hunting.
✅ Strategi pencegahan untuk infrastruktur sekolah dan perusahaan.

💡 Pertanyaan untuk administrator Linux:

Apakah seluruh Linux Server yang Anda kelola sudah diperiksa terhadap CVE-2026-98432?

Bagikan pengalaman, konfigurasi, atau kendala mitigasi yang Anda temukan melalui kolom komentar.

Jangan lupa bagikan artikel ini kepada sesama Sysadmin, Network Administrator, DevOps Engineer, dan praktisi IT agar semakin banyak administrator memahami pentingnya keamanan kernel Linux.