Server Linux yang baru selesai diinstal biasanya masih cukup “polos”. Bisa dipakai, memang, tapi belum tentu siap dihadapkan ke internet atau dipakai menampung layanan penting. Hardening tidak harus langsung rumit; mulai dari hal-hal yang paling sering jadi pintu masuk masalah.

1. Update sistem sebelum memasang banyak layanan

Jangan menunda update hanya karena server baru dibuat. Paket bawaan image, ISO, atau template VM sering tertinggal beberapa patch keamanan.

sudo apt update && sudo apt upgrade -y
RHEL, Rocky, AlmaLinux
sudo dnf upgrade -y

Kapan dipakai: langsung setelah provisioning, lalu jadwalkan patch rutin. Untuk server produksi, cek dulu changelog dan lakukan di maintenance window jika update menyentuh kernel atau database.

2. Buat akun admin terpisah, lalu hindari login root langsung

Login root via SSH membuat audit jadi kabur dan brute-force lebih menarik bagi bot. Buat user admin biasa, beri akses sudo seperlunya, lalu nonaktifkan akses root dari SSH.

sudo adduser denrama-admin
sudo usermod -aG sudo denrama-admin

Edit /etc/ssh/sshd_config, lalu set PermitRootLogin no. Jangan tutup sesi SSH lama sebelum mencoba login dengan akun baru. Ini kesalahan kecil yang cukup sering bikin orang terkunci dari server sendiri.

Kapan dipakai: hampir selalu, terutama server yang punya IP publik.

3. Gunakan SSH key dan matikan password authentication

Password tetap bisa ditebak, bocor, atau dipakai ulang dari layanan lain. SSH key jauh lebih masuk akal untuk akses admin sehari-hari.

ssh-keygen -t ed25519 -C "admin@laptop"
ssh-copy-id denrama-admin@ip-server

Setelah key terbukti berfungsi, ubah konfigurasi SSH:

PasswordAuthentication no
PubkeyAuthentication yes

Reload layanan dengan sudo systemctl reload ssh atau sshd, tergantung distro.

Kapan dipakai: wajib untuk server internet-facing. Jika ada tim yang masih memakai password, rapikan proses distribusi key dulu sebelum mematikannya.

4. Batasi akses SSH dengan firewall

Firewall bukan pengganti keamanan aplikasi, tapi tetap lapisan dasar yang wajib ada. Prinsipnya sederhana: buka hanya port yang memang dipakai.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80,443/tcp
sudo ufw enable

Kalau IP kantor atau VPN sudah tetap, lebih baik batasi SSH ke sumber tersebut saja. Misalnya, jangan biarkan port 22 terbuka untuk seluruh internet jika tidak perlu.

Kapan dipakai: setiap server. Untuk cloud, kombinasikan dengan security group atau firewall dari provider, jangan hanya mengandalkan salah satunya.

5. Pasang Fail2ban untuk meredam percobaan login berulang

Bot akan tetap mencoba SSH, WordPress, panel admin, dan endpoint lain yang terlihat umum. Fail2ban membantu memblokir IP yang terlalu sering gagal login.

sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Mulai dari jail SSH bawaan, lalu tambah aturan untuk Nginx, Postfix, atau aplikasi lain jika log-nya jelas dan konsisten. Jangan terlalu agresif; salah konfigurasi bisa memblokir IP tim sendiri.

Kapan dipakai: berguna pada server dengan akses SSH publik atau layanan autentikasi yang sering diserang brute-force.

6. Kurangi service yang tidak diperlukan

Setiap service aktif menambah permukaan serangan dan pekerjaan patching. Cek dulu apa saja yang sedang mendengarkan port.

sudo ss -tulpn
sudo systemctl --type=service --state=running

Jika ternyata ada layanan yang tidak dipakai, nonaktifkan dengan sadar, misalnya:

sudo systemctl disable --now apache2

Jangan asal mematikan service hanya karena namanya asing. Di server produksi, cek dependensi aplikasi dan dokumentasikan perubahan.

Kapan dipakai: setelah instalasi awal, sebelum server menerima trafik, dan setiap kali ada aplikasi baru dipasang.

7. Aktifkan update keamanan otomatis dengan pertimbangan

Untuk VM kecil, server internal, atau node yang fungsinya sederhana, update keamanan otomatis bisa mengurangi patch yang terlewat. Di Debian atau Ubuntu, gunakan unattended-upgrades.

sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure -plow unattended-upgrades

Namun untuk server dengan stack sensitif, otomatisasi penuh kadang bukan pilihan terbaik. Update library tertentu bisa memicu restart service atau perubahan perilaku aplikasi. Model yang sering dipakai: patch otomatis untuk security update, reboot tetap terjadwal dan dipantau.

Kapan dipakai: cocok untuk server standar dengan risiko perubahan rendah. Server kritikal tetap perlu proses change management.

8. Rapikan permission file dan rahasia aplikasi

File konfigurasi sering menyimpan password database, token API, private key, atau kredensial SMTP. Jangan biarkan file semacam ini bisa dibaca semua user lokal.

sudo chown root:appuser /etc/myapp/app.env
sudo chmod 640 /etc/myapp/app.env
sudo chmod 600 /home/denrama-admin/.ssh/authorized_keys

Hindari menaruh secret di repository Git atau command history. Untuk skala kecil, file environment dengan permission ketat sudah cukup. Untuk lingkungan yang lebih besar, pertimbangkan secret manager.

Kapan dipakai: setiap kali memasang aplikasi, CI/CD runner, backup agent, atau integrasi pihak ketiga.

9. Pastikan log, sinkronisasi waktu, dan backup benar-benar jalan

Hardening bukan cuma soal mencegah akses. Saat insiden terjadi, log dan backup yang rapi jauh lebih berharga daripada tebakan. Pastikan NTP aktif agar timestamp log tidak berantakan.

timedatectl status
sudo systemctl enable --now systemd-timesyncd

Untuk backup, lakukan uji restore. Bukan sekadar melihat job backup berstatus sukses. Coba pulihkan file atau database ke lokasi terpisah, lalu pastikan datanya memang terbaca.

Kapan dipakai: sejak hari pertama. Backup yang belum pernah diuji pada dasarnya belum bisa dianggap backup.

10. Audit berkala, jangan hanya hardening sekali lalu lupa

Konfigurasi aman hari ini bisa berubah setelah deploy aplikasi, membuka port baru, atau menambah user. Jadwalkan pemeriksaan ringan: user lokal, port terbuka, service aktif, disk usage, log autentikasi, dan status patch.

getent passwd
sudo ss -tulpn
sudo journalctl -u ssh --since "7 days ago"

Tool seperti Lynis juga cukup membantu untuk mendapatkan daftar temuan awal. Anggap hasilnya sebagai bahan review, bukan daftar yang harus dipenuhi mentah-mentah. Ada rekomendasi yang relevan untuk server publik, tapi belum tentu cocok untuk workload internal.

Kapan dipakai: bulanan untuk server biasa, lebih sering untuk server yang menangani data sensitif atau punya perubahan konfigurasi tinggi.

Penutup

Urutan praktisnya: patch sistem, amankan SSH, tutup port yang tidak perlu, lalu pastikan logging dan backup bisa diandalkan. Tidak ada konfigurasi yang benar-benar final, tetapi fondasi ini sudah menutup banyak celah umum yang biasanya dimanfaatkan lebih dulu.