Belajar UFW - Manajemen Banyak Server & Audit

#Pendahuluan

Episode 20 mengajarkan otomasi untuk satu pola ruleset. Episode 21 menaikkan skala: banyak server, banyak peran, satu kebijakan. Inilah yang membedakan admin server tunggal dari tim ops yang mengelola fleet — kemampuan mendefinisikan kebijakan di satu tempat dan memastikan semua server patuh.

Mengapa ini penting? Karena semakin banyak server, semakin besar risiko drift — server yang menyimpang dari standar karena edit manual, konfigurasi lama, atau server baru yang lupa dikonfigurasi. Tanpa deteksi drift, kalian tidak pernah tahu server mana yang terbuka. Episode ini menyediakan kerangka untuk menjawab pertanyaan itu dengan pasti.

#Policy Rule Terpusat dengan Inventory

Kuncinya adalah memisahkan kebijakan (rule) dari data (server). Ansible memungkinkan ini lewat inventory + group variables.

#Struktur Inventory

inventory/
├── production/
│   ├── hosts.yml
│   └── group_vars/
│       ├── all.yml
│       ├── webservers.yml
│       └── databases.yml
└── staging/
    ├── hosts.yml
    └── group_vars/
        └── all.yml

#Definisikan Peran via Group Vars

Setiap grup server mendefinisikan port yang dibutuhkan — satu sumber kebenaran:

ufw_policy:
  - { rule: allow, port: 22, proto: tcp }
  - { rule: allow, port: 80, proto: tcp }
  - { rule: allow, port: 443, proto: tcp }
 
ufw_defaults:
  incoming: deny
  outgoing: allow

ufw_policy:
  - { rule: allow, port: 22, proto: tcp }
  - { rule: allow, port: 5432, proto: tcp, from_ip: 10.0.1.0/24 }
 
ufw_defaults:
  incoming: deny
  outgoing: allow

#Playbook yang Membaca Policy

Playbook tunggal yang berlaku untuk semua grup:

- name: Deploy firewall UFW ke semua server
  hosts: all
  become: true
  tasks:
    - name: Default policies
      community.general.ufw:
        default: "{{ ufw_defaults.incoming }}"
        direction: incoming
      when: ufw_defaults is defined
 
    - name: Terapkan rules dari policy
      community.general.ufw:
        rule: "{{ item.rule }}"
        port: "{{ item.port | default(omit) }}"
        proto: "{{ item.proto | default(omit) }}"
        from_ip: "{{ item.from_ip | default(omit) }}"
      loop: "{{ ufw_policy }}"
      when: ufw_policy is defined

Dengan pola ini, menambahkan server baru ke inventory sudah cukup — playbook akan menerapkan kebijakan yang sesuai dengan grupnya. Satu definisi, seluruh fleet patuh.

#Deteksi Drift

Drift adalah ketika server menyimpang dari definisi kode. Dua pendekatan deteksi:

#Deteksi Aktif: Verifikasi Rutin

Jalankan playbook dalam mode check yang membandingkan state aktual dengan definisi:

ansible-playbook deploy-firewall.yml --check --diff

--check mensimulasikan tanpa menerapkan; --diff menampilkan perbedaan yang akan terjadi. Hasilnya adalah daftar drift di seluruh fleet.

#Deteksi Pasif: Dump dan Bandingkan

Ekspor ruleset semua server, lalu bandingkan dengan standar:

ansible all -m shell -a "sudo ufw status verbose" > ufw-status-all.txt

#Dashboard Drift Sederhana

Dengan beberapa baris parsing, kalian bisa membangun indikator sederhana:

grep -c "Status: active" ufw-status-all.txt
grep -L "Status: active" ufw-status-all.txt

Server yang tidak active muncul di output kedua — kandidat untuk perhatian segera.

#Ekspor Ruleset untuk Backup dan Compliance

Backup ruleset sama pentingnya dengan backup data. Dua bentuk ekspor:

#Frontend (untuk rekonstruksi perintah)

sudo ufw show added > ufw-rules-backup.txt
cat ufw-rules-backup.txt

ufw allow 22/tcp
ufw allow 80/tcp
ufw limit 443/tcp

File ini bisa dijalankan ulang langsung (bash ufw-rules-backup.txt) — rekonstruksi sempurna.

#Backend (untuk state persis)

sudo iptables-save > ufw-iptables-save.txt

iptables-save menghasilkan ruleset mentah yang bisa dikembalikan dengan iptables-restore. Ini snapshot persis yang dijalankan kernel.

#Compliance Checklist

Checklist yang bisa dipakai untuk audit seluruh fleet:

• Semua server: ufw status = active, service ufw enabled saat boot.
• Default policies: deny incoming, allow outgoing, forward sesuai kebutuhan (episode 9).
• SSH: hanya dari IP/subnet yang disetujui, atau rate limit; tidak ada deny yang mati (episode 17).
• Port layanan: sesuai peran (web/mail/db), tidak ada port tidak dikenal terbuka (episode 15-16).
• Tidak ada drift: state server sama dengan definisi kode (episode 20).
• Logging aktif dan log dirotasi (episode 12).
• Backup ruleset tersedia dan bisa dipulihkan.
• Dokumentasi perubahan ruleset mutakhir (episode 17).
• Integrasi aman: Docker/KVM ditangani via DOCKER-USER atau interface (episode 14).

Jalankan checklist ini berkala; setiap item yang gagal adalah tiket perbaikan.

#Common Pitfalls

1. Policy duplikat antar grup: server di dua grup (misal web + db) bisa menerima ruleset gabungan yang membingungkan. Desain grup dengan overlap yang jelas.
2. Drift tanpa deteksi: edit manual di satu server akan menghilang saat playbook dijalankan lagi — dan jika kalian tidak pernah memeriksa, tidak ada yang tahu.
3. Backup ruleset tidak pernah diuji restore: backup tanpa uji restore (episode rsync mengajarkan ini) tidak bernilai. Uji iptables-restore di lab.
4. Compliance checklist tanpa penjadwalan: checklist yang tidak dijalankan berkala hanyalah dokumen. Pasang reminder atau CI job.

#Penutup

Pada episode 21 ini, kalian telah menguasai manajemen banyak server.

Inti yang harus dibawa pulang:

• Definisikan policy terpusat di inventory/group vars; satu playbook menerapkannya ke semua server.
• Deteksi drift: ansible-playbook --check --diff dan ekspor status berkala.
• Ekspor ruleset dalam dua bentuk: ufw show added (rekonstruksi) dan iptables-save (state persis).
• Compliance checklist menilai seluruh fleet dengan standar yang sama.
• Backup tanpa uji restore tidak bernilai; jadwalkan audit berkala.

Di episode 22 — episode terakhir — kita menutup perjalanan dengan Gufw, Alternatif & Refleksi Akhir: GUI Gufw untuk desktop, alternatif seperti firewalld dan cloud security groups, rekap seluruh series, checklist production final, dan sumber belajar resmi. Sampai jumpa di episode 22!