Mengapa autentikasi kata sandi harus dinonaktifkan dan diganti dengan kunci SSH?

Kunci SSH secara kriptografis kebal terhadap brute-force — kunci RSA 2048-bit memiliki lebih banyak kombinasi yang mungkin daripada atom di alam semesta yang dapat diamati. Autentikasi kata sandi melawan penyerang yang menggunakan botnet terdistribusi adalah pertarungan yang tidak akan menang. Menonaktifkan keduanya, bersama login root, adalah baseline minimum yang direkomendasikan oleh CIS Benchmark untuk Ubuntu.

Apa urutan yang benar saat mengganti port SSH dan mengatur UFW agar tidak terkunci dari server?

Anda harus menambahkan aturan port SSH baru ke UFW terlebih dahulu (misalnya ufw allow 2222/tcp), mengaktifkan UFW, dan baru kemudian mengubah port di sshd_config lalu reload SSH. Melakukannya di luar urutan — mengaktifkan firewall sebelum mengizinkan port baru — akan memblokir koneksi SSH Anda sendiri dan mengharuskan pembukaan sesi konsol DigitalOcean untuk pemulihan.

Haruskah perubahan hardening langsung diterapkan ke server produksi?

Tidak — selalu uji perubahan hardening di lingkungan staging yang mencerminkan produksi terlebih dahulu. Menerapkan hardening CIS Level 2 langsung ke server NestJS produksi tanpa pengujian pernah menonaktifkan fitur kernel yang diandalkan runtime Node.js untuk performa, menyebabkan crash intermiten di bawah beban. Gunakan CIS-CAT atau Lynis setelah menerapkan perubahan untuk mengaudit apa yang sebenarnya telah di-hardening.

Apa yang harus dilakukan di luar hardening SSH dan aturan firewall untuk mengurangi attack surface?

Terapkan hardening tingkat kernel via /etc/sysctl.conf (nonaktifkan IP forwarding, aktifkan SYN cookies, atur ASLR dengan kernel.randomize_va_space=2), instal dan konfigurasikan fail2ban untuk pemblokiran IP otomatis, serta hapus paket yang tidak diperlukan dan nonaktifkan layanan yang tidak perlu. Untuk deteksi intrusi yang lebih dalam, pertimbangkan OSSEC atau Wazuh untuk pemantauan integritas file, dan auditd untuk audit logging tingkat kernel di lingkungan yang memerlukan kepatuhan.

Checklist Hardening Server Linux untuk VPS Baru

Checklist Hardening Server Linux: Yang Saya Lakukan di Setiap VPS Baru

Checklist hardening server Linux praktis yang mencakup penguncian SSH, aturan firewall, pembaruan otomatis, dan fail2ban — langkah-langkah yang saya terapkan di setiap instance DigitalOcean dan GCP.

Matthews Wong

Software Engineer

Juni 202512 menit baca

DevOps

Server Linux yang menghadap internet rata-rata menerima ratusan upaya brute-force SSH setiap hari. Dalam hitungan menit setelah menyediakan DigitalOcean Droplet baru, bot sudah mulai memindai port 22. Server dengan kata sandi root yang lemah rutin dikompromikan tidak lama setelah online. Karena itu, saya menjalankan checklist hardening yang sama di setiap server baru sebelum men-deploy aplikasi apa pun.

Langkah 1: Amankan Akses SSH

SSH adalah pintu depan setiap server Linux dan target nilai tertinggi bagi penyerang. CIS Benchmark untuk Ubuntu merekomendasikan menonaktifkan login root, menonaktifkan autentikasi kata sandi, dan menggunakan pasangan kunci SSH sebagai baseline minimum. Kunci SSH secara kriptografis kebal terhadap brute-force — kunci RSA 2048-bit memiliki lebih banyak kombinasi yang mungkin daripada atom di alam semesta yang dapat diamati.

Hardening Konfigurasi SSH

Edit /etc/ssh/sshd_config dengan pengaturan kritis ini: PermitRootLogin no, PasswordAuthentication no, MaxAuthTries 3, PubkeyAuthentication yes, X11Forwarding no, AllowTcpForwarding no (kecuali diperlukan), dan ubah port dari 22 ke port non-standar (misalnya 2222) untuk mengurangi kebisingan pemindaian otomatis. Setelah membuat perubahan, selalu uji konfigurasi baru dengan sshd -t sebelum reload.

Firewall dengan UFW

UFW (Uncomplicated Firewall) adalah alat yang tepat untuk manajemen firewall VPS yang mudah. Mulai dengan kebijakan default-deny-all-incoming, lalu masukkan daftar putih hanya yang Anda butuhkan: port SSH Anda, HTTP (80), dan HTTPS (443). Jangan pernah membuka port database (5432, 3306, 6379) ke internet publik — database hanya boleh dapat dijangkau di antarmuka loopback atau jaringan privat.

