Cara hardening server Linux dimulai dari mematikan yang tidak perlu dan mengunci yang perlu: nonaktifkan login root dan autentikasi kata sandi pada SSH, pakai kunci SSH, tutup semua port kecuali yang dipakai, pasang fail2ban, aktifkan pembaruan keamanan otomatis, dan pantau log secara terpusat.
Server baru yang terhubung ke internet akan menerima upaya masuk paksa dalam hitungan menit. Pemindai otomatis bekerja sepanjang waktu, mencoba kombinasi pengguna dan kata sandi yang umum pada setiap alamat IP yang mereka temukan.
Dua belas langkah berikut adalah dasar yang seharusnya dikerjakan sebelum server dipakai untuk apa pun. Semuanya bisa diselesaikan dalam satu hingga dua jam, dan menutup sebagian besar celah yang paling sering dieksploitasi.
Mengamankan akses masuk (langkah 1–4)
SSH adalah pintu utama server Anda dan sekaligus sasaran paling sering. Empat langkah berikut menutup hampir seluruh upaya masuk paksa:
- 1. Buat pengguna biasa dengan hak sudo, lalu nonaktifkan login root secara langsung.
- 2. Gunakan autentikasi berbasis kunci SSH dan matikan autentikasi kata sandi sepenuhnya.
- 3. Batasi pengguna yang boleh masuk melalui SSH memakai direktif AllowUsers.
- 4. Pasang fail2ban untuk memblokir alamat IP yang berulang kali gagal masuk.
Mengurangi permukaan serangan (langkah 5–8)
Setiap layanan yang berjalan adalah pintu tambahan. Semakin sedikit yang menyala, semakin sedikit pula yang perlu dijaga:
- 5. Tutup semua port dengan firewall, lalu buka hanya yang benar-benar dipakai.
- 6. Matikan dan hapus layanan yang tidak digunakan — periksa daftar layanan aktif satu per satu.
- 7. Pastikan basis data hanya mendengarkan pada alamat lokal bila tidak diakses dari luar.
- 8. Jalankan setiap layanan dengan pengguna khusus, bukan dengan hak root.
Menjaga sistem tetap mutakhir dan terpantau (langkah 9–12)
Hardening bukan pekerjaan sekali jalan. Empat langkah terakhir memastikan keamanan tetap terjaga seiring waktu:
- 9. Aktifkan pembaruan keamanan otomatis untuk paket sistem.
- 10. Kirim log ke penyimpanan terpusat agar tidak ikut hilang bila server disusupi.
- 11. Pasang pemantauan integritas berkas untuk mendeteksi perubahan pada berkas sistem penting.
- 12. Jadwalkan pemindaian kerentanan berkala dan tindak lanjuti temuannya berdasarkan prioritas.
Menyimpan konfigurasi agar bisa diulang
Setelah selesai melakukan hardening pada satu server, jangan biarkan pengetahuannya hanya ada di kepala. Tuliskan seluruh langkah sebagai skrip atau playbook Ansible.
Dengan begitu, server berikutnya bisa diamankan dengan standar yang persis sama hanya dengan satu perintah — dan bila ada pengetatan baru, ia bisa diterapkan serentak ke seluruh server tanpa ada yang terlewat.
Keamanan server Linux: apa yang benar-benar menentukan
Pembicaraan tentang keamanan server Linux sering terjebak pada perkakas — pemindai mana yang dipakai, firewall mana yang lebih baik. Dalam praktiknya, yang menentukan justru tiga hal yang jauh lebih membosankan: siapa yang punya akses, seberapa cepat tambalan dipasang, dan apakah ada yang memperhatikan log.
Sebagian besar peretasan server memanfaatkan kerentanan yang tambalannya sudah tersedia berbulan-bulan, atau kredensial yang bocor dari tempat lain. Keduanya tidak diselesaikan dengan menambah perangkat lunak keamanan.
Karena itu urutan yang kami pakai selalu dimulai dari akses dan pembaruan. Lapisan deteksi datang setelahnya — bukan karena kurang penting, tapi karena mendeteksi serangan pada server yang pintunya masih terbuka lebar tidak banyak menolong.
Konfigurasi SSH aman langkah demi langkah
Untuk konfigurasi SSH aman, empat perubahan di `/etc/ssh/sshd_config` sudah menutup hampir seluruh upaya masuk paksa: `PermitRootLogin no`, `PasswordAuthentication no`, `PubkeyAuthentication yes`, dan `AllowUsers` yang membatasi siapa saja yang boleh masuk.
Sebelum menerapkan yang kedua, pastikan kunci publik Anda sudah terpasang dan sudah diuji pada sesi terpisah. Menonaktifkan autentikasi kata sandi sambil belum punya kunci yang berfungsi adalah cara tercepat mengunci diri sendiri di luar server.
Menggeser port SSH dari 22 sering disarankan, tetapi manfaatnya terbatas: ia mengurangi kebisingan log, bukan menghentikan pemindai yang serius. Kalau ingin dampak nyata, batasi akses SSH hanya dari alamat kantor atau lewat VPN.
Setting firewall UFW yang benar urutannya
Pada Ubuntu dan Debian, setting firewall UFW paling mudah dimulai dari kebijakan bawaan: `ufw default deny incoming` dan `ufw default allow outgoing`. Baru setelah itu port yang dipakai dibuka satu per satu.
Urutan ini penting dan sering dibalik. Kalau kebijakan bawaan dibiarkan mengizinkan lalu hanya beberapa port ditutup, satu layanan baru yang dipasang bulan depan akan langsung terbuka ke internet tanpa ada yang menyadari.
Jangan lupa membuka SSH sebelum mengaktifkan UFW pada server jarak jauh — `ufw allow OpenSSH` lalu `ufw enable`. Terbalik urutannya, sesi Anda terputus dan server hanya bisa dijangkau lewat konsol penyedia.
Untuk basis data dan layanan internal, batasi per sumber alih-alih membuka port: `ufw allow from 10.0.0.0/24 to any port 3306` jauh lebih aman daripada membuka 3306 ke semua alamat.
Fail2ban tutorial singkat dan ambang yang wajar
Sebagai fail2ban tutorial ringkas: setelah dipasang, buat berkas `jail.local` alih-alih mengubah `jail.conf` agar konfigurasi Anda tidak tertimpa saat pembaruan. Aktifkan jail untuk SSH lebih dulu, lalu tambahkan untuk layanan lain yang punya halaman login.
Tiga parameter yang menentukan perilakunya: `maxretry` berapa kali gagal sebelum diblokir, `findtime` rentang waktu perhitungannya, dan `bantime` lama pemblokiran. Ambang yang terlalu ketat berisiko memblokir seluruh kantor pelanggan Anda yang berbagi satu alamat IP publik.
Karena itu masukkan alamat IP kantor dan kantor pelanggan penting ke `ignoreip`. Dan periksa `fail2ban-client status` beberapa hari setelah pemasangan — daftar alamat yang terblokir akan menunjukkan apakah ambangnya masuk akal.
Audit log server Linux dan apa yang dicari
Pekerjaan audit log server Linux tidak berarti membaca semuanya. Yang dicari beberapa pola saja: login berhasil dari alamat atau jam yang tidak biasa, penggunaan `sudo` oleh akun yang seharusnya tidak, layanan yang restart tanpa dijadwalkan, dan lonjakan lalu lintas keluar yang tidak wajar.
Yang paling penting justru bukan isi lognya, tapi di mana ia disimpan. Log yang hanya ada di server itu sendiri akan ikut dihapus oleh penyerang yang berhasil masuk. Karena itu log dikirim ke penyimpanan terpusat di luar server, dan di sana ia tidak bisa dihapus dari sisi server sumber.
Ditambah pemantauan integritas berkas pada direktori sistem. Munculnya berkas baru di `/usr/bin` atau perubahan pada berkas konfigurasi layanan adalah penanda yang jauh lebih cepat daripada menunggu gejala terlihat oleh pengguna.
Satu hal terakhir yang murah tapi sering dilewatkan: sinkronkan waktu server dengan NTP. Log dari beberapa server yang jamnya bergeser beberapa menit membuat penelusuran urutan kejadian jauh lebih sulit daripada seharusnya.