┌─────────────────────────────────────────────────────┐
│             LINUX SERVER HARDENING LAYERS           │
├─────────────────────────────────────────────────────┤
│  [1] Cloud Firewall   — Block before it hits VPS    │
│  [2] UFW              — Host-level packet filter    │
│  [3] SSH Hardening    — Key-only, non-standard port │
│  [4] Fail2ban         — Auto-ban brute-forcers      │
│  [5] Unattended-upgrades — Auto security patches    │
│  [6] Kernel sysctl    — SYN cookies, ASLR           │
│  [7] Audit (Lynis)    — Verify what you hardened    │
└─────────────────────────────────────────────────────┘

Dari pengalaman saya mengamankan server di Jakarta dengan bandwidth admin yang terbatas, siapkan UFW sebelum mengubah port SSH Anda. Urutan penting: tambahkan aturan port SSH baru (ufw allow 2222/tcp), aktifkan UFW, lalu ubah port sshd_config dan reload SSH. Melakukannya di luar urutan telah mengunci saya sebanyak dua kali — Anda akhirnya membuka sesi konsol DigitalOcean untuk memperbaikinya.

Langkah 2: Pembaruan Keamanan Otomatis

Paket yang tidak ditambal bertanggung jawab atas sebagian besar kompromi server. Di Ubuntu/Debian, unattended-upgrades menangani pembaruan keamanan otomatis tanpa intervensi manual. Instal, aktifkan reboot otomatis selama jendela traffic rendah, dan konfigurasikan notifikasi email untuk kejadian reboot. Unit Riset Ancaman Qualys menemukan bahwa 60% pelanggaran melibatkan kerentanan yang tersedia patch-nya namun tidak diterapkan.

Hardening Tingkat Sistem

Di luar SSH dan firewall, terapkan hardening tingkat kernel via /etc/sysctl.conf: nonaktifkan IP forwarding (kecuali ini adalah router), aktifkan SYN cookies untuk mencegah serangan SYN flood, atur kernel.randomize_va_space=2 untuk ASLR, dan batasi core dump. Instal dan konfigurasikan fail2ban untuk pemblokiran IP otomatis pada kegagalan autentikasi berulang.

# SSH hardening — /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
X11Forwarding no
AllowTcpForwarding no
Port 2222

# UFW setup
ufw default deny incoming
ufw default allow outgoing
ufw allow 2222/tcp    # SSH (new port)
ufw allow 80/tcp      # HTTP
ufw allow 443/tcp     # HTTPS
ufw enable

# Kernel hardening — /etc/sysctl.conf
net.ipv4.tcp_syncookies = 1
kernel.randomize_va_space = 2
net.ipv4.conf.all.rp_filter = 1
fs.suid_dumpable = 0

Langkah 3: Deteksi Intrusi

Fail2ban adalah deteksi intrusi minimum yang layak untuk VPS. Ia memantau file log dan melarang IP yang melebihi ambang kegagalan. Di luar fail2ban, pertimbangkan menginstal OSSEC atau Wazuh untuk pemantauan integritas file — mereka memberi tahu Anda ketika file sistem kritis berubah, yang merupakan sinyal kuat dari kompromi.

Saya pernah menerapkan hardening CIS Level 2 ke server NestJS produksi tanpa mengujinya terlebih dahulu — ia menonaktifkan fitur kernel yang diandalkan runtime Node.js untuk performa, menyebabkan crash intermiten di bawah beban. Selalu uji perubahan hardening di lingkungan staging yang mencerminkan produksi. Jalankan CIS-CAT atau Lynis setelah menerapkan perubahan untuk mengaudit apa yang sebenarnya Anda hardening.

Langkah 4: Manajemen Pengguna dan Izin

Jangan pernah menjalankan beban kerja aplikasi sebagai root. Buat pengguna sistem khusus untuk setiap layanan (misalnya www-data untuk Nginx, nestjs untuk aplikasi Node.js Anda) dengan izin minimal. Gunakan sudo untuk eskalasi hak istimewa dan konfigurasikan /etc/sudoers dengan hati-hati — catat semua perintah sudo. Audit pengguna yang ada secara berkala dengan getent passwd.

Skrip Hardening Produksi Saya

Saya memelihara skrip bash yang menjalankan semua langkah ini secara idempoten — saya bisa menjalankannya di server baru atau menjalankan ulang di server yang sudah ada tanpa merusak apa pun. Skrip ini mengatur konfigurasi SSH, mengonfigurasi UFW, menginstal dan mengonfigurasi fail2ban, mengaktifkan unattended-upgrades, menerapkan hardening sysctl, dan menghapus paket yang tidak diperlukan